Key Takeaways
Background
SLEEPWALKER represents a notable approach to post-compromise persistence and command execution because its passive architecture significantly reduces network indicators commonly associated with backdoors. The analyzed sample contains no hard-coded C2 domains, IP addresses, URLs, or embedded second-stage payload. Its initial configuration instructs the malware only to monitor network interfaces indefinitely for a matching encrypted trigger packet.
Researcher Dominik Reichel, who discovered the malware, assesses that SLEEPWALKER is consistent with a targeted, well-resourced operation rather than opportunistic activity. The combination of passive activation, DLL side-loading into a trusted management component, a custom bytecode interpreter, multiple communications mechanisms, and support for VMware VMCI suggests deliberate engineering intended to provide operators with flexible post-compromise access while limiting conventional network exposure.
However, no threat actor, campaign, victim, or intrusion chain has been identified. The analyzed sample also does not establish which of SLEEPWALKER's post-compromise capabilities were actually used. The only encrypted task stored within the sample activates the raw-packet listener. DNS triggering, VMCI communications, ICMP, named pipes, lateral movement, staged payload delivery, and other functionality represent implemented capabilities rather than confirmed operator behavior.
Technical Analysis
SLEEPWALKER is an unsigned 64-bit Windows DLL masquerading as Microsoft dpapi.dll. The analyzed sample is 59,904 bytes and contains version information copied from the legitimate ESET Management Agent, including ESET company and product information and version 11.2.2076.0. The malware is designed to execute through DLL side-loading into ERAAgent.exe.
Before initialization, SLEEPWALKER checks whether its host process is named ERAAgent.exe. The malware validates only the process name rather than its path or digital signature. Two separate execution paths can initiate the same startup routine: loading through DllMain and the first invocation of any of seven forwarded DPAPI exports. Both paths check the host process name before launching a background thread, reserving a 128 KB buffer, decrypting the bootstrap instruction, and starting the bytecode interpreter.
The embedded configuration contains only a five-byte SNIFF_MAGIC_PACKET instruction directing SLEEPWALKER to monitor every available network interface indefinitely. All additional behavior must be supplied later through attacker-delivered tasking.
Passive Network Activation
Unlike conventional backdoors that establish outbound communications after execution, SLEEPWALKER does not autonomously contact attacker-controlled infrastructure. The sample contains no embedded domains, IP addresses, or URLs. Instead, it places network interfaces into promiscuous mode and examines observed packets for a specific trigger structure. Packets satisfying the malware's framing and validation requirements are decrypted and passed to its custom bytecode interpreter.
Tasking is protected using AES-256-CCM, providing both encryption and authentication. The raw trigger additionally uses CRC-32 validation, allowing SLEEPWALKER to reject packets that do not match the expected structure before attempting decryption. The analyzed DLL contains the AES-256 key used by the implant, which Reichel recovered during reverse engineering. This architecture allows the implant to remain dormant without producing its own malicious beaconing traffic. Legitimate ERAAgent.exe network activity may continue independently while SLEEPWALKER waits for tasking, further complicating network-centric identification of a dormant infection.
Custom Command Language
Once tasking is decrypted, SLEEPWALKER does not receive conventional human-readable commands. Instead, the resulting data consists of a proprietary bytecode format interpreted by the malware. Each instruction begins with a single-byte opcode followed by parameters determined by the selected operation.
SLEEPWALKER implements 23 instructions supporting:
The proprietary command language creates an additional analytical layer beyond encryption. Recovering the AES key can expose the bytecode, but the resulting instruction stream must still be parsed according to SLEEPWALKER's custom format before individual commands and parameters can be understood. Task programs delivered through raw triggers, TCP, UDP, named pipes, or VMCI use AES-256-CCM. DNS-carried tasking uses Base32 over AES-256-CCM to make the encrypted envelope compatible with DNS labels. Nested programs used for scheduled execution are additionally XOR-obfuscated while retained in memory. However, data transmitted by several outbound instructions is not automatically encrypted. Instead, the malware sends the data supplied by the operator.
Alternative Communications
Five SLEEPWALKER networking instructions can use VMware VMCI when supplied with an address beginning with “vm:”. VMCI allows communications between VMware guests or between a guest and host through the virtualization layer rather than a conventional network adapter. As a result, these communications would not appear in ordinary network packet captures between systems.
SLEEPWALKER also implements a DNS-based trigger capable of carrying encrypted tasking within DNS queries. However, this functionality is not enabled by the analyzed sample's embedded bootstrap. The deployed configuration activates only the raw-packet listener. DNS triggering would require a different embedded configuration or subsequent tasking that activates the DNS-aware listener.
Where enabled, the DNS mechanism could provide an alternative path through environments where direct inbound traffic cannot reach the monitored interface but DNS communications remain permitted. The implementation can also observe qualifying DNS queries leaving the compromised host, potentially allowing a trigger to reach SLEEPWALKER through outbound DNS activity.
Network Positioning and Post-Compromise Reach
The raw-packet trigger creates an important operational constraint. The trigger must reach an interface monitored by SLEEPWALKER, favoring an operator that already possesses some mechanism for placing traffic onto or through the victim network. The sample does not establish how such access would be obtained. Possibilities include another compromised system, routed access, an insider position, a public-facing interface, or another delivery path.
Once SLEEPWALKER receives tasking, several supported transports no longer require the same inbound reachability. TCP, UDP, and ICMP instructions can cause the infected system to initiate outbound communications to operator-supplied destinations. Named pipes additionally provide a mechanism for communications across Windows networks, while VMCI provides a specialized channel for systems sharing VMware infrastructure.
Host Security Changes
SLEEPWALKER can modify Windows security configuration to facilitate unauthenticated named-pipe access. The malware sets EveryoneIncludesAnonymous, adds its pipe name to NullSessionPipes, and creates named pipes with permissions allowing Everyone and Anonymous Logon to connect. Together, these changes can permit unauthenticated access to the malware's named-pipe channel when surrounding network controls allow the connection. These modifications provide useful behavioral hunting opportunities but should be evaluated alongside system baselines and additional evidence rather than treated independently as proof of SLEEPWALKER infection.
Analyst Commentary
SLEEPWALKER demonstrates how passive C2 architectures can undermine detection strategies that depend heavily on identifying recurring beaconing, known malicious infrastructure, or immediately suspicious outbound connections. A successfully deployed SLEEPWALKER implant can remain dormant while waiting for attacker-generated traffic, potentially leaving defenders without the repetitive network patterns commonly associated with persistent remote-access malware.
Its custom bytecode architecture adds another complication. Encryption protects tasking in transit, but decryption alone does not reveal conventional commands. Analysts must additionally understand the implant's proprietary instruction format to reconstruct operator tasking. Combined with support for multiple transports, staged payloads, in-memory execution, and VMCI communications, the design provides operators with substantial flexibility after the initial trigger is delivered.
At the same time, SLEEPWALKER illustrates why defenders should avoid equating malware capability with observed adversary behavior. The analyzed sample proves that the implant can support DNS triggering, VMCI, named pipes, lateral movement, scheduling, staged payload delivery, and shellcode execution, but it does not demonstrate that an operator used those features in an actual intrusion. The absence of identified infrastructure, victimology, delivery information, or related samples further limits conclusions about the malware's operational history or attribution.
The absence of fixed C2 infrastructure also reinforces the value of artifact-centric and behavior-centric detection rather than reliance on conventional network blocklists alone. Defenders should investigate unexpected or unsigned dpapi.dll files located alongside ERAAgent.exe, particularly when accompanied by anomalous anonymous SMB configuration, suspicious named-pipe activity, or other SLEEPWALKER-associated indicators. Behavioral detections capable of identifying suspicious activity within otherwise trusted processes may provide additional visibility when static infrastructure indicators are unavailable.
This is also where PolySwarm's multi-engine detection model provides an important defensive advantage. Novel malware does not arrive with the benefit of mature signatures, established infrastructure blocklists, or years of accumulated threat intelligence. SLEEPWALKER's limited public exposure and passive design illustrate precisely the type of threat for which relying on a single detection engine or traditional C2-focused controls can create blind spots. PolySwarm enables defenders to evaluate suspicious artifacts across a diverse marketplace of commercial and specialized detection engines, increasing opportunities for emerging or independently developed detections to surface threats that individual products may miss.
The discovery of SLEEPWALKER by an independent researcher further highlights the importance of a security ecosystem that can rapidly incorporate expertise beyond any single vendor or research organization. PolySwarm is designed around that principle: bringing independent security expertise, specialized malware detection, and established anti-malware technologies into a common environment where competing detection approaches can collectively improve visibility. For previously unknown or low-prevalence malware such as SLEEPWALKER, that diversity can be particularly valuable because defenders are not forced to depend on one vendor being the first to recognize the threat.
IOCs
PolySwarm has a sample of SLEEPWALKER.
d347170752a28e2b8c4b8b9f3cab2e3a6541ba11682c94498d26eb9002779d60
Click here to view all samples of SLEEPWALKER in our PolySwarm portal.
Don’t have a PolySwarm account? Go here to sign up for a free Community plan or subscribe.
Contact us at hivemind@polyswarm.io | Check out our blog | Subscribe to our reports.