Antino phishing spoofs trusted senders despite SPF passing
News
Antino phishing emails passed SPF because the sending service was authorized for the attacker's envelope domain, osc-cdn[.]com. The visible From header showed a trusted organization's identity instead. SPF did not authenticate that displayed identity. DMARC compared the domains, found that they did not match, and failed. The reviewed domain published p=none, so its policy requested monitoring rather than quarantine or rejection, and the receiving provider accepted the message. DMARC was not bypassed.
Cisco Talos describes the evidence in its September 30 report, originally published September 30, 2026 at 10:00:01 UTC. The report covers historical UAT-11587 activity observed between September 2025 and July 2026. It does not establish that the attacks began when the report was published. Talos says the activity targeted government, policy, research, and civil-society organizations across Asia.
What the authentication results show
An email has more than one sender identity. SPF checks the RFC5321 envelope sender used during SMTP delivery. People normally see the RFC5322 From header in their mail client. Those identities can use different domains, and that difference is central to the reviewed Antino message.
Simplified authentication readingtext
Visible From: trusted-organization.example Envelope domain: osc-cdn[.]com SPF: pass for osc-cdn[.]com DMARC: fail for visible From domain Published policy: p=none Reviewed outcome: receiver accepted the message
The simplified reading above describes the relationship reported by Talos, not a reproduction of every raw header. Migadu carried mail for osc-cdn[.]com, and that infrastructure was permitted by the attacker's SPF record. A pass therefore said that the sending IP was valid for osc-cdn[.]com. It said nothing about whether the organization named in the visible From field authorized the message.
DMARC evaluated the visible From domain and looked for a matching authenticated SPF or DKIM domain. Talos reports that the domain match failed, producing DMARC fail. The report does not state a DKIM result for the reviewed email, so there is no sound basis to invent one or infer whether a signature was present.
An SPF pass is scoped to one identity
Read the domain attached to the SPF result. A bare "spf=pass" can mislead an analyst when the authenticated envelope domain differs from the sender a recipient sees.
A p=none policy requests no DMARC-based quarantine or rejection. When the record also names an aggregate-report destination, participating receivers can send DMARC reports for monitoring. That explains why acceptance was possible in this case. It does not guarantee inbox placement, because receivers can still filter or reject mail using local reputation, content, impersonation, or threat controls.
The distinction matters during incident review. Operators should record both the result and the identity it covers. Treating SPF pass as proof of the visible sender collapses two separate protocol layers and can turn a clear DMARC failure into a false sense of legitimacy.
What SPF passed
- Domain checked: The attacker-controlled envelope domain.
- Authorization found: The sending infrastructure was permitted for that domain.
Why DMARC failed
- Identity checked: The trusted domain displayed in the From header.
- Domain mismatch: No reported authenticated domain matched the displayed domain.
How the fake Gmail attachment lure worked
The message body copied the appearance of Gmail's attachment preview card. Talos says the actor assembled the card with embedded PNG images and wrapped the visual element in a link to a cloud-hosted delivery page. A recipient saw something that looked like a normal Gmail attachment control, but the element was attacker-authored HTML inside the email body.
This was not a genuine Gmail attachment, and it is not evidence that Gmail or the recipient's provider was compromised. The lure borrowed a familiar interface pattern to make a link feel like a file action. Analysts should inspect the underlying MIME structure and link destination rather than rely on the rendered card.
Flowchart showing how a forged attachment card leads to an external page
Mail controls that extract links should account for uncommon URL forms and links wrapped around image-based controls. Human review should also treat attachment-like graphics as untrusted until the raw message confirms an actual MIME attachment. The useful detection question is not whether the card looks accurate. It is whether the message contains a real attachment or a linked image construct.
This separation prevents a common reporting error. The email impersonated a familiar Gmail interface, but that fact does not show control of Gmail. The actor controlled the message HTML and the linked delivery path.
What Talos attributes to UAT-11587
Talos says it observed UAT-11587 activity between September 2025 and July 2026. The historical activity used tailored policy and government themes against organizations across Asia. Talos identified 10 confirmed affected environments, five probable affected environments, and one additional intended target by July 2026. Those categories are distinct and should not be combined into a single confirmed-victim count.
|
|
|
|---|---|---|
Email identity | Trusted From was spoofed | SPF covered another domain |
DMARC | Failed domain match | p=none requested monitoring |
Lure | Copied attachment card | Not a provider compromise |
Attribution | China-nexus assessment | State sponsorship is not proved |
Reported scope and evidentiary limits
After endpoint compromise, Antino used Microsoft Graph to interact with Outlook and OneDrive for command-and-control traffic. That is reported abuse of legitimate cloud services. It does not show that Microsoft, Outlook, OneDrive, or their underlying infrastructure was breached. Defenders should investigate suspicious tenant applications, tokens, mailbox behavior, and cloud-file activity without blanket blocking widely used shared-cloud services.
Talos assesses with high confidence that UAT-11587 is China-nexus based on technical and operational indicators. That wording is an intelligence assessment, not proof of state sponsorship. Keeping the attribution boundary intact is important when incident reports move into executive, legal, or government review.
Separate observations from assessments
The authentication results, forged body element, and cloud-service use are technical observations. China-nexus is Talos's assessment. State sponsorship is not established by the published evidence.
Checks for mail and security operators
Start with raw headers from the receiving system and use the Authentication-Results field added by a trusted gateway. Forwarded text or a screenshot can omit the envelope identity, authentication authority, or final receiver decision. Our DMARC monitoring workflow groups aggregate evidence by sending source, but a targeted incident still needs message-level header and content review.
A disciplined triage sequence keeps an SPF pass in context and reduces the chance of trusting a forged visible identity.
- Preserve evidence: Export the original message with full headers and MIME structure.
- Compare identities: Record the visible From, envelope sender, SPF domain, and DMARC result.
- Validate trust: Use only authentication fields inserted by your trusted receiving systems.
- Inspect the lure: Determine whether an attachment-like card is embedded imagery linked elsewhere.
- Trace activity: Search mail, proxy, endpoint, and identity logs for related user actions.
- Scope carefully: Follow the internal spoofed email triage process before changing domain-wide controls.
Check the current DNS record separately from the historical message. A domain's policy can change after an incident, and a lookup today does not prove what was published when the email arrived. The message header, contemporaneous DMARC reports, and DNS history provide different pieces of evidence.
Use the DMARC checker to parse the policy currently published for a domain. It confirms syntax and tags at query time, while incident evidence determines the policy and result associated with a specific message.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Treat a DMARC failure with impersonation cues as an investigation lead even when the receiver accepted the message. Authentication policy and receiver disposition are related but separate. Local filtering can act on a p=none failure, and a receiver can also accept mail that the domain owner asked it to quarantine or reject.
Do not respond by blocking every message that touches Outlook, OneDrive, or another shared cloud service. Investigate the tenant, application identity, consent record, account context, destination, and behavior. Broad service blocks impose operational damage and still miss abuse routed through other legitimate infrastructure.
Move from monitoring to enforcement safely
A domain owner should inventory legitimate senders before changing p=none to p=quarantine or p=reject. That inventory needs every authorized marketing system, transactional sender, support platform, internal relay, and third party that uses the domain in a visible From header. Fix the domain match for legitimate traffic first, then increase enforcement in measured stages while watching reports.
Suped is our DMARC platform. For most teams, it is the best overall practical option because it combines automated issue detection, specific fix steps, real-time alerts, and SPF, DKIM, and DMARC monitoring in one operational workflow. Its hosted DMARC controls support staged policy changes after legitimate sources have been verified. That is the concrete job that matters here: finding unauthorized sources without breaking valid mail as enforcement rises.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Enforced DMARC helps stop direct unauthorized spoofing of a protected domain because a receiver can quarantine or reject mail that lacks a matching authenticated identity. It does not stop a lookalike domain, a compromised authorized account, or malicious content sent through a correctly authenticated account. Those cases require separate identity, content, behavior, and incident-response controls.
The Antino email shows why the rollout still matters. DMARC correctly identified the mismatch, but p=none did not ask for a protective disposition. Moving to enforcement reduces this direct-spoofing path, while the surrounding controls handle threats that email authentication cannot classify by intent.
What enforced DMARC helps stop
Unauthorized direct use of the protected visible From domain when neither SPF nor DKIM authenticates a matching domain.
What DMARC cannot establish
Whether authenticated content is benign, whether an authorized account is compromised, or whether a lookalike domain is deceptive.
What defenders should take from the Antino emails
The Antino phishing evidence is a protocol lesson with a clear operational consequence. SPF passed for osc-cdn[.]com, not for the trusted sender shown to the recipient. DMARC caught the domain mismatch and failed. The monitored domain's p=none policy requested observation, and the reviewed receiver accepted the message. None of that means SPF authenticated the visible sender or that DMARC was bypassed.
Preserve raw evidence, compare the envelope and visible identities, investigate failed DMARC with impersonation cues, and stage enforcement only after legitimate senders are known. Review attachment-like body elements as links, and investigate abuse of shared-cloud services with account-level context instead of assuming provider compromise or blocking the service wholesale.
