The Phishing Email With No Login Page

The email did everything a phishing filter is trained to reward. It passed SPF. It passed DKIM. It passed DMARC. It arrived from Amazon SES with a valid signature and a composite authentication score of 100. And its one and only link pointed at login.microsoftonline.com, a domain no reputation engine on earth is going to block.

There was just one problem. The link was built so the victim would never see a Microsoft login page. No credentials prompt, no consent screen, nothing. Just a benefits document that opened straight into a fake sign-in page on a domain nobody had ever heard of.

The target was a VP of Finance at a mid-size technology company. The lure was a benefits and compensation update. The technique was an OAuth authorize request tuned to be silent. Here is how it worked, and why authentication told the defenders nothing useful.

A Benefits Update That Passed Every Auth Check

The subject line read like HR paperwork: an action-required notice about an updated benefits and compensation package, complete with a random reference number for verisimilitude. The body carried professional e-signature branding, loading image assets from HelloSign infrastructure, and a single prominent VIEW DOCUMENT call to action. A line of copy warned the recipient not to forward the email "to prevent others from accessing your document," a classic secrecy nudge that keeps a target from asking a colleague whether the message is real.

The delivery was clean on paper. The message was sent through Amazon SES from an authenticated domain with a valid DKIM signature, so SPF, DKIM, and DMARC all returned a pass. That domain was a first-time sender to the recipient and carried no prior relationship with the organization, but nothing about the transport screamed malicious. Authenticated delivery is not evidence of safety. It is evidence that someone used a reputable mail service correctly, which attackers do precisely because it improves deliverability and lowers suspicion.

There were no attachments. The entire attack lived in one link.

The Link That Skipped the Login Screen

Here is the destination behind VIEW DOCUMENT, defanged:

hxxps://login[.]microsoftonline[.]com/common/oauth2/v2.0/authorize?client_id=606c8066-a5a1-4b1d-a003-15125329b1f2&prompt=none&redirect_uri=hxxps://myreguerastudio[.]com/zdoc-100901668&response_type=code&scope=openid profile email

Read the parameters, because they are the whole story.

• response_type=code requests an OAuth authorization code flow.
• redirect_uri=hxxps://myreguerastudio[.]com/zdoc-100901668 hands the flow off to a domain that has nothing to do with Microsoft or the recipient's employer.
• prompt=none is the sharp edge. It instructs Microsoft to display no interactive login or consent screen. For a user who is already signed in, the browser passes straight through the endpoint with no Microsoft page to slow them down.

The intent is a phishing link with no visible login step. The victim clicks a benefits document, the request runs through a genuine Microsoft endpoint, and they arrive at a page on the third-party domain whose displayed text reads "completing secure sign in." That landing page, hxxps://myreguerastudio[.]com/zdoc-100901668, is where the credential theft actually happens. It was flagged malicious on inspection.

This is worth being precise about, because the mechanism is easy to overstate. The scope requested was openid profile email, basic identity, not mailbox or file access. This was not a broad consent grant that would hand an attacker a persistent token to read a mailbox. The Microsoft endpoint was being used as a trusted redirector and a login-screen suppressor, laundering the reputation of login.microsoftonline.com to move the victim quietly onto a harvesting page. The theft is the fake sign-in form, not a silent token grab. That distinction matters when you are writing detections.

Under MITRE ATT&CK this maps to Spearphishing Link (T1566.002) for the delivery vector, with Impersonation (T1656) covering the HelloSign brand dressing used to make the request look routine.

Why the Third-Party Domain Was the Tell

The landing domain, myreguerastudio[.]com, is the kind of infrastructure that looks unremarkable until you pull the thread. Its WHOIS record is privacy-protected. Its name servers point to a small third-party host, and it resolves to a single unremarkable IP. It has no relationship to Microsoft, to HelloSign, or to the recipient's company. In an OAuth request, a redirect_uri that lands on an unrelated, privacy-registered domain is a screaming anomaly, and it is exactly the signal that clean authentication headers will never surface.

That is where behavioral detection earns its keep. Themis, the IRONSCALES agentic AI SOC analyst, did not care that the message passed DMARC. It scored the malicious redirect, weighed the first-time external sender and the brand-to-destination mismatch, flagged the incident with 90 percent confidence as credential theft against a VIP recipient, and quarantined the message within seconds of delivery. A gateway tuned to authentication and URL reputation would have waved this through on the strength of the Microsoft domain alone.

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

The Broader Lesson for Detection Teams

Credentials remain the currency of intrusion. The 2024 Verizon Data Breach Investigations Report found that stolen credentials were involved in 38 percent of breaches, and that phishing was present in 15 percent of breaches. The Microsoft Digital Defense Report 2024 documents the same shift toward abusing legitimate identity infrastructure rather than obvious spoofs. When the front door is a trusted OAuth endpoint, the attacker no longer needs a lookalike domain to fool a scanner.

Three practical takeaways from this case:

• Inspect the full URL, not the host. A link to login.microsoftonline.com is meaningless on its own. The redirect_uri is the destination that matters, and a prompt=none parameter on an inbound benefits email is a red flag with no legitimate explanation.
• Treat authentication as necessary, not sufficient. SPF, DKIM, and DMARC confirm transport, not intent. CISA phishing guidance is blunt that authenticated does not mean trusted.
• Score behavior and destination. First-time senders, brand-to-link mismatches, and low-trust redirect targets are the signals that catch credential harvesting and the account takeover that follows it, long after the headers come back clean.

The 2024 IBM Cost of a Data Breach report puts the price of credential-driven compromise in the millions per incident. This one cost the attacker a signed benefits email and a clever URL. Finance executives are targeted precisely because they are trusted, and because a benefits update is the one email nobody wants to ignore. The defense is not more authentication. It is looking at where the link actually goes.

Indicators of Compromise