A new backdoor does nothing at all until one crafted packet arrives

An analysis published on 24 August 2026 describes a previously unreported Windows backdoor called Sleepwalker. The file is an unsigned 64-bit DLL of 59,904 bytes that poses as Microsoft's dpapi.dll and is built to be side-loaded into ERAAgent.exe, the executable of the ESET Management Agent. It contacts no fixed server and opens no obvious listening port on its own. Instead it reads every packet crossing the network card and waits for one specific encrypted packet before doing anything at all. The analysis states that no earlier public reporting of the backdoor was found, and that detection coverage for the file was still low at the time of publication.

What happens technically

DLL side-loading rests on a well known property of Windows. A program that asks for a library by name finds a file in its own folder before the operating system looks in the system directory. Sleepwalker is built for exactly that order. It carries a version resource copied from ESET's real agent, with the company name ESET and the file description ESET Management Agent Module, and it exports the same seven functions as the genuine dpapi.dll. The compilation timestamp in the file is 10 June 2024, while the analysis was first published in August 2026. The only thing the backdoor checks is the name of the process that loaded it. Neither the signature nor the path is examined. If the process is called anything other than ERAAgent.exe, the code stays inactive, so it will not wake up in a sandbox or under a debugger either. The seven exported functions are empty stubs that try to fetch the real function from a file called dpapisvc.dll. No such file ships with Windows, and the analysis notes that a failed attempt terminates the whole host process rather than only that one call. Side-loading is also the only persistence the backdoor has. As long as the file sits beside ERAAgent.exe, it is loaded again every time the ESET service starts.

The configuration built into the file is 2,048 bytes and is encrypted with AES-256-CCM. Decrypted, it holds a single five-byte instruction: watch every network interface, with no time limit, for one particular packet. The backdoor reads raw traffic from at most eight interfaces at a time, and it skips the loopback interface and the addresses a machine assigns to itself when it cannot reach a network. Every packet is measured against a pattern in several steps. It must be at least 48 bytes. Two 16-bit values at the end of the packet are combined into a candidate length, and that length must fall inside a valid range. The bytes at the position the length points to must match the sum of those same two trailing values, and the block they point to must pass a CRC-32 check. Only then does the backdoor try to decrypt the contents. If any step fails, the packet is dropped with no response. The check runs on the raw contents before Windows has decided whether the packet is TCP, UDP or something else, so the trigger can travel inside almost any IP traffic. A second trigger channel, carrying the signal encoded inside ordinary DNS lookups, is implemented in the file. The analysis is explicit that it is not switched on in the sample examined: the embedded instruction selects the raw listener alone, and the DNS variant uses its own opcode.

What the packet carries is not a readable command. It is a short program written in a command language that exists nowhere but inside this file, with 23 instructions covering scheduling, several ways of moving data, staged file delivery verified with SHA-256 and execution of code directly in memory. Recovering the encryption key is not enough. The key shows how the bytes are to be read, while only reverse engineering the language itself shows what they mean, the analysis says. The instructions can choose between six transports: TCP, UDP, ICMP with data hidden inside ping requests, SMB named pipes, VMware's internal VMCI channel between a guest and its host, and raw packet capture. None of them has an address built in. The target is supplied by the program that arrives from outside. To let unauthenticated connections reach its pipes, the backdoor changes two Windows security settings, EveryoneIncludesAnonymous and NullSessionPipes. The analysis points out that the cleanup afterwards is unreliable, because the code records whether the entry was added rather than whether it already existed, so cleanup can remove an entry the machine had all along. The file contains no code for gaining higher privileges. The changes require local administrator rights, which the backdoor inherits from its host process.

What this means for you if you run the ESET agent

If you operate ESET PROTECT, ERAAgent.exe sits on a large number of machines across your estate, and that reach is exactly what makes side-loading into the agent attractive. Our assessment is that the lesson here is not one file name, but the kind of detection that fails. If your monitoring rests on outbound traffic to known malicious addresses, you see nothing. The analysis says so directly: the absence of outbound connections to known bad infrastructure does not rule out an infection, and a machine can be fully compromised while giving network monitoring nothing to flag. Note as well that the genuine ESET agent keeps checking in with ESET PROTECT as usual while the backdoor lies still. The traffic from the machine therefore looks right the whole time.

If you do find this file, the find itself is only the beginning. The backdoor cannot install itself, and the changes it makes require local administrator rights that it inherits from its host process. Someone already had access to a protected application directory on your machine before the file got there. At the same time, there is a great deal the analysis cannot say. It rests on a single file, without incident records and without network captures, and it names no victim, no actor and no delivery method. The 23 instructions describe what the backdoor is able to do, not what anyone actually did with it. For you that means a hit is the start of an incident response of unknown scope. Note also that two of the indicators are registry values that only mean something when compared against a known good baseline. The analysis itself states that they are not proof on their own.

Berigo recommends

• Run the read-only PowerShell scanner and the YARA rule from the analysis against every machine with the ESET Management Agent installed. Both are published in the article, and the scanner writes nothing to the system.
• Look for a dpapi.dll or a dpapisvc.dll sitting in the same folder as ERAAgent.exe. No genuine Windows component is called dpapisvc.dll.
• Compare EveryoneIncludesAnonymous and NullSessionPipes against a known good baseline before you draw any conclusion. If you have no such baseline, build one first.
• Check whether your detection sees anything beyond outbound traffic to known addresses. Log which processes load which libraries, and watch for machines that put the network card into promiscuous mode.
• Treat a hit as an incident of unknown scope, and rehearse that procedure before you need it.