A Hijacked 20-Year-Old Mailbox Delivers a Document Lure

The message that landed in a Canadian industrial-supply distributor's quotes and submissions inbox looked, on paper, like the most boring email of the day. A document waiting for review. A short, polite note. A PDF attached. And it came from a mailbox that had been quietly sending business email for nearly twenty years, riding legitimate hosted Exchange infrastructure. Nothing about the sending path screamed attack. That was the point.

Underneath the ordinary surface, the account behind that decades-old construction company mailbox had been taken over. The attacker was not spoofing the domain from the outside. They were logged in and sending as the real account, which is why the email carried the one thing most crude phishing lacks: a clean-looking origin.

An authentication story with almost nothing to authenticate

The technical signals here are less about what failed and more about what was never there to check.

SPF passed. The message left a legitimate hosted-Exchange relay (64[.]78[.]26[.]103, ServerData infrastructure) that the domain genuinely authorizes, so the path check cleared cleanly. But the domain published no DKIM signature at all, and it published no DMARC record, which meant the receiver could only fall back to a best-guess pass with no alignment policy to enforce and no reporting stream to surface abuse. Composite authentication landed on a heuristic pass (reason 109).

In other words, the domain offered defenders one usable authentication signal, SPF, and that signal was working exactly as designed while the account behind it was in the wrong hands. SPF confirms the sending path is allowed for the domain. It cannot tell you the human at the keyboard is not the account's real owner.

There was one quiet tell in the headers. The originating IP address (185[.]121[.]176[.]151) had no PTR record and did not resemble the domain's normal internal submission pattern, which is consistent with an outside operator reaching in through a hijacked login rather than the account owner sending from their usual environment. On its own, though, that is a whisper, not an alarm.

The 2024 Verizon Data Breach Investigations Report puts numbers behind why this shape of attack keeps working. Stolen credentials were the single most common way in, involved in 38% of breaches, and the human element figured into 68% of them. A hijacked, well-aged mailbox is that statistic operationalized: valid credentials turned into trusted-looking delivery infrastructure.

The lure was engineered to feel personal

The subject line did something small and effective. It referenced the recipient distributor's own company name, paired with a random reference token (935k9mvq4dxw3gv), so the note read like it belonged to an existing thread or a specific submission rather than a cold blast. Name-dropping the target is a cheap way to buy a second of trust from someone who processes dozens of vendor documents a day.

The body itself was deliberately thin: a generic request to review the attached document, which arrived as an unopened PDF (roughly 146 KB, AV-scanned clean at delivery). We are not going to claim what sat inside that file, because it was never independently detonated, and inventing a payload would be its own kind of dishonesty. The interesting move was elsewhere.

Real Microsoft links, used as camouflage

Woven into the message were legitimate, benign Microsoft anti-phishing help-page links, the "how to recognize a phishing email" style education pages. They were not the attack. They were the disguise. Real links to a trusted brand raise a message's apparent legitimacy, and they can push naive content scanners toward a clean verdict by loading the email with reputable destinations. It is the phishing equivalent of a forged document wrapped in genuine letterhead. The reputation padding does the talking while the actual ask hides in the attachment.

This is the pattern that pure gateway logic tends to miss. Authentication was as clean as this domain could produce, the links resolved to a household-name security vendor, and the attachment scanned clean. Every individual box a legacy filter checks came back green.

What actually flagged it

Our Adaptive AI analyst, Themis, called this one at 90% confidence with a Credential Theft label, and it did so on the mismatch rather than any single failed check. The message authenticated as an unrelated construction company while the subject line referenced the distributor's own name, the sender had no prior relationship with the recipient (a first-time-sender signal), and the body leaned on benign brand links as cover. Put those signals together and the story stops being "a vendor sent us a document" and starts being "an unknown account is impersonating relevance."

That is the core lesson for account takeover defense. When an attacker sends from a real, hijacked mailbox on an aged domain, authentication is not the tripwire, because the mail really is coming from where it says. The tripwire has to be relationship and behavior: does this sender have a history with us, does the claimed context match the sending identity, and is the message doing anything (like padding itself with unrelated trusted links) that a genuine correspondent never would.

CISA's guidance on stopping the phishing attack cycle makes the same point from the defender's side: recognizing the social pretext matters as much as blocking the infrastructure, because increasingly there is no attacker-owned infrastructure to block. Here, the hijacked legitimate domain was the delivery infrastructure.

Indicators of compromise

MITRE ATT&CK mapping

• T1586.002 (Compromise Accounts: Email Accounts): the attacker operated a real, hijacked mailbox on a legitimately aged domain rather than registering their own.
• T1566.001 (Phishing: Spearphishing Attachment): a document-review PDF lure, personalized with the target's name and padded with benign trusted-brand links.

The takeaway is uncomfortable but clarifying. As more attacks route through genuine, compromised accounts on domains with decades of history, the absence of attacker infrastructure to block is the norm, not the exception. Detection has to move to identity and behavior. If you want to see how that behavioral layer catches the mailbox that authenticates perfectly but has no business emailing you, request a demo.