2026-07-31 · view entry permalink →
OctLurk and SilkLurk — sibling plugin backdoors whose loaders key their payload decryption to the victim machine itself, deployed against Central Asian and Syrian government bodies
Kaspersky GReAT published analysis of two new plugin-based backdoors on 2026-07-30, naming them OctLurk and SilkLurk (Kaspersky Securelist, 2026-07-30). Victim organisations sit in Afghanistan, Kyrgyzstan, Tajikistan, Uzbekistan, Kazakhstan and Syria, across healthcare, research, government offices, foreign-affairs ministries, logistics, law enforcement, urban planning and public education. The victimology is out of scope for this constituency; the loader design and the plugin architecture are the reason the entry is here, because both are aimed squarely at the analysis and detection workflow a government SOC would use against them.
Everything here starts after the attacker already has administrative credentials. OctLurk's chain begins with a scheduled task created on remote machines with admin rights, set to run once under the System account immediately after creation. That task runs a batch script from a user profile folder or a temporary directory, which installs a Windows service; the service's ServiceMain registry parameter is then repointed to invoke an export of a malicious loader DLL rather than a legitimate service binary. The loader exports two functions, and the one the service calls simply invokes the other, which carries the actual logic. SilkLurk reaches the same place by a different route — its own service name, and side-loading under a legitimate binary rather than the ServiceMain repoint.
The loader is built to be useless to an analyst who does not also have the victim's machine. Taking OctLurk's, it locates its payload by decrypting a hard-coded byte blob through two successive XOR passes and a decompression step, then applies the identical process to the payload itself to produce the backdoor DLL. Two keys are involved: one is baked into the binary, and the second is derived at runtime from the serial number of the victim's C: drive. SilkLurk's loader does the same thing with a different host identifier, computing a hash of the victim's computer name. A sample lifted from one host therefore cannot be unpacked on an analyst's workstation, in a sandbox, or against any other victim — Kaspersky states plainly that the loaders are customised per victim and use information from the victim's machine to decrypt the payload. The resulting backdoor DLL is loaded reflectively into memory and never written to disk in decrypted form. The same double-XOR-and-compress framing wraps command-server traffic in both directions, with a freshly generated random key travelling in each packet header, so the wire format changes every session even though the static key does not.
Plugins arrive from the command server and stay in memory. Kaspersky documents three. A file manager enumerates volumes and directories, reads and writes files in chunks with integrity checking, executes commands, and — worth noting for anyone doing timeline work afterwards — deliberately rewrites file timestamps to attacker-supplied values. A command shell either maintains an interactive cmd.exe session or, when none is running, executes each command non-interactively with output redirected to a temporary file that it reads back and then deletes. An interaction manager captures the screen on demand or on an interval, reads and writes the clipboard, and synthesises mouse movement, clicks and keystrokes through low-level Windows input events — full hands-on-keyboard control delivered as a plugin rather than as a separate remote-access tool.
Post-compromise, the operators run a fingerprinting script that inventories sessions, Kerberos tickets, running tasks, antivirus products and Defender's tamper-protection and exclusion settings, network connections and hardware, and specifically queries the Windows Security log for the last few successful remote-interactive logons. They then deploy Impacket's secretsdump for credential extraction, a keylogger persisted under a scheduled task named after a legitimate remote-access product, a browser-password decryptor targeting Chrome and Firefox credential stores, Pandora RC agents for durable remote access, the FSCAN network scanner, and email-harvesting tooling. SilkLurk victims additionally receive PlugX — which Kaspersky describes as a modular remote-access trojan active since at least 2008 and historically linked to Chinese-speaking threat actors, and which is part of what supports its attribution language — and SilkLurk intrusions show operators mounting shares with harvested admin credentials, hunting documents by hand, and archiving them before exfiltration.
Kaspersky also reports that several command-server addresses used by OctLurk and its companion proxy utility appear in a Kazakhstani State Technical Service report on a separate Linux-targeting implant — tracked as TrustFall by that agency, MystRodX by Qianxin and SilentRaid by Cisco Talos — and it is explicit that this points to shared infrastructure across campaigns without establishing whether they ran at the same time.
Detection. Four behaviours here are strong hunt anchors and none of them depend on knowing this malware. First, service creation where the ServiceMain parameter points at a DLL export in a path outside the normal system directories — a configuration that legitimate services essentially never use. Second, a scheduled task created remotely to run once under System immediately after creation, executing a script from a user profile or temporary directory. Third, in process telemetry, the non-interactive shell pattern: a cmd.exe child redirecting output to a temporary file in the user temp directory, followed within moments by a read of that file and its deletion — the create-read-delete triple on a short-lived temp file is far more distinctive than any one of the three events. Fourth, in the same log the operators query, an inventory sweep that touches session enumeration, Kerberos ticket listing, antivirus product enumeration and Defender exclusion registry keys inside a single short window from one process lineage.
Triage: administrators run every one of those discovery commands individually, and management agents create services and scheduled tasks constantly. The discriminators are sequence and origin: the fingerprinting commands arrive as one uninterrupted batch from a single script rather than typed over minutes; the service points at a DLL export rather than an executable; and the scheduled task runs exactly once and never again, which is the opposite of what a legitimate maintenance task looks like.
We assess with medium confidence that the same threat actor is behind both backdoors, and that they are Chinese-speaking. However, at the time of publication, we couldn't attribute this activity to any known group.
The backdoor loaders are customized for each victim and use information from the victim's machine to decrypt the payload. Both the loaders and the backdoors are heavily obfuscated, making analysis more complicated.