When Your Security Vendor's OAuth Endpoint Is the Phishing Link

The billing notice looked legitimate. Pandora branding, a recurring charge of $30.93, an account ID, a processing date. Clean formatting. Exactly the kind of transactional email users open without thinking.

The sender domain was calclean.com, not pandora.com. SPF passed. DMARC passed. And the only CTA in the email resolved to api.services.mimecast.com.

That last detail is the one worth examining.

The Link That Pointed to Your Security Vendor

The clickable element in this email was not a lookalike domain. It was not a freshly registered .xyz or a homoglyph of a known brand. It was a real URL on a real Mimecast API subdomain:

hxxps://api.services.mimecast[.]com/oauth2/authorize?client_id=o20nRkVXf7VUVnANkXhoOwGytEwGN0YAlyeDJn7oBTGNl2kN&redirect_uri=hxxps://report.mimecastcybergraph[.]com/callback&response_type=code&state=[encoded_payload]

That is Mimecast's legitimate OAuth2 authorization endpoint. The api.services.mimecast.com domain has an established reputation. Any URL scanner evaluating this link on domain reputation alone would rate it clean. In this case, one did exactly that.

The problem is not the domain Mimecast controls. The problem is the redirect_uri parameter: hxxps://report.mimecastcybergraph[.]com/callback.

According to WHOIS, mimecastcybergraph.com is registered to Mimecast Services Limited through MarkMonitor, hosted on AWS nameservers. That domain is also legitimate Mimecast infrastructure, specifically their CyberGraph email inspection and reporting product. So the callback endpoint the OAuth flow was directed to was, on paper, another real Mimecast asset.

What this attack exploited is the implicit trust that accumulates around a security vendor's infrastructure. If the URL goes to Mimecast, it must be vetted. That assumption is the vulnerability.

How the Attack Chain Was Constructed

The full delivery path:

1. Sender identity: Display name "Pandora" with sending address pandoramusic@calclean.com. The sending domain is privacy-protected via a Cloudflare-fronted registrar, with no verifiable connection to the Pandora brand.

1. Infrastructure: Email sent via Amazon SES (a9-30.smtp-out.amazonses.com, IP 54[.]240[.]9[.]30), then relayed through relay.mimecast[.]com before reaching Microsoft Exchange Online and the final mailbox.

1. Authentication result at the Mimecast relay: DKIM passes for both calclean.com and amazonses.com. SPF passes. DMARC passes for header.from=calclean.com.

1. Authentication result at final delivery (Microsoft): DKIM body-hash failures for both signing domains. The message body as received did not match what was signed. The Mimecast relay had rewritten the body in transit, injecting its own CyberGraph inspection banner and banner markup into the HTML before passing it downstream.

This is where DKIM's design limitation surfaces in an attacker-friendly way. DKIM protects the integrity of a message between the signer and a recipient who can verify the signature. When a legitimate intermediary (in this case, Mimecast itself) modifies the body to add security annotations, the body hash no longer verifies. The DKIM failure at final delivery is not evidence of tampering by the attacker. It is a side effect of the relay that was supposed to be adding protection. The cryptographic trust signal is gone, but not because the attacker broke it.

That is a subtle failure mode. And it matters because a DKIM pass at the relay hop had already satisfied the ARC chain. By the time the message arrived in the mailbox, the authentication picture was: SPF pass, DMARC pass, DKIM fail, ARC pass. Three of four green lights.

The OAuth Flow as a Phishing Mechanism

OAuth consent phishing is not new. Microsoft documented campaigns abusing its own OAuth infrastructure as far back as 2022, and the technique is tracked under MITRE ATT&CK T1550.001 (Use Alternate Authentication Material: Application Access Token). What makes this case notable is the second layer of vendor trust involved.

The email landed in the mailbox of an organization running Mimecast as its email security gateway. The injected CyberGraph banner at the top of the message told the recipient: "This message needs your attention. This is their first email to your company." It offered a button to "Report this Email or Mark as Safe." Powered by Mimecast.

So a recipient seeing this email would see Pandora branding, a plausible billing amount, and a Mimecast security notice at the top confirming the message had been through their vendor's inspection. Then they would click a link that resolves to api.services.mimecast.com.

At no point in that user experience is there an obvious signal that anything is wrong.

Clicking the CTA would initiate an OAuth2 authorization code flow. Whether that flow was intended to harvest tokens, capture credentials through a fraudulent consent page, or simply validate that the mailbox was active depends on what was behind the redirect_uri. What is certain is that the attacker designed the flow to land at a destination they controlled through that parameter, and that automated scanning had already given the link a clean verdict.

See Your Risk: Calculate how many threats your gateway is missing each month

Within minutes of delivery across four affected mailboxes, Themis flagged the campaign based on behavioral signals: first-time sender, brand impersonation patterns, and the unusual presence of an OAuth authorization URL in what was framed as a routine billing notification. No action had been taken on the email before automated mitigation completed.

What URL Reputation Checks Cannot See

The reason this technique is effective against signature-based defenses is architectural, not a gap that can be patched with a rule update.

URL reputation systems evaluate the domain being linked. When that domain is api.services.mimecast.com, the reputation score reflects Mimecast's standing as a legitimate vendor, not the intent of whoever crafted the redirect_uri parameter embedded in the query string.

Scanning the link at click time improves the picture but does not solve it. The Mimecast OAuth endpoint is a real OAuth endpoint. A click-time scanner following that URL will see a legitimate OAuth authorization page. It will not know whether the redirect_uri points to a consent flow the user actually authorized or to an attacker-controlled callback.

This is a broader pattern. According to the Verizon 2024 Data Breach Investigations Report, phishing remains the top initial access vector in confirmed breaches, and the technique sophistication is increasing specifically in the direction of abusing trusted infrastructure. The Microsoft Digital Defense Report 2024 (full report) identified OAuth token theft as a primary persistence mechanism for advanced threat actors in cloud environments.

Across the IRONSCALES customer base of 1,921 analyzed organizations, campaigns using security vendor infrastructure as delivery or redirect mechanisms have increased. The pattern is consistent: attackers identify that defenders have trained both users and automated tools to trust known vendor domains, then route payloads through those domains.

The IRONSCALES platform approaches this through behavioral analysis rather than reputation lookup. The relevant signals here were not the domain's reputation but the combination of factors: brand claimed in the email does not match the sending domain, first-time sender, OAuth authorization URL in a billing context, and abnormal link structure for the claimed email type. That behavioral fingerprint does not depend on knowing that the linked domain is "good" or "bad."

What to Check in Your Environment

If your organization uses Mimecast or any email security gateway that injects content into email bodies, these are the specific things worth reviewing:

• DKIM body-hash failures on relay-processed mail. They are expected and normal when your gateway modifies message bodies. That expectation should not be used to suppress DKIM failure signals entirely. Track the pattern: does a body-hash failure appear alongside a first-time sender and an OAuth URL? That combination is different from routine relay modification.

• OAuth authorize URLs in commercial or transactional email. Legitimate billing notifications do not require OAuth authorization flows. Flag any email categorized as transactional or commercial that contains an OAuth authorize endpoint as a CTA.

• Redirect URI contents in scanned links. If your URL scanner or secure email gateway has the ability to parse query parameters during link analysis, configure it to flag OAuth flows where the redirect_uri points to a domain different from the primary linked domain. This catches the specific mismatch this attack relied on.

• Brand display name versus sending domain mismatches. calclean.com claiming to be Pandora is a clear mismatch. DMARC alignment does not validate the brand claim. It only validates that the sending domain matches the header.from. A privacy-protected domain sending as a consumer media brand is worth automatic scrutiny regardless of authentication status.

The IRONSCALES DMARC management capability provides visibility into exactly these mismatches at scale. And for teams doing incident response on OAuth consent phishing patterns, the credential harvesting protection page covers the broader detection framework.

Indicators of Compromise

The sending infrastructure used Amazon SES and Mimecast relay. Both are legitimate commercial services. Neither their presence in the relay chain nor the clean reputation of the linked domains should be treated as exculpatory in phishing investigations. The relevant question is always whether the combination of behaviors makes sense for the claimed email type. Here, it did not.