The LOGIN Button Went to Microsoft. That Was the Attack.

A recipient at an environmental-services organization received a DocuSign notification: a completed NDA amendment was waiting. The DocuSign logo was genuine, the layout matched real DocuSign transactional emails, assets were hotlinked from Akamai CDN nodes that DocuSign actually uses. One button sat in the center of the message: LOGIN.

That button did not go to a fake login page. It went to the real Microsoft OAuth authorization endpoint.

Most phishing teardowns describe a counterfeit: a fake portal, a cloned form, a spoofed UI. This attack did not need any of that. The goal was an OAuth consent grant, and the real Microsoft infrastructure was already available.

A DocuSign wrapper around a Microsoft consent request

The display name was formatted to resemble the recipient's own organization's Microsoft account. The actual sending infrastructure was a compromised legitimate domain with years of age and valid authentication records. SPF passed. DKIM passed. The external-origin warning banner was the only visible signal that anything was external.

The body carried no personalization: no recipient name, no document title, no counterparty name. For a genuine DocuSign completion notice, that absence is unusual. Real NDA-completion emails name the document and the parties. This one did not, which reflects mass-targeting rather than a transaction. The duplicate LOGIN blocks and a broken link placeholder in the footer confirmed it was template-generated. That is how impersonation at scale works: the brand is borrowed wholesale, the specifics are omitted, and the call to action does the work.

What the OAuth URL actually contained

The LOGIN button resolved to login.microsoftonline.com, the real Microsoft identity endpoint. That hostname clears every block list ever written. The attack lived in the query string, not the host.

Embedded in that URL were parameters that had nothing to do with DocuSign:

• A redirect_uri pointing to the Spotify authentication service
• supportContact=service[@]ibm[.]com
• locale=ja-JP
• currency=JPY
• timezone=America/New_York

A legitimate DocuSign OAuth flow redirects back to DocuSign's own infrastructure and would not carry IBM contact details or Japanese locale settings for a U.S. recipient. These parameters are artifacts of the attacker's Azure application registration: the client_id belongs to an app the attacker created in Azure AD, and the resulting consent screen requests Microsoft Graph API permissions. Not DocuSign permissions. Graph permissions.

This is consent phishing, and it is the reason MFA does not fully protect against it. The victim does not enter a password into a fake page. The victim authenticates through the real Microsoft identity platform, and the consent grant is the moment of compromise. Once the attacker's application has a delegated Graph token, it can read email, enumerate contacts, access calendar data, and persist that access without needing the password again.

Why link scanners cleared it

The footer carried genuine DocuSign support links. DocuSign's Akamai CDN served the brand assets. The primary CTA pointed to login.microsoftonline.com. Microsoft is clean. DocuSign is clean. Spotify, IBM, and Akamai are clean. A scanner following URLs and checking reputation lists had nothing to flag.

The issue is the combination: a DocuSign lure whose action endpoint encodes a Spotify redirect and Graph consent scope for an attacker-controlled Azure app. Detecting that requires parsing the full OAuth query string and correlating the client_id against known-legitimate app registrations, not just resolving the domain.

The parallel to fake login pages is instructive as a contrast. Classic credential-harvest phishing creates a fake portal because the attacker needs to capture a password and replay it. Consent phishing skips that entirely because modern OAuth access does not require the password at replay time. The attack surface has shifted to the permission layer, and defenses built around "is this a fake login page" miss it by design.

The sender was already trusted

The compromised sender domain was registered in 2002 and had years of legitimate use behind it. The attacker did not register anything new. They used an existing domain whose authentication infrastructure was intact and whose reputation was clean. Age and history cleared the first filter.

The display name mimicked the recipient's own organization's Microsoft identity. A recipient scanning the From field sees their organization's name alongside a Microsoft-formatted address. The sender domain behind that display name was never examined.

Indicators of compromise for the OAuth consent lure

What the detection rested on

Authentication cleared this message. The sender domain was legitimate and properly configured. Every link resolved to a real host with clean reputation. The detection signal was the OAuth query string itself: a consent-grant flow embedding a Spotify redirect and third-party contact details has no plausible legitimate explanation for a DocuSign NDA completion. The mismatch between the claimed transaction and the actual OAuth parameters was the artifact.

Defenders in Microsoft 365 environments should review Azure AD application consent grant logs for applications granted delegated Graph permissions outside a defined approval workflow. Consent phishing does not appear in mail flow as a blocked message. It appears in identity logs as a successful authorization.

The FBI's IC3 2024 Internet Crime Report ranks credential theft and BEC among the costliest categories by reported losses. Verizon's 2026 Data Breach Investigations Report puts the human element in 62 percent of breaches. CISA advises verifying any unexpected authorization request through a known channel before completing it.

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

A secure email gateway inspects hostnames and content. It does not parse OAuth authorization parameters for application identity mismatches. When the entire attack surface lives inside a query string on a Microsoft domain, the gateway has nothing to block. IRONSCALES data shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes each month. Consent phishing is a structural reason why: the malicious element is invisible to controls built around counterfeit URLs and fake login pages.

The LOGIN button was real. Microsoft's endpoint was real. That was the attack.