Antino Backdoor Targets Asian Government Organizations

Cisco Talos has documented a targeted intrusion set it tracks as UAT-11587, which used a previously undocumented Windows backdoor called Antino against government, policy, research and security-related organizations across Asia. The activity combined tailored spear-phishing with a multi-stage delivery chain that relied heavily on Cloudflare and Amazon infrastructure, then shifted to Microsoft 365 services for command and control.

Talos first observed the activity in September 2025 and identified operations continuing through July 2026. By that point, the researchers had identified at least 10 confirmed and five probable affected institutional environments, as well as one additional intended target. Their investigation found approximately 350 compromised endpoints across eight countries. Talos assessed with moderate-to-high confidence that the campaign targeted organizations in Taiwan, India, the Philippines, Cambodia, Pakistan, Thailand, Myanmar and Syria.

The research organization assesses with high confidence that UAT-11587 is China-nexus. That judgment is based on multiple technical and operational indicators rather than a single artifact. Talos also assesses with moderate confidence that the campaign supported intelligence gathering. Those are researcher assessments, not independently established facts about the operator’s identity or the ultimate use of collected information.

Targeting favored public-sector and policy environments

The campaign focused on institutions with access to political, diplomatic, security and regional policy information. Talos identified targeting involving defense and national security, central government, foreign affairs, justice and border security, legislative bodies, shared government IT services, universities, think tanks, civil-society groups and policy organizations.

The lures were adapted to the intended audience. Recovered documents included material about Taiwan information warfare, taxation rules affecting legislators and a purported Indo-Pacific policy event. Other filenames and themes referred to maritime policy, diplomatic events, human rights, cabinet business, foreign affairs and technology research. Talos cautions that some audience assessments were based only on filenames or subject matter; those details do not by themselves prove that a particular recipient opened a file or was compromised.

In Taiwan-focused operations, the messages were designed to resemble familiar Gmail attachment previews. The email body recreated the visual appearance of Gmail’s attachment card using embedded images, while the apparent attachment linked to an attacker-controlled Cloudflare Pages address. The URL included a recipient-specific parameter that could support delivery tracking. Talos also observed protocol-relative links beginning with //, a format that may be missed by tools looking only for fully qualified HTTP or HTTPS URLs.

The actor also abused the difference between an SMTP envelope sender and the visible From header. In the messages reviewed by Talos, mail was sent through Migadu using osc-cdn[.]com as the envelope-sender domain, while the visible sender impersonated a trusted organization. SPF passed for the envelope domain, but DMARC detected that the envelope and visible domains were not aligned. Because the displayed domain used a non-enforcing p=none policy, the message was accepted rather than quarantined or rejected.

Five stages separated delivery from the final backdoor

In the recurring delivery branch, a victim followed the link in the spoofed email and received an HTA file. The initial HTA executed through mshta.exe, resized or hid its window, sent a tracking request and loaded a second-stage JavaScript component. Talos also found WSF stagers performing a similar role through Windows Script Host.

The next stage was hosted through Cloudflare R2 or Amazon CloudFront. It retrieved three encrypted resources: a JavaScript orchestrator and two serialized .NET resources. The downloader used custom Base64 processing and RC4 with an embedded key, then ran the decrypted orchestrator in memory.

The third stage abused unsafe .NET BinaryFormatter deserialization and gadget chains in standard .NET assemblies. The orchestrator attempted one serialized resource and then proceeded to another when an exception occurred, behavior Talos interpreted as an effort to accommodate differences in .NET versions, patch levels or assembly availability. The second resource used a deserialization chain to load an embedded PE file named TestAssembly.dll directly into the mshta.exe process.

TestAssembly.dll acted as a downloader and launcher. It retrieved a decoy document and a bundle of files, opened the decoy and placed the bundle in a writable staging directory. It then launched GatherOsState.exe, a legitimate Microsoft-signed Windows Assessment and Deployment Kit binary. That executable loaded a neighboring slc.dll, which contained Antino. The use of randomized extensions for the downloaded files reduced obvious executable or DLL indicators, while the signed executable provided a trusted host for the sideloaded component.

Talos found a repeated assembly GUID, b2b3adb0-1669-4b94-86cb-6dd682ddbea3, across the reviewed TestAssembly.dll downloader builds. This is a useful tooling-level detection marker, although it should be treated as one signal rather than a sole basis for blocking.

Antino combines reconnaissance, execution and file transfer

Antino is a Rust-compiled Windows backdoor observed in both 32-bit and 64-bit forms, including standalone executable and DLL variants. Talos named it after finding AntinoApp in the application manifest and repeated Antino-related directory names in PDB and Rust source paths.

Across the analyzed builds, the malware could collect system and process information, enumerate files, execute commands through cmd.exe and PowerShell, run an operator-supplied program, transfer files and load supplied shellcode in memory. Some builds included a command to add a Windows Registry Run value for persistence. Command availability varied between generations and individual builds.

The backdoor included a sleep-mask option for loaded payloads. Talos describes this as a defense-evasion feature intended to reduce the exposure of a secondary payload to memory scanners. The supplied research does not establish how effective that feature was against particular security products.

Talos distinguished two Antino generations. Earlier builds used host-derived data in session identifiers, while later builds generated random UUID version 4 identifiers. Later variants also used an application manifest naming AntinoApp and stored heartbeat objects in OneDrive. These differences can help analysts correlate samples, but they also show that detections based on a single build characteristic may have limited durability.

Microsoft 365 served as the command channel

Antino’s most notable feature is its reliance on Microsoft Graph rather than a conventional dedicated command server. The malware authenticated to Microsoft Graph using OAuth 2.0 client credentials and interacted with Outlook and OneDrive. Network connections terminated at graph.microsoft.com and login.microsoftonline.com, services that are normally trusted and widely accessible in enterprise environments.

OneDrive provided registration, heartbeat and file-transfer functions. The backdoor uploaded JSON heartbeat files containing information such as the session identifier, timestamp, online status, machine name, username, platform and campaign code. Talos observed later builds sending heartbeats at one-minute intervals. OneDrive folders also separated data pulled from victims from tools staged for delivery to them.

Outlook supplied tasking. The implant polled the operator’s mailbox every 10 seconds for messages whose subjects used a session-specific command prefix. Command bodies contained JSON fields for the command type, command data and request identifier. Results were returned through corresponding response messages. This dead-drop design can blend malicious activity with ordinary Microsoft 365 traffic and complicate investigations that depend only on destination reputation or broad HTTPS inspection.

What organizations should do now

• Review email authentication enforcement. Move beyond monitoring-only DMARC policies where operationally appropriate, and verify alignment between visible From domains and authenticated sending domains. Train users to treat unexpected attachment previews and cloud-hosted download links cautiously.
• Monitor script-host execution. Investigate unusual instances of mshta.exe, Windows Script Host, JScript and PowerShell launched from email, browser or user-writable locations. Pay particular attention to script hosts making network requests before spawning or loading .NET content.
• Hunt for the execution chain. Look for the sequence of HTA or WSF activity, cloud-hosted encrypted resources, in-memory .NET loading, GatherOsState.exe and a neighboring slc.dll. The repeated TestAssembly.dll GUID can support triage.
• Inspect signed-binary sideloading. Alert when the Windows ADK binary GatherOsState.exe executes from an unusual directory or loads a DLL from a location outside an approved software installation.
• Examine Microsoft 365 application activity. Review newly registered or unusual Entra ID applications, client-credential authentication, unexpected Graph access to Outlook or OneDrive, and mailbox or storage activity inconsistent with the service account’s role. Correlate this activity with endpoint telemetry rather than blocking Microsoft domains wholesale.
• Use layered endpoint controls. Restrict script interpreters where feasible, apply application-control policies to prevent unapproved binaries from user-writable directories, and collect process, module-load, registry and memory telemetry. These measures are general defensive recommendations, not controls specifically validated by Talos against every campaign variant.
• Compare telemetry with the supplied indicators. Talos reported delivery infrastructure including microsoft-flash[.]com, wps-cn[.]com, several Cloudflare Pages and R2 hosts, and the historical IP 103[.]27[.]110[.]220. Because cloud infrastructure can be shared or repurposed, indicators should be investigated in context and not treated as conclusive proof of compromise.

Attribution and remaining uncertainty

Talos’s high-confidence China-nexus assessment draws on the combination of Simplified Chinese metadata, a UTC+8 preparation environment, targeting patterns, use of the China-focused Rust mirror rsproxy[.]cn in build artifacts and other technical evidence. Talos identified a possible delivery-layer overlap with activity previously reported by Arctic Wolf, but assigned that relationship low confidence and continues to track UAT-11587 separately.

Talos also noted similarities between Antino-related espionage activity and activity that Symantec tracks as Jewelbug. The researchers could not independently verify a connection between that espionage activity and Jewelbug’s financially motivated operations. No specific individual or organization is identified as the operator in the supplied research.

Conclusion

UAT-11587 illustrates how a targeted campaign can combine familiar social engineering with a technically layered Windows infection chain and cloud services that are difficult to distinguish from legitimate traffic. Antino’s use of Microsoft Graph, Outlook and OneDrive is especially relevant for defenders because network allowlists alone may not reveal the intrusion. Effective monitoring should connect email authentication, script-host execution, DLL sideloading, .NET activity, endpoint persistence and unusual Microsoft 365 application behavior.

Sources

Technical findings and attribution assessments in this analysis are from Cisco Talos: “China-nexus UAT-11587 targets government and policy organizations across Asia with Antino backdoor.”