DEV Community

Shadrach Adongo
Shadrach Adongo

Posted on

TryHackMe After Hours Walkthrough โ€” Medium Windows Forensics Room

๐ŸŽฏ 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:

  1. ๐Ÿ•ต๏ธ Reviewing Windows Event Logs for signs of intrusion
  2. ๐Ÿงฉ Understanding how WMI Event Subscriptions work
  3. ๐Ÿ” Locating the malicious WMI consumer, filter, and binding
  4. ๐Ÿšฉ 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 }
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

๐Ÿ’ก 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
Enter fullscreen mode Exit fullscreen mode

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 *
Enter fullscreen mode Exit fullscreen mode

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 *
Enter fullscreen mode Exit fullscreen mode

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 CommandLineTemplate or 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>
Enter fullscreen mode Exit fullscreen mode

๐Ÿšฉ 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 *
Enter fullscreen mode Exit fullscreen mode

๐ŸŽ“ 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)