• Cisco Talos has identified UAT-11473, a highly sophisticated advanced persistent threat (APT) actor, who exploited CVE-2026-20127, an authentication bypass vulnerability in Cisco SD-WAN Catalyst Controller instances to bypass authentication and gain unauthorized access to affected systems.
• UAT-11473 then installed a custom malware framework we track as “KeyDrift” consisting of multiple components geared towards collecting sensitive keying information, acting as backdoors and intermediate command-and-control (C2) hosts.
• Observed targeting spans across space and satellite services, defense and aerospace technology, and policy research.

---

Talos assesses with high confidence that UAT-11473’s operating infrastructure overlaps considerably with Volt Typhoon’s “Silent Train” covert access network.

KeyDrift is a custom malware framework that is designed to operate in Cisco SD-WAN controller environments. Talos assesses with high confidence that the framework is designed to provide long-term persistent access and automated exfiltration of sensitive keying material. KeyDrift operates inside SD-WAN control-plane processes and is capable of intercepting decrypted control traffic, extracting control-session metadata and data-plane keying material, and staging or transmitting the collected material using encrypted records.

The framework's primary component is PolyFlame, a memory-resident module deployed through modified runit service paths. PolyFlame is injected into legitimate running vdaemon processes, and it can also masquerade as a packed “aaamgrd” loader variant. Once resident, PolyFlame interposes socket, DTLS, and runtime-linker behavior through functions such as recvfrom, sendto, getpeername, dlopen, dlsym, mprotect, and “/proc/%d/maps” parsing. This gives KeyDrift access to SD-WAN control-plane traffic from inside legitimate controller daemon execution rather than through a conventional endpoint beacon.

LittleFilch, another component of the KeyDrift framework, provides the collection and exfiltration capability identified in the framework. The module hooks “SSL_read” inside vdaemon, inspects decrypted control-plane buffers, extracts keying material for a list of predefined edge nodes, and stages the data locally in encrypted format for exfiltration.

Talos assesses with high confidence that KeyDrift's intended operational purpose is Cisco SD-WAN control-plane collection: persistent controller residence, in-band traffic access, key-material extraction from decrypted control messages, and encrypted staging or exfiltration of the recovered material. Observed variations of the KeyDrift modules and deployment mechanisms suggest active development of the framework’s capabilities.

KeyDrift analysis

KeyDrift uses Cisco SD-WAN runit service paths as its primary execution anchor. In the PolyFlame sshd deployment, the actor modifies the service run script, remounts /rootfs.rw executable, launches a malicious script “conf_sshd” in the background, and then starts the legitimate sshd service. The loader script enumerates running vdaemon PIDs, records them in “/tmp/system-vdaemon”, and invokes the injector component “rsshd” to inject PolyFlame (“libdssl.so”) into each process.

Recovered conf_sshd logic uses the same control flow across reviewed samples:

Runit launchers

The observed sshd runit launcher preserves normal Cisco SD-WAN sshd startup logic while adding two malicious lines before service execution, which remount “/rootfs.rw” executable and background execution of conf_sshd, which then drives rsshd injection into vdaemon.

The recovered aaamgr runit launcher from an affected vBond appliance uses a parallel service-wrapper pattern, but it executes the packed aaamgrd PolyFlame loader directly. The deletion of the writable-overlay PAM configurations for sshd and login before remounting “/rootfs.rw” executable if part of the legitimate script, along with the invocation of the aaamgrd daemon via Python:

PolyFlame

PolyFlame is the primary operational module in the KeyDrift framework. PolyFlame operates at the socket and DTLS control-plane layer. PolyFlame serves two primary purposes:

• Command execution via a TinyShell-styled backdoor
• Intermediate C2 that can forward commands to and from the C2 to other peers

PolyFlame is primarily injected into the vdaemon process, providing operational obfuscation and access to all in-process state: DTLS session keys, vEdge topology, OMP routes, and policy tables. No hardcoded IPv4 addresses, binding ports, callback domains, URLs, host headers, or polling interval were recovered from the analyzed PolyFlame samples. PolyFlame is designed for in-band control or tasking over Cisco SD-WAN control-plane traffic rather than a conventional fixed external beacon.

This implant is meant to serve as a hook of the recvfrom() API call. The original recvfrom is replaced by a malicious subroutine in the vdaemon process. When recvfrom is called in the vdaemon process, the malicious subroutine will first execute the real/legitimate recvfrom() API to obtain the C2 IP address info for communicating with it in the future.

PolyFlame’s time check

The recvd data from the C2 consists of the MD5 value of a specific DATE. PolyFlame will calculate the local time on the device in format “%Y-%m-%d" and calculate its MD5 hash. If the MD5 calculated by the device does not match with the one sent by the C2, the implant will stop further execution. Otherwise, the implant then uses an “administrative code” from the C2 and performs an action.

PolyFlame’s tasking

PolyFlame contains an administrative mode that processes the admin code sent by the C2, that defines operations — it's one of the first flags checked in the backdoor:

• Code = 1: Generate random bytes and send to C2. This is likely a check-in beacon or heartbeat for the C2.
• Code = 2: Set implant type to backdoor (TinyShell) or intermediate C2.
• Code = 3: Set up the command handler for the intermediate C2.
• Any other code value: Check the implant type flag currently set. Based on the implant type flag, either send the accompanying data to TinyShell or the intermediate C2 component for processing.

PolyFlame’s command execution

PolyFlame contains a backdoor that matches the capabilities of TinyShell: file read, file write, and arbitrary command execution, but not interactive shell. This backdoor component’s implementation is quite similar to TinyShell, but the command codes differ. PolyFlame handles the following command codes:

• Code = 0x100: Execute command using “/bin/sh -c <command>”
• Code = 0x200: Write file to disk.
• Code = 0x300: Read file from disk and send to the C2.

PolyFlame as an intermediate C2 component

The intermediate C2 component is a one-to-many handler (somewhat like a one-to-many multiplexer) — meaning the implant can connect to only one C2 but can connect to many peers who can be served by the intermediate C2 component. Similar to the TinyShell-backdoor component, the intermediate C2 component also accepts and processes specific command codes from the C2:

• Code = 0x403: Create a thread to connect to the specified peer IP. Make a new connection and keep socket alive until specified.
• Code = 0x404: Send data recvd from the C2 to a connected peer.
• Code = 0x405: Remove a peer from the list of active connections.
• Code = 0x407: Send a response recvd from a peer, back to the C2.
• Code = 0x408: Set a specific value in memory.

PolyFlame variant: aaamgrd

 Talos has observed a distinct PolyFlame variant that masquerades as the aaamgr service. The legitimate Cisco aaamgr component is a Python package; it does not normally appear as a compiled ELF runit service. This PolyFlame variant is executed by a malicious runit service under “/etc/sv/aaamgr/” with aaamgrd and a modified run launcher.

aaamgrd is a statically linked ELF64 executable with no section headers, a single RWE loader segment, and an RC4-encrypted embedded ELF payload. The loader uses direct syscalls including ptrace, fork, wait4, kill, tgkill, mmap, and mprotect. It performs an anti-debug check by deobfuscating /proc/%d/status and TracerPid: and exits if a tracer is present.

The observed staging sequence was:

Figure 4. PolyFlame staging sequence.

Note that in addition to the implant execution staging, there are also indications of timestomping.

LittleFilch: libcommon.so TLS interception module

LittleFilch is a control-session interception module positioned to collect data-plane keying material from control sessions visible to the injected vSmart process.

LittleFilch installs an SSL_read hook inside vdaemon. The hook calls the original SSL_read, then processes returned buffers only when the returned size is greater than 0x18F, the first decrypted byte is 0x07, and three marker patterns are checked for presence. These marker bytes are followed by the actual artifacts that LittleFilch aims to record:

Marker bytes	Parsed field	Length	Notes
40 03 06	Public IP	4 bytes	vEdge public / transport IP
40 0C 04	Peer system-IP	4 bytes	vEdge OMP system-IP
05 01 0C 06 40	Binary key field	32 (0x20) bytes	Assessed OMP-distributed AES-256 IPsec data-plane key material

LittleFilch records the extracted keying material and RSA-encrypts it before writing the output to “/var/tmp/vdaemon.bin”. It can then send the encrypted content over UDP in a DTLS 1.2 application-data style record.

LittleFilch expects its configuration file — located at “/var/tmp/vdaemon.conf” —  to contain two host port lines: one local bind IP/port and one remote destination IP/port. It deletes “/var/tmp/vdaemon.conf” after reading it. Talos has not been able to recover the “vdaemon.conf” file.

KeyDrift components

Component	Primary hook/surface	Observed scope	Confirmed function
PolyFlame libdssl.so	Socket / DTLS / runtime linker interposition inside vdaemon	Multiple affected controller roles	In-band control-plane interception and tasking; exact command format unresolved
rsshd	Ptrace injection	Multiple affected controller roles	Injects libdssl.so into vdaemon by PID
conf_sshd	Shell-based PID enumeration	Multiple affected controller roles	Locates vdaemon PIDs and records injection output
Trojanized run	Runit service launcher	Multiple affected controller roles	Remounts overlay executable and launches injector chain
Packed aaamgrd	Packed loader, direct syscalls, anti-debug	Affected vBond appliance evidence	Decrypts and runs embedded PolyFlame payload; tampers with PAM configs
LittleFilch libcommon.so	OpenSSL SSL_read hook	Affected vSmart process evidence	Extracts control-session identifiers and assessed data-plane key material from decrypted control traffic
vdaemon.bin	Encrypted staging file	Affected vSmart process evidence	Stores RSA-encrypted LittleFilch telemetry records
vdaemon.conf	Runtime endpoint config	Affected vSmart process evidence	Supplies local and remote UDP endpoint configuration; deleted after read

MITRE ATT&CK techniques 

Technique	ID	Notes
Process Injection: Ptrace System Calls	T1055.008	rsshd injects libdssl.so into vdaemon by PID
Hijack Execution Flow: Dynamic Linker Hijacking	T1574.006	PolyFlame uses dlsym(RTLD_NEXT, ...), dlopen, and runtime interposition
Boot or Logon Initialization Scripts	T1037	Modified runit service scripts launch KeyDrift components
Create or Modify System Process	T1543	Malicious service paths under etc/sv/sshd/ and etc/sv/aaamgr/
Masquerade Task or Service	T1036.004	sshd and aaamgr service-name masquerading
Unix Shell	T1059.004	conf_sshd and recovered operator staging commands
Software Packing	T1027.002	aaamgrd uses packed embedded ELF payload
System Checks	T1497.001	aaamgrd checks TracerPid before unpacking
Timestomp	T1070.006	touch --reference= and chmod --reference= staging commands copied reference file metadata
Network Sniffing	T1040	PolyFlame and LittleFilch intercept SD-WAN control-plane traffic
Encrypted Channel: Symmetric Cryptography	T1573.001	PolyFlame AES implementation; aaamgrd RC4 packer; LittleFilch RSA-encrypted records

Recommendations

Cisco has released patches for CVE-2026-20127 and published a hardening guide for Cisco Catalyst SD-WAN deployments available here. Organizations are strongly advised to prioritize the application of these patches and follow the guidance provided.

Following the identification of UAT-11473 activity, Talos strongly recommends that organizations monitor their systems for indicators of post-compromise activity. Should any signs of unauthorized activity be detected, organizations should immediately activate their incident response frameworks. Contact the Cisco Technical Assistance Center (TAC) for support by initiating a TAC request.

Coverage

Snort SIDs are already available for CVE-2026-20127: 65938, 65958.

Snort SIDs for the malicious artifacts illustrated in this blog:

• Snort v2: 67387 through 67416
• Snort v3: 7:44 through 7:73

Cisco Talos is aware of eight compromised intermediate certificates belonging to the intermediate certificate authority, eMudhra. Rather than possessing the mandatory 384 bits of pseudo-random security, several private keys evaluated single-digit and double-digit integers. This misconfiguration allows an attacker with the private key of any of the compromised intermediate CAs to impersonate any website or service. Six of the TLS certificates, trusted by Chrome, Mozilla, and Apple have been blocked by these vendors already. Two other certificates, used for codesigning by Microsoft, have also been blocked. Talos expects there will be additional patches available across a variety of technologies as software applications work to remediate the certificates’ exposure.

Following the disclosure, eMudhra has revoked the compromised certificates and stopped issuing new certificates under its G3 root.

Compromise details

The cause of this issue, originated during an April 30, 2025 key generation activity conducted by eMudhra under its emSign Root TLS CA - G3 and cross-signed Comodo AAA Certificate Services.  During a key generation ceremony for 24 subordinate CAs, a flaw in eMudhra’s key generation process created a second set of weak P-384 keys during a wrap/unwrap step. Those keys were mistakenly used for eight intermediate CA certificates. This flaw took the encryption from 384 bytes of entropy down to 3 – 8, making recovering the private keys trivial. The following are the impacted certificates, as illustrated in Mozilla’s bug report:

EM EV TLS CA - G3B (eMudhra BV), CCADB A012304
SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
serial c7c41efe92d825f05eae841a4a82c1, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3B (eMudhra BV), CCADB A012308
SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
serial 6cada367fb1c100088120ea202d568, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3B (eMudhra BV), CCADB A012302
SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
serial a4aee678f23362b4c0e460b772f214, issuer emSign Root TLS CA - G3

EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296
SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
serial 8009928a64107601af05fa2f19f109, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300
SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
serial 296926c227a3a1526392b19482a504, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294
SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
serial 588b2e3c2bb8cda13e1a1209254321, issuer emSign Root TLS CA - G3

EM OV CS CA - G3B (eMudhra BV), CCADB A012306
SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
serial 7818933f8f85b4619a2b35fba83d0a, issuer emSign Root CS CA - G3

EM OV CS CA - G3C (eMudhra Inc), CCADB A012298
SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
serial 544b7f922c31ae220a4a922916f6e6, issuer emSign Root CS CA - G3

CVE-2026-111943 

Unlike languages that defer entirely to external dynamic system libraries (like OpenSSL), the Go programming runtime implements its own X.509 chain verification engine in the standard library (crypto/x509). While Go usually queries platform certificates, several platforms or static container environments rely on embedded or legacy root certificate pools where certificate revocations are ignored. 

To eliminate exploitation across the entire cloud-native ecosystem including Docker, Kubernetes, Terraform, and Prometheus, the Go team designated the compromised certificates as a vulnerability, CVE-2026-111943, and released Go versions 1.27.3 and 1.26.10. 

 The fixed versions filter out chains containingthe SHA-256 hashes of the SubjectPublicKeyInfo (SPKI) for all eight compromised eMudhra intermediate certificates.

Impact

These compromised certificates could allow adversaries to impersonate servers and intercept or modify traffic. The impact of their exposure is far more than just web browsers. Other programs that check for TLS certificates might still be impacted since they may not check revocation lists. One clear example is related to virtual private networks (VPNs); these technologies will likely require software updates to mitigate the issue. Based on this guidance, Talos strongly recommends users update software using and handling TLS certificates as fixes become available.

Talos is actively monitoring the impact of these compromised certificates and has not seen any malicious incidents involving them in the wild yet (as of October 21, 2026 14:00 UTC / 10:00 a.m. ET).

Significance of this breach  

Public key infrastructure relies on trust being delegated through certificate chains: root CAs authorize intermediate CAs, which can issue certificates within the scope of their authority. An attacker who obtains an intermediate CA’s private key may be able to issue fraudulent certificates that clients accept, subject to the intermediate certificate’s constraints and each client’s validation controls. In this incident, six compromised intermediates were for TLS and two were for code signing.

 For TLS, an attacker able to intercept or redirect a connection could use a fraudulent certificate to impersonate a server and potentially read or modify traffic if the client still trusts the affected key and no applicable protection blocks it. Protections such as revocation, key distrust, certificate transparency enforcement, and certificate pinning can prevent or expose such an attack. Browser vendors have blocked the affected TLS keys, but other applications may rely on separate trust stores or validation paths:

Enterprise infrastructure and VPNs

Organizations should assess TLS-using software and appliances, including proxies, reverse load balancers, VPN clients, and gateways. Exposure depends on the certificate chain being validated and the trust store and revocation behavior in use. A stale or separately managed trust store may need an application, operating-system, firmware, or trust-bundle update; verify the required action for each product.

Software supply chains and CI/CD

Build runners and package managers may be exposed if they fetch content over TLS while still trusting an affected key and an attacker can intercept the connection. A fraudulent TLS certificate could enable registry impersonation, but it would not by itself bypass separate package integrity checks, such as lockfile hashes, checksums, signatures, or provenance controls. Assess the actual package-manager configuration and dependency path.

Industrial IoT and embedded systems

Review devices that use bundled or independently managed CA stores, especially where certificate revocation or trust-store updates may be limited. Some devices may require a vendor update or compensating control, but the necessary action depends on each device’s validation and update mechanisms.

Talos recommends updating affected software and trust stores as vendor fixes become available.

Coverage

The following SNORT® SIDs provide coverage for this threat: 67363 - 67374.

 

Talos would like to highlight the efforts of Chris Morrison for providing emergency coverage and mitigations for this threat.

Update 10/22: Added section detailing observations of in the wild exploitation and associated IOCs.

Cisco Talos is tracking the disclosure of two unauthenticated remote code execution (RCE) flaws in PHP core, dubbed “php2shell”, triggered by a plain HTTP request and exploitable before any application code runs, affecting every PHP build since 5.4. Based on the entities involved in the disclosure, artificial intelligence and associated technologies played a key role in the discovery of these vulnerabilities — yet another example of how these technologies are forcing change across the landscape, most notably on patching processes for organizations because of the wave of vulnerabilities being disclosed. 

Cisco customers are covered with the Cisco Talos Network Intrusion Prevention (SNORT®) signatures 67359, 67360, and 67375. These rules are also available in the Community Ruleset for open-source customers. Splunk Enterprise Security customers have an Enterprise Security Content Update with detections available. Please refer to the following recommendations, detection, and coverage guidance for more information.

Details

CVE-2026-109618 and CVE-2026-109619 are both critical vulnerabilities with a CVSS v4.0 score of 9.2.

• CVE-2026-109618 occurs when out-of-memory handling interrupts PHP while internal request data is only partially initialized. Request cleanup may then treat invalid data as valid.
• CVE-2026-109619 occurs when a stale internal state is reused after its backing memory has already been freed, before normal initialization resets it.

Impact

The potential blast radius is enormous and extends across the PHP ecosystem. The vulnerability sits in PHP core, so applications running affected versions — including WordPress, Drupal, Magento, Shopware, WooCommerce, and Laravel, plus PHP sites hosted through cPanel or Plesk — may be exposed. Note that many older branches will no longer receive fixes, so customers are urged to upgrade to a supported version as soon as possible.

Talos regularly investigates threat actor exploitation of vulnerabilities. State-sponsored and affiliated threat actors, as well as ransomware and other financially motivated groups, all employ tactics to exploit RCE. Talos assesses that all industries running PHP applications are at risk for exploitation if systems remain unpatched.

PHP 8.1 and older are end of life (EOL), and PHP 8.2 security support ends Dec. 31, 2026. Talos’ initial estimates based on open-source intelligence show a significant corpus of PHP systems that will not receive a patch (~50%). If your organization is running PHP 8.1 or older, Talos very strongly advises immediate update to PHP 8.2 or later. There is no patch for PHP 8.1 or older.

Talos is actively monitoring the impact of these CVEs and has not seen them being exploited in the wild yet (as of October 21, 2026 14:00 UTC/10:00 a.m. ET).

Observed Exploitation 

Cisco Talos began observing exploitation attempts within hours of the vulnerabilities’ disclosure. So far, most of the activity is scanning, along with some uncoordinated attempts to deliver various payloads. This is expected: scanning or basic exploitation with public proof-of-concept (PoC) code takes far less effort than integrating a vulnerability into an actor’s own tooling. We expect exploitation volume to grow in the coming days, and campaigns to become more sophisticated and coordinated as more capable groups finish updating their tooling and begin deploying it. 

Recommendations and detection guidance

Talos strongly recommends all PHP users to upgrade to the available fixed releases. There are no intermediate or temporary controls that provide comprehensive protection; however, PHP advises that the following measure may reduce exposure to specific attack paths:

CVE-2026-109618

• Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
• Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
• Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

CVE-2026-109619

• Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool, or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
• Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors, or @ does not help.
• Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing, and cleanup.

This is another vulnerability that owes its discovery to AI and its associated technologies. As we move through 2026, the wave of vulnerabilities and related patches is building. Talos advises organizations to work on a triaged process for prioritizing vulnerabilities with a specific focus on public-facing systems and vulnerabilities that are under active exploitation. The glaring need to prioritize vulnerabilities along with a streamlined process for rolling out patching strongly indicates that the historic trend of “baking in” patches before deployment is not going to survive the AI era.

The true impact of this vulnerability will take time to evaluate. These types of vulnerabilities that impact core technologies tend to cascade into other platforms and applications as they evaluate impact and provide associated patching, harkening back to the waves of exploitation that we saw after Log4J.

Coverage

SNORT® SIDs covering these vulnerabilities for subscribers: 67359, 67360, 67375. Free community rules are live through our Community Ruleset.

Splunk has released an Enterprise Security Content Update (ESCU) related to the ongoing PHP2Shell activity with additional detections. Splunk Enterprise Security customers are urged to download and apply.

Talos would like to highlight the efforts of Ankur Tyagi, Dalton Schaadt, Brandon Stultz, and Matt Killion for providing emergency coverage and mitigations for these threats.

In this video, Talos’ Nick Biasini explains what the vulnerabilities allow adversaries to do, how to assess your exposure, and what defenders should prioritize.

Indicators of Compromise (IoCs) 

5.191.140[.]240 
158.69.113[.]75 
94.154.43[.]149 
143.246.223[.]124 
45.198.224[.]169 
85.11.167[.]243 

This research was conducted jointly with Julian-Ferdinand Vögele of Recorded Future’s Insikt Group. Details of the joint research and presentation are available here.

• Cisco Talos identified UAT-6275 (TAG-193 by Recorded Future) activity targeting government organizations across the Commonwealth of Independent States (CIS). Recovered artifacts show additional interest in water resources and energy. This focus is consistent with intelligence collection and may reflect the regional effects of the Russia–Ukraine war. 
• In activity observed from June 2025 through August 2026, Talos identified four infection-chain types that use macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and a crafted WinRAR archive exploiting CVE-2025-8088. The recovered payloads include several custom reverse shells that provide interactive remote access. 
• Three publicly accessible staging directories and GitHub repository history exposed payload builds, tool inventories, and changes to command-and-control (C2) infrastructure. These operational security lapses gave us direct visibility into the group's recent activity. 
• The files recovered from the exposed infrastructure suggest preparation for post-compromise operations and potential activity against Linux hosts and internet-facing appliances.  
• Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus, based on infrastructure access, language artifacts, sample submissions, working hours analysis, and regional targeting interests.

---

Background 

Cisco Talos and Recorded Future Insikt Group jointly investigated UAT-6275 activity targeting government organizations across the Commonwealth of Independent States (CIS). The investigation uncovered three publicly accessible staging directories and a previously unreported GitHub repository used to host malicious scripts and payloads. These exposed assets provided visibility into the threat actor's malware development, infrastructure changes and preparations for additional intrusion activity. 

Talos tracks this activity as UAT-6275, while Recorded Future tracks it as TAG-193. It overlaps with Silent Lynx (first reported by Seqrite) and sits within a broader set of campaigns connected to YoroTrooper, which we first reported in 2023. Subsequent research on Tomiris (Kaspersky), ShadowSilk (Group-IB), Cavalry Werewolf (BI.ZONE), and Hydra Saiga (VMRay) identified overlapping indicators across these reported clusters. We assess that UAT-6275 and YoroTrooper likely belong to the same broader activity cluster. However, we continue to track them separately because we have not observed direct indicator or toolset overlap between the two.

This post summarizes our joint Virus Bulletin 2026 white paper, “Break the silence: tracking Silent Lynx through exposed infrastructure” which contains the full technical analysis and indicators of compromise (IOCs).

Victimology 

UAT-6275's targeting is concentrated in Central Asia and the wider CIS region. Across the reviewed campaigns, observed victims and lure themes span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus.

Government and diplomatic affairs 

UAT-6275 targets government institutions responsible for diplomacy, economic development, agriculture, and environmental management. These organizations hold information that can inform bilateral negotiations, economic planning, and regional security decisions.

Our network flow analysis identified activity involving a Tajik government entity shortly after treaty discussions with Kazakhstan in March 2026 and a Belarusian government entity ahead of a bilateral meeting in April. This timing may indicate an interest in regional diplomatic developments.

The decoy documents we recovered also suggest an interest in diplomatic relations, international trade, and aviation. Examples include a diplomatic letter addressed to Armenia’s Ministry of Foreign Affairs.

Water security and resource management 

The group’s interest in regional resources spans environmental management and energy. Talos observed activity involving an Armenian government entity responsible for environmental matters and Uzbekistan’s Smart Forestry initiative, consistent with earlier reporting on Silent Lynx targeting water resource organizations across Central Asia. 

Energy-themed decoys included a cooperation proposal between Turkmenistan’s state oil company, Turkmennebit, and Russia’s Orsk Oil Refinery, used in an August 2025 sample. The refinery supplies petroleum products to Kazakhstan and later shut down after a Ukrainian drone strike in August 2026, with repairs expected to take up to six months. These ties suggest a possible intelligence interest in regional fuel supplies and the war’s implications for Kazakhstan’s energy security.

Campaign timeline 

Since Seqrite first reported Silent Lynx in January 2025, we have identified at least eight campaigns across the region through May 2026. These include malware delivery targeting Russia, Turkmenistan, and Uzbekistan; a credential-harvesting site impersonating Azerbaijan’s State Agency for Public Service; and lures referencing the China–Central Asia Summit and Russian energy infrastructure. In 2026, we also observed activity involving government entities in Tajikistan, Armenia, and Belarus, as well as Uzbekistan’s Smart Forestry initiative in May. 

Infrastructure and malware delivery 

Talos identified three publicly accessible staging directories containing malware and tools of UAT-6275. One sample led to the previously unreported GitHub repository, where the group hosted PowerShell scripts and payloads. Its commit history allowed us to track infrastructure changes and malware development.

The group relies on lightweight reverse shells, including Chvost, Laplas, and PickleShell, to issue commands on compromised systems.

We also recovered Linux-compatible tooling and a publicly available proof-of-concept exploit for FortiWeb CVE-2025-25257 from UAT-6275 infrastructure. These findings suggest interest in expanding the group’s operational capabilities. 

Four infection chains 

UAT-6275 used malicious documents, executable downloaders, and shortcuts to deliver malware, and later incorporated a WinRAR exploit. Talos categorized the recovered samples into four infection chains, A – D, based on how they retrieve and execute their payloads.

The first Chain A samples, observed in June 2025, used macro-enabled Word documents to download and execute a second-stage binary. In July 2025, we observed Chain B downloaders built with PS2EXE, a tool that packages PowerShell scripts as standalone Windows executables. These downloaders retrieved reverse-shell payloads and created scheduled tasks for persistence. 

We first observed Chain C in October 2025. A malicious shortcut launches PowerShell to retrieve and execute a GitHub-hosted script that provides remote shell access. Later samples also downloaded PickleShell and placed it in the Windows Startup folder for persistence.

In April 2026, we identified a RAR archive that exploited CVE-2025-8088 in WinRAR to place PickleShell in the Windows Startup folder (Chain D). The payload runs at the next user sign-in. This was the first vulnerability exploit we observed in UAT-6275’s malware delivery.

Kazakhstan nexus assessment 

Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus. Supporting evidence includes Russian-language artifacts, apparent malware-testing submissions from Kazakhstan shortly after compilation, and operator activity consistent with UTC+5 working hours.

Looking ahead 

UAT-6275’s sustained activity and adoption of new delivery techniques suggest the group will continue pursuing access to government organizations across Central Asia and the CIS. Its interest in environmental agencies, economic ministries, and energy infrastructure reflects the intelligence value of regional diplomacy and resource management. 

Defenders in these sectors should monitor unexpected PowerShell activity and payload downloads from public services such as GitHub, alongside scheduled tasks and Startup-folder changes. Keeping archive utilities patched can help reduce exposure to the exploit-assisted delivery observed in this campaign. 

For further details on this research and our accompanying presentation, see “Break the Silence: Tracking Silent Lynx Through Exposed Infrastructure” on Virus Bulletin’s website, as well as Recorded Future’s related blog post.

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.PickleShell-10060602-0 
• Win.Backdoor.Chvost-10060603-0 
• Win.Malware.Generic-10060604-0 
• Win.Malware.LAPLAS-10060605-0 
• Win.Malware.LAPLAS-10060606-0 
• Win.Proxy.Generic-10060628-0 

The following Snort rules cover this threat: 

• Snort 2: 1:11192, 1:15306, 1:46983, 1:47398 
• Snort 3: 1:46983, 4:16 

IOCs

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

• Cisco Talos identified an advanced persistent threat (APT) spear-phishing campaign against individuals affiliated with Taiwan research organizations. The operation leveraged legitimate public event themes and impersonated reputable academic and policy institutions to establish credibility. 
• The phishing emails exhibited highly consistent structure, rhetoric, and personalization patterns, suggesting the threat actor likely used AI-assisted content generation to rapidly customize invitation lures for different targets while maintaining a common social engineering framework. 
• Beyond traditional email phishing, the actor incorporated QR code phishing (quishing) techniques by modifying legitimate event posters with malicious QR codes, expanding the attack surface beyond email recipients to secondary victims who may encounter printed materials. 
• The campaign deployed an advanced adversary-in-the-middle (AitM) phishing framework that impersonated Google authentication pages and utilized a hybrid HTTP and WebSocket architecture to synchronize authentication workflows in real time, enabling the interception of credentials and multi-factor authentication (MFA) challenges. 
• After technical analysis of the phishing kit, Talos assesses with moderate confidence that the user interface was originally developed in Simplified Chinese and later adapted for Traditional Chinese and English. The localization architecture, Simplified Chinese default language branch, and mainland-Chinese lexical usage collectively suggest a developer whose primary working language is Simplified Chinese.

---

In mid-2026, Talos observed an APT spear-phishing campaign targeting Taiwan-based research organizations. The threat actor appeared to reuse legitimate or plausible public event information, then embedded a hyperlink to actor-controlled infrastructure, while the displayed URL appeared benign. Several invitation emails exhibited nearly identical syntactic structures despite discussing different geopolitical topics, suggesting the content was generated from a reusable prompt template rather than independently authored. While Talos cannot conclusively determine whether the emails were fully generated by a large language model (LLM), the campaign demonstrates strong evidence of AI-assisted content production and personalization. 

Spear-phishing mail 

Based on the phishing emails we observed, the threat actor impersonated legitimate institutions in Taiwan such as Taiwan European Union Centre, NCCU Institute of International Relations, and Taiwan Research Institute. Below is a deep analysis of the mail contents.

An email recipient contacted the organizations concerned to verify the purported senders. However, none of the organizations could confirm that the three senders were employees or representatives of the institutions named in the emails. This suggests that the threat actor fabricated the sender identities while using legitimate organizational names and publicly available event information as cover.

All three emails follow a highly consistent, three-part structure, indicating the use of a common template. The opening section provides a polished (but overly elaborate) description of the geopolitical or policy context. It relies heavily on grandiose yet vague expressions such as “the global strategic landscape,” “reshaping the great-power order,” “three-dimensional analysis,” “forward looking and in-depth analysis,” and “high intensity professional dialogue” to create an impression of academic authority and subject matter expertise. Although the language is generally fluent, the excessive use of policy jargon and abstract strategic terminology makes the content appear formulaic.

The second section is customized for the recipient and uses targeted flattery to encourage engagement. Similar phrases including “admiration,” “authoritative perspective,” “highly perceptive,” and “key practical dimensions” appear across the three messages. These compliments are broadly applicable and contain few verifiable details about the recipient’s actual work, suggesting that the actor personalized a reusable template using publicly available professional information. References to exclusive participation, reserved VIP seating, or the recipient’s supposedly unique expertise further exploit professional recognition and status to reduce suspicion.

The final section presents event logistics, including the topic, date, venue, and registration instructions. Although much of this information appears to have been copied from legitimate institutional websites or public event announcements, its accuracy does not validate the email or the sender. Instead, the actor appears to use authentic event details as a form of legitimacy laundering. The registration links embedded in the emails do not direct recipients to the legitimate event registration pages they seem to represent. For example, one hyperlink displays a legitimate-looking Google Forms URL, while its underlying href redirects the recipient to a deceptive phishing site hosted on a third-party platform. This mismatch between the visible link text and the actual destination demonstrates a deliberate attempt to conceal the phishing infrastructure and exploit the recipient’s trust in a familiar service.

Taken together, the reuse of an almost-identical narrative structure, rhetorical style, personalized flattery, institutional impersonation, and deceptive registration mechanism strongly suggests a coordinated and carefully targeted spear-phishing campaign rather than three independent invitations. The messages also exhibit characteristics consistent with AI-assisted content generation such as grammatically fluent but formulaic prose, excessive use of grandiose and abstract policy terminology, interchangeable praise, repetitive sentence patterns, and rapid customization for different recipients, institutions, and geopolitical topics. Although these linguistic indicators alone cannot conclusively prove the use of generative AI, their consistency across all three emails suggests that the threat actor likely used an AI-assisted template to produce and personalize the phishing lures at scale. The legitimate event details and visible Google Forms URLs were then combined with disguised hyperlinks leading to actor-controlled phishing pages, making the emails appear credible while concealing their actual destination. 

Quishing in the poster 

We also observed the threat actor attaching event posters to several phishing emails. While the poster designs were scraped from legitimate websites, the embedded QR codes were maliciously altered. This modification indicates a calculated physical world attack vector. The actor may have anticipated that recipients might print and display these posters on office bulletin boards, thereby tricking other individuals into scanning the malicious QR code to register for the event. By doing so, the threat actor expands their attack vector beyond traditional email phishing to include quishing (QR code phishing), and broadens their reach within the targeted entities.

Phishing kit used by UAT-11985 

Phishing page’s impersonation 

These three phishing email attacks use the same tactics, techniques, and procedures (TTPs) which include a phishing page impersonating a legitimate Google Form and appearing visually identical to the authentic service. However, aligned with the threat actor's primary objective of credential theft, the malicious form forcibly redirects the user to a spoofed Google login page.

Talos observed that the spoofed Google login panels only support Simplified Chinese (zh-CN), Traditional Chinese (zh-TW), and English locales, with region detection based on the victim's browser “navigator.languages”, strongly suggesting targeting of Chinese-speaking users.

We also observed that this phishing page revealed a hidden HTML <section> designed to simulate a successful Google authentication event. Within this structure, the threat actor embedded an iframe (ID: google-success-frame) configured to load a locally hosted asset (/google-login-assets/operation-success.html). Notably, the iframe includes the sandbox="allow-scripts" attribute. We will discuss JavaScript in the next section.

Attack summary  

The attack chain initiates when a victim clicks a malicious URL delivered via a phishing email. Upon access, the victim is presented with a pixel-perfect replica of the Google sign-in page, which covertly hosts an obfuscated JavaScript payload. Operating as an adversary in the middle (AitM), the threat actor positions their infrastructure between the victim's browser and legitimate Google authentication servers. This allows them to seamlessly forward credentials and dynamically control the victim's user interface step-by-step via a persistent WebSocket connection.

To evade detection and complicate analysis, the malicious JavaScript is embedded at the end of the HTML document and relies on advanced string rotation obfuscation. The script leverages a large, static array of Base64 encoded strings coupled with control flow obfuscation. By utilizing a while(!![]) { push/shift } shuffle loop mechanism, the array rotation is resolved dynamically at runtime, effectively thwarting automated static deobfuscation tools.

Talos’ analysis of the phishing kit's client-side JavaScript indicates, with moderate confidence, that the user interface localization was authored by a native Simplified Chinese speaker. The strongest indicator is the kit's localization architecture:  

1. The base translation object (T) is written entirely in Simplified Chinese and is directly assigned as the zh-CN locale, while the Traditional Chinese (zh-TW) and English (en) locales are derived from it at runtime via an override or merge function (v(T, {...})).  
2. This structure demonstrates that the interface was originally composed in Simplified Chinese and subsequently translated into Traditional Chinese and English, consistent with Simplified Chinese being the developer's primary working language.
3. This assessment is reinforced by lexical choices characteristic of mainland Chinese usage rather than Taiwanese, Hong Kong, or Southeast Asian conventions. For example, the text uses Simplified Chinese forms such as “账号” for “account,” whereas Traditional Chinese environments would more commonly use “帳號” or related variants. Similarly, terms such as “计算机” for “computer,” “邮箱” for “email/mailbox,” “无痕浏览窗口” for “incognito browsing window,” and “访客模式” for “guest mode” reflect terminology commonly seen in mainland-oriented Simplified Chinese software localization. In Taiwanese or Hong Kong contexts, these concepts are typically rendered with Traditional Chinese characters and often different localized wording, such as “電腦,” “電子郵件/信箱,” or “無痕式視窗.” This linguistic pattern is further supported by the ternary-fallback ordering throughout the code, which consistently places Simplified Chinese as the default branch.

Operator-driven phishing page 

Following the deobfuscation and analysis of these JavaScript payloads, Talos identified an advanced, real-time AitM phishing kit targeting Google accounts. Unlike fully automated phishing kits, this framework appears optimized for operator-driven authentication orchestration. This kit impersonates the Google sign-in interface across three locales (zh-CN, zh-TW, en) and employs a dual-channel architecture including HTTP POST and WebSocket to synchronize Google's authentication state in real time. This mechanism effectively bypasses multi-factor authentication (MFA) to harvest complete, authenticated session tokens.

The threat actor deliberately employs a split communication channel architecture to optimize both data exfiltration and real-time command and control (C2) efficiency. For the outbound data exfiltration, the threat actor utilized HTTP POST for stateless, event-driven data transmission. The phishing page actively pushes captured data to the C2 server, including initial browser fingerprints, credential and challenge submissions during user interaction, and periodic heartbeat polls to maintain synchronization. Each call completes independently.

The threat actor uses WebSocket to provide a low-latency, persistent connection. The C2 server streams real-time instructions to the phishing page via this channel, dictating exactly which MFA challenge screen to render. Cisco Talos has also recently published a report on a different phishing campaign where similar WebSocket techniques were observed in a phishing kit used by a Chinese-speaking actor. However, the strategies employed by that phishing kit differ from those in this case.

The following diagram illustrates the real-time AitM relay architecture.

At the beginning phase, the threat actor collects device and browser information, including the locale, user agent, screen dimensions, and mobile-device status. This data is sent to the actor’s HTTP C2 server through a google_login_start request. After the server creates a session, the JavaScript establishes a WebSocket connection with the actor’s C2 infrastructure and receives a snapshot containing the current session state.

The victim enters an email address or phone number into the fake Google login page. The phishing page sends the identifier to the actor’s HTTP C2 server using the google_input_identifier event. The actor’s server then relays the identifier to the real Google authentication service to verify whether the account exists and determines whether a passkey-based flow is enabled. Based on Google’s response, the actor instructs the phishing page through WebSocket state updates to display either the password-entry page or a passkey prompt.

When the victim submits a password, the phishing page sends the password, account identifier, and browser user-agent information to the actor’s HTTP C2 server through a google_login_check request. The actor’s server forwards the credentials to the real Google authentication service. If the credentials are accepted and Google requires additional authentication, the server returns the MFA challenge type and layout. The actor then advances the victim’s interface to the appropriate MFA step through a WebSocket update.

By deliberately splitting one-shot uploads with POST requests from low-latency state updates with WebSocket connection, the threat actor has engineered a seamless credential-harvesting relay. This allows the threat actor to mirror Google's dynamic authentication state in real time, ultimately achieving full account takeover without raising the victim's suspicion.

Coverage  

The following ClamAV signatures detect and block this threat:  

• Html.Phishing.UAT11985-10060614-0 

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

• Snort2: 1:67198
• Snort3: 7:31

Indicators of compromise (IOCs)  

The IOCs can be found in our GitHub repository here.

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

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

Instructions	Purpose
to_index	Send victim to the landing/entry page
to_login	Send victim to site-login page
to_password	Prompt for account password
to_info	Collect PII
to_card	Send victim to card-entry page
to_qr	Show QR code for scan-based verification
to_sms	Request SMS OTP
to_sms_login	Request SMS OTP for login step
to_sms_bank	Request SMS OTP for bank verification
to_2fa	Request 2FA code
to_text_verify	Request custom text/code verification
to_email	Request email OTP
to_pin	Request card PIN
to_app	Request bank-app push approval
to_login_app	Request app-based login approval
to_bank_login1	Step 1 of multi-stage bank login
to_bank_login2	Step 2 of multi-stage bank login
to_bank_login3	Step 3 of multi-stage bank login
to_custompage	Route to a custom/template-defined page
to_shop	Show fake storefront/shop page
to_paypal_login	Collect PayPal login credentials
to_paypal_card	Collect card data via PayPal-branded flow
to_paypal_card_verify	Request card verification text (PayPal flow)
to_paypal_sms	Request PayPal-linked phone OTP
to_paypal_email	Request PayPal-linked email OTP
to_paypal_pin	Request PayPal PIN
to_paypal_app	Request PayPal app-approval verification
to_apple_login	Collect Apple ID login
to_apple_sms	Request Apple-linked SMS OTP
to_apple_email	Request Apple-linked email OTP
to_apple_card	Collect card data via Apple-branded flow
to_apple_verify	Request generic Apple verification step
to_klarna_login	Collect Klarna login credentials
to_klarna_sms	Request Klarna-linked SMS OTP
to_klarna_email	Request Klarna-linked email OTP
to_klarna_pay	Collect Klarna payment details
to_klarna_pin	Request Klarna PIN
to_success	Sends full data to the C2 and redirect victim to a real site
to_redirect	Redirect victim out to an operator-supplied URL
tip_fail	Show generic declined/invalid error, force re-entry
tip_custom_fail	Show an operator-authored custom error message
to_page_custom_fail	Route to a custom failure page defined per template
tip_change_card	Fake card-declined prompt to extract a second/different card
updata_img	Push a new image likely a refreshed QR code without navigating
updata_2fa	Silently inject/display an OTP code supplied by the operator
text_updata_verify	Push custom verification text to display, without navigating
submitResult	Operator pushes a corrected or enriched copy of the victim's form data back into the session

The JWR client engine has a data exfiltration schema. Its scope extends well beyond payment data, and includes full identity information (name, gender, date of birth, Social Security Number, passport, driver's license, medical record number), address, email and email password, up to three sets of website credentials, PayPal login, complete card data (PAN, expiry, CVV, PIN, brand, issuer, issuing country), front and back card images, photos of identity documents, and an automatically captured browser fingerprint, including IP, device, language, time zone, user agent, cookies, and geolocation. 

Upon submission, the client normalizes the submission types, triggering a full-screen non-interactive overlay over the page. For credit card submissions, a Lottie animation is displayed that corresponds to the card brand detected from the first two BIN digits. After exfiltration, when the actor closes the WebSocket, terminate the worker and POST the entire cvvformobject to the C2 endpoint at api/open/the_final_interface. Once the actor confirms, the victim is redirected to the actual site. 

Talos discovered that the primary mode of C2 communication for the JWR kit is via a binary WebSocket connection. The WebSocket path follows the format shown below, where the JWRCID and JWRCVV segments encode the victim’s unique session token, and the trailing alphanumeric suffix is likely a server-side authentication token. 

Alongside the WebSocket, the JWR client registers five Representational State Transfer (REST) endpoints which are used as an alternate communication method, between the C2 and the victim browser. In this case, a session opens with api/open/addClick, executed once from within the mounted function after the phishing page becomes visible to the victim. It reports the victim's IP address, country, the specific phishing page they landed on, the referring or storefront URL, and a bundle of device and operating system (OS) metadata to the actor's console with a live "new visitor" entry before a single instruction has even been sent by the actor from the C2 server. Running alongside it is api/open/getSyncSettings, which pulls inbound configuration from the actor's server rather than exfiltrating anything, letting the actor change error messages, default contact placeholders, currency display, and other behavior on the fly without redeploying the client engine. For the victim’s environments where a persistent WebSocket connection is unavailable or blocked, api/open/pollInstruction provides an HTTP long poll fallback that delivers the same operator instruction objects the socket would otherwise push, keeping the actor's remote control functional even under restrictive network conditions. The session closes with api/open/the_final_interface, the client engine terminal exfiltration call. Once the actor issues a release instruction, the WebSocket connection and background worker are closed, and the entire accumulated cvvform object, every field collected across the full victim session — card data, identity documents, credentials, and fingerprint alike — is sent via HTTP POST to the C2 endpoint. 

The below table represents the endpoints and the purpose.  

Endpoint	Purpose
api/open/addclick	Victim arrival beacon with fingerprinting data sent to C2
api/open/getSyncSettings	Gets actor-controlled settings from the C2
api/open/the_final_interface	POSTs the entire cvvform – exfiltration endpoint
api/open/pollInstruction	Gets the actor’s instructions from the C2
api/open/addCvv	Exfiltration endpoint

The JWR client has purpose-built integrations for two major e-commerce platforms Shopify and WooCommerce. For Shopify deployments, the client reads the cart_data URL parameter which is a signed JSON blob that Shopify passes between checkout steps and extracts the checkout domain to use as the WebSocket base URL. This makes the WebSocket connection seem to originate from a legitimate Shopify domain. The initShopifyProductInfo() and initWordPressProductInfo() functions reconstruct the victim's shopping cart from the Shopify cart data, populating the phishing page with accurate product names, quantities, unit prices, and order totals making the fake checkout indistinguishable from the real one. 

The operator facing status messages of the JWR framework are entirely written in Simplified Chinese and read as a professional admin dashboard notification feed phrases like "正在填写PayPal登录账号" (filling in PayPal login account), "进入2FA验证页, 请发送验证, 等待用户提交" (entering 2FA verification page, please send verification, waiting for user submission), and "均失败" (all failed), indicating that a Chinese-speaking actor is operating this scam campaign. 

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:

Command code	Action taken
0x2268, 0x2267	Execute command using /bin/sh -c
0x2266	Read file
0x2271	Rename file to create a backup
0x2273, 0x2274	Close socket listener
0x3450	Get OS info info -> release, version, machine HW ID, node name
None of the above	Execute code in memory

JARLEASH: 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