OctLurk and SilkLurk: newly identified tailored backdoors in cyber-espionage campaign in Central Asia

Summary

Researchers discovered two new tailored backdoors, OctLurk and SilkLurk, deployed in a cyber-espionage campaign targeting government organizations across Central Asia (Afghanistan, Kyrgyzstan, Tajikistan, Uzbekistan, Kazakhstan, Syria) since January 2025. Both backdoors operate primarily in memory, inject plugins for shells, network scanning, credential dumping, keylogging, and browser password theft. The same Chinese-speaking threat actor likely operates both backdoors and a supporting utility called LurkProxy.

Full text

Table of Contents IntroductionOctLurkOctLurk DeploymentLurkPoxy DeploymentOctLurk loaderOctLurk backdoorPost-compromise activityVictim fingerprintingEvent log collectionCredential harvestingImpacket — secretsdumpKeyloggerBrowser Password DecryptorRemote access : Pandora FMS agents (Pandora RC agent)Network scan: FSCANEmail harvestingLurkProxySilkLurkDeploymentSilkLurk loaderSilkLurk backdoorPost-compromise activitySecond-stage payloadPlugXInfrastructureAttributionConclusionsIndicators of CompromiseBackdoor domains and IPsOctLurk C2LurkProxy C2SilkLurk C2LoadersOctLurk loaderSilkLurk loaderPlugX dropperPlugX loaderOctLurk backdoorOctLurk File Manager pluginOctLurk Command Shell pluginOctLurk Interaction Manager pluginImpacket’s secretsdump (not available)KeyloggerBrowser password stealerFSCANBatch scripts (not available)Archive utilitiesWinRAR7zipFile pathsOctLurk file pathsSilkLurk file pathsPlugX file pathsWinRAR and 7z file paths Authors Saurabh Sharma Yaroslav Kikel Introduction We have been tracking two new backdoors, OctLurk and SilkLurk, observed in attacks against government organizations primarily in Central Asia since January 2025. Identified victims are located in Afghanistan, Kyrgyzstan, Tajikistan, Uzbekistan, Kazakhstan, and the Syrian Arab Republic. These organizations operate across several sectors, including healthcare, research, government offices, ministries of foreign affairs, logistics, law‑enforcement agencies, urban planning and facilities management, and public educational establishments. 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. OctLurk and SilkLurk can download and inject additional plugins to perform further malicious actions, including launching command shells, performing file system activity, synthesizing keyboard and mouse events, network scanning, credential dumping, keylogging, password theft from browsers, email collection, and remote access. Furthermore, the attackers deployed a specialized utility we named LurkProxy, which we also cover in this report. While it has a highly similar architecture to the OctLurk backdoor, it is not a backdoor itself. Our investigation shows that the same threat actor operates both SilkLurk and OctLurk , and some victims infected with SilkLurk also contain OctLurk. We assess with medium confidence that the same 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. OctLurk OctLurk Deployment The attacker created a scheduled task named GoogleUpDate on remote machines using admin credentials. The task runs once with System account privileges right after it was created, executing the batch script located at C:\Users\<username>\Videos\1.bat (MD5 6ecf84fb18f6747ed08d7598364d853a). Prior to executing the task, the actor queries its status. It is then run, as shown below. The 1.bat script creates a service named NgcCIntSvc, which loads the loader DLL named oleasapi.dll (MD5 082d49ef9f14e6811d68c7e0e82e5069). The ServiceMain parameter in the service’s registry entry is set to invoke the RegisterService function of oleasapi.dll as shown below. LurkPoxy Deployment In another case, the attacker at first checked connectivity to the domain dns[.]ssentialserv[.]xyz as shown below. At the time of our research, the domain was resolving to the address 154[.]196[.]162[.]76 which is used as a LurkProxy C2 server. After confirming that the C2 server was reachable, the attacker executed the batch script C:\Users\[username]\Desktop\auto.bat (MD5 b874123a80fc4f40e06872b9cb54ebc6). The script created a service named Cusrxsrv, which loads a DLL named msbasesysdc.dll. In the service registry, the ServiceMain parameter was set to call the RegisterService function of msbasesysdc.dll as shown below. We identified several service names — specitsrc, cmtastsvc, PNRPHostSvc, vmictimerosync, and vmicagent — that the attackers used to load a malicious DLL onto compromised machines. OctLurk loader The loader DLL exports two methods, Refresh and RegisterService. The previously created service first calls RegisterService, which in turn invokes Refresh, the method that contains the malicious code. To locate the payload, the loader double-XOR-decrypts and then zlib-decompresses a set of hard‑coded bytes, yielding the payload file path. The payload bytes itself undergoes the same double‑XOR decryption and zlib decompression to produce the backdoor DLL bytes. The double‑XOR decryption uses two distinct multibyte keys: Key 1: hard‑coded in the loader Key 2: derived from the serial number of the C: drive The backdoor DLL is reflectively injected into memory and its entry point is executed. The loader can then call the DLL’s exported methods either by name or by ordinal; both the method name and the ordinal number are hard‑coded in the loader and are decrypted using the same double‑XOR and zlib‑decompression process applied to the payload path and bytes. OctLurk backdoor The loader invokes the backdoor’s curl_easy_escape function (ordinal 2). The backdoor then creates a stream socket using a hard‑coded C2 address (dns[.]multitoconference[.]com) and port 443. It gathers the following information from the victim machine: OS information as RTL_OSVERSIONINFOW structure Computer name User name Local host name Local IP address in format %u.%u.%u.%u, with local hostname-to-IP-address translation Current local date and time as SYSTEMTIME struct To encrypt the collected data, the backdoor employs a hard‑coded XOR key, which in most cases we observed was the string FDrertgr##@QEWASGkio865ehyf98foidsjzhug874392dfsREFDfdsAGH43wea98h. In addition, it generates 0x53 (83) random bytes — this length is also hard‑coded in the sample — and uses them as a second XOR key. The collected victim information is first compressed with zlib (deflate), and then XOR‑encrypted twice, first with the hard‑coded string key and then with the randomly generated byte sequence. The final data is arranged as follows: 0x00: randomly generated XOR key bytes (size 83 bytes) 0x53: compressed data size 0x57: compressed data in the following format: <uncompressed_size> <deflate(data)> 0x57 + compressed_data_size: randomly generated bytes (from 14 to 41 bytes) The backdoor initially transmits a 16‑byte header that specifies the size of the incoming data packet, as shown below. It then sends the actual data packet. 0x00: randomly picked 10 chars from the string “zyxwvutsrqponmlkjihgfedcbaABCDEFGHIJKLMNOPQRSTUVWXYZ9876543210-_” 0x0A: \x00\x00 0x0C: next_packet_size The first packet received is 16 bytes long, and its last four bytes specify the size of the subsequent data packet. The format of the subsequent data packet is shown below. 0x00: XOR key; size 83 bytes 0x53: compressed data size 0x57: compressed data in the format: <uncompressed_size> <deflate(data)> The received data is decrypted using a double‑XOR method: first with the XOR key contained in the packet, then with a hard‑coded XOR key. After the XOR decryption, the data is zlib decompressed. The data may be a command or a plugin code. OctLurk loads plugins from the C2 server directly into memory to perform various tasks. Each plugin exports two methods — ins_ctl_db and oct_lk_col — with the actual functionality implemented in oct_lk_col. Our analysis shows that the plugins listed below are commonly deployed on victim machines. Command Shell: provides a command shell File Manager: performs filesystem interaction Interaction Manager: synthesizes keyboard and mouse events The table below provides a detailed description of operations performed by these plugins, where each switch case value denotes command ID. Plugin type Description File Manager ● case 0x10020: for each drive, retrieve the following information: volume GUID path, drive letter, v

Indicators of Compromise

• hash_md5 — 6ecf84fb18f6747ed08d7598364d853a
• hash_md5 — 082d49ef9f14e6811d68c7e0e82e5069
• hash_md5 — b874123a80fc4f40e06872b9cb54ebc6
• domain — dns.ssentialserv.xyz
• ip — 154.196.162.76
• malware — OctLurk
• malware — SilkLurk
• malware — LurkProxy
• malware — PlugX

Entities