A StreamRat banking trojan campaign uses fake Meta TV-streaming ads to infect Android users. The StreamRat banking trojan enables full device takeover.
While monitoring Mirage Kitten activity, we uncovered a previously undocumented malware family that we dubbed NodeRabbit. We identified the first sample on a system in Afghanistan. Further threat hunting revealed two additional, more advanced, variants: one on a system in Egypt and another on a system in Ethiopia.
NodeRabbit is a cross-platform remote access trojan (RAT) built with Node.js. It targets Windows, Linux, and macOS. Its operators deliver it through spear-phishing messages on LinkedIn and other job search platforms that contain trojanized coding challenge archives.
During the same investigation, we discovered another previously undocumented malware family that we dubbed PollCat. Like NodeRabbit, PollCat is a cross-platform RAT, but it is written in obfuscated JavaScript also distributed through trojanized coding challenge archives.
Mirage Kitten has historically relied on native malware written in languages such as C, C++, and Go, often deploying it through DLL search-order hijacking. NodeRabbit and PollCat represent the first publicly documented use of Node.js- and JavaScript-based malware by this APT group.
Kaspersky’s products detect this threat as Trojan.JS.MirageKitten.*
Background
During recent threat research, we detected suspicious activity on a system in Afghanistan. We traced it to an archive containing a software development project that the user may have received during a job application process. The archive purported to contain a coding challenge for candidates applying for an engineering role.
The archive, Front-Technical-Challenge.zip (MD5: 1EA83E4E4592B01E4ACAB63EB867BEE5), was hosted in an Amazon S3 bucket at: https://oracle-challenge.s3[.]us-east-1.amazonaws[.]com/Front-Technical-Challenge.zip
It contained TaskFlow, an app for software engineering assessment built with Express, React, and Vite. The accompanying README instructed the candidate to review the application and fix defects in its frontend. It also claimed that server.js was bug-free and should not be modified, conveniently directing attention away from the only application source file the attackers had altered.
README file for a trojanized coding challenge app
The README also imposed a three-hour time limit and prohibited the use of AI assistants. Notably, an AI code-review assistant tasked with auditing the project would likely have flagged the suspicious first-line import of an unknown npm package and warned the targeted developer that the project was trojanized.
Rules and time limit included in the trojanized coding challenge app README file
The first line of server.js imported a trojanized npm package named colorized_terminal, version 2.1.0. The attackers bundled the package directly in the challenge task archive’s node_modules directory rather than publishing it to the npm registry. When imported, the package silently launched an implant from node_modules/.cache/.320697f1/index.js as a detached background process.
Retrospective threat hunting across our telemetry revealed the broader scope of the campaign. We identified three NodeRabbit variants with a shared code lineage; each was recovered from a system in a different country. The operators delivered the variants through similarly themed coding challenges and used two trojanized packages, colorized_terminal and pretty-log, both pinned to version 2.1.0.
The campaign also delivered PollCat, a second RAT with a substantially different structure, through a separate coding challenge lure. We’ll analyze PollCat later in this research.
Initial access
The infection chain begins with fake recruiter accounts contacting prospective targets on a job search platform. According to a publicly cited source, a threat actor posing as a talent acquisition specialist at a major technology company contacted a software engineer and advertised a job opening, inviting the target to complete a technical assessment.
The target received a link to a coding challenge hosted on Amazon S3 and was pressured to download and run the project immediately. This public post matches the delivery chain we reconstructed from our telemetry: recruiter outreach on a job search platform, a coding challenge presented as a technical assessment, and a trojanized project archive hosted on legitimate cloud infrastructure.
NodeRabbit RAT: the first variant
We discovered the first NodeRabbit variant on a system in Afghanistan. The malware was concealed within the TaskFlow assessment at node_modules/.cache/.320697f1/index.js and executed by the trojanized colorized_terminal package.
Once running, NodeRabbit generates a unique agent identifier from available host information. It calculates the SHA-256 hash of the hostname, username, operating system version, architecture, and MAC address, then truncates the result to its first 32 hexadecimal characters.
NodeRabbit binds a TCP listener to 127.0.0.1:48739. This listener acts as a single-instance mechanism. If the malware cannot bind to the port, it assumes that another instance is already running and terminates silently.
NodeRabbit uses a persistence mechanism for each operating system:
Operating system
Persistence mechanism
Windows
Copies itself to %APPDATA%\Microsoft\EdgeUpdate\msedge_update.js; clones the local node.exe to nodew.exe in the same folder and patches its PE subsystem from Console to Windows GUI to suppress the console window; creates HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftEdgeUpdate registry key executing nodew.exe msedge_update.js
Linux
Copies itself to ~/.config/microsoft-edge-update/msedge_update.js and creates an @reboot cron entry that invokes the script using the current Node.js executable.
macOS
Copies itself to ~/.config/microsoft-edge-update, creates ~/Library/LaunchAgents/com.microsoft.edgeupdate.plist configuration file pointing at the copy’s location with RunAtLoad and KeepAlive parameters, and attempts to load it.
The malware communicates with its command-and-control servers through three API endpoints, choosing from the following Azure-hosted C2 infrastructure addresses. On failure, it switches to the next C2 address:
NodeRabbit serializes each C2 request object as JSON and wraps it with AES-256-GCM. The AES key is the SHA-256 digest of an ASCII seed embedded into the agent. Every request uses a fresh 12-byte IV and a 16-byte authentication tag:
The malware sends encrypted requests using the following structure:
C2 responses are structured the same way and may contain a command to execute. We observed the first NodeRabbit variant supporting 11 commands:
Command
Functionality
sys:info
Return hostname, domain user information, username, and process ID.
proc:list
List running processes.
proc:start
Execute an arbitrary shell command.
fs:list
List a directory.
fs:read
Read a file in chunks and return Base64 data.
fs:write
Decode Base64 and write it at a chosen file offset.
fs:delete
Delete a file or recursively delete a directory.
fs:mkdir
Create directories recursively.
net:config
Enumerate adapters, MAC addresses, IP addresses, and DNS settings.
agent:sleep
Change the beacon interval.
script:exec
Write a base64 Node.js script to a randomly named .tmp file, execute it and delete it.
NodeRabbit RAT: the second variant
Retrospective threat hunting following the discovery in Afghanistan led us to a second infection on a system in Egypt. This sample is a more advanced NodeRabbit variant, launched through the trojanized pretty-log package instead of colorized_terminal.
Before running its core functionality, the malware checks whether the host resembles an analysis environment. It terminates if it detects limited system memory, a low CPU count, short system uptime, analyst-associated usernames or hostnames, or common analysis tools running on the system.
Before terminating, the malware generates benign HEAD requests to www.google.com, www.microsoft.com, and www.cloudflare.com, then exits without ever contacting its C2 infrastructure. Most likely, it attempts to look less suspicious by showing some benign activity before exiting.
Variant 2 implements partial corporate proxy support: it checks HTTP(S) proxy environment variables, Windows Internet Settings, including an explicit PAC URL, and WinHTTP configuration; tunnels its HTTPS C2 through HTTP CONNECT. It first tries to establish an unauthenticated connection. If it fails, it retries using URL-embedded basic credentials. Finally, it delegates Windows NTLM/Negotiate challenges to curl.exe --proxy-anyauth --proxy-user. It caches the proxy-discovery result, including when no proxy is found, for five minutes. If the polling loop detects a network-interface or IP-address change, it clears the cache and runs proxy discovery again on the next checkin.
To make sure a single instance is running, Variant 2 uses a host-specific port derived from the agent identifier instead of the fixed TCP port used by the first variant. It interprets the first four hexadecimal characters of the identifier as an integer and applies the following calculation: 41984 + (value mod 5000).
The resulting listener port falls between 41984 and 46983. Unlike the shared port used by Variant 1, this port varies depending on the infected host.
For persistence, Variant 2 masquerades as Intel Driver & Support Assistant. The exact persistence mechanism, once again, depends on the operating system.
Operating system
Persistence mechanism
Windows
Copies itself to %LOCALAPPDATA%\Intel\DSA\idriver_support.js. It then copies the local node.exe binary to IntelDSA.exe and changes its PE subsystem from Console to Windows GUI, suppressing the console window. Finally, it creates a scheduled task named IntelDriverSupportUpdate, which runs daily at 10AM and executes IntelDSA.exe with the dropped script.
Linux
Copies itself to ~/.config/intel-dsa/idriver_support.js and creates an @reboot cron entry.
macOS
Copies itself to ~/Library/Application Support/Intel DSA/idriver_support.js and creates the LaunchAgent com.intel.dsa.helper with RunAtLoad and KeepAlive enabled.
NodeRabbit RAT: the third variant
Further threat hunting identified a third NodeRabbit variant on a system in Ethiopia. Like the second variant, it is launched through the trojanized pretty-log package. It retains much of the previous variant’s functionality but introduces significant changes to its command-and-control configuration, command set, and persistence mechanisms.
The third variant communicates with its C2 infrastructure through a different set of API endpoints:
Method
Endpoint
Purpose
POST
/sdk/v2/ready
Register agent and host info
POST
/sdk/v2/config
Poll for commands
POST
/sdk/v2/events
Submit results
We observed the malware using a C2 chain composed of Azure- and Cloudflare-hosted domains.
For persistence, Variant 3 implements the following mechanisms depending on the operating system in use:
Operating system
Persistence mechanism
Windows
Attempts to copy the payload to ProgramData or LocalAppData, create a build-specific daily 10AM task, and start the copied payload. To choose the exact directory, it tries to list C:\Windows\System32\config. If successful, it selects ProgramData with /ru SYSTEM /rl highest; in case of a failure, it selects LocalAppData without explicit /ru or /rl settings.
macOS
Copies the payload to ~/Library/Application Support, creates and loads a RunAtLoad/KeepAlive LaunchAgent and starts the copied payload.
Linux
Copies the payload to ~/.local/share, attempts to add an @reboot cron entry, and starts the copied payload. If crontab -l fails, persistence is skipped.
WSL
Uses the payload copied for persistence on the main Linux system, as described above. Writes launcher.vbs under the Windows user profile, and creates a daily 10AM Windows task that relaunches it through wscript.exe and wsl.exe.
A new command, agent:servers, replaces the active in-memory C2 server list and can write the updated list to .sv.json. The third variant retains the original 11 commands and adds 12 new ones, bringing the total to 23.
New commands
Functionality
fs:drives
Enumerate accessible Windows drive letters or WSL-mounted drives
proc:exec
Execute a process
proc:kill
Kill process by PID or image name
agent:servers
Replace the active C2 and attempt to keep the new configuration
agent:getchain
Return the current C2
outlook:emails
Harvest account addresses from Outlook OST and PST artifacts
persist:check
Check selected VS Code, scheduled-task, and Run-key persistence indicators
persist:vscode
Attempt to install a fake VS Code extension and Windows Run value
persist:vscode:remove
Remove the fake extension
persist:projects:scan
Search recent and common development locations for Git repositories
persist:project:inject
Inject a launcher into a repository’s Git hooks
persist:project:remove
Remove the marked Git-hook launcher
Beyond the persistence mechanisms described above, Variant 3 introduces two additional persistence mechanisms that relaunch the malware through common developer workflows.
1. Malicious VS Code extension
The persist:vscode command first copies the payload to its build-specific install path. If a compatible extension directory exists, it creates a fake extension displayed as GitHub Copilot Helper, with the description AI coding assistant helper service and the activation event on StartupFinished.
The extension’s extension.js file attempts to start the installed payload as a detached Node.js process. To look less suspicious to the user, it uses a trusted publisher name borrowed from local extension metadata or a trustedPublishers value found in state.vscdb. However, no signature or trusted status is copied.
Separately, the handler tries to disable Workspace Trust if the VS Code User directory exists. On Windows, it attempts to establish persistence using a current-user Run registry key value even if the extension directory is missing.
2. Git hook injection
Git-hook persistence works in two steps. First, persist:projects:scan checks recent VS Code workspace paths directly. Under common locations such as ~/projects and ~/source, it checks only the first 60 immediate children, not the root itself, and returns no more than 20 repositories.
For a selected repository, persist:project:inject appends a marked launcher to .git/hooks/post-merge and .git/hooks/post-checkout by default. The marker is # shepherd-persist; the line following the marker attempts to start the installed payload with Node in the background. A later Git operation must trigger one of those hooks, and the referenced Node executable and payload must still exist.
PollCat RAT
While tracking NodeRabbit infections, we discovered another malicious tool we dubbed PollCat, which is also distributed under the guise of a programming challenge. The sample we obtained resides inside RankChallenge-react, a React code-fixing challenge presented as a time-limited developer assessment. Running the project invokes npm i && node index.js, which starts the local application and attempts to open the challenge in the user’s browser.
Although the visible exercise is not a security CTF, the project uses CTF terminology in several places. The root package is named ctf-server, the backend prints CTF server running, the frontend uses several ctf-* storage keys, and the tutorial refers to path/to/ctf. These repeated labels, together with instructions that do not fully match the delivered application, are consistent with an AI-assisted or template-generated project. One possible explanation is that the attacker prompted an AI coding assistant to create a CTF-style React platform and later inserted the malicious components.
README instructions and challenge overview included in the trojanized React coding project
The PDF tutorial contained in the same archive as the project tells the target to click Continue, enter a six-digit OTP code, and complete the challenge within a one-hour session. It states that codes are supplied by the recruiter, are single-use, and expire quickly; the visible login page also claims that codes rotate every 30 seconds. In the delivery scenario described by the investigation, the threat actor posing as a recruiter could provide the code directly to the targeted developer. This gives the operator control over access to the lure, while the expiring code and countdown create a sense of urgency, pressuring the target to run the project and complete the assessment quickly, potentially accelerating the infection process.
One-hour session window enforced by the trojanized coding challenge
The bundled .env file contains the JWT signing secret, OTP service URL, and OTP client ID.
Configuration embedded in .env file of the trojanized coding project, including the OTP service URL and client identifier
The application forwards submitted codes to an attacker-managed domain registered in late June-2026: https://lifespotify[.]com/api/users/b879746e-fed9-4211-a6da-4d8223681267/otp/validate.
That said, PollCat starts independently of the OTP authentication process. During application startup, app.js loads requireAuth.js, which imports and immediately starts the malicious requireObjects.js component. PollCat can therefore begin C2 registration and command polling while the application is still loading, before the user enters an access code.
A failed OTP validation prevents the user from accessing the protected challenge features, but PollCat continues running in the background. A successful OTP validation issues a JWT and creates another worker that starts an additional PollCat instance. The first authenticated request also triggers the persistence attempt.
Persistence starts when the first request carrying a valid JWT reaches the protected middleware. PollCat then uses one of the following methods:
Operation system
Persistence mechanism
Windows
Writes package.json and requireObject.js to %APPDATA%\Microsoft\Network, runs npm install, and creates a daily task named NetSync_<username> and scheduled for 09AM that runs the worker with Node.js.
Linux
Writes the worker to ~/.node_packages, runs npm i, and appends both a daily 09AM cron line and an @reboot line.
macOS
Uses the same ~/.node_packages copy and cron path, then creates and loads ~/Library/LaunchAgents/com.harsh.requireobject.plist with RunAtLoad and a daily 09AM trigger.
Once active, PollCat identifies the host as 129--<hostname> and iterates over the following C2s until registration succeeds:
After registration, PollCat sends host information to /gate/hello, polls /gate/fetch for commands, and returns results through /gate/submit. All endpoints in use are presented in the table below.
Method
Endpoint
Purpose
POST
/beacon
Register the client and obtain a socketId and optional timing values.
POST
/gate/hello
Submit host, user, domain, OS information, and its current privilege level.
GET
/gate/fetch?token=<socketId>
Poll for commands.
POST
/gate/submit
Submit a Base64-encoded command-result structure.
GET
/vault/<uuid>
Retrieve a hosted file and write it to the victim machine.
PUT
/vault/push/
Upload a local file or file chunk to the C2.
POST
/gate/track
Report chunk-upload progress.
By default, PollCat RAT polls every two minutes with up to five seconds of jitter. Commands and results are stored as little-endian binary records and carried as Base64 text.
PollCat RAT declares 22 commands, but three of them have no implementation:
Command
Functionality
0x02 (DIR)
List a directory.
0x03 (MV)
Move a file or directory.
0x04 (RUN)
Execute a shell command.
0x05 (TASKLIST)
List running processes.
0x06 (DEL)
Delete a file or directory.
0x07 (UPLOAD)
Download a file from the C2 to the victim’s machine.
0x08 (DOWNLOAD)
Upload a local file to the C2.
0X09 (DRIVES)
List drives, volumes, or mount points.
0X0A (TERMINATE)
Terminate a process by PID.
0X0B (RUNDLL)
Load a DLL and call an exported function on Windows.
0X0C (MKDIR)
Create a directory.
0X0D (ZIP)
Create or extract a ZIP archive.
0X0E (CHUNKED_DOWNLOAD)
Upload a local file in chunks.
0X0F (RUN_HIDDEN)
Start a hidden background process.
0X20 (EVAL_JS)
Execute JavaScript supplied by the C2.
0X30 (SYSTEM_CHECK)
Collect process and software inventory.
0XA1 (WS_DOWNLOAD)
Defined but not implemented.
0xB0 (REQUEST_ELEVATION)
Defined but not implemented.
0XB1 (PERSIST)
Defined but not implemented.
0xF0 (SET_SLEEP_TIME)
Change the polling interval.
0XF1 (SET_IDLE_TIME)
Store an idle-time value.
0xF2 (SET_JITTER_TIME)
Change polling jitter.
The command names UPLOAD, DOWNLOAD, and CHUNKED_DOWNLOAD are written from the C2’s perspective. UPLOAD sends a C2-hosted file to the victim’s machine, while the two download commands transfer victim files back to the C2.
EVAL_JS runs JavaScript supplied by the C2 and gives that code access to Node.js modules, files, processes, networking, and child-process functions. SYSTEM_CHECK collects the names of running processes and lists files and folders from:
%SystemDrive%\Program Files
%SystemDrive%\Program Files (x86)
%LOCALAPPDATA%
%LOCALAPPDATA%\Programs
%APPDATA%
%USERPROFILE%
%APPDATA%\Microsoft\Outlook
%LOCALAPPDATA%\Microsoft\Olk\Attachments
%USERPROFILE%\Documents
It also searches for folders matching 24 hardcoded strings corresponding to security software vendor names: ‘Google’, ‘Microsoft’, ‘Palo Alto Networks’, ‘Cisco’, ‘VMware’, ‘Fortinet’, ‘Citrix’, ‘CheckPoint’, ‘Juniper Networks’, ‘LogMeIn’, ‘Sophos’, ‘Symantec’, ‘Trend Micro’, ‘McAfee’, ‘Kaspersky Lab’, ‘ESET’, ‘Bitdefender’, ‘Avast Software’, ‘CrowdStrike’, ‘SentinelOne’, ‘Malwarebytes’, ‘BraveSoftware’, ‘Tencent’, and ‘Naver’.
When PollCat finds a matching folder, it lists that folder’s root contents. It does not recursively scan the entire product directory. The detailed inventory, including process names, directory listings, and collected paths, is sent as JSON to POST /api/system-details/result.
Infrastructure
Mirage Kitten continues to rely on Azure Websites and Cloudflare-backed domains to hinder infrastructure discovery and tracking. More importantly, the use of Microsoft Azure subdomains for C2 helps the traffic blend into legitimate organizational network activity. In some cases that we encountered during our research, the actors even incorporated the targeted organization’s name into the Azure subdomain, making C2 communications appear more like normal business traffic originating from an employee machine during regular business days.
Based on our analysis of Mirage Kitten’s infrastructure, we identified certain patterns across several command-and-control channels, including msmanagementgrp[.]com and visitfinancedentists[.]com
Further investigation based on these patterns led to the discovery of approximately 11 additional infrastructure assets attributed to the same group.
Domain
Creation date
Registrar
healthful-hub[.]com
2026-07-03
NameCheap, Inc.
neumedicahealthcare[.]com
2026-07-03
NameCheap, Inc.
optimumhealthcredit[.]com
2026-07-03
NameCheap, Inc.
healthfullyrecipes[.]com
2026-06-30
NameCheap, Inc.
refreshhealthandwellness[.]com
2026-06-09
NameCheap, Inc.
healthvitalitycare[.]com
2026-05-18
NameCheap, Inc.
aceofspadesmanagement[.]com
2026-05-18
NameCheap, Inc.
glmediaagency[.]com
2026-05-18
NameCheap, Inc.
digimediaskill[.]com
2026-05-18
NameCheap, Inc.
healthyweightplan[.]com
2026-05-18
NameCheap, Inc.
mens-health-online[.]com
2026-05-15
NameCheap, Inc.
Victims
Based on our telemetry, we identified victims in fintech, aviation and aerospace sectors across the Middle East and Africa – specifically, in Egypt, Ethiopia and Afghanistan.
We also observed submissions of ZIP archives with trojanized projects containing NodeRabbit and PollCat to an online multi-scanner originating from several countries, including India, Türkiye, Israel, Iraq, Germany, and Ireland.
Attribution
We attribute this activity to Mirage Kitten with a high degree of confidence based on the following observations:
Structural similarities with the Retrograde/MiniFast native DLL backdoor (MD5:810F8E3B88EB05F710C09552941D6F56)
Initial C2 handshake and session establishment logic. Both PollCat and Retrograde/MiniFast follow a similar C2 handshake flow. Each builds a JSON request body containing host information and sends it via an HTTP POST request. Notably, both treat HTTP 400 as a successful handshake response rather than an error, parsing the response body to extract a socketId, which is then stored and used as the session token for subsequent C2 communication.
Similar C2 handshake and socketId session establishment logic in MiniFast/Retrograde and PollCat
Host registration. Both PollCat and Retrograde/MiniFast register the infected host with the C2 server by sending a structurally similar JSON request body containing the session token and host information.
Command fetching similarities. The similarities extend to command retrieval. Both PollCat and Retrograde/MiniFast periodically poll the C2 server using an HTTP GET request containing the previously assigned socketId as a token. Retrograde/MiniFast uses GET /agent/poll?token=<socketId>, while PollCat follows the same pattern with GET /gate/fetch?token=<socketId>, demonstrating a closely aligned C2 communication structure.
Beacon timing similarities. PollCat and the Retrograde/MiniFast share identical beacon timing defaults: a polling interval of 120,000 ms (0x1D4C0), a jitter of 5,000 ms (0x1388), and a retry timeout of 60,000 ms (0xEA60). This further highlights the structural similarities between the two C2 communication implementations.
Command set similarities. PollCat and Retrograde/MiniFast share several commands and command IDs. Notably, PollCat declares REQUEST_ELEVATION (0xB0) and PERSIST (0xB1) but does not implement them. In MiniFast, both are functional: 0xB0 performs UAC elevation, while 0xB1 creates the WindowsSecurityUpdate scheduled task for persistence.
Command set similarities between MiniFast/Retrograde and PollCat, including shared command identifiers
Proxy authentication similarities. NodeRabbit delegates corporate-proxy NTLM/Negotiate authentication to curl.exe --proxy-anyauth --proxy-user, using the victim’s logon session. Retrograde/MiniFast native DLL implements the same approach natively through WinHttpQueryAuthSchemes and WinHttpSetCredentials with NULL credentials. This shared proxy-aware C2 design suggests the same development approach across both malware families.
Speaking of victimology, the attacks are consistent with Mirage Kitten’s known geographic targeting, with the group maintaining a strong focus on entities across Africa and the Middle East, this time with a particular focus on the aviation and FinTech sectors.
As for the operational infrastructure, Mirage Kitten has historically hosted its initial ZIP lures on legitimate third-party services. Previously, it used onlyoffice.com for this purpose. In this activity, the group shifted to Amazon S3 buckets.
Finally, the combination of Azure Websites and Cloudflare‑backed domains has been a hallmark of Mirage Kitten’s TTPs, which we have observed across NodeRabbit and PollCat.
Conclusions
Mirage Kitten’s latest activity marks a notable evolution in the group’s tooling: NodeRabbit and PollCat are the group’s first Node.js/JavaScript-based implants, departing from its usual native malware deployed through DLL search-order hijacking. The shift to cross-platform scripting gives the operators a single codebase that runs on Windows, Linux, and macOS, with payloads that blend naturally into developer workstations.
The delivery mechanism, however, remains consistent with Mirage Kitten’s historical tradecraft: the use of recruiter personas on LinkedIn to target critical sectors across the Middle East and Africa for cyberespionage purposes. We continue to track the group’s activity and will report on new developments in future publications.
The new ToxicPanda 2.0 banking Trojan attacks target hundreds of financial apps globally. Learn how this ToxicPanda 2.0 banking Trojan steals credentials.
Attackers typically try to pass off malware as legitimate applications or as potentially unwanted programs that users deliberately search for and download, such as cheats or cracks. They often rely on ad and affiliate networks to deliver their creations to victims’ devices. This post examines a less conventional case: a well-known backdoor distributed under the guise of adware. The attackers may have chosen this distribution method because the adware was signed by the developer. On top of that, users often manually add these apps to exclusions, so their useful features don’t get blocked.
Some time ago, a client asked us to analyze a file with the MD5 hash c24e99f9437feacaa63766a3cde3fe3d and add it to our detection database. We initially classified it as adware, but a cursory analysis turned up suspicious network activity, which prompted us to dig deeper. It turned out the sample did far more than serve ads. In fact, its advertising functionality doesn’t even work; instead, it triggers an infection chain that delivers the ValleyRAT backdoor.
Malicious installer
The file the client shared with us turned out to be an installer that performed different actions depending on the two-letter suffix used in the file name, positioned just before the numeric string.
Installer name
What it does
FS_SETUP_DD_173.exe
Installs DingTalk, a workplace collaboration platform
FS_SETUP_GG_173.exe
Installs Google Chrome
FS_SETUP_HY_173.exe
Opens hxxps://meeting[.]tencent[.]com/download/
These actions are most likely designed to divert the user’s attention away from the sample’s malicious functionality. Regardless of the file name, the installer deploys a modified Chinese desktop wallpaper management tool called QN Wallpaper (hxxps://qnwallpaper[.]keansoft[.]cn/) and adds it to the registry’s autorun entries.
The original version of QN Wallpaper is genuine adware: on installation, it delivers bundled partner apps to the device and then displays ad banners to the user. In this case, however, the attackers use it to carry out DLL sideloading, a technique that allows malicious code to run under the guise of a signed process by way of a malicious DLL.
The QN Wallpaper modules, along with the malicious components, are unpacked to C:\Program Files\QNWallpaper\5.4.0.1662\<random string of letters and digits>. The following files are saved in that directory:
File name
MD5
Purpose
1.zip
7ad1e3ef4e6d9d636c9e7e967733850e
Archive containing the adware files QnWallpeper.exe and QnwPlayer.exe, along with the modules needed to run them
7z.dll
96b4c1d0683dce22bd3223e1e40689c1
7z archiver library
7z.exe
9b86d3ab6cef15c633933fbbeab39c0a
Archiver
chrome_elf.dll
edfdc30cbd85879776b8f735ea7de1f1
Library used to launch Electron-based applications
libcef.dll
07ddbbe2c71c45577a7a4fbcdba0df91
Malicious library
PeLoader
48826d5ca845979d2e6ebd66dc1aae90
File containing the encrypted backdoor
QnWallpaper.exe
6c158c0f8e029342192d4f0d72e102b7
Adware module
QnwPlayer.exe
9a71d6a41cd258b9e89cdc5fc224de73
Adware module
<random string of letters and digits>Nedca.exe
c24e99f9437feacaa63766a3cde3fe3d
Malicious installer copy
After unpacking, the installer uses the DisableAntiSpyware registry key to disable Windows Defender and then launches QnWallpaper.exe.
Disabling Windows Defender
DLL Sideloading via libcef.dll
QnWallpaper.exe has dependencies in libcef.dll, so this library gets loaded when the process starts. QnWallpaper.exe also launches QnwPlayer.exe, which likewise calls libcef.dll.
QnWallpaper and QnwPlayer won’t actually function correctly, because the functions exported from libcef.dll are put into an infinite sleep. However, in case that sleep is ever interrupted, the attackers have implemented a function that loads all the necessary functions from the original library into memory, provided it can locate that library on the system.
Example of an exported function
Loading functions from the original libcef.dll
The malicious functionality in libcef.dll is invoked by a call to DllMain, which runs automatically when the library is loaded. That said, alongside the original exports, the library also contains a function named RunDLL, which likewise initiates execution of the malicious code. QnWallpaper never calls this function. We suspect the attackers intended to invoke it manually via rundll32 or planned to use a separate executable for this purpose, one that wasn’t included in the package downloaded by the sample.
The RunDLL function
Running the malicious code
When the library is loaded, code runs that ensures QnWallpaper.exe persists at startup: it adds a file extension association and drops a file with the corresponding extension in C:\Documents and Settings\<username>\Start Menu\Programs\Startup\.
This is followed by a chain of wrapper functions whose main job is to call the next one. Execution eventually reaches the function that contains the actual malicious code. For convenience, we’ll refer to it as mw_entry.
Inside mw_entry, the malware checks two things:
Whether the current user belongs to the Administrators group
Which process the DLL is running inside
Checking for administrator privileges
If the user isn’t a member of the Administrators group, the program attempts to obtain administrator privileges by using the runas utility.
Relaunching the process to obtain administrator privileges
Once it has administrator privileges, the malicious code determines which process the DLL has been loaded into, and selects the payload accordingly:
If the library is running inside QnWallpaper.exe, the payload is loaded from the PeLoader file.
Encrypted payload
If the library is running inside QnwPlayer.exe, the payload is loaded from libcef.dll resources.
Retrieving the payload from a resource
Both payloads are AES-encrypted DLLs that contain the ValleyRAT backdoor. The only difference between them is their configuration, specifically, the C2 server addresses. After decryption, libcef.dll checks the magic signatures in the resulting PE file’s headers to confirm the sample is valid. If this check fails, the library releases its resources and takes no further action.
Validating the PE file headers after decryption
If the headers check out, libcef.dll loads the payload into the process’s memory space and hands control over to the backdoor by calling DllMain.
Calling DllMain
ValleyRAT
ValleyRAT begins its operation by parsing its configuration, which consists of key:value pairs concatenated into a single string. To obfuscate this configuration, the attackers wrote the string in reverse.
Obfuscated configuration
During parsing, the backdoor restores the correct character order and reads the key values one by one. The set of keys is the same regardless of which process the backdoor is running in.
Parsing the configuration
Some of the configuration fields are listed below:
Key
Description
p?
C2 server IP address
o?
C2 server port
t?
Protocol (1: TCP, 0: UDP)
dd
Sleep duration before executing the main code
cl
Sleep duration after receiving the corresponding command from the server
bz
Configuration creation date
bh
Whether to mark the current process as critical (so that terminating it triggers a blue screen of death) Possible values: 1: yes, 0: no
ll
Whether to check for running security/traffic-analysis tools/processes (1: check, 0: do not check)
sh
Whether to inject code into svchost that will restart the malicious process (1: inject, 0: do not inject)
The backdoor uses several techniques to protect its process. Some are configuration-dependent, while others are always applied:
Injecting code into svchost to restart the process: a configurable option. The backdoor allocates memory inside the svchost process, injects code into it, and sets PAGE_NOACCESS permissions on the memory page containing the injected data. It then creates a suspended thread, waits 60 seconds, grants read, write, and execute permissions on the page, and resumes the thread.
Injecting code into svchost
The function injected into the process has a single job: restart the backdoor if its execution is interrupted for any reason.
Injected function
Marking its own process as critical (so that terminating it triggers a blue screen of death): a configurable option.
Setting its own process as critical
Restarting on an unhandled exception. This protection mechanism is always active, regardless of the backdoor’s configuration.
Restarting on exceptions
The backdoor also has spyware functionality. While running, it tracks keystrokes and the currently focused window by using functions from the DirectInput8 library. It also captures clipboard contents. All collected data is saved to a file on disk.
Capturing clipboard data
If the ll key in the configuration is set to 1, ValleyRAT periodically checks for active windows belonging to applications that could be used to analyze processes or traffic. Window enumeration is done via the EnumWindows function, using the following callback:
Window name checks
After completing these checks, the backdoor collects system information, including:
Host name
Host IP addresses
User idle time
Detailed Windows version information (ProductName, EditionId, DisplayVersion)
Number of CPU cores
Free disk space
Graphics adapter
Currently focused window and its title
System bitness
Language settings
Path to the system directory
On command, the backdoor can perform the actions typical of this malware category:
Rebooting the computer
Shutting down the computer
Taking a screenshot
Wiping logs
Updating its C2 addresses
Downloading additional modules
Sending keylogger logs along with clipboard contents
Snippet of the command handler
Let’s take a closer look at the module-loading functionality. Upon receiving the corresponding command with a link from its operator, the backdoor downloads the file at that link and executes it. The download can come from either the C2 server or a third-party address.
The DownloadPeFile function is responsible for downloading a PE file
The DownloadAndExecute function calls DownloadPeFile, then launches the downloaded module
Additional modules can take the form of purpose-built dynamic libraries or shellcode. If the payload is shellcode, the backdoor uses process hollowing with svchost to launch the module.
Implementation of the process hollowing technique
If the module is a dynamic library, the backdoor loads the PE file into its own process, calls DllMain, and searches for a Main function among the exported functions. Once Main has been called, the library is unloaded from memory.
Calling DllMain after the backdoor loads the PE file
Targets and attribution
Over the course of 2026, we detected the ValleyRAT backdoor and its associated malware more than 100,000 times, with more than 1500 unique users affected, primarily in China and India.
This attack geography, combined with the use of the ValleyRAT backdoor, points to Silver Fox, a known operator of this malware family, as the likely group behind the campaign.
Conclusion
This case is a clear example of how adware and affiliate networks can turn out to be far more dangerous than they appear. ValleyRAT is a sophisticated backdoor capable of collecting sensitive data such as keystrokes and clipboard contents, taking screenshots, and delivering additional malicious modules. The attackers exploited a well-known adware application to run the backdoor under the guise of a signed process, which complicates detection.
Motivated by both cyberespionage and financial gain, Silver Fox targets organizations across multiple countries. To stay protected, organizations should keep employee cybersecurity awareness up to date and enforce clear policies on the use of third-party software on work devices.
For individual users, we recommend avoiding the installation of software with a questionable reputation, and, even more importantly, never adding such software to your security solutions’ exclusion lists.
In Q2 2026, the percentage of ICS computers on which malicious objects were blocked continued to decrease, falling to 19.15%, its lowest level since 2022.
Percentage of ICS computers on which malicious objects were blocked, Q3 2023–Q2 2026
Regionally, the percentages ranged from 8.1% in Northern Europe to 27.9% in Africa.
Regions ranked by percentage of attacked ICS computers
The figures increased in five regions over the quarter, most notably in East Asia (by 2.0 pp) and Africa (by 0.5 pp).
East Asia saw increases in percentages for all threats except miners. The region ranked first in terms of growth for malicious scripts and phishing pages, spyware, and viruses. East Asia also led in terms of growth in threats from the internet. The percentage of ICS computers on which email threats were blocked also increased.
Selected industries
The biometrics sector (26.44%) has traditionally led the rankings of industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked. Biometric systems are characterized by the availability of internet access, extensive email use for data exchange and approvals (e.g. access granting), and, in many cases, minimal cybersecurity controls within the organizations that use them.
Industries ranked by percentage of ICS computers on which malicious objects were blocked
The biometrics sector ranked first among industries in terms of the following threat categories: malicious scripts and phishing pages, malicious documents, spyware, ransomware, and worms. The sector is also leading among industries in terms of email threats. At the same time, unlike other industries, the percentage of affected ICS computers for email threats in biometrics exceeds that for internet threats.
In all selected industries, the global average follows a downward trend.
Threat categories
In Q2 2026, Kaspersky security solutions blocked malware from 10,904 different malware families of various categories on industrial automation systems.
Over the quarter, the percentage of ICS computers on which malicious objects of the following categories were blocked increased: denylisted internet resources, malicious documents, worms, ransomware, and malware for AutoCAD.
Percentage of ICS computers on which the activity of malicious objects from various categories was blocked
Malicious scripts and phishing pages (JS and HTML)
Malicious scripts and phishing pages remained in first place in the threat category rankings based on the percentage of ICS computers on which the respective threats were blocked. In Q2 2026, the global average dropped to 5.42%.
Over the quarter, the figure for this category only increased in East Asia, rising by 0.93 pp to 4.86%. This is the second-highest figure in the region in the last three years.
In East Asia, the percentage of ICS computers affected by malicious scripts and phishing pages increased in all the industries surveyed, except construction. The highest figures were recorded for biometrics (9.01%) and building automation (6.49%).
Denylisted internet resources
In Q2 2026, denylisted internet resources rose in the threat category rankings from third to second place, displacing spyware. Globally, the percentage of ICS computers on which denylisted internet resources were blocked has been increasing for two quarters in row and reached 4.31%.
The figures increased in all regions over the quarter, most notably in Russia (by 1.33 pp). Moreover, Russia ranked first (5.17%) among the regions in terms of denylisted internet resources. Since 2022, the region has topped these rankings twice before, both times in Q2: in 2022 and 2024.
Among the selected industries in Russia, the highest figures for the denylisted internet resources were in the electric power (6.61%) and engineering and ICS integration (5.62%) industries.
Malicious documents (MSOffice + PDF)
Malicious documents ranked fourth in the threat category rankings by the percentage of ICS computers on which they were blocked. The percentage for this category decreased over the previous three quarters, reaching its lowest level in three years. However, in Q2 2026, it increased to 1.77%.
Over the quarter, the figures for malicious documents increased in seven regions, most notably in South America (by 1.35 pp) and Southern Europe (by 0.48 pp). These two regions are among the top three in terms of malicious documents, malicious scripts and phishing pages, as well as threats from email clients.
South America ranked second in the rankings of regions in terms of malicious documents. In Q2 2026, the percentage of ICS computers in the region on which this threat was blocked was 3.56%, which was the fourth highest in three years.
Among the selected industries in South America, the highest percentage of ICS computers on which malicious documents were blocked was in biometrics (6.67%).
Southern Europe ranked first in the rankings of regions in terms of malicious documents. In the previous quarter, the percentage of ICS computers in the region on which this threat was blocked was the lowest in three years, but in Q2 2026 it increased to 3.63%.
Among the selected industries in Southern Europe, the highest percentage of ICS computers on which malicious documents were blocked was once again in biometrics (11.48%).
Spyware
Spyware ranked third in the threat category rankings based on the percentage of ICS computers on which it was blocked. The percentage for this category (3.30%) is the lowest since 2022.
Over the quarter, the figures increased in three regions, most notably in East Asia (by 0.53 pp) and Southeast Asia (by 0.42 pp).
East Asia ranked third based on the figures for spyware (4.77%), behind Africa and Southeast Asia. This is the region’s highest rate since Q2 2025. Among the countries and territories in the region, the highest percentage of ICS computers on which spyware was blocked was in mainland China (6.61%). Among the selected industries in East Asia, the highest figures for spyware were in the electric power (11.75%) and manufacturing (5.87%) industries. In all the industries surveyed, the figures are higher than the regional average.
Southeast Asia ranked second after Africa in the ranking of regions in terms of spyware, with 5.32%. Among the selected industries in Southeast Asia, the highest figures for spyware were in biometrics (8.93%) and manufacturing (7.32%). The figures increased in all industries over the quarter.
Ransomware
The percentage of ICS computers on which ransomware was blocked decreased in the previous three quarters but increased to 0.16% in Q2 2026.
During the quarter, the percentage increased in all regions, except Western and Southern Europe and North America (Canada). Africa led the ranking in terms of growth for this metric.
In Q2 2026, Africa ranked first among the regions in terms of the percentage of ICS computers on which ransomware was blocked (0.29%). The only time the figure in the region was higher in the past three years was Q2 2025 (0.31%).
Among the selected industries in Africa, the highest figures for ransomware were in the electric power industry (0.72%) and biometrics (0.52%). Over the quarter, the figures increased in all industries, except manufacturing and construction. The biggest increase was recorded in the electric power industry.
In Russia, the percentage of ICS computers on which ransomware was blocked in biometric systems has increased for three consecutive quarters, reaching 1.22%. This is the highest level of ransomware across all industries in all regions.
Miners
In Q2 2026, the percentage of ICS computers on which miners were blocked was the lowest since 2021, for both miners in the form of executable files for Windows (0.48%) and web miners running in browsers (0.14%).
The figures for both categories decreased in all regions, except for Africa where figures for miners in the form of executable files for Windows increased slightly.
On average, the oil and gas industry led the rankings among the selected industries both in terms of miners in the form of executable files for the Windows OS (0.66%) and in terms of web miners (0.34%).
Worms
In Q2 2026, the percentage of ICS computers on which worms were blocked increased to 1.43%.
In Q2 2026, the Middle East (2.11%) was second (after Africa) in the rankings of regions in terms of worms, displacing Central Asia and the South Caucasus.
Among the selected industries in the Middle East, the highest percentage of ICS computers on which worms were blocked was in building automation (2.90%). Over the quarter, the figures increased in all industries.
Australia and New Zealand ranked 12th among the regions in terms of the percentage of ICS computers on which worms were blocked (0.41%). Over the past three years, the figure in this region was only higher in Q2 2024 (0.42%). The figures increased in all the surveyed industries in the region, most notably in manufacturing and electric power. As a result, for these industries they exceeded the regional average by 2.9 and 2.3 times, respectively.
Viruses
In Q2 2026, the percentage of ICS computers on which viruses were blocked decreased to 1.29%.
The top three regions for this metric remain unchanged: Southeast Asia (6.03%), Africa (4.22%), and East Asia (3.14%). These same regions lead the rankings in terms of malware for AutoCAD.
The figures increased in three regions: East Asia, Australia and New Zealand, and Africa, where it has been growing for four consecutive quarters and reached its highest value since 2022.
Among the selected industries in Africa, the highest percentage of ICS computers on which viruses were blocked was in construction (5.47%).
East Asia ranked third among the regions in terms of viruses, reaching the highest level in the region for the past three years. Among the countries and administrative regions of East Asia, mainland China is the clear leader in terms of viruses (5.07%).
Among the selected industries in East Asia, the highest percentage of ICS computers on which viruses were blocked was in construction (5.93%).
In Australia and New Zealand, the increase in the percentage of ICS computers on which viruses were blocked was primarily due to a 4.3-fold increase in the figure for the electric power industry: from 0.29% to 1.24%. For a region where the percentage of attacked ICS computers for all threats is 0.12%, this is a very high value.
Malware for AutoCAD
In Q2 2026, the percentage of ICS computers on which malware for AutoCAD was blocked increased to 0.31%.
The most notable increase over the quarter was observed in Africa. After more than doubling in the previous quarter, the figure for the region continued to rise (although not so dramatically), reaching 1.02%.
Among the selected industries across all regions, the highest percentage of ICS computers on which malware for AutoCAD was blocked was in construction in East Asia (6.38%) and in Southeast Asia (4.05%).
Main threat sources
In Q2 2026, of all the threat sources, the percentage increased only for email.
Percentage of ICS computers on which malicious objects from various sources were blocked
Internet
The percentage of ICS computers on which threats from the internet were blocked decreased to 7.61%, reaching its lowest level since 2021.
Over the quarter, the percentage increased in three regions: East Asia by 0.8 pp (to 6.3%), South Asia by 0.3 pp (to 10.4%), and Russia by 0.3 pp (to 6.4%).
Among the selected industries across all regions, the highest percentage of ICS computers on which threats from the internet were blocked was in biometrics (13.03%) and engineering and ICS integration (12.16%) in South Asia.
Email
The percentage of ICS computers on which email threats were blocked increased to 2.84%.
In Q2 2026, the percentage of ICS computers on which email threats were blocked increased in South America by 1.0 pp (to 5.2%) and in Africa by 0.7 pp (to 4.3%).
Among the selected industries across all regions, the highest percentage of ICS computers on which email threats were blocked was in biometrics (19.14%) and building automation (12.49%) in Southern Europe.
Removable media
The percentage of ICS computers on which threats from removable media were blocked continued to decrease, reaching 0.24%, the lowest value for the period under review.
Among the selected industries across all regions, the highest percentage of ICS computers on which threats from removable media were blocked was in the electric power industry in East Asia (1.34%) and biometrics in Africa (1.29%).
Network folders
The percentage of ICS computers on which threats from network folders were blocked continued to decrease. In Q2 2026, it was the lowest for the period under review, at 0.023%.
The only region to see an increase in the percentage of ICS computers on which threats from network folders were blocked during the quarter was Africa. This was mainly due to an increase in the building automation figure to 0.05%.
Among the selected industries across all regions, the highest percentage of ICS computers on which threats from network folders were blocked was in biometrics (0.23%), building automation (0.17%), and engineering and ICS integration (0.13%) in East Asia.
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.
Background
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.
Initial infection
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
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.
How it works
When Sync launches, the attackers set several environment variables. Before starting any malicious activity, the implant pulls configuration parameters from these:
STILL_SYNC_ADDR: the address of the command-and-control server. By default, this is https://tg4service[.]com:443.
STILL_SEND_PATH: the path to the tdata
STILL_TELEGRAM_PASSCODE: the password for decrypting the tdata 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:
Motherboard serial number
CPU ID
System UUID
BIOS serial number
Computer domain name
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:
enabled: triggers malicious activity on the infected device.
scan_portable: turns on extended scanning when searching for the tdata We’ll cover this feature in more detail below.
fetch_telegram: if this parameter is on, Sync attempts to log in to Telegram and extract data. We’ll cover this feature in more detail below.
download_channels: if this parameter is off, Sync skips channel dialogs when exfiltrating Telegram data.
These parameters have no default values, so Sync doesn’t perform any malicious actions until the registration and settings-retrieval processes both complete successfully.
Telegram data collection
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:
C:\Users\<username>\AppData\Roaming\Telegram Desktop\: the standard Telegram Desktop installation directory.
C:\Users\<username>\AppData\Local\Packages\<package_folder>\LocalCache\Roaming\: the installation directory for the Microsoft Store version. Sync identifies the package folder by a name that contains the string TelegramMessenge.
C:\: used for the extended search (if the scan_portable option is 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:
snapshot_id: an identifier the server assigns to the current data snapshot.
present: a list of file paths that are already present on the server.
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:
Opening files with the CreateFileW function using the FILE_FLAG_BACKUP_SEMANTICS parameter
Creating a backup copy through the Shadow Copy service and reading files from there
If the previous methods all fail, attempting to copy the file using the Robocopy utility in backup mode
Beyond 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:
User details, such as username, phone number, first and last name
Information about private chats, groups, or channels, such as chat name and ID, the member list, and so on
Dialogs from private chats, groups, and channels (if the download_channels option is on)
Media files under 250MB: photos, documents, stickers, and contacts
Still Audio
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:
It extracts libmp3lame.dll, a file stored inside the executable. This is a library used to encode audio data.
If the --console command-line argument is absent, the implant creates a service named auxhost, connects to it, and continues running in the background.
While running in the background, it creates a file, 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:
machine_id: a unique identifier for the current device.
vad_threshold: the threshold value for the VAD (Voice Activity Detection) algorithm. Expressed as a decimal fraction, it represents a proportion of the maximum sound level the input device can pick up. Sound above this threshold counts as voice activity. The default vad_threshold is 02.
max_silence_duration: the number of audio samples with a VAD value below the set threshold after which the implant considers the recording finished.
max_buffer_size: the maximum buffer size for recorded audio data.
active_device: the name of the input device selected for recording, from the list of available devices.
The eavesdropping process
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.
Infrastructure
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:
They use the same hosting providers, with the ASNs 149440, 202448, and 215311.
Their domain names follow similar naming patterns that mimic Windows system services and update mechanisms.
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
Victims
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.
Attribution
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:
Identical dropper architecture in the February and current campaigns, which includes the use of the Tauri library to build the graphical interface, a similar user-input handler, a payload with the ICRYPTMP header, and the same multi-part encryption format.
The same encryption algorithm and key used in AquilaRAT from the previous campaign and in the Still Audio module from the current campaign, both implementing the Dead Drop Resolver technique.
Identical logic for generating the 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.
Substantial infrastructure overlap, which includes the hosting providers and domain-naming patterns described in the Infrastructure section.
Takeaways
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.
The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.
Quarterly figures
In Q2 2026:
Kaspersky products blocked nearly 400 million attacks that originated with various online resources.
Web Anti-Virus responded to 52 million unique links.
File Anti-Virus blocked more than 16 million malicious and potentially unwanted objects.
There were 2538 new ransomware variants discovered.
More than 71,000 users experienced ransomware attacks.
15% of all ransomware victims whose data was published on threat actors’ data leak sites (DLS) were attacked by Qilin.
More than 213,000 users were targeted by miners.
Ransomware
Quarterly trends and highlights
Threat actor disruption
Microsoft has dismantled an illicit malware-signing service used by ransomware operators. Microsoft’s Digital Crimes Unit has shut down a malware-signing-as-a-service (MSaaS) operation run by the threat group Fox Tempest. The illicit service abused the Microsoft Artifact Signing platform to generate digital signature certificates for malicious software. Malware signed by these certificates was observed in campaigns conducted by such ransomware groups as Rhysida, Akira, INC, Qilin, and BlackByte. The service was also leveraged by operators of the Oyster loader as well as the Lumma and Vidar infostealers. To disrupt the operation, Microsoft seized the domain used by the MSaaS platform, revoked all associated certificates, and disabled the related accounts. Additionally, the company filed a lawsuit against Fox Tempest.
Vulnerabilities and attacks
CISA has confirmed that a Windows vulnerability known as BlueHammer is actively being exploited in ransomware attacks. On April 22, the agency updated its Known Exploited Vulnerabilities (KEV) catalog to note the ongoing ransomware exploitation of CVE-2026-33825. The local privilege escalation flaw in Microsoft Defender was originally disclosed earlier in April. Although Microsoft released a fix on April 14, unpatched systems remain vulnerable. CISA did not disclose further details or attribute the attacks to specific threat groups.
Check Point has linked zero-day exploitation of CVE-2026-50751 to the Qilin ransomware group. The critical vulnerability affects Check Point Remote Access VPN and Mobile Access. Attackers began exploiting the flaw as a zero-day on May 7, with activity spiking sharply in early June. While several dozen organizations have been targeted, at least one incident has been definitively tied to Qilin. Check Point also disclosed a related certificate validation flaw (CVE-2026-50752) that affects site-to-site VPN connections relying on the legacy IKEv1 key exchange protocol.
Researchers assess with high confidence that the PayoutsKing group is leveraging the legitimate QEMU emulator to deploy hidden, Alpine Linux-based virtual machines on compromised hosts. Because security solutions often lack visibility inside virtualized environments, the threat actors use this technique to evade detection. Inside the VM image, the operators deploy various tools — such as credential theft software — and configure the virtual machine as a backdoor managed via a reverse SSH tunnel to their command-and-control infrastructure. While the technique is not new, and we’ve detailed it before, it remains relatively rare in ransomware attacks.
The most prolific groups
This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. Qilin reclaimed the top spot (accounting for 14.57% of total listings) after placing second last quarter. It is followed by the Akira ransomware (7.80%) and the DragonForce RaaS group (6.88%).
Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)
Number of new ransomware variants
In Q2, Kaspersky solutions detected four new ransomware families and 2538 new modifications. This signals a continued stabilization following spikes seen in Q1 and Q4 of last year.
Number of new ransomware modifications, Q2 2025 — Q2 2026 (download)
Number of users attacked by ransomware Trojans
Our solutions protected a total of 71,860 unique users from ransomware during Q2. Ransomware activity peaked in April, with 31,206 targeted users recorded during that month.
Number of unique users attacked by ransomware Trojans, Q2 2026 (download)
TOP 10 countries and territories attacked by ransomware Trojans
Country/territory*
%**
1
South Korea
0.87
2
Pakistan
0.76
3
China
0.71
4
Libya
0.49
5
Tajikistan
0.46
6
Turkmenistan
0.38
7
Cameroon
0.38
8
Indonesia
0.36
9
Bangladesh
0.36
10
Mozambique
0.34
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.
* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.
Miners
Number of new miner variants
In Q2 2026, Kaspersky solutions detected 6067 new miner variants, almost twice the number for the previous reporting period.
Number of new miner modifications, Q2 2026 (download)
Number of users attacked by miners
In Q2, we detected attacks using miner programs on the computers of 213,003 unique Kaspersky users worldwide.
Number of unique users attacked by miners, Q2 2026 (download)
TOP 10 countries and territories attacked by miners
Country/territory*
%**
1
Mali
1.56
2
Senegal
1.54
3
Tanzania
1.32
4
Panama
1.04
5
Bangladesh
1.03
6
Ethiopia
0.87
7
Costa Rica
0.67
8
Bolivia
0.67
9
Côte d’Ivoire
0.65
10
Kazakhstan
0.62
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.
Attacks on macOS
Quarterly highlights
In April, Aikido researchers reported a new attack by the GlassWorm stealer, which was distributed via malicious IDE extensions on the Open VSX Registry. The payload operated by installing a secondary malicious extension across all installed IDE environments on the host machine. Ultimately, this second-stage implant exfiltrated crypto wallet data, environment variables, and other secrets. It also installed a RAT on the infected device.
In May, Socket researchers uncovered a supply chain compromise involving the popular npm package art-template. As a result of the breach, the weaponized package injected the Coruna exploit kit into web applications it was used to build. Coruna targets iOS devices.
In June, Palo Alto Networks’ Unit 42 discovered FlutterShell, a new backdoor family that targets macOS devices. Developed with the Flutter framework, the malware leverages the WebView engine to load web pages that contain malicious JavaScript. On the client side, the backdoor registers bridge functions invoked by the loaded JavaScript that allow threat actors to execute arbitrary payloads on the victim’s device. Notably, the malicious applications successfully passed Apple notarization. Although the specific samples analyzed functioned primarily as adware, the underlying architecture permits the delivery of far more sophisticated malicious payloads.
TOP 20 threats to macOS
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)
* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.
Detections of PasivRobber spyware continued their downward trend. Meanwhile, adware and traffic-routing utilities (categorized as NetTool) rose to the top of the rankings. Additionally, Q2 saw a noticeable spike in detections for the DirtyCow exploit frequently leveraged for iPhone jailbreaking.
TOP 10 countries and territories by share of attacked users
Country/territory
%* Q1 2026
%* Q2 2026
Brazil
1.13
1.13
China
1.04
1.28
Hong Kong
0.92
0.49
Singapore
0.85
0.19
France
0.62
1.18
Mexico
0.43
0.72
India
0.41
0.42
Thailand
0.40
0.24
Germany
0.33
0.71
The Netherlands
0.31
0.62
* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.
IoT threat statistics
This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.
In Q2 2026, the breakdown of attacking devices and sessions that targeted Kaspersky honeypots by protocol was as follows:
Distribution of attacked services by number of unique IP addresses of attacking devices (download)
The share of SSH attacks saw a slight uptick compared to the previous quarter.
Distribution of cybercriminal sessions in Kaspersky honeypots (download)
TOP 10 threats delivered to IoT devices
Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)
As is typically the case, Mirai botnet variants continue to dominate the IoT threat landscape. Activity of another prominent botnet, Prometei, also saw an increase.
Attacks on IoT honeypots
the Netherlands, Germany, and The United States accounted for the highest proportions of SSH-based attacks during this period. While the top three countries remained the same as last quarter, their relative rankings shifted.
Country/territory
Q1 2026
Q2 2026
The Netherlands
17.57%
21.18%
Germany
10.34%
16.73%
United States
23.74%
6.76%
Bulgaria
1.10%
5.50%
Sweden
2.09%
4.93%
Panama
6.34%
4.67%
Luxembourg
0.16%
4.62%
Romania
5.82%
4.06%
Vietnam
3.50%
3.91%
India
6.05%
2.78%
The percentage of Telnet-based attacks originating from Pakistan continued to climb, knocking China down to second place.
Country/territory
Q1 2026
Q2 2026
Pakistan
27.31%
36.60%
China
39.54%
35.62%
Russian Federation
8.25%
8.75%
India
4.66%
4.19%
Brazil
3.30%
3.34%
United States
0.45%
3.03%
Indonesia
6.71%
1.52%
Philippines
0.36%
0.95%
France
0.17%
0.84%
Thailand
0.55%
0.66%
Attacks via web resources
The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.
TOP 10 countries and territories that served as sources of web-based attacks
The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malware, botnet C&C centers, and so on). One or more web-based attacks could originate from each unique host.
To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).
In Q2 2026, Kaspersky solutions blocked 399,312,961 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 52,850,592 unique URLs.
Web-based attacks by country/territory, Q1 2026 (download)
Countries and territories where users faced the greatest risk of online infection
To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.
This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Bangladesh
11.71
2
India
7.40
3
Tajikistan
7.13
4
Venezuela
7.05
5
New Zealand
6.58
6
Vietnam
6.34
7
Taiwan
6.28
8
Belgium
6.24
9
France
5.97
10
Hungary
5.92
11
Nepal
5.91
12
Portugal
5.86
13
Italy
5.77
14
Costa Rica
5.72
15
Canada
5.65
16
Qatar
5.61
17
Dominican Republic
5.52
18
Palestine
5.48
19
Greece
5.47
20
UAE
5.43
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky product users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.
On average during the quarter, 4.54% of users’ computers worldwide were subjected to at least one Malware web attack.
Local threats
Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.
Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.
In Q2 2026, our File Anti-Virus detected 16,986,351 malicious and potentially unwanted objects.
Countries and territories where users faced the highest risk of local infection
For each country and territory, we calculated the percentage of Kaspersky users whose computers had the File Anti-Virus triggered at least once during the reporting period. These statistics reflect the level of personal computer infection in different countries.
Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Turkmenistan
46.38
2
Cuba
29.70
3
Tajikistan
28.46
4
Afghanistan
28.19
5
Yemen
27.85
6
Burundi
26.82
7
Mozambique
25.01
8
Republic of the Congo
24.88
9
Syria
23.17
10
Uzbekistan
22.49
11
China
21.92
12
Nicaragua
21.60
13
Cameroon
21.47
14
Bangladesh
20.43
15
Democratic Republic of the Congo
20.25
16
Algeria
19.78
17
Uganda
19.48
18
Ethiopia
18.57
19
Tanzania
18.54
20
Mali
18.53
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers Malware local threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.
On average worldwide, Malware local threats were detected at least once on 10.93% of users’ computers during Q2.
The mobile section of the quarterly cyberthreat report includes statistics on malware, adware, and potentially unwanted software for Android, as well as descriptions of the most notable threats for Android and iOS discovered during the reporting period. These statistics are based on detection alerts from Kaspersky products, collected from users who consented to provide statistical data to Kaspersky Security Network.
The quarter in figures
According to Kaspersky Security Network, in Q2 2026:
More than 1.99 million attacks on mobile devices utilizing malware, adware, or unwanted mobile software were blocked.
The Trojan-Banker category was the most prevalent mobile malware threat with a 30.77% share of total detected applications.
More than 304,000 malicious installation packages were discovered, including:
93,574 packages were related to mobile banking Trojans;
570 packages were related to mobile ransomware Trojans.
Quarterly highlights
Attacks on mobile devices involving malware, adware, or unwanted software continued their downward trend, falling to 1,996,823 in Q2 from 2,676,328 the previous quarter.
Attacks on users of Kaspersky mobile solutions, Q4 2024 — Q2 2026 (download)
We noted a downward trend in attacks driven by specific strains of pre-installed Trojans — a shift likely tied to the rollout of patched vendor firmware.
In Q2, our telemetry uncovered multiple malicious loaders hosted directly on Google Play. As highlighted in a prior report (link in Russian), one such instance involved a PDF reader app trojanized to drop the Anatsa banking malware. Upon execution, the app presented users with a fake request to install an update, which served as a front to stage the banking Trojan on the victim’s device.
Another notable case involves a loader we detected in the Cleanova app alongside several others. The malware sent requests to a command-and-control server containing telemetry gathered from various SDKs that track the installation source. A malicious payload was returned only for certain sources. This is a fairly interesting method for bypassing app store review processes while ensuring precise victim targeting. If an analytics SDK indicates that an arbitrary installation originated from a source outside the threat actors’ scope, the malicious logic remains dormant. This effectively hides the malware from app store scanners.
Mobile threat statistics
In Q2, the number of Android malware samples totaled 304,128. It remained steady compared to the previous reporting period.
The detected installation packages were distributed by type as follows:
Detected mobile apps by type, Q1 — Q2 2026* (download)
* Data for the previous quarter may differ slightly from previously published data due to certain verdicts being retrospectively revised.
While the number of newly discovered banking Trojan variants fell precipitously, they continued to dominate the threat landscape as they did in Q1. Notably, the share of Creduz malware family among identified banking samples has grown significantly despite low activity in victim telemetry. This discrepancy suggests the threat actors are actively iterating on the malware — likely testing new features or bypasses — by generating a high volume of builds before staging a broader campaign.
Share* of users attacked by the given type of malicious or potentially unwanted apps out of all targeted users of Kaspersky mobile products, Q1 — Q2 2026 (download)
* The total may exceed 100% if the same users experienced multiple attack types.
Within the adware category, the sharpest declines were observed in the HiddenAd and MobiDash families. Meanwhile, the proportion of users targeted by Trojan-Dropper malware increased, primarily driven by surges in banking droppers such as Trojan-Dropper.AndroidOS.Banker and Trojan-Dropper.AndroidOS.Mamont. The corresponding drop in the Trojan-Banker category is partially explained by a shift in tactics: several banking Trojans which are now being packed were subsequently reclassified as droppers.
TOP 20 most frequently detected types of mobile malware
Note that the malware rankings below exclude riskware or potentially unwanted software, such as RiskTool or adware.
Verdict
%* Q1 2026
%* Q2 2026
Difference in p.p.
Change in ranking
Backdoor.AndroidOS.Triada.ag
7.09
9.35
+2.25
0
DangerousObject.Multi.Generic.
5.84
5.65
-0.19
0
DangerousObject.AndroidOS.GenericML.
5.51
5.25
-0.26
0
Trojan.AndroidOS.Boogr.gsh
2.15
3.33
+1.18
+9
Backdoor.AndroidOS.Triada.z
3.08
3.23
+0.15
+3
Trojan-Banker.AndroidOS.Mamont.hl
1.10
2.48
+1.38
+22
Trojan.AndroidOS.Fakemoney.v
3.44
2.31
-1.13
-2
Trojan-Spy.AndroidOS.Btmob.e
0.00
2.27
+2.27
Trojan.AndroidOS.Triada.fe
2.98
2.18
-0.81
0
Trojan-Dropper.AndroidOS.Banker.dd
0.01
2.16
+2.15
Trojan.AndroidOS.Triada.hf
2.23
1.93
-0.29
+1
Backdoor.AndroidOS.Triada.ad
1.40
1.93
+0.53
+8
Backdoor.AndroidOS.Keenadu.a
2.73
1.88
-0.85
-3
Backdoor.AndroidOS.Triada.ab
1.72
1.79
+0.07
+2
Trojan-Banker.AndroidOS.Mamont.iv
1.03
1.63
+0.60
+16
Trojan.AndroidOS.Generic.
1.32
1.47
+0.15
+7
Backdoor.AndroidOS.Triada.ae
1.76
1.44
-0.31
-2
Trojan.AndroidOS.Fakemoney.ej
0.00
1.43
+1.43
Trojan.AndroidOS.Triada.ii
2.07
1.41
-0.66
-5
Trojan-Spy.AndroidOS.Agent.asa
0.02
1.38
+1.36
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.
The distribution of top malware families in Q2 largely mirrors the rankings from the previous reporting period. Newer variants of the Mamont banking Trojan climbed the leaderboards, displacing older iterations. This shift points to ongoing, active development of new variants by the threat actors behind the malware.
Mobile banking Trojans
In Q2, the total volume of Trojan-Banker applications dropped sharply compared to the previous quarter, totaling 93,574 installation packages.
Number of installation packages for mobile banking Trojans detected by Kaspersky, Q2 2025 — Q2 2026 (download)
Against the backdrop of this trend, the distribution shifted heavily toward Creduz Trojans. However, as noted earlier, this shift was not reflected in real-world attack metrics: virtually the entire leaderboard by proportion of targeted users continues to be dominated by diverse Mamont variants.
TOP 10 mobile bankers
Verdict
%* Q1 2026
%* Q2 2026
Difference in p.p.
Change in ranking
Trojan-Banker.AndroidOS.Mamont.hl
3.27
11.13
+7.86
+6
Trojan-Banker.AndroidOS.Mamont.iv
3.08
7.33
+4.25
+6
Trojan-Banker.AndroidOS.Mamont.mv
0.00
5.12
+5.12
Trojan-Banker.AndroidOS.Agent.ws
3.78
4.99
+1.22
+2
Trojan-Banker.AndroidOS.Mamont.mg
0.35
4.71
+4.36
+62
Trojan-Banker.AndroidOS.Faketoken.pac
2.56
4.10
+1.54
+6
Trojan-Banker.AndroidOS.Mamont.jo
15.75
3.73
-12.02
-6
Trojan-Banker.AndroidOS.Mamont.mc
0.83
3.51
+2.67
+26
Trojan-Banker.AndroidOS.Mamont.lf
0.00
2.79
+2.79
Trojan-Banker.AndroidOS.Agent.eq
0.89
2.58
+1.69
+23
* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile security solutions who encountered banking threats.
Astaroth's new WhatsApp spambot auto-messages every victim contact in Brazil using a hidden browser, quietly turning each victim into a malware distributor.
The new GenieLocker ransomware family has been active since March 2026. It has been used in attacks against organizations in the Russian Federation, primarily in the manufacturing sector, and attributed to the Toy Ghouls group by open-source intelligence (link in Russian).
The Toy Ghouls, also known as Bearlyfy, Labubu and Laboo.boo, is a financially motivated extortion group, which previously relied on third-party encryption Trojans like RedAlert, LockBit, and Babuk. GenieLocker, apparently a custom design, upgrades their toolkit and reduces their reliance on third-party software. We discovered multiple samples of this Trojan in two variants: PE builds for Windows and ELF builds for Linux and ESXi.
Technical details
Modus operandi
We described typical TTPs and modus operandi of the Toy Ghouls threat actor in the previous post (link in Russian).
In this article, we aim to thoroughly describe the capabilities of Windows and Linux builds of the custom encryption Trojan GenieLocker. To give more context, we will also provide a brief overview of the attack that took place at the end of March 2026, where GenieLocker was deployed on the victim’s systems.
Initial Access
During the incident, the attackers first entered the environment through an OpenVPN connection originating from an external partner’s network. They likely exploited the trusted relationship with that partner and used stolen, yet still valid, credentials to connect.
Discovery and Credential Access
After breaching the target’s network, the attackers installed additional tools on the compromised hosts, including OpenSSH, socks5.exe, SoftPerfect Network Scanner, and Mimikatz. They employed SoftPerfect Network Scanner for discovery and used Mimikatz to dump credentials. Forensic analysis also shows that they accessed the KeePassXC password manager already installed on several compromised machines, likely attempting to extract the stored credentials from the KeePass databases.
Lateral Movement and Command and Control
Lateral movement was performed by using RDP to reach Windows machines and SSH for Linux servers. The widespread deployment of the encryption Trojan was conducted with the legitimate utilities PsExec and PAExec. Additionally, the attackers established a reverse SSH tunnel to communicate with their command‑and‑control server.
Impact
During the impact phase, the attackers encrypted files on the compromised Windows machines with the PE version of the GenieLocker ransomware. On the compromised Linux and ESXi servers, they stopped active virtual machines and encrypted their disks using the ELF version of GenieLocker.
The tactics, techniques, and procedures seen here match those documented in earlier attacks attributed to the Toy Ghouls group. As in those prior incidents, forensic analysis found no evidence of data exfiltration, which is typical behavior for this threat actor. Toy Ghouls have not employed a double‑extortion model and do not run a data‑leak website.
Encryption Trojan for Windows
The Windows version of GenieLocker (MD5: 5d62c1349b8981c396c9a23f4f8f053c) is primarily written in C, but compiled with the C++ libraries using Microsoft Visual C/C++. The malware incorporates several ransom‑related capabilities, including process termination, service shutdown, debugger evasion, and a sophisticated encryption routine. For its cryptographic operations, it relies on the open‑source libsodium library.
Aligned with the recent trend supported by our expertise, as observed in attacks of some other ransomware strains, GenieLocker doesn’t save the ransom notes on the victim’s system. The Trojan doesn’t contain any attackers’ contact info or negotiation addresses. Instead, the attackers will need to deliver the ransom demands and contacts manually during the attack. This approach may be an attempt by the GenieLocker developers to avoid proactive detection of the ransomware process being triggered by the creation of multiple readme files.
GenieLocker help message
Arguments and launch
GenieLocker supports multiple arguments for configuring its behavior.
Argument
Description
First argument
“Secret” argument, hex string value
-p, –percent N
Percentage of file content to encrypt
-r, –recursive
Process directories recursively
-l, –log <filename>
Set path for log file
-h, –help
Show help message
Last argument
Path to encrypt
GenieLocker expects the first argument to be a hex string referred to in the malware code as the “secret argument”, which is required for the ransomware to start. Most likely, the purpose of this is to avoid execution on sandboxes and other automated analysis environments. Another reason may be to prevent unauthorized usage by other threat actors.
Checking the secret argument
The secret argument is a hex value with a variable size that does not exceed 4096 bytes. This hex string value is converted to bytes and hashed with the SHA‑256 algorithm. The result is compared to a hardcoded value. If they match, the literal string session is appended to the secret value, and the whole string is hashed with BLAKE2b‑256, but the resulting hash is never used. This may be a part of a feature still in development.
Secret value hashing
Anti-debugging
GenieLocker contains multiple methods to inspect if its process is under debugging. After launch it makes the first check named Environment check and uses WinAPI functions IsDebuggerPresent and CheckRemoteDebuggerPresent to detect the debugger.
Environment check
After the secret argument validation, GenieLocker starts a new parallel thread called watchdog. It runs in an infinite loop that performs a number of checks to detect well-known debuggers every 500 milliseconds. If at least one of the checks fails, the whole GenieLocker process immediately terminates.
Watchdog checks
The only thing worth elaborating on is that the GenieLocker process calculates the CRC32 of its .text section when the watchdog thread is starting, saves the resulting hash, and then recalculates it again in every loop and compares with the initial value. In case the code in this section is modified by the debugger or other program, this method allows the Trojan to detect this modification.
Preparing for encryption
GenieLocker contains multiple exclusion lists. For example, it does not encrypt folders with names from the list below. Among those, there are mostly system folders, which are skipped to avoid corrupting the OS.
Furthermore, the Trojan contains an exclusion list for host names. The malware retrieves the computer name using GetComputerNameA and checks it against this list, but in the sample in question, the list is empty.
Output for whitelisted hosts
If the host name is not excluded, GenieLocker starts to kill processes that could be using the files of interest and therefore prevent the Trojan from encrypting them. These processes are listed below. The Trojan stops them by using the TerminateProcess function.
Finally, GenieLocker starts encryption threads and searches for all available drives, including network shares, to encrypt them.
Threads info output
File encryption and cryptography
The extension for the encrypted files is hardcoded in the Trojan’s body. In the sample under review, it is .03ffc1c4a3da0f02. Before starting to encrypt each file, GenieLocker creates two auxiliary files:
a lock file: <filename.fileext>.03ffc1c4a3da0f02.lock
a journal: <fileext>.03ffc1c4a3da0f02.journal
The lock file helps to protect files from double encryption by other threads or instances. Inside this file, the Trojan stores the current PID obtained from the GetCurrentProcessId function.
The journal file contains the hardcoded string VCJOURN, value 1 (possibly version), some unused zeroed fields, total blocks to encrypt, and the count of blocks that are actually encrypted. The last field is a CRC32 hash sum for the integrity check of the journal content.
Journal content
By default GenieLocker encrypts files using 0x1000000-byte chunks. If the argument -p is passed (it sets the percentage of the file contents to be encrypted), the ransomware calculates how many chunks with 0x1000000 size are necessary to encrypt the specified percentage. Each chunk has a random position inside the file. Regardless of whether the percentage is set, even if it is zero, the first chunk in the beginning of the file will be encrypted anyway.
The Trojan encrypts the file content using the Authenticated Encryption with Associated Data (AEAD) algorithm XChaCha20-Poly1305, with a unique key and nonce for each file. The Trojan also adds a footer that contains the data necessary for future decryption and metadata. The metadata parts are encrypted using the same cipher and key as the file contents, but with a different nonce. The file key is encrypted using the Curve25519-XSalsa20-Poly1305 scheme, with the attackers’ master public key hardcoded in the Trojan’s body.
The metadata of each encrypted file contains the following fields.
Value or name
Size (bytes)
Description
version
1
Hardcoded byte with value 1, most likely the version.
encryption_percent
1
Percentage of file content to encrypt, value from -p argument.
file_nonce
24
Nonce used during encryption of the file content.
original_filesize
8
Original size of the file before encryption.
total_chunk_count
8
Max count of chunks inside the current file.
chunk_size
4
Size of a single encrypted chunk (by default, 0x1000000 bytes on Windows and 0x400000 on ESXi and Linux).
remain_size
4
The number of bytes remaining after splitting the file content into chunks.
blake2b_digest_of_chunks
32
BLAKE2b-256 hash calculated from the original data of all chunks before they are encrypted. Used for integrity checks.
chunk_count
4
Number of chunks that were encrypted.
extension
64
A string with the additional ransomware extension.
poly1305_tags (array)
16 bytes per chunk
Array of Poly1305 tags of encrypted chunks.
bitmask
varies, one bit per each chunk
Chunks bitmask; if set, the chunk is encrypted; otherwise, it is not.
The chunks bitmask contains as many bits as the maximum number of chunks inside a file at 100%. If a bit at a specific index is set to 1, the chunk is encrypted. The value 0 means that the chunk is not encrypted. Since the Trojan encrypts files based on the percentage value, it needs to know which chunks were encrypted.
Metadata structure at the end of an encrypted file (without a Poly1305 tags array or bitmask)
Encryption Trojan for ESXi and Linux
Compared with its Windows counterpart, the Linux and ESXi version of GenieLocker (MD5: 9201e35e2993612612919a3c71302cab) is simpler: there is no secret argument, anti‑debugging techniques, or exclusion lists. However, the sample has ESXi-specific features, such as double‑fork support and the ability to modify the Welcome Message. The sample has the version v1 and, similarly to the Windows version, uses the libsodium library for cryptography.
ESXi version description
The command‑line help output mirrors LockBit’s styling, reinforcing the theory that GenieLocker’s creators set out to craft a LockBit‑style replacement for their own operations.
LockBit output design, possibly the source layout for the GenieLocker ESXi variant
Based on the default path of the encryption directory /vmfs/volumes, we can assume that this version is intended primarily for ESXi. Nonetheless, it can still be executed on Linux distributions.
Argument
Description
-p <perc>
Percentage of file content to encrypt
-j <workers>
Number of encryption threads
-r <dir>
Process directories recursively
-w <sec>
Delay before start
-d
Daemonizing the process
-l <logfile>
Path to log file
ESXi and Linux features
This build allows daemonizing its process with the -d flag, employing the classic double‑fork method so the new process becomes fully detached from its parent.
This variant also modifies the /etc/vmware/welcome file, which contains the Welcome Message (Message of the Day) on the ESXi operating system. On Linux distributions, it does not change anything, because they use different paths for the Message of the Day. In the GenieLocker sample examined here, the message is left empty.
Additionally, the ESXi version supports a few basic features that are not included in the Windows version. For instance, there is a launch‑delay option and the ability to set the number of encryption worker threads. This build also includes several features that already exist in the Windows variant, such as configuring the percentage of a file to encrypt, choosing the target directory, and setting the log file location.
File encryption
The encryption scheme for files is identical to the Windows version. The Trojan uses XChaCha20-Poly1305 to encrypt the file content and metadata, and Curve25519-XSalsa20-Poly1305 for key encryption.
File encryption summary
Victims
According to KSN telemetry, GenieLocker detections are overwhelmingly concentrated on endpoints located in the Russian Federation. In the March 2026 campaign, the primary sector under siege was manufacturing, with construction trailing closely, followed by financial services, retail, and technology.
Conclusions
Toy Ghouls are ramping up their campaign against Russian enterprises. The rollout of their home‑grown encryption Trojan GenieLocker marks a major upgrade to the group’s ransomware toolkit. By engineering bespoke ransomware that runs natively on Windows, Linux, and ESXi, the actor has cut their dependence on off‑the‑shelf ransomware families and unified the cryptographic backbone across all targeted platforms.
Kaspersky’s products detect this malware as Trojan-Ransom.Win64.Agent.genie, HEUR:TrojanRansom.Win64.Generic, Trojan-Ransom.Linux.Agent.genie.
Mirage Kitten – also known as UNC1549, Smoke Sandstorm, and Nimbus Manticore – is an advanced persistent threat (APT) group focused on cyber-espionage operations against aerospace, aviation, defense, and telecommunications sectors across the Middle East and Africa, using highly targeted spear-phishing campaigns, fake recruitment portals, and custom multi-stage malware to gain persistent access and exfiltrate sensitive data.
During recent threat research, we identified a previously undocumented malware set developed and used by Mirage Kitten. The toolset includes NightLedger, a new Windows backdoor for reconnaissance, command execution, file operations, process discovery, and screenshot capture; and two custom WebSocket-based tunnelers, ArcBridge and BridgeHead, for covert network access and operator-controlled tunneling.
Technical details
Although the initial access vector remains unclear for most malware samples observed in this activity, we saw BridgeHead being deployed during post-exploitation activities in victim environments in Egypt and at a Pakistan-based aerospace and aviation organization. The deployment followed targeted spear-phishing activity consistent with tradecraft we recently documented as part of our private threat intelligence reporting service and publicly reported by Unit 42 and Check Point Research, including the use of highly tailored social engineering lures against selected targets. These lures included recruitment-themed content impersonating trusted brands and hiring platforms, as well as lookalike videoconferencing pages that redirected victims to malicious archives hosted on third-party file-sharing services.
NightLedger backdoor
NightLedger is a recently identified Windows backdoor that we attribute to Mirage Kitten based on code and behavioral similarities to the historical implants developed and used by the group. The implant masquerades as SspiCli.dll and appears to be designed for DLL search-order hijacking, targeting a legitimate AppVShNotify.exe binary. While AppVShNotify.exe does not directly import SspiCli.dll, it imports RPCRT4.dll, which can delay-load SspiCli.dll when it invokes an RPC API that requires authentication. This allows a co-located malicious SspiCli.dll to be loaded while forwarding expected exports to the legitimate DLL.
When started, the malicious DLL creates the mutex A8215357-F99A-44FE-BC65-D8F0434B0C03 to enforce a single running instance. If the mutex already exists, it exits immediately.
NightLedger periodically contacts its C2 over HTTPS, issuing an HTTP GET request to the /edfcvfgbhnjmkqwasderfgg endpoint at the realhealthshop[.]com domain, and uses tjconsultingservices[.]com as a fallback C2.
When a valid C2 response is received, the implant tokenizes the payload using the custom delimiter (#%%#) and passes the parsed fields to its command dispatcher. From a development standpoint, this is similar to TWOSTROKE, a backdoor attributed to the same APT and previously documented by GTIG, whose C2 response is hex-encoded and uses (@##@) as a field separator.
NightLedger supports the following commands:
Command ID
Description
1
Gather user and host identity information
3
Execute a process/program
17
List directories
20
Download a file to the infected system
25
Gather host and network information
27
Copy a file
30
Update beacon interval
36
Take a screenshot
43
Load a DLL
56
Kill a process
62
Delete a file
69
Terminate thread
70
Upload file to C2 server via POST request to /qasxcdfvgbhnmyuioplkhnj
75
Enumerate logical drives
90
List processes
93
Collect C:\Windows\debug\NetSetup.log together with process-list output.
NetSetup.log is a Windows diagnostic log generated under C:\Windows\debug\ during domain/workgroup join, unjoin, and related network setup operations.
Command output is returned to the C2 via an HTTP POST request to /wsdefvvbnhyuijkplmbgfrtt.
BridgeHead – a WebSocket tunneler
During our investigation, we encountered a tunnel proxy deployed as unbcl.dll in the %LocalAppData%\Microsoft\VisualStudio directory on a machine in Egypt. We also identified a similar deployment in a Pakistan-based environment, where the tunneling tool was stored as C:\program files (x86)\univpn\promote\libwinpthread-1.dll. The malware dynamically loads advapi32.dll, resolves GetUserNameA, retrieves the current Windows username, converts it to lowercase, and searches for a specific substring in it. This behavior suggests prior reconnaissance was performed within the internal network and the username check is needed to make sure it runs on a specific machine. This is potentially intended to prevent execution of the standalone malware sample inside virtual analysis systems. If the substring is not found, the function returns silently without activating.
If the username check was successful, the tunneler establishes an HTTPS WebSocket connection as follows:
GET /connect HTTP/1.1
Host: smartconnect.azurewebsites.net
Upgrade: websocket
Connection: Upgrade
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36 Edg/86.0.622.38
The server responds with HTTP 101 (Switching Protocols) to complete the WebSocket upgrade. After the upgrade, the client sends a binary WebSocket message containing the literal string "token" as authentication. The server must respond within 10 seconds, or the connection is dropped and retried with exponential backoff.
The malware’s next action depends on the HTTP response returned by the server:
HTTP response
Description
407 (Proxy Auth Required)
Queries supported auth schemes via WinHttpQueryAuthSchemes, selects Negotiate (0x10) or NTLM (0x2) in that exact order, sets Windows SSO credentials (null username/password), retries up to 3 times.
101 (Switching Protocols)
Success. Proceeds to WebSocket upgrade and authentication.
Other
Connection failed. Closes all handles, enters backoff.
This implementation closely mirrors the enterprise proxy traversal logic seen in the backdoor we track internally as Retrograde, which overlaps with tooling publicly reported as MiniFast/MiniUpdate, attributed to the same APT group. The implant is designed to operate through corporate proxy environments by handling HTTP 407 responses, negotiating Windows-integrated proxy authentication with Negotiate preferred over NTLM, retrying with the current user’s SSO context, and falling back to exponential C2 connection retry logic capped at 60 seconds.
Once the WebSocket channel is established and authenticated, the implant functions as a full SOCKS5 tunnel proxy. The C2 server initiates all tunnel connections by sending binary commands over the WebSocket; the implant simply forwards traffic between server‑specified targets and the WebSocket channel. This makes it a relay node: the operator runs tools server‑side, and all resulting TCP traffic is tunneled through the victim’s machine as if originating from the victim’s network.
All tunnel communication uses a fixed binary wire format:
Offset
Size
Field
Encoding
0
1
type
Message type (1–9)
1
4
connId
Tunnel connection identifier
5
1
flags
Status or error indicator
6
2
dataLen
Payload length
8
var
payload
Message data
Every message is at least 8 bytes. Seven message types are actively used:
Type
Name
Direction
Description
1
CONNECT
Server -> Client
Open a new TCP tunnel to a SOCKS5 target address
2
CONNECT_RESPONSE
Client -> Server
Confirm the connection was established
3
DATA
Bidirectional
Relay TCP traffic through the tunnel
4
DISCONNECT
Bidirectional
Close a tunnel connection
5
PING
Bidirectional
Keepalive probe, sent every 30 seconds by timer
6
PONG
Bidirectional
Keepalive reply
9
FLOWCTRL
Bidirectional
Throttle data flow to prevent buffer overrun
The CONNECT payload specifies where the implant should open a TCP connection. The target address is encoded in SOCKS5 format and consists of a single type byte, followed by the address and a 2-byte destination port:
Type byte
Description
0x01
IPv4 address (4 bytes)
0x03
Domain name (1-byte length + string)
0x04
IPv6 address (16 bytes)
Notably, in the process of threat hunting, we detected another variant (MD5: C832ECD135781B11F59E3FFFB3D2B6AC) that shares the same dynamic-resolve stub pattern. This variant communicates with businessmixture.com/blog over WSS on port 443, and not through Microsoft Azure. Still, it implements the same technique of limiting execution to a specific username on the infected machine by hardcoding a 3-character control value that must appear as a substring in the lowercased Windows username retrieved via GetUserNameA. If the match fails, the implant silently exits, confirming per-target tailoring of each deployed binary.
ArcBridge: another WebSocket tunneling tool
ArcBridge is another WebSocket tunneling tool developed and used by Mirage Kitten. We first identified it in April 2026 in activity targeting victims in the Middle East. The malware creates a mutex named F56E68DA-4A89-46B4-9AC8-7290A7651000 to enforce single-instance execution. The use of a UUID-like mutex name is consistent with the NightLedger backdoor described earlier.
The malware contains an embedded configuration block that stores the C2 host, C2 port, retry or timeout value, SSL flag, and what is highly likely an implant identifier:
After initialization, ArcBridge communicates over a WebSocket-style channel and waits for server-side control messages. It supports the following commands:
Command
Description
OPEN:
Creates a proxy/tunnel session to a target selected by the operator.
DNS:
Performs hostname or address resolution and returns the result.
Victimology
According to our telemetry, we identified victims across Middle East and African countries including Egypt, SMB and government environments in Jordan and Tanzania, aviation organizations in Pakistan, telecommunication companies in Ethiopia and financial-sector entities in Burkina Faso.
Conclusion
Mirage Kitten continues to evolve its malware arsenal to support targeted cyber-espionage operations across the Middle East and Africa regions. The NightLedger backdoor retains similar core command functionality to TWOSTROKE while introducing additional capabilities, including screenshot capture and collection of the NetSetup.log file.
Another notable aspect of the campaign is the group’s continued reliance on tunneling utilities as part of its operational toolkit. This aligns with previous public reporting, which documented the group’s use of the LIGHTRAIL and POLLBLEND tunnelers. Consistent with this tradecraft, we observed Mirage Kitten continuing to leverage tunneling capabilities alongside a gradual shift away from Microsoft Azure subdomain-style infrastructure in favor of Cloudflare-backed domains in some of its malware, a change likely intended to complicate attribution while maintaining resilient command-and-control communications.
RedHook malware uses fake banking and government apps to steal data and control Android phones, with attacks confirmed in Vietnam and Indonesia so far.
Dr.Web details Siggen Windows backdoor that uses Steam for C2, steals credentials and crypto data and infects Visual Studio projects to spread among developers.
Content In the second quarter of 2026, the AhnLab SEcurity intelligence Center (ASEC) collected and analyzed attack logs targeting poorly managed Linux SSH servers through honeypots. The scope of the analysis covers attack sources that progressed to executing actual malware installation commands, as well as statistics on the malware used in those attacks. Purpose and […]
Contents The AhnLab SEcurity intelligence Center (ASEC) analyzed attack logs from the second quarter of 2026 targeting MS-SQL server and MySQL server installations on Windows. This report summarizes the damage status, attack status, and the classification of the malware and tools used in the attacks. Purpose and Scope The targets are MS-SQL servers and MySQL […]
Content In the second quarter of 2026, the AhnLab SEcurity intelligence Center (ASEC) compiled an analysis of the current attack status for poorly managed Windows web servers and classified the malware used in these attacks. The targets were Internet Information Services (IIS) web servers and Apache Tomcat web servers running in Windows environments. Purpose and […]
The percentage of ICS computers on which malicious objects were blocked continued to decrease, reaching 19.6% in Q1 2026. This is the lowest value in three years, and it is 1.4 times lower than in Q2 2023.
Percentage of ICS computers on which malicious objects were blocked, Q2 2023–Q1 2026
Regionally, the percentages ranged from 9.1% in Northern Europe to 27.4% in Africa.
Regions ranked by percentage of attacked ICS computers
The percentage of ICS computers on which malicious objects were blocked increased in five regions over the quarter, most notably in Southern Europe, Northern Europe, and Russia.
In Q1 2026, Southern Europe led the way in growth for internet and email threats. The region also saw the fastest growth in spyware, as well as malicious scripts and phishing pages.
In Russia, the percentage of ICS computers on which malicious objects were blocked exceeded the figures for the previous two quarters. Russia saw an increase in the percentage for threats from the internet, and a slight increase in the figure for threats from email clients (Russia is one of three regions where this figure did not decrease).
Among the threat categories, the greatest increases were observed in the percentages for denylisted internet resources, as well as spyware (distributed in the region via the internet and email clients).
Selected industries
Biometric systems (26.4%) traditionally rank top among the industries and OT infrastructure types covered in this report in terms of the percentage of ICS computers on which malicious objects were blocked. These systems are characterized by internet access, extensive email use for data exchange and approvals (such as access granting), and, in many cases, minimal cybersecurity controls within the organizations that use these systems.
Industries ranked by the percentage of ICS computers on which malicious objects were blocked
Biometric systems rank first among industries in terms of email threats. At the same time, unlike other industries, the percentage for email threats in biometric systems exceeds that for internet threats.
In all selected industries, the global average follows a downward trend. In Q1 2026, the percentage of ICS computers on which malicious objects were blocked increased only in the manufacturing sector — by 1.0 pp. The percentages for this industry increased across 10 regions, with the most notable increases in Western Europe, Northern Europe, and Russia.
Threat categories
In Q1 2026, Kaspersky security solutions blocked malware from 10,052 different malware families of various categories on industrial automation systems.
Over the quarter, the percentage of ICS computers on which denylisted internet resources were blocked increased (after decreasing over the previous two quarters), and there was a slight increase in the percentage for AutoCAD malware.
Percentage of ICS computers on which the activity of malicious objects from various categories was prevented
Malicious scripts and phishing pages (JS and HTML)
Malicious scripts and phishing pages retained their to spot among threat categories by the percentage of ICS computers on which these threats were blocked. The global average in Q1 2026 was 6.56%.
Over the quarter, the percentages increased in four regions. The most significant change was observed in Southern Europe (9.85%, +0.94 pp). The figures for malicious scripts in the region increased over three consecutive quarters.
Among the selected industries, across all regions, the highest percentages for the malicious scripts and phishing pages category were recorded for biometric systems (19.59%) and building automation (15.43%) in Southern Europe. These same industries lead in similar rankings for malicious documents and spyware.
Spyware
The percentage of ICS computers on which spyware was blocked decreased over two consecutive quarters, dropping to 3.73%. Despite the decline, spyware has ranked second among threat categories by the percentage of attacked computers for three consecutive quarters.
The percentages increased in five regions over the quarter, most notably in Southern Europe (5.46%, +0.35 pp) and Russia (2.84%, +0.24 pp).
In Southern Europe, the percentage of ICS computers on which spyware was blocked increased in all the selected industries except manufacturing. The greatest increase was observed in biometric systems.
Among the selected industries, the highest percentage of spyware in Russia was recorded in biometric systems. That said, the percentage of ICS computers on which spyware was blocked increased in all industries in the region except construction. The percentage figure has been increasing for two consecutive quarters in the oil and gas industry (by a factor of 1.63 over six months), and for three consecutive quarters in engineering and ICS integration, as well as electric power. In the remaining sectors, the values have been fluctuating.
Percentage of ICS computers on which spyware was blocked in various industries in Russia, Q3 2025–Q1 2026
Denylisted internet resources
The percentage of ICS computers on which denylisted internet resources were blocked increased to 3.54%.
The most notable increase over the quarter occurred in Southeast Asia (4.58%, +0.65 pp). Among the industries in the region, the highest percentage figures for this threat category were recorded in electric power and construction. Over the quarter, the largest increases in percentages figures were observed in the electric power and manufacturing industries.
In North America (Canada), denylisted internet resources (2.14%) showed the greatest increase among all categories — by a factor of 1.22.
Among the selected industries across all regions, the highest percentage figures for the denylisted internet resources category were in the electric power (7.11%) and construction (6.25%) industries in Southeast Asia.
Malicious documents (Microsoft Office + PDF)
The percentage figure for this category decreased over two consecutive quarters, reaching its lowest value (1.56%) for the entire period of observations in Q1 2026. It increased just in two regions: Australia and New Zealand (1.12%, +0.04 pp), and Russia (0.62%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for malicious documents were recorded for biometric systems (9.02%) and building automation (6.97%) in Southern Europe. These same industries also lead in similar rankings for malicious scripts and spyware.
Ransomware
The percentage of ICS computers on which ransomware was blocked has decreased for two consecutive quarters, dropping to 0.14%. This is the lowest value among all categories.
The percentage increased in two regions: North America (Canada) (0.11%, +0.04 pp) and slightly in Northern Europe (0.06%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for ransomware were recorded in the oil and gas and manufacturing industries (0.92% and 0.65%, respectively) in Central Asia and the South Caucasus, and in biometric systems (0.89%) in Russia.
Miners in the form of executable files for Windows
The percentage of ICS computers on which miners in the form of executable files for Windows were blocked decreased to 0.59%.
The percentage increased in seven regions. The largest increase was observed in Africa (0.63%, +0.16 pp). Among the selected industries, the largest increases in the region were in the manufacturing and oil and gas industries.
Among the selected industries across all regions, the highest percentages for miners in the form of executable files were recorded in construction (1.99%), biometric systems (1.98%), and the oil and gas industry (1.97%) in Central Asia and the South Caucasus.
Web miners
The percentage of ICS computers on which web miners were blocked has been declining for a year, and in Q1 2026, it reached the lowest value for the entire period under review (0.22%).
At the same time, the percentage increased in seven regions. The largest increases were observed in South Asia (0.28%, +0.11 pp), the Middle East (0.31%, +0.09 pp), and Africa (0.34%, +0.08 pp). Despite the increases, the percentages in these regions for Q1 2026 did not exceed those observed in 2023–2024 and in Q1 2025.
Among the selected industries across all regions, the highest percentages for web miners were recorded for biometric systems (0.97%) in Russia. Biometric systems in South Asia (0.79%) ranked second, and the electric power sector in Southeast Asia (0.76%) ranked third.
Worms
The percentage of ICS computers on which worms were blocked decreased to 1.33%.
The percentage decreased across all regions following an increase in the previous quarter (due to a wave of phishing attacks that distributed the Backdoor.MSIL.XWorm backdoor worm across all regions of the world).
Among the selected industries across all regions, the highest percentage figure for worms was recorded for biometric systems (4.80%) in Central Asia and the South Caucasus. Two industries in Africa – biometric systems (4.04%) and electric power (3.53%) – took the second and third spots, respectively.
Viruses
The percentage of ICS computers on which viruses were blocked decreased to 1.31%.
The top 3 regions by this figure remained the same: Southeast Asia (6.11%, first by a wide margin), Africa (4.15%), and East Asia (2.97%). These same regions are also among the leaders by the percentage of systems affected by AutoCAD malware. The largest increase in this figure was observed in Africa (+0.41 pp).
Among the selected industries across all regions, the highest percentages for viruses were recorded in the construction industry (6.35%) and building automation (5.50%) in Southeast Asia.
Malware for AutoCAD
The percentage of ICS computers on which malware for AutoCAD was blocked increased to 0.30%.
The most notable increase over the quarter was observed in Africa, with the region’s percentage figure rising by 0.47 pp, a very significant increase for this category, and almost doubling (to 0.91%).
Among the selected industries across all regions, the highest percentages for AutoCAD malware were recorded in the construction industry in East Asia (5.58%) and Southeast Asia (3.87%).
Main threat sources
In Q1 2026, the average percentages across all threat sources, except threats from the internet, decreased globally.
Percentage of ICS computers on which malicious objects from various sources were blocked
Internet
The percentage of ICS computers on which threats from the internet were blocked increased to 7.88%. However, over the past three years, the percentage figure for internet threats has followed a downward trend.
The largest increases in the percentages were recorded in Southern Europe (8.59%, +0.59 pp), Southeast Asia (10.16%, +0.55 pp), and Northern Europe (4.47%, +0.51 pp).
Among the selected industries across all regions, the highest percentages for threats from the internet were recorded in electric power (13.16%) and construction (12.55%) in Southeast Asia, and in the engineering and ICS integration sector (12.33%) in South Asia.
Email clients
The percentage of ICS computers on which threats delivered via email clients were blocked decreased to 2.59%. This is a three-year low.
The percentage of this threat source increased in three regions: Southern Europe (6.54%, +0.2 pp), East Asia (1.5%, +0.09 pp), and slightly in Russia (0.7%, +0.04 pp).
Among the selected industries across all regions, the highest percentages for email threats were recorded for biometric systems (19.78%) and building automation (12.34%) in Southern Europe. In these two industries, the percentage of ICS computers on which email threats are blocked is higher than the percentage for threats from the internet. A similar situation was observed in two other instances, both in biometric systems (in South America and Southeast Asia).
Removable media
The percentage of ICS computers on which threats were detected when connecting removable media continued to decrease, reaching its lowest value for the period under review (0.26%).
Among the selected industries across all regions, the highest percentages for removable media threats blocked on ICS computers were observed in the electric power sector in Central Asia and the South Caucasus (1.45%), East Asia (1.34%), and Africa (1.16%).
Network folders
The percentage of ICS computers on which threats are blocked in network folders is steadily decreasing. In Q1 2026, it was the lowest for the period under review (0.029%).
East Asia has traditionally led by a wide margin. The percentage for East Asia (0.135%) is 27 times higher than the lowest regional value (recorded in Northern Europe).
The largest increases in the percentages for threats from network folders were observed in Africa (0.037%, +0.006 pp) and South America (0.013%, +0.006 pp).
Among the selected industries across all regions, the construction industry in East Asia, at 0.36%, holds the top positions in the ranking by the percentage of ICS computers on which threats are blocked in network folders.