The Signature Block Was Real. One Link in It Was Not.

The reply landed in a conversation that had been running for weeks. Same subject line, same RE: prefix it had carried since late July, same cost write-off spreadsheets going back and forth between an outsourced-accounting manager at a regional accounting and business advisory firm and a partner at the outside law firm she worked with. The attachment was another spreadsheet of exactly the kind she had been receiving. Every authentication check on the message passed. All of that was genuine, because the email really did originate from that law firm's own Microsoft 365 tenant.

Exactly one element of the message had been altered. In the sender's email signature, on the line where the firm's website address belongs, the hyperlink pointed at a domain that had nothing to do with the firm.

The Control Copy Was Sitting in the Same Email

Signature-block tampering is normally hard to prove from a single message. You need to know what the sender's real footer looks like, which means going back through old mail or checking the firm's site. This case did not require either, because the evidence was already in the email.

Reply chains quote themselves. Beneath the newest message sat the sender's own reply from a couple of weeks earlier in that same thread, and that quoted copy carried its own copy of the same signature block. The two were identical in every element: same name, same title, same street address, same phone and fax numbers, same confidentiality disclaimer, same layout. They differed in exactly one thing. The older, legitimate copy still pointed at the firm's real website. The newest copy pointed at hxxps://ohiotiger[.]com/.

That is a closed proof. Whatever introduced the difference did so when the newest message was composed, and the recipient could establish it without leaving her inbox. It is also the reason this case is worth a teardown: the tell is not a subtle stylistic drift or a one-digit phone discrepancy, it is a single substituted link with its own unaltered original sitting a few inches below it on screen.

Nothing Was Spoofed, So Nothing Failed Authentication

The header analysis is short, which is the point. At the authoritative final hop, SPF passed on the sending address, DKIM passed with a cryptographically verified signature aligned to the law firm's own domain, DMARC passed, the full ARC chain verified across both seals, and Microsoft's composite authentication returned compauth=pass reason=100. The domain itself had been registered in 1998, twenty-eight years of clean sending history behind it.

Two details deserve care. First, the DMARC pass was against a p=none policy with sp=none, so this was not an enforced reject posture doing heavy lifting, it was simply a correctly aligned message evaluating cleanly under the current DMARC specification. Second, an intermediate header added earlier in the recipient's own cross-tenant routing showed dkim=none and dmarc=none. That is a well-known artifact of multi-hop Microsoft 365 relaying, not a contradiction and not a detection signal. Reading it as one would have sent an analyst chasing the wrong thing.

None of this is a control failure. It is authentication working correctly and telling the truth about a message whose sender was no longer the account's rightful owner. That gap is the whole of vendor email compromise. For scale on the surrounding problem, the 2026 Verizon Data Breach Investigations Report reports that credentials feature in 39% of breaches across the kill chain, and that phishing accounts for 16% of initial access. Once the credential is spent and the mailbox is in hand, the attacker inherits every trust signal the account had accumulated. MITRE tracks the acquisition step as compromise of email accounts precisely because it is preparation, not the attack itself.

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

The Clean Attachment Was Cover, Not Payload

The reply carried a spreadsheet, roughly 43 KB, named for the fiscal year under discussion. It scanned clean and it was clean. There were no macros to strip, no embedded objects, no remote template reference, nothing for a sandbox to detonate.

That is a deliberate choice, and it is worth naming because attachment-centric review habits misread it. A genuine business document does two things for the attacker. It satisfies the recipient's expectation that a reply in this thread would contain a file, and it consumes the reviewer's attention. Analysts and automated pipelines alike gravitate to the attachment, find it benign, and lower the weighting on everything else in the message. The malicious element was never in the file. It was in the footer, which is the part of an email almost nobody inspects on the fortieth message of a relationship.

Where the Link Went, and Where the Trail Stops

The substituted domain resolved to a page serving a Cloudflare security-verification challenge, the standard "verify you are human" interstitial. Our platform recorded a malicious verdict on the link, and a live capture of the page confirmed the challenge screen.

What sat behind that challenge was not recovered, and it should not be guessed at. An interactive gate is an inspection barrier by design: automated crawlers and URL sandboxes cannot complete the challenge, so they capture a benign holding page and score it accordingly, while a human recipient clicks through in a second and never registers the step. Any claim about the final content, whether a credential form, a paste-and-run instruction page or a downloader, would be invention.

What the record does support is thinner and more useful. The domain was registered in 2010, its registrant details were privacy-shielded, and its nameservers were on Cloudflare. Whether it was acquired by the attacker as an aged asset or is itself a separately compromised legitimate site is not established. The screener's original guess at a named malware family did not survive verification either, which is the correct outcome. Describe the interstitial, record the verdict, and stop there.

What Actually Caught It

Sender reputation contributed nothing here. Authentication contributed nothing. The attachment contributed nothing. Every conventional signal pointed the same direction, which was the wrong one.

The malicious verdict on the link is what carried the detection, and Themis scored the message at 90% confidence. The mailbox was quarantined, and three earlier messages from the same sender pattern in the same thread history were pulled with it, all mitigated together. That last part matters more than the single catch. When a counterparty's mailbox is compromised, the exposed asset is the correspondence relationship, not one email, and the response has to cover the thread rather than the message. Protecting against that requires treating an established sender's mail as inspectable rather than exempt, which is the operating premise of account takeover protection at the mailbox layer.

For teams building playbooks around this pattern, both CISA's phishing guidance and the NIST definition of phishing frame the problem around induced trust rather than technical defect, which is exactly the shape of this case. Add one habit to the list: when a reply in a long thread contains anything actionable, compare its signature block against the copies quoted below it. The attacker in this case left the answer in the message.

Indicators of Compromise

MITRE ATT&CK Mapping