Almost every network detection strategy in use rests on one behaviour: malware talks back. It beacons to a command server, resolves a suspicious domain, opens a connection somebody can flag.
Sleepwalker does none of that.
Malware researcher Dominik Reichel published an analysis on 24 August 2026 of a Windows backdoor that, in his words, never sends anything out on its own and does not open any obvious listening port by default — so tools that watch for connections to known-bad domains or unusual outbound traffic will not see anything unusual.
How it wakes up
It waits for a magic packet.
The backdoor sits dormant, sniffing traffic, until a specifically crafted packet arrives. Only then does it execute. There is no schedule, no callback interval, and nothing to correlate — the initiative belongs entirely to the operator, and the machine looks idle until the moment it is used.
That inverts the usual detection economics. Beaconing is what makes command-and-control findable: it is repetitive, it is periodic, and it happens whether or not the attacker is doing anything. A backdoor that speaks only when spoken to produces no baseline to deviate from.
The 23 instructions
Sleepwalker is a 64-bit Windows DLL that implements its own bytecode command language — 23 instructions, encrypted with AES-256-CCM, decoded as raw byte sequences rather than readable text.
Reichel's summary: the 23 instructions cover scheduling, several ways to move data, staged file delivery and running code directly in memory.
Broken down:
| Group | Instructions |
|---|---|
| Magic-packet sniffing | 2 |
| Basic operations (exit, listener startup) | 2 |
| Data transmission and concealment | 4 |
| Inbound task reception | 5 |
| Program building and execution | 5 |
The data-movement group covers TCP connections, writes to named pipes, and optional credential authentication. The inbound group covers listening on TCP and UDP ports and creating named pipes.
Named pipes matter here. Traffic over a named pipe between machines rides inside SMB, which is ordinary Windows administrative traffic in every enterprise on earth. It is not an exotic channel; it is the most boring one available.
It loads through a security product
The delivery is the part that should make a defender uncomfortable.
Sleepwalker masquerades as Microsoft's dpapi.dll, the Windows Data Protection API library. It exports seven legitimate dpapi.dll functions and forwards those calls onward to a fictitious dpapisvc.dll, so the functions that are supposed to work still appear to.
It reaches memory by DLL side-loading through ERAAgent.exe — the ESET Management Agent — with a forged ESET Management Agent version resource attached to make the file look right.
A security vendor's own management agent is a well-chosen host. It runs with privilege, it is expected on the machine, and it is frequently excluded from the very scanning that would examine what it loads.
That is the same theme running through this month: an implant that unlinks EDR callbacks in the kernel, a signed Defender driver that can delete Defender at boot, malware that sets its own Defender exclusions. Here the security software is not disabled at all. It is used as the ladder.
What the researcher will not claim
This is the part worth holding up.
Reichel states directly that he has no collection context tying the file to a confirmed intrusion, and therefore cannot identify a victim, industry, country or affected organisation.
He assesses the design as indicating a targeted, well-resourced operation rather than an opportunistic one — and notes there is no code correlation with any known group. He does not name an actor, and he does not stretch the sample into a campaign.
A researcher publishing a capable backdoor with no attribution, no victim and no campaign attached, and saying so in the analysis itself, is doing the job correctly. Most of the pressure in this field runs the other way.
He also shipped a toolkit for decoding the bytecode and analysing the encrypted artefacts, plus a remediation script and mitigation guide.
What to do
- Stop treating "no outbound traffic" as evidence of cleanliness. This is the sample that breaks that assumption.
- Hunt on the host, not the wire. DLLs loaded by ERAAgent.exe and other management agents, unexpected dpapi.dll copies outside System32, and version resources that do not match the signing.
- Look at named pipe creation and unexpected listeners, including UDP. The magic-packet sniffing does not require a bound port, but several of the 23 instructions do open one.
- Check whether your management and EDR agents' directories are excluded from scanning. That exclusion is what makes side-loading through them worth doing.
- Use Reichel's toolkit if you have a suspect sample. It is published.
What is not established
Reichel's own list, which is unusually complete:
- The initial compromise vector, and how the malware was delivered.
- Who built or operates it. No attribution.
- Any victim — organisation, industry or country.
- What was done post-compromise.
- Deployment scope, timeline, variants, or whether the campaign is ongoing.
