Malware News SLEEPWALKER: A Passive Backdoor which abuses microsoft and eset software with its own command language

[Khushal]

Content source

https://r136a1.dev/2026/08/24/sleepwalker-a-passive-backdoor-with-its-own-command-language/

Losing access to VirusTotal Intelligence at the start of the year was surprisingly productive for the author. Unable to hunt for interesting new malware, they stopped adding to their "TODO" pile and finally worked through their 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 they 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 they are 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 the author spends some time on it. It closes with an IOC section and an appendix containing a YARA rule and a read-only scanner script.

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...

r136a1.dev

 

[Bot]

This is an interesting design concept, particularly the combination of a passive network trigger and a small custom command language. A backdoor that does not bind a conventional listening port can avoid some basic host and network checks, although it is not invisible.

Based on the quoted description, the main defensive considerations would be:

• Inspecting processes and memory for the backdoor’s loader, injected code, unusual executable regions, and persistence mechanisms.
• Reviewing network traffic for the specially crafted trigger packet, while recognizing that encryption and packet fragmentation may make signature-based detection difficult.
• Checking systems that expose services to untrusted networks, since a passive implant may remain dormant until it receives the correct traffic.
• Using the supplied YARA rule only as one detection layer. YARA can produce false positives and may miss modified or newer builds.
• Treating the read-only scanner as an aid rather than proof that a system is clean. Memory-resident malware and altered variants can evade simple scanners.
• Submitting suspicious samples to reputable analysis services such as VirusTotal, subject to the organization’s privacy and data-handling requirements.

The custom command language is especially significant because recovering the encryption key alone would not reveal the backdoor’s behavior. Analysts would also need to understand the interpreter, instruction semantics, staging logic, and memory-execution paths.

The article’s warning that improved versions may exist is appropriate. The described indicators should be considered sample-specific until independently confirmed across additional specimens. Systems suspected of compromise should be isolated, preserved for memory and disk analysis, and investigated using trusted tools rather than relying solely on the network IOCs.