You’ll notice a lot of our critical server infrastructure was recently transferred from the domain of our MSSP - Forela.local over to Northpole.local. We actually managed to purchase some second-hand servers from the MSSP who have confirmed they are as secure as Christmas is! It seems not as we believe Christmas is doomed and the attackers seemed to have the stealth of a clattering sleigh bell, or they didn’t want to hide at all!!!!!! We have found nasty notes from the Grinch on all of our TinkerTech workstations and servers! Christmas seems doomed. Please help us recover from whoever committed this naughty attack!
The attacker reached the domain controller from a single internal host by exploiting the Netlogon Zerologon flaw, which left an unusual service behind and an anonymous machine-account authentication in the logs within a second of each other. They then logged on with the built-in administrator and a second account, and registered a scheduled task for persistence. Files across the estate were later encrypted with a custom XOR scheme, and the key was recoverable from strings in a dropped DLL. The encrypted files could be decrypted with that key, and the recovered documents answer what the ransom note’s victim had written down. The process that wrote the encrypted files is identifiable from file virtualization events, since the collection has no memory image.
DANGER.txt → extract, then parse the collected Logs folder with EvtxECmdEvtxECmd CSV output, filtered with Python.xmax files from the victim → decrypt with a script once the key is knownstrings only, never executedTimestamp note: The event log CSVs are in UTC, which is what the time questions ask for. Answer in
YYYY-MM-DD hh:mm:ss.
Parse the event logs and look at the System log (7045) and Security log (4742) around the first signs of trouble. A service named vulnerable_to_zerologon was installed, and an anonymous Netlogon change to the DC01$ computer account (4742) came from the internal address that shows up again in Q5. An anonymous logon changing a domain controller’s machine account is the Zerologon signature, which maps to the CVE named in the reveal.
EvtxECmd -d Logs --csv work/evtx# filter the parsed CSV for EventIds 7045, 7036, 5805, 4742 around 2023-12-13 09:24The exploit shows up twice at the same second: Netlogon event 5805 in the System log and the anonymous-logon 4742 in the Security log. Both carry the same timestamp, so there is no ambiguity about when the exploit landed.
# same filter as Q1: rows with EventId in (5805, 4742) at 2023-12-13 09:24The service-install event (7045) for vulnerable_to_zerologon records the binary in its ImagePath. It points at a randomly named executable under %systemroot%, the usual pattern for an exploit tool that installs and starts its payload as a service.
# EventId 7045 rows from the System log CSV; read the ImagePath fieldService state changes are event 7036. The entry saying vulnerable_to_zerologon entered the running state is the start, one second after the exploit time from Q2.
Gotcha: The 7045 install event and the 7036 start event are different records. The question asks for the start, so take the time from the 7036 row.
# EventId 7036 rows for vulnerable_to_zerologon in the System log CSVThe Task Scheduler operational log records task registration as event 106. One task under \Microsoft\ was registered by the bytesparkle account, one of the two accounts the attacker used (see Q6), and its name is the answer.
# EventId 106 rows from Microsoft-Windows-TaskScheduler/Operational; read the task name and userNetwork logons (4624, type 3) to the domain controller for the administrator account and the DC01$ machine account share one source address. That is the same host behind the anonymous Netlogon event in Q1.
# EventId 4624, LogonType 3 rows; group by source IPPivot on the Q5 address and list the account names on every 4624 logon from it. Two real user accounts appear. Sort them alphabetically as the question asks.
# EventId 4624 rows where source IP = 192.168.68.200; unique TargetUserNameThe encrypted files carry the .xmax extension. Running strings on the dropped splunk_svc.dll turns up a readable XOR key, EncryptingC4Fun!. XOR-decrypting the .xmax files with it restores the originals. The documents include a topsecret image and PDF about the new sleigh, which name the animals that will pull it. This answer was read from the decrypted documents, but the decryption script is a one-off and isn’t reproduced here.
strings splunk_svc.dll | less# XOR each .xmax file with the key from the DLL, write results to work/decpdftotext topsecret.pdf -Tip: The format hint is a single word ending in
n. The documents name the creature in plural, so reduce it to the singular.
The KAPE collection has no memory image, so a live process listing is not available. The UAC-FileVirtualization log has the data instead. Events 4000 and 5004 show rundll32.exe writing .xmax files, and the event header carries the ProcessId of the writer.
# EventId 4000/5004 rows from the UAC-FileVirtualization log; read the header ProcessId for rundll32.exe writing .xmax| Phase | Action |
|---|---|
| Initial Access | Zerologon exploited against DC01 from an internal host |
| Persistence | Service vulnerable_to_zerologon installed with a randomly named executable and started a second later |
| Lateral Movement | Network logons from the same host as the built-in administrator and a second account |
| Persistence | Scheduled task created under the second account |
| Impact | Files encrypted to .xmax with a XOR key held in the dropped DLL, written by rundll32.exe |
| Type | Value |
|---|---|
| CVE | CVE-2020-1472 |
| IP (attacker, internal) | 192.168.68[.]200 |
| Service | vulnerable_to_zerologon |
| File | %systemroot%\hAvbdksT.exe |
| File | splunk_svc.dll |
| Account | Bytesparkle |
| Scheduled task | \Microsoft\svc_vnc |
| File extension | .xmax |
| XOR key | EncryptingC4Fun! |
| Technique | ID | Description |
|---|---|---|
| Exploitation of Remote Services | T1210 | Zerologon against the domain controller |
| Create or Modify System Process: Windows Service | T1543.003 | vulnerable_to_zerologon service with a random-name executable |
| Valid Accounts: Domain Accounts | T1078.002 | Logons as Administrator and Bytesparkle from the attacker host |
| Scheduled Task/Job: Scheduled Task | T1053.005 | svc_vnc task registered by the attacker account |
| Data Encrypted for Impact | T1486 | .xmax files encrypted with a XOR key |
An unpatched domain controller handed over the domain. Zerologon (CVE-2020-1472) has had a patch available since 2020, and the logs show an anonymous Netlogon machine-account change followed one second later by a service install. Patch DCs and enforce secure Netlogon channel enforcement mode.
Anonymous machine-account changes on a DC should alert. Event 4742 with an anonymous logon, or Netlogon 5805 failures for a DC’s own account, should be a high-severity detection on its own.
A new service with a random name on a DC is rarely benign. Event 7045 for an executable in %systemroot% with a random name is cheap to alert on, and here it was named after the vulnerability.
Hardcoded keys in malware reverse the damage. The XOR key sat in plain strings in the dropped DLL, so the victim’s files were recoverable. Keep sample DLLs from incident triage, because their strings can matter for recovery.
Log what writes to disk when you have no memory. UAC-FileVirtualization events gave the encrypting process ID when no memory image existed. Collect memory during triage where you can.
The attacker went from a single internal host to encrypted files by exploiting a Netlogon flaw on the domain controller, and the exploit announced itself in the logs within a second. The files were recoverable because the XOR key was left in plain strings.