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 ofBeheMOFas 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.
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’sdpapi.dlland has a forged ESET Management Agent version resource. It is designed to be side-loaded intoERAAgent.exe, the Windows executable forESET Management Agent. ESET describes the agent as an essential component of ESET PROTECT and ESET PROTECT On-Prem that connects managed endpoints and servers to the management platform and stores and enforces policies locally. SLEEPWALKER checks only the host process name, not its signature or path, and stays inactive unless that name isERAAgent.exe.
The whole lifecycle of the backdoor:
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 internalVMCI channelbetween 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 ofmbedTLS, 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. Since the code is unfamiliar to anything I’ve seen in the past, I cannot attribute this malware to any particular actor.
The sample is an unsigned 64-bit DLL for the Windows GUI subsystem. It is 59,904 bytes and has a compilation timestamp of 2024-06-10 09:18:27 UTC:
To make the disguise, the file carries a version resource copied from ESET’s real Management Agent:
That name does not belong to any genuine Windows component. No file calleddpapisvc.dllships with Windows. The closest real name isdpapisrv.dll, an unrelated file that exports only two LSA extension functions, nothing like the seven this code is looking for. A plain reference todpapi.dllitself would not have worked either, since the malicious file already occupies that name inside the host process, and a bareLoadLibraryWcall for it would just return a handle to itself rather than reaching the real one. Some other name or path was needed, but the one actually used matches nothing on a real system. When the load fails, the resolver exits the entire host process rather than failing that one call on its own. Whether this ever happens in practice depends on whether anything actually calls one of these seven specific functions, which this file alone cannot show. It is possible a fuller version of this attack drops a renamed copy of the realdpapi.dllunder this same name alongside it, since a file in the application’s own folder would be found before Windows ever checks System32, the same search order this backdoor already relies on to get loaded in the first place. This file carries no such copy inside itself, though, and nothing here confirms one exists.
That same first call also quietly re-runs the backdoor’s own startup check, giving it a second chance to wake up if something interfered with the first one. The section on initialization below covers startup in full.