A new Windows backdoor dubbed SLEEPWALKER backdoor has been documented by an independent malware researcher. The striking detail is its behavior: the component does not become active just by landing on a system. Instead, it waits in a dormant state in memory until it receives a specially crafted network packet, at which point it starts executing instructions.
Because the payload only wakes up when the right trigger arrives—and it does not initiate outbound connections on its own—infected machines may appear “normal” to some monitoring tools. The researcher’s write-up also notes that the sample’s exact origin and whether it was actually deployed remains unclear.
What makes the SLEEPWALKER backdoor different
The backdoor is implemented as an unsigned 64-bit Windows DLL with a size of 59,904 bytes. The DLL is designed to be side-loaded into a legitimate executable: ERAAgent.exe, which is the Windows component for ESET Management Agent.
Once loaded, SLEEPWALKER impersonates the system’s dpapi.dll by exporting the same seven data protection functions as the genuine library. It also carries a version resource copied from ESET Management Agent, helping it blend into a context that may already be trusted.
Importantly, the file contains no embedded domains, IP addresses, or URLs, and the backdoor does not establish outbound connections by itself. That design choice can make threat hunting harder when it relies heavily on known-bad infrastructure or external callbacks.
Execution model: custom bytecode after a crafted packet
Rather than storing commands in readable form, the SLEEPWALKER backdoor receives and runs them as bytecode. According to the analysis, decrypting a key embedded in the configuration leads to opcodes in a 23-instruction language created specifically for this sample.
The configuration decrypts using AES-256-CCM into a single instruction that tells the backdoor to monitor every network interface indefinitely for the trigger packet. When that packet arrives, the backdoor’s internal logic becomes active and begins processing its command set.
This is consistent with a targeted and well-resourced operation rather than a “spray and pray” malware drop, the researcher said, even though attribution to a specific actor was not possible from the single sample alone.
Network capture behavior and cross-machine visibility
The trigger mechanism is implemented as a listener that captures traffic crossing each watched interface. Notably, the capture includes traffic addressed to other machines as well, which means an operator can potentially observe communications that were never intended for the compromised host.
The write-up highlights scenarios where a gateway, VPN server, or network bridging two segments could inadvertently receive or relay a trigger meant for a different machine. In such cases, traffic visibility may expand beyond the originally compromised endpoint.
Trigger checks: host process name only
SLEEPWALKER’s activation logic checks only the host process name, not whether that process is signed or where it was launched from. That matters for defenders because it shifts the focus away from signature verification and toward ensuring the environment matches a known-good baseline.
To place the malicious DLL into the required directory for side-loading, the operator must already have local administrator rights. The backdoor itself does not need to obtain those privileges. Instead, it relies on the security context of the legitimate process it is piggybacking on.
That design makes SLEEPWALKER a post-compromise implant rather than an initial access method. The analysis also states that the method used to reach the machine and write the DLL remains unknown.
Persistence via Windows DLL side-loading
Persistence in this case is not achieved through scheduled tasks or typical registry run keys. The DLL loads again each time the ESET Management Agent service starts, because the side-loading is tied to Windows DLL search order.
As described in the write-up, this is not a flaw defenders can simply “patch” inside ESET’s software. The DLL search order behavior is leveraged as a technique. The recommended response after confirmation is therefore incident response and rebuilding, rather than applying a targeted vendor fix.
The researcher also notes that ESET products have been abused for side-loading in the past. One cited example involved ToddyCat, which Kaspersky reported used a search-order weakness in an ESET command-line scanner to load a malicious DLL.
Embedded transports and stealth considerations
The 23-instruction language supports scheduling, moving data in multiple stages, delivering files verified against a SHA-256 hash before execution, and running code directly in memory.
The instructions can travel over six different transports: TCP, UDP, ICMP, SMB named pipes (including credentialed lateral movement), raw promiscuous capture, and VMware’s Virtual Machine Communication Interface (VMCI).
VMCI traffic passes through the virtualization layer rather than a standard network adapter. As a result, capturing traffic between two machines with typical packet capture tooling may miss it entirely.
DNS-based trigger and “watcher” instructions
Two instructions in the language relate to trigger behavior. In the analyzed sample, one opcode enables the raw-packet listener. Another opcode also implements a DNS-based trigger inside the binary, though it is not active in this build.
The design suggests flexibility: even if defenders focus on one trigger path, additional trigger variants could appear in other builds.
Registry changes: enabling anonymous access to named pipes
To allow unauthenticated callers to reach its named-pipe channel, SLEEPWALKER modifies registry settings. Specifically, it sets the EveryoneIncludesAnonymous value and adds a pipe name to NullSessionPipes.
The cleanup routine records whether its own write to NullSessionPipes succeeded, rather than checking whether the targeted entry already existed. That behavior can lead to a cleanup operation that removes a legitimate entry that predates the infection.
From a defense perspective, that means baseline comparisons matter. These registry indicators are described as meaningful primarily when compared against known-good values for the specific environment.
Host indicators and how to look for SLEEPWALKER
The researcher published host indicators intended for detection and triage. The most concrete file and hash-based items include:
- An unexpected dpapi.dll beside ERAAgent.exe
- An unexpected dpapisvc.dll in the same directory
- SHA-256: d347170752a28e2d2b5f0211fc7cab2e3a6541ba11682c94498d26eb9002779d60
- MD5: 2318327b29bb1c0e2d2b5f0211fc7fac
- EveryoneIncludesAnonymous set to 1
- An unexpected entry in NullSessionPipes
Alongside the write-up, the researcher shared a YARA rule and a read-only PowerShell scanner to check those indicators across an estate. The publication notes that coverage for the file was low at the time of sharing, and the rule partly relies on a static AES key and compiled protocol code—meaning a rebuild with different compiler settings could reduce detection reliability.
How defenders should respond if SLEEPWALKER is confirmed
If the SLEEPWALKER backdoor is suspected or confirmed, the response described in the analysis is straightforward: treat it as a post-compromise implant. Focus on incident response actions and rebuilding rather than trying to patch the behavior away.
Because the backdoor depends on side-loading, remediation typically involves removing the malicious DLLs, restoring a known-good directory structure, and validating service behavior. Additionally, investigate how the operator gained the local administrator rights needed to place the DLL on disk—since that initial compromise vector remains unknown.
Finally, ensure that your detection strategy includes host-based baselines. Registry keys like EveryoneIncludesAnonymous and NullSessionPipes can look different across environments, so comparisons against a trustworthy baseline are essential.
Reporting, attribution gaps, and what’s next
The analysis package is based on a single binary supplied without additional collection context. As a result, the researcher could not attribute it to a known actor, establish a victim, identify an industry, or determine a country of targeting. The write-up also notes that it was not possible to confirm whether the sample had ever been deployed.
The researcher contacted the relevant vendor for comment on telemetry. As of August 26, no public advisory or statement had been issued, and the article indicates that updates would be added if telemetry information was provided.
Even with these gaps, the described behavior—memory dormancy until a crafted packet, custom bytecode execution, and traffic monitoring that can expose more than the local host—offers clear lessons for defenders.
Conclusion
The SLEEPWALKER backdoor is a stealth-focused Windows implant that stays inactive until it receives a precisely crafted network trigger. By side-loading a spoofed dpapi.dll into ERAAgent.exe and executing commands in a custom bytecode language, it reduces visible signs for many tools and complicates straightforward “known bad” detection.
For security teams, the most actionable path is to hunt using the provided file and registry indicators, compare registry values against known-good baselines, and treat confirmed findings as post-compromise activity requiring incident response and rebuilds.
Source: https://thehackernews.com/2026/08/newly-sleepwalker-backdoor-waits-for.html
