The SharePoint Notification That Came From a Tenant Nobody Owns

A SharePoint notification arrived claiming someone had shared a document titled "Remittance." The sending address carried SPF pass, DKIM pass, and DMARC pass. The email traveled through Microsoft's own outbound relay, picked up intact ARC seals, and was delivered to a Google-hosted recipient mailbox without a single authentication failure. The link pointed to a URL under hospitalityruby-my.sharepoint.com, hosted on genuine Microsoft infrastructure.

Everything authenticated. Nothing was what it claimed to be.

Three Mismatches That Authentication Cannot See

The surface looked legitimate because it was legitimate, up to a point. Microsoft SharePoint allows any tenant to send share notifications, and the authentication chain covers the sending infrastructure, not the tenant identity. What this email exposed was a structural gap: authentication verifies the plumbing, not the occupant.

The first mismatch was the tenant name. The SharePoint URL contained the tenant identifier hospitalityruby, corresponding to a tenant registered under the display name "Ruby Hospitality." The email, however, arrived from a domain associated with a performing arts organization, not a hospitality company. These two names share no discernible relationship.

The second mismatch was the owner path. SharePoint personal site URLs encode the file owner's email address in the path segment (in the form /personal/username_domain_com). The owner path in this URL mapped back to the sending domain, meaning the file was attributed to an account at that domain but hosted under a tenant branded as a completely different business. An unregistered domain was embedded in this path, meaning the hosting organization did not exist as a registered entity.

The third signal was sender history. The sending address had no prior relationship with the recipient organization. This was a first-time sender contacting a financial or operations contact with a document labeled "Remittance," one of the highest-risk lure keywords in phishing campaigns targeting accounts payable workflows.

Why Microsoft Infrastructure Makes This Hard to Block

The email routing tells the story. The message originated from eastus2r-notifyp.svc.ms, a genuine Microsoft notification infrastructure host in the East US 2 Azure region. It routed through Microsoft's outbound protection layer before arriving at the recipient's Google Workspace environment. The ARC chain was intact. Every hop was a Microsoft or Google IP with verified reputation.

This is the core challenge of email spoofing attacks built on hyperscaler infrastructure. When the sending platform is Microsoft, blocking by IP or domain would mean blocking all SharePoint notifications globally. Gateways that evaluate trust by sender reputation alone have no viable path to detection: the reputation is real because the infrastructure is real.

The SharePoint share template used here was pixel-accurate to a genuine notification. No credential prompt appeared in the body text. The lure relied entirely on the recipient clicking through to a SharePoint-hosted document, where any redirect or embedded payload would be hosted one step removed from the delivery mechanism.

The Tenant Registration Surface

What this attack demonstrates is that Microsoft's tenant registration system is effectively an open credential factory for phishing infrastructure. Creating a Microsoft 365 tenant requires a payment method and an email address. There is no domain verification requirement that ties the tenant name to the sender domain. An attacker can register "Ruby Hospitality" as a tenant, add the owner account from an unrelated domain, and immediately produce SharePoint notifications that carry full Microsoft authentication.

The unregistered hosting domain embedded in the owner path is a particularly telling detail. The attacker registered a tenant, associated it with a domain that was never actually registered as a functional web presence, and used that combination to generate authenticated share notifications. The tenant exists. The domain behind it does not. Authentication sees the tenant; nothing verifies whether the owner domain is real or operated by the claimed organization.

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

Behavioral Detection Where Authentication Ends

Themis, the Adaptive AI engine from IRONSCALES, flagged this message before any recipient could interact with it. The detection was not based on a known-bad domain or a malicious URL signature. It was based on the behavioral and structural anomalies that authentication cannot surface: tenant name inconsistency with the sending domain, owner path pointing to an unregistered domain, a high-risk keyword ("Remittance") in the document title, and a first-time sender relationship.

No prior interaction between this sending address and the recipient organization existed in the relationship model. The combination of a clean authentication chain with a mismatched tenant identity and a financial lure keyword is a pattern that appears consistently in Microsoft infrastructure abuse campaigns, and one that pure authentication-based filtering is structurally blind to.

Organizations that process remittances or handle vendor payments should treat any SharePoint notification from an unknown sender as requiring out-of-band verification, regardless of how clean the authentication headers look.

Indicators of Compromise

MITRE ATT&CK Mapping