TryHackMe After Hours Walkthrough — Medium Windows Forensics Room

🎯 Room Info

📖 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 }

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:

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 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>

🚩 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.