SLEEPWALKER: A Passive Backdoor With Its Own Command Language

Losing access to VirusTotal Intelligence at the start of the year was surprisingly productive. Unable to hunt for interesting new malware, I stopped adding to my “TODO” pile and finally worked through my backlog from last year. That led to a detailed examination of BeheMOF as well as the discovery of this malware. Upon closer inspection, a sample that did not seem too noteworthy at first turned out to have a distinctive design once I looked under the hood: a passive backdoor that opens no obvious listening port and carries no payload inside itself. It waits in memory doing nothing at all until one specifically crafted network packet reaches the machine, which is why I am calling it SLEEPWALKER. What makes it worth writing up is what that packet carries: not a readable command, but a short program written in a command language of the backdoor’s own design. Its 23 instructions cover scheduling, several ways to move data, staged file delivery and running code directly in memory. Recovering the encryption key is not enough to understand one of these programs. The internal command language must be reverse engineered as well. From a reverse-engineering perspective, SLEEPWALKER has a cool design. Still, the implementation has several weaknesses and is not top-notch malware engineering. This could be an early version, however. Newer and improved builds may exist. This post covers what the file itself reveals, how SLEEPWALKER gets loaded, how it starts up, how it stays hidden on the network, how its commands are protected and how its internal command language works. That last part explains most of what the backdoor is actually capable of doing, so I spend some time on it. It closes with an IOC section and an appendix containing a YARA rule and a read-only scanner script. Executive summary SLEEPWALKER is a passive backdoor with a command language of its own. It never contacts a fixed C2 address. Instead, it sniffs the network for a covert trigger packet. Only then does it wake up to decrypt and run an attacker-supplied task program. The program arrives as bytecode that only this file knows how to interpret, not as readable commands. The file carrying it is a 64-bit Windows DLL that impersonates Microsoft’s dpapi.dll and has a forged ESET Management Agent version resource. It is designed to be side-loaded into ERAAgent.exe, the Windows executable for ESET Management Agent.

SLEEPWALKER checks only the host process name, not its signature or path, and stays inactive unless that name is ERAAgent.exe. The whole lifecycle of the backdoor: Figure 1: The path from side-loading to execution: nothing runs until one matching packet arrives. The configuration built into the file decrypts, with AES-256-CCM and a verified authentication tag, to a single bootstrap command: watch every network interface indefinitely for that trigger. On its own, the file does nothing except wait. The backdoor carries a compact bytecode interpreter with 23 instructions covering scheduling, staged payload delivery with SHA-256 verification and in-memory shellcode execution. Its network capabilities include TCP, UDP, ICMP, SMB named pipes with lateral movement using supplied credentials, VMware’s internal VMCI channel between a guest and its host and raw-socket promiscuous sniffing. A second trigger channel can also carry commands in DNS queries. To facilitate unauthenticated named-pipe access, SLEEPWALKER actively weakens the host: it enables anonymous SMB access and creates named pipes with permissions granted to Everyone and Anonymous Logon. All encryption is provided by a statically linked copy of mbedTLS, an open-source cryptography library, rather than anything loaded at runtime. This combination is what makes SLEEPWALKER hard to catch from the network side: there is nothing to block until the operator sends that one crafted packet, and it can arrive inside traffic that looks completely ordinary, including a crafted DNS query. A passive implant triggered this way, using multiple covert transports including VMCI and deployed through side-loading into a trusted ESET management component, is most likely part of a targeted attack that also includes other unidentified components.

It does not contact any server on its own. It waits for one specific encrypted network packet before doing anything. Once triggered, it runs programs written in a small custom command language, supporting scheduling, several network methods, staged file delivery and running code directly in memory. The file itself contains no ready-made malicious payload. Everything beyond the single starting instruction has to arrive later, over the network. It changes local Windows settings so that unauthenticated network connections can reach it.