Focus: OctLurk and SilkLurk backdoors (Central Asia)

Since January 2025, researchers have been tracking two new backdoors seen in attacks targeting government organizations in Central Asia: OctLurk and SilkLurk. Victims include, among others, Afghanistan, Kyrgyzstan, Tajikistan, Uzbekistan, Kazakhstan, and even Syria. The affected organizations operate across a wide range of sectors, from healthcare and research to ministries, logistics, law enforcement, and public education institutions.

What makes these campaigns especially concerning is how the malware is built: each loader is tailored to the specific target and uses information from the infected machine to decrypt payloads. In addition, both the code and the communications are heavily obfuscated, making analysis difficult and forcing defenders to work harder to reliably identify indicators.

Why OctLurk and SilkLurk stand out

The underlying tooling is not a single straightforward backdoor that “does everything.” Instead, it takes the form of a chain of components: a loader that prepares itself and subsequent payloads, followed by a backdoor that responds to commands. Moreover, the backdoors can download and inject additional plug-ins, allowing attackers to add new actions without deploying an entirely new implant.

Researchers describe capabilities such as running command shells, interacting with the file system, generating mouse and keystrokes, performing network reconnaissance, stealing login credentials, and collecting email. Keylogging and extracting passwords from browsers are also in scope. Overall, the activity appears geared toward long-term access with versatile post-exploitation capabilities.

Furthermore, analysis indicates that the same threat actor is active with both SilkLurk and OctLurk. Some victims containing SilkLurk were also found to have OctLurk. Based on this, researchers assess the likelihood as “medium” that both variants were developed by the same actor and that this actor is Chinese-speaking. A definitive attribution to a known group could not be made at publication time.

OctLurk: from a scheduled task to payload injection

In OctLurk, the attack begins by obtaining elevated privileges via admin credentials. Next, the attacker creates a scheduled task on external systems named GoogleUpDate. That task runs once shortly after it is created, under the System account. The task points to a batch script located in the user directories, after which the loader starts.

For the actual execution, OctLurk sets up a services structure. The script creates a service that loads a DLL (with a specific DLL name pattern identified during source analysis). This DLL exports functions that let the loader start the next phase and activate the core code.

The payload mechanism clearly focuses on evasion. The loader collects hard-coded bytes that are first decrypted using double XOR and then decompressed with zlib. At least two key components are involved: a first key hard-coded in the loader and a second key derived from the C:-drive serial number of the victim. This makes the payload specific to each device and complicates reuse by defenders.

Next, the backdoor DLL is reflectively injected into memory, and the entry point is activated. From there, the malware can call functions through decrypted methods, with both names and ordinals hard-coded and again obfuscated.

OctLurk backdoor: collecting information and executing commands

The OctLurk backdoor establishes an encrypted connection to a C2 address and port 443. To set up the session, the malware collects various information: OS details, computer and user name, hostname-to-IP mapping, local time, and IP address information. It then compresses and encrypts these data using a hard-coded XOR key plus a second key derived from random bytes (length hard-coded in the analyzed samples).

The malware uses its own packet framing: it first sends a header and then the actual data payload. Upon receiving a response from the C2, the backdoor processes a packet again through double XOR and zlib. The resulting contents can include both command instructions and plugin-like code.

In the post-compromise phase, OctLurk can activate multiple plug-ins to support different tasks. The source analysis explicitly mentions a command-shell plug-in used to perform further actions, such as extensive victim fingerprinting and exporting relevant event logs.

Post-exploitation: credential theft, keylogging, and browser passwords

After initial access, the actor focuses on expanding visibility and control. For example, a scheduled task is reused to collect detailed information about hardware, software, and network configurations. The results are stored in multiple files in the %TEMP% environment.

In addition, attackers export successful login events for interactive remote logons and search for logons from specific users. For credential harvesting, a portable variant of the well-known secretsdump material (Impacket-like) is used to retrieve password hashes from domain controllers. Immediately afterward, the malware also checks all members of the “Domain Controllers” group to target further parts of the environment.

Keylogging is also part of the toolkit. The analysis describes a keylogger being dropped and executed via a path under public directories. The malware then writes keystrokes and clipboard data to two files, encoding the collected data by subtracting a fixed value per byte.

Finally, the theft of browser passwords is covered. The source describes a “Browser Password Decryptor” that can extract passwords from Chrome and Firefox data files. The mechanism involves, among other things, the use of master key data (such as Local State in Chrome) and the storage of encrypted login records.

Role of LurkProxy: relaying traffic in proxy mode

Alongside the OctLurk backdoor, the attackers deploy an additional utility researchers call LurkProxy. While LurkProxy is architecturally similar to OctLurk, the analysis makes it clear that it is not a “backdoor” by itself: its primary goal is proxying network traffic.

Researchers observed that the actor creates a service that loads a DLL and then tests connectivity to a domain serving as the C2 connection endpoint. After confirming reachability, the proxy component becomes active and establishes a TLS connection to the C2 server. Communication uses a custom packet protocol with compression and double XOR-like encryption.

Notably, the proxy can run in two modes, with the selected mode fixed in the implant. In the analyzed variant, SOCKS5 is primarily used: the proxy informs the C2 that a connection has been established, after which the C2 opens a connection to the target so that bidirectional communication flows through the attacker.

SilkLurk: sideloading with legitimate executables

Where OctLurk starts with scheduled tasks and services that drive a loader DLL, SilkLurk moves more toward “sideloading” via legitimate programs. The actor creates a services structure that starts normal binaries (such as tools related to NVIDIA and Realtek), with malicious loader DLLs loaded alongside them.

The SilkLurk loader first verifies that it is running in the correct context—namely inside the legitimate executable that loads it. After that, it moves a payload file to a path that is hard-coded in the sample. To establish persistence, a new service is created to restart the legitimate module binary again, ensuring the malicious DLL is loaded repeatedly.

Decryption is also device- and target-specific here: the loader generates a 32-bit hash based on the computer name and uses that hash in its own algorithm to decrypt both payload paths and payload bytes. This makes the malware tailored to the specific system.

What this means for defense

For organizations, the key takeaway is that OctLurk and SilkLurk are not just “backdoors,” but a complete set of techniques for persistence, payload decompression, task execution, and network relaying. By combining obfuscated loaders, machine-specific keys, and plug-ins that add extra functionality, attackers can adapt while staying active.

Therefore, it helps not to focus on a single component. Concentrate on recognizing the chain: scheduled tasks and services that load DLLs, unexplained network connections toward the mentioned C2 structures, and anomalous behavior related to credential harvesting, keylogging, and reading browser databases.

Conclusion

The campaign surrounding OctLurk and SilkLurk demonstrates how advanced backdoors were used across Central Asia against a variety of government environments. Using tailored loaders, heavy obfuscation, plug-in expansion, and additional proxy functionality via LurkProxy, attackers aim to maintain access and support lateral movement.

By translating technical details from the research analysis into detection and response measures, defenders can connect the dots between initial access, persistence, and post-exploitation activities more quickly—reducing the chance of prolonged compromise.