A Credential Phish With No Attacker Domain to Block

A regional development officer at a national pediatric research and fundraising charity received a proposal email. It came from a waste-disposal company, a real business that has been operating under the same domain since 2007. The pitch was thin: a request-for-proposal and budget note for the coming cycle, one button reading View Proposal, no signature, no context, nothing that explained why a waste-disposal vendor would be sending a fundraising officer a budget document.

Two details made it worth a second look. The From and To headers were identical, so the message was addressed to itself. And the button did not point at some freshly registered lookalike. It pointed at the vendor's own genuine SharePoint Online tenant.

There was no attacker domain anywhere in the chain to block.

Every Check Passed Because Nothing Was Spoofed

Most phishing analysis starts by finding the fake. Here there was nothing fake to find. The sending domain was authentic. The Microsoft 365 tenant behind it was authentic. The SharePoint site hosting the lure was authentic. The login page the link eventually reached was Microsoft's real OAuth prompt.

That is why the authentication picture reads like a textbook example of a clean message. SPF passed, because the mail genuinely left the vendor's own outbound relay. Domain Keys Identified Mail (DKIM) passed on the tenant's real signing key. Domain-based Message Authentication, Reporting and Conformance passed under a p=quarantine policy, with the action logged as none. ARC passed. Microsoft's composite authentication returned compauth=pass with reason=100, the strongest possible verdict.

Every gate a legacy gateway leans on returned green, because authentication was never designed to measure intent. It confirms that a sender is who the headers claim, and in this case the sender really was a long-established company's mailbox. This is the mechanic behind vendor email compromise: once an attacker is operating from inside a trusted partner's authentic infrastructure, the reputation and the cryptographic proof both work in the attacker's favor rather than the defender's.

The Lure Lived Inside Real SharePoint

Follow the button and the reason for the clean pass becomes obvious. The View Proposal link resolved to a personal SharePoint document path on the vendor's own tenant, the kind of .../_layouts/15/Doc.aspx URL that Microsoft 365 generates for every shared file. Tucked into the query string was a base64-encoded originalPath parameter, the standard way SharePoint remembers where to send a user after sign-in.

From there the flow handed off to Microsoft's real login.microsoftonline.com OAuth prompt. To the recipient, and to any URL-reputation engine, this is Microsoft asking a user to authenticate to a Microsoft resource. Nothing in the redirect chain touched a non-Microsoft host. The credential capture, when it came, wore the most trusted login screen in the enterprise. The document itself was bait, its only job to justify a sign-in that the attacker could observe or intercept.

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

Mapping to MITRE ATT&CK

The tradecraft maps to a small set of techniques in the MITRE ATT&CK framework, and the interesting part is how few artifacts each one leaves behind.

• T1566.002 Spearphishing Link covers the delivery. The payload is a link, not an attachment, and the link goes to a legitimate cloud document rather than a malicious host.
• T1204.001 User Execution: Malicious Link covers the click. The attack depends entirely on the recipient opening the SharePoint document and proceeding through the OAuth prompt.
• T1534 Internal Spearphishing captures the self-addressed structure. A message that sends from and to the same identity mimics the pattern of internal or trusted-partner correspondence, lowering suspicion before the reader has processed the content.

Indicators of Compromise

Because the campaign used no attacker-owned infrastructure, the indicators here are behavioral patterns, not blocklist entries. The vendor identifiers below are anonymized because that company is itself a victim.

Detection Has to Read Relationships, Not Reputation

Reputation and signature engines were never going to catch this. There was no bad reputation to catch, because every hop belonged to a trusted vendor and to Microsoft. Detection has to move to the layer authentication ignores: the relationship and the behavior.

The signals that actually matter are the first-time sender who has never corresponded with this recipient, a mismatch between the vendor's line of business and the content of the pitch, a self-addressed message, and a context-free proposal that asks for a click with no supporting detail. Read together, those add up to a story that a p=quarantine pass cannot override.

This is where IRONSCALES adds a layer that static gateways miss. Themis, the Adaptive AI analyst on the IRONSCALES platform, models the relationship between sender and recipient and weighs the behavioral anomalies a human analyst would notice, flagging the message even when SPF, DKIM, and DMARC all pass. Across 35,000+ security professionals in 17,000+ organizations, the recurring lesson is that clean authentication is not a clean bill of health. The 2024 Verizon Data Breach Investigations Report puts stolen credentials behind 38 percent of breaches and the human element in 68 percent, and it clocks the median time to click a phishing link at 21 seconds and to submit data at 28 seconds. The Microsoft Digital Defense Report 2024 documents the same shift toward abusing trusted cloud services rather than breaking them, and the FBI's 2023 Internet Crime Report ranks business and vendor identity compromise among the costliest fraud categories precisely because it turns trust into the weapon.

The Takeaway

A green authentication result answers one question: did the mail come from where it says it came from. It does not answer whether you should trust the request. When an attacker operates from a real vendor's tenant and stages the lure inside real SharePoint behind a real Microsoft login, there is no domain to blocklist and no signature to write. The defense is layered credential harvesting protection that judges relationships and behavior, plus the human habit of verifying an unexpected proposal through a known contact on another channel. CISA's guidance on stopping the attack cycle early is a solid reference for building that reflex: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one