SLEEPWALKER: A Passive Backdoor That Wakes Up for Exactly One Packet, Carries Its Own Bytecode Language, and Hides Inside ESET Management Agent
Overview
On August 24, 2026, independent malware researcher Dominik Reichel (former Palo Alto Networks Unit 42) published an exceptionally detailed analysis on his personal blog (r136a1.dev) of SLEEPWALKER — a previously undocumented Windows backdoor.
SLEEPWALKER is a passive backdoor in the strictest sense: it never autonomously contacts a command-and-control server, carries no second-stage payload, and contains no hardcoded domain, IP address, or URL. It sits completely dormant in memory until one specifically crafted network packet (a magic packet) reaches the machine — and only then does it decrypt and execute an attacker-supplied "task program."
What makes SLEEPWALKER technically noteworthy isn't just the magic-packet mechanism — which has precedent in Linux implants like BPFDoor used by Red Menshen in telecom networks — but the fact that the task program is not readable text or a structured config file, but bytecode written in a command language designed entirely by the backdoor itself, comprising 23 instructions. This means recovering the encryption key is not enough to understand a command — the analyst must also reverse-engineer the entire proprietary language format, one that exists nowhere outside this file.
The analyzed sample is an unsigned 64-bit Windows DLL, designed to side-load into ERAAgent.exe — the executable for ESET Management Agent — while impersonating Microsoft's dpapi.dll.
Important context note: This analysis is based on a single binary sample with no collection context. Reichel cannot identify victims, industry, country, or even whether this sample was ever deployed in the wild. This is not a report about an active campaign — it is a deep technical analysis of a tool's capabilities, discovered by working through an old sample backlog. As of August 26, ESET had not issued any advisory or public statement about this malware.
About the Discovery and Operational Assessment
Because no threat actor has been identified, this section summarizes the discovery context and what can be assessed about the operation (if any) behind the tool — not a conventional threat-actor profile.
| Attribute | Detail |
|---|---|
| Discoverer | Dominik Reichel — independent researcher, former malware analyst at Palo Alto Networks Unit 42 |
| Discovery context | Found while working through an old sample backlog after losing VirusTotal Intelligence access earlier in the year |
| Attribution | Cannot be determined — Reichel found no similar code in anything he had analyzed previously |
| Operational character assessment | The approach is consistent with a targeted, well-resourced operation rather than an opportunistic one |
| Basis for that assessment | Based on a single binary with no accompanying collection context — an important limitation |
| Victims / industry / country | Cannot be determined |
| Ever deployed in the wild? | Cannot be determined — nothing in the sample proves it was ever successfully used |
| Sample compilation timestamp | 2024-06-10 09:18:27 UTC — suggesting the sample may have existed for some time before discovery |
| Detection coverage at time of publication | Low (per Reichel's assessment; specific basis not stated) |
Technical Analysis
1. File Characteristics and Disguise
The sample is an unsigned 64-bit Windows DLL in 59,904 bytes:
SHA-256: d347170752a28e2b8c4b8b9f3cab2e3a6541ba11682c94498d26eb9002779d60
SHA-1: 2ec8aa9661a33bccc002150ce1ed02d90c3986ff
MD5: 2318327b29bb1c0e2d2b5f0211fc7fac
Imphash: 4e2dbfa7e3efd4cca2f3662797df9735
To complete the disguise, the file carries a version resource copied from the real ESET Management Agent: CompanyName "ESET," ProductName "ESET Management Agent," FileDescription "ESET Management Agent Module," OriginalFilename "dpapi.dll," version 11.2.2076.0.
The file exports the correct name and exactly 7 functions that Windows's real dpapi.dll provides: CryptProtectDataNoUI, CryptProtectMemory, CryptResetMachineCredentials, CryptUnprotectDataNoUI, CryptUnprotectMemory, CryptUpdateProtectedState, and iCryptIdentifyProtection. Each function is merely a small stub jumping through a pointer table that starts out empty. The first time any of these 7 functions is called, a shared resolver attempts to load a file named dpapisvc.dll — a name that belongs to no real Windows component (the closest real name, dpapisrv.dll, exports only two LSA extension functions). If the load fails, the resolver exits the entire host process rather than failing that single call — a design detail that could crash ESET Management Agent itself. That first call also silently re-runs the backdoor's own startup sequence — giving it a second chance to wake up if something blocked the first attempt.
2. Initialization and Startup Sequence
Before doing anything else, the DLL checks the name of the process that loaded it. If the process is not named ERAAgent.exe, the DLL stays inactive — meaning it will not run inside a debugger, sandbox, or any other program unless it happens to carry that exact name. After passing the check, a short sequence brings the backdoor to life: start a separate background thread, allocate a 128 KB memory buffer for assembling multi-part programs, decrypt the single instruction stored in the file, prepare networking, and hand that instruction to the internal interpreter.
There are two independent paths that both reach this startup sequence: (1) the DLL is loaded into ERAAgent.exe via DllMain, and (2) the first call to any of the 7 forwarded DPAPI functions. Neither path checks whether the other has already run — the root of a potential duplicate-worker issue in the design.
The ERAAgent.exe string used for the check, along with three function names the file never lists in its import table (VirtualProtect for shellcode execution, SetSecurityDescriptorDacl for permissive pipe permissions, and CryptGenRandom for randomized pauses), are never stored as readable text — all are reconstructed from number sequences at runtime.
3. No Autonomous Beaconing — No Fixed C2 Server
This is the defining characteristic of SLEEPWALKER's entire design. After confirming the host process name, the embedded bootstrap makes no outbound connection at all. There are no domains, IP addresses, or URLs anywhere in the file.
Instead, it puts the network card into promiscuous mode — allowing it to see every packet passing through, not just packets addressed to itself — then checks each packet against a specific pattern:
| Step | Check | If it fails |
|---|---|---|
| 1 | Packet is at least 48 bytes long | Ignored |
| 2 | XOR the packet's last two 16-bit values, then XOR the result with 0xAAAA to get a candidate length |
— |
| 3 | Candidate length falls within a valid range | Ignored |
| 4 | The byte pair at position (packet length minus candidate length) equals the sum, not XOR, of those same two trailing values | Ignored |
| 5 | The block the candidate length points to passes its own CRC-32 check | Ignored |
| 6 | Decrypt with AES-256-CCM and process the result as a command | — |
All of this runs against the raw packet contents before Windows has even classified it as TCP, UDP, or anything else — so the trigger can ride inside almost any form of IP traffic. The backdoor watches up to 8 network interfaces simultaneously, skipping loopback. After a successful trigger, it waits at least 3 seconds before accepting another.
Because the backdoor never sends anything out and opens no obvious listening port by default, tools that monitor for outbound connections to known-bad infrastructure will see nothing unusual. The only moment it becomes visible on the network is when the operator sends the trigger packet. A machine can be fully compromised by this backdoor while generating nothing for a network monitor to flag.
4. Authentication and Command Encryption
Every command sent to the backdoor is encrypted with AES-256-CCM — simultaneously hiding the content and authenticating that it hasn't been tampered with. The layout: a 12-byte nonce (changed each time), a 16-byte authentication tag, then the encrypted data. The raw trigger packet also carries its own separate CRC-32 checksum to cheaply discard non-matching packets before any decryption effort is spent.
Reichel recovered the encryption key and the configuration nonce during analysis:
AES-256 key: 0x746531ff378dbb4bb51d2aa2b1d38d905350a959583186baf4c690f5f316b3ae
Config nonce: 0x3a6d357fb9bc51eacc8b8509
All cryptography is provided by a statically linked copy of mbedTLS — nothing is loaded at runtime.
| Content | Direction | Protection |
|---|---|---|
| Task programs via raw trigger, TCP, UDP, named pipe, VMCI | Into SLEEPWALKER | AES-256-CCM |
| Task programs in DNS labels | Into SLEEPWALKER | Base32 over AES-256-CCM |
Programs loaded from file (RUN_FILE_SCRIPT) |
Local | AES-256-CCM |
Programs nested in CRON_SCHEDULE |
Internal | AES-256-CCM, then XOR in memory between runs |
Data sent via TCP_SEND/UDP_SEND/ICMP_SEND/PIPE_SEND |
Out of SLEEPWALKER | No automatic encryption — sent as the operator provided |
5. The Bytecode Format — the Backdoor's Own "Programming Language"
After decryption, a command is not text or a document — it is a raw byte sequence that only makes sense when read in a specific order. This is a second layer of protection placed behind encryption: recovering the key reveals a stream of opcodes in a format that exists nowhere outside this single file. To understand what a command means, an analyst must independently reverse-engineer the entire language — the key shows how to read the bytes; only reversing the command language shows what they mean.
Each instruction begins with a single byte identifying which of the 23 types it is. Fixed-size numbers are written most-significant-byte-first using a specified byte count. Variable-length text or data blocks are written as a compact byte count followed by the data itself.
The only instruction actually found stored in the analyzed file is SNIFF_MAGIC_PACKET (opcode 0x87), just 5 bytes, meaning: "watch every network interface, with no time limit, for the trigger packet." This is also the entire useful content of the bootstrap configuration embedded in the file — every other capability of the backdoor exists only as a potential of the language, waiting to be activated later over the network.
Several instructions carry an entire nested program as one of their parameters. The CRON_SCHEDULE instruction is the clearest example: its nested program is XOR-encrypted in memory between scheduled runs, only decrypted at execution time (decrypt → run → re-encrypt). This inner XOR layer is unique to CRON_SCHEDULE, sitting inside the outer AES-256-CCM envelope shared by all task programs.
6. Command Language Reference — 23 Instructions
| Instruction | Function |
|---|---|
| Basic control | |
EXIT (0x06) |
Sets a process-wide stop flag — stops every running program and listener, not just the one containing this instruction |
SPAWN_THREAD_SCRIPT (0x0B) |
Launches a nested program in a separate thread, running in parallel |
| Timing and scheduling | |
SLEEP_SECONDS (0x0C) |
Pauses for a fixed number of seconds |
SLEEP_RANDOM_SECONDS (0x0D) |
Pauses for a random number of seconds up to a limit — adds jitter |
CRON_SCHEDULE (0x0E) |
Matches current minute/hour/day/weekday against 4 stored bitmasks; runs a nested program when all 4 match |
REPEAT_N (0x0F) |
Runs a nested program a fixed number of times |
LOOP_FOREVER (0x10) |
Runs a nested program in an infinite loop until halted |
| Sending data | |
TCP_SEND (0x29) |
Opens a TCP connection, sends data, does not wait for a reply (supports VMCI destinations) |
UDP_SEND (0x2A) |
Sends a UDP payload without waiting for a reply (supports VMCI destinations) |
ICMP_SEND (0x2B) |
Hides data inside an ICMP echo request (ping packet) |
PIPE_SEND (0x2C) |
Writes data to a Windows named pipe on a remote machine, optionally authenticating with supplied credentials |
| Receiving task programs | |
TCP_CONNECT_RECV (0x6F) |
Actively connects outward then waits to receive a follow-up program (supports VMCI destinations) |
TCP_LISTEN_RECV (0x70) |
Opens a TCP port, waits for one connection, receives a program from the caller |
UDP_BIND_RECV (0x73) |
Opens a UDP port, waits to receive a single data block as a follow-up program |
PIPE_CLIENT_RECV (0x7D) |
Connects to a named pipe on a remote machine, waits to receive a follow-up program |
PIPE_SERVER_RECV (0x7E) |
Creates a local named pipe, waits for a connection, receives a program from the caller |
| Assembling and executing programs | |
STAGE_WRITE (0x32) |
Writes one chunk of a larger program into the shared 128 KB buffer at a specified offset — allows out-of-order assembly |
STAGE_VERIFY_EXEC (0x33) |
Compares a SHA-256 fingerprint of the assembled chunks against a supplied value; runs only on an exact match |
DECOMPRESS_RUN (0x1F) |
Decompresses an LZMA-compressed program to its original size, then runs it |
RUN_SHELLCODE (0x65) |
The only instruction in the language that hands bytes directly to the CPU — runs raw machine code in memory, switching the memory region from writable to executable just before calling it |
RUN_FILE_SCRIPT (0x66) |
Reads a file already present on disk, decrypts it using the same mechanism as every other channel, then runs it |
| Trigger detection | |
SNIFF_MAGIC_PACKET (0x87) |
Watches one or all network interfaces for the raw trigger packet — the instruction actually present in the analyzed sample |
SNIFF_MAGIC_PACKET_DNS (0x88) |
Same as above but also activates the DNS-based trigger channel — not active in the analyzed sample |
A notable observation: not one of all 23 instructions writes a file to disk. Anything the backdoor expects to find already present (like the file RUN_FILE_SCRIPT reads) must have been placed there by a separate component outside this tool — only RUN_SHELLCODE can create new files, and only through the machine code it executes.
7. Alternative Trigger Channels and 6 Transport Protocols
Five networking instructions (TCP_SEND, UDP_SEND, TCP_CONNECT_RECV, TCP_LISTEN_RECV, UDP_BIND_RECV) check whether the supplied address begins with the prefix vm: — if so, they switch to using VMware's VMCI (Virtual Machine Communication Interface) channel instead of a normal network address. VMCI is an internal communication channel between virtual machines and their physical host, operating through the virtualization layer rather than a physical network adapter — meaning a packet capture between two machines would completely miss this traffic. The UNC3886 group previously used VMCI sockets to deploy the VirtualPita and VirtualPie backdoors for lateral movement and persistence across compromised ESXi hosts and their guest VMs — exploiting CVE-2023-20867 (a VMware Tools authentication bypass) — as documented by Mandiant in June 2023.
A second trigger channel is also implemented, hiding commands inside ordinary-looking DNS queries — though not the active channel in the analyzed sample (requires opcode 0x88 instead of 0x87). Each DNS label carries a compact format: one marker character, a Base32-encoded middle section, and a second marker character. The two markers encode a CRC-8 checksum of the middle text, letting the backdoor cheaply distinguish a genuine trigger label from ordinary labels like example or com. This approach lets a command travel through networks that only permit outbound DNS — which many networks allow even when most other outbound traffic is restricted.
Taken together, SLEEPWALKER's networking instructions use 6 underlying transport protocols:
| Protocol | Mechanism | Notes |
|---|---|---|
| TCP | socket/connect/listen/accept | Both client and server |
| UDP | sendto/recvfrom | One-shot send and bind-and-receive |
| ICMP | IcmpSendEcho |
Data hidden inside ping echo-request payloads |
| SMB named pipe | CreateNamedPipeW/CreateFileW |
Can mount a remote share with supplied credentials — serves lateral movement |
| VMware VMCI | Address family resolved via \\.\VMCI |
Guest-to-host or guest-to-guest channel, bypasses physical network adapter entirely |
| Raw/Promiscuous | Raw socket in promiscuous mode | How the trigger packet is received |
8. Network Reachability and Attacker Positioning
One of the most analytically valuable contributions in Reichel's report is the clear distinction between delivering the first command to a dormant backdoor versus the reach of a running task.
| Channel | From the internet | Through firewall/NAT | Internal network | Target machine |
|---|---|---|---|---|
| Raw trigger (first command) | Blocked | Blocked | Reaches | Reaches |
| DNS trigger (implemented, not active in this sample) | Reaches | Reaches | Reaches | Reaches |
| VMCI (guest/host channel) | N/A | N/A | N/A | Only within the same VMware host |
| Outbound-initiated transports (after trigger) | Reaches | Reaches | Reaches | Reaches |
| Inbound-facing transports (after trigger) | Blocked | Blocked | Reaches | Reaches |
Delivering the first command depends on a regular packet actually reaching the network interface the backdoor is watching. A perimeter firewall or NAT gateway ordinarily blocks unsolicited raw traffic from the open internet — so in practice, the operator needs an existing position on or near the target network, or the machine falls into one of the exceptions: a public IP address, a NAT/port-forwarding rule pointing to it, or — a less obvious exception — the machine routes or forwards traffic for others (gateway, VPN server, a host bridging two network segments). Because the backdoor captures everything passing through an interface rather than only packets addressed to itself, a trigger aimed at a completely different machine can still be "seen" by a gateway or VPN server and activate the backdoor.
The DNS channel exists in the binary as a workaround for this reachability constraint — but is not the mechanism in use in the analyzed sample. Once the first command lands, most of what a running task can do reaches outward rather than requiring anything to reach inward — so the operator does not need to maintain that initial network position for subsequent actions.
The deployment inside ERAAgent.exe suggests the intended target is a 64-bit Windows endpoint or server with ESET Management Agent installed — the kind of machine normally sitting behind a firewall and NAT gateway. This makes it notable that the analyzed sample relies entirely on the raw trigger (without activating the DNS fallback), suggesting the operator already had some position on or near the target network rather than working from the open internet with nothing in hand.
9. Host Configuration Changes
To facilitate unauthenticated named-pipe access, the backdoor actively weakens two security settings: it enables EveryoneIncludesAnonymous (causing permissions granted to "Everyone" to apply to anonymous login tokens) and adds its pipe name to NullSessionPipes (allowing the pipe to be reached without credentials). It also creates the pipe with permissions allowing both "Everyone" and "Anonymous Logon" to connect.
A notable implementation flaw: the cleanup mechanism remembers whether it successfully wrote to NullSessionPipes, not whether that entry existed before. This means the "cleanup" may delete a legitimate pre-existing entry, leaving the machine in a different state than it was before infection.
There is no privilege escalation code anywhere in the file. Nothing in it attempts to bypass User Account Control or obtain higher privileges. Modifying the two registry keys above already requires local administrator rights. The backdoor relies entirely on the security context of its host process — it doesn't acquire those rights itself. This is the key fact that defines SLEEPWALKER's nature: it is a post-compromise implant, not an initial access tool. How the operator first reached the machine and wrote the malicious DLL into that protected application directory remains entirely unknown.
10. A Notable Methodological Observation: AI-Assisted Analysis
Reichel dedicated a section of his post to methodology: he performed the initial analysis entirely manually to preserve the hands-on challenge, then used multiple frontier AI models to assist with verification and deeper analysis — testing Claude Opus 5 and GPT-5.6-Sol (also using Opus 4.8 and Sonnet 5 when safety restrictions prevented Opus 5 from continuing). He excluded Claude Fable because its safety filters blocked even general questions with potential dual-use answers.
Results across models were broadly similar, with neither family consistently ahead. One notable difference: when analyzing the distinction between SNIFF_MAGIC_PACKET and SNIFF_MAGIC_PACKET_DNS, Claude described both instructions as "functionally identical" across all 3 attempts — an incorrect conclusion — while GPT correctly identified the key difference (opcode 0x88 also enables the DNS trigger) on its first attempt.
Reichel also noted that GPT's weekly usage allowance was easier to work with than Claude's hourly limit during extended reverse-engineering sessions; none of his GPT runs were interrupted by safety refusals, while he encountered a refusal in every malware-analysis run with Claude Opus or Sonnet — sometimes early, sometimes only after substantial progress — despite enrollment in Anthropic's Cyber Verification Program. He suggests Anthropic should apply stricter admission checks to such programs, in exchange for fewer restrictions for approved researchers conducting legitimate reverse engineering.
His overall assessment: AI is a powerful accelerator for malware analysis — work that previously took hours, days, or weeks can be completed much faster — but it doesn't eliminate the need for technical expertise or careful verification of every result.
What Remains Unknown
This is where Reichel's report is at its most epistemically rigorous, and that spirit is worth preserving:
Sample origin and victim: No collection context ties the file to a confirmed intrusion. No victim, industry, country, or organization can be identified. The
ERAAgent.exerequirement points to a 64-bit Windows endpoint or server with ESET Management Agent installed, but reveals nothing about whether the actual host was a workstation, server, gateway, VPN system, or VMware guest — and doesn't prove the sample was ever successfully deployed.Initial access and delivery: DLL side-loading explains how SLEEPWALKER executes and persists after being placed beside
ERAAgent.exe. It doesn't explain how an operator first entered the environment, obtained the required administrator privileges, or wrote the malicious DLL into that protected application directory. No dropper, installer, exploit, or initial access technique is present in this file.Companion components and operator tooling: The backdoor cannot install itself, and its command language provides no general way to create the files it expects to find. The unresolved
dpapisvc.dlldependency may imply another component places a renamed genuinedpapi.dllalongside it — but no such file accompanied this sample.Commands actually received: The only encrypted task stored in the sample starts the raw-packet listener. The remaining 22 instructions describe capabilities, not observed behavior. Without captured trigger traffic, memory from an infected host, or related local files, there is no way to know what commands were sent, what payloads ran, what data was collected, or whether lateral movement occurred.
Channels actually used: DNS, VMCI, ICMP, named pipes, and other transports are implemented, but their presence doesn't prove they were ever used. DNS support is not enabled in the embedded bootstrap.
Infrastructure and operator position: No hardcoded servers, domains, addresses, or operator identifiers exist. The raw trigger favors an operator with an existing network position, but the code can't reveal whether that came from another compromised host, an insider, a routing system, a public-facing interface, or something else.
Attribution, campaign, and spread: Nothing in the file identifies its developer or operator. Reichel found no related code to support attribution to any known group. A single sample cannot establish when or how widely SLEEPWALKER was deployed, whether variants exist, or whether it belongs to a continuing campaign.
Contextual Comparison: Not an Entirely New Technique — But a New Blind Spot
Magic-packet triggered implants have appeared on Linux — most notably BPFDoor, used by Red Menshen (also tracked as Earth Bluecrow, DecisiveArchitect, Red Dev 18) inside telecommunications networks, as documented by Rapid7 (March 2026). What makes SLEEPWALKER distinct is the combination: a passive implant on Windows, awakened by a single crafted packet, supporting multiple covert transports including the rare VMCI channel, deploying through side-loading into a trusted ESET management component, and packaging its commands in a proprietary bytecode language.
On the ESET ecosystem as a side-loading target: this is not the first time ESET software has been abused for side-loading. The ToddyCat group (China-linked APT, active since at least 2020, targeting government and defense entities across Asia-Pacific) was documented by Kaspersky (April 2025) exploiting CVE-2024-11859 — a real DLL search-order hijacking vulnerability in ESET's command-line scanner (ecls) that caused it to load version.dll from the current directory instead of the system directory — to load a malicious DLL named TCESB (based on the open-source EDRSandBlast tool, capable of disabling kernel notification callbacks and using a BYOVD technique via a vulnerable Dell driver). ESET patched this vulnerability in January 2025.
An important distinction: the TCESB/ToddyCat case exploited a real, CVE-numbered vulnerability in ESET's own code — one that has since been patched. By contrast, per Reichel's analysis, SLEEPWALKER's side-loading into ERAAgent.exe relies on Windows's default DLL search-order behavior, not on a specific flaw in ESET's code — so there is no patch to wait for. When a confirmed SLEEPWALKER match is found, the correct response is incident investigation and machine rebuild, not waiting for a vendor patch.
This pattern shows the ESET management ecosystem continues to attract interest from multiple distinct threat actors for side-loading purposes — a point worth noting for any organization that has deployed ESET Management Agent, since security software is often placed on exclusion lists from other monitoring precisely because it's trusted, making it an attractive side-loading target.
Risk Summary
| Risk Dimension | Level | Rationale |
|---|---|---|
| Network stealth | Very High | No beaconing, no fixed C2; traffic monitoring tools watching for outbound connections to known-bad infrastructure see nothing |
| Technical sophistication | High | Proprietary bytecode language, dual-layer encryption, 6 transport protocols including the rare VMCI channel |
| Confirmed as an active real-world threat | Low / Unknown | Single sample, no confirmed victims, no evidence of deployment — read this finding with appropriate caution |
| Initial access requirement | High | Requires pre-existing local admin rights + ability to get a packet onto the target network; this is a post-compromise implant |
| Lateral movement potential | Medium-High | Named pipe with credential support, combined with active weakening of pipe authentication on the host |
| Persistence longevity | Medium | Side-loading is the only persistence mechanism — reloads each time the ESET Management Agent service starts |
IOCs & Artifacts
File Hashes
SHA-256: d347170752a28e2b8c4b8b9f3cab2e3a6541ba11682c94498d26eb9002779d60
SHA-1: 2ec8aa9661a33bccc002150ce1ed02d90c3986ff
MD5: 2318327b29bb1c0e2d2b5f0211fc7fac
Imphash: 4e2dbfa7e3efd4cca2f3662797df9735
Host-Based Indicators
An anomalous
dpapi.dllsitting besideERAAgent.exe.An anomalous
dpapisvc.dllin the same directory (this name belongs to no real Windows component).The registry value
EveryoneIncludesAnonymousset to1.An anomalous entry in
NullSessionPipes.
Important note: the two registry values above are only meaningful when compared against a known-good baseline — on their own, they are not conclusive proof of SLEEPWALKER.
Additional Technical Details (for sample cross-referencing)
AES-256 key: 0x746531ff378dbb4bb51d2aa2b1d38d905350a959583186baf4c690f5f316b3ae
Config nonce: 0x3a6d357fb9bc51eacc8b8509
Compilation timestamp: 2024-06-10 09:18:27 UTC
Detection Tools Published by the Researcher
Reichel published alongside his post a YARA rule (matching on the static AES-256 key, config nonce, the distinctive magic-packet validation code, and the dpapisvc.dll string) and a read-only PowerShell scanner to sweep at scale — checking for an anomalous dpapi.dll beside ERAAgent.exe, verifying the SHA-256 hash, and reading the two registry values above, returning exit codes (0 = clean, 1 = review needed, 2 = confirmed match). Both tools were verified directly against the analyzed sample before publication. Since the YARA rule partially matches on the static AES key and compiled code, a rebuild with a different compiler configuration could break matching — results should be interpreted with corresponding caution.
The full YARA rule and PowerShell script are not reproduced in this article — readers who need the complete tools should access Reichel's original post directly (see References).
MITRE ATT&CK Mapping
| Tactic | Technique ID | Technique Name | Description in SLEEPWALKER |
|---|---|---|---|
| Persistence | T1574.002 | Hijack Execution Flow: DLL Side-Loading | The only load-and-persist mechanism — side-loaded into ERAAgent.exe |
| Defense Evasion | T1036.005 | Masquerading: Match Legitimate Name or Location | Impersonates dpapi.dll, copies ESET Management Agent version resource |
| Defense Evasion | T1027 | Obfuscated Files or Information | Proprietary bytecode language + two-layer AES-256-CCM encryption; key strings reconstructed from numbers at runtime |
| Defense Evasion | T1140 | Deobfuscate/Decode Files or Information | Temporary XOR decryption of nested programs in CRON_SCHEDULE (decrypt–run–re-encrypt) |
| Defense Evasion | T1556 | Modify Authentication Process | Enables EveryoneIncludesAnonymous, adds pipe to NullSessionPipes for unauthenticated access |
| Command and Control | T1205 | Traffic Signaling | The core magic-packet mechanism — the entire backdoor wakes up only when it receives exactly one matching trigger packet |
| Command and Control | T1071.004 | Application Layer Protocol: DNS | Second trigger channel via DNS queries (implemented, not active in the analyzed sample) |
| Command and Control | T1095 | Non-Application Layer Protocol | ICMP_SEND hides data inside ping packets; raw-packet handling occurs before protocol classification |
| Command and Control | T1132 | Data Encoding | Base32 for DNS labels; proprietary bytecode format for all other channels |
| Command and Control | — | (No standard ID) | VMware VMCI channel — guest-host communication through the virtualization layer, bypassing physical network adapter |
| Lateral Movement | T1021.002 | Remote Services: SMB/Windows Admin Shares | PIPE_SEND/PIPE_CLIENT_RECV support credential-based authentication for lateral movement |
| Command and Control | T1105 | Ingress Tool Transfer | STAGE_WRITE/STAGE_VERIFY_EXEC/DECOMPRESS_RUN — deliver programs in pieces, SHA-256 verified before execution |
| Execution | T1106 | Native API | RUN_SHELLCODE calls VirtualProtect then executes raw machine code directly in memory |
| Defense Evasion | — | (No standard ID) | Host process name check only (no signature or path verification) — incidentally evades debuggers/sandboxes not running under the exact process name |
Expert Assessment
SLEEPWALKER is noteworthy not just for the magic-packet technique — which has precedent via tools like BPFDoor on Linux — but for how it stacks multiple protective layers against each other in a way that is rarely seen: a completely passive implant with no fixed C2 infrastructure, packaging its commands in a proprietary bytecode language rather than any conventional command format, supporting 6 transport protocols including the VMCI channel that until now has appeared almost exclusively in highly resourced APT tooling (UNC3886), and concealing itself inside a trusted security management component. This level of design investment is typically seen in tools built for targeted operations, not commodity-grade widely distributed tooling.
However, the most important point to emphasize to defenders is the gap between "technically impressive capabilities" and "confirmed active threat." This is a single binary sample with no confirmed victim, industry, or campaign behind it. The analyst himself — with commendable methodological honesty — stresses that nearly every aspect of the real deployment context remains unknown. This doesn't diminish the value of preparing detections, but it demands a proportionate organizational response: treat this as a signal to raise threat-hunting readiness and detection preparedness, not as a basis for triggering broad-scale emergency incident response.
Three technical defensive lessons stand out. First, combining encryption with a proprietary command format is a meaningful step beyond backdoors that merely encrypt text-based commands — recovering the key no longer tells you what the attacker intended, significantly lengthening forensic analysis time. Second, the "check only the host process name" design — while simple — is surprisingly effective against automated sandbox and analysis tools that don't emulate the exact ERAAgent.exe process name. Third, the backdoor actively weakening the host OS's own security configuration (EveryoneIncludesAnonymous, NullSessionPipes) for its own purposes — combined with a cleanup logic bug that may delete pre-existing legitimate entries — is a detail easily overlooked in post-incident review without a known-good baseline for comparison.
The ESET ecosystem continuing to attract side-loading attempts (after the TCESB/ToddyCat precedent) is a broader signal worth noting: security software is often placed on monitoring exclusion lists precisely because it's trusted — which makes it an attractive side-loading target for exactly that reason. This is a reminder that security tooling, if left unmonitored by other controls, creates a trust blind spot an attacker can exploit through the ordinary Windows DLL search order, without needing to touch the vendor's code at all.
Recommendations
Threat Hunting and Detection
Immediately audit host-based indicators on every machine running ESET Management Agent: look for an anomalous
dpapi.dllbesideERAAgent.exe, verify the SHA-256/MD5 hash against the published values, look fordpapisvc.dll(a name that belongs to no real Windows component).Compare the two registry values against a known-good baseline —
EveryoneIncludesAnonymousandNullSessionPipes— because on their own, without a baseline, these values are not conclusive proof of infection.Deploy the YARA rule and read-only PowerShell scanner published by Reichel (see References) to sweep across the organizational estate before deciding on a response path.
Note the YARA rule's limitation: part of the rule matches on the static AES key and compiled code — a rebuild with a different compiler could break the match, so a "no match" result should not be treated as absolute proof of absence.
Network Monitoring
Do not rely on traditional C2 connection monitoring to detect SLEEPWALKER — because it never beacons out, tools watching for unusual outbound traffic or known-bad infrastructure connections will see nothing.
Consider monitoring for unexpected promiscuous-mode activation on endpoints with no legitimate business reason for it (not a recognized network analysis tool).
Pay particular attention to machines acting as gateways, VPN servers, or bridging two network segments — these are positions that could "inadvertently" see and activate a trigger aimed at another machine.
For VMware virtualization environments: recognize that VMCI traffic does not appear in conventional packet captures — dedicated hypervisor-level monitoring is needed if VMCI-based C2 is suspected.
