The Sign-In Link Pointed Home, and Home Was a Decoy

The only destination you could read in this Microsoft sign-in link pointed at the victim's own company. It was a decoy. The subdomain it named does not exist, the parameter carrying it is not one Microsoft recognises, and the values that would actually decide where the flow goes were missing from the link.

The target was a senior finance leader at a UK medical-device and infection-prevention manufacturer. The email was a Teams-styled notice saying a company document was ready, with a VIEW & COMPLETE button underneath.

Click-path reasoning says decode the link, find the destination, judge the destination. Here, that reasoning lands on a hostname that looks like home. An automated analysis of this same message did exactly that, describing the button as an authorize flow with a redirect to the company's developer subdomain and calling it "a plausible single-sign-on path."

A Real Microsoft Endpoint With a Fake Signpost

The button opened a genuine request to login.microsoftonline.com/common/oauth2/v2.0/authorize. Nothing about the host was spoofed. Inside the query string:

• client_id belonged to an unknown third-party app with no public footprint
• prompt=none, asking Microsoft to proceed without showing any UI
• scope of openid, profile and Graph User.Read
• state, a hex string that decodes to the company name plus the recipient's own address
• uri=, double-URL-encoded, pointing at a verification path on a subdomain of the victim's own domain
• several long, multiply-encoded junk parameters dressed up to look like code

The uri value is the signpost. It is the one human-readable URL in the request, and it reads like an internal developer portal handling account verification. A live DNS lookup on 2026-10-06 returned NXDOMAIN for that subdomain. The apex domain is real and routes mail through Exchange Online. The subdomain is fiction.

The Parameters That Were Not There

Microsoft's authorization code flow reference lists response_type and redirect_uri as required. It documents no parameter called uri at all. Successful and error responses both go to the app's redirect_uri.

This link carried neither required parameter. That was checked in the extracted link and again in the original source attribute in the delivered HTML.

So the only "destination" a reader could decode carried no weight in the flow. The real destination, if any, is whatever reply URL the attacker registered for that app, and it appears nowhere in the email. Microsoft's documentation does not cover what happens when both required parameters are omitted, so the request may simply have ended on an error page. The record does not settle which. What it does settle is that the hostname you could read was not where the flow was designed to go.

That matches a family Microsoft Threat Intelligence described in a March 2026 write-up on OAuth redirection abuse. Actors register apps in tenants they control, point the redirect URIs at their own infrastructure, use prompt=none, and carry the target's email in state in plaintext, hex, Base64 or custom encodings. The variant here adds a planted readable value aimed at the victim's own brand, which gives anyone decoding the link a comforting answer.

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

Why Every Conventional Check Came Back Green

All six links scored clean. Every one of them was a Microsoft host: microsoft.com, microsoftonline.com, teams.microsoft.com. URL reputation has nothing to say about a legitimate identity provider.

Authentication passed too. The current-hop results at Microsoft showed SPF, DKIM, DMARC and composite authentication all passing for the sending domain, an established business domain sending through Google Workspace. Whether that domain's account was compromised, abused or attacker-held is not established, and nothing here suggests its owner did anything wrong. Microsoft filtering assigned a spam confidence level of 1 and delivered the message to the inbox.

The relay hop adds one more detail. The host that submitted the message to Google's SMTP relay introduced itself with the name of the victim's own mail server. A Cyrillic-homoglyph rendering of the company name in the display name rounded out the costume.

None of that was the deciding signal. The Themis agentic AI analyst flagged the message as VIP impersonation against a VIP recipient at confidence 85, and the platform automatically quarantined the single affected mailbox. There is no evidence anyone clicked.

The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches and credentials in 39% across the full kill chain. A link that survives both reputation and authentication checks is precisely the kind that reaches a human.

MITRE Mapping and Indicators

The delivery maps to T1566.002, Spearphishing Link. This record does not establish token theft or a consent grant: the scope was identity plus User.Read, under prompt=none, with no response type requested.

Judge the App, Not the Signpost

The lesson is narrow and practical. Decoding an authorize link and reading "where it goes" can mislead you, because the attacker controls which values look like destinations and which values actually are.

Read three things instead:

1. The client_id. Is it a Microsoft first-party app or one your organization approved? An unknown third-party id is the story.
2. The prompt value. prompt=none on an unsolicited link means the request was built to run without the user seeing anything.
3. What is missing. If redirect_uri is absent, the destination is in a registration you cannot see from the email. Treat any URL-shaped value in the query string as decoration.

Then act on the app. Search Entra sign-in logs for the client_id, block it at the tenant level, and review account takeover protection controls around third-party app sign-ins. CISA phishing guidance already pushes defenders toward identity-layer controls, and the Microsoft Digital Defense Report 2024 tracks identity attacks as a dominant pressure on enterprise tenants.

NIST defines phishing as a fraudulent solicitation in which the perpetrator masquerades as a legitimate business or reputable person. This one masqueraded for the defender too, and a planted hostname pointing home was enough to fool an automated reader. What caught it was impersonation analysis of sender and recipient, the kind of signal Adaptive AI weighs, not the link.

IRONSCALES platform data, drawn from 36,000+ security professionals across 18,000+ organizations, shows 67.5 phishing emails per 100 mailboxes each month. Some of them will point home. Check the app.