
Reputation Radar #14: Dead Drops on Trusted Ground
A China-nexus backdoor called Antino runs its entire command channel through Outlook and OneDrive, and every other stage of the attack sits on Cloudflare or AWS. No step of it touches an address you would think to block. Here is what a reputation check sees at each hop, and where it has to hand over to you.
Last week's attackers took over a box that already had your reputation. This week's didn't need to take anything over. They just made sure that every single hop of their attack landed somewhere you already trust.
The phishing page sat on Cloudflare. The payloads sat on Cloudflare and AWS. And the command channel, the part we usually hunt for, ran through Microsoft Outlook and OneDrive. Go looking for a suspicious server in that chain and you won't find one, because there isn't one.
Meet Antino
Cisco Talos published a deep dive on a China-nexus group it tracks as UAT-11587, which has been going after government and policy organizations across Asia since September 2025: Taiwan, India, the Philippines, Cambodia, Pakistan, Thailand, Myanmar and Syria. Sixteen organizations in eight countries, with the busiest stretch between March and early June this year.
Their implant is a Rust backdoor Talos calls Antino, and the detail that matters is how it talks home. In Talos's words, "Antino communicates exclusively through Microsoft 365, using the Microsoft Graph API to interact with Outlook and OneDrive as dead-drop C2 channels."
Here's how that works in practice. The operators register their own app in their own Microsoft tenant. The implant signs in to it with the app's credentials, no user involved, and then checks the attackers' mailbox every ten seconds for an email whose subject starts with command_req_ plus the victim's session ID. It runs the command and writes the answer back as another email, command_res_. Once a minute it drops a little heartbeat file into the attackers' OneDrive, and that same OneDrive is where tools come in and stolen files go out.
So from your network, the "C2 traffic" is a workstation talking to graph.microsoft.com and login.microsoftonline.com. That's the same thing every copy of Outlook in your building does all day.
Every other hop was borrowed too
The C2 gets the headlines, but the delivery chain is just as tidy, and it's the part a reputation check actually gets to see.
The lures were spear-phishing emails dressed as policy-world material: workshop invitations, summit proceedings, disciplinary reports. They used a fake Gmail attachment preview card built out of inline images, so the "attachment" was really a link. One small trick we liked, in the way you like a pickpocket's technique: the links were written as //my-xxxx.pages.dev/... with no https:, which can slip past tools that only extract full URLs.
From there it's a relay race across trusted platforms:
- Cloudflare Pages (
*.pages.dev) served the first HTA or WSF file. - Cloudflare R2 buckets (
*.r2.dev) and an Amazon CloudFront distribution (d2nq35tel3ucuo.cloudfront.net) served the next stages. - The final step dropped a genuine Microsoft-signed binary,
GatherOsState.exe, next to a maliciousslc.dll, so a legitimate program loads the backdoor for them.
The sender side was borrowed as well. The emails went out through a mail provider that properly authorized the attackers' own domain, while the visible From line showed the organization they were impersonating. SPF passed on the hidden envelope domain. DMARC failed, but the spoofed organizations had DMARC set to p=none, so the mail was delivered anyway.
What the reputation column shows
We ran the indicators from Talos's report through our own API, hop by hop. They split into three groups, and the split is the useful part.
The C2 endpoints come back clean, and they should. graph.microsoft.com and login.microsoftonline.com return likely_benign, recognized as Microsoft's own productivity infrastructure. That's correct: those domains really are Microsoft's, and flagging them would bury every SOC in noise. What our API also keeps attached is the reason that matters here: both sit on the LOTS list, described as "legitimate sites frequently abused by attackers for C2, phishing, data exfiltration." The domain is trustworthy. Whose mailbox is on the other end of the request is a question no domain lookup can answer.
The staging hosts come back as rentable platforms. The Cloudflare Pages site and the R2 bucket both land on investigate. So does the CloudFront distribution, with the note that matters most: the cloudfront.net name tells you nothing about the AWS customer who owns that particular distribution, so the hostname itself is the thing to check.
A confession while we're here. When we first ran that CloudFront host, our API labelled it "Imperva (Incapsula)", along with a hint about finding the real site behind an Imperva proxy. The verdict was right, but the label was wrong and the hint pointed the analyst at the wrong question. A category-matching rule was letting the Imperva profile claim any CDN that also carried a security tag. We fixed it this week, so CloudFront distributions now read as Amazon CloudFront, with a hint that treats each distribution as its own indicator. Running real attack chains through the product is exactly how these things surface.
The attacker's own domains come back with nothing on them. osc-cdn.com, the sending domain, has no feed history at all, and neither does the Hong Kong IP Talos tied to the fake-installer site. Two of the fake-installer domains, microsoft-flash.com and wps-cn.com, even carry a popularity ranking in the Tranco top 500K, which our API reports alongside its standing caveat: "Popularity alone isn't trust."
Put the three groups side by side and you get the shape of this whole campaign. The infrastructure you'd normally block was either fresh with no history yet, or a shared platform you can't block wholesale. And the one hop that ran for weeks, the C2, ran on a domain that is legitimately trusted.
That's where the work moves from the domain to the behaviour. A Microsoft-signed GatherOsState.exe running from a user folder. A workstation calling Graph every ten seconds around the clock. An Entra app you didn't register showing up in sign-in logs. Talos also recommends enforcing DMARC at p=reject, which would have stopped the spoofing in the first place. None of those depend on a bad name showing up anywhere.
Also on the radar
- A third NetScaler zero-day. A week after the pair we covered in Radar #13, Citrix shipped emergency fixes on October 4th for CVE-2026-88779, a memory overflow in NetScaler's SAML handling that is being exploited in the wild (BleepingComputer). It's rated as denial of service, but admins report shell commands stuffed into login usernames, so treat it as worse. If you patched last week, patch again.
- Cisco SD-WAN Manager, auth bypass. CVE-2026-76504 (CVSS 9.8) lets an unauthenticated attacker reach admin-level API access with a crafted, oddly encoded request. It was exploited from September and went into CISA's KEV on the 30th (Rapid7). The box that pushes config to every branch is another prize like the gateway.
- TA419 impersonates its way into AI policy. Proofpoint tracked a China-aligned crew posing as a former White House science official, an economist, and an Anthropic employee to approach US AI-policy experts, then stealing Microsoft 365 sessions through fake OneDrive pages (Proofpoint). Same week, same trusted brand, a different way of borrowing it.
- KillSec taken down. European police dismantled the KillSec ransomware-as-a-service operation and made three arrests across Spain, Romania and the UK. The main administrator was a 16-year-old in Spain. Affiliates paid a $250 entry fee to join a service that claimed over a thousand attacks (Risky Bulletin).
If you want the longer read on why a trusted cloud, CDN or SaaS platform in the reputation column is where the question starts rather than where it ends, we walked through it in Borrowed reputation: when attackers hide behind trusted infrastructure.
See you next week.
Sources are linked inline, with credit to Cisco Talos for the Antino research and to the original researchers and reporters. If we got a detail wrong, tell us and we'll fix it.
About Reputation Radar: This is written by the small team building Reput.io, not a marketing department. It's our weekly read on the infosec landscape, with a bias toward the thing we care most about: how attackers borrow the reputation of legitimate infrastructure so their traffic looks normal. Every item links the original reporting, and any claim about our own API is run against it live and labelled.
Ready to Try Reput.io?
Start reducing false positives today with our free plan.