TryHackMe Detecting AD Post-Exploitation Walkthrough

Detecting AD Post-Exploitation

The last room in the Active Directory for SOC module, and the one that awards the module badge. The previous four covered monitoring, initial access, credential attacks, and lateral movement. This one is what happens once the attacker already owns the domain and starts acting on objectives: long-term persistence, ransomware deployment, and outright data destruction.

Seven tasks, eighteen graded answers, all solved 100%. The structure is unusual for this module, roughly half the questions are open research against public incident reports (CISA, Aviatrix, SentinelLabs) rather than Splunk queries, and the lab data is split one index per task: task3, task4, task5.

Standing advice for the whole module still applies: set the time picker to All time, this data is timestamped February 2026.

Task 2: the research warm-up

Three questions against two public reports, and they are worth doing properly rather than guessing, because the answers are specific.

For Volt Typhoon, CISA advisory AA24-038A says it plainly in the Collection and Exfiltration section: the actors “collected sensitive information obtained from a file server in multiple zipped files [T1560] and likely exfiltrated the files via Server Message Block (SMB) [T1048].” So the file type is zip and the protocol is SMB. Worth flagging because the obvious guesses are wrong, I tried PDF and FTP first and both were rejected. Volt Typhoon does famously hunt .docx/.xlsx/.pdf/.pst files (that is from the earlier AA23-144A advisory), but this question is about what left the network, not what was searched for. The collected material was OT documentation: diagrams for SCADA systems, relays, and switchgear.

For the Synnovis breach, Qilin’s June 2024 attack on the pathology provider for London’s NHS hospitals, 400 GB of patient data stolen then encrypted, the Aviatrix threat research report maps exfiltration to T1041 (Exfiltration Over C2 Channel).

Task 3: long-term persistence

Now into Splunk. The scenario is a rogue account planted for future access, and the whole story is four events on DC-01:

index=task3 (EventCode=4720 OR EventCode=4728 OR EventCode=4732 OR (EventCode=1 AND Image="*AppData*"))
| eval evidence=case(EventCode==1, "Exec: ".Image,
                     EventCode==4720, "User created: ".SAM_Account_Name." by ".Subject_Account_Name,
                     true(), "Added to ".Group_Name." by ".Subject_Account_Name)
| table _time, host, EventCode, evidence | sort _time

So the malicious file ran from C:\Users\maria.garcia\AppData\Roaming, the planted account is hans.schmidt, the remote-access group is Remote Desktop Users, and it hit Domain Admins at 09:41:07.

The last question, did the attacker later log in with it?, is answered by an absence:

index=task3 hans.schmidt | stats count by EventCode
#   1, 4738, 4720, 4722, 4724, 4728 , and no 4624 anywhere

No successful logon event exists for the account, so the answer is Nop. That is the entire point of this kind of persistence: the account is created, fully privileged, and then deliberately left dormant so it blends into the directory and survives the incident response that follows. If you only alert on usage, you never see it. You have to alert on the creation, a new account added to Domain Admins twenty-three minutes after a binary ran out of AppData\Roaming is the detection, and there is no second chance at it.

Task 4: destroying recovery options

Before encrypting anything, competent ransomware operators remove the victim’s ability to recover and the defender’s ability to reconstruct. Three commands, nine minutes:

index=task4 EventCode=1 (CommandLine="*shadow*" OR CommandLine="*vssadmin*" OR CommandLine="*wevtutil*")
| table _time, host, ProcessId, CommandLine | sort _time

So the enumeration command is vssadmin list shadows, the PID that actually performed the deletion is 5520, and the logs cleared were the Security logs.

Two details make this a good teaching case. The attacker enumerated before destroying, list seven minutes before delete, which gives you a genuine early-warning window: vssadmin list shadows from an interactive session is itself suspicious and precedes the damage. And the log clearing is self-defeating from the attacker’s perspective: clearing the Security log generates Event 1102 (audit log cleared), which fired one second later at 10:38:34. You cannot delete your way out of that one, because 1102 is written by the act of clearing. In a real environment with log forwarding, everything before the wipe is already off the box anyway, which is exactly why this data still exists for us to query.

Task 5: the ransomware fan-out

The payload and its distribution, in one view:

index=task5 (EventCode=11 OR (EventCode=1 AND CommandLine="wmic *node:*"))
| eval evidence=if(EventCode==11, "DROPPED: ".TargetFilename, CommandLine)
| table _time, host, EventCode, evidence | sort _time

At 11:19:58 PowerShell writes C:\Windows\fixer.exe onto TSM-PROD-01. Then from 11:31:50 to 11:32:29, thirty-nine seconds, DC-01 issues six near-identical commands:

wmic /node:tsm-prod-0N.trysaveme.local /user:maria.garcia /password:P@ssw0rd123! process call create C:\Windows\fixer.exe

tsm-prod-01 through tsm-prod-06. So the executable is C:\Windows\fixer.exe, the execution method is T1047 (Windows Management Instrumentation), and 6 systems were targeted.

The final question is whether it worked, and again the answer is an absence. Searching the whole index for fixer returns only the file-create on TSM-PROD-01 and the twelve command-line events on DC-01, there is no process-creation event for fixer.exe on any target. The answer is Nop: the attacker issued the commands, but the ransomware never ran.

That distinction matters more than it looks. In a live incident this is the difference between “we were encrypted” and “we caught them at the last step”, and the evidence for it is negative, you prove it by showing the execution events that should exist and do not. It is also a reminder that a wmic process call create returning successfully to the operator does not mean the binary ran on the far end.

Also worth noting: the plaintext credentials sitting right there in the command line (/user:maria.garcia /password:P@ssw0rd123!). WMIC’s remote syntax puts the password on the command line, so any environment with process command-line auditing captures the attacker’s working credentials for free. That is a gift both for detection and for scoping which account to reset.

Task 6: wipers

Back to research. Data Destruction under the Impact tactic is T1485, stated in the task text itself.

The other two are genuine open research. HermeticWiper, used against Ukraine in February 2022, was delivered via Discord, attacker infrastructure abused the Discord CDN (cdn.discordapp.com) to host and serve the payload, which is a recurring trick because the domain is widely allowlisted and TLS-protected. And for Apostle, the wiper-masquerading-as-ransomware from the Iranian-linked Agrius group, SentinelLabs’ From Wiper to Ransomware: The Evolution of Agrius states that “Agrius uses those webshells to tunnel RDP traffic in order to leverage compromised accounts to move laterally.” So the tunnelling protocol is RDP, not the DNS you might reflexively guess for the word “tunneling”.

The room is candid that this task is research rather than detection, and the reason is sound: identifying a wiper from logs at the moment it runs is close to impossible. By the time the destruction is visible in telemetry the data is gone. Everything defensible happens earlier, which is what the previous four rooms were about.

Task 7: closing the module

Two habits from this room generalise well beyond it.

Absence is evidence. Two of the eighteen answers, did the rogue account log in, did the ransomware execute, are both “Nop”, and both are established by searching for events that should exist and finding none. That is an uncomfortable kind of proof to write into a report, so it is worth being explicit about the query you ran and the events you expected, rather than just asserting nothing happened.

Every destructive step has a louder precursor. vssadmin list before vssadmin delete. A binary in AppData\Roaming before a new Domain Admin. A file dropped on one host before WMIC fans it out to six. The post-exploitation phase is where an intrusion becomes expensive, but it is never where it becomes detectable, it was detectable in the four rooms that came before this one. This room is mostly a demonstration of what it costs to have missed those.

Room solved 100%: seven tasks, eighteen answers, and the Active Directory for SOC module badge.