The SharePoint File Share That Came From Microsoft's Own Infrastructure

The URL pointed to Microsoft's own infrastructure. The domain was my.sharepoint[.]com. The TLS certificate was valid. The URL scanner returned "clean." And the credential-harvesting page was sitting right there, hosted inside a real SharePoint Online tenant, waiting for the recipient to authenticate.

This is what phishing looks like when the attacker never leaves Microsoft's trust perimeter.

A Pixel-Perfect File Share From a First-Time Sender

The email arrived as a standard Microsoft "file shared with you" notification. Subject line, font, layout, CTA button: all generated by Microsoft's notification system or built to be indistinguishable from it. The single call-to-action read "VIEW PROJECT PROPOSAL." Below it, a line of UI copy: "This link only works for the direct recipients of this message." Microsoft help links populated the footer. A 1x1 tracking pixel loaded from southcentralusr-notifyp.svc[.]ms.

The sender address belonged to a domain registered to a marine services company. First-time external sender. No prior email relationship with the recipient organization. HIGH risk classification from IRONSCALES.

No personalization appeared in the body beyond the recipient's mailbox address. No urgency language. No grammatical errors. The notification looked exactly like every other SharePoint file share that lands in a business inbox on a Tuesday morning. That was the point.

Authentication: Everything Passed, but Nothing Was Verified

SPF passed. DKIM passed for truenorth-marine[.]com. ARC passed. DMARC returned bestguesspass.

That last result is the one that matters. A bestguesspass means the sender domain has no published DMARC record. None. The domain owner never configured one. Microsoft, rather than returning "none" and flagging the gap, inferred a DMARC outcome based on the SPF and DKIM results. Since both passed, the inferred result was bestguesspass, which most receiving systems treat the same as a legitimate pass.

The practical effect: there is no enforcement policy. Even if SPF and DKIM had both failed, there would be no DMARC policy instructing the receiving server to reject or quarantine the message. The domain owner opted out of the one mechanism that gives receiving servers explicit instructions on how to handle authentication failures.

For an attacker, this is ideal. The domain authenticates well enough to avoid rejection, and the absence of a DMARC record means no enforcement exists to catch a spoofed or compromised message even if the authentication signals degrade.

The FBI's 2024 Internet Crime Report recorded $2.9 billion in BEC losses. A significant share of those incidents began with emails that passed authentication because the sending domain's authentication posture was either incomplete or missing entirely.

The SharePoint URL: Real Infrastructure, Attacker-Controlled Content

The embedded link pointed to:

hxxps://truenorthtexas-my.sharepoint[.]com/:b:/g/personal/[sender]_truenorth-marine_com/...

This is a SharePoint Online personal site URL. The domain resolves to Microsoft infrastructure. The TLS certificate chains to Microsoft. URL reputation databases rate it clean. Automated scanners that evaluate domain age, registrar, hosting provider, and certificate validity find nothing to flag. The domain is my.sharepoint[.]com, and Microsoft owns it.

The content hosted at that URL is a different story. Any organization with a Microsoft 365 subscription gets a SharePoint Online tenant with a subdomain on my.sharepoint[.]com. The attacker (or the compromised account holder) created or had access to a tenant with the subdomain "truenorthtexas." That tenant hosted the credential-harvesting payload. But from the scanner's perspective, it was a clean Microsoft URL.

Here is the detail that a human reviewer would catch and a scanner would not: the tenant subdomain "truenorthtexas" does not match the sender's company domain pattern "truenorth-marine." It is similar enough to pass a glance. Both start with "truenorth." But a marine services company's SharePoint tenant should logically match its own domain, not reference a different geographic entity. That mismatch is the seam in the attack.

This maps to MITRE ATT&CK T1036.005 (Masquerading: Match Legitimate Name or Location): the tenant name was chosen to be close enough to the sender's legitimate identity to avoid scrutiny while remaining a distinct, attacker-controlled entity.

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

Why the Scanner Saw Nothing

The URL scanner evaluated the SharePoint link and returned a clean verdict. This is not a scanner failure in the traditional sense. The scanner did exactly what it was designed to do: check the domain against blocklists, verify the TLS certificate, assess the URL's reputation. All of those checks passed because the URL is hosted on Microsoft's legitimate infrastructure.

What the scanner did not evaluate: whether the tenant subdomain matched the sender's organizational identity, whether the sender had ever contacted the recipient before, whether the DMARC result was an actual policy evaluation or an inference from a missing record. Those are behavioral and contextual signals. They require analysis that goes beyond domain reputation.

This is the core problem with SEG-only defenses when attackers operate inside trusted platforms. The traditional detection model assumes that malicious infrastructure is distinguishable from legitimate infrastructure at the domain or IP level. When the attacker uses Microsoft's own domain, that assumption breaks.

The attack maps to MITRE ATT&CK T1566.002 (Phishing: Spearphishing Link) for the delivery mechanism and T1586.002 (Compromise Accounts: Email Accounts) for the use of a compromised or purpose-registered M365 tenant to generate the credential-harvesting infrastructure.

What Caught It

Themis, the IRONSCALES Adaptive AI, flagged the message on behavioral signals. First-time external sender with no prior relationship. A SharePoint tenant name that did not align with the sender's domain. A bestguesspass DMARC result indicating no published record. Content patterns consistent with credential-harvesting campaigns observed across the IRONSCALES community.

Authentication said clean. The URL scanner said clean. Behavioral analysis said otherwise.

Indicators of Compromise

MITRE ATT&CK

Defender Takeaways

Treat bestguesspass as a warning, not a pass. A bestguesspass DMARC result means the sender domain has no DMARC record. That is a policy gap, not an authentication success. Flag inbound messages from domains with no DMARC record, especially from first-time senders.

Do not whitelist Microsoft domains for URL inspection. SharePoint, OneDrive, and Forms URLs hosted on my.sharepoint[.]com and similar Microsoft subdomains are actively used as credential-harvesting infrastructure. A clean domain reputation check on a Microsoft URL tells you nothing about the content hosted inside the tenant.

Watch for tenant-domain mismatches. When a SharePoint sharing notification arrives from a sender at one domain but the SharePoint URL uses a different tenant subdomain, that inconsistency is worth investigating. Legitimate file shares typically originate from the sender's own organizational tenant.