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-
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.
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:
Figure 1. conf_sshd control flow logic.
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.
Figure 2. conf_sshd execution logic.
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:
Figure 3. aamgrd daemon launch.
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.
Figure 5. Keying material recording format used by LittleFilch.
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.
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:
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 Ru
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.
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.
Figure 1. Regional targeting.
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.
Figure 2. Lure document masquerading as a Russian diplomatic congratulatory letter to the Armenian 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.
Figure 3. Decoy impersonating Turkmennebit and proposing cooperation with Orsk Oil Refinery management.
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.
Figure 4. Campaign timeline.
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.
Figure 5. First observations of four UAT-6275 infection chains, June 2025 – April 2026.
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.
Figure 6. Chain C retrieves a GitHub-hosted PowerShell script; later samples also deploy PickleShell to the Startup folder.
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.
Figure 7. Chain D exploits CVE-2025-8088 to place PickleShell in the Windows Startup folder for execution at the next sign-in.
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.
Figure 8. Timing of 77 GitHub commits in UTC+3 and UTC+5, with 09:00–18:00 local working hours shaded.
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.
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 f
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.
Figure 1. Impersonated Taiwan European Union Centre event.Figure 2. Impersonated NCCU Institute of International Relations event.Figure 3. Impersonated Taiwan Research Institute event.
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.
Figure 4. Hyperlink phishing destination.
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.
Figure 5. Legitimate poster (left) and modified poster (right).
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.
Figure 6. Form forcibly redirects 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.
Figure 7. Spoofed Google login panels.
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.
Figure 8. Google success page.
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.
Figure 9. Attack chain.
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.
Figure 10. Obfuscation of malicious JavaScript.
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:
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, {...})).
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.
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.
Figure 11. Language and developer assessment.
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.
Figure 12. Outbound data exfiltration with HTTP.
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.
Figure 13. Inbound command and control with WebSocket.
The following diagram illustrates the real-time AitM relay architecture.
Figure 14. UAT-11985 operating diagram.
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.
Figure 15. Mobile device status check.
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.
Figure 16. Authentication challenge function.
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.
Figure 17. google_login_check request.
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 uncovered a cluster of activity we track as UAT-11587 targeting government and policy organizations across Asia, including in Taiwan, India, the Philippines, and Cambodia, to deliver a previously undocumented backdoor referred to as “Antino” in developer artifacts. Talos first observed UAT-11587 activity in September 2025. By July 2026, Talos had identified at least 16 affected or targeted institutional environments across eight Asian countries. Antino is a Rust-compiled Windows back
Cisco Talos uncovered a cluster of activity we track as UAT-11587 targeting government and policy organizations across Asia, including in Taiwan, India, the Philippines, and Cambodia, to deliver a previously undocumented backdoor referred to as “Antino” in developer artifacts.
Talos first observed UAT-11587 activity in September 2025. By July 2026, Talos had identified at least 16 affected or targeted institutional environments across eight Asian countries.
Antino is a Rust-compiled Windows backdoor that supports host reconnaissance, shell and PowerShell execution, file transfer, in-memory shellcode loading and persistence. Its native command-and-control channel operates exclusively through Microsoft 365, using Microsoft Graph to interact with Outlook and OneDrive.
Talos identified a recurring delivery branch that began with spear-phishing emails and tailored decoy documents, followed by a five-stage infection chain. The actor relied heavily on Cloudflare infrastructure for delivery, execution tracking, and payload staging.
Based on the development, preparation-environment, and targeting indicators detailed in this report, Talos assesses with high confidence that UAT-11587 is China-nexus.
Overview
Talos first identified UAT-11587’s campaign while investigating a spear-phishing campaign directed at Taiwan's academic, think tank, and civil society policy community in March 2026. The message recreated Gmail's attachment interface and directed the target into a cloud-hosted, multi-stage infection chain.
Across this activity, our researchers assessed that the actor used several delivery methods, loader families, and post-compromise tools. One recurring final-stage payload was a custom Rust backdoor that Talos tracks as Antino. Antino communicates with Microsoft 365 applications and uses Outlook and OneDrive objects as dead drops, rather than depending on a conspicuous dedicated command server.
Further investigation showed that the activity extended beyond the initial Taiwan operation. Talos subsequently identified confirmed or probable affected government and security environments across multiple Asian countries, alongside additional regional targeting supported by lure content.
While this report was being prepared, Symantec published research on an activity set it tracks as Jewelbug. Talos identified overlaps between UAT-11587 and the Antino-related espionage activity attributed to Jewelbug. Although Symantec reported that Jewelbug conducted both espionage and cryptocurrency fraud, it assessed that “the SEO business supplied access, delivery and infrastructure into the espionage operation, rather than that one person performed both roles.” Talos could not independently verify a connection between the espionage campaign and Jewelbug’s financially motivated activity. We therefore track UAT-11587 as a separate activity set.
Who is UAT-11587?
Talos assesses with high confidence that UAT-11587 is a China-nexus actor, based on the totality of corroborating technical and operational evidence, rather than any single indicator. The indicators discussed below are selected examples of the broader evidence supporting this assessment.
Evidence supporting the attribution assessment
Decoy document metadata provides several preparation-environment clues. A Taiwan-focused decoy contains the zh-CN language tag, the Simplified Chinese author value 未定义 (“undefined”), and an explicit +08:00 creation timestamp. Both recovered spear-phishing messages also contain +08:00 date headers. UTC+8 alone is not geographically distinctive because it is used across mainland China, Taiwan, Hong Kong, Singapore, and other locations. However, the combination of the +08:00 offset, the zh-CN language tag and Simplified Chinese metadata is more consistent with a mainland Chinese environment than with Taiwan or Hong Kong, where Traditional Chinese predominates.
Figure 1. Decoy metadata.
The campaign’s lure theme and targeting provide additional contextual support. Its lures and observed targets include Taiwanese political, legislative, civil defense, and policy research subjects, together with regional government, maritime, diplomatic, and security themes. This collection focus is consistent with China-nexus actor interests.
Another supporting indicator appears in Antino’s development artifacts. Ten distinct Antino build outputs contain Cargo registry paths referencing rsproxy.cn, a Rust package mirror intended to improve dependency downloads within mainland China. The service’s public accessibility does not reveal the developer’s location, but its repeated use suggests reliance on a China-focused Rust mirror.
During our investigation, Talos also identified a JavaScript downloader associated with UAT-11587 that referenced “d32tpl7xt7175h[.]cloudfront[.]net”, the same CloudFront distribution previously reported by Arctic Wolf in China-nexus UNC6384 delivery activity. This shared infrastructure suggests possible delivery-layer overlap. However, because cloud infrastructure can be reused and the campaigns employed different core malware and command-and-control (C2) architectures, Talos assesses this relationship with low confidence and continues to track UAT-11587 as a separate activity cluster.
Victimology
UAT-11587 primarily targeted public-sector and national-security-adjacent organizations across Asia. By July 2026, Talos had identified at least 10 confirmed and five probable affected institutional environments, plus one additional intended target. Our investigation reveals approximately 350 compromised endpoints across eight countries.
The affected or targeted sectors included:
Defense, military, and national security
Executive government and central public administration
Foreign affairs and diplomatic services
Justice, law enforcement, border security, and interior security
Legislative and parliamentary institutions
Government IT and shared e-government services
Think tanks, universities, and research institutions
Civil society, human rights, and public policy organizations
Based on the available evidence, Talos assesses with moderate-to-high confidence that the campaign targeted organizations in Taiwan, India, the Philippines, Cambodia, Pakistan, Thailand, Myanmar, and Syria.
Figure 2. Victimology map
Based on its sustained targeting of government and national security-adjacent organizations, tailored political and diplomatic lures, and capabilities supporting persistent access and information collection, Talos assesses with moderate confidence that UAT-11587 is conducting intelligence gathering operation.
Campaign timeline
Talos observed UAT-11587 activity from September 2025 through July 2026. The earliest reviewed activity, from September through November 2025, used Philippines-themed lures and direct email attachment delivery. In January 2026, the actor conducted two additional Philippines-focused HTML application (HTA) campaigns and began using a broader set of policy and geopolitical lures alongside a standalone fake installer delivery branch. Activity accelerated between March and early June, with closely timed operations involving the Philippines and Taiwan, followed by activity affecting or targeting environments in Cambodia, Myanmar, Syria, Pakistan, and Thailand. The largest concentrated wave occurred on June 8 and 9, when Talos identified around 57 newly observed endpoints associated with India.
Figure 3. Timeline of UAT-11587 campaign activity.
Spear-phishing delivery and sender spoofing
UAT-11587, like many targeted intrusion sets, relies on spear-phishing emails to deliver its infection chain. The social engineering themes used in these emails suggest the threat actor possessed detailed prior knowledge of their target organizations. This targeting precision is particularly apparent in the Taiwan campaigns, where lure content was carefully aligned with the operational and institutional context of each target.
Abusing sender-domain misalignment to spoof trusted senders
To make its spear-phishing emails appear more credible, UAT-11587 spoofed sender identities trusted by the intended recipients. The actor exploited the distinction between the SMTP envelope sender and the visible From header. Messages were sent through Migadu using the attacker-controlled “osc-cdn[.]com” domain as the RFC5321 envelope sender, while the RFC5322 From header displayed the identity of the organization being impersonated.
SPF passed because Migadu’s sending infrastructure was authorized to send email on behalf of “osc-cdn[.]com”. However, this result authenticated only the envelope-sender domain, not the sender displayed to the recipient. DMARC detected that the envelope and visible sender domains were not aligned and returned a failure. In the reviewed message, the displayed domain used a non-enforcing p=none policy, which requested monitoring rather than quarantine or rejection. The receiving provider therefore accepted the message, allowing the spoofed email to be successfully delivered to the recipient’s inbox despite the DMARC failure.
Figure 4. The spoofed email passed SPF.
Gmail attachment widget cloning
Another social engineering technique used for initial access in this campaign was the closely replicated reconstruction of Gmail’s native attachment preview widget inside the email HTML body. The actor replicated the styling of Gmail’s attachment card using four inline PNG images embedded as Base64-encoded MIME parts. The entire attachment card was wrapped in an anchor tag pointing to an attacker-controlled URL. These links use Cloudflare Pages URLs with the pattern shown below. The ?m= parameter carries a target identifier and therefore permits per-recipient logging at the delivery service //my-<project>.pages.dev/File_download?m=<target-identifier>. The actor used a protocol-relative URL beginning with //, which may be overlooked by security tools that extract only fully qualified HTTP or HTTPS URLs.
When a Gmail user opens the email in a browser, Gmail’s renderer faithfully displays the attacker-controlled HTML, producing a fake attachment widget that is visually indistinguishable from a legitimate Gmail attachment preview.
Figure 5. Spear-phishing email sample.Figure 6. HTML code in the email with link to download malware.
Tailored lures and decoy documents
Our analysis recovered three decoy documents during separate UAT-11587 operations. The first decoy described a workshop focused on the “Taiwan Information Warfare.” The document referenced a 2025 TikTok study and discussed perceived public knowledge gaps concerning cross-strait issues and information manipulation.
Figure 7. Decoy document recovered from Taiwan-targeting campaign.
The second decoy, titled “立法委員行使職務支領之各項費用徵免稅原則” (“Principles governing the taxation of expenses received by legislators in performing their duties”), used a narrower administrative pretext. It describes the income tax treatment of legislators’ remuneration, overseas travel, and expenses incurred while performing legislative duties. The document exactly reproduces a public Taiwan Ministry of Finance ruling to make the decoy appear credible. Its subject strongly suggests that it was prepared for members of Taiwan's public sector.
Figure 8. Taiwan-focused decoy document.
Outside Taiwan, Talos recovered a two-page decoy titled “CSIS Indo-Pacific Forecast 2026 (Event Details).” The document borrowed the framing of a legitimate event and referenced real experts, presenting an agenda focused on regional alliances, gray-zone security, demographic trends, and human security. The subject matter would plausibly appeal to government, diplomatic, think tank, academic, and security policy audiences across the Indo-Pacific, including readers focused on India.
Beyond the recovered decoys, file names of malicious executables, HTA files, and WSF stagers revealed additional themes spanning maritime policy, foreign affairs, diplomatic events, human rights, government administration, and technology research.
One lure shows how the actor exploited current geopolitical developments. “Trump’s Former Russia Adviser Claims Moscow Offered US Free Rein in Venezuela in Exchange for Ukraine” closely paraphrased an Associated Press report, with two related samples appearing on VirusTotal two days later.
Together, these examples show the actor using both news-style headlines and official-sounding documents to target audiences interested in foreign affairs, international security, and government policy.
The table below lists the likely audience for each lure. Where recipient details or decoy content were unavailable, assessments are based solely on file names and subject matter and do not confirm delivery or compromise.
Lure or decoy title
Potential target or audience
115年度薪資所得扣繳稅額表說明 (Instructions for the 2026 Salary Income Tax Withholding Table)
Taiwanese think tank
Resolution on the Updated Chart of Bajo de Masinloc
Likely Philippine public sector
Trump's Former Russia Adviser Claims Moscow Offered US Free Rein in Venezuela in Exchange for Ukraine
Foreign-policy, government, research, or media audiences interested in the topic.
CrossBorder_Repression_Seminar_Agenda
Likely human-rights, civil-society, diaspora, academic, or policy communities.
the May 27 inauguration of the TPiE
Regional political and civil-society audiences
Tehran_Bilateral_Summit_Proceedings_May2026
Likely diplomatic, foreign-affairs, or policy audiences following a Tehran-based bilateral meeting.
Items likely to be considered in the next Cabinet meeting.T11065885611.doc.exe
Indian government audiences
UO -C-DAC (1)
Indian government technology and research audiences
The infection chain
In the reviewed spear-phishing operations, the actor uses a five-stage infection chain that begins with an HTA stager. Later stages abuse unsafe BinaryFormatter deserialization and gadget chains in standard .NET assemblies to load and execute the final payload.
Figure 10. Antino backdoor infection chain.
Stage 1: HTA and WSF Stager
The “my-<project>.page[.]dev” Cloudflare URL in the spear-phishing emails leads to the download of an HTA file that was executed by mshta.exe. It hides and resizes its window, emits a tracking request to an invariant Cloudflare Pages beacon, and imports the next JavaScript stage from a cloud-hosted location. The same general template appears across multiple campaign variants:
Figure 11. HTA stager.
The actor uses two cloud services to deliver the second-stage JavaScript:
The fixed Cloudflare Pages hostname “oisadjfoinsiduhfnoisdnfosdnoifnsoid[.]pages[.]dev” appears across multiple reviewed HTA variants. A hidden image causes mshta.exe to send a request containing the lure title in the URL path and ?track in the query string. This could allow the operator to correlate HTA execution with a particular lure for campaign tracking.
Talos also observed WSF stagers that perform the same role through Windows Script Host. They send an HTTP HEAD request to the tracking host name with the lure title in the URL path, then load the next JavaScript stage from Cloudflare R2. Although paired HTA and WSF samples use different R2 objects and obfuscated loaders, both lead to the same infection chain.
Figure 12. WSF stager script.
Stage 2: HTA-hosted JScript downloader and decryptor
The Stage 2 component is HTA-hosted Microsoft JScript, delivered from Cloudflare R2 and loaded in-process by mshta.exe through the HTA stager. It acts as a downloader and decryptor that prepares the next stage in-memory .NET deserialization chain. The script retrieves three encrypted resources from the cloud-hosted delivery infrastructure:
After downloading the files, the script applies custom Base64 decoding and decrypts each response with RC4 using an embedded key. It then executes the decrypted JScript orchestrator in memory to initiate the .NET 4.x deserialization chain.
Figure 13. HTA-hosted JScript downloader and decryptor.
The three files downloaded from Cloudflare R2 or Amazon CloudFront are the JScript orchestrator and two serialized .NET gadget resources. The threat actor leverages a scripted .NET deserialization technique in which JScript instantiates COM-visible .NET classes and passes attacker-controlled serialized data into BinaryFormatter. During deserialization, the embedded gadget chain drives execution, allowing the malware to load and execute an embedded .NET assembly, the next-stage “TestAssembly.dll”, inside the script host process, mshta.exe.
Figure 14. JScript orchestrator.
The JScript orchestrator deserializes the two resources in sequence. It first attempts to deserialize stage_1, which appears designed to disable a .NET security check introduced to block ActivitySurrogateSelector-based deserialization gadget chains. The code wraps this operation in a try/catch block and proceeds to stage_2 when an exception occurs, suggesting the actor anticipated differences in .NET versions, patch levels, or assembly availability across target systems. The two-call behavior observed in stage_1 appears intended to improve compatibility across different .NET patch levels.
The second serialized resource, stage_2, uses the System.Windows.Forms.AxHost+State deserialization gadget in combination with an ActivitySurrogateSelector gadget chain. This technique substitutes a surrogate object during deserialization to drive code execution. In this case, the gadget chain loads the embedded PE file, “TestAssembly.dll”, directly into memory and executes it inside mshta.exe.
Stage 4: “TestAssembly.dll” downloader and launcher
“TestAssembly.dll” is a small .NET downloader and launcher that Stage 3 loads directly into mshta.exe through the BinaryFormatter deserialization chain. It downloads a lure-specific decoy document and a three-file DLL-sideloading bundle from cloud-hosted infrastructure. It opens the decoy, writes the bundle to a writable staging directory, and launches the Microsoft-signed “GatherOsState.exe”, which sideloads “slc.dll”, the Antino backdoor.
The table below shows the files retrieved during one Taiwan-targeting campaign. Note that the actor uses randomized nonstandard extensions (.luy, .pzs, .syk) that remove obvious executable/DLL filename signaling.
All the “TestAssembly.dll” downloader builds recovered in this investigation share the AssemblyAttribute GUID b2b3adb0-1669-4b94-86cb-6dd682ddbea3. This is a useful tooling-level detection marker.
Figure 15. .NET assembly metadata for the TestAssembly component.
The downloaded “GatherOsState.exe” is a legitimate Microsoft-signed Windows Assessment and Deployment Kit (ADK) binary that was abused for DLL sideloading. When executed, it loads “slc.dll” from its local directory. The attacker placed the Antino backdoor file slc.dll alongside the signed executable, which then calls the DLL’s SLOpen export to start Antino.
C2 infrastructure
Beyond email delivery, UAT-11587 relied extensively on Cloudflare throughout the infection chain. Cloudflare Pages hosted malicious HTA and WSF files and a separate execution-tracking endpoint, while Cloudflare R2 stored encoded loader stages, decoy documents, and payload components. UAT-11587 also used Amazon CloudFront to deliver additional scripts and decoy content. This architecture placed much of the infection chain within widely used cloud services and ordinary HTTPS traffic.
We also identified software-themed domains that directly hosted standalone Antino executables. The domain “microsoft-flash[.]com”, registered shortly before its use, served Antino samples from “https://microsoft-flash[.]com/download/flashcenter_pp_ax_install_en.exe”. Similarly, “wps-cn[.]com” delivered a related Antino build from “https://www.wps-cn[.]com/downloads/flashcenter_pp_ax_install_en.exe”. The choice of “wps-cn[.]com” may also indicate that the delivery site was designed to appeal to Chinese-speaking users, particularly those in mainland China.
While the infection chain relied heavily on Cloudflare, Antino itself used Microsoft 365 for post-compromise C2. The “Dead-drop C2 communication” section explains this channel in more detail.
The Antino backdoor
Antino is a , Rust-compiled Windows backdoor observed in both 32-bit and 64-bit builds. Talos named the malware after identifying AntinoApp in its Windows application manifest and repeated antino directory names in PDB and Rust source paths across multiple variants. It supports host reconnaissance, command execution, persistence, and Microsoft Graph-based C2, using Outlook for command exchange and OneDrive for heartbeat and file transfer.
Figure 16. The Windows application manifest identifies the program as AntinoApp.
The “D:\a\antino\antino\...” paths follow the standard GitHub Actions Windows workspace structure, “D:\a\<repository>\<repository>\...”. This suggests that the reviewed CI variants were compiled on GitHub-hosted Windows runners.
The backdoor was observed in both standalone executable and DLL forms. Our analysis observed two generations of Antino, distinguished by consistent differences in their underlying code and Rust build environment. The clearest implementation differences involve session-ID generation and registration and heartbeat behavior.
Characteristic
Antino Gen1
Antino Gen2
Observed build period
October 2025
December 2025 to January 2026
Application identity
No AntinoApp manifest in the reviewed builds
Uses the AntinoApp application manifest
Session identifier
XOR- and Base64-encodes the process ID, computer name, username and platform.
Generates a random UUID v4 containing no host-derived information
Registration and heartbeat
Classic builds use sendsession and heartbeat email drafts; an early DLL already supports OneDrive heartbeats
Stores JSON heartbeat objects under “/antino/heartbeats/<session_id>.json”; the heartbeat also registers the implant
Dead-drop C2 communication
Antino communicates exclusively through Microsoft 365, using the Microsoft Graph API to interact with Outlook and OneDrive as dead-drop C2 channels. Both Antino generations use broadly similar Microsoft 365-based C2 workflows. This design allows Antino’s C2 traffic to blend into legitimate Microsoft application synchronization at the network layer. Outbound connections terminate at “graph.microsoft.com” and “login.microsoftonline.com”, both of which are widely trusted and commonly allowed in enterprise environments.
The Antino Gen2 implant authenticates to Microsoft Graph using the OAuth 2.0 client-credentials flow. This authentication method allows the registered Entra ID application to access the configured Outlook mailbox and OneDrive resources without requiring an interactive user sign-in.
The Antino implant uses two distinct mechanisms for C2 communication, implemented in separate modules:
Mechanism 1: OneDrive file-based communication
The Antino backdoor uses the threat actor’s OneDrive for registration and file-based communication. The OneDrive folder used for communication includes three folder paths:
Path
Direction
Purpose
/antino/heartbeats/{id}.json
Antino upload
Beacon / check-in; carries system state
/antino_downloads/{file}
Antino upload
Exfiltrated data from victims (files the operator downloads from victims)
/antino_uploads/{file}
Threat actor upload
Toolkit delivery staging (files the operator uploads to victims)
Antino uses the heartbeats folder to upload JSON-formatted heartbeat files containing host telemetry, including the session ID, timestamp, online/offline status, machine name, username, platform, and a campaign code defined in the backdoor configuration. Each implant session is assigned a randomly generated UUID, which is used as the heartbeat filename “{session_id}.json”. The implant uploads the heartbeat file to OneDrive during initial execution and resends every minute.
Figure 17. Example heartbeat JSON.
The directory naming is from the threat actor’s perspective. “antino_uploads/” holds tools the operator pushes to victims, while “antino_downloads/” holds data the operator pulls from victims. The file-based polling model is characteristic of dead-drop C2 designs used to decouple operator activity from implant activity on the network.
Mechanism 2: Outlook commands communication
The Antino backdoor receives commands through email messages. The implant actively pulls commands from the threat actor’s Outlook mailbox folder every 10 seconds. The protocol uses two message types: command emails contain tasking from the controller, while response emails contain the implant’s results.
Command messages are identified by the subject prefix command_req_[session_id] and responses by command_res_[session_id], as indicated in the HTTP GET request sent by Antino:
Figure 18. Request from Antino to Outlook to get commands from emails.
The body of each command message contains a JSON object with the information required for execution. It has three fields: command_type, the command to invoke; command_data, an object containing command-specific parameters; and request_id, a per-command identifier used to correlate the request with the corresponding response (the request_id is distinct from the implant session_id used in the message subject and heartbeat). For example, a cmd request has this body:
Figure 19. The JSON sent in command request message.
The response follows a similar structure. Its body contains a JSON object describing the outcome of command execution. The command_type field identifies the command that was executed, while request_id links the response to the corresponding request. The success field indicates whether the command succeeded, result contains the returned output, and error provides failure details or is null when execution succeeds. For example, a successful cmd response has the following body:
Figure 20. The JSON sent in command response message.
Antino-supported commands
Antino is a comprehensive backdoor that supports several commands for host reconnaissance and execution. Across the reviewed Antino builds, Talos identified the following command handlers. Command availability varies by generation and build.
Command/handler
Capability
cmd
Runs cmd.exe /C and captures output
powershell
Runs powershell.exe -Command
system_info
Collects host and process context
execute_program
Executes an operator-supplied program
list_files
Enumerates a directory
upload_file
Transfers files from the threat actor’s OneDrive to the compromised host
download_file
Exfiltrates files from the compromised host to the threat actor’s OneDrive
load_shellcode
Runs operator-supplied shellcode in memory
add_to_run
Establishes Antino persistence by adding a Registry Run value
exit
Stops the Antino runtime
Antino-supported commands. Command availability varies slightly by generation and build.
The cmd and powershell commands allow the operator to execute commands directly through the Windows command shell or PowerShell and collect their output.
Filesystem operations are handled through list_files, upload_file, and download_file. Similar to the C2 communication protocol, these names are written from the operator’s perspective: upload_file transfers files from the threat actor’s OneDrive to the compromised endpoint, while download_file reads a file from the endpoint and uploads it to OneDrive for operator retrieval.
Antino provides two options for running actor-supplied code: load_shellcode and execute_program. The load_shellcode command sends a Base64-encoded payload in the command-request email body in the following JSON format:
Figure 21. The load_shellcode command structure.
Masking the loaded payload
The use_sleep_mask parameter enables a defense evasion technique intended to reduce the secondary payload’s exposure to memory scanners. When enabled, Antino hooks Sleep and VirtualAlloc and registers a vectored exception handler (VEH). The VirtualAlloc hook records the tracked memory region. When the tracked payload thread calls Sleep, the Sleep hook changes that region to non-executable (PAGE_READWRITE), encrypts its contents in place, and then calls the real Sleep function.
After Sleep returns, an attempt to execute code from the encrypted, non-executable region triggers an access violation. The VEH confirms that the fault occurred within the tracked region, restores its previous memory protection, decrypts the content, and resumes execution. This technique is intended to reduce the time during which memory scanners can observe recognizable executable payload bytes. Although this technique does not mask the entire Antino process or guarantee evasion, it adds another layer of defense evasion by reducing the window in which memory scanners can identify the loaded payload.
Abuse of the Windows Scripted Diagnostics framework workflow
The Antino backdoor abuses the Windows Scripted Diagnostics framework to execute attacker-controlled PowerShell through legitimate Windows components. Both the execute_program and add_to_run commands use this technique.
Program Compatibility Wizard (PCW) troubleshooting package (“C:\Windows\diagnostics\system\PCW”)
Scripted Diagnostics Native Host process (“sdiagnhost.exe”)
Windows normally uses “sdiageng.dll” to load troubleshooting packages such as PCW, while “sdiagnhost.exe” executes their PowerShell scripts in a separate process.
Antino initializes COM and creates an instance of CLSID {1F3D8AA5-9EBF-4EE4-85C2-EA40379AEDE8}, the CScriptedDiag class implemented by “sdiageng.dll”. It then initializes the engine with the legitimate PCW package and a blank diagnostic Answers XML document. The engine creates a temporary working copy of the package and returns its directory, such as “C:\Windows\Temp\SDIAG_<GUID>”.
Antino writes an attacker-controlled PowerShell script into this directory. For example, the add_to_run command generates a script that creates an HKCU Run key value:
Figure 22. PowerShell script generated by Antino’s add_to_run command.
Antino then resumes the diagnostic workflow. The Scripted Diagnostics engine delegates execution to the native host, observed in runtime traces as %windir%\SysWOW64\sdiagnhost.exe -Embedding. The host subsequently executes result.ps1. The resulting Run key entry launches the selected Antino executable the next time the affected user signs in.
The technique allows Antino to proxy PowerShell execution and the persistence-related registry modification through a Microsoft-signed diagnostic workflow. This can complicate behavioral attribution to the original implant, although it does not eliminate observable PowerShell, file-creation or registry telemetry.
Figure 23. Antino calls CoCreateInstance to activate the Windows diagnostic COM class.
Antino configuration
Antino stores the configuration data in a custom PE section named .cfg. The on-disk structure begins with a four-byte little-endian JSON length followed by bytes XORed with the alternating key 0xAB 0xCD.
In addition to its C2 configuration, Antino’s embedded configuration contains two deployment settings, run and launch_mode. The run field controls whether Antino automatically installs a persistent copy when it starts. When set to true, Antino launches its installation task, stages the required files under %LOCALAPPDATA%\Windows GatherOSStateKit\, and creates an HKCU Run value. launch_mode is evaluated only when run is set to true. It defines which files constitute the persistent payload: exe or raw for standalone PE or dll for sideloading.
Coverage
The following ClamAV signatures detect and blocks this threat:
Html.Trojan.UAT-11587-10060367-2
Txt.Trojan.UAT-11587-10060385-5
Txt.Trojan.UAT-11587-10060386-1
Win.Trojan.UAT-11587-10060365-1
Win.Trojan.UAT-11587-10060366-1
Win.Trojan.UAT-11587-10060369-1
Win.Trojan.UAT-11587-10060370-1
Win.Trojan.UAT-11587-10060371-1
Win.Trojan.UAT-11587-10060372-1
Win.Trojan.UAT-11587-10060373-1
Win.Trojan.UAT-11587-10060374-1
Win.Trojan.UAT-11587-10060375-1
Win.Trojan.UAT-11587-10060376-1
Win.Trojan.UAT-11587-10060377-1
Win.Trojan.UAT-11587-10060378-1
Win.Trojan.UAT-11587-10060379-1
Win.Trojan.UAT-11587-10060380-1
Win.Trojan.UAT-11587-10060381-1
Win.Trojan.UAT-11587-10060382-1
Win.Trojan.UAT-11587-10060383-1
Win.Trojan.UAT-11587-10060384-1
The following Snort rules cover this threat:
Snort 2: 1:66880, 1:66881, 1:66882
Snort 3: 1:66880, 1:66881, 1:66882
Indicators of compromise (IOCs)
IOCs for this research can also be found 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 f
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:
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.
Figure 1. LONGLEASH’s functional components.
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:
Downloads DOGLEASH.
Adds iptables rules to allow TCP traffic to a specific port, on which DOGLEASH binds and listens.
Executes DOGLEASH on the device.
Figure 2. Startup script for SHORTLEASH.
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.
Figure 3. Startup script for 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
Figure 4. JARLEASH core components.
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: