"We have been tracking two new backdoors, OctLurk and SilkLurk ," Kaspersky researchers write — a concise summary of a campaign that, according to the firm, has targeted government organizations across Central Asia since January 2025.
Where the campaign was observed and who was hit
Kaspersky reports identified victims in Afghanistan, Kyrgyzstan, Tajikistan, Uzbekistan, Kazakhstan, and the Syrian Arab Republic. Targeted organizations span healthcare, research, government offices and ministries of foreign affairs, logistics, law‑enforcement agencies, urban planning and facilities management, and public educational establishments. The implants and loaders are customized per victim and rely on machine‑specific data to decrypt payloads, complicating detection and analysis.
OctLurk: loader mechanics, plugins, and post‑compromise activity
OctLurk is deployed via a scheduled task named GoogleUpDate that executes a batch script (examples: C:\Users\[username]\Videos\1.bat and C:\windows\temp\in.bat). The task creates a service NgcCIntSvc which loads a loader DLL oleasapi.dll (MD5 082d49ef9f14e6811d68c7e0e82e5069). The loader double‑XOR‑decrypts and zlib‑decompresses hard‑coded bytes to resolve both a payload path and the backdoor bytes; the second XOR key is derived from the C: drive serial number. The backdoor is reflectively injected into memory and invoked.
Once active, OctLurk connects to a hard‑coded C2 on port 443 (example host dns[.]multitoconference[.]com) and fingerprints the host (OS info, computer and user names, local IP, local time). Collected data are compressed with zlib and encrypted with a hard‑coded XOR string plus 0x53 (83) random bytes, then sent using a 16‑byte header protocol. OctLurk supports loading in‑memory plugins; common modules include a Command Shell, a File Manager and an Interaction Manager capable of synthesizing keyboard and mouse events and taking screenshots.
Post‑compromise activity observed through OctLurk included credential harvesting with Impacket’s secretsdump (run as Adobe.exe, MD5 32a5985543433a4f60da2fafd873b927), dropping and scheduling a keylogger (AnyDesk.exe, MD5 2a571f6cee42a17d873f4c942649813f) and a browser password extractor (x64.exe, MD5 37dc84e4bcad92fa28f1e7778d088283). Operators also installed Pandora RC agents (via 1.bat scripts) and used an internal scanning tool Fscan (fc.exe, MD5 cf903e4a1629aa0582fd0363b5786676) to enumerate services and attempt password reuse attacks.
SilkLurk and LurkProxy: side‑loading, victim‑specific decryption, and proxying
SilkLurk is introduced via DLL side‑loading of legitimate binaries (examples include NetSetSvc.exe, nvgwls.exe, RtkSmbus.exe and RtkNGUI64.exe) that load malicious loader DLLs such as vulkan-1.dll and RtkSmbusLoc.dll. The SilkLurk loader moves a payload file (example OneDrive.dat) into a hard‑coded payload path (C:\ProgramData\Microsoft OneDrive\setup in the analyzed sample), then creates a service RmSs to run the legitimate host process which loads the malicious DLL.
Critically, SilkLurk’s loaders and shellcode use a hash of the victim computer name in multiple decryption steps: the payload path, payload bytes and relocation/entry‑point values are all victim‑specific. The SilkLurk backdoor stores an encrypted configuration in %APPDATA% (examples: filenames like 2470b666bece868f) and uses that configuration to connect to one or more C2 hosts and optionally a proxy. After establishing a connection it generates a 32‑byte network key, exchanges it with the C2 using a custom encrypted packet, and then transmits compressed, encrypted victim information.
SilkLurk was observed used to access network shares (via cmd.exe and PowerShell net use), search shared drives for sensitive documents, archive stolen data with WinRAR and 7‑Zip (binaries observed: RecordedTV.exe / recordutil.exe and C:\windows\vss\7z.exe) and to deploy a second‑stage PlugX dropper. The PlugX dropper (kmsonline.exe, MD5 3c9a1ba8e0c7475706adc6376e9d7b7c) unpacked a PlugX loader RasTls.dll (MD5 ef59aad625eebda8650aec5820d6ce69) configured to contact gycudore[.]kozow[.]com and 64[.]7[.]198[.]130.
LurkProxy is a heavily obfuscated, OctLurk‑style implant whose principal role is proxying. It listens on port 64980 and establishes a TLS connection to a C2 at 154[.]196[.]162[.]76. LurkProxy implements a proprietary, compressed and double‑XOR encrypted protocol and can operate as either a SOCKS5 reverse proxy (mode observed) or a transparent proxy with a hard‑coded target.
Shared infrastructure and attribution signals
Kaspersky documents multiple links between OctLurk and SilkLurk infections: co‑existence on the same hosts, shared staging directories (examples: C:\ProgramData\intel\), and one case where an OctLurk command shell was used to drop a SilkLurk loader (vulkan-1.dll MD5 be4731c09734da2e8eb6814a9c82f266). Some OctLurk and LurkProxy C2 addresses overlap with TrustFall (MystRodX/SilentRaid) infrastructure that Kazakhstan’s STS researchers publicly reported as used against critical infrastructure. Kaspersky assesses with medium confidence that a single Chinese‑speaking actor operates OctLurk and SilkLurk but does not attribute the activity to any known group.
What this means for technologists, policymakers, and affected enterprises
- Technologists and security teams: monitor for the deployment artifacts Kaspersky lists — scheduled tasks named GoogleUpDate or AnyDesk, services such as NgcCIntSvc, Cusrxsrv and RmSs, loader DLLs (oleasapi.dll MD5 082d49ef9f14e6811d68c7e0e82e5069, vulkan-1.dll MD5 8269d6ba1b6842f9152c90cf7add9b93), and LurkProxy behavior (listening on port 64980, C2 154[.]196[.]162[.]76).
- Policymakers and regulators in affected countries: the campaign targets multiple government ministries and critical functions across Central Asia, and Kaspersky documents reuse of VPS infrastructure and overlap with domains reported by local technical services — tracking and cross‑agency information sharing will be necessary to map the full scope.
- Affected enterprises and public bodies: the loaders are intentionally minimal and victim‑specific (drive serial number or computer name gates), so incident response should include full memory analysis and inspection of scheduled tasks, services and the specific file paths Kaspersky lists (for example C:\ProgramData\Microsoft OneDrive\setup\OneDrive.dat and C:\ProgramData\intel\).
OctLurk and SilkLurk show a repeated technical pattern: small, heavily obfuscated loaders on disk and multi‑plugin, in‑memory backdoors that rely on victim‑specific keys. That design gives operators multiple ways to persist, harvest credentials and move laterally — and it leaves open a central question Kaspersky’s reporting raises but does not resolve: which established actor stands behind this toolkit and whether the shared infrastructure reflects deliberate campaign coordination or opportunistic reuse.
https://securelist.com/octlurk-silklurk-backdoors-central-asia/120840/
