When the SharePoint Notification Is Real But the Share Is the Attack

The DKIM signature failed. But not because the attacker sent a forged message. Because the target organization's own security relay rewrote the links in transit, changing the message body and invalidating the cryptographic hash. By the time the email landed in the inbox, authentication looked like this: SPF pass, DKIM fail, DMARC pass, compauth pass. And a Barracuda ESS spam score of exactly 0.00.

The email got through. What stopped it wasn't authentication. It was behavioral analysis.

The SharePoint Notification With a Corporate Footer That Told the Whole Story

On April 6, 2026, an employee at a regional water authority received what looked like a routine Microsoft SharePoint file-sharing notification. Subject: "Beverly Fithian shared 'DPCSERVICES' with you." Segoe UI font, blue "Open" button, document icon. Standard SharePoint boilerplate.

The footer was the tell.

"This email is generated through Diamond Property Consultants, Inc.'s use of Microsoft 365 and may contain content that is controlled by Diamond Property Consultants, Inc."

This was not a spoofed domain. This was a genuine Microsoft 365 SharePoint notification, generated by Microsoft's infrastructure, from what appears to be an active M365 tenant belonging to a real property services company. The sender domain, dpcservices[.]net, has been registered since 2004. WHOIS shows GoDaddy as registrar, Squarespace name servers (updated November 2025), and registrant details fully redacted.

This is the vendor email compromise scenario that defenders find hardest to catch. If the account was compromised, an attacker with access to a legitimate M365 tenant can use SharePoint's native sharing features to send authentication-clean notifications at scale. The sending infrastructure is Microsoft's. The domain passes SPF. DKIM signs from the legitimate tenant. The email looks exactly like every other SharePoint share your employees receive.

How the Relay Chain Complicated the Picture

The water authority's inbound mail ran through Barracuda Email Security Service (Barracuda ESS). This is a common configuration: an organization routes email through a security relay that scans for malware and spam before delivering to Microsoft 365. Barracuda ESS rewrites links in transit, substituting the original URLs with linkprotect.cudasvc[.]com redirect wrappers.

The problem: DKIM signs the message body at the time of transmission. When Barracuda rewrote the embedded SharePoint links, it modified the HTML body. The body hash recorded in the DKIM signature no longer matched the delivered message. DKIM failed.

The ARC (Authenticated Received Chain) headers tell the full story. At hop i=1, before Barracuda processed the message, Microsoft's infrastructure recorded dkim=pass header.d=dpcservices.net. The signature was intact. At hop i=2, after Barracuda rewrote the links, the ARC seal shows arc=fail and dkim=fail (body hash did not verify). The relay did not forge the message. It modified it. The effect on the DKIM signature was the same either way.

SPF passed because the sending IP (a Microsoft outbound server, 52.101.57.140) was authorized for the domain. DMARC passed because SPF aligned, and the dpcservices[.]net DMARC policy was set to p=none, meaning no enforcement action even if both SPF and DKIM had failed. Compauth returned pass with reason=100.

The Microsoft Digital Defense Report 2024 notes that a significant share of email-based attacks succeed because organizations over-rely on authentication signals that legitimate infrastructure can satisfy. A compauth pass is not a security guarantee. It means the delivery chain looked familiar.

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

What Automated Scanners Scored and What They Missed

Barracuda ESS assigned the message a spam score of 0.00. The only rule triggered was HTML_MESSAGE, the baseline flag for any HTML-formatted email. The links it scanned through its own wrapper came back clean. Verdict: not spam.

The link pointed to hxxps://dpcservices-my.sharepoint[.]com/:o:/g/personal/beverly_dpcservices_net/..., a SharePoint personal site under the dpcservices-my tenant. This could be a genuine file share weaponized as a lure, or an attacker-configured SharePoint page built to harvest credentials. Because Barracuda's scanner returned a clean verdict and no landing page screenshot was captured, the final destination is unconfirmed.

What the scanner did not evaluate: the sender had never contacted anyone at the water authority before. The domain had seven weeks until expiration. The WHOIS registrant was fully redacted. DNS reconfigured to Squarespace name servers in late November 2025, consistent with account takeover preparation or infrastructure retooling ahead of a campaign.

The Verizon 2024 Data Breach Investigations Report notes that phishing remains the most common initial access vector, with pretexts involving file sharing and document collaboration rising sharply. The FBI IC3 2024 Internet Crime Report recorded $2.9 billion in BEC losses, with vendor impersonation and compromised vendor accounts driving a significant share of cases. When attackers use real vendor infrastructure, the authentication layer provides no signal at all.

This attack maps to MITRE ATT&CK T1566.002 (Spearphishing Link): a targeted email containing a link to a malicious or credential-harvesting resource, delivered with contextual relevance to increase the likelihood of a click.

What Caught It

Themis, the IRONSCALES autonomous detection agent, flagged the message at 80% confidence and quarantined it automatically. The signals were behavioral: a first-time external sender with a high risk profile, a file-sharing pretext from a domain with no prior relationship to the organization, and content patterns consistent with VEC campaigns observed across the 35,000-organization IRONSCALES community.

DKIM failed (because the relay broke it). SPF and DMARC passed (because the infrastructure was legitimate). Compauth passed. Spam score: 0.00. Every authentication signal said clean. The behavioral signals said otherwise.

Quarantined within seconds. No employee interaction required.

The Defender's Takeaway on VEC Through Cloud Tenants

Vendor Email Compromise through legitimate cloud infrastructure defeats authentication by design. When an attacker uses a real M365 tenant, SPF, DKIM, and DMARC all pass. DKIM only verifies that the body was not altered after signing, and in this case, the organization's own gateway broke that signal anyway.

Three things worth actioning:

First, compauth pass does not mean the email is benign. It means the sending infrastructure was not obviously forged. VEC abuses legitimate infrastructure precisely because it satisfies authentication checks.

Second, audit what your gateway modifies in transit. Link rewriting, disclaimer injection, and content scanning all alter message bodies after DKIM signing. If your gateway sits inline without ARC sealing, it will break signatures on legitimate mail and phishing alike. The distinction disappears at the authentication layer.

Third, layer behavioral detection over authentication. First-time sender status, pretext analysis, and community-correlated threat intelligence catch what header checks cannot. CISA advisory guidance is consistent on this: authentication is necessary but not sufficient. The IBM 2024 Cost of a Data Breach Report found that AI-augmented detection reduced breach costs by an average of $2.2 million per incident compared to organizations without it.

Indicators of Compromise