The OAuth Authorize URL That Didn't Ask for Permission

The phishing email did not ask the recipient to enter a password. It did not redirect to a fake login page. It pointed to login.microsoftonline.com, the real Microsoft authentication endpoint, and attempted to silently acquire an OAuth access token without ever showing a consent screen.

The campaign arrived through Amazon SES with full SPF, DKIM, and DMARC authentication passing for the sending domain. The body was rendered as an embedded image, invisible to text-based scanners. And the OAuth authorize URL was duplicated inside a nested .eml attachment, giving the attack two independent paths to the target's Microsoft 365 session.

This is not credential harvesting through a fake portal. This is token theft through Microsoft's own infrastructure.

See Your Risk: Calculate how many threats your SEG is missing

Amazon SES Provides the Authentication Cover

The email originated from admin@hungarofood[.]hu, a Hungarian food industry domain with Amazon SES configured as its authorized sending infrastructure. The Return-Path pointed to an SES bounce address, and the DKIM signature validated against both hungarofood[.]hu and amazonses.com. SPF passed. DKIM passed. DMARC passed.

For any Secure Email Gateway (SEG) evaluating this message on authentication results alone, it looked clean. The sending domain was not newly registered. The infrastructure was not associated with known malicious campaigns. And Amazon SES, one of the most widely used legitimate email services on the internet, was the delivery vehicle.

The Reply-To header, however, pointed somewhere else entirely: gary@turchco[.]com. That address had no relationship to the sending domain, no relationship to the claimed sender identity, and no reason to be receiving ACH remittance replies. According to the Microsoft Digital Defense Report 2024, abuse of legitimate cloud services for phishing delivery increased significantly year-over-year, with email service providers among the most frequently weaponized platforms.

The Subject and Body Tell Two Different Stories

The subject line read "Vendor Qualification Review" followed by a random alphanumeric token. The email body showed an "ACH Remittance Advice" notification. That mismatch is a signal. Legitimate financial communications do not reference vendor qualification in the subject and payment remittance in the body.

The body itself was rendered as a CID-embedded image, not selectable text. This is a deliberate evasion technique. Text-based classifiers, keyword filters, and natural language processing engines cannot extract content from an image embedded via MIME Content-ID reference. The message included an external sender warning banner, and the signature block read "Accounts Payable Department" with no phone number, no company name, and no contact details.

The technique maps to MITRE ATT&CK T1566.002 (Phishing: Spearphishing Link) for the delivery mechanism and T1528 (Steal Application Access Token) for the objective.

The OAuth Flow Is the Weapon

The primary call-to-action linked directly to login.microsoftonline.com/common/oauth2/v2.0/authorize with several parameters that reveal the attacker's intent.

The client_id (e0480c25-5026-4692-bcfe-ca3d98fb25fe) referenced an unregistered or untrusted application, not a recognized Microsoft or third-party service. The prompt parameter was set to none, which instructs the Microsoft identity platform to attempt token issuance without displaying a login or consent screen. If the target has an active Microsoft 365 session (and most corporate users do during business hours), the token is granted silently. The user sees nothing.

The state parameter contained a base64-encoded string that decoded to the target's corporate email address. This confirms per-recipient URL generation: each target received a unique OAuth URL tailored to their identity.

A secondary domain, guzeldagenerji[.]com[.]tr (a Turkish energy company site), appeared in the OAuth redirect flow, returning an AADSTS50058 error. That error code means "silent sign-in failed because no session cookie was found." In other words, the prompt=none strategy requires the victim to already be authenticated. When the session cookie is absent, the flow breaks at the redirect URI. That error is the fingerprint of a failed silent token acquisition attempt.

This is not traditional phishing. There is no fake login form. No password field. The attack operates entirely within Microsoft's legitimate OAuth2 infrastructure, requesting account takeover access through an application consent flow that most security tools do not inspect.

The Nested .eml Attachment Doubles the Attack Surface

Attached to the email was a 4,405-byte .eml file named [Company]-Remittance-Service-Agreement-nlwz-4891Eml.eml. Inside that nested message (From: Account@account[.]com, a generic internal-looking header) was the same OAuth authorize URL with the same client_id and the same recipient-specific state parameter.

The nested .eml contained no password fields, no script tags, and no form elements. It did not need them. The entire attack relies on the OAuth authorization flow. By duplicating the URL inside an attachment, the attacker created a second delivery path. If the recipient did not click the link in the email body, opening the attachment presented the same opportunity.

SHA256 of the attachment: 54093804eb7204c4c87ebd312f347811110526414571f669578023f630bbe499

Behavioral Detection Caught What Authentication Could Not

Authentication verified the sending infrastructure. It could not evaluate what the email was asking the recipient to do. Themis, the IRONSCALES Adaptive AI engine, identified the behavioral mismatch: an external sender with no prior relationship to the organization, a subject-body content conflict, CID image rendering to evade text analysis, and an OAuth authorize URL with parameters consistent with silent token acquisition.

The combination of first-time sender signals, reply-to divergence, and the OAuth consent flow pattern triggered classification before any user interaction occurred. Multiple mailboxes at the targeted organization were affected, and the campaign was contained through automated quarantine based on behavioral analysis rather than payload scanning.

What Defenders Should Watch For

OAuth consent phishing is a fundamentally different threat than credential harvesting through fake login pages. The URL is legitimate. The domain is Microsoft. The flow is real. The only thing that is wrong is the application requesting access.

Security teams should monitor for:

1. OAuth authorize URLs with unrecognized client_id values. If the application is not in your organization's approved registry, the request should be blocked or flagged regardless of the domain.
2. The prompt=none parameter in authorize requests. Silent authentication attempts from email links are almost never legitimate. This parameter should trigger elevated scrutiny.
3. Base64-encoded state parameters that resolve to internal email addresses. Per-recipient URL generation is a hallmark of targeted OAuth phishing campaigns.
4. Nested .eml attachments containing OAuth or authentication URLs. The duplicated attack path is designed to survive partial content inspection.

---

Indicators of Compromise

MITRE ATT&CK Mapping