The Nested .eml That Tried to Silently Authorize a Microsoft App

The subject line said vendor qualification review. The body said ACH remittance advice. That mismatch was the first signal something was wrong, but it was not the payload. The payload was inside the attachment: a nested .eml file containing a Microsoft OAuth authorize URL crafted to silently steal an application access token from the specific recipient. This was consent phishing delivered through a multi-layer obfuscation chain.

Authenticated Infrastructure, Mismatched Identity

The outer message was sent from admin@hungarofood[.]hu through Amazon SES infrastructure at IP 54[.]240[.]8[.]42. SPF passed. DKIM passed for both hungarofood[.]hu and amazonses[.]com. DMARC passed. By every authentication measure, the message was legitimate.

But the Reply-To pointed to gary@turchco[.]com, a completely different domain. Responses would never reach the apparent sender. The From, Reply-To, and Return-Path each referenced different domains, a pattern that should trigger identity-mismatch detection but often does not when each individual domain passes its own authentication checks.

The OAuth Authorize URL Inside the Nested .eml

The attachment, named Dart-Remittance-Service-Agreement-nlwz-4891Eml.eml, contained a nested message from Account@account[.]com with a single high-value link:

hxxps://login[.]microsoftonline[.]com/common/oauth2/v2.0/authorize?client_id=e0480c25-5026-4692-bcfe-ca3d98fb25fe&prompt=none&scope=openid&state=Y2hyaX...

Three details made this link dangerous. First, the client_id referenced an unregistered third-party application, not a known Microsoft or enterprise app. Second, prompt=none instructed the identity provider to skip the consent screen and attempt silent token issuance. If the recipient had an active browser session, the attacker could receive an access token without any user interaction. Third, the state parameter base64-decoded to the recipient's exact email address, confirming this was not a mass campaign but a targeted attack personalized to a specific mailbox.

The click chain also included redirect URLs on guzeldagenerji[.]com[.]tr, a Turkish energy company domain that returned Azure AD error strings in its parameters, indicating it served as a waypoint in the OAuth flow.

Why This Bypasses Gateway Scanning

Most email gateways scan URLs in the outer message body but treat .eml attachments as opaque files. The OAuth URL lived inside the nested message, outside the primary scanning scope. Even gateways that recursively inspect .eml content may not flag a login.microsoftonline.com URL because the domain itself is legitimate. The credential harvesting happens through a legitimate Microsoft endpoint, not an attacker-hosted page.

IRONSCALES flagged the message based on behavioral signals: first-time sender, three-domain identity mismatch, nested .eml with an authorize URL, and the subject-body content inconsistency.

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

Indicators of Compromise

MITRE ATT&CK Mapping