๐ฏ Room Info
| Room | After Hours |
| Difficulty | ๐ก Medium |
| Category | Windows Forensics, WMI Persistence, Incident Response |
| Link | tryhackme.com (search "After Hours") |
๐ What This Room Is About
After Hours flips the format from "attacker" to "defender." Instead of exploiting a box, you're handed forensic artifacts (often a memory image, event logs, or a full disk/registry export) from a machine that was compromised outside business hours, and your job is to figure out how the attacker got in and โ critically โ how they made sure they'd stay in.
The specific mechanism at the center of this room is WMI (Windows Management Instrumentation) persistence โ a technique attackers use specifically because it's fileless and easy to miss with traditional antivirus, since it lives inside the WMI repository rather than as a file on disk.
The room covers:
- ๐ต๏ธ Reviewing Windows Event Logs for signs of intrusion
- ๐งฉ Understanding how WMI Event Subscriptions work
- ๐ Locating the malicious WMI consumer, filter, and binding
- ๐ฉ Extracting the flag from the persistence artifact itself
๐ง Skills You'll Practice
- Windows Event Log analysis (Security, System, Sysmon if present)
- Understanding WMI persistence internals (
__EventFilter,__EventConsumer,__FilterToConsumerBinding) - Using PowerShell / native tools to enumerate WMI subscriptions
- Correlating timestamps to build an incident timeline
๐ ๏ธ Step-by-Step Walkthrough
1๏ธโฃ Get oriented in the provided environment
Rooms like this usually give you either:
- RDP/SSH access to a pre-compromised Windows VM, or
- A set of exported log files (
.evtx) and a WMI repository dump to analyze offline
Start by identifying what you actually have access to and what tools are available (PowerShell, Event Viewer, wevtutil, or a forensic suite like Autopsy/FTK if the room provides one).
2๏ธโฃ Review Windows Event Logs for initial access clues
Start broad โ look for logon anomalies, especially outside normal hours (hence the room's name):
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
Where-Object { $_.TimeCreated.Hour -lt 6 -or $_.TimeCreated.Hour -gt 20 }
Event ID 4624 = successful logon. Filtering for off-hours activity is a classic first step in identifying suspicious access.
Also check for:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} # Failed logons (brute force signs)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} # New process creation
๐ก Why this matters: correlating logon times with process creation events lets you build a real timeline โ "user X logged in at 2:47 AM, then spawned PowerShell 30 seconds later" is exactly the kind of pattern real incident responders hunt for.
3๏ธโฃ Look specifically for WMI activity
WMI persistence has a very distinctive signature once you know where to look. The three components an attacker sets up are:
| Component | Purpose |
|---|---|
__EventFilter |
Defines the trigger (e.g. "system startup" or "every N seconds") |
__EventConsumer |
Defines the action to take (e.g. run a script or command) |
__FilterToConsumerBinding |
Links the filter to the consumer, activating the persistence |
Enumerate all three directly with PowerShell:
Get-WmiObject -Namespace root\subscription -Class __EventFilter
Get-WmiObject -Namespace root\subscription -Class __EventConsumer
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding
Legitimate WMI subscriptions do exist on Windows by default (some are built in), so the goal is spotting the out-of-place one โ often referencing a suspicious script path, an encoded PowerShell command, or a consumer name that doesn't match anything on the vendor's standard list.
4๏ธโฃ Inspect the malicious consumer in detail
Once you've spotted a suspicious entry (commonly a CommandLineEventConsumer or ActiveScriptEventConsumer), pull its full definition:
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer | Format-List *
Look at the CommandLineTemplate field โ this shows you exactly what the attacker configured the system to run, and often contains the flag directly, or a path to a script that does.
๐ก Why this matters: WMI persistence is popular with real-world attackers (including several APT groups) specifically because it doesn't drop a traditional file that endpoint antivirus scans on disk โ it lives inside the WMI repository (
OBJECTS.DATA) instead. Knowing how to hunt it manually is a genuinely valuable blue-team skill, not just a CTF trick.
5๏ธโฃ Check the trigger condition
Pull the matching __EventFilter to understand when this persistence fires:
Get-WmiObject -Namespace root\subscription -Class __EventFilter | Format-List *
The Query field uses WQL (WMI Query Language) and typically shows something like a timer interval or a system startup trigger โ this tells you how often the attacker's payload re-executes.
6๏ธโฃ Extract the flag
Depending on how the room is built, the flag is either:
- Directly visible inside the
CommandLineTemplateor script referenced by the consumer - Written to a file that the WMI persistence creates/writes to, which you then read directly:
Get-Content C:\Users\Public\<artifact-file>
๐ฉ Click to reveal: flag
Redacted โ swap in your own captured flag if you want to keep a private record.
๐ Every Command, In Order
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624}
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625}
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688}
Get-WmiObject -Namespace root\subscription -Class __EventFilter
Get-WmiObject -Namespace root\subscription -Class __EventConsumer
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer | Format-List *
๐ Key Takeaways
- WMI persistence is fileless โ which is exactly why it's dangerous. It doesn't rely on a dropped executable or scheduled task entry that traditional AV signatures easily catch.
-
The three-part structure (
FilterโConsumerโBinding) is always the pattern. Once you recognize it, hunting for it on any Windows box becomes a repeatable checklist, not guesswork. - Off-hours logon correlation is a simple but effective triage technique. Real SOC analysts use exactly this kind of time-based filtering as a first pass before diving deeper.
- Blue team skills matter as much as offensive ones. Knowing how an attacker persists is only half the value โ knowing how to find that persistence after the fact is what actually stops a breach from becoming a long-term compromise.
Top comments (0)