Blue Team of One field notes · security

Home›Email Security›Inbound security

Inbound security · phishing

When the sender is real and the email still isn't

A phishing wave that arrived from a genuine, trusted client mailbox — so it passed every authentication check — then laundered its reputation through a legitimate SaaS host on the way to a fake Microsoft login. Sender trust is not email trust, and this is why.

Ram Mudigina August 13, 2026 ~8 min read

Several users reported a "secure document" email on the same morning. What made it dangerous wasn't the lure — it was the From line. The messages came from a real, known contact at a legitimate client vendor: a mailbox these users had corresponded with for years. It passed SPF, DKIM, and DMARC cleanly, because it wasn't spoofed. The vendor's mailbox had been compromised, and the phishing was being sent from inside it.

That's the whole problem in one sentence: authentication proves the message came from that mailbox — not that the mailbox is trustworthy today. Every control that checks "is this really the sender?" answered yes, correctly, and the phish sailed through.

01The lure

A fake "secure message" wrapper — the most trusted-looking template there is.

The email impersonated a secure-message / encrypted-document notification — the kind of "you have received a protected file, click to view" wrapper that legitimate encryption gateways genuinely use. It carried a blurred thumbnail of a "secured PDF," a time-pressure expiry line, and a single call-to-action button. Two waves went out with two different subject lines but an identical body and payload link — a classic attempt to slip past subject-based blocking while keeping the same trap underneath.

02The redirect chain

Legitimate services used as stepping stones to launder reputation.

Compromised vendor mailbox real sender · auth passes "Secure msg" email · user clicks time-pressure lure Legit SaaS host clean reputation, redirects onward Fake M365 sign-in on a compromised domain → harvests credentials Each hop looks more legitimate than the last — trusted sender, then trusted SaaS domain, and only the final page is obviously malicious, by which point the user has committed.
Reputation laundering. The link in the email didn't point at the credential harvester directly — it pointed at a legitimate presentation/hosting SaaS with a clean reputation, which then forwarded to the fake login. Each hop borrows trust from a real service so no single URL trips a reputation filter.

This staging is the craft of the attack. A link straight to a sketchy domain gets caught by URL reputation. But a link to a well-known SaaS presentation host is clean — so that's what's in the email. That host redirects to the fake Microsoft 365 sign-in page (itself hosted on some other compromised legitimate domain), which is where credentials actually get harvested. The malicious destination is two hops removed from anything a filter scores on delivery.

03Why it got through — and why that's expected

Every control did its job. The trust model was the gap.

ControlWhat it checkedWhy it passed the phish
SPF / DKIM / DMARCDid this come from the real sender?Yes — sent from the genuine (compromised) mailbox
Sender reputationIs this a known-good correspondent?Yes — years of legitimate history with them
URL reputationIs the linked domain malicious?No — the link pointed at a legitimate SaaS host
Attachment scanningIs there a malicious file?No file — just a link to a "document"

The uncomfortable takeaway

You cannot filter your way out of this one on the delivery path alone. When a trusted partner's mailbox is compromised, the email is authentically from them and the links are authentically clean SaaS domains. The defenses that catch it are the ones that don't rely on the sender being bad: user reporting, time-of-click URL detonation, and impossible-travel/anomaly detection on the accounts that submit credentials.

04Response — scope the blast, then purge it

One reported click means many delivered. Find them all first.

The mistake is to remediate only the user who reported. With two subject lines and multiple recipients, the job is to establish the full footprint before purging, so nothing is missed:

# 1. scope — search the mail-security console for BOTH subjects and the payload URL
- identify every recipient across both waves
- record the exact message count and recipient list

# 2. purge from every mailbox (soft-delete first, then hard-delete)
#    Purview eDiscovery / mail-flow tooling:
New-ComplianceSearch -Name "Phish-Purge" -ExchangeLocation All `
  -ContentMatchQuery '(subject:"<subject A>" OR subject:"<subject B>")'
Start-ComplianceSearch -Identity "Phish-Purge"
New-ComplianceSearchAction -SearchName "Phish-Purge" -Purge -PurgeType HardDelete

# 3. report the sender/URLs to Microsoft as phishing; block IOC domains (TABL)
# 4. for anyone who CLICKED: full account + endpoint hygiene
-  password reset · revoke sessions · review MFA methods
-  audit mailbox for inbox rules / forwarding · endpoint health check

Then close the loop with the vendor: their mailbox is the source, so they need to know it's compromised — the same wave is almost certainly hitting their other contacts too.

The lesson

Authentication tells you a message is from a sender, never that the sender is safe — a compromised partner mailbox passes every check you own. Multi-stage phishing launders reputation through legitimate SaaS so no single URL looks bad on delivery. Defend on the axes that don't assume a bad sender (reporting, time-of-click, anomaly detection), and when one lands, scope the whole blast before you purge and warn the vendor whose mailbox is spraying it.

Further reading

This write-up is anonymized from a real incident; the sender, vendor, URLs, and subjects have been changed or defanged.

Comments

Questions or corrections welcome. Sign in with GitHub to join the thread.