The OAuth Consent Phish Riding Microsoft's Real Login

The dangerous part of this phishing email was not a fake login page. It was a real one.

An IT director at a nonprofit received a message dressed as a Microsoft 365 security notice. The pretext was a scheduled credential check, and the whole thing hinged on a single button that read Confirm Access. That button did not lead to a spoofed Microsoft sign-in clone hosted on some throwaway domain. It led to login.microsoftonline[.]com, Microsoft's genuine authorization endpoint, served on Microsoft's genuine certificate. There was nothing to catch in the address bar, because the address bar was telling the truth.

What sat inside that legitimate URL is the entire story.

A Consent Request, Not a Password Trap

The authorize link carried a real OAuth 2.0 consent request: a registered application client_id and a scope string asking for openid, profile, and https://graph.microsoft.com/User.Read. If the director had clicked Confirm Access and approved the prompt, no password would have changed hands. Instead, the attacker's registered app would have received a delegated access token to read the account through the Microsoft Graph API.

This is consent phishing, and it walks around the two controls most teams lean on hardest. There is no password to capture, so a forced reset accomplishes nothing. And because the user actively grants the permission after a legitimate sign-in, multifactor authentication is satisfied and never challenged again. The token that comes back is a valid grant, not a stolen secret, which is exactly what makes it a durable foothold on the road to full account takeover. Revoking it means hunting through enterprise app registrations, not rotating a credential.

To keep static scanners from recognizing the consent request for what it was, the authorize URL was buried under roughly 80 nonsense query parameters. currency=JPY, brightness_mode=dark, deviceModel=Pixel8Pro, and dozens more like them. Microsoft's endpoint reads only the OAuth parameters it needs and ignores the rest, so the padding changed nothing functionally. What it changed was recognizability: a clean, parseable authorize string became a wall of noise that pattern-based URL filters slide right past.

After the grant, the request's redirect_url pointed the browser at github[.]com/dashboard, an ordinary GitHub page. Landing a victim on a mainstream developer site rather than an obvious attacker portal adds a final coat of legitimacy and buys time before anyone suspects that a permission grant just happened.

Authentication That Passed Its Way In

The sending identity looked reputable, and that was engineered too. The message claimed an aged, legitimately registered business domain that publishes valid DKIM keys. But it was injected from a colocation host (198.46.129[.]90, reverse DNS on colocrossing[.]com) that had no authorization to send for that domain, so SPF failed at the true origin. By the time the message reached the Microsoft 365 boundary it had been relayed onward, and Exchange Online Protection re-evaluated SPF at its own frontend and recorded a pass. DKIM validated against the domain's selector, and DMARC passed as a result. Even that verdict was hollow, because the domain published a policy of p=none, so an outright failure would have carried no enforcement either way.

Every authentication line a gateway printed on this message reads clean or harmless. None of them describe what the link actually asks the recipient to approve.

A few tells gave away the mass-produced kit behind it. The body copy was garbled and templated, and the signature block referenced an unrelated Scandinavian organization that had nothing to do with the sender, the recipient, or Microsoft. A benign invite.ics calendar attachment rode along as social-engineering filler. This was a blast, not a bespoke operation, and it still cleared the edge.

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

Mapping to MITRE ATT&CK

The tradecraft lines up with a few techniques in the MITRE ATT&CK framework:

• T1566.002 Spearphishing Link and T1204.001 User Execution: Malicious Link cover the delivery and the click: a security-themed lure whose payload is a single authorize link the user is coaxed into following.
• T1528 Steal Application Access Token is the objective. Rather than harvesting a credential, the operation solicits an OAuth consent grant so the attacker's app walks off with a delegated token.

Indicators of Compromise

Why Static Tooling Missed It

Signature and reputation checks were never going to flag this. The link resolves to Microsoft's own login domain, the sending domain carries valid DKIM, the final landing page is GitHub, and the attachment is a harmless calendar file. Nothing in the message is a known-bad string. The malice lives entirely in the OAuth scope being requested and in the mismatch between a security-notice pretext and a permission grant, and neither of those is something a URL blocklist can see.

That is where behavioral analysis earns its place. Themis, the Adaptive AI analyst on the IRONSCALES platform, reads the relationship between the claimed brand, the requested application permission, and the redirect chain the way a trained analyst would, flagging a consent-grant lure even when every server-level check comes back green. The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches, and the Microsoft Digital Defense Report 2024 documents the same pivot toward abusing trusted identity services rather than breaking them. The FBI's 2023 Internet Crime Report ranks business-identity and account-compromise fraud among the costliest categories, which is exactly the outcome a stolen token enables. Across 35,000+ security professionals and 17,000+ organizations, the pattern that repeats is legitimate infrastructure turned into cover.

The Takeaway

Consent phishing is the logical answer to a world that finally deployed MFA. If you cannot beat the login, you get the user to approve you after it. When a Microsoft-branded notice says Confirm Access, the reflex is to trust the real login page it points to, not to read the permission it is quietly requesting. The defense is to govern app consent as tightly as you govern passwords, restrict which users can grant permissions to third-party apps, audit existing OAuth grants for unfamiliar client IDs, and pair that hygiene with detection that judges a message by what it asks for, not by whether its servers check out. See where consent-grant and account takeover risk hides in your own mail flow, because the next Confirm Access button is already sitting in someone's inbox.

CISA's guidance on recognizing and stopping phishing early is a solid reference for building that reflex across a team: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one

NIST's working definition of phishing is a useful anchor for training material: https://csrc.nist.gov/glossary/term/phishing