We continue tracking the activity of Toy Ghouls (also known as Bearlyfy, Laboo.boo, and Feral Wolf), a financially motivated group that has been targeting Russian organizations since 2025. The attackers initially relied exclusively on tools pulled from public GitHub repositories along with leaked Babuk and LockBit ransomware builders, later shifting to their own custom ransomware, GenieLocker. In early July 2026, we observed the group using a custom backdoor for the first time.
We identified two versions of this backdoor: one uses the HiveMQ MQTT broker as its C2 server, while the other relies on the Element messenger. Both versions include “bird” in their names:
mqtt-bird-agent 0.1.0 (HiveMQ version)
matrix-bird-agent 0.1.0 (Element version)
This post examines how the backdoor is delivered to target systems, how it establishes persistence, and how it communicates with its C2 server.
Technical details
Delivery
In this campaign, the attackers use Windows Remote Management (WinRM) to deliver the backdoors and their configuration files to compromised systems. The group relies on open-source tools such as Evil-WinRM and WinRM-fs to do this.
Installation
The backdoor can both run within an interactive command-line session and establish persistence as a Windows service, using the --install or install option, depending on the backdoor version. The --service (or service) option is not available by default and is instead used as an argument for the installed Windows service.
Other launch options are listed in the backdoor’s help output:
C:\cplsupport.exe -h
Bird Agent - MQTT server monitor
Usage: cplsupport.exe [OPTIONS]
Options:
-c, --config <CONFIG> Path to config.toml config file
--install Install as a system service
--uninstall Uninstall the system service
--seal Encrypt sensitive config fields in-place using a machine-bound key
-h, --help Print help
-V, --version Print version
HiveMQ version backdoor help output
In the Element version, the backdoor help output looks as follows:
C:\wtass.exe -h
Matrix monitoring agent
Usage: wtass.exe [OPTIONS] [COMMAND]
Commands:
install Register this agent with the Matrix homeserver and panel
uninstall Remove this agent's service and credentials
service Run as a Windows service (internal)
help Print this message or the help of the given subcommand(s)
Options:
-c, --config <CONFIG>
-h, --help Print help
-V, --version Print version
Element version backdoor help output
By default, the backdoor looks for a config.toml configuration file in the directory where the executable was launched, then falls back to %PROGRAMDATA%\SynapseAgent\config.toml (Element version) or %PROGRAMDATA%\cplsupport\config.toml (HiveMQ version). If no configuration file is found in either location, the full path can be specified using the -c (--config) option.
The backdoor accepts both unencrypted configuration files and files with partially encrypted sections. In the first case, once the backdoor is launched, it reads the file and partially encrypts it using the seal() function (the --seal option in the HiveMQ version), applying the ChaCha20-Poly1305 algorithm with a key derived from the value of the HKLM\Software\Microsoft\Cryptography\MachineGuid registry key. This means that after the backdoor’s first run, the configuration file becomes bound to that specific machine. On subsequent runs, the configuration is decrypted automatically. If the input configuration was already partially encrypted, it is likewise decrypted automatically.
If the configuration cannot be decrypted, the backdoor stops running.
Encrypted configuration files look as follows:
Encrypted backdoor configuration file, HiveMQ version
The encrypted portion of the HiveMQ version’s configuration contains the following parameters:
agent_privkey: the agent’s private key
channel_id: the channel identifier used to communicate with the broker
server_pubkey: the server’s public key
Decrypted blob field in the HiveMQ version’s configuration
In the Element version, the configuration file is deleted immediately after the first run, and the relevant parameters are instead written to the HKLM\Software\synapse\Config\SealedConfig registry key. On subsequent runs, the backdoor checks the registry for its configuration first.
Decrypted Element version configuration file, retrieved from the registry
The Element version’s configuration specifies the address of an Element server controlled by the attackers, a room identifier, and an access_token used to access that room. If this parameter is left empty, the backdoor prompts for the password interactively during installation. After successfully creating a session, the backdoor saves the received token to the blob field.
Communication
At startup, both backdoor versions send a GET request to http://ip-api.com/json to determine the system’s public IP address and country of origin.
The first version uses the public HiveMQ MQTT broker (broker.hivemq.com) as its C2 server. The free tier of this broker supports up to 100 concurrent connections and up to 10 GB of traffic per month. The attackers set up their own cluster and used it both to collect telemetry from compromised systems and to send commands to the backdoor.
Once a connection is established, the system’s status is sent via a POST request to
broker.hivemq.com:8883/[cluster_id]/status. The message format is:
{"online":bool,"hostname":"hostname.domain","timestamp":unix_timestamp,"location":{"json"}}.
At intervals defined in the configuration file, system information, such as CPU load and available memory, is sent via a POST request to
broker.hivemq.com:8883/[cluster_id]/metrics3. The message format is:
{cpu_percent":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m":float,"load_5m":float,"load_15m":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}.
The backdoor sends GET requests to
broker.hivemq.com:8883/[cluster_id]/cmd/req to retrieve commands from the C2 server. The server responds in the format:
{"cmd_id":int,"command":"str","timeout_secs":int}.
Commands are executed via PowerShell.exe in hidden mode, using the -NonInteractive -NoProfile -Command parameters.
Command execution results are sent to the command server at
broker.hivemq.com:8883/[cluster_id]/cmd/res in the
{"stdout":"str","stderr":"str","exit_code":int,"duration_ms":int} format.
For the second backdoor version, the attackers set up their own Element server running on the Matrix protocol, meet.element[.]tw, as the C2 server. On this server, they created a room used to receive messages containing device information and to send commands for execution on the compromised system. The communication flow is as follows:
Once a connection is successfully established, the backdoor sends an m.bird.status message containing the system’s status. This message format is identical to that used in the HiveMQ version.
At intervals defined in the configuration file, information about the compromised system is sent as an m.bird.metrics message. Field names are slightly different from those in the first version:
{cpu_percent_x100":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m_x100":float,"load_5m_x100":float,"load_15m_x100":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}.
This version of the backdoor supports two types of commands, distinguished by the start of the received message.
To set a new interval for sending metrics, the attackers send a message beginning with config:set_interval (accepting values from 5 to 3600 seconds). The new value is saved to the HKLM\Software\SynapseAgent\metrics_interval registry key.
Messages containing commands to execute begin with the string cmd:. Based on data extracted from Element’s SQLite databases on the compromised system, we were able to identify the account name the attackers used to send commands: panel-bot.
Received commands are executed via the Windows command line interface.
Command output is sent as an m.bird.cmd_response message. This message format mirrors the one used in the HiveMQ version.
Takeaways
We have been tracking Toy Ghouls’ activity for quite some time. We previously found that the group had expanded its arsenal with a custom ransomware strain, GenieLocker, and we have now discovered that it has also developed a backdoor capable of giving it full control over an infected device. The new tools use unconventional channels to communicate with their C2 server: the HiveMQ MQTT broker and the Matrix-based Element messenger. This shift away from publicly available open-source projects toward custom-built tools suggests that Toy Ghouls is working to make its attacks more sophisticated and to evade detection for longer.
While monitoring Mirage Kitten activity, we uncovered a previously undocumented malware family that we dubbed NodeRabbit. We identified the first sample on a system in Afghanistan. Further threat hunting revealed two additional, more advanced, variants: one on a system in Egypt and another on a system in Ethiopia.
NodeRabbit is a cross-platform remote access trojan (RAT) built with Node.js. It targets Windows, Linux, and macOS. Its operators deliver it through spear-phishing messages on LinkedIn and other job search platforms that contain trojanized coding challenge archives.
During the same investigation, we discovered another previously undocumented malware family that we dubbed PollCat. Like NodeRabbit, PollCat is a cross-platform RAT, but it is written in obfuscated JavaScript also distributed through trojanized coding challenge archives.
Mirage Kitten has historically relied on native malware written in languages such as C, C++, and Go, often deploying it through DLL search-order hijacking. NodeRabbit and PollCat represent the first publicly documented use of Node.js- and JavaScript-based malware by this APT group.
Kaspersky’s products detect this threat as Trojan.JS.MirageKitten.*
Background
During recent threat research, we detected suspicious activity on a system in Afghanistan. We traced it to an archive containing a software development project that the user may have received during a job application process. The archive purported to contain a coding challenge for candidates applying for an engineering role.
The archive, Front-Technical-Challenge.zip (MD5: 1EA83E4E4592B01E4ACAB63EB867BEE5), was hosted in an Amazon S3 bucket at: https://oracle-challenge.s3[.]us-east-1.amazonaws[.]com/Front-Technical-Challenge.zip
It contained TaskFlow, an app for software engineering assessment built with Express, React, and Vite. The accompanying README instructed the candidate to review the application and fix defects in its frontend. It also claimed that server.js was bug-free and should not be modified, conveniently directing attention away from the only application source file the attackers had altered.
README file for a trojanized coding challenge app
The README also imposed a three-hour time limit and prohibited the use of AI assistants. Notably, an AI code-review assistant tasked with auditing the project would likely have flagged the suspicious first-line import of an unknown npm package and warned the targeted developer that the project was trojanized.
Rules and time limit included in the trojanized coding challenge app README file
The first line of server.js imported a trojanized npm package named colorized_terminal, version 2.1.0. The attackers bundled the package directly in the challenge task archive’s node_modules directory rather than publishing it to the npm registry. When imported, the package silently launched an implant from node_modules/.cache/.320697f1/index.js as a detached background process.
Retrospective threat hunting across our telemetry revealed the broader scope of the campaign. We identified three NodeRabbit variants with a shared code lineage; each was recovered from a system in a different country. The operators delivered the variants through similarly themed coding challenges and used two trojanized packages, colorized_terminal and pretty-log, both pinned to version 2.1.0.
The campaign also delivered PollCat, a second RAT with a substantially different structure, through a separate coding challenge lure. We’ll analyze PollCat later in this research.
Initial access
The infection chain begins with fake recruiter accounts contacting prospective targets on a job search platform. According to a publicly cited source, a threat actor posing as a talent acquisition specialist at a major technology company contacted a software engineer and advertised a job opening, inviting the target to complete a technical assessment.
The target received a link to a coding challenge hosted on Amazon S3 and was pressured to download and run the project immediately. This public post matches the delivery chain we reconstructed from our telemetry: recruiter outreach on a job search platform, a coding challenge presented as a technical assessment, and a trojanized project archive hosted on legitimate cloud infrastructure.
NodeRabbit RAT: the first variant
We discovered the first NodeRabbit variant on a system in Afghanistan. The malware was concealed within the TaskFlow assessment at node_modules/.cache/.320697f1/index.js and executed by the trojanized colorized_terminal package.
Once running, NodeRabbit generates a unique agent identifier from available host information. It calculates the SHA-256 hash of the hostname, username, operating system version, architecture, and MAC address, then truncates the result to its first 32 hexadecimal characters.
NodeRabbit binds a TCP listener to 127.0.0.1:48739. This listener acts as a single-instance mechanism. If the malware cannot bind to the port, it assumes that another instance is already running and terminates silently.
NodeRabbit uses a persistence mechanism for each operating system:
Operating system
Persistence mechanism
Windows
Copies itself to %APPDATA%\Microsoft\EdgeUpdate\msedge_update.js; clones the local node.exe to nodew.exe in the same folder and patches its PE subsystem from Console to Windows GUI to suppress the console window; creates HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftEdgeUpdate registry key executing nodew.exe msedge_update.js
Linux
Copies itself to ~/.config/microsoft-edge-update/msedge_update.js and creates an @reboot cron entry that invokes the script using the current Node.js executable.
macOS
Copies itself to ~/.config/microsoft-edge-update, creates ~/Library/LaunchAgents/com.microsoft.edgeupdate.plist configuration file pointing at the copy’s location with RunAtLoad and KeepAlive parameters, and attempts to load it.
The malware communicates with its command-and-control servers through three API endpoints, choosing from the following Azure-hosted C2 infrastructure addresses. On failure, it switches to the next C2 address:
NodeRabbit serializes each C2 request object as JSON and wraps it with AES-256-GCM. The AES key is the SHA-256 digest of an ASCII seed embedded into the agent. Every request uses a fresh 12-byte IV and a 16-byte authentication tag:
The malware sends encrypted requests using the following structure:
C2 responses are structured the same way and may contain a command to execute. We observed the first NodeRabbit variant supporting 11 commands:
Command
Functionality
sys:info
Return hostname, domain user information, username, and process ID.
proc:list
List running processes.
proc:start
Execute an arbitrary shell command.
fs:list
List a directory.
fs:read
Read a file in chunks and return Base64 data.
fs:write
Decode Base64 and write it at a chosen file offset.
fs:delete
Delete a file or recursively delete a directory.
fs:mkdir
Create directories recursively.
net:config
Enumerate adapters, MAC addresses, IP addresses, and DNS settings.
agent:sleep
Change the beacon interval.
script:exec
Write a base64 Node.js script to a randomly named .tmp file, execute it and delete it.
NodeRabbit RAT: the second variant
Retrospective threat hunting following the discovery in Afghanistan led us to a second infection on a system in Egypt. This sample is a more advanced NodeRabbit variant, launched through the trojanized pretty-log package instead of colorized_terminal.
Before running its core functionality, the malware checks whether the host resembles an analysis environment. It terminates if it detects limited system memory, a low CPU count, short system uptime, analyst-associated usernames or hostnames, or common analysis tools running on the system.
Before terminating, the malware generates benign HEAD requests to www.google.com, www.microsoft.com, and www.cloudflare.com, then exits without ever contacting its C2 infrastructure. Most likely, it attempts to look less suspicious by showing some benign activity before exiting.
Variant 2 implements partial corporate proxy support: it checks HTTP(S) proxy environment variables, Windows Internet Settings, including an explicit PAC URL, and WinHTTP configuration; tunnels its HTTPS C2 through HTTP CONNECT. It first tries to establish an unauthenticated connection. If it fails, it retries using URL-embedded basic credentials. Finally, it delegates Windows NTLM/Negotiate challenges to curl.exe --proxy-anyauth --proxy-user. It caches the proxy-discovery result, including when no proxy is found, for five minutes. If the polling loop detects a network-interface or IP-address change, it clears the cache and runs proxy discovery again on the next checkin.
To make sure a single instance is running, Variant 2 uses a host-specific port derived from the agent identifier instead of the fixed TCP port used by the first variant. It interprets the first four hexadecimal characters of the identifier as an integer and applies the following calculation: 41984 + (value mod 5000).
The resulting listener port falls between 41984 and 46983. Unlike the shared port used by Variant 1, this port varies depending on the infected host.
For persistence, Variant 2 masquerades as Intel Driver & Support Assistant. The exact persistence mechanism, once again, depends on the operating system.
Operating system
Persistence mechanism
Windows
Copies itself to %LOCALAPPDATA%\Intel\DSA\idriver_support.js. It then copies the local node.exe binary to IntelDSA.exe and changes its PE subsystem from Console to Windows GUI, suppressing the console window. Finally, it creates a scheduled task named IntelDriverSupportUpdate, which runs daily at 10AM and executes IntelDSA.exe with the dropped script.
Linux
Copies itself to ~/.config/intel-dsa/idriver_support.js and creates an @reboot cron entry.
macOS
Copies itself to ~/Library/Application Support/Intel DSA/idriver_support.js and creates the LaunchAgent com.intel.dsa.helper with RunAtLoad and KeepAlive enabled.
NodeRabbit RAT: the third variant
Further threat hunting identified a third NodeRabbit variant on a system in Ethiopia. Like the second variant, it is launched through the trojanized pretty-log package. It retains much of the previous variant’s functionality but introduces significant changes to its command-and-control configuration, command set, and persistence mechanisms.
The third variant communicates with its C2 infrastructure through a different set of API endpoints:
Method
Endpoint
Purpose
POST
/sdk/v2/ready
Register agent and host info
POST
/sdk/v2/config
Poll for commands
POST
/sdk/v2/events
Submit results
We observed the malware using a C2 chain composed of Azure- and Cloudflare-hosted domains.
For persistence, Variant 3 implements the following mechanisms depending on the operating system in use:
Operating system
Persistence mechanism
Windows
Attempts to copy the payload to ProgramData or LocalAppData, create a build-specific daily 10AM task, and start the copied payload. To choose the exact directory, it tries to list C:\Windows\System32\config. If successful, it selects ProgramData with /ru SYSTEM /rl highest; in case of a failure, it selects LocalAppData without explicit /ru or /rl settings.
macOS
Copies the payload to ~/Library/Application Support, creates and loads a RunAtLoad/KeepAlive LaunchAgent and starts the copied payload.
Linux
Copies the payload to ~/.local/share, attempts to add an @reboot cron entry, and starts the copied payload. If crontab -l fails, persistence is skipped.
WSL
Uses the payload copied for persistence on the main Linux system, as described above. Writes launcher.vbs under the Windows user profile, and creates a daily 10AM Windows task that relaunches it through wscript.exe and wsl.exe.
A new command, agent:servers, replaces the active in-memory C2 server list and can write the updated list to .sv.json. The third variant retains the original 11 commands and adds 12 new ones, bringing the total to 23.
New commands
Functionality
fs:drives
Enumerate accessible Windows drive letters or WSL-mounted drives
proc:exec
Execute a process
proc:kill
Kill process by PID or image name
agent:servers
Replace the active C2 and attempt to keep the new configuration
agent:getchain
Return the current C2
outlook:emails
Harvest account addresses from Outlook OST and PST artifacts
persist:check
Check selected VS Code, scheduled-task, and Run-key persistence indicators
persist:vscode
Attempt to install a fake VS Code extension and Windows Run value
persist:vscode:remove
Remove the fake extension
persist:projects:scan
Search recent and common development locations for Git repositories
persist:project:inject
Inject a launcher into a repository’s Git hooks
persist:project:remove
Remove the marked Git-hook launcher
Beyond the persistence mechanisms described above, Variant 3 introduces two additional persistence mechanisms that relaunch the malware through common developer workflows.
1. Malicious VS Code extension
The persist:vscode command first copies the payload to its build-specific install path. If a compatible extension directory exists, it creates a fake extension displayed as GitHub Copilot Helper, with the description AI coding assistant helper service and the activation event on StartupFinished.
The extension’s extension.js file attempts to start the installed payload as a detached Node.js process. To look less suspicious to the user, it uses a trusted publisher name borrowed from local extension metadata or a trustedPublishers value found in state.vscdb. However, no signature or trusted status is copied.
Separately, the handler tries to disable Workspace Trust if the VS Code User directory exists. On Windows, it attempts to establish persistence using a current-user Run registry key value even if the extension directory is missing.
2. Git hook injection
Git-hook persistence works in two steps. First, persist:projects:scan checks recent VS Code workspace paths directly. Under common locations such as ~/projects and ~/source, it checks only the first 60 immediate children, not the root itself, and returns no more than 20 repositories.
For a selected repository, persist:project:inject appends a marked launcher to .git/hooks/post-merge and .git/hooks/post-checkout by default. The marker is # shepherd-persist; the line following the marker attempts to start the installed payload with Node in the background. A later Git operation must trigger one of those hooks, and the referenced Node executable and payload must still exist.
PollCat RAT
While tracking NodeRabbit infections, we discovered another malicious tool we dubbed PollCat, which is also distributed under the guise of a programming challenge. The sample we obtained resides inside RankChallenge-react, a React code-fixing challenge presented as a time-limited developer assessment. Running the project invokes npm i && node index.js, which starts the local application and attempts to open the challenge in the user’s browser.
Although the visible exercise is not a security CTF, the project uses CTF terminology in several places. The root package is named ctf-server, the backend prints CTF server running, the frontend uses several ctf-* storage keys, and the tutorial refers to path/to/ctf. These repeated labels, together with instructions that do not fully match the delivered application, are consistent with an AI-assisted or template-generated project. One possible explanation is that the attacker prompted an AI coding assistant to create a CTF-style React platform and later inserted the malicious components.
README instructions and challenge overview included in the trojanized React coding project
The PDF tutorial contained in the same archive as the project tells the target to click Continue, enter a six-digit OTP code, and complete the challenge within a one-hour session. It states that codes are supplied by the recruiter, are single-use, and expire quickly; the visible login page also claims that codes rotate every 30 seconds. In the delivery scenario described by the investigation, the threat actor posing as a recruiter could provide the code directly to the targeted developer. This gives the operator control over access to the lure, while the expiring code and countdown create a sense of urgency, pressuring the target to run the project and complete the assessment quickly, potentially accelerating the infection process.
One-hour session window enforced by the trojanized coding challenge
The bundled .env file contains the JWT signing secret, OTP service URL, and OTP client ID.
Configuration embedded in .env file of the trojanized coding project, including the OTP service URL and client identifier
The application forwards submitted codes to an attacker-managed domain registered in late June-2026: https://lifespotify[.]com/api/users/b879746e-fed9-4211-a6da-4d8223681267/otp/validate.
That said, PollCat starts independently of the OTP authentication process. During application startup, app.js loads requireAuth.js, which imports and immediately starts the malicious requireObjects.js component. PollCat can therefore begin C2 registration and command polling while the application is still loading, before the user enters an access code.
A failed OTP validation prevents the user from accessing the protected challenge features, but PollCat continues running in the background. A successful OTP validation issues a JWT and creates another worker that starts an additional PollCat instance. The first authenticated request also triggers the persistence attempt.
Persistence starts when the first request carrying a valid JWT reaches the protected middleware. PollCat then uses one of the following methods:
Operation system
Persistence mechanism
Windows
Writes package.json and requireObject.js to %APPDATA%\Microsoft\Network, runs npm install, and creates a daily task named NetSync_<username> and scheduled for 09AM that runs the worker with Node.js.
Linux
Writes the worker to ~/.node_packages, runs npm i, and appends both a daily 09AM cron line and an @reboot line.
macOS
Uses the same ~/.node_packages copy and cron path, then creates and loads ~/Library/LaunchAgents/com.harsh.requireobject.plist with RunAtLoad and a daily 09AM trigger.
Once active, PollCat identifies the host as 129--<hostname> and iterates over the following C2s until registration succeeds:
After registration, PollCat sends host information to /gate/hello, polls /gate/fetch for commands, and returns results through /gate/submit. All endpoints in use are presented in the table below.
Method
Endpoint
Purpose
POST
/beacon
Register the client and obtain a socketId and optional timing values.
POST
/gate/hello
Submit host, user, domain, OS information, and its current privilege level.
GET
/gate/fetch?token=<socketId>
Poll for commands.
POST
/gate/submit
Submit a Base64-encoded command-result structure.
GET
/vault/<uuid>
Retrieve a hosted file and write it to the victim machine.
PUT
/vault/push/
Upload a local file or file chunk to the C2.
POST
/gate/track
Report chunk-upload progress.
By default, PollCat RAT polls every two minutes with up to five seconds of jitter. Commands and results are stored as little-endian binary records and carried as Base64 text.
PollCat RAT declares 22 commands, but three of them have no implementation:
Command
Functionality
0x02 (DIR)
List a directory.
0x03 (MV)
Move a file or directory.
0x04 (RUN)
Execute a shell command.
0x05 (TASKLIST)
List running processes.
0x06 (DEL)
Delete a file or directory.
0x07 (UPLOAD)
Download a file from the C2 to the victim’s machine.
0x08 (DOWNLOAD)
Upload a local file to the C2.
0X09 (DRIVES)
List drives, volumes, or mount points.
0X0A (TERMINATE)
Terminate a process by PID.
0X0B (RUNDLL)
Load a DLL and call an exported function on Windows.
0X0C (MKDIR)
Create a directory.
0X0D (ZIP)
Create or extract a ZIP archive.
0X0E (CHUNKED_DOWNLOAD)
Upload a local file in chunks.
0X0F (RUN_HIDDEN)
Start a hidden background process.
0X20 (EVAL_JS)
Execute JavaScript supplied by the C2.
0X30 (SYSTEM_CHECK)
Collect process and software inventory.
0XA1 (WS_DOWNLOAD)
Defined but not implemented.
0xB0 (REQUEST_ELEVATION)
Defined but not implemented.
0XB1 (PERSIST)
Defined but not implemented.
0xF0 (SET_SLEEP_TIME)
Change the polling interval.
0XF1 (SET_IDLE_TIME)
Store an idle-time value.
0xF2 (SET_JITTER_TIME)
Change polling jitter.
The command names UPLOAD, DOWNLOAD, and CHUNKED_DOWNLOAD are written from the C2’s perspective. UPLOAD sends a C2-hosted file to the victim’s machine, while the two download commands transfer victim files back to the C2.
EVAL_JS runs JavaScript supplied by the C2 and gives that code access to Node.js modules, files, processes, networking, and child-process functions. SYSTEM_CHECK collects the names of running processes and lists files and folders from:
%SystemDrive%\Program Files
%SystemDrive%\Program Files (x86)
%LOCALAPPDATA%
%LOCALAPPDATA%\Programs
%APPDATA%
%USERPROFILE%
%APPDATA%\Microsoft\Outlook
%LOCALAPPDATA%\Microsoft\Olk\Attachments
%USERPROFILE%\Documents
It also searches for folders matching 24 hardcoded strings corresponding to security software vendor names: ‘Google’, ‘Microsoft’, ‘Palo Alto Networks’, ‘Cisco’, ‘VMware’, ‘Fortinet’, ‘Citrix’, ‘CheckPoint’, ‘Juniper Networks’, ‘LogMeIn’, ‘Sophos’, ‘Symantec’, ‘Trend Micro’, ‘McAfee’, ‘Kaspersky Lab’, ‘ESET’, ‘Bitdefender’, ‘Avast Software’, ‘CrowdStrike’, ‘SentinelOne’, ‘Malwarebytes’, ‘BraveSoftware’, ‘Tencent’, and ‘Naver’.
When PollCat finds a matching folder, it lists that folder’s root contents. It does not recursively scan the entire product directory. The detailed inventory, including process names, directory listings, and collected paths, is sent as JSON to POST /api/system-details/result.
Infrastructure
Mirage Kitten continues to rely on Azure Websites and Cloudflare-backed domains to hinder infrastructure discovery and tracking. More importantly, the use of Microsoft Azure subdomains for C2 helps the traffic blend into legitimate organizational network activity. In some cases that we encountered during our research, the actors even incorporated the targeted organization’s name into the Azure subdomain, making C2 communications appear more like normal business traffic originating from an employee machine during regular business days.
Based on our analysis of Mirage Kitten’s infrastructure, we identified certain patterns across several command-and-control channels, including msmanagementgrp[.]com and visitfinancedentists[.]com
Further investigation based on these patterns led to the discovery of approximately 11 additional infrastructure assets attributed to the same group.
Domain
Creation date
Registrar
healthful-hub[.]com
2026-07-03
NameCheap, Inc.
neumedicahealthcare[.]com
2026-07-03
NameCheap, Inc.
optimumhealthcredit[.]com
2026-07-03
NameCheap, Inc.
healthfullyrecipes[.]com
2026-06-30
NameCheap, Inc.
refreshhealthandwellness[.]com
2026-06-09
NameCheap, Inc.
healthvitalitycare[.]com
2026-05-18
NameCheap, Inc.
aceofspadesmanagement[.]com
2026-05-18
NameCheap, Inc.
glmediaagency[.]com
2026-05-18
NameCheap, Inc.
digimediaskill[.]com
2026-05-18
NameCheap, Inc.
healthyweightplan[.]com
2026-05-18
NameCheap, Inc.
mens-health-online[.]com
2026-05-15
NameCheap, Inc.
Victims
Based on our telemetry, we identified victims in fintech, aviation and aerospace sectors across the Middle East and Africa – specifically, in Egypt, Ethiopia and Afghanistan.
We also observed submissions of ZIP archives with trojanized projects containing NodeRabbit and PollCat to an online multi-scanner originating from several countries, including India, Türkiye, Israel, Iraq, Germany, and Ireland.
Attribution
We attribute this activity to Mirage Kitten with a high degree of confidence based on the following observations:
Structural similarities with the Retrograde/MiniFast native DLL backdoor (MD5:810F8E3B88EB05F710C09552941D6F56)
Initial C2 handshake and session establishment logic. Both PollCat and Retrograde/MiniFast follow a similar C2 handshake flow. Each builds a JSON request body containing host information and sends it via an HTTP POST request. Notably, both treat HTTP 400 as a successful handshake response rather than an error, parsing the response body to extract a socketId, which is then stored and used as the session token for subsequent C2 communication.
Similar C2 handshake and socketId session establishment logic in MiniFast/Retrograde and PollCat
Host registration. Both PollCat and Retrograde/MiniFast register the infected host with the C2 server by sending a structurally similar JSON request body containing the session token and host information.
Command fetching similarities. The similarities extend to command retrieval. Both PollCat and Retrograde/MiniFast periodically poll the C2 server using an HTTP GET request containing the previously assigned socketId as a token. Retrograde/MiniFast uses GET /agent/poll?token=<socketId>, while PollCat follows the same pattern with GET /gate/fetch?token=<socketId>, demonstrating a closely aligned C2 communication structure.
Beacon timing similarities. PollCat and the Retrograde/MiniFast share identical beacon timing defaults: a polling interval of 120,000 ms (0x1D4C0), a jitter of 5,000 ms (0x1388), and a retry timeout of 60,000 ms (0xEA60). This further highlights the structural similarities between the two C2 communication implementations.
Command set similarities. PollCat and Retrograde/MiniFast share several commands and command IDs. Notably, PollCat declares REQUEST_ELEVATION (0xB0) and PERSIST (0xB1) but does not implement them. In MiniFast, both are functional: 0xB0 performs UAC elevation, while 0xB1 creates the WindowsSecurityUpdate scheduled task for persistence.
Command set similarities between MiniFast/Retrograde and PollCat, including shared command identifiers
Proxy authentication similarities. NodeRabbit delegates corporate-proxy NTLM/Negotiate authentication to curl.exe --proxy-anyauth --proxy-user, using the victim’s logon session. Retrograde/MiniFast native DLL implements the same approach natively through WinHttpQueryAuthSchemes and WinHttpSetCredentials with NULL credentials. This shared proxy-aware C2 design suggests the same development approach across both malware families.
Speaking of victimology, the attacks are consistent with Mirage Kitten’s known geographic targeting, with the group maintaining a strong focus on entities across Africa and the Middle East, this time with a particular focus on the aviation and FinTech sectors.
As for the operational infrastructure, Mirage Kitten has historically hosted its initial ZIP lures on legitimate third-party services. Previously, it used onlyoffice.com for this purpose. In this activity, the group shifted to Amazon S3 buckets.
Finally, the combination of Azure Websites and Cloudflare‑backed domains has been a hallmark of Mirage Kitten’s TTPs, which we have observed across NodeRabbit and PollCat.
Conclusions
Mirage Kitten’s latest activity marks a notable evolution in the group’s tooling: NodeRabbit and PollCat are the group’s first Node.js/JavaScript-based implants, departing from its usual native malware deployed through DLL search-order hijacking. The shift to cross-platform scripting gives the operators a single codebase that runs on Windows, Linux, and macOS, with payloads that blend naturally into developer workstations.
The delivery mechanism, however, remains consistent with Mirage Kitten’s historical tradecraft: the use of recruiter personas on LinkedIn to target critical sectors across the Middle East and Africa for cyberespionage purposes. We continue to track the group’s activity and will report on new developments in future publications.
Attackers typically try to pass off malware as legitimate applications or as potentially unwanted programs that users deliberately search for and download, such as cheats or cracks. They often rely on ad and affiliate networks to deliver their creations to victims’ devices. This post examines a less conventional case: a well-known backdoor distributed under the guise of adware. The attackers may have chosen this distribution method because the adware was signed by the developer. On top of that, users often manually add these apps to exclusions, so their useful features don’t get blocked.
Some time ago, a client asked us to analyze a file with the MD5 hash c24e99f9437feacaa63766a3cde3fe3d and add it to our detection database. We initially classified it as adware, but a cursory analysis turned up suspicious network activity, which prompted us to dig deeper. It turned out the sample did far more than serve ads. In fact, its advertising functionality doesn’t even work; instead, it triggers an infection chain that delivers the ValleyRAT backdoor.
Malicious installer
The file the client shared with us turned out to be an installer that performed different actions depending on the two-letter suffix used in the file name, positioned just before the numeric string.
Installer name
What it does
FS_SETUP_DD_173.exe
Installs DingTalk, a workplace collaboration platform
FS_SETUP_GG_173.exe
Installs Google Chrome
FS_SETUP_HY_173.exe
Opens hxxps://meeting[.]tencent[.]com/download/
These actions are most likely designed to divert the user’s attention away from the sample’s malicious functionality. Regardless of the file name, the installer deploys a modified Chinese desktop wallpaper management tool called QN Wallpaper (hxxps://qnwallpaper[.]keansoft[.]cn/) and adds it to the registry’s autorun entries.
The original version of QN Wallpaper is genuine adware: on installation, it delivers bundled partner apps to the device and then displays ad banners to the user. In this case, however, the attackers use it to carry out DLL sideloading, a technique that allows malicious code to run under the guise of a signed process by way of a malicious DLL.
The QN Wallpaper modules, along with the malicious components, are unpacked to C:\Program Files\QNWallpaper\5.4.0.1662\<random string of letters and digits>. The following files are saved in that directory:
File name
MD5
Purpose
1.zip
7ad1e3ef4e6d9d636c9e7e967733850e
Archive containing the adware files QnWallpeper.exe and QnwPlayer.exe, along with the modules needed to run them
7z.dll
96b4c1d0683dce22bd3223e1e40689c1
7z archiver library
7z.exe
9b86d3ab6cef15c633933fbbeab39c0a
Archiver
chrome_elf.dll
edfdc30cbd85879776b8f735ea7de1f1
Library used to launch Electron-based applications
libcef.dll
07ddbbe2c71c45577a7a4fbcdba0df91
Malicious library
PeLoader
48826d5ca845979d2e6ebd66dc1aae90
File containing the encrypted backdoor
QnWallpaper.exe
6c158c0f8e029342192d4f0d72e102b7
Adware module
QnwPlayer.exe
9a71d6a41cd258b9e89cdc5fc224de73
Adware module
<random string of letters and digits>Nedca.exe
c24e99f9437feacaa63766a3cde3fe3d
Malicious installer copy
After unpacking, the installer uses the DisableAntiSpyware registry key to disable Windows Defender and then launches QnWallpaper.exe.
Disabling Windows Defender
DLL Sideloading via libcef.dll
QnWallpaper.exe has dependencies in libcef.dll, so this library gets loaded when the process starts. QnWallpaper.exe also launches QnwPlayer.exe, which likewise calls libcef.dll.
QnWallpaper and QnwPlayer won’t actually function correctly, because the functions exported from libcef.dll are put into an infinite sleep. However, in case that sleep is ever interrupted, the attackers have implemented a function that loads all the necessary functions from the original library into memory, provided it can locate that library on the system.
Example of an exported function
Loading functions from the original libcef.dll
The malicious functionality in libcef.dll is invoked by a call to DllMain, which runs automatically when the library is loaded. That said, alongside the original exports, the library also contains a function named RunDLL, which likewise initiates execution of the malicious code. QnWallpaper never calls this function. We suspect the attackers intended to invoke it manually via rundll32 or planned to use a separate executable for this purpose, one that wasn’t included in the package downloaded by the sample.
The RunDLL function
Running the malicious code
When the library is loaded, code runs that ensures QnWallpaper.exe persists at startup: it adds a file extension association and drops a file with the corresponding extension in C:\Documents and Settings\<username>\Start Menu\Programs\Startup\.
This is followed by a chain of wrapper functions whose main job is to call the next one. Execution eventually reaches the function that contains the actual malicious code. For convenience, we’ll refer to it as mw_entry.
Inside mw_entry, the malware checks two things:
Whether the current user belongs to the Administrators group
Which process the DLL is running inside
Checking for administrator privileges
If the user isn’t a member of the Administrators group, the program attempts to obtain administrator privileges by using the runas utility.
Relaunching the process to obtain administrator privileges
Once it has administrator privileges, the malicious code determines which process the DLL has been loaded into, and selects the payload accordingly:
If the library is running inside QnWallpaper.exe, the payload is loaded from the PeLoader file.
Encrypted payload
If the library is running inside QnwPlayer.exe, the payload is loaded from libcef.dll resources.
Retrieving the payload from a resource
Both payloads are AES-encrypted DLLs that contain the ValleyRAT backdoor. The only difference between them is their configuration, specifically, the C2 server addresses. After decryption, libcef.dll checks the magic signatures in the resulting PE file’s headers to confirm the sample is valid. If this check fails, the library releases its resources and takes no further action.
Validating the PE file headers after decryption
If the headers check out, libcef.dll loads the payload into the process’s memory space and hands control over to the backdoor by calling DllMain.
Calling DllMain
ValleyRAT
ValleyRAT begins its operation by parsing its configuration, which consists of key:value pairs concatenated into a single string. To obfuscate this configuration, the attackers wrote the string in reverse.
Obfuscated configuration
During parsing, the backdoor restores the correct character order and reads the key values one by one. The set of keys is the same regardless of which process the backdoor is running in.
Parsing the configuration
Some of the configuration fields are listed below:
Key
Description
p?
C2 server IP address
o?
C2 server port
t?
Protocol (1: TCP, 0: UDP)
dd
Sleep duration before executing the main code
cl
Sleep duration after receiving the corresponding command from the server
bz
Configuration creation date
bh
Whether to mark the current process as critical (so that terminating it triggers a blue screen of death) Possible values: 1: yes, 0: no
ll
Whether to check for running security/traffic-analysis tools/processes (1: check, 0: do not check)
sh
Whether to inject code into svchost that will restart the malicious process (1: inject, 0: do not inject)
The backdoor uses several techniques to protect its process. Some are configuration-dependent, while others are always applied:
Injecting code into svchost to restart the process: a configurable option. The backdoor allocates memory inside the svchost process, injects code into it, and sets PAGE_NOACCESS permissions on the memory page containing the injected data. It then creates a suspended thread, waits 60 seconds, grants read, write, and execute permissions on the page, and resumes the thread.
Injecting code into svchost
The function injected into the process has a single job: restart the backdoor if its execution is interrupted for any reason.
Injected function
Marking its own process as critical (so that terminating it triggers a blue screen of death): a configurable option.
Setting its own process as critical
Restarting on an unhandled exception. This protection mechanism is always active, regardless of the backdoor’s configuration.
Restarting on exceptions
The backdoor also has spyware functionality. While running, it tracks keystrokes and the currently focused window by using functions from the DirectInput8 library. It also captures clipboard contents. All collected data is saved to a file on disk.
Capturing clipboard data
If the ll key in the configuration is set to 1, ValleyRAT periodically checks for active windows belonging to applications that could be used to analyze processes or traffic. Window enumeration is done via the EnumWindows function, using the following callback:
Window name checks
After completing these checks, the backdoor collects system information, including:
Host name
Host IP addresses
User idle time
Detailed Windows version information (ProductName, EditionId, DisplayVersion)
Number of CPU cores
Free disk space
Graphics adapter
Currently focused window and its title
System bitness
Language settings
Path to the system directory
On command, the backdoor can perform the actions typical of this malware category:
Rebooting the computer
Shutting down the computer
Taking a screenshot
Wiping logs
Updating its C2 addresses
Downloading additional modules
Sending keylogger logs along with clipboard contents
Snippet of the command handler
Let’s take a closer look at the module-loading functionality. Upon receiving the corresponding command with a link from its operator, the backdoor downloads the file at that link and executes it. The download can come from either the C2 server or a third-party address.
The DownloadPeFile function is responsible for downloading a PE file
The DownloadAndExecute function calls DownloadPeFile, then launches the downloaded module
Additional modules can take the form of purpose-built dynamic libraries or shellcode. If the payload is shellcode, the backdoor uses process hollowing with svchost to launch the module.
Implementation of the process hollowing technique
If the module is a dynamic library, the backdoor loads the PE file into its own process, calls DllMain, and searches for a Main function among the exported functions. Once Main has been called, the library is unloaded from memory.
Calling DllMain after the backdoor loads the PE file
Targets and attribution
Over the course of 2026, we detected the ValleyRAT backdoor and its associated malware more than 100,000 times, with more than 1500 unique users affected, primarily in China and India.
This attack geography, combined with the use of the ValleyRAT backdoor, points to Silver Fox, a known operator of this malware family, as the likely group behind the campaign.
Conclusion
This case is a clear example of how adware and affiliate networks can turn out to be far more dangerous than they appear. ValleyRAT is a sophisticated backdoor capable of collecting sensitive data such as keystrokes and clipboard contents, taking screenshots, and delivering additional malicious modules. The attackers exploited a well-known adware application to run the backdoor under the guise of a signed process, which complicates detection.
Motivated by both cyberespionage and financial gain, Silver Fox targets organizations across multiple countries. To stay protected, organizations should keep employee cybersecurity awareness up to date and enforce clear policies on the use of third-party software on work devices.
For individual users, we recommend avoiding the installation of software with a questionable reputation, and, even more importantly, never adding such software to your security solutions’ exclusion lists.
Overview AhnLab monitored APT (Advanced Persistent Threat) attacks targeting entities in Korea using its own infrastructure. This report summarizes the classification, statistics, and functional characteristics for each type of domestic APT attacks identified during the month of July 2026. Trends of APT Attacks in South Korea Most APT attacks detected in South Korea were distributed […]
CoolClient is a backdoor family attributed to the HoneyMyte APT group (also known as Mustang Panda) that has been used in their cyber-espionage campaigns targeting organizations across Asia and Russia. It supports such capabilities as keylogging, clipboard theft, credential harvesting, file management, system reconnaissance, and plugin-based extensions.
Since its first public disclosure by Sophos in 2022 and subsequent analysis by Trend Micro in 2023, CoolClient has continued to evolve. In 2025, we analyzed a newer variant that introduced clipboard theft and HTTP traffic interception for credential harvesting.
In late 2025 and 2026, our latest investigation reveal another major evolution. The newest CoolClient variant can deploy a signed kernel-mode driver as a Windows service and communicate with it through IOCTL requests. The driver enhances the malware’s stealth by hiding the CoolClient process, protecting related files and registry entries, and preventing them from being inspected or modified. The overall design is comparable to the kernel-mode enhancements previously observed in ToneShell, but the CoolClient driver exposes dedicated IOCTL handlers that allow the user-mode backdoor to communicate directly with the driver.
We have observed this updated CoolClient variant and its accompanying driver in intrusions across multiple countries in Asia, including Pakistan, Mongolia, and Myanmar.
Technical analysis
In the observed campaign targeting Myanmar, HoneyMyte used PlugX as the initial post-compromise implant to deploy the CoolClient components. Before deploying the malware, the actor added both a folder exclusion and a file exclusion to Microsoft Defender for the fake Windows Defender installation directory and the renamed sideloader executable (defender.exe).
The actor then created a fake Windows Defender installation directory, copied the CoolClient components into it, and renamed a legitimate Sangfor executable, usually named Sang.exe, to defender.exe to serve as the DLL sideloader.
When executed, defender.exe sideloads the malicious libngs.dll, initiating the CoolClient execution chain described in the following sections.
CoolClient components
Similar to previous variants, the latest CoolClient user-mode component follows a multi-stage execution chain, with each component performing a distinct role during execution.
Component
Description
defender.exe / Sang.exe
Legitimate Sangfor application abused for DLL sideloading
libsrapc.dll
Benign dependency required for the Sangfor application to execute normally
libngs.dll
First-stage loader that decrypts and loads the next stage into memory (First stage)
loadcert.ini
Encrypted DLL implementing the core CoolClient functionality, including command handling, process injection, driver deployment, and persistence (Second stage)
cert.ini
Final-stage implant responsible for C2 communication and backdoor functionality (Final stage)
time.ini
CoolCleint configuration file
Our previous CoolClient analysis focused primarily on the final-stage implant (main.dat), including its backdoor commands and plugin framework, while the first-stage loader (libngs.dll) and second-stage component (loader.dat) received only a brief overview. In the latest variant CoolClient, loader.dat and main.dat have been renamed to loadcert.ini and cert.ini, respectively. This article revisits those earlier stages, focusing on the second-stage component and the newly introduced kernel-mode driver that extends CoolClient with rootkit capabilities.
Overview of the new variant of CoolClient
First stage: libngs.dll
Execution begins when the legitimate Sangfor application (defender.exe or Sang.exe) loads the malicious libngs.dll through DLL sideloading. As in previous CoolClient variants, the malware continues to abuse the same Sangfor application to execute its first-stage loader.
To make the DLL appear legitimate, libngs.dll exports numerous dummy functions. Each export simply calls OutputDebugStringA with its corresponding function name before immediately invoking ExitProcess, serving no functional purpose other than mimicking the expected export table of the legitimate DLL.
Dummy export functions in libngs.dll invoking OutputDebugStringA and ExitProcess
The actual malicious logic is executed from DllMain (DllEntryPoint). Although heavily obfuscated through control flow flattening and numerous unconditional jumps, the routine ultimately performs a straightforward task: loading, decrypting, and executing the encrypted second-stage DLL, loadcert.ini.
The loader resolves the required Windows APIs, reads loadcert.ini into memory, and decrypts it using a 0x32-byte repeating XOR keystream derived from a transformed seed value of 0xA4. After decryption, the DLL is loaded directly into memory, and execution is transferred to loadcert.ini.
Second stage: loadcert.ini (before synchost.exe injection)
The second-stage DLL, loadcert.ini, is responsible for preparing the execution environment before the malware transitions into its injected process. It first determines its execution context by checking whether the current module is synchost.exe.
If the DLL is running under the original sideloaded process (for example, Sang.exe), it performs the initial setup, including persistence, UAC bypass, registry modifications, and process injection.
If the DLL is already executing inside synchost.exe, it follows a different execution path that decrypts time.ini, deploys the kernel-mode driver, and loads the final-stage implant (cert.ini).
Command handler
The command handler remains largely unchanged from previous CoolClient variants, with one notable difference: the malware now injects into synchost.exe instead of write.exe.
Execution is controlled through three command-line parameters:
Parameter
Purpose
install
Performs the initial setup, including persistence, privilege checks, and preparation for the injected execution path.
work
Executes the primary second-stage functionality from the injected synchost.exe process, including driver deployment and third-stage loading.
passuac
Continues execution after privilege elevation.
If no parameter is supplied, the malware creates a new Sang.exe process with the install parameter using CreateProcessW.
Establishing AutoRun persistence
When executed with the install parameter, CoolClient creates an AutoRun entry under:
The registry value, named goopdate, launches Sang.exe (or defender.exe, depending on the deployment) with the work parameter whenever the user logs on.
Process injection into synchost.exe
Upon establishing the AutoRun registry entry, CoolClient decrypts loadcert.ini using a 0x32-byte repeating XOR keystream derived from the hardcoded base key 0x4D.
The decrypted DLL is then injected into a newly created suspended instance of synchost.exe. The malware allocates memory in the target process, writes the decrypted payload, redirects the thread context to the injected code, resumes execution, and finally terminates the original process with ExitProcess.
From this point onward, execution continues entirely within synchost.exe, where the malware proceeds with kernel-mode driver deployment before loading the final-stage implant (cert.ini).
Service installation
When executed with the install parameter, CoolClient establishes an additional persistence mechanism by installing itself as a Windows service. Before doing so, it verifies that it has sufficient access to the Service Control Manager and that no 360 Total Security software processes (360sd.exe, zhudongfangyu.exe, or 360desktopservice64.exe) are running.
Function to check for running 360 Total Security software processes
If both checks succeed, the malware decrypts time.ini to retrieve the service configuration, including the service name and description. It then checks whether the service media_updaten already exists. If found, the existing service is stopped and deleted before a new one is created.
The new service is configured to execute Sang.exe<.code> with the work parameter using CreateServiceA. The malware then starts the service by executing "sc start media_updaten" via WinExec.
Administrator privilege check
If the service installation path is not taken, CoolClient checks whether the current process is running with administrator privileges by verifying membership in the local Administrators group.
When administrative privileges are available, the malware relaunches itself with the passuac parameter before continuing with the remaining execution flow.
Elevated relaunch and UAC bypass
To continue execution with elevated privileges while concealing its true parent process, CoolClient implements an RPC-based process creation technique similar to the method described by Google Project Zero. The technique combines RPC process creation with parent process ID (PPID) spoofing to launch a new elevated instance of itself.
The malware first checks for the presence of escanmon.exe. If the process is running, it constructs the path to C:\Windows\System32\winver.exe and establishes a connection to the local ncalrpc endpoint (201ef99a-7fa0-444c-9399-19ba84f12a1a). It then invokes NdrAsyncClientCall to launch winver.exe through the RPC interface.
Authenticated RPC binding used during the RPC-based UAC bypass
After winver.exe is created, CoolClient retrieves its debug object using NtQueryInformationProcess, detaches the debugger through NtRemoveProcessDebug, and terminates the process. The obtained debug object is later reused during the remainder of the UAC bypass routine.
Next, the malware repeats the same RPC-based process creation technique to launch computerdefaults.exe. It associates the previously obtained debug object with the current thread using DbgUiSetThreadDebugObject, waits for the resulting process creation event through WaitForDebugEvent, and duplicates the process handle using NtDuplicateObject, obtaining a handle with full access rights.
Finally, CoolClient relaunches itself as Sang.exe passuac using CreateProcessW with an extended startup attribute list. By configuring PROC_THREAD_ATTRIBUTE_PARENT_PROCESS through UpdateProcThreadAttribute, the duplicated process handle is assigned as the parent of the new process. As a result, the new Sang.exe passuac instance executes with an elevated context while appearing to have been spawned by the trusted Windows process instead of the original CoolClient process.
Second stage: loadcert.ini (Injected Execution)
After being injected into synchost.exe, loadcert.ini follows its injected execution path, where it deploys the kernel-mode driver and launches the final-stage implant (cert.ini). If administrative privileges are unavailable, the malware skips driver deployment and proceeds directly to the third-stage injection.
Kernel-Mode driver deployment
The deployment routine begins by decrypting time.ini. CoolClient then verifies that it has sufficient privileges to install a kernel-mode driver by checking for full access to the Service Control Manager (SCM) and the presence of SeTcbPrivilege.
If both conditions are met, CoolClient extracts an embedded LZMA-compressed driver from loadcert.ini, decompresses it, and writes it to disk as msagent.sys in the same directory as cert.ini, for example:
Next, the malware checks whether a service named msagent already exists. If present, the existing service is stopped and deleted before a new driver service is created and started, loading the kernel-mode component into the operating system.
Driver initialization
After the driver is loaded, CoolClient establishes communication with it by opening the device \\.\msagent using CreateFileW. The user-mode component then initializes the driver by issuing three DeviceIoControl requests.
IOCTL
Purpose
0x222120
Registers the current CoolClient process with the driver.
0x2221E0
Sends the configured C2 IPv4 address to the driver.
0x2220F0
Registers filesystem and registry paths that should be protected or hidden.
The first request (0x222120) registers the current CoolClient process as a trusted process within the driver. The request includes the process ID, an operation code, and a flag that marks the process as trusted, allowing it to interact with protected files, registry keys, and processes.
The second request (0x2221E0) passes the configured C2 IPv4 address extracted from time.ini.
Finally, 0x2220F0 registers the CoolClient installation directory (for example, C:\Program Files\Microsoft\Windows Defender\) together with the service registry path (\Registry\Machine\SYSTEM\CurrentControlSet\Services\media_updaten). These entries allow the driver to protect the malware’s files and registry objects from inspection, modification, and deletion.
As part of the initialization, CoolClient updates the HKLM\SYSTEM\RNG\Wid_H1deF5Dirs registry value by appending its installation directory if it is not already present. This registry value is later used by the driver when applying its hiding and protection mechanisms.
The implementation of these IOCTL handlers and the corresponding driver functionality are discussed in the msagent.sys section.
Cert.ini process injection
Once the driver has been initialized, CoolClient proceeds to launch the final-stage implant (cert.ini). Before creating the target process, the malware enumerates active WinStation sessions to identify a suitable interactive user session.
After selecting a session, CoolClient duplicates its access token, updates the session identifier, and creates a new synchost.exe process using CreateProcessAsUserA. The decrypted cert.ini DLL is then injected into the suspended process using the same memory allocation, thread context modification, and ResumeThread technique described earlier.
This marks the final transition in the execution chain, where the third-stage implant takes over C2 communication and the remaining backdoor functionality.
Msagent.sys driver
Analysis of the deployed kernel-mode driver reveals an embedded PDB path:
The path contains several notable strings, including “Nanjing Laboratory” (南京实验室) and “Zhang Xuejie Yunnan m” (张雪杰云南m), which likely refer to the driver’s development environment. However, our OSINT analysis did not identify any information linking these strings to a known organization, developer, or threat actor.
The driver is digitally signed with a certificate issued to "Nanjing Ranyi Technology Co., Ltd.", with serial number 3E 62 DC 5D 8D 61 2A 26 33 E7 6B DF D6 07 19 DD. The certificate was valid from August 2013 to September 2014.
We identified several older malicious drivers signed with the same certificate that were compiled around 2013. However, we found no evidence directly linking those samples to the CoolClient activity described in this article.
Driver configuration
During initialization, the driver loads its stealth configuration from the registry key \REGISTRY\MACHINE\SYSTEM\RNG. The configuration defines which system objects should be hidden or protected and controls the driver’s operating mode.
Registry configuration loaded by the driver during initialization
Two REG_DWORD values control the driver’s operating mode:
Registry Value
Default
Description
Hid_State
1
Enables the driver’s rootkit functionality.
Hid_StealthMode
0
Controls additional stealth features used by selected driver routines.
In addition, the driver loads several REG_MULTI_SZ values that define the objects to be hidden or protected.
Registry Value
Purpose
Wid_H1deF5Dirs
Directories to hide
Wid_H1deF5Files
Files to hide
Wid_H1deRegKeys
Registry keys to hide
Wid_H1deRegValues
Registry values to hide
Hid_IgnoredImages
Processes to ignore
Hid_ProtectedImages
Processes to protect
Together, these registry values determine which filesystem paths, registry objects, and processes are managed by the driver’s protection mechanisms.
After loading the configuration, the driver converts the registry entries into internal lookup structures that are shared across its various protection components.
These structures are later referenced by the filesystem minifilter, registry callback, process callback, object callback, image load callback, and IOCTL handlers to determine whether a file, registry object, or process should be hidden, protected, or ignored.
Preparation for process hiding
Next, the driver dynamically locates the ActiveProcessLinks (LIST_ENTRY) field within the EPROCESS structure instead of relying on hardcoded offsets. It first validates several predefined offsets and, if none match, performs a linear scan of the EPROCESS structure to identify the correct location. This approach allows the driver to remain compatible across different Windows versions, where the layout of EPROCESS may differ.
The driver validates candidate ActiveProcessLinks layouts before enabling process hiding
Once the correct offset has been identified, it is stored for later use by the process hiding routines. During process hiding and restoration, the driver uses IOCTLs 0x22219C and 0x2221A0 to unlink and relink entries in the Windows active process list, effectively hiding or restoring processes on demand.
Process, object, and image load callbacks
After preparing its process tracking structures, the driver initializes several AVL trees and populates them with configuration entries loaded from the registry, including Wid_H1deF5Dirs, Wid_H1deF5Files, Wid_H1deRegKeys, Wid_H1deRegValues, Hid_IgnoredImages, Hid_ProtectedImages, and Hid_HideImages.
These AVL trees provide efficient lookups for protected files, registry objects, and tracked processes, and are shared by the callback routines and IOCTL handlers.
The driver then registers three types of kernel callbacks that form the foundation of its protection and monitoring mechanisms:
Object callbacks using ObRegisterCallbacks
Process creation and termination callbacks using PsSetCreateProcessNotifyRoutineEx
Image load callbacks using PsSetLoadImageNotifyRoutine
Registration of object, process, and image load callbacks during driver initialization
After registration, these callbacks maintain the driver’s internal tracking structures as processes, threads, and images are created or loaded.
Object callbacks
To protect selected processes, the driver registers object callbacks for process (PsProcessType) and thread (PsThreadType) objects using ObRegisterCallbacks with an altitude of 1203. These callbacks intercept requests to open process and thread handles. If the target process is protected, the driver reduces the access rights granted to the requesting process, preventing operations such as process termination, code injection, and other forms of process manipulation. In this sample, the protected process is the injected CoolClient code running inside synchost.exe.
Process and image load callbacks
The driver registers process creation and termination callbacks using PsSetCreateProcessNotifyRoutineEx, together with an image load callback via PsSetLoadImageNotifyRoutine.
When a process is created, its image name is compared against the configuration lists Hid_IgnoredImages, Hid_ProtectedImages, and Hid_HideImages. Matching processes are added to the driver’s internal tracking structures, allowing them to be protected, hidden, or managed through subsequent IOCTL requests. When a tracked process terminates, its entry is removed from the tracking structures.
The image load callback monitors modules loaded into tracked processes and updates the driver’s internal state to support subsequent protection and hiding operations.
To ensure that processes already running before the driver is initialized are also tracked, the driver performs a one-time enumeration of all active processes after registering the callbacks and adds any matching processes to the tracking structures.
MiniFilter registration
To protect files and directories, the driver registers a filesystem minifilter. During initialization, it creates internal path filter lists, loads the configured directory and file entries (Wid_H1deF5Dirs and Wid_H1deF5Files), and creates the required minifilter registry entries under HKLM\SYSTEM\CurrentControlSet\Services\msagent\Instances. To avoid altitude conflicts, the driver dynamically assigns a filter altitude and retries registration until a unique value is obtained.
Retrying minifilter registration with incrementing filter altitude values until FltRegisterFilter succeeds
The driver then activates the minifilter using FltRegisterFilter. The filter works together with the IOCTL interface, which dynamically adds, removes, or clears protected path entries (0x2220F0, 0x2220F4, and 0x2220F8). During filesystem operations, the minifilter compares accessed paths against its internal path lists and denies access to matching entries, effectively hiding protected files and directories from users and applications.
Registry callback registration
To protect registry keys and values, the driver registers a registry callback using CmRegisterCallbackEx with an altitude of 320000. During initialization, it creates separate lookup structures for protected registry keys and values, then populates them using the configured entries from Wid_H1deRegKeys and Wid_H1deRegValues.
Registration of the registry callback using CmRegisterCallbackEx with an altitude of 320000
Once registered, the callback intercepts registry operations and compares the target key or value against the protected entries. For enumeration requests, matching keys and values are removed from the results before they are returned to user mode, effectively hiding them from registry viewers. For direct access requests, such as opening, modifying, or deleting protected registry objects, the callback returns STATUS_ACCESS_DENIED, preventing the operation.
Before applying these restrictions, the driver verifies whether the requesting process is trusted. Processes registered through IOCTL 0x222120, including the CoolClient user-mode component, bypass the filtering logic and retain unrestricted access, while all other processes remain subject to the driver’s registry protection rules.
IOCTL command dispatcher
To communicate with the user-mode component, the driver creates a device object named \Device\ToolTool together with the symbolic link \DosDevices\ToolTool to allow the user-mode CoolClient component to communicate with the driver through DeviceIoControl requests.
The driver implements 33 IOCTL handlers, although the analyzed CoolClient sample uses only three during normal execution:
0x222120: registers the current CoolClient process with the driver.
0x2221E0: passes the configured C2 IPv4 address.
0x2220F0: registers filesystem and registry paths for protection.
The remaining IOCTL handlers were not invoked by the analyzed sample.
IOCTL
Handler
Functionality
0x222000
0x140001E04
Enable or disable the rootkit.
0x222004
0x1400020B0
Query the current rootkit state.
0x2220F0
0x140002320
● Register protected filesystem or registry paths
● Used by CoolClient to register its installation directory and service registry key.
0x2220F4
0x1400034DC
Remove a protected filesystem or registry path.
0x2220F8
0x140003464
Clear all protected filesystem and registry path entries.
0x222118
0x1400024B0
Register process or path protection entries.
0x22211C
0x140002A20
Query registered protection entries.
0x222120
0x140003794
Update process protection entries. Used by CoolClient to register itself as a trusted process.
0x222124
0x14000362C
Remove a protection entry.
0x222128
0x14000349C
Clear all process protection entries.
0x222130
0x14000265C
Register a protected process by PID.
0x222134
0x140010E88
Inject shellcode into a target process using NtCreateThreadEx.
0x222138
0x14000F498
Hide a kernel module by unlinking it from PsLoadedModuleList.
0x222144
0x14000270C
Delete a file.
0x222148
0x14000286C
Decrypt an embedded buffer and write it to disk.
0x22214C
0x1400027F4
Read and decrypt an encrypted file.
0x222168
0x140002780
Unmap the image section of a target process.
0x22216C
0x140013984
Terminate a process by PID.
0x222194
0x140011F50
Remove Protected Process Light (PPL) protection.
0x222198
0x140002940
Create or modify a registry value.
0x22219C
0x140010630
Hide a process by unlinking it from the active process list.
0x2221A0
0x140010670
Restore a previously hidden process.
0x2221A4
0x14000F8A0
Hide a module within a process.
0x2221A8
0x14000F954
Restore a hidden module.
0x2221AC
0x140016368
Enumerate and restore kernel notification callbacks.
0x2221B0
0x140016458
Disable or restore kernel notification callbacks.
0x2221B4
0x140012408
Manually load a secondary kernel driver.
0x2221B8
0x14001262C
Debug/test handler.
0x2221BC
0x1400165F6
Write to an arbitrary kernel address.
0x2221C0
0x14000BB00, 0x14000BB78
Enables deny-rootkit mode by registering image-load monitoring and enabling the patching logic.
0x2221C4
0x14000BB6C, 0x14000BB10
Disables deny-rootkit mode by clearing state and unregistering/removing the monitoring logic.
0x2221E0
0x1400126C0
Register a C2 IPv4 address.
0x2221E4
0x140012E50
Delete a C2 IPv4 address.
After initializing the IOCTL dispatcher, the driver releases the temporary configuration buffer that was previously loaded from \REGISTRY\MACHINE\SYSTEM\RNG.
Kernel module enumeration and hiding
To support kernel module hiding, the driver resolves the address of the non-exported kernel variable PsLoadedModuleList at runtime using MmGetSystemRoutineAddress. This global linked list maintains information about all loaded kernel modules and drivers, allowing the rootkit to enumerate and manipulate module entries.
Driver initialization routine resolving the address of PsLoadedModuleList for subsequent kernel module hiding
This functionality is exposed through IOCTL 0x222138, which accepts a module name or path from the user-mode component. When a matching module is found, the driver locates the corresponding entry in PsLoadedModuleList and unlinks it by updating its Flink and Blink pointers. As a result, the hidden module no longer appears in standard kernel module enumeration routines.
Nsiproxy hooking and data filtering
The driver also hooks the Nsiproxy driver to filter network-related data returned to user mode. This functionality is connected to IOCTL 0x2221E0, which allows the user-mode component to register C2 IPv4 addresses with the driver.
To install the hook, the driver obtains a reference to \Driver\Nsiproxy using ObReferenceObjectByName and replaces one of the Nsiproxy handler pointers with its own filtering routine. The hook preserves the original handler and forwards execution after processing the returned data.
Installing the Nsiproxy hook by resolving \Driver\Nsiproxy and replacing the original handler with the driver’s filtering routine
When the hooked routine processes network information, the driver compares the returned entries against its registered C2 address list. Matching IP addresses are removed before the data is returned to user mode, preventing applications that rely on Nsiproxy-provided network information from seeing the malware’s C2 addresses.
Finally, the driver registers a DriverUnload routine to release allocated resources when the driver is unloaded.
Victimology
The latest CoolClient variant continues to target organizations consistent with previously observed HoneyMyte activity. Based on our investigations, we identified victims in Myanmar, Mongolia, Pakistan, and Russia, including confirmed government entities.
Across the observed intrusions, CoolClient was consistently deployed as a secondary backdoor following a PlugX infection, indicating that HoneyMyte continues to use PlugX as its initial post-compromise implant before transitioning to CoolClient.
Attribution
Our analysis confirms that the investigated malware is a new CoolClient variant associated with the HoneyMyte threat group. While the overall execution flow remains consistent with previously documented CoolClient variants, this sample introduces a previously undocumented kernel-mode driver that significantly expands the malware’s stealth capabilities.
The deployment chain observed in this investigation is also consistent with previous HoneyMyte campaigns, in which PlugX serves as the initial foothold before CoolClient is deployed as a secondary backdoor, further reinforcing the attribution.
Conclusion
The latest CoolClient variant represents a significant evolution of the malware. Rather than operating solely as a user-mode backdoor with plugin support, it now deploys and communicates with a kernel-mode driver that extends its capabilities beyond earlier versions. Through this driver, CoolClient can hide and protect processes, files, and registry objects, as well as filter selected network information, making detection and analysis considerably more difficult.
HoneyMyte has previously introduced kernel-mode functionality in ToneShell. The addition of a kernel-mode driver to CoolClient suggests that the group continues to expand its use of rootkit capabilities to improve stealth, persistence, and defense evasion during post-compromise operations.
In July 2026, Kaspersky experts detected a new attack by the Head Mare group. Previously, we classified them as hacktivists, but now we define them as an APT group due to the sophistication of their TTPs and the absence of destructive activity (encryption, wiping) in the targeted infrastructures. In this latest campaign, the attackers exploited a chain of vulnerabilities in the TrueConf video conferencing server and replaced the original TrueConf client installers with infected versions that installed the PhantomCore malware on the system.
An investigation of the compromised server revealed that the attackers used a combination of two new vulnerabilities (assigned the internal identifiers KLCERT-26-057 and KLCERT-26-058), allowing them to execute arbitrary code with the highest privileges.
The attack occurs in several stages:
The attackers connect to the TrueConf server without prior authorization via port 4307/TCP, which, according to the product documentation, is open by default. The attack targets TrueConf servers running versions 5.3.X through 5.3.9, 5.4.X through 5.4.9, and 5.5.X through 5.5.5.
Once connected, attackers call a server function to transmit a malicious script and execute it on the server. The vulnerability that allows this stage of the attack to be carried out has been assigned the internal identifier KLCERT-26-057.
The received script runs on the TrueConf server in an isolated environment. By default, operating system functions are not accessible in this environment, which should limit the capabilities of the executed code.
To escape the isolated environment, attackers exploit a second vulnerability, assigned the internal identifier KLCERT-26-058. Exploiting this vulnerability allows them to bypass the restrictions of the isolated environment and proceed to execute commands in the context of the operating system.
Once the environment’s restrictions are bypassed, attackers gain the ability to execute arbitrary code on the server with the privileges of the NT AUTHORITY\SYSTEM account.
Once they have gained elevated privileges, attackers replace the file …\public\js\locale.php with a web shell, which can be used for subsequent remote control of the compromised server.
This web shell was used for the following activities:
collecting data on the IT infrastructure;
gaining privileged access to the TrueConf database;
replacing the original TrueConf Client distribution with an infected version containing the PhantomCore backdoor.
The vulnerabilities exploited by the attackers were patched by the vendor in the latest TrueConf Server updates (versions 5.3.9, 5.4.9, and 5.5.5). These updates were released on June 18, 2026.
The PhantomCore backdoor was successfully detected by Kaspersky solutions.
To automatically launch the malware after the system boots, a registry key is created: HKEY_CURRENT_USER\Software\Classes\CLSID\{0340F119-A598-4ed9-B0AC-6F6A12D3E755}\InprocServer32, with the value set to the path to the malicious program’s file.
Using a web shell, in addition to PhantomCore, the attackers load a backdoor that we have named PhantomGraph, consisting of two modules:
SysExcSvc.dll is responsible for receiving commands from the attackers and transmitting the results of their execution. The attackers used an account on Microsoft OneDrive cloud storage as their command-and-control (C2) server.
SysReadSvc.dll reads the command transmitted by the first module, executes it, and saves the execution result.
To establish persistence on the system, the attackers execute a Base64-encoded PowerShell command that installs SysExcSvc.dll and SysReadSvc.dll as Windows services. We believe the attackers deliberately split this malicious command into two components to make it harder to detect using EDR tools. Additionally, the program’s code partially matches that of PhantomCore, indicating that it belongs to Head Mare’s arsenal.
We also managed to identify the commands executed by the attackers when connecting to the backdoor. The SysReadSvc module executes commands using a BATCH file. Example of execution:
In addition, we discovered several commands that did not work due to the attackers’ typos and encoding issues.
We are observing several active Head Mare campaigns targeting Russian organizations across various industries: instrument manufacturing, electronics, transportation, energy,
IT, and software development. The attackers distribute their backdoors using various methods, including phishing, exploiting public web servers, or through a subcontractor.
We recommend that all organizations using TrueConf software install the latest server version (versions 5.3.9, 5.4.9, and 5.5.5) in accordance with the vendor’s recommendations.
We also recommend verifying that the client distributions downloaded from the TrueConf server used by your organization have a valid TrueConf digital signature and have not been tampered with. The malicious distributions we detected did not have a valid digital signature. You can also verify authenticity on the vendor’s website.
Important: Even if your organization does not use a TrueConf server, your employees may connect to compromised TrueConf servers belonging to business partners to participate in online meetings and download infected installation packages.
Specifically, activity involving the replacement of the legitimate file …\public\js\locale.php with a web shell, as well as the deletion of entries from TrueConf event logs, is detected by the rule unusual_php_file_creation_from_trueconf_process.
Downloading a file containing the PhantomCore backdoor via the replaced legitimate file …\public\js\locale.php is detected by KEDR Expert with the rule unusual_file_creation_from_trueconf.
Activity related to the installation of an infected TrueConf client installer containing the PhantomCore backdoor is detected by KEDR Expert using the unsigned_trueconf_installer rule.
Creation of suspicious files by TrueConf Server processes.
Execution of a TrueConf Client installer file that lacks a software developer’s signature.
Suspicious process chains associated with TrueConf Client executables and TrueConf Client update executables.
Registration of suspicious libraries in the HKEY_CURRENT_USER\Software\Classes\CLSID\ registry key.
Actions related to retrieving information about the lsass.exe process.
Memory dump creation for the lsass.exe process using the comsvcs.dll library.
Accessing the memory of the lsass.exe process.
Creating tunnels using the ssh process.
To protect companies using our Kaspersky SIEM system, a general set of rules is available in the product repository that allows detection of the following techniques:
Creation of suspicious files in the C:\Windows\System32\inetsrv\* directory: R405_07_File write to IIS native modules folder or OWA via WriteData.
Creating a memory dump of the lsass.exe process using the comsvcs.dll library: R233_04_Process memory dump via comsvcs.dll.
Accessing the memory of the lsass.exe process: R262_Suspicious access to the LSASS process.
We also recommend paying attention to the following events when developing your own detection rules or conducting threat hunting:
Registration of suspicious libraries in the registry key \Software\Classes\CLSID\{0340F119-A598-4ed9-B0AC-6F6A12D3E755}\InprocServer32:
(DeviceEventClassID = '4657' OR DeviceEventClassID = '13')
AND FileName like '%\Software\Classes\CLSID\{0340F119-A598-4ed9-B0AC-6F6A12D3E755}%' AND DeviceCustomString6 = 'InprocServer32'
Creating the SysExcSvc and SysReadSvc services to run executables from temporary directories in the background via cmd:
DeviceEventClassID = '4697'
AND (DestinationServiceName = 'SysExcSvc' OR DestinationServiceName = 'SysReadSvc')
AND match (FileName, '.*cmd\s+\/c.*temp\\cmd_cmd_.*\.bat.*')
Creation of suspicious processes originating from the TrueConf update process (trueconf_windows_update.exe)
(DeviceEventClassID = '4688' OR DeviceEventClassID = '1')
AND SourceProcessName LIKE '%\trueconf_windows_update.exe'
For the detection rules to work correctly, ensure that events from Windows systems are received in full, including Security events 4688, 4663, 4657, and 4697 and Sysmon events 1, 7, 11, and 13.
1. Overview AhnLab SEcurity intelligence Center (ASEC) recently confirmed that the Larva-26005 threat actor is distributing Xctdoor to users in Korea. Xctdoor was disclosed through the ASEC blog in 2024, and [1] In March 2026, Hauri disclosed an attack case in which the malware was disguised as an integrated security program. [2] While analyzing […]
The UK Home Office has once again demanded Apple allows it access to encrypted iCloud data.
The Guardian reports that the Home Office issued a Technical Capability Notice to Apple, this time targeting only British users. A Technical Capability Notice is a formal government order that compels tech and telecommunications companies to build or maintain specific technical functions—such as intercepting data or removing encryption protections—so law enforcement can access communications.
In the last round of this ongoing battle, the UK secretly ordered Apple to provide blanket access to protected iCloud backups around the world. Advanced Data Protection (ADP) is Apple’s opt‑in end‑to‑end encryption for iCloud backups, which even Apple itself cannot read. Apple argued that weakening or removing ADP would expose users to data breaches and other threats, and instead chose in January 2025 to withdraw ADP for UK customers rather than build a backdoor, while leaving it available elsewhere.
So, instead of working to keep citizens safe and secure, the Home Office just ended up removing an option for them.
Apple has responded by lodging a complaint with the Investigatory Powers Tribunal (IPT), seeking to challenge the scope and lawfulness of the government’s powers to issue such notices under the Investigatory Powers Act. The Tribunal is an independent court that has the power to investigate claims that the UK intelligence services have acted unlawfully.
Privacy International and Liberty have parallel complaints at the IPT challenging Technical Capability Notices more broadly, including their secrecy and necessity, and have asked for Apple’s claim to be heard in public given its wide public-interest implications.
I feel the fear of leaving an intentional backdoor is justified. If it exists, there is a chance that (AI-assisted) criminals will find and exploit it.
Weighing the importance of the right to privacy and the ability to investigate cases including terrorism and child sexual abuse is not easy. Apple’s ADP is used by many and as soon as criminals would know it’s no longer safe for them to use, they’d move to other platforms. Platforms where no legislative power will be able to gain access.
But, given the danger of a backdoor becoming available for criminals, we think in this case privacy should prevail. Let us know how you feel in the comments.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
This technical analysis report was prepared as part of the joint cybersecurity advisory titled “Advisory on Cyberattacks Targeting Korean Citizens and Businesses by State-Sponsored Hacking Groups” issued by the Republic of Korea’s National Intelligence Service (NIS), National Police Agency (NPA), Korea Internet & Security Agency (KISA), and Financial Security Institute (FSI). OverView AhnLab SEcurity […]
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:
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, volume name, file system name, drive type, volume serial number, total size in bytes, and free space in bytes.
● case 0x10030: search for a file that matches a specified name and retrieve the following information: file attributes, creation time, last access time, last write time, file size, the file’s name, and its short (8.3) name.
● case 0x10040: recursively list all files in a specified location, including only those whose size, creation time, last write time, and last access time fall within the threshold values defined by C2. For each listed file, retrieve the following details: file attributes, creation time, last access time, last write time, file size, file name and alternative name for the file
● case 0x10050: use the ShellExecuteExW API to open the specified file path, which may be an executable, a document, or a folder.
● case 0x10051: execute the specified command line using the CreateProcessAsUserW API.
● case 0x10060: perform the following file‑system operations: copy, delete, move, and rename — using the SHFileOperationW API.
● case 0x10070: create a directory.
● case 0x10080: set the attributes for a file or directory.
● case 0x10090: for the filename provided by C2, set the file created, last accessed, and last modified timestamps to the values received from C2.
● case 0x20010: get the size of a file.
● case 0x20020: read a file from the system in chunks, starting at a specified offset.
● case 0x20030: calculate the CRC32 of each file data chunk, and retrieve the file created, last accessed, and last written times.
● case 0x20040: close the file handle and free the associated metadata (file path, handle, and size).
● case 0x20110: create a file at the specified path and write the bytes received from C2 into it. Then set the file created, last accessed, and last modified times using the timestamps supplied by C2.
Command Shell
● case 0x3E9: launch cmd.exe as shell.
● case 0x3EA: send the exit command to close the command shell.
● case Default: if a command string is received from the C2 and the shell is running, write the command to the shell. Then read the shell’s output and send it back to the C2.
If a command string is received from the C2 server and the shell is not already running, execute the command using C:\Windows\System32\cmd.exe /S /C "<command_string>" > %TEMP%\tmp%d%x.tmp where %d and %x are random values. Afterwards, read the output from the temporary file tmp%d%x.tmp and then delete the file.
Interaction Manager
● case 0x3E9: capture the entire screen as a BMP image.
● case 0x3EA: capture the entire screen at specified intervals.
● case 0x3EC: retrieve clipboard data.
● case 0x3ED: copy the data to the clipboard.
● case 0x3F3: MOUSEEVENTF_LEFTDOWN: set the cursor to the specified position and press the left mouse button.
● case 0x3F5: MOUSEEVENTF_LEFTDOWN | MOUSEEVENTF_LEFTUP: move the cursor to the specified position, then press and release the left mouse button.
● case 0x3F6: MOUSEEVENTF_RIGHTDOWN: set the cursor to the specified position and press the right mouse button.
● case 0x3F7: MOUSEEVENTF_RIGHTUP: set the specified cursor position and release the right mouse button.
● case 0x3F8: MOUSEEVENTF_MOVE: move the mouse cursor to specific coordinates, simulating a mouse movement event.
● case 0x3F9: MOUSEEVENTF_WHEEL: move the mouse wheel by a specified amount.
● case 0x3FD: press the key indicated by the virtual‑key code.
● case 0x3FE: KEYEVENTF_KEYUP: release the key identified by the virtual-key code.
● case DEFAULT: MOUSEEVENTF_LEFTUP: move the cursor to the specified position and release the left mouse button.
Post-compromise activity
The attacker used the command‑shell plugin installed via the OctLurk backdoor to perform the following actions:
Victim fingerprinting
The attacker used admin credentials to create a scheduled task named GoogleUpDate on remote machines. This task runs once with System account privileges, executing the script located at C:\windows\temp\in.bat (MD5 45cf5916fab4272a1313c26e67aa9220, 4e6d5c4770d5a822d7fcce6a74f7ad73). After querying the task’s status, the attacker triggers its execution, as shown below.
The batch script runs a series of commands that collect comprehensive information about the machine’s hardware, software, and network configuration as shown in the table below. The results are saved in three files — info.txt, <hostname>.datb, and <hostname>_logs.datb — all stored in the %TEMP% directory.
Command
Description
chcp 1256
Changes the system’s code page to 1256, which supports Arabic characters.
powershell $PSVersionTable
Retrieves the version information of PowerShell.
qwinsta
Views all active sessions on the local machine.
klist sessions
Displays a list of logon sessions on this computer (Including Kerberos).
TASKLIST /V
Lists all running tasks with detailed information.
findstr /i /c:”explorer.exe”
Searches for explorer.exe in a case-insensitive manner. Used together with TASKLIST /V.
wevtutil qe Security /f:text /c:5 /rd:true /q:”*[System[(EventID=4624)]] and *[EventData[Data[@Name=’LogonType’]=10]]”
Retrieves the last 5 events from the Security event log where the event ID is 4624 (successful logon event) and the logon type is 10 (remote interactive logon e.g., Remote Desktop Protocol).
Displays detailed information about the current user, including their security identifiers (SIDs), privileges, group memberships, and authentication details.
Searches the Windows Registry under HKEY_LOCAL_MACHINE (HKLM) for entries where the value name is “ProfileImagePath” and the type is REG_EXPAND_SZ. It points to the location of a user’s profile folder.
cmd.exe /c dir /b c:\users
Lists the contents of the C:\Users directory.
wmic startup get caption,command | findstr exe
Filters startup items for executable files.
powershell “get-MpComputerStatus”
Retrieves the status and configuration details of Microsoft Defender Antivirus (formerly Windows Defender) on a Windows system.
Queries exclusion settings for Microsoft Defender Antivirus. This is where you can configure files, folders, processes, and extensions that should be excluded from being scanned by Defender.
wevtutil gli Security
Configures the Security event log.
wevtutil gl Security /f:xml
Retrieves events from the Security log in XML format.
wevtutil gli “Windows PowerShell”
Configures the Windows PowerShell event log.
wevtutil gl “Windows PowerShell” /f:xml
Retrieves events from the Windows PowerShell log in XML format.
wevtutil gli System
Configures the System event log.
wevtutil gl System /f:xml
Retrieves events from the System log in XML format.
schtasks /query /fo LIST /v | findstr “TaskName> Status> ‘Task To Run’> ‘Run As User’>”
Lists all scheduled tasks in verbose mode and extracts the following fields: Status, Task To Run, Run As User, and TaskName.
Provides network configuration details, such as IP address, DNS, DHCP status, etc.
ipconfig /all
Displays detailed network configuration.
netstat -e -s
Displays detailed network protocol statistics.
certutil -urlcache
Displays URL cache entries.
ipconfig /displaydns
Displays the contents of the DNS client resolver cache.
Event log collection
The attackers ran commands to export successful logon events for remote interactive logons (e.g., Remote Desktop Protocol) and to query those events for specific users.
Credential harvesting
Impacket — secretsdump
Attackers ran a malicious file named Adobe.exe (MD5 32a5985543433a4f60da2fafd873b927), which is a portable‑executable version of Impacket’s secretsdump.py tool. Using this tool, they extracted password hashes from domain controllers, the critical servers in an Active Directory environment. Immediately after harvesting the hashes, they issued commands to list all members of the “Domain Controllers” group, likely to identify and target additional domain controllers for further compromise.
Keylogger
Attackers dropped and executed a keylogger located at C:\Users\Public\Pictures\AnyDesk.exe (MD5: 2a571f6cee42a17d873f4c942649813f). They then created a scheduled task named AnyDesk to run the keylogger whenever any user logged on as shown below.
The keylogger creates two files: C:\Users\Public\Libraries\msect\dev0, which stores captured keystrokes, and C:\Users\Public\Libraries\msect\dev1, which holds clipboard data. Before writing to these files, the captured data is encoded by subtracting 2 from each byte.
Browser Password Decryptor
The Browser Password Decryptor tool C:\users\[username]\libraries\64.exe (MD5 37dc84e4bcad92fa28f1e7778d088283) is used to extract passwords from browsers. The tool offers two options: -help to extract passwords from Chrome and -exit to extract passwords from Firefox. For Chrome, the tool targets the Login Data and Local State databases located at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data and %LOCALAPPDATA%\Google\Chrome\User Data\Local State, respectively. The Local State contains the master key, which is essential for decrypting encrypted login information stored in the Login Data database file. For Firefox, the tool targets the logins.json file located at %APPDATA%\Mozilla\Firefox\Profiles\{profile folder}. The logins.json file in Firefox stores encrypted usernames and passwords for websites.
Pandora RC agent provides remote control of a victim’s computer, allowing attackers to monitor and manipulate the system. Using administrative credentials, the attacker creates a scheduled task named GoogleUpDate on the compromised machines. This task runs once with System account privileges and executes the script 1.bat, which can be found at either C:\Users\[username]\1.bat or C:\ProgramData\1.bat (MD5 5e26df131ff0a679a0a2699b723b46e3). The task’s status is first queried, then it is executed, as shown below.
The batch script 1.bat executes a command that downloads and installs the Pandora RC agent using the arguments shown below.
EHUSER: a Pandora RC user
STARTEHORUSSERVICE: start the agent after the installation finishes (default = 1)
EHORUSINSTALLFOLDER: specify the folder where you want to install the agent (default: %ProgramFiles%\_agent)
DESKTOPSHORTCUT: 0: do not create a desktop shortcut
Network scan: FSCAN
Fscan is a comprehensive internal‑network scanning tool that offers a range of functions, including network discovery, vulnerability assessment, reverse‑shell creation, and brute forcing of common services. The executable is dropped to %TEMP%\fc.exe (MD5: cf903e4a1629aa0582fd0363b5786676) and writes its output to %TEMP%\result.txt. Using Fscan, both internal and public networks were scanned to identify services running on specific ports, such as Secure Shell (SSH) on port 22 and MySQL on port 3306. The tool also attempted to access these services using credentials from the password file pp.txt.
Email harvesting
The attackers used the curl command to connect to an email server, authenticate with a username and password, and issue a command to select the Inbox folder. Typically, the goal is to:
Verify that a connection to the email server is working
Authenticate the user
Prepare the Inbox folder for reading or manipulating messages (e.g., listing, fetching, or deleting emails)
LurkProxy
In a similar manner to the OctLurk backdoor, the attacker also deployed another implant we named LurkProxy, which uses a heavily obfuscated version of the OctLurk loader. While LurkProxy has a nearly identical architecture to the OctLurk backdoor, its primary role is to proxy network traffic. Like the OctLurk, it exports a function named curl_escape_easy, which the loader invokes. Once executed, LurkProxy listens on all interfaces on hard‑coded port 64980 and establishes a TLS‑encrypted connection to the C2 server (154[.]196[.]162[.]76). The C2 communication uses a proprietary binary protocol, where each packet is compressed with zlib, encrypted with a double‑XOR scheme, and follows the structure outlined below.
Offset
Data
Type
0x00 (00)
Unused
–
0x08 (08)
Packet control flags. Bit 0 indicates high priority packet, bit 1 indicates single packet
bit array
0x0C (12)
Command number
int
0x10 (16)
Handler number (unique identifier for each proxy client in the first mode)
int
0x14 (20)
Command integer argument
int
0x18 (24)
Unused
–
0x1C (28)
Data 1 payload size
int
0x20 (32)
Data 2 payload size
int
0x24 (36)
Data 1 byte stream
bytes
0x24 (36) + N
Data 2 byte stream
bytes
LurkProxy can function as a reverse proxy in two distinct modes as described below. The mode is selected by a static flag, meaning the proxy can operate in only one mode at a time. In the implant we examined, the first (SOCKS5) mode was used.
Mode 1: SOCKS5 proxy
When a client connects, LurkProxy sends to the C2 the command 0x1000010, indicating that the connection has been established and includes the target address in the packet data. The C2 server then opens a connection to that address, enabling bidirectional communication through the appropriate commands.
Mode 2: transparent proxy
In this mode, the target address and port are hard‑coded. Upon startup, LurkProxy immediately connects to the predefined target via the C2 channel using the same command. All subsequent client connections are routed through this single, fixed target. This mode handles raw network traffic directly, bypassing the SOCKS5 layer.
Command ID
Direction
Description
Arguments
0x1000010
Implant -> C2
When a new proxy client connects, it creates a proxy session and notifies C2 of the successful configuration
Target port in command integer argument
UTF-16 encoded connection hostname in data 1
0x1000010
C2 -> Implant
Used to control the session, allowing it to pause or stop proxying
Action in command integer argument (1 to pause, or any other value to terminate)
0x1000030
Implant -> C2
Sent when the LurkProxy is shut down
–
0x1000050
Implant -> C2
Forwards the received bytes from the client to C2
Raw TCP bytes in data 1
0x1000050
C2 -> Implant
Forwards the received bytes from the proxy target to the client
Raw TCP bytes in data 1
SilkLurk
Deployment
The attacker created a service that executes legitimate binaries, such as NetSetSvc.exe (NVIDIA debug dump), nvgwls.exe (NVIDIA background tool responsible for autotuning), RtkSmbus.exe (Realtek Semiconductor’s noise‑cancelling program), and RtkNGUI64.exe (Realtek High‑Definition Audio Manager), to side‑load malicious loader DLLs: nvml.dll, vulkan-1.dll, RtkSmbusLoc.dll, and RtkNGUI64Loc.dll, respectively. These DLLs act as a loader that will inject SilkLurk backdoor into the process memory.
SilkLurk loader
SilkLurk loader working logic
The loader first verifies that it is running within the legitimate executable that loads it. Next, it moves the payload file (in the analyzed sample, it was named OneDrive.dat) from its module location (C:\ProgramData\Microsoft\Network\Connections in the analyzed sample) to the hard‑coded payload path (C:\ProgramData\Microsoft OneDrive\setup in the analyzed sample). Note that the hard-coded payload path may vary depending on the loader.
Next, the loader creates a service named RmSs to maintain persistence. The service will run the legitimate module binary (C:\ProgramData\Microsoft\Network\Connections\nvgwls.exe) that loads the malicious loader (vulkan-1.dll). The service is configured with the parameters mentioned below. Additionally, the service configuration is modified to restart the service in the event of a failure. Finally, the loader starts the service.
Service Type:SERVICE_WIN32_OWN_PROCESS
Start Type:SERVICE_AUTO_START
Error Control:SERVICE_ERROR_NORMAL
On service start, loader calls StartServiceCtrlDispatcher, which will invoke ServiceProc. The ServiceProc then calls the routine s_1800078F0_decrypt_and_run_payload. This routine computes a 32-bit hash (dword) of the victim’s computer name. The dword hash is used by a custom algorithm made up of arithmetic and logical operations to decrypt the hardcoded payload file path. The payload bytes themselves are decrypted with the same algorithm that decoded the file path. By using the victim’s computer name in the decryption of both the file path and the payload bytes, the loader becomes specific to each victim. The decrypted bytes contain shellcode with the following structure:
Shellcode offset
Description
0x000 (0)
Stub code, which performs reflective code injection
0x770 (1904)
Hardcoded value 0x11113F68, XORed with the computer name hash
0x774 (1908)
Hardcoded byte 0xD9, used as XOR key to decrypt import DLL names and APIs
0x775 (1909)
Size of the encrypted backdoor
0x779 (1913)
Encrypted backdoor data blob
The stub code decrypts and injects the backdoor blob into memory. To decrypt the blob, it first computes a dword hash of the computer’s name. This hash is then fed into a custom algorithm — a series of arithmetic and logical operations — that performs the decryption. This algorithm differs from the one used to decrypt the payload file.
The IMAGE_DOS_HEADER of the backdoor binary is zeroed out. Information in the IMAGE_NT_HEADERS, such as ImageSize and NumberOfSections, is XOR-decrypted using the hash of the computer name. The first three sections are decrypted again using a custom algorithm (a series of arithmetic and logical operations) before being injected into memory.
During import resolution, DLL names and API names are XOR‑decrypted using a hard‑coded single‑byte key. After the import DLL is loaded and the API addresses are resolved, the DLL and API name strings are zeroed out.
During relocation, the size of each relocation block, the value of each relocation entry, and the bytes to be relocated are XOR‑decrypted using the dword hash of the computer name. Afterward, the entry point is also XOR‑decrypted with the same hash and then invoked.
SilkLurk backdoor
The backdoor contains a hardcoded configuration of 0x4AC (1196) bytes, with the first 0x10 (16) bytes holding a mutex string and the remaining 0x49C (1180) bytes comprising encrypted configuration data; this configuration is written to a hardcoded filename (e.g., 2470b666bece868f, 27879a4df1a740ff) that differs across samples and is placed in the %APPDATA% directory. The configuration is decrypted using a custom algorithm involving a series of arithmetic and logical operations that is distinct from the algorithm used to decrypt the encrypted backdoor blob and payload file. The configuration has the following structure:
Offset
Description
0x00 (000)
C2 Host 1
0x64 (100)
C2 Host 2
0xC8 (200)
C2 Host 3
0x12C (300)
C2 Host 4
0x190 (400)
Port for C2 Host 1
0x192 (402)
Port for C2 Host 2
0x194 (404)
Port for C2 Host 3
0x196 (406)
Port for C2 Host 4
0x198 (408)
Unknown 21 bytes
0x1AD (429)
Proxy address 1
0x22A (554)
Proxy username 1
0x2A7 (679)
Proxy password 1
0x324 (804)
Proxy address 2
0x3A1 (929)
Proxy username 2
0x41E (1054)
Proxy password 2
The backdoor creates a TCP socket and connects to the C2 server defined in the configuration. If proxy details are provided, it attempts to establish the C2 connection through the proxy. The proxy request uses the following format:
After successfully connecting to the C2 server, it generates a random 32‑byte (0x20) network key that will be used to encrypt and decrypt network packets. This key is appended to the magic dword, as shown in the table below, creating a 40‑byte block that is then encrypted with a custom algorithm: a series of arithmetic and logical operations that differs from the one used to decrypt the configuration.
Field offset
Field size (in bytes)
Field value
0x00 (00)
0x04 (04)
0x0C7FFBE86h (magic dword)
0x04 (04)
0x04 (04)
0
0x08 (08)
0x20 (32)
Network key (will be used to encrypt and decrypt network traffic)
It then prepares a packet to send the key to the command‑and-control server, as shown in the table below. The packet contains a 0xC (12‑byte) header, a 0x28 (40‑byte) block of encrypted network‑key data (see the table above), and a randomly generated payload whose size ranges from 0x14 (20) to 0xB4 (180) bytes.
Encrypted network key data (as mentioned in above table)
0x34 (52)
size between 0x14 (20) and 0xB4 (180)
Random data bytes
After sending the key, the backdoor collects the following victim information: local computer name, DNS domain assigned to the local computer, user’s logon name, processor architecture, OS major version and build number, host IP address, current process ID, tick count value, and backdoor module name. The collected victim information is first compressed and then encrypted using the network key. The custom algorithm (a series of arithmetic and logical operations) used to encrypt collected victim information is different from the algorithms used to decrypt the configuration and encrypt the network key. Before sending the victim information, a 0x0F (15) byte header is generated and encrypted using the same custom algorithm used to encrypt the collected victim data. The header follows the format as shown in the table below.
Field offset
Field size (in bytes)
Field value
0x00 (00)
0x04 (04)
0xC7FFBE86 (magic dword)
0x04(04)
0x04 (04)
Message type (1 means victim information)
0x08 (08)
0x04 (04)
Data size (size of encrypted victim information)
0x0C (12)
0x01 (01)
Compression flag (1 means compressed)
0x0D (13)
0x02 (02)
Size of random bytes, between 0x14 and 0x96 bytes
Finally, the encrypted header and victim information are formatted as shown below and transmitted to the C2 server.
Once the backdoor has transmitted the victim information, it waits for a 0x13‑byte (19‑byte) response from the C2 server. This response follows the structure presented in the table below.
Field offset
Field size (in bytes)
Field value
0x00 (00)
0x04 (04)
Random dword
0x04 (04)
0x0F (15)
Encrypted header data
The encrypted header contained in the response is decrypted with the network key that was generated and shared with the C2 server. After decryption, the header retains the same size and structure as the one used in the victim information message.
The message type field in the header (offset 0x04) determines which operation (command) to perform. Next, the backdoor figures out the size of the command data to receive by adding up the size of the encrypted data (found at position 0x08 in the received header) and the size of the random bytes (found at position 0x0D in the received header). The received command data is first decompressed, based on the compression flag located at position 0x0D in the received header, and then decrypted using the custom algorithm that was used to encrypt the sent data. The backdoor supports the following commands:
Command (message type)
Description
03
Based on subcommand, perform the following operations:
00: Get target system’s local time
01: Set sleep time in milliseconds, after which to reconnect to the C2 server
04
Send current backdoor configuration
05
Update backdoor configuration
06
Receive and inject additional payloads (plugins) into memory. Based the on subcommand, perform the following operations:
01: Inject payload (plugin) bytes into memory and execute payload’s entry point
03: Call export method of injected plugin
Post-compromise activity
The threat actor operating the SilkLurk backdoor first used it to invoke cmd.exe to launch PowerShell. Within PowerShell, they ran commands such as net use to connect to shared network resources with administrative credentials. After establishing the connection, they searched the shared drives for confidential documents to exfiltrate. Once the search was complete, they disconnected from the network share to erase evidence of which internal servers had been accessed. To archive the stolen data, they employed legitimate archiving tools: WinRAR and 7‑Zip.
Below are the paths and names of the WinRAR and 7Zip binaries used by the attackers.
The SilkLurk backdoor opened a command shell (cmd.exe). Using this shell, the attacker executed the file C:\ProgramData\microsoft\html help\kmsonline.exe (MD5: 3c9a1ba8e0c7475706adc6376e9d7b7c). The kmsonline.exe binary acted as a dropper for the PlugX malware, deploying the malicious files listed below.
Our Kaspersky Threat Attribution Engine (KTAE) also identified a strong degree of similarity between kmsonline.exe (MD5: 3c9a1ba8e0c7475706adc6376e9d7b7c) and PlugX.
PlugX was configured to communicate with the C2 domain gycudore[.]kozow[.]com and the IP address 64[.]7[.]198[.]130. Below are the extracted configuration fields from PlugX.
Config field name
Value
Injection Target Process
%SystemRoot%\system32\svchost.exe
Home Directory
%ALLUSERSPROFILE%\Symantec
Persistence Name
SymantecRAS
Service Display Name
SymantecRAS
Service Description
Symantec RAS Services
Campaign ID
KG_MFA
Infrastructure
The threat infrastructure relies on VPS servers. Some OctLurk and LurkProxy C2 addresses are referenced in a public report by Kazakhstan’s State Technical Service (STS) company. According to available data, a campaign targeting critical infrastructure in Kazakhstan was discovered in March 2025. During this campaign, attackers employed the TrustFall (STS internal designation) remote access malware, also known as MystRodX (Qianxin) and SilentRaid (Cisco) and designed for Linux-based operating systems. Subsequently, in October 2025, STS researchers found additional TrustFall samples, while also discovering its new C2 servers via active probing. Notably, three observed TrustFall C2 addresses were also leveraged by OctLurk and LurkProxy. This overlap points to shared infrastructure across multiple OS-targeting campaigns, though it remains unclear whether these activities ran concurrently or at different times.
Attribution
We identified multiple artifacts confirming that OctLurk and SilkLurk are operated by the same threat actor. Several users infected with OctLurk were also found to be infected with SilkLurk, and in some cases both malware families used the same staging directory. Below are examples of these artifacts.
In one incident, the attackers created the service C:\Windows\system32\svchost.exe -k ExAstSrc -s ExAstSrc to deploy OctLurk. They used OctLurk to obtain a command shell and were observed dropping the SilkLurk loader vulkan-1.dll (MD5 be4731c09734da2e8eb6814a9c82f266) via this shell, as shown below.
In another incident, we observed attackers using the same directory C:\ProgramData\intel\ to drop both the OctLurk and SilkLurk loader DLLs.
In one incident, the attacker used SilkLurk to obtain a command shell (cmd.exe) and then deployed and executed the PlugX malware. The PlugX sample was configured to contact gycudore[.]kozow[.]com as its command‑and‑control (C2) server, while the SilkLurk backdoor used ctyuhjerf[.]kozow[.]com for C2. PlugX is a well‑known modular remote‑access Trojan (RAT) that has been active since at least 2008 and historically linked to Chinese-speaking threat actors. This suggests that both OctLurk and SilkLurk were also developed and operated by a Chinese‑speaking actor, although at this time, we cannot attribute this activity to a known threat group.
Conclusions
The emergence of the OctLurk and SilkLurk multi‑plugin malware framework highlights how threat actors continuously refine their tactics to evade detection and maintain control over compromised networks. Both families operate primarily in memory, leaving only a minimalistic loader on disk that relies on machine‑specific data (OctLurk uses the drive serial number, and SilkLurk uses the computer name) to decode payload locations and contents. This victim‑specific encoding makes reverse engineering and automated detection considerably harder.
In addition to sophisticated obfuscation, the attackers establish redundant access channels, harvest credentials, and deploy well‑known remote access and monitoring tools. These secondary pathways ensure persistence even if the original infection vector is discovered or neutralized.
Mirage Kitten – also known as UNC1549, Smoke Sandstorm, and Nimbus Manticore – is an advanced persistent threat (APT) group focused on cyber-espionage operations against aerospace, aviation, defense, and telecommunications sectors across the Middle East and Africa, using highly targeted spear-phishing campaigns, fake recruitment portals, and custom multi-stage malware to gain persistent access and exfiltrate sensitive data.
During recent threat research, we identified a previously undocumented malware set developed and used by Mirage Kitten. The toolset includes NightLedger, a new Windows backdoor for reconnaissance, command execution, file operations, process discovery, and screenshot capture; and two custom WebSocket-based tunnelers, ArcBridge and BridgeHead, for covert network access and operator-controlled tunneling.
Technical details
Although the initial access vector remains unclear for most malware samples observed in this activity, we saw BridgeHead being deployed during post-exploitation activities in victim environments in Egypt and at a Pakistan-based aerospace and aviation organization. The deployment followed targeted spear-phishing activity consistent with tradecraft we recently documented as part of our private threat intelligence reporting service and publicly reported by Unit 42 and Check Point Research, including the use of highly tailored social engineering lures against selected targets. These lures included recruitment-themed content impersonating trusted brands and hiring platforms, as well as lookalike videoconferencing pages that redirected victims to malicious archives hosted on third-party file-sharing services.
NightLedger backdoor
NightLedger is a recently identified Windows backdoor that we attribute to Mirage Kitten based on code and behavioral similarities to the historical implants developed and used by the group. The implant masquerades as SspiCli.dll and appears to be designed for DLL search-order hijacking, targeting a legitimate AppVShNotify.exe binary. While AppVShNotify.exe does not directly import SspiCli.dll, it imports RPCRT4.dll, which can delay-load SspiCli.dll when it invokes an RPC API that requires authentication. This allows a co-located malicious SspiCli.dll to be loaded while forwarding expected exports to the legitimate DLL.
When started, the malicious DLL creates the mutex A8215357-F99A-44FE-BC65-D8F0434B0C03 to enforce a single running instance. If the mutex already exists, it exits immediately.
NightLedger periodically contacts its C2 over HTTPS, issuing an HTTP GET request to the /edfcvfgbhnjmkqwasderfgg endpoint at the realhealthshop[.]com domain, and uses tjconsultingservices[.]com as a fallback C2.
When a valid C2 response is received, the implant tokenizes the payload using the custom delimiter (#%%#) and passes the parsed fields to its command dispatcher. From a development standpoint, this is similar to TWOSTROKE, a backdoor attributed to the same APT and previously documented by GTIG, whose C2 response is hex-encoded and uses (@##@) as a field separator.
NightLedger supports the following commands:
Command ID
Description
1
Gather user and host identity information
3
Execute a process/program
17
List directories
20
Download a file to the infected system
25
Gather host and network information
27
Copy a file
30
Update beacon interval
36
Take a screenshot
43
Load a DLL
56
Kill a process
62
Delete a file
69
Terminate thread
70
Upload file to C2 server via POST request to /qasxcdfvgbhnmyuioplkhnj
75
Enumerate logical drives
90
List processes
93
Collect C:\Windows\debug\NetSetup.log together with process-list output.
NetSetup.log is a Windows diagnostic log generated under C:\Windows\debug\ during domain/workgroup join, unjoin, and related network setup operations.
Command output is returned to the C2 via an HTTP POST request to /wsdefvvbnhyuijkplmbgfrtt.
BridgeHead – a WebSocket tunneler
During our investigation, we encountered a tunnel proxy deployed as unbcl.dll in the %LocalAppData%\Microsoft\VisualStudio directory on a machine in Egypt. We also identified a similar deployment in a Pakistan-based environment, where the tunneling tool was stored as C:\program files (x86)\univpn\promote\libwinpthread-1.dll. The malware dynamically loads advapi32.dll, resolves GetUserNameA, retrieves the current Windows username, converts it to lowercase, and searches for a specific substring in it. This behavior suggests prior reconnaissance was performed within the internal network and the username check is needed to make sure it runs on a specific machine. This is potentially intended to prevent execution of the standalone malware sample inside virtual analysis systems. If the substring is not found, the function returns silently without activating.
If the username check was successful, the tunneler establishes an HTTPS WebSocket connection as follows:
GET /connect HTTP/1.1
Host: smartconnect.azurewebsites.net
Upgrade: websocket
Connection: Upgrade
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36 Edg/86.0.622.38
The server responds with HTTP 101 (Switching Protocols) to complete the WebSocket upgrade. After the upgrade, the client sends a binary WebSocket message containing the literal string "token" as authentication. The server must respond within 10 seconds, or the connection is dropped and retried with exponential backoff.
The malware’s next action depends on the HTTP response returned by the server:
HTTP response
Description
407 (Proxy Auth Required)
Queries supported auth schemes via WinHttpQueryAuthSchemes, selects Negotiate (0x10) or NTLM (0x2) in that exact order, sets Windows SSO credentials (null username/password), retries up to 3 times.
101 (Switching Protocols)
Success. Proceeds to WebSocket upgrade and authentication.
Other
Connection failed. Closes all handles, enters backoff.
This implementation closely mirrors the enterprise proxy traversal logic seen in the backdoor we track internally as Retrograde, which overlaps with tooling publicly reported as MiniFast/MiniUpdate, attributed to the same APT group. The implant is designed to operate through corporate proxy environments by handling HTTP 407 responses, negotiating Windows-integrated proxy authentication with Negotiate preferred over NTLM, retrying with the current user’s SSO context, and falling back to exponential C2 connection retry logic capped at 60 seconds.
Once the WebSocket channel is established and authenticated, the implant functions as a full SOCKS5 tunnel proxy. The C2 server initiates all tunnel connections by sending binary commands over the WebSocket; the implant simply forwards traffic between server‑specified targets and the WebSocket channel. This makes it a relay node: the operator runs tools server‑side, and all resulting TCP traffic is tunneled through the victim’s machine as if originating from the victim’s network.
All tunnel communication uses a fixed binary wire format:
Offset
Size
Field
Encoding
0
1
type
Message type (1–9)
1
4
connId
Tunnel connection identifier
5
1
flags
Status or error indicator
6
2
dataLen
Payload length
8
var
payload
Message data
Every message is at least 8 bytes. Seven message types are actively used:
Type
Name
Direction
Description
1
CONNECT
Server -> Client
Open a new TCP tunnel to a SOCKS5 target address
2
CONNECT_RESPONSE
Client -> Server
Confirm the connection was established
3
DATA
Bidirectional
Relay TCP traffic through the tunnel
4
DISCONNECT
Bidirectional
Close a tunnel connection
5
PING
Bidirectional
Keepalive probe, sent every 30 seconds by timer
6
PONG
Bidirectional
Keepalive reply
9
FLOWCTRL
Bidirectional
Throttle data flow to prevent buffer overrun
The CONNECT payload specifies where the implant should open a TCP connection. The target address is encoded in SOCKS5 format and consists of a single type byte, followed by the address and a 2-byte destination port:
Type byte
Description
0x01
IPv4 address (4 bytes)
0x03
Domain name (1-byte length + string)
0x04
IPv6 address (16 bytes)
Notably, in the process of threat hunting, we detected another variant (MD5: C832ECD135781B11F59E3FFFB3D2B6AC) that shares the same dynamic-resolve stub pattern. This variant communicates with businessmixture.com/blog over WSS on port 443, and not through Microsoft Azure. Still, it implements the same technique of limiting execution to a specific username on the infected machine by hardcoding a 3-character control value that must appear as a substring in the lowercased Windows username retrieved via GetUserNameA. If the match fails, the implant silently exits, confirming per-target tailoring of each deployed binary.
ArcBridge: another WebSocket tunneling tool
ArcBridge is another WebSocket tunneling tool developed and used by Mirage Kitten. We first identified it in April 2026 in activity targeting victims in the Middle East. The malware creates a mutex named F56E68DA-4A89-46B4-9AC8-7290A7651000 to enforce single-instance execution. The use of a UUID-like mutex name is consistent with the NightLedger backdoor described earlier.
The malware contains an embedded configuration block that stores the C2 host, C2 port, retry or timeout value, SSL flag, and what is highly likely an implant identifier:
After initialization, ArcBridge communicates over a WebSocket-style channel and waits for server-side control messages. It supports the following commands:
Command
Description
OPEN:
Creates a proxy/tunnel session to a target selected by the operator.
DNS:
Performs hostname or address resolution and returns the result.
Victimology
According to our telemetry, we identified victims across Middle East and African countries including Egypt, SMB and government environments in Jordan and Tanzania, aviation organizations in Pakistan, telecommunication companies in Ethiopia and financial-sector entities in Burkina Faso.
Conclusion
Mirage Kitten continues to evolve its malware arsenal to support targeted cyber-espionage operations across the Middle East and Africa regions. The NightLedger backdoor retains similar core command functionality to TWOSTROKE while introducing additional capabilities, including screenshot capture and collection of the NetSetup.log file.
Another notable aspect of the campaign is the group’s continued reliance on tunneling utilities as part of its operational toolkit. This aligns with previous public reporting, which documented the group’s use of the LIGHTRAIL and POLLBLEND tunnelers. Consistent with this tradecraft, we observed Mirage Kitten continuing to leverage tunneling capabilities alongside a gradual shift away from Microsoft Azure subdomain-style infrastructure in favor of Cloudflare-backed domains in some of its malware, a change likely intended to complicate attribution while maintaining resilient command-and-control communications.
Content AhnLab monitored domestic APT (Advanced Persistent Threat) attacks—attacks that are conducted covertly and persistently—using its own infrastructure. This report summarizes the classification and statistics on domestic APT attacks identified in June 2026 and describes the capabilities of each type of APT attack. Purpose and Scope Most of the APT attacks identified in Korea were […]
AhnLab SEcurity intelligence Center (ASEC) previously disclosed an attack case in which the Kimsuky group used spear phishing attacks to install the PebbleDash malware in a post titled “Analysis of the Kimsuky Group’s Latest Attacks Exploiting PebbleDash and RDP Wrapper” [1]. The same threat actors have continued their activities in 2026 and have recently been […]
In February 2026, we discovered a set of malicious activities that had been ongoing since late 2025. These activities involved a RAT module written in Go with proxy capabilities, which served as the main stage of the attack. The attack targeted government and diplomatic entities in Southeast Asia and showed a level of sophistication that caught our attention.
During the attack, the main malware, dubbed GoSerpent, received an encrypted argument and started communicating with a remote server. It was also used to deploy further malicious tools to collect sensitive data and dump credentials on the system.
Monitoring the activities of this threat actor revealed that in May 2026, they came back with an evolved set of malicious tools: a new RAT and proxy tool, Stowaway, which resembled the initial malware, as well as an additional stealthy tool to exfiltrate sensitive data collected in the previous few months through network shares.
We found earlier versions of the GoSerpent backdoor used since 2021 against victims in Southeast Asia with relatively simpler code that received command-line arguments in plain text. Even though the newer variant is stealthier, the attackers continued using the simpler version alongside the latest one in their recent attacks.
What makes this threat particularly concerning is the strategic deployment of various tools with sophisticated data collection and exfiltration capabilities.
In this article, we introduce the malicious tools uncovered by us, which have been used since late 2025.
Technical details
Initial phase of the attacks
The initial phase of the attacks involved deployment of the GoSerpent backdoor, followed by additional malicious tools. During this phase, the main goal was to collect sensitive files and store them for future exfiltration, which was done by a data collecting tool, ThumbcacheService. The attackers also needed system credentials to exfiltrate the collected data through network drives at a later stage. This was achieved through a number of credential dumping tools deployed in this phase via the GoSerpent backdoor.
GoSerpent backdoor
The primary weapon in this campaign is the GoSerpent backdoor, a sophisticated Go-based remote access Trojan that has been active since at least 2021, with the most recent variant deployed in 2026.
This malware receives encrypted and base64-encoded command-line arguments containing a C2 server address and communication password, which are decrypted using AES-CBC mode with a fixed IV (31323334353637383930616263646566) and keys derived from predefined strings.
The backdoor connects to command-and-control servers using ChaCha20 encryption for communications, with the SHA256 hash of the communication password serving as the encryption key.
GoSerpent supports multiple C2 commands by receiving special command values. The commands include the following:
Command
Symbol (as derived from corresponding function names)
Description
2BA1
Sync
Respond to the server to show the infection is active
3BA2
Exit
Exit process
4BA3
Ls
Start listening on a port
5BA4
Connect
Connect to a remote server
6BA5
Hello
Create a shell on the infected machine
7BA6
Ul
Upload a file or directory to the server
8BA7
Dl
Download from the server
9BA8
Ss5
Start a SOCKS5 proxy on the infected machine
ABA9
Cl
Close a listening port
CBAB
RF
Forward to a connected node
GoSerpent can establish SOCKS5 proxy servers to route traffic through compromised hosts, enabling attackers to access other networks while masking their true IP addresses. The backdoor is capable of deploying additional malicious tools, including ThumbcacheService for file collection, Mimikatz for credential dumping, and QuarksDumpLocalHash for local account password hash extraction. The malware exhibits strong persistence mechanisms and uses filenames that mimic legitimate system processes such as lass.exe and updates.exe to evade detection.
McMx RAT
McMx is a basic Go-based proxy and remote access tool that represents a simpler variant of the GoSerpent backdoor, apparently compiled from a different GitHub repository path.
Unlike the latest variant of GoSerpent, which uses encrypted command-line arguments, McMx receives input parameters from text files in plaintext format — in a way that resembles older versions of GoSerpent. The malware features similar function names with apparent typos present in both tools.
Before executing McMx, attackers manipulate batch files to generate configuration files containing C2 parameters. The patterns observed show the use of echo commands to create configuration files with parameters like remote host addresses, ports, and secret keys. The McMx malware is then deployed with this configuration.
The tool shares core functionalities with GoSerpent, including:
SOCKS5 proxying
port forwarding
file transfer
remote shell capabilities
Data collection and credential dumping tools
Following initial deployment of the GoSerpent backdoor, attackers typically wait several days before utilizing it to download and execute additional malware components for data collection and credential dumping.
ThumbcacheService
ThumbcacheService is a malicious DLL deployed as a Windows service that functions as a sophisticated file collection mechanism within the GoSerpent ecosystem. The malware employs XOR encryption with a single-byte key of 0x13 for string obfuscation. It decrypts embedded strings and creates a database file named thumbcache_605a.db in the C:\Users\Public\ directory to store collected sensitive files. It specifically targets documents with the following extensions: .doc, .docx, .pdf, .xls and .xlsx.
The targeted files are then archived using 7-Zip and protected with a predefined password @vx0a9n5W2M0c3D6.#, enforcing a 20MB size limit for archives.
The malicious service also monitors the $Recycle.Bin directory for deleted files with the extensions of interest, ensuring comprehensive data collection.
Credential dumping tools
The threat actor deploys the following tools via GoSerpent backdoor to dump credentials:
Mimikatz — dumps memory from the LSASS process to extract credential material, including cached credentials and Kerberos tickets.
QuarksDumpLocalHash — extracts local account password hashes from the SAM registry hive, allowing for offline password cracking attacks.
These tools work together to maximize information extraction from compromised systems. The stolen credentials were used in later stages of the attack to facilitate the exfiltration of sensitive files collected by ThumbcacheService.
Second stage of the attacks
After the initial phase of the malware deployments, the attackers allowed a few weeks for the ThumbcacheService to silently collect sensitive files without exfiltrating them. In the meantime, the credential dumping tools also continued to steal credentials. In May 2026, the threat actor came back with a set of new tools. The main malware of this round of activity was another Go-based RAT and proxy tool, Stowaway. It was used to deploy the two-stage data exfiltration tool TmcLoader/TmcPayload, which was the last piece of the data theft puzzle.
Stowaway
Stowaway is a proxy and remote access tool compiled from an open-source framework with customized functions to make the infection stealthier. This malware features both network admin and agent capabilities, enabling attackers to establish chained proxy paths across multiple hosts with the following functionalities:
SOCKS5 proxying
port forwarding
reverse tunneling
remote shell access
file transfer
SSH-based tunneling
Communications are transported over TCP, HTTP, or WebSocket channels protected by AES-256-GCM or TLS encryption.
As the next step, the attackers deliver two files to the victim machine via Stowaway:
TmcLoader with an embedded payload
{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db — an encrypted configuration file
TmcLoader/TmcPayload
TmcLoader is a stealthy C++ loader module registered as a Windows service. The malware embeds an encrypted payload dubbed TmcPayload within its .data section, which is decrypted and loaded into the memory space of the svchost process to maintain persistence and avoid detection.
TmcLoader employs dynamic API resolution through a circular XOR encryption, where each byte is XORed with the value of the subsequent byte, combined with Base64 encoding for string obfuscation to hide API names.
The loader creates a unique event to prevent multiple infections on the same system. After that, it extracts and decrypts the embedded TmcPayload. This payload component is responsible for exfiltrating sensitive data from the victim’s machine.
TmcPayload generates a file path from an obfuscated string:
C:\Users\Public\Libraries\{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db.
It then checks for the existence of this configuration file. If the file doesn’t exist, it delays execution for a random period of time before rechecking. The configuration file contains encrypted network share credentials and destination paths for data exfiltration. It specifically references the thumbcache_605a.db file created by ThumbcacheService as the file to be exfiltrated, demonstrating the integrated nature of the attack chain.
Toolset integration
What distinguishes this threat actor’s approach is the deliberate integration between different components of their toolset. The chain from ThumbcacheService to TmcLoader/TmcPayload demonstrates sophisticated operational planning:
ThumbcacheService: deployed via GoSerpent, collects and archives sensitive files into the thumbcache_605a.db database file.
Credential dumping tools: deployed via GoSerpent to retrieve system credentials.
Configuration file: delivered via Stowaway, contains credentials and file paths for data exfiltration.
TmcLoader/TmcPayload: deployed via Stowaway, reads the configuration file for data exfiltration.
Data transfer: using network credentials and destination paths from the configuration file, TmcPayload transfers the exact same thumbcache_605a.db.
This integration shows that the threat actor has carefully orchestrated their tools to work together seamlessly, ensuring that data collected by one component is available for exfiltration by another component.
Infrastructure
The malware operators leverage legitimate hosting providers, including Alibaba Cloud and UCLOUD HK, for their command-and-control infrastructure. The use of legitimate hosting platforms demonstrates operational security awareness, making detection more challenging.
The technical similarities between GoSerpent and the newer Stowaway tools strongly suggest the threat actor’s deep familiarity with network proxy technologies. The consistent use of legitimate domain names as secret keys, with GoSerpent employing www.microsoft.com and www.spacex.com and Stowaway utilizing github.code, indicates a standardized operational methodology.
Attribution
While the exact attribution of the GoSerpent campaign remains uncertain, there are indications of a potential link to the TetrisPhantom threat actor. The similarities in victim targeting, technical capabilities, and operational methodologies suggest a possible connection. However, further investigation is necessary to confirm this association.
Conclusion
The GoSerpent campaign represents a sophisticated and evolving threat to government and diplomatic entities in Southeast Asia. The threat actor’s use of customized tools, such as the GoSerpent backdoor, Stowaway, and TmcLoader, demonstrates a high degree of technical expertise and operational planning. The integration of these tools to collect and exfiltrate sensitive data highlights the actor’s focus on long-term access and intelligence gathering. As the threat landscape continues to shift, it is essential for organizations to remain vigilant and implement robust security measures to detect and prevent such attacks. By understanding the tactics, techniques, and procedures (TTPs) employed by this threat actor, defenders can better prepare themselves to counter similar threats in the future.
In January 2026, we identified multiple attacks involving unknown malware that captures the contents of cryptocurrency wallet windows. During the investigation, we reconstructed the complete infection chain, which consisted of four tightly linked stages initiated by the execution of the previously described malicious PowerShell script TookPS. However, this campaign differs from previous activity in that it uses a new framework to deliver all malicious modules and orchestrate them via an SSH tunnel. In total, the framework includes more than 20 malicious payloads and implants, covering a wide variety of functions. At the time of writing, the threat remains active.
Kaspersky’s products detect this threat as Trojan-Downloader.Win32.TookPS.*, Trojan.Win64.BypassUAC.*, Trojan-Banker.Script.Agent.gen, Trojan.Win32.Dllhijack.*, Backdoor.Win32.TeviRat.*, Trojan-PSW.Win64.Stealer.*, Trojan-Spy.Win64.Keylogger.*, Trojan-Spy.Win64.Agent.*, Trojan.Win64.Agent.*.
Background
TookPS is a downloader used for retrieving malicious commands and scripts from attacker-controlled servers to further propagate attacks. The first campaign using TookPS was discovered in March 2025. At that time, malicious scripts delivered a Python‑based infostealer along with a script that installed and configured an SSH tunnel on the victim’s machine. The next wave appeared in April 2025: the payload was changed, and TookPS was used to deliver the TeviRAT malware with the same SSH installer.
Then at the end of April 2025, TookPS underwent minor changes, yet its attack chain was completely redesigned. Unlike previous incidents, in this case, TookPS was used solely for the initial infection, with an automated SSH bot responsible for payload delivery. This new malicious campaign has multiple stages that cover the full attack lifecycle, from initial infection to persistence and data exfiltration. Among various malware strains, at one of the stages, the TeviRAT backdoor is delivered to the compromised host, ultimately fetching another version of a TookPS script.
We dubbed this updated TookPS campaign “OkoBot”.
Original OkoBot infection chain
We will break down this chain in greater detail later in the article. However, this is not the only version of OkoBot we were able to find. Already in March 2026, we discovered a new phase in the development of the framework, with Volume2 now being installed directly using TookPS. The HDUtil launcher → extl injector → Rilide chain was found to be abandoned in this newer version since it was replaced in full by the identical ext_daemon Volume2 plugin. TeviRAT was also removed, most likely because its functions were covered by the new plugins dispatcher.
New OkoBot infection chain
Initial infection
The initial infection is primarily delivered through two vectors: a ClickFix attack, and malware distributed through GitHub that masquerades as legitimate software. One such example is the fake SQL Server Management Studio (SSMS) package distributed through GitHub. In fact, it is actually the legitimate Audacity — a popular audio editor — compiled with a malicious implant embedded in one of its libraries. Because the repository was indexed by most search engines and appeared at the top of the results for the query SSMS, the malware looked legitimate and quickly earned users’ trust.
Malicious application distribution report
This repository was created at the end of March 2025 and existed until June of that year. It consisted of a single file, README.md, which provided a fake SSMS installation guide written in an official style and likely derived from excerpts of Microsoft’s documentation. However, the download link for the program, located at the beginning of the guide, pointed to the latest release in the same repository.
Both infection vectors trigger the execution of the malicious script TookPS, which installs SSH on the victim’s system, establishes a connection to the attacker-controlled SSH server and subsequently forwards the SSH daemon port. Following a delay, an automated SSH bot connects to the forwarded port.
Back connection
The automated SSH bot collects system information such as usernames, antivirus software installed, the IP address, and OS version. It harvests cryptocurrency wallet files, browser cookies, profiles, and other credentials through an SSH tunnel. For subsequent delivery of malicious modules, it disables Windows Defender notifications via a registry modification. Moreover, it gains access to the graphical session on the victim’s system using the following sequence:
Open firewall ports for inbound RDP traffic
Create a user in the “Remote Desktop Users” group
Replace the legitimate termsrv.dll with a patched one to permit multiple concurrent RDP sessions
Create a scheduled task named Apple Sync to maintain a reverse SSH tunnel that forwards the local RDP port every hour
After that, the SSH bot begins retrieving malicious modules over SFTP.
Launcher with advanced options
One of the deployed modules is HDUtil, an auxiliary utility protected with VMProtect and heavily obfuscated. This launcher is used by the SSH bot during an attack to deploy various malicious modules via the target command. Additionally, it implements three auxiliary commands that were not observed during the attacks we analyzed. Nevertheless, their presence and potential capabilities further demonstrate the high degree of integration among all components of the framework.
Active sessions
At startup, the launcher verifies its execution environment by checking the HWID in the contents of %PROGRAMDATA%\hwid.dat, a technique consistently employed throughout the framework. If the file is missing or contains invalid data, such as a non‑MD5 hash, the launcher terminates without performing any further actions. Otherwise, the specified commands are executed. For example, enumsessions provides a list of sessions along with detailed information, including the session type (Console, Services, RDP, and others), username, connection host, and domain. In turn, enumadapters returns the names of all graphics adapters present on the system.
Example output of HDUtil enumeration commands
UAC bypass
The most important command of the launcher is target, which enables payload execution on the system. An optional nouac argument enables automatic UAC bypassing via Windows RPC and an auto-elevated msconfig.exe program, allowing the payload to run with elevated privileges stealthily. This technique has been known for a long time, discovered and described in 2019 by the Project Zero team, who provided a full report with a detailed technical description.
Below is the list of all HDUtil commands.
Command
Description
target [nouac [user=<user>]] [noattach] <file>
Starts file and prints its output.
If optional argument noattach passed, command to be executed in background.
If optional argument nouac passed, automatic UAC bypass to be performed.
If optional argument user passed, new process to be executed under , otherwise default local administrator to be chosen.
pcopy <file> <dir_src> <dir_dst>
Copies file <file> located in <dir_src> to <dir_dst>. Not used by SSH bot.
enumadapters
Prints names of graphical adapters on current system. Not used by SSH bot.
enumsessions
Prints all sessions on current system. Not used by SSH bot.
Browser extensions loader
The first malicious module delivered to the infected system via SFTP is executed using the previously described launcher with the command .\HDUtil.exe target extl.exe. It is a heavily obfuscated DLL injector protected with VMProtect. At startup, the module enters an infinite loop and uses the EnumWindows and IsWindowVisible API methods to enumerate the PIDs of active windows and retrieve the corresponding executable filenames. For processes associated with widely used Chromium‑based browsers, the module invokes a routine that injects a specialized implant.
The injector opens a process, allocates a memory region, and writes the payload directly into this region as unencrypted raw bytes. Then it resolves two exported implant functions, LdrInitMain and LdrCallMain, based on a pre-specified hash derived from a modified version of DJB2 hash function. The first function performs the final PE unpacking, including rebase operations and the initialization of the import and exception tables. The second function directly initiates malware execution.
Setting up protections on the regions and launching the implant
This loader installs malicious browser extensions and hides them from the user. It uses an internal engine that resolves the addresses of stripped functions by analyzing the byte patterns of their calls using YARA-style syntax. This approach enables the malicious code to access critical Chromium engine functions required for extension installation and management. This functionality is also implemented for other browsers with appropriate modifications. For example, in the case of Microsoft Edge, the corresponding DLL msedge.dll is hooked using the specific patterns.
List of the functions hooked by the malware
Using the obtained address of the BrowserProcess object, the loader traverses the inheritance hierarchy and subsequently resolves a pointer to the function responsible for registering observers of browser‑window creation, specifically ProfileManager::BrowserListObserver::OnBrowserAdded. With a specialized built‑in engine, they are hooked using the attacker’s own implementations while preserving the original function’s address.
The loader replaces the functions it finds with its own
When a new Chromium window is opened, a hooked function is invoked that silently installs extensions. This routine scans the user’s %APPDATA% directory, loads all .crx files (Chromium-based browsers extension format), and records them in the ext_table. The extensions are then installed in the browser.
During installation, the extension is unpacked into a non‑default extensions directory, Local Extension Settings, and its manifest is dynamically modified. An object named custom_args is added, containing the fields hwid (the identifier of the infected system) and browser (the name of the browser in which the extension is installed). Then, using previously resolved internal functions of chrome.dll, the extension is installed and all requested permissions are granted.
Extensions are unpacked into a non-default directory
All extensions loaded in this manner are added to a special array to be subsequently identified among regular extensions and to remain hidden from the user.
The remaining patched functions are used to hide the installed malicious extensions from the user. When invoked with registered extensions as parameters, they perform no operation and return a constant value. This enables the threat actor to suppress notifications related to the malicious nature of the extensions and to exclude them from the displayed list of installed extensions. As a result, the behavior of other extensions remains unaffected.
Stub for hiding malicious extensions
During the attack, the Rilide extension was installed on the victim’s system using the previously described loader. Rilide is a stealer targeting Chromium-based browsers that has been frequently used by Russian-speaking threat actors since April 2023. The malware is designed to steal sensitive user data, including login credentials, cookies, and financial information, with a specific emphasis on cryptocurrency theft.
Plugins dispatcher
The final module delivered via SFTP is an open-source utility called Volume2, which is executed with elevated privileges using the command .\HDUtil.exe target nouac noattach Volume2.exe. The executable was linked with the malicious protobuf.dll library. Although the library seems identical to the legitimate DLL, it has been modified to include a malicious exported function, ProtobufGetVer2. This function decrypts and initiates a malicious implant. The payload is encrypted using AES GCM, initialized with a static 256‑bit key and a 96‑bit nonce. The GCM authentication tag is omitted, resulting in the absence of integrity verification. Starting in March 2026, the name of protobuf.dll was changed to version.dll, although its contents remained a modified ProtoBuf library.
Decrypting implant using AES GCM and subsequent mapping
The loaded implant functions as a malicious plugin dispatcher. Upon initialization, it reads and verifies the HWID before establishing communication with the C2 server via the HTTP protocol. Each request follows a predefined binary format: a 2-byte numeric bot identifier encoded in little-endian format, followed by an AES CBC-encrypted JSON object. By default, the BotID is set to 0, and the key and IV consist of 32 and 16 bytes of 0xff, respectively. The implant polls the server every 20 seconds to retrieve new commands. The request contains client data encoded in Base64, and the server may respond with a command containing three mandatory fields: TaskIndex (the command number from the dispatcher), TaskID (a unique task identifier), and HWID (the client identifier). The dispatcher supports four built-in commands:
Task index
Action
1
Reconfigure client: update session keys, assign ID, switch to another C2
2
Load DLL implant into memory and run its entry point
3
Load plugin into process and register tasks with RegisterPlugin function
4
Restart dispatcher as new process
x
If the task number is none of the above, search for it among the registered plugins
Each plugin is required to export two functions: RegisterPlugin and PluginDispatch. These functions are used to manage and configure plugins. The RegisterPlugin function registers the plugin’s tasks with the dispatcher, whereas the PluginDispatch function is invoked when the plugin is called. Both these functions, as well as other external API functions, are located within the base libraries using one algorithm. This algorithm iterates through the export table and uses a specialized callback that calculates the MurmurHash3 hash and compares it against the target value to identify the appropriate function.
Resolving a plugin initialization function
During the analysis, we were able to discover five plugins that implement functions under their unique task identifiers.
CMD wrapper (10xx): allows running scripts and individual commands in cmd.
PowerShell wrapper (11xx): allows running scripts and individual commands in PowerShell.
Environment enumerator (12xx): gathers system information, active sessions, and processes.
Dropper (14xx): downloads an additional payload directly onto the system both from embedded Base64-encoded binary blob and via URL.
Process injector (16xx): launches additional malicious implants on the target system by injecting them into legitimate processes.
We identified four malicious implants that are delivered to the system via the process injector plugin.
ext daemon
The malware is functionally identical to the browser extensions loader (extl.exe) described above, but less obfuscated and not protected with VMProtect.
SeedHunter
Similarly to extl.exe, this malware monitors the list of active processes in the system and injects an implant into Trezor Suite, Ledger Wallet, and Ledger Live processes. The implant is malware that collects seed phrases of Ledger and Trezor cryptocurrency wallets. Initially, it verifies the HWID, and if it fails, it terminates immediately. Then, based on the value of BaseDllName, the malware determines the process context and uses the corresponding implementation for either Trezor or Ledger. It then utilizes the previously described technique to hook the internal Electron framework functions.
List of functions hooked by the malware
Then the malware communicates with the C2 (moonsand[.]store) over HTTPS, sending a Base64-encoded JSON request containing the fields Pid, HWID, and Build. In response, it receives a JSON payload containing the Wait flag. If this flag is set to true, the malware initiates periodic USB device scans filtered by VID and PID (Vendor and Product ID). Upon detecting a connected Trezor or Ledger hardware wallet, it invokes the hooked functions to display a hard‑coded phishing page designed for seed phrase recovery, with a distinct layout used for each identified wallet. If the Wait flag is set to false, the phishing page is displayed immediately.
When the seed phrase is entered and validated, the JavaScript code of the page outputs the phrase to the console prefixed with @:app:print. This prefix helps identify the malware messages in the hooked function mal_LogConsoleMessage.
Phishing pages for seed phrase recovery
The obtained seed phrase is subsequently sent to the C2 server within a JSON payload containing fields such as App (ledger or trezor), Build, DeviceName, DeviceHardwareId, and SeedData. Furthermore, an identical JSON, encrypted with the RC4 algorithm using the HWID as the key, is saved in a temporary directory under the filename sh_<ts>.json, where <ts> is the file creation timestamp.
MC Keylogger
This module is a keylogger that, in addition to recording user input, performs three malicious activities:
Clipboard logging: periodically checks various clipboard formats, including CF_HDROP for files dragged between windows, CF_DIB for copied bitmap images, and CF_UNICODETEXT for Unicode text. Each format is handled appropriately, and all copy events are logged under the Clipboard section. Text data is written directly to the log, while copied files are recorded by their file paths. Images are saved as JPG files following the naming pattern bf_YYYY-MM-DD hh_mm_ss.jpg, and the path to the saved image is added to the log.
Logging connected devices: logs information about USB devices connected to the system, including hardware characteristics like VID, PID, manufacturer, and other details.
Screenshot creation: creates a screenshot every five minutes with a name in the format sc_YYYY-MM-DD hh_mm_ss.jpg. A corresponding message is recorded in the log under the Screenshot section, including the path to the screenshot.
Thus, the keylogger creates three types of different file artifacts, which are placed in a temporary directory. Below is an example of a log file generated by the keylogger.
Example of the keylogger log file
OkoSpyware
This module, which we dubbed OkoSpyware, captures both keystrokes and the video stream of the target application’s window. It first compiles a list of over 100 executable names, including cryptocurrency wallet applications (such as Exodus or Litecoin QT), password managers (such as KeePassXC or 1Password), and other widely used applications, to identify which processes should be monitored among all active system processes. For each identified process, the module uses a bundled FFmpeg instance to capture an MP4 video of the window while concurrently logging keystrokes within that window. The resulting video file is saved in %TEMP% as media_<ts> (where <ts> is the recording’s start timestamp). In the same folder, a JSON file named oko_<ts>.json is created, containing metadata about the captured stream, such as the process name, intercepted input, the stream’s MD5 hash, and additional details.
Example of an OkoSpyware metadata file
The malware also monitors the state of browsers, and when the window title matches a specified regular expression — for instance, a MetaMask or Tonkeeper wallet extension page — it performs video recording and input logging, adding the window title value to the corresponding field in the JSON metadata file.
Artifacts exfiltration
The TookPS script launched via a scheduled task receives a PowerShell exfiltration script as its payload from the C2. All files created by the MC Keylogger and OkoSpyware are sent to the C2 server to the endpoint ir-post.php. After that, the files are deleted from the victim’s system and a command history file, ConsoleHost_history.txt, is cleared.
Sequential exfiltration of artifacts from the temporary directory
Victims
At the time of writing, we have detected hundreds of victims of the OkoBot campaign in more than 25 countries, with the largest proportion of attacked end users found in Brazil, Vietnam, Canada, Mexico, and Türkiye.
Distribution of users attacked by OkoBot by country, April 2025–June 2026 (download)
Attribution
At the time of writing, we can’t attribute this malicious campaign to any known crimeware actor. However, during the analysis, we observed that the servers hosting the PowerShell scripts used in the initial infection stage implement server-side geoblocking. When attempting to retrieve the malicious script using an IP from Russia or CIS countries, the server returns an empty response. This technique is very popular among Russian-speaking threat actors.
It was previously mentioned that the campaign uses the malicious Rilide extension, an infostealer that is actively spreading on Russian-speaking, invitation-only cybercrime forums. Additionally, the source code of the SeedHunter phishing pages includes comments in Russian.
Conclusion
The framework described here has numerous modules — mostly written in C and C++ — that are obfuscated and use a variety of packing techniques. Across all stages, specific patterns and techniques can be identified that are borrowed and used in other modules, which allows us to conclude that there is a close interconnectedness among all stages, forming a full‑fledged high‑level framework. Overall, these modules enable a wide range of functions, such as collecting local files, executing remote commands, downloading arbitrary browser extensions, and stealing crypto wallets.
The OkoBot campaign has been ongoing for over a year, and it remains active at the time of publication. Moreover, it is adapting, which indicates that this framework is being maintained and distribution campaigns continue.
Content In the second quarter of 2026, the AhnLab SEcurity intelligence Center (ASEC) collected and analyzed attack logs targeting poorly managed Linux SSH servers through honeypots. The scope of the analysis covers attack sources that progressed to executing actual malware installation commands, as well as statistics on the malware used in those attacks. Purpose and […]
Contents The AhnLab SEcurity intelligence Center (ASEC) analyzed attack logs from the second quarter of 2026 targeting MS-SQL server and MySQL server installations on Windows. This report summarizes the damage status, attack status, and the classification of the malware and tools used in the attacks. Purpose and Scope The targets are MS-SQL servers and MySQL […]
The percentage of ICS computers on which malicious objects were blocked continued to decrease, reaching 19.6% in Q1 2026. This is the lowest value in three years, and it is 1.4 times lower than in Q2 2023.
Percentage of ICS computers on which malicious objects were blocked, Q2 2023–Q1 2026
Regionally, the percentages ranged from 9.1% in Northern Europe to 27.4% in Africa.
Regions ranked by percentage of attacked ICS computers
The percentage of ICS computers on which malicious objects were blocked increased in five regions over the quarter, most notably in Southern Europe, Northern Europe, and Russia.
In Q1 2026, Southern Europe led the way in growth for internet and email threats. The region also saw the fastest growth in spyware, as well as malicious scripts and phishing pages.
In Russia, the percentage of ICS computers on which malicious objects were blocked exceeded the figures for the previous two quarters. Russia saw an increase in the percentage for threats from the internet, and a slight increase in the figure for threats from email clients (Russia is one of three regions where this figure did not decrease).
Among the threat categories, the greatest increases were observed in the percentages for denylisted internet resources, as well as spyware (distributed in the region via the internet and email clients).
Selected industries
Biometric systems (26.4%) traditionally rank top among the industries and OT infrastructure types covered in this report in terms of the percentage of ICS computers on which malicious objects were blocked. These systems are characterized by internet access, extensive email use for data exchange and approvals (such as access granting), and, in many cases, minimal cybersecurity controls within the organizations that use these systems.
Industries ranked by the percentage of ICS computers on which malicious objects were blocked
Biometric systems rank first among industries in terms of email threats. At the same time, unlike other industries, the percentage for email threats in biometric systems exceeds that for internet threats.
In all selected industries, the global average follows a downward trend. In Q1 2026, the percentage of ICS computers on which malicious objects were blocked increased only in the manufacturing sector — by 1.0 pp. The percentages for this industry increased across 10 regions, with the most notable increases in Western Europe, Northern Europe, and Russia.
Threat categories
In Q1 2026, Kaspersky security solutions blocked malware from 10,052 different malware families of various categories on industrial automation systems.
Over the quarter, the percentage of ICS computers on which denylisted internet resources were blocked increased (after decreasing over the previous two quarters), and there was a slight increase in the percentage for AutoCAD malware.
Percentage of ICS computers on which the activity of malicious objects from various categories was prevented
Malicious scripts and phishing pages (JS and HTML)
Malicious scripts and phishing pages retained their to spot among threat categories by the percentage of ICS computers on which these threats were blocked. The global average in Q1 2026 was 6.56%.
Over the quarter, the percentages increased in four regions. The most significant change was observed in Southern Europe (9.85%, +0.94 pp). The figures for malicious scripts in the region increased over three consecutive quarters.
Among the selected industries, across all regions, the highest percentages for the malicious scripts and phishing pages category were recorded for biometric systems (19.59%) and building automation (15.43%) in Southern Europe. These same industries lead in similar rankings for malicious documents and spyware.
Spyware
The percentage of ICS computers on which spyware was blocked decreased over two consecutive quarters, dropping to 3.73%. Despite the decline, spyware has ranked second among threat categories by the percentage of attacked computers for three consecutive quarters.
The percentages increased in five regions over the quarter, most notably in Southern Europe (5.46%, +0.35 pp) and Russia (2.84%, +0.24 pp).
In Southern Europe, the percentage of ICS computers on which spyware was blocked increased in all the selected industries except manufacturing. The greatest increase was observed in biometric systems.
Among the selected industries, the highest percentage of spyware in Russia was recorded in biometric systems. That said, the percentage of ICS computers on which spyware was blocked increased in all industries in the region except construction. The percentage figure has been increasing for two consecutive quarters in the oil and gas industry (by a factor of 1.63 over six months), and for three consecutive quarters in engineering and ICS integration, as well as electric power. In the remaining sectors, the values have been fluctuating.
Percentage of ICS computers on which spyware was blocked in various industries in Russia, Q3 2025–Q1 2026
Denylisted internet resources
The percentage of ICS computers on which denylisted internet resources were blocked increased to 3.54%.
The most notable increase over the quarter occurred in Southeast Asia (4.58%, +0.65 pp). Among the industries in the region, the highest percentage figures for this threat category were recorded in electric power and construction. Over the quarter, the largest increases in percentages figures were observed in the electric power and manufacturing industries.
In North America (Canada), denylisted internet resources (2.14%) showed the greatest increase among all categories — by a factor of 1.22.
Among the selected industries across all regions, the highest percentage figures for the denylisted internet resources category were in the electric power (7.11%) and construction (6.25%) industries in Southeast Asia.
Malicious documents (Microsoft Office + PDF)
The percentage figure for this category decreased over two consecutive quarters, reaching its lowest value (1.56%) for the entire period of observations in Q1 2026. It increased just in two regions: Australia and New Zealand (1.12%, +0.04 pp), and Russia (0.62%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for malicious documents were recorded for biometric systems (9.02%) and building automation (6.97%) in Southern Europe. These same industries also lead in similar rankings for malicious scripts and spyware.
Ransomware
The percentage of ICS computers on which ransomware was blocked has decreased for two consecutive quarters, dropping to 0.14%. This is the lowest value among all categories.
The percentage increased in two regions: North America (Canada) (0.11%, +0.04 pp) and slightly in Northern Europe (0.06%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for ransomware were recorded in the oil and gas and manufacturing industries (0.92% and 0.65%, respectively) in Central Asia and the South Caucasus, and in biometric systems (0.89%) in Russia.
Miners in the form of executable files for Windows
The percentage of ICS computers on which miners in the form of executable files for Windows were blocked decreased to 0.59%.
The percentage increased in seven regions. The largest increase was observed in Africa (0.63%, +0.16 pp). Among the selected industries, the largest increases in the region were in the manufacturing and oil and gas industries.
Among the selected industries across all regions, the highest percentages for miners in the form of executable files were recorded in construction (1.99%), biometric systems (1.98%), and the oil and gas industry (1.97%) in Central Asia and the South Caucasus.
Web miners
The percentage of ICS computers on which web miners were blocked has been declining for a year, and in Q1 2026, it reached the lowest value for the entire period under review (0.22%).
At the same time, the percentage increased in seven regions. The largest increases were observed in South Asia (0.28%, +0.11 pp), the Middle East (0.31%, +0.09 pp), and Africa (0.34%, +0.08 pp). Despite the increases, the percentages in these regions for Q1 2026 did not exceed those observed in 2023–2024 and in Q1 2025.
Among the selected industries across all regions, the highest percentages for web miners were recorded for biometric systems (0.97%) in Russia. Biometric systems in South Asia (0.79%) ranked second, and the electric power sector in Southeast Asia (0.76%) ranked third.
Worms
The percentage of ICS computers on which worms were blocked decreased to 1.33%.
The percentage decreased across all regions following an increase in the previous quarter (due to a wave of phishing attacks that distributed the Backdoor.MSIL.XWorm backdoor worm across all regions of the world).
Among the selected industries across all regions, the highest percentage figure for worms was recorded for biometric systems (4.80%) in Central Asia and the South Caucasus. Two industries in Africa – biometric systems (4.04%) and electric power (3.53%) – took the second and third spots, respectively.
Viruses
The percentage of ICS computers on which viruses were blocked decreased to 1.31%.
The top 3 regions by this figure remained the same: Southeast Asia (6.11%, first by a wide margin), Africa (4.15%), and East Asia (2.97%). These same regions are also among the leaders by the percentage of systems affected by AutoCAD malware. The largest increase in this figure was observed in Africa (+0.41 pp).
Among the selected industries across all regions, the highest percentages for viruses were recorded in the construction industry (6.35%) and building automation (5.50%) in Southeast Asia.
Malware for AutoCAD
The percentage of ICS computers on which malware for AutoCAD was blocked increased to 0.30%.
The most notable increase over the quarter was observed in Africa, with the region’s percentage figure rising by 0.47 pp, a very significant increase for this category, and almost doubling (to 0.91%).
Among the selected industries across all regions, the highest percentages for AutoCAD malware were recorded in the construction industry in East Asia (5.58%) and Southeast Asia (3.87%).
Main threat sources
In Q1 2026, the average percentages across all threat sources, except threats from the internet, decreased globally.
Percentage of ICS computers on which malicious objects from various sources were blocked
Internet
The percentage of ICS computers on which threats from the internet were blocked increased to 7.88%. However, over the past three years, the percentage figure for internet threats has followed a downward trend.
The largest increases in the percentages were recorded in Southern Europe (8.59%, +0.59 pp), Southeast Asia (10.16%, +0.55 pp), and Northern Europe (4.47%, +0.51 pp).
Among the selected industries across all regions, the highest percentages for threats from the internet were recorded in electric power (13.16%) and construction (12.55%) in Southeast Asia, and in the engineering and ICS integration sector (12.33%) in South Asia.
Email clients
The percentage of ICS computers on which threats delivered via email clients were blocked decreased to 2.59%. This is a three-year low.
The percentage of this threat source increased in three regions: Southern Europe (6.54%, +0.2 pp), East Asia (1.5%, +0.09 pp), and slightly in Russia (0.7%, +0.04 pp).
Among the selected industries across all regions, the highest percentages for email threats were recorded for biometric systems (19.78%) and building automation (12.34%) in Southern Europe. In these two industries, the percentage of ICS computers on which email threats are blocked is higher than the percentage for threats from the internet. A similar situation was observed in two other instances, both in biometric systems (in South America and Southeast Asia).
Removable media
The percentage of ICS computers on which threats were detected when connecting removable media continued to decrease, reaching its lowest value for the period under review (0.26%).
Among the selected industries across all regions, the highest percentages for removable media threats blocked on ICS computers were observed in the electric power sector in Central Asia and the South Caucasus (1.45%), East Asia (1.34%), and Africa (1.16%).
Network folders
The percentage of ICS computers on which threats are blocked in network folders is steadily decreasing. In Q1 2026, it was the lowest for the period under review (0.029%).
East Asia has traditionally led by a wide margin. The percentage for East Asia (0.135%) is 27 times higher than the lowest regional value (recorded in Northern Europe).
The largest increases in the percentages for threats from network folders were observed in Africa (0.037%, +0.006 pp) and South America (0.013%, +0.006 pp).
Among the selected industries across all regions, the construction industry in East Asia, at 0.36%, holds the top positions in the ranking by the percentage of ICS computers on which threats are blocked in network folders.
The following analysis presents the key findings from Kaspersky Compromise Assessment engagements performed in 2025. A compromise assessment is an independent, expert-driven service that examines whether a target network has been compromised. The service combines threat intelligence analysis (including darknet sources), tool-aided endpoint scanning, a systematic review of security event logs and network traffic, and, when necessary, an initial incident response and digital forensic investigation.
This report focuses on missed incidents – threats that remained undetected for weeks, months, or even years.
Key trends observed during compromise assessment engagements
Proactive compromise assessment decreases the number of missed high-severity incidents. The highest proportions of high-severity incidents were revealed in organizations that requested our compromise assessment service after containing a known incident. The lowest proportions of high-severity incidents were observed in organizations that conducted regular audits. Of all the incidents discovered, 20% were found manually, while enterprises missed 60% because of the absence of high-confidence alerts from the tools in place.
Nearly a third of discovered incidents took over three months to detect. The longer a threat persisted in the target environment, the greater the likelihood that an incident would be severe. 30.8% of all discovered incidents and 52% of high-severity compromises had historical activity spanning over three months. The oldest incident discovered in 2025 had gone undetected for four years.
Malicious files often remain in backups and are restored after incident response activities. 40% of all discovered web shells resided in backups and went unnoticed until a proper compromise assessment was conducted.
Threat actors rely on remote management tools and LoLBins. These types of tools were found in all compromise assessment engagements that resulted in an incident detection.
Monitoring tools and controls are not self-sufficient; operational maturity makes the difference. Monitoring tools must be configured and adapted to the changing threat landscape. Furthermore, human analysts need to review low-confidence alerts. A lack of continuous monitoring and threat hunting activities increased the likelihood of high- and medium-severity incidents to 84–86%. At the same time, high‑severity incidents were rare among organizations with in-house capabilities to reverse-engineer malware.
Communication issues lead to missed incidents. Nearly a third of the compromise assessments revealed communication issues that impacted incident response activities.
The incident response playbook is not set in stone. For incident response to be efficient and effective, playbooks must be updated as new artifacts are discovered. Treating the incident response plan as a living document reduces the risk of missing threats.
About the Kaspersky Compromise Assessment service
Our global compromise assessment portfolio spans several regions. In 2025, around 71% of the incidents we identified affected our customers in the META region, while the APAC and CIS regions accounted for the remaining 29%.
Geographic distribution of incidents identified during Kaspersky Compromise Assessment projects in 2025 (download)
Our service was requested by organizations from a diverse set of sectors. The government sector accounted for around 29% of incidents, followed by the education (19%) and financial (17%) sectors.
Distribution of economy sector incidents identified during Kaspersky Compromise Assessment projects in 2025 (download)
Detection logic families
Our compromise assessments operate on a continuously updated catalogue of indicators of attack (IoAs). Because the raw set of IoAs is too granular for high-level reporting, we map them to a concise set of detection logic families. The statistics indicate that three detection families dominate the incident mix:
Credentials from dumps: 12.4% of all incidents;
Specific living-off-the-land (LOTL) tools: 11.2 %;
Specific malware families: 11.2 %.
These three detection logic families represent high-fidelity indicators of attack that reliably signal infrastructure compromises ranging from dormant, disk-based malware to persistent and multi-stage attacks.
Distribution of detection logic families (download)
Reasons for requesting Kaspersky Compromise Assessment services
Analysis of our compromise assessment engagements that took place in 2025 reveals a clear correlation between the stated purpose of the engagement and the risk profile of the findings. General audits dominate the portfolio with 56% of requests, followed by authority reporting engagements (19%), post-incident checkups (17%), and acquisitions (9%).
Statistics on the reasons behind CA project requests (download)
When the findings are classified by severity, the post-incident checkup category exhibits the highest proportion of high-severity incidents (40.7%). The full breakdown is shown below.
Incident severity breakdown by service engagement reason
Incident severity (%)
High
Medium
Low
Reason for service
Acquiring new company
28.6
42.8
28.6
General audit
27.7
36.7
35.6
Report to an authority
30
46.7
23.3
Checkup after a cybersecurity incident
40.7
25.9
33.4
Post-incident checkups are frequently initiated after an initial incident response (IR) effort. The elevated share of high-severity findings suggests that IR activities, which are typically limited to containing a known incident, do not provide a complete view of the broader environment. Consequently, other threats may remain undetected until a full compromise assessment is performed.
Merger and acquisition-related assessments are proactive assessments performed when a company acquires another entity. This involves the target’s network being scanned for hidden threats before the two environments are merged. These assessments demonstrate a balanced distribution of severity: 28.6% low-severity, 42.8% medium-severity, and 28.6 % high-severity. This reflects the mixed risk posture of target environments of acquisitions, which are often evaluated for both known vulnerabilities and hidden malicious activity. Similarly, other proactive approaches like general audit assessments or assessments driven by the need to regularly submit a compliance report to a regulatory authority, share almost the same ratio. This indicates that regular, proactive and compliance-oriented assessments tend to reveal substantive issues earlier in the attack lifecycle, reducing the likelihood that they will evolve into high-severity incidents.
Organizations that conduct regular audits have the highest rate of low-severity findings (36%) and the lowest rate of high-severity issues (28%). We can assume with medium confidence that continuous, proactive compromise assessments are more effective at limiting the emergence of high-severity compromises than reactive, incident-driven evaluations. The data collected in 2025 are consistent with this hypothesis. Integrating regular, third-party compromise assessments into governance processes can therefore reduce the probability of unexpected high-severity findings and improve overall risk posture.
The following case study illustrates the impact of relying on a reactive rather than proactive approach. It describes a persistent threat that remained dormant on a client’s network and was only discovered after a comprehensive compromise assessment was performed following initial IR activity.
Case study: Dormant threat uncovered only by a compromise assessment
A midsize enterprise suffered a high-severity intrusion that was contained and remediated by the IR team within the defined scope of the initial alert. Following containment, the organization requested a check to determine if any additional footholds existed elsewhere in the network. To address this need, the organization engaged Kaspersky’s Compromise Assessment (CA) service, which performed a full forensic review of the environment beyond the scope of the initial incident.
Compromise assessment experts collected forensic metadata, historical security event logs, and Active Directory configuration data from the entire infrastructure. Threat hunting queries were executed against the aggregated telemetry, focusing on persistence mechanisms, lateral movement artifacts, and anomalous process activity. As a result, a number of severe threats were detected and reported; for example, malicious persistence:
A cron job that recreates a web shell
A critical Linux system (web server) had a cron job that automated fetched a copy of a PHP web shell from a public GitHub repository and placed it in an online directory. Even if the file was removed by security personnel, the cron job would simply download it again, giving the attacker a persistent remote code execution point on the web server.
A live reverse shell
On a server hosting a published web application, the process list showed a bash reverse shell.It was run by a user with the username “apache,” which was the account used to run the web application. This may indicate that the attacker exploited a vulnerability in the web application to gain remote code execution, allowing them to establish a reliable command and control channel that bypassed the firewall because it was initiated from inside the network.
ClipBanker data stealer persisting via Windows registry
A ClipBanker variant was detected on a user’s workstation machine maintaining persistence by adding itself to the registry key HKU\S-1-5-21-[REDACTED]-500\Software\Microsoft\Windows\CurrentVersion\Run\9Er6IIp.
This was done after adding the malware’s folder to Windows Defender exclusions and applying hidden and system attributes to the file to hide it from regular users.
Malicious WMI event consumer with deceptive alias
A malicious WMI event consumer was detected that downloads and executes a PowerShell script. It created the alias “Kaspersky” for “Invoke-Expression” in an attempt to blend in as legitimate activity in the hope that a quick glance at the script would not raise suspicion. Kaspersky’s Cyber Threat Intelligence confirmed that the downloaded script (no longer reachable) was a weaponized payload used to spread the infection further.
The IR containment was rapid, focused and effective in addressing the specific incident that triggered the alert. However, the broad-scope compromise assessment revealed multiple backdoors across the environment, each using a different persistence technique: cron jobs, scheduled registry runs, and WMI subscriptions. The infected hosts were outside the original IR scope, so they remained unseen until a comprehensive hunt was conducted.
Incident response excels at stopping the bleeding and ensuring business continuity after a known incident. A compromise assessment provides a health check that determines whether any other wounds exist. By pairing timely IR with regular, full network compromise assessments, the organization had both the reactive agility to contain incidents and the proactive visibility to eradicate malicious persistence wherever it was hiding. The investigation uncovered additional undetected footholds, providing a clearer view of the environment and reducing the likelihood of a repeat incident.
Missed long-term incidents
The statistics on the mean time to detect (MTTD) incidents identified during compromise assessment projects are concerning. Many incidents go unnoticed for extended periods. For example, in 2025 we identified an incident that was approximately four years old!
Such prolonged detection times can lead to severe consequences, as 30.8% of incidents have historical activity spanning over three months. These incidents can range from dormant malware to persistent threats, highlighting the need for robust detection and response mechanisms.
Severity distribution of incidents by MTTD (download)
The relationship between detection latency and incident severity was analyzed by grouping findings according to their MTTD:
For incidents detected within the first month, severity is more or less evenly distributed among the low, medium and high categories.
However, as the MTTD increases, the severity of incidents shifts towards higher severity. Notably, a high proportion of incidents that took between 30–60 days to be detected are medium-severity incidents (78.57%), while those detected between 60–90 days are predominantly high-severity (71.43%).
Among incidents detected after 90 days, a significant proportion are also high-severity incidents (52%).
Overall, 52% of high-severity incidents are only identified after 90 days of going undetected. This represents a concrete risk: the longer an incident goes undetected, the higher the probability of severe compromise. Organizations that integrate continuous detection, threat hunting activities, and regular compromise assessments can reduce MTTD, limit threat escalation, and lower their overall risk profile.
The following case study highlights the importance of timely detection and response to prevent incidents from escalating into high-severity events.
Case study: Four-year-old crypto mining activity on domain controllers
In May 2025, our compromise assessment experts identified three domain controllers on a customer network that were infected with malicious files. The files had remained hidden for almost four years. They were created in the C:\Windows\Fonts\Mysql directory, abusing its unique characteristic whereby only font files in this directory are visible to regular users. Files with the names nei.bat, dl1host.exe, bat.bat, cmd.bat, and a spoofed svchost.exe were found there. These files were created in June and July of 2021.
Kaspersky Threat Intelligence confirmed that these files are part of a crypto-mining campaign called NSABuffMiner, which spreads via the SMB protocol by exploiting the EternalBlue (MS17-010) vulnerability. A patch was released for this vulnerability in March 2017, four years before the initial compromise. This was more than enough time to patch the systems. This underscores the importance of implementing effective patch management operations and staying informed through threat intelligence news feeds.
Based on the organization’s request, the malicious files were collected along with a forensic image for analysis and revealed the following:
bat.bat and cmd.bat generate random IPs and scan them with a lightweight port scanner renamed taskhost.exe to locate live hosts with SMB port 445 and NetBIOS port 139 open and looking for vulnerable machines.
Discovered vulnerable IPs are handed to helper scripts named bat, poab.bat, load.bat, and loab.bat that execute the malware mance.exe, Eter.exe, and puls.exe to inject the malicious DLLs Eternalblue2.dll and Doublepulsar2.dll into lsass.exe and explorer.exe, enabling lateral movement.
Persistence is then established by creating scheduled tasks to execute the propagation and infection scripts, and services are created to execute the crypto miner, with the names MicrosoftMysql, MicrosoftFonts, and MicrosoftMSSql. Other scheduled tasks were also observed with the names At1 and At2 and created for the same purpose.
After successfully compromising the machine and installing the persistence mechanisms, a cleanup task is performed to delete temporary files and dropped malware.
Because of the lack of proper monitoring and threat hunting procedures, the organization was unaware that a mining operation had been hijacking their resources for four years, running on their domain controllers.
Unintentional malware preservation
An issue that is frequently discovered during compromise assessment activities is that of web shells remaining or being restored on target systems. Based on data collected during 2025 compromise assessment engagements, 64% of web shell incidents were classified as high-severity findings, 7% as low-severity (possibly legitimate files, but potentially compromised), and 29% as medium-severity findings requiring eradication.
Web shell incident distribution by severity (download)
One way web shells persist is through infected backups. The distribution of discovered incidents in our projects shows that 60% of the web shells were located on active systems, while 40% were stored in backups. Restoring such backups can reintroduce the threat long after the initial infection.
Another common issue is asset inventory gaps, which were observed in 25% of engagements. This resulted in untracked devices, particularly cloud-only Linux web servers that are not joined to Active Directory, evading routine scans.
An attacker can plant a web shell on such a cloud server, and that server never appears in the inventory, though is still regularly backed up. As a result, the web shell may persist on the cloud server for a long time. If it is occasionally deleted, the backup server later restores the infected files, exposing the web shell to third parties again. This demonstrates that without a complete and up-to-date asset inventory, detection capabilities are significantly impaired.
One case was observed in which the web shell was located on an internal file server (not a web server) within a .rar archive at the following path: D:\backup\[redacted_for_privacy].rar/wwwroot/<…>/[redacted_for_privacy].aspx
During the investigation, the server administrators indicated that the folder had been copied from a different server that was offline at the time of the assessment. Because of poor asset inventory, the company’s security team did not detect the infection of this server. As a result of the backup procedure, the web shell was copied to the internal file server. Forensic analysis of the offline server revealed that the adversary had introduced a backdoor to the majority of the Windows servers in the environment, configuring the local administrator account with an identical password.
The technique involved using PsExec to execute a .cmd script across all the servers listed in a .txt file; the script altered the local administrator password to a common value:
Legitimate, yet suspicious: LoLBins and remote management tools
In 2025, nonstandard remote management (RM) utilities were observed in all compromise assessment engagements. Living-off-the-land binaries (LoLBins) were also present in every engagement. These findings highlight the ongoing challenge for security operations centers (SOCs) that must distinguish between legitimate administrative use and malicious abuse.
The observed remote management utilities span both proprietary platforms, such as TeamViewer and AnyDesk, and freely available tools, including PsExec, VNC servers, and open-source RM frameworks. These binaries are used daily in many environments for troubleshooting, software deployment, or remote support. However, the same capabilities – creating a new local admin account, copying files to a remote share, or launching a network port scan for diagnostics – are also typical of attacker post-exploitation activity. Our analysts frequently encounter cases where a legitimate sysadmin action resembles a lateral movement step. This makes the mere fact that “a remote management tool was executed” insufficient to classify it as an incident. Instead, the incident must be judged against an organization-specific baseline of expected usage. Establishing that baseline requires a deep, contextual understanding of who is authorized to run the tool, from which endpoints, and under which circumstances – a resource-intensive process on a case-by-case basis.
LoLBins, binaries that are part of the operating system or commonly installed utilities (such as certutil, bitsadmin, regsvr32, and wmic), were also present in every assessment. While these files are trusted system components, threat intelligence confirms they are often repurposed for lateral movement, data exfiltration, and persistence. The graph below shows the severity distribution for incidents involving riskware or a LoLBin binary. The relatively high share of medium- (40%) and high-severity (31%) findings underscores that misuse of legitimate utilities is often the vector that enables a compromise to progress beyond the initial foothold.
Severity distribution of incidents involving riskware or LoLBin involvement (2025) (download)
To address the potential use of LoLBins and remote management tools by attackers, we recommend a multi-layered approach that goes beyond static deny lists:
Formalize a policy that enumerates the remote management tools authorized for use. The policy must be coupled with a requirement to forward software operational logs to a central log management platform (SIEM or dedicated log collector). Continuous monitoring of these logs enables a SOC to detect deviations from authorized usage patterns.
Periodically perform a software inventory audit to identify unauthorized remote management tools. Consider collecting data from the following registry keys on all hosts:
Enrich the hashes (MD5/SHA-256) of every executed binary with a functional category, such as “Remote Access”, “Golden Image”, or “Security Software.” Correlating the category with the execution path makes it possible to hunt for instances where a “Remote Access” binary runs from a non-standard location, such as %TEMP% or a user’s Downloads folder.
Deploy detection rules that capture known LoLBin abuse patterns, such as certutil -decode, bitsadmin -transfer, regsvr32 -i <dll>, wmic process call create. These rules should be continuously baselined against the organization’s normal activity. The baseline is derived from a period of verified legitimate use and refreshed whenever new legitimate use cases emerge. Alerts are generated only when observed behavior diverges from the established norm, thereby reducing noise while preserving sensitivity to genuine abuse.
Impact of not having continuous monitoring and proactive threat hunting
Analyses of recent compromise assessment projects reveal a systematic blind spot in organizations that follow the security-by-purchase model to defend their networks. Without continuous human monitoring or a dedicated threat hunting program, the severity profile of detected incidents becomes heavily skewed toward a higher impact:
Incident severity breakdown, where 24/7 monitoring or threat hunting is absent
Control type
Low-severity
Medium/high-severity
No continuous monitoring
14%
86%
No threat hunting
16%
84%
Often, the problem is not a lack of tools, but rather a lack of operational use of those tools. Many enterprises deploy next-generation security solutions and then let them run in “set-and-forget” mode, or they rely exclusively on an alert-driven workflow. The following issues are common in such organizations:
Alert fatigue: high false positive rates drown analysts in noise, forcing them to triage superficial indicators rather than conduct deep, contextual investigations.
Fragmented analyst assignment: without a dedicated hunting team, the same analyst may be tasked with dozens of unrelated alerts, limiting the time available for the hypothesis-driven exploration required to uncover stealthy footholds.
The practical consequence is that adversaries retain an extended dwell time, enabling continued lateral movement and data exfiltration before the organization becomes aware of the breach. This pattern represents a measurable risk exposure that translates directly into business impact. As the following example illustrates, merely purchasing security controls does not guarantee detection; continuous monitoring, regular alert validation, and structured threat hunting are essential to reduce dwell time and limit business impact.
Case study: Secure by design without continuous monitoring
The enterprise invested in security controls and assumed that the environment was secure by design. However, security controls require proper configuration, continuous tuning, and active monitoring to be effective. The tools had been installed, but no one was ensuring that the security controls were configured effectively, there was no analyst reviewing the alerts they produced, and no schedule existed to review the collected logs.
The organization opted for Kaspersky’s Compromise Assessment service. Historical security logs were collected and investigated as part of the assessment procedures. The goal was simple: to determine what had really been going on in the network over the previous few months.
Log analysis revealed clear evidence of malicious activity. Activities related to Impacket behavior were discovered that led to the deployment of Cobalt Strike and Mimikatz on several critical servers, including the domain controllers. These activities were three months old at the time of detection, and the enterprise was unaware of them because there was no effective 24/7 monitoring in place.
Impacket is a collection of Python scripts for network protocols and low-level network packet manipulation. Attackers can abuse it to move laterally into the network. The following are examples of its artifacts detected in the network:
The attacker used Impacket to execute a PowerShell command that downloaded an executable from a command-and-control server. This server was found to be associated with Cobalt Strike. Cobalt Strike is a post-exploitation tool that provides capabilities for remote command execution and lateral movement within a compromised network. The execution was set up via a scheduled task that attempted to masquerade as a legitimate Google Chrome update task.
The timeline assessment confirmed the presence of a Mimikatz binary and a memory dump associated with the same incident on the compromised system, confirming that a credential theft operation had indeed taken place.
The organization was completely unaware of the breach. The activity had gone undetected for three months because the deployed controls were never monitored. Upon learning of the findings, a full-scale incident response was initiated to eradicate the footholds, rotate credentials, and harden the security of the environment.
Security controls are not self-sufficient. Deploying a firewall or an EDR solution does not automatically protect you. Without proper configuration, baseline tuning, and, most critically, continuous log monitoring and threat hunting, those controls become merely decorative. Always-on monitoring, either performed internally or delegated to an external managed security service, can turn weeks-old compromises into minutes-old alerts by correlating events, hunting for anomalous use of penetration testing or hacking tools, and escalating suspicious activity.
Incident response action statistics
An analysis of historical compromise assessment projects reveals a persistent discrepancy between the best practices described in incident response playbooks and the operational realities of executing them in unprepared, often legacy-affected environments. The figure below shows how frequently each response action was required during the initial response phase of a compromise assessment.
Incident response actions required after compromise assessment (download)
The distribution highlights three frequently observed patterns:
Forensic analysis accounts for the majority of cases, with around 59% requiring at least one forensic package collection and analysis.
Remote eradication, i.e., file or registry key removal, was reported in 39% of cases.
Plans evolve as the investigation proceeds; 39% of engagements required a mid-engagement plan update, reflecting the iterative nature of incident response.
Why forensic collection is the default entry point
Forensic package collection and analysis was the most frequent response action, occurring in 59% of cases. The prevalence of forensic package collection can be explained by two observable factors in CA engagements: (1) the targeted organization’s limited historical visibility and (2) the fact that a substantial proportion of incidents were older than 90 days at the start of the assessment. In many cases, native logs had already been rotated or purged, forcing investigators to rely on residual artifacts (e.g., MFT entries, registry hives, filesystem timestamps) to reconstruct timelines.
Our observations suggest that remote forensic package collection is effectively a prerequisite rather than an optional convenience. The graph below summarizes the reported ability to collect forensic packages, categorized by incident severity level. It highlights that, in a significant proportion of high-severity cases, the affected organization lacked this capability.
The organization’s ability to collect forensic data by incident severity (download)
Containment: The remove files/registry keys paradox
Response execution and eradication actions, such as file or registry key removal (reported in 39% of cases), were also common. However, they highlighted a notable gap in execution practices. While many organizations reported having EDR capabilities for remote removal, execution was often delegated to IT teams or MSPs via ticketing systems. This can introduce delays and reduce the precision of the removal process. Malware removal is a surgical process, particularly in multi-stage, fileless, or persistence-heavy scenarios. Capability alone is insufficient without expertise, sequencing, and planning, especially when artifacts may exist in shadow copies, backups, hidden paths, or downloader chains.
Communication failures: An additional operational overhead
A notable organizational finding emerged regarding communication. In 32% of projects, internal communication issues at the assessed organization materially impacted response execution. Below are the typical blockers:
Unclear action confirmation – system administrators could not quickly confirm whether a suspicious file was legitimate.
Delayed owner validation – ticket escalations stalled while waiting for system owners to respond.
Compromised communication channels – email accounts or ticketing portals may already be under the attacker’s control in the event of a suspected domain compromise.
Staff turnover – loss of knowledge about historical configuration baselines.
These findings suggest that regular tabletop exercises are required to test not only technical playbooks, but also human and communication workflows, as well as operational level agreements that govern and facilitate communication between different teams, and standard operating procedures for proper documentation.
The iterative nature of response plan updates
The need to update response plans based on new analytical input arose in 39% of cases, emphasizing the inherently iterative nature of incident response. Early-stage plans cannot realistically account for all variables. Examples of the most commonly observed causes for updating the response plan are listed below:
Reverse engineering results that reveal previously unknown command-and-control (C2) servers or behaviors.
Forensic discoveries, such as hidden scheduled tasks, shadow-copy artifacts, or dormant DLLs.
Traffic analysis outcomes that expose additional lateral movement paths.
Human constraints – unavailable system owners, changes in management processes, or supervisor approval.
Based on our experience, teams that treat the IR plan as a living document – incorporating each new artifact, reprioritizing actions, and reissuing the playbook before the next containment step – reduce the risk of missed eradication steps. Conversely, strict adherence to an initial, evidence-limited plan can increase the risk of overlooking persistent footholds.
Distinguishing real attacker artifacts from penetration testing leftovers
Finally, distinguishing attacker activity from penetration testing artifacts remained a recurring challenge (12% of cases). Compromise assessments frequently uncover remnants of legitimate testing tools, which can create uncertainty about whether a detected artifact originated from a malicious intrusion or a legitimate penetration test. Contributing factors:
Poorly documented penetration test report and artifact cleanup.
Overlapping toolsets (e.g., SharpHound) used by both red team operators and adversaries.
Running compromise assessments and active penetration testing projects simultaneously, which degrades analyst focus and increases false positive rates. Although correlating findings with penetration testing reports is essential, compromise assessments are human-driven investigative processes, and confusing analysts with overlapping “legitimate” attack signals leads to misinterpretation and weaker outcomes.
Incident response maturity and its effect on severity
Our data show a correlation between the presence of internal digital forensics or malware reverse engineering capabilities and the distribution of incident severity categories. Across the 2025 compromise assessment engagements, the distribution of low-, medium- and high-severity findings differed markedly between organizations that possessed these capabilities and those that did not. The data below illustrate this correlation and provide a basis for assessing the business value of expanding internal response skill sets.
Incident severity split for cases requiring digital forensics, based on an organization’s capabilities (download)
Organizations capable of analyzing digital forensic artifacts independently experienced half as many high-severity incidents and a higher proportion of low- and medium-severity cases.
Incident severity split for cases requiring malware analysis, based on an organization’s capabilities (download)
The presence of a dedicated reverse engineering resource correlates with a total absence of high-severity cases in our sample set; the majority of incidents were rated as medium severity, with a significant proportion of low-severity outcomes.
The analysis of this correlation indicates, with medium confidence, that the observed shifts are unlikely to be caused solely by sample size effects. Rather, they are more likely to reflect a genuine operational phenomenon: internal digital forensics and malware analysis capabilities contribute not only to SOC processes, but also to cyber-resilience in general.
Case study: In-memory LionTail infection on critical Windows servers
During a compromise assessment, a persistent in-memory threat was identified on several critical servers. The activity was attributed to the LionTail framework, a sophisticated set of custom loaders and memory-resident shellcode implants. LionTail takes advantage of undocumented Windows HTTP.sys driver behaviors to covertly deliver and retrieve payloads via inbound HTTP traffic, effectively blending malicious activity into legitimate network flows.
Several observed variants are attributed to the Scarred Manticore actor, which generates a unique implant per compromised host and performs data exfiltration while carefully masking command-and-control communications within normal-looking traffic.
Detection was achieved through static memory signatures discovered within the scrcons.exe process. Although scrcons.exe is a legitimate WMI host binary located under C:\Windows\System32\wbem, it is frequently abused to host injected payloads, making it an attractive target for stealthy in-memory operations.
The response plan comprised a number of actions, the most critical of which are highlighted below:
Collection of volatile memory dumps for in-depth analysis.
Acquisition of full forensic disk images from affected systems.
Detailed analysis of the collected artifacts and subsequent updates to the incident response plan.
Executing these actions proved challenging for the organization because of its limited digital forensics and reverse engineering capabilities. In incidents dominated by fileless memory-resident threats, these capabilities are not optional – they are essential. Without them, organizations risk losing critical evidence, misjudging the scope of the compromise, or failing to fully eradicate advanced implants that leave minimal traces on disk.
While our specialists were able to complete the investigation and contain the breach, the case revealed a readiness gap. It demonstrated the operational risk of depending on external assistance during high‑impact incidents and reinforced the necessity of in‑house forensic and reverse‑engineering maturity to achieve timely, confident and comprehensive incident handling.
Solving the root cause problems
Upon completion of a compromise assessment engagement, the focus shifts from incident response to a consulting phase. The final workshop focuses on preventing recurrence of incidents by identifying underlying deficiencies that allowed them to go unnoticed. The recommendations are actionable and tailored to the environment. For the purpose of this report, they have been grouped into a limited set of high-level categories.
Root-cause category
Share of incidents
Typical findings
Insufficient detection fidelity
60.7%
• No high-confidence alerts were generated by the EPP/EDR or related log sources.
• In 9.4% of cases, the product was mis-configured or out of date or malfunctioning.
Missing alert-driven monitoring
35.9%
• Alerts that could have indicated compromise were generated, but an incident was not declared.
• Signals with high uncertainty (e.g., heuristic web shell detections) required analyst validation.
Deficient vulnerability and configuration management
28.2%
• Evident misconfigurations (e.g., disabled audit logging, over-permissive service accounts).
• Known vulnerabilities left unpatched or unmitigated.
Lack of structured threat hunting processes
27.4%
• Low-fidelity alerts were never reexamined after initial dismissal.
• High-volume telemetry remained unchecked due to staffing constraints.
Inadequate security awareness programs
25.6%
• Credential leaks from personal devices of employees or contractors accounted for 27.2% of incidents where inadequate security awareness was identified.
• Social engineering attempts were successful because of insufficient user training.
Absence of documented policies/processes
23.9%
• No formal incident response playbooks, change management procedures or data handling guidelines were available.
Common observations on root causes
The detection health check was the most frequent corrective action. In more than half of the cases where alerts were missing, a simple verification of sensor health and rule relevance was recommended to fill the gap. Without such validation, immediate attribution of the failure to the product capability could not be made.
Human analysis is still essential for low-confidence alerts. Automated pipelines alone cannot compensate for rules prone to false positives (e.g., generic web shell heuristics). Embedding a manual triage step was recommended to reduce the dwell time for incidents.
Process hygiene (vulnerability management, threat hunting, security policies) accounts for a substantial proportion of the root causes. Even mature organizations exhibited gaps in routine activities that could be mitigated with disciplined workflows. The absence of documented policies/processes was the root cause of 23.9% of cases.
A modern example of a policy gap is the use of generative AI development tools that operate without clear data handling rules. During one project, we identified a macOS workstation that executed the Claude Code (Anthropic) command-line assistant as a VS Code extension. The tool automatically captured filesystem snapshots to enrich its language model prompts. These snapshots included full directory listings and absolute paths to several Excel workbooks containing internal confidential data:
ls -lh /Users/[REDACTED]/Documents/[REDACTED].xlsx /Users/[REDACTED]/Documents/[REDACTED].xlsx /Users/[REDACTED]/Documents/[REDACTED].xlsx .. [REDACTED]
The organization was advised to conduct awareness sessions for employees on the risk of exposing confidential internal data to generative AI tools, and to develop a policy governing the use of such tools with confidential information.
Lack of detections: Causes and impacts
Compromise assessment engagements repeatedly show that insufficient detection fidelity is a significant contributing factor to high-severity incidents. In cases where the target organization’s detection coverage was rated low, 52% of incidents were classified as high severity and 15% as low severity. This suggests a correlation: limited visibility appears to increase the proportion of incidents that evolve into high-severity compromises.
Incident severity distribution when detection coverage was insufficient (download)
A common assumption is that engaging a managed security service provider (MSSP) improves detection maturity. The data, however, show a more nuanced picture. Even when an MSSP is engaged, 26.5% of incidents related to low detection coverage remain unidentified, and roughly 50% of MSSP-supported projects have basic Windows audit gaps (e.g., missing event log collection or disabled audit policies).
These findings suggest that outsourcing alone does not guarantee effective detection; active governance and continuous validation are required. Detection should be treated as an evolving capability that requires continuous testing, measurement, and refinement, irrespective of whether it is managed internally or by a third party.
Statistics of missed incidents due to lack of detection capability with or without MSSP (download)
The analysis of root causes of missed detections reveals several recurring themes. In many environments, the technology is present but poorly operationalized. The main issues are:
Absence of endpoint protection platform (EPP) health check – nearly 50% of incidents escalated to high severity in engagements where the EPP health check was weak or absent. This reflects the classic “installed-but-not-enforced” risk, where agents are present but not tuned, updated, or validated.
Threat intelligence gaps – when there was no functional threat intelligence feed or platform, about half of the incidents reached high severity. Without curated indicators of compromise and contextual enrichment, analysts rely on generic alerts and may overlook known malicious behaviors.
The underlying issue is an alert-driven, set-and-forget mindset: organizations assume that deployed tools will automatically protect them, even though the tools are not continuously tuned, validated, or enriched with threat intelligence.
Incident severity breakdown where there was no EPP health check or threat intelligence
Missing control
High-severity
Medium-severity
Low-severity
EPP health check
48.3%
36.7%
15%
Threat intelligence feed
50%
40%
10%
Detection failures are rarely caused by a single missing control; they emerge from weak configuration, insufficient telemetry, and an absence of regular checks of controls and processes to ensure they are functional, especially in outsourced models. A hybrid monitoring approach that combines internal ownership with external MDR or MSSP support consistently proves to be the most resilient model when roles, expectations, and performance metrics are clearly defined. Detection must be treated as a living function, not a procurement outcome.
The following example illustrates the real-world consequences of control gaps by walking through a severe incident that persisted undetected for months simply because the organization lacked the necessary detection capabilities and security tools.
Case study: In-memory PurpleFox infection evades conventional endpoint protection
During a compromise assessment engagement, memory was scanned on the target hosts using the threat hunting rule set. Two hidden objects were identified:
PurpleFox rootkit code injected into legitimate svchost.exe processes on several critical servers.
PurpleFox drops specially crafted DLLs and forces svchost.exe to load them. From there, it installs a kernel-mode driver that gives the attacker persistent and stealthy execution capabilities, as well as the ability to pull additional payloads. This results in the loading of the XMRig miner.
The deployed EPP solution monitored file creation, registry modifications and network connections. However, its memory inspection module was disabled. Additionally, the signature set applied at the time of the assessment was not up to date. As a result, no alerts were generated for the injected DLLs or the miner’s shellcode. The compromise assessment team identified this detection gap during the memory analysis phase and documented the missing in-memory inspection capability in the final report.
The organization’s security operations were outsourced to an MSSP, which collected the logs and forwarded them to the SIEM solution. Because the logs never contained alerts for in-memory activity, PurpleFox activity was not identified.
Insufficient vulnerability management: A catalyst for high-severity compromises
In the 2025 compromise assessment engagements, more than half of the threats identified and linked to insufficient vulnerability management practices or missing patches were classified as high severity. The most frequently observed consequences were the deployment of web shells that enabled persistent remote code execution and the exploitation of misconfigured Active Directory instances.
Severity distribution of incidents due to improper vulnerability management (download)
The root causes of missing patches are multifaceted. They include inadequate asset inventory management (25% of projects) and the absence of formal vulnerability management processes (41% of projects). Moreover, 86% of organizations that claimed to have a vulnerability management program still exhibited exploited misconfigurations during compromise assessment engagements. These findings suggest that robust patch management, comprehensive asset inventory practices, and structured vulnerability management processes are critical for preventing high-severity incidents.
Case study: How overly permissive GPO-based software distribution goes wrong
During multiple compromise assessment engagements, a high-impact misconfiguration was consistently observed: a Group Policy Object (GPO) was used to point to an executable in a shared folder and run it on every workstation via a scheduled task. The access control list (ACL) on the share was set to “Everyone – Full Control”.
Given that any authenticated domain user can write to the share, an attacker who compromises a single low-privilege account can replace the legitimate binary with a malicious payload. The next scheduled task run propagates the payload automatically to all endpoints that receive the GPO. This provides:
Elevated execution context: the scheduled task typically runs under the SYSTEM or local administrator account.
Automatic lateral movement: the malicious binary propagates without requiring additional network exploitation.
Privilege escalation: a compromised low-privilege account can lead to domain administrator code execution.
Vulnerability management procedures that include systematic GPO and share permission audits would have flagged the writeable ACL as a high-severity finding, enabling remediation before exploitation. Remediation typically involves restricting the share permissions to “Authenticated Users” with read-only access and limiting modifications to certain privileged accounts. Incorporating these checks into the baseline security controls reduces the attack surface, demonstrating the tangible risk reduction achievable through disciplined vulnerability assessment and penetration testing (VAPT) practices.
Conclusion
In 2025, Kaspersky Compromise Assessment helped organizations reveal a persistent detection gap: 30.8% of all incidents and 52% of high-severity compromises had historical activity spanning over three months. Of all the incidents discovered, 20% were found manually, while 60% were missed by enterprises because of the absence of high-confidence alerts from existing tools. The oldest missed incident identified by the Kaspersky Compromise Assessment team in 2025 was four years old.
Post-incident checkups produced the highest percentage of high-severity findings, while regular proactive audits, compliance-driven audits, and audits performed before merging two networks tended to reveal issues earlier. This indicates that purely reactive investigations often miss hidden persistence. The top high-level recommendations for immediate improvement in 2025 for all projects were:
Run a comprehensive detection engine health check within 30 days of project closure, prioritizing telemetry integrity and rule relevance.
Introduce a Tier 1 alert validation team that reviews all low-confidence events on a defined schedule.
Ensure robust 24/7 monitoring augmented with threat hunting capabilities focused on baselining, low-fidelity alerts, and emerging adversary techniques.
Reevaluate the vulnerability management pipeline to ensure continuous patching and audit log activation across all critical assets.
Update security awareness curricula to address credential leakage from personal devices and reinforce secure BYOD practices.
Ensure periodic tabletop exercises are run to test technical playbooks and sharpen the team’s skills and communication workflows.
Establish operational-level agreements to govern and facilitate communication between different teams and standard operating procedures used for proper documentation.
Addressing the root cause categories systematically will reduce the likelihood of future blind spots and improve the overall security posture of the engaged organizations.
Entrar
