SLEEPWALKER Backdoor Hides in a Security Agent and Wakes Up for One Packet

5 bytes of orders sit inside a backdoor that has never once called home. It reads what crosses your network cable and waits. The security agent it hides in loads it again at each restart.

Dominik Reichel, who used to hunt malware at Palo Alto Unit 42, published the analysis on August 24. He named it SLEEPWALKER, because that is what it does. It sits in memory and does nothing at all until one specific packet crosses the network cable, and then it wakes up and runs whatever the sender told it to run.

The backdoors you have read about work the other way around. One lands on a machine, and within minutes it reaches out to a server somewhere to ask for orders. That outbound connection is the thing security tools are built to catch. Block the domain, flag the IP address, watch for a machine talking to an address it has no business talking to. That is how this kind of thing usually gets found.

This one is empty where that infrastructure would be. The file holds not a single domain, address or URL, and it opens no connection of its own. A blocklist has nothing to block, and a network monitor sees nothing worth flagging. A fully compromised machine sits on your network producing not one suspicious connection.

All of this fits in a single file of 59,904 bytes. A Windows program does not carry all its code in one piece. It loads smaller code files and runs them as part of itself, and Windows leans on that arrangement everywhere. Put a file with the right name in a folder the program searches before it reaches the system folders, and the program can end up loading yours instead of the genuine one. Whether that works depends on how carefully the program looks, and that is the exact point the vendor argues about further down. That file type is called a DLL.

This one wears the name dpapi.dll, which belongs to a genuine Microsoft file that handles protected data. It lists the same seven functions the genuine file lists, so anything checking that list sees what it expects to see. Open its properties and it says ESET: company name, product name, file version 11.2.2076.0, copyright 1992-2024, the lot copied from the genuine management agent. The file lies about who made it, and Windows has no reason to argue.

Before it does anything, it looks at the name of the program that just loaded it. It checks that name and nothing else, not the signature and not the folder it sits in. If the name is not ERAAgent.exe, it goes back to sleep and runs nothing.

That one check keeps it quiet in the places where malware normally gets caught. Drop it in a sandbox, open it in a debugger, run it where the host program has a different name, and the file does nothing at all.

The name it looks for is not even written in the file as text. It gets rebuilt from a handful of numbers while it runs. The same trick covers three Windows functions it keeps off its list of borrowed code: one for running code straight from memory, one for handing out the loose permissions on its pipe, one for its random pauses. VirtualProtect, SetSecurityDescriptorDacl, CryptGenRandom. Someone sat down and made those choices.

So instead of calling out, it listens. A network card normally hands the computer only the packets addressed to it, and lets the rest go by. This one tells the card to keep it all, including the traffic meant for the machine next to it. That setting has a name, promiscuous mode, and it is the same setting a packet capture tool uses. SLEEPWALKER uses it to wait.

The configuration stored inside the file comes to five bytes:

1

87 01 2A 00 00

That is the complete set of orders it ships with. 87 is the instruction that means watch the network for the trigger. 01 says the next field is one byte long. 2A is that byte, the character code for an asterisk, meaning look on all interfaces. 00 00 is a two-byte number saying how many seconds to keep watching, and zero means no limit.

Five bytes: watch the wire, forever.

Forever comes with small print. It watches at most eight interfaces at a time. It skips the loopback interface and the addresses a machine hands itself when it cannot reach a network. And after a trigger lands, it waits at least three seconds before it accepts another one, mostly so it does not act on the same packet twice.

Each packet gets held up against a pattern, in six steps, in order, and the first five are checks. It has to be at least 48 bytes. Then it takes the last two small numbers in the packet and folds them into one value with a bit of arithmetic, an XOR, and folds that against a fixed value, 0xAAAA, again. Out comes a length. That length has to be sensible. It counts back from the end of the packet by that length, and the two bytes sitting there have to add up to those two trailing numbers, added this time, not folded. Then the block at that spot has to pass a CRC-32, a small sum calculated over data so that a reader can tell whether it arrived intact. That sum has nothing to do with the encryption. It is there so the backdoor can throw a packet away before wasting any effort on decrypting it.

Pass those five and the sixth step follows. It decrypts what it found with AES-256-CCM, which hides the contents and proves that nothing changed on the way, and only then does it treat the result as an order. All of the encryption comes from a copy of mbedTLS compiled into the file itself, so nothing has to be loaded from the system while it runs. Miss one step and the packet is dropped with no answer at all. Scan that machine from outside and it looks like nothing is there, because nothing is.

All of that runs against the raw bytes, before Windows has even decided whether it is looking at TCP or UDP. So the trigger can ride inside almost any kind of traffic.

When the trigger arrives and gets decrypted, what comes out is not a readable command. It is not download this file or run this program in any form you could read. It is a short program written in a command language that exists nowhere except inside this one file, with 23 instructions of its own design.

The simplest malware sends commands as plain text, so you can read along while watching the traffic. Better malware encrypts that plain text, and the protection ends the moment someone recovers the key. The researcher did recover the key here, it sits right in the file, and it decrypts the configuration cleanly with the authentication tag checking out. And it still tells you nothing. What comes out is a stream of opcodes in a private format. The key shows you how to read the bytes, and only reverse engineering the language shows you what they mean.

Those 23 instructions can wait for a time of day and move data over several routes. They can also take a program in pieces, write each piece into a shared work area of 128 KB in memory, and compare a SHA-256 fingerprint of what has arrived so far against the one that came with the instruction. Only on an exact match does it run. Anything it runs, it runs straight out of memory. Nothing in the language writes to disk, so whatever the operator wants sitting on that machine has to get there some other way.

The instructions ride on six different transports:

• → TCP, as client and as server
• → UDP
• → ICMP, with data hidden inside ping echo requests
• → SMB named pipes, including mounting a remote share with supplied credentials to move sideways
• → Raw promiscuous capture, which is how the trigger itself arrives
• → VMware VMCI

VMware machines have a channel for talking to the computer they run on. VMware built it so a virtual machine and its host can pass data back and forth without going out on the network, and it is called VMCI. Nothing about it touches a network card. If the infected machine is a virtual machine, orders can travel between it and its host, or between two machines sitting on the same host. Point a packet capture at the cable between them, record it all, and you still see nothing of this. Mandiant documented the Chinese group UNC3886 using that same channel to keep a foothold between compromised ESXi hosts and the machines running on them.

Each interface is captured with the Windows option set to receive everything crossing it, not just what is addressed locally. On an ordinary desktop that barely matters. On a machine that forwards traffic for others, a gateway, a VPN server, a host bridging two segments, a trigger meant for a completely different computer still crosses that interface. The infected machine does not have to be the destination. It just has to be standing where the packet goes past.

A second way in is built into the file but switched off. One opcode higher than the one stored in this sample turns on a trigger hidden inside DNS lookups. The command gets encoded with a text-safe scheme and split across the parts of a domain name. A checksum byte sits hidden in the first and last character of the label, so the backdoor can tell its own label from an ordinary one. The researcher built a working example to prove it out, encoding a sleep command:

1

mqfoceywmw4etcjdp2nptitil.example.com

Read back the way the backdoor reads it, the m and the l are the markers, the middle decodes to 14 bytes, and those decrypt to one instruction: sleep for 60 seconds. That is his own construction and not captured traffic. But it works, and DNS is the one kind of traffic almost any network lets out even when it blocks everything else. Turning that on needs either a different build or a follow-up command sent through another route.

The people behind this made mistakes, and those are what you would notice first.

The file forwards its seven fake data protection functions to something called dpapisvc.dll. That name does not exist on Windows. The closest match is dpapisrv.dll, which is unrelated and exports two functions instead of seven. When the load fails, the code does not fail that one call quietly. It exits the host process. So if something on that machine calls one of those seven functions, your management agent falls over for no visible reason.

Two separate paths also start the backdoor, one when the DLL loads and one on the first call to those exports, and neither checks whether the other already ran. That produces duplicate workers.

The DNS trigger has its own build fault. It only works over UDP. A DNS question sent over TCP starts with a two-byte length field, and this code never skips it, so a correct TCP query arrives two bytes out of step and falls apart before anything reads it.

And the cleanup is worse than the infection in one specific way. To let unauthenticated callers reach its named-pipe channel, it sets EveryoneIncludesAnonymous to 1 and adds its own pipe name to NullSessionPipes. When it tidies up afterwards, it records whether its own write succeeded, not whether an entry was already there. So the cleanup can delete a legitimate entry that existed before any of this started.

Side-loading is the only persistence it has, so a registry run key, a scheduled task or a service of its own are things you will not find here. It survives because the file lies in that folder and the agent loads it again whenever the service starts. Take the file out of the folder and it has nothing left to hold on to.

He has the file and nothing else. It arrived without a hacked company attached to it and without network logs, so where it turned up stays unknown. That leaves the victim unnamed, along with the country and the industry. The dropper that put it there is missing, and there is no proof the thing was ever used on a target at all. He could not tie the code to a known group. The only command actually stored inside the file is the one that starts the listener, so the rest of that language describes what it can do rather than what someone watched it do. He asks people who think they were targeted to contact him directly.

He also used SLEEPWALKER as a test case to compare AI models on reverse engineering Windows binaries, and wrote up the result. He tested Claude Opus 5 against GPT-5.6-Sol. Opus 4.8 and Sonnet 5 filled in when safety limits stopped Opus 5, and he left Fable out entirely, because its filters blocked even general questions that might have a second use.

Neither family was consistently ahead. Claude did better on some parts and GPT on others, and he names one exception. On three separate attempts Claude called the two trigger opcodes functionally identical. GPT caught the difference on its first try: one enables the raw listener only, the other also turns on DNS. The other finding is about access. He hit a refusal in each of his malware analysis runs with Claude, despite being accepted into Anthropic’s Cyber Verification Program, and not once with GPT. His suggestion is stricter admission to those programs and fewer interruptions for the people who get in. I am in that program too, and I have had chats close on me mid-analysis, so this is not an abstract complaint.

The vendor answered, though not in an advisory. Someone from the company replied to a question on their own forum. They tried it themselves on the current agent, and the planted file did not load. Windows reached past it and picked up the genuine one in each test. And where the agent sits next to their security product, Self-Defense locks that folder down so hard that an administrator cannot write into it.

Their second point lands harder. To put that file there you already need administrator rights on the machine, and with those in hand, side-loading a DLL is one of the milder things you could be doing. Asked why it went undetected, the answer was short. They detect it, and so do more vendors than a week ago.

That argument is fair as far as it goes. This is a post-compromise implant and not a way in. It is what an operator leaves behind after they already own the box, and it is built to sit there without drawing a single eye.

This shape is not new on Linux. Red Menshen ran BPFDoor inside telecom operator networks the same way for years, a listener that said nothing until a crafted packet arrived, documented by Rapid7. What is new is the same idea on Windows, wearing the file name of a security product.

The indicators are all on the machine itself:

• → An unexpected dpapi.dll sitting beside ERAAgent.exe
• → An unexpected dpapisvc.dll in that same folder
• → SHA-256 d347170752a28e2b8c4b8b9f3cab2e3a6541ba11682c94498d26eb9002779d60
• → EveryoneIncludesAnonymous set to 1
• → An unexpected entry in NullSessionPipes

The last two only mean something if you know what that machine looked like before. Plenty of software has a legitimate reason to sit in either one, so on their own they prove little. They are a place to start looking. The writeup ships a YARA rule and a read-only PowerShell scanner that checks these indicators across the machines you manage. The rule keys partly on a static key and on compiled protocol code, so a rebuild with different compiler settings would break it, and the researcher says so himself.

You can watch your own traffic and see what a passive listener would and would not see, using the network card you already have. My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

SLEEPWALKER analysis | ESET Security Forum | Mandiant