↓ Skip to main content
Juan Carlos Munera
  1. Posts/

SLEEPWALKER: Detection Notes on a Backdoor That Never Calls Home

·1192 words·6 mins
Detection Engineering SLEEPWALKER DLL Side-Loading Passive Backdoor Windows Internals Configuration Baseline Threat Hunting
Table of Contents

A Windows backdoor disclosed in late August, tracked as SLEEPWALKER, is worth reading closely for what it does not do rather than for its capability list.

It carries no command-and-control domain, no IP address, and no URL. It does not beacon. It does not open a listening port. On a compromised host it sits inside a trusted process doing nothing at all until one specifically crafted packet crosses a network interface it happens to be watching. Until that moment, the machine produces nothing for a network monitor to flag.

That is the part worth sitting with. Most of the detection stack in a mature environment assumes malware eventually talks.

What the sample is
#

The analyzed file is an unsigned 64-bit DLL of 59,904 bytes with a June 2024 compile timestamp. It names itself dpapi.dll and exports the same seven Data Protection API functions as the genuine Microsoft library. Its version resource is copied wholesale from ESET Management Agent, down to the company name, product version, and copyright string.

It is built to be side-loaded into ERAAgent.exe. The load check is a process name comparison and nothing more. Not the signature, not the path. If the host process is not named ERAAgent.exe, the DLL stays inert, which also means it will not run in a sandbox or a debugger unless that process carries the exact name.

The seven exported stubs try to forward to dpapisvc.dll. No such component ships with Windows. The closest real filename is dpapisrv.dll, an unrelated LSA extension library exporting two functions. That unresolved dependency suggests a companion component that did not accompany the sample.

Once it starts, the DLL decrypts a configuration containing exactly one instruction: watch every network interface, with no time limit, for the trigger. Everything else, including scheduling, staged payload delivery with SHA-256 verification, decompression, and in-memory shellcode execution, arrives later as encrypted bytecode written in a 23-instruction language of the backdoor’s own design.

This is not a vulnerability in ESET’s software and there is nothing to patch. Side-loading here relies on the standard Windows DLL search order, and writing a file into a protected application directory already requires local administrator rights the operator had to obtain some other way. SLEEPWALKER is a post-compromise implant, not an entry point.

The assumptions this breaks
#

Malware eventually talks. Egress filtering, DNS reputation, domain categorization, TLS fingerprinting, beacon interval and jitter analysis: none of it fires. The only network moment is the inbound trigger, and that trigger is validated through a length check, an XOR-derived candidate length, a CRC-32 check, and authenticated decryption before it is treated as a command. A packet failing any step is dropped silently with no response, so there is nothing to probe or fingerprint from the outside either.

East-west traffic is visible. Five of the networking instructions accept a vm: prefix and switch to VMware’s VMCI channel instead of a normal address. Guest-to-host and guest-to-guest communication through the virtualization layer does not cross a virtual switch port in a way a SPAN or tap will see. A packet capture between machines contains none of it. There is also a second trigger channel that encodes commands inside DNS labels, implemented in the binary but not enabled in this particular build.

Unsigned code gets caught. User-mode DLL loading has never required a valid signature. The vendor metadata in this file is a copied version resource, not an Authenticode signature. A properties dialog showing a familiar security vendor’s name proves nothing at all about provenance, which is the entire point of the masquerade.

Hashes are the answer. The published SHA-256 covers one build. The analyst who released it noted detection coverage was low at publication and that later or modified builds may exist. Hash matching is worth running, but it is the least durable thing on the indicator list.

Where the durable detection lives
#

Two of the five published indicators are not files at all. They are registry values:

  • EveryoneIncludesAnonymous set to 1 under the LSA key
  • An unexpected entry in NullSessionPipes under LanmanServer parameters

The backdoor sets both so unauthenticated callers can reach its named pipe channel, and it also creates pipes with DACLs granting Everyone and Anonymous Logon.

Both values are standard hardening baseline items. Any organization that actually enforces and continuously monitors a configuration baseline gets a meaningful piece of this detection nearly for free. Any organization that applied a baseline once at build time and never looked again does not. This is significant because it draws a clean line between having a control documented and operating one, which is exactly where control testing tends to fall apart under scrutiny.

One detail from the analysis is easy to miss and matters during recovery. The cleanup routine records whether it succeeded in adding the NullSessionPipes entry, not whether an entry already existed. It can therefore remove a legitimate pre-existing entry on its way out. After an incident, the configuration can be wrong in a direction that does not look like attacker activity. Validate against a known-good baseline rather than assuming a clean-looking value is untouched.

Practical checks
#

Worth running across a fleet, in rough order of signal quality:

  • Inventory every dpapi.dll outside System32 and SysWOW64. A file with that name sitting in an application directory is anomalous on its own, regardless of hash.
  • Search for dpapisvc.dll anywhere on disk. No genuine Windows component uses that name.
  • Hunt on structure rather than filename: unsigned modules loaded by signed service binaries, particularly management and security agents running with elevated rights.
  • Diff EveryoneIncludesAnonymous and NullSessionPipes against a baseline rather than checking presence or absence. A nonempty pipe list is not proof of anything by itself.
  • Alert on raw socket creation with SIO_RCVALL or promiscuous mode enabled by processes that have no legitimate packet capture role.
  • Audit writes to EDR and management agent installation directories. Those paths should be effectively static between vendor updates, which makes write events there high-signal and low-volume.
A confirmed match means the host is compromised and should be rebuilt. The file cannot tell you which commands it already received, which payloads ran, or whether lateral movement occurred, because none of that is stored in the binary. Absence of outbound traffic is not evidence of absence of compromise on a host running this implant.

What to take from it
#

Passive, packet-triggered implants are not new. What separates this one is the second barrier behind the encryption. Recovering the AES key does not produce a readable command or a config block. It produces opcodes in a format that exists nowhere except inside that file, so the command language has to be reverse engineered before anyone can say what a captured task actually did.

For anyone building detections, the practical adjustment is a weighting change. Network telemetry answers less than usual against a design like this, and host integrity, module signature state, and configuration drift answer more. Those are unglamorous controls that tend to get deprioritized precisely because they generate no interesting alerts most of the time. This is a reasonable argument for funding them anyway.

Source
#

The original technical analysis, including a YARA rule and a read-only PowerShell scanner: r136a1.dev

Juan Carlos Munera
Author
Juan Carlos Munera
Passionate about cybersecurity, governance, risk, and compliance. Sharing insights on security best practices, frameworks, and industry trends.

Related