The Phish Submitted Inside the Victim's Own Mail Platform

Four mailboxes at a North American cloud communications provider (hosted voice, email and contact-center services) received the same e-signature lure inside a four-second window, and all four copies reached the inbox. The message came from the mailbox of an attorney at a small bankruptcy law practice, sent over a genuine authenticated session with no spoofing anywhere in the chain. What separates this from every other compromised-sender story is where that mailbox lives: the law practice buys its email hosting from the provider that got attacked. The hosted Exchange behind the sender was the victim's own product.

When a customer mailbox is an address inside your platform

An operator with valid credentials signed into the practice's mailbox from a client session at a public address (defanged below) and composed the message there. Because the mailbox is hosted on the provider's shared Exchange environment, the send was a MAPI submission between two mailbox hosts on the provider's own network, entering the provider's mail flow from a private RFC1918 address rather than from the internet edge.

The provider's inbound MTA recorded the submission with an SPF status of internal_ip against a private client address, reverse-DNS validation failing, no DKIM signature and DMARC absent. None of that is a bug. Those are the correct values for a message that originated inside the platform, which is the problem: account takeover of a hosted customer produces mail that is internal by construction.

The control case that rules out routing noise

It would be easy to read that stamp as an artifact of the recipient tenant's complicated reroute. It is not. A genuinely external message into the same tenant, crossing the same provider hop a day earlier, was logged there with reverse-DNS and SPF both passing from a public address. The internal stamp tracks the sender's hosting arrangement, not the path everybody's mail takes.

Every reassuring marker was applied by the target's own stack

From there the provider's infrastructure did each helpful thing in turn. Its Cloudmark-based anti-spam scored the message zero, recorded a clean verdict and filed it under a category reserved for legitimate mail. Its outbound egress address is listed in the law practice's published SPF record, so on arrival at the provider's own Microsoft 365 tenant SPF returned a pass for the sending domain, composite authentication passed and DMARC came back as a best-guess pass. The tenant's link-rewriting service, part of the recipient's own stack, then wrapped the malicious button so the payload arrived behind a security vendor's address, and the platform's URL reputation check called that wrapped link clean.

The sending domain has been registered since 2001 and in all that time has published no DKIM key and no DMARC record. That is the authentication failure that actually matters, and it is permanent rather than momentary: with no signature under RFC 6376 and no policy under RFC 7489, no downstream receiver has any cryptographic way to tell a genuine send from that practice apart from a send by whoever borrowed its credentials. A pass on the SPF check answered a much smaller question, and answered it honestly.

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

What the four recipients actually saw

The rendered message was a blue e-signature panel in DocuSign styling announcing that UnitedHealthcare had sent a document to review and sign, with a yellow REVIEW DOCUMENTS button and body copy explaining that a Medicare beneficiary-notice form had been prepared and was ready for electronic signature. The signature block claimed a beneficiary notifications division. No DocuSign or UnitedHealthcare domain, signing selector or hosted asset appears anywhere in the message; both brands are impersonated in pixels and prose only, a pattern documented as impersonation.

The real destination survives in the anchor's title attribute, which the rewriter copies the original URL into. It points at a dot-prefixed hidden directory and a PHP file on the website of a small plumbing contractor, with a long junk query string appended. That site was registered the previous year, sits on registrar parking nameservers, and carries the payload in a path a site owner would never create. It reads as a compromised web host rather than attacker-registered infrastructure.

The subject line was spliced with 63 zero-width spaces in seven runs of nine, every run intra-word, breaking the brand word in two places and the form number in three while the phrases a human scans for stayed intact. This is a well-worn evasion; the only unusual detail is its distribution. Every one of those characters is in the subject and not one appears in the 100,000-character body, and the hidden preheader nobody renders was mangled with crude literal spaces instead.

Two labels on one message, and delivery anyway

Microsoft prepended an external-sender tag to the subject and, at every hop, scored the message as non-spam with a negative confidence level. The tenant's phishing-banner gateway reached a different conclusion, scoring it above zero, sanitizing the HTML, reporting that a large amount of potentially dangerous content had been removed, and injecting a caution banner that named the sending address and appended the word Internal. It then routed the message to the inbox rather than quarantine, with the call to action live. Elsewhere in this corpus, an external banner sitting beside internal routing has been a thread-hijack tell. Here the verified fact is upstream of the banner and independent of it: the provider's own submission hop recorded this send as internal because the mailbox is hosted on the provider's platform.

The catch was Themis, which scored the message at 88 percent confidence with credential-theft and VIP-recipient labels on language and structure alone, with no human report and no community signal, and mitigated all four copies within seconds of arrival. Three recipients were on the provider's own implementation staff and one was another's manager.

The uncomfortable takeaway for anyone who sells mail

The 2024 Verizon Data Breach Investigations Report puts stolen credentials in 38 percent of breaches as the top initial action and phishing in 15 percent, with the human element a component of 68 percent. Run a hosting platform and those numbers arrive pre-authenticated. Every customer credential is a key to a mailbox inside your perimeter, and the entire trust vocabulary your operations team relies on, internal submission, clean score, SPF pass, rewritten link, describes your own systems being obedient. As CISA phishing guidance and the NIST definition both imply, the question is never where the packet came from but who is driving the session.

Practically: treat hosted-customer submissions as untrusted input rather than internal traffic, and alert on session anomalies inside customer mailboxes the way you would on your own staff, which is the core of account takeover protection. Require signing and a published policy for every domain you host, because a customer with neither is indistinguishable from an attacker the moment credentials leak. Stop treating a link rewriter as a verdict, and revisit any policy that sanitizes a message, warns about it and still delivers it with the button working. Layering behavioural detection over the native controls, rather than trusting a stack of passes, is the point of Microsoft 365 augmentation.

Indicators of Compromise

MITRE ATT&CK mapping