The Email That Passed Every Security Check (Because Adobe Sent It)

At 5:41 PM UTC on December 1, 2025, a staff member at a school district in Arizona received an email from Adobe Acrobat. It looked like dozens of similar notifications she had seen before: a colleague had shared a document, a phonics and math instruction resource with a name suggesting it was something for a classroom. The email asked her to click Open.

She probably almost did.

The Notification That Had No Wrong Answers

The email rendered flawlessly. The Adobe Acrobat logo was real, pulled from Adobe's own CDN. The layout matched Adobe's production email template exactly, because it was Adobe's production email template. The sender line showed a colleague's school email address "via Adobe Acrobat," displayed in her email client in the same way a legitimate collaboration notification would appear.

When her organization's email gateway evaluated the message, it had no objections. SPF passed. The sending IP, 76[.]223[.]139[.]181, belonged to Amazon SES, the infrastructure Adobe uses for outbound transactional mail via c139-181.smtp-out.amazonses.com. DKIM signatures verified for both adobe[.]com and amazonses[.]com. DMARC passed with action=none for header.from=adobe.com. Microsoft's compauth score came back at 100. The email authentication was not just passing, it was perfect.

The "Open" button in the email pointed to postoffice[.]adobe[.]com, Adobe's legitimate link-redirect service. The URL was not a lookalike. It was not a typosquat. It resolved to Adobe infrastructure on AWS. Every URL scanner that touched the links returned clean verdicts.

There was no lookalike domain. No spoofed header. No suspicious attachment. Technically, every indicator said: this is Adobe.

What the Attacker Actually Built

To understand what happened, you have to work backward from the infrastructure.

Adobe Acrobat's document-sharing feature lets any account holder share a file and trigger an automated notification to any email address. The notification comes from message@adobe[.]com, routed through Amazon SES on Adobe's authorized sending IPs, signed with Adobe's DKIM keys. The recipient sees a real document name, a real timestamp, and a real Open button. Phishing built on top of legitimate platforms like this is sometimes called "living-off-trusted-services" (LOTS), and it is becoming one of the more difficult categories to defend against.

In this case, the attacker shared a real Acrobat Creative Cloud resource. The document name, EDITABLERollandReadPhonicsMathFactsTargetedInstruction-1, matched the target's professional context precisely. This was not a generic lure. The targets were district staff, the document looked like a K-12 curriculum resource, and the sender address belonged to the same organization. The attacker either had access to an internal account or had researched the target well enough to impersonate a plausible internal sender.

The primary CTA and most utility links in the email routed through postoffice[.]adobe[.]com/po-server/link/redirect, with the destination URL encoded as a HS512 JWT in the target parameter. Those JWTs contained the recipient's full email address (cervantes.elisa@[anonymized].org) embedded in the payload, meaning Adobe's redirect server would handle personalized routing for each target. From a URL scanner's perspective, the link host was adobe.com. The encoded destination was opaque until runtime.

One technical tell surfaced in the DNS: postoffice[.]adobe[.]com publishes v=spf1 -all, meaning it explicitly rejects all mail from itself. It has no DKIM selectors and no DNSKEY records. It is configured as a redirect host, not a mail sender. The mismatch between its role in delivering email links and its DNS policy is unusual, but it would not raise a flag in any standard mail filter.

MITRE ATT&CK mapping: - T1566.002: Spearphishing Link (primary delivery vector) - T1534: Internal Spearphishing (sender impersonation of same-org colleague) - T1036: Masquerading (Adobe brand and infrastructure used to mask intent)

Defanged IOCs: - Sending IP: 76[.]223[.]139[.]181 (Amazon SES, ses[.]adobe[.]com authorized) - SMTP host: c139-181[.]smtp-out[.]amazonses[.]com - Sender address: message@adobe[.]com - Return-Path domain: ses[.]adobe[.]com - Redirect host: postoffice[.]adobe[.]com - Document URN: urn:aaid:sc:VA6C2:22d2fa6b-b966-4881-9a2a-bdda3102a26e - Message-ID: 0100019adb01b661-b983db10-c37d-4d99-ba05-81ff788bb9fd-000000@email[.]amazonses[.]com

The One Thing That Was Not Right

There was no malicious URL to detonate. No domain reputation to check. No header anomaly to surface. The attack was built specifically to make technical detection impossible.

What remained were behavioral signals.

IRONSCALES' Themis AI flagged the message through two independent detection paths. First, the Semantic Analyzer, a natural language processing model that evaluates message content for patterns consistent with social engineering attempts, found the message suspicious. The body text, the document-sharing framing, the urgency-lite invitation to "view and comment," the lack of any personal greeting to the named recipient, these are structural patterns that align with credential-luring campaigns even when the platform sending the email is legitimate.

Second, community intelligence: similar messages had been quarantined at peer organizations. The same campaign, same infrastructure, same lure pattern had hit other tenants. That pattern recognition, aggregated across IRONSCALES' protected organizations, gave Themis a community-sourced signal that this sender profile was associated with active phishing activity.

Combined, the two signals produced a classification of Phishing with 78% confidence. The email was quarantined. Four mailboxes across the district received the same lure. All four were mitigated.

No credential was harvested.

What Happens When You Trust the Checkmarks

Most enterprise email stacks are built around a core assumption: if SPF, DKIM, and DMARC pass for a known legitimate domain, the email is safe. Threat intelligence feeds, URL scanners, and domain reputation databases reinforce this assumption. A perfect authentication result for adobe.com is as strong a clean signal as those systems can produce.

That assumption breaks against living-off-trusted-services attacks. The Verizon 2024 Data Breach Investigations Report found that phishing remains one of the top initial access vectors in breaches, and attackers are increasingly routing lures through legitimate cloud platforms precisely because authentication-based defenses cannot distinguish authorized use from abuse. IBM's 2024 Cost of a Data Breach Report puts the average cost of a phishing-initiated breach at $4.88 million. The investment in tooling that cannot catch this attack class is not neutral. It is a liability.

MITRE ATT&CK T1566.002 documents spearphishing links as a primary initial access technique. What the framework's current documentation does not fully capture is the variant where the link host itself is a trusted vendor's production infrastructure.

For organizations that work primarily in Microsoft 365 environments, this is worth stress-testing directly. The Microsoft 365 Defender documentation on anti-phishing policies describes impersonation protection and mailbox intelligence as core controls, but those controls target domain and display-name impersonation. They are not designed for the case where the sending domain is genuinely adobe.com and the infrastructure is genuinely Amazon SES.

The signal that caught this attack was not technical. It was contextual and behavioral. A first-time sender. A document that matched the recipient's professional context a little too precisely. Language patterns consistent with social engineering. Community data showing the same campaign active elsewhere.

That is not a checklist a spam filter runs. It is pattern recognition that requires understanding what normal looks like for this recipient, for this organization, and across an entire protected ecosystem.

See how many phishing emails are getting through your filters.

The four mailboxes in this district were protected. The question for every organization running authentication-only defenses is: how many of theirs are not?

---

For more on the threat intelligence behind cases like this, visit the IRONSCALES Threat Intelligence blog.