The Email Thread That Never Happened

The message that arrived in an accounts-payable mailbox at a national IT and professional staffing firm did not read like a first contact. It read like the last reply in a conversation everybody else had already finished. Subject line: [EXTERNAL]_Overdue Invoice INV0214 - Please Advise. Below the sender's short, faintly impatient note about an invoice more than a month past due, the message trailed off into two quoted replies, stacked the way a real thread looks after a couple of weeks of back and forth.

The first quoted reply was attributed to the firm's own accounts-payable contact, telling the vendor to send the paperwork straight to the internal accounts-payable alias where somebody would handle it. The second, quoted underneath, was attributed by name to an executive at a real and reasonably well-known IT consultancy, confirming the implementation scope and noting the invoice would follow shortly.

Three parties. Three companies. A tidy chain of internal approval and external confirmation sitting right there in the body, requiring nothing from the reader but the last small step of returning the attached forms.

None of it happened. No thread, no replies. One HTML email, composed by one person, sent once from one mailbox.

Three voices, one sender

This is simpler than it looks. Quoted reply text is not a protocol feature, it is characters in an HTML body. When a mail client renders an indented block with a "From" line above it and a date beside it, nothing has been verified. No server signed it, no standard checked it. The visual grammar of a reply chain is a convention your client draws for you, and an attacker with a text editor can draw it too.

So the attacker wrote the whole cast. The vendor persona chasing payment was invented. So was the internal approval, which is the audacious move, because it planted a forged endorsement from the recipient's own colleague as social proof for a request that colleague never saw. The consultancy executive's confirmation was invented too, borrowing a real company's credibility to make the engagement sound like a done deal.

Each fabricated voice removed a question a finance team would normally ask. Who are you? The vendor thread answers that. Are we working with them? The executive confirms it. Am I supposed to handle this? Your own colleague already said so. By the time a reader reaches the attachments, the message has pre-answered every objection using testimony it manufactured itself. That is impersonation as infrastructure, and it maps to MITRE ATT&CK T1656, Impersonation.

The paperwork was the point

The two attachments were the reason for all of it, and neither was malware: ordinary PDFs, roughly 36KB and 180KB, both scanning clean.

The larger one was an invoice, the pretext. The smaller one was the payload: a fillable W-9, generated programmatically rather than scanned, with live AcroForm fields waiting for a legal name, a business address, and a taxpayer identification number. No JavaScript. No embedded files. Nothing for a sandbox to detonate or a content disarm engine to strip. A W-9 is not an exploit, it is stationery.

Once completed and returned, it is identity-grade data. A taxpayer identification number is frequently a Social Security number when the filer is a sole proprietor, and paired with a verified legal name and address it opens the door to tax-refund fraud, credit opened in the business name, and a far more convincing fake vendor next time. Better still for the attacker, exchanging a W-9 is a normal step in vendor onboarding, so the request does not feel like an attack because in almost every other context it is not one. Filed under T1566.001, spearphishing attachment, it was a document nobody had a technical reason to block.

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

What the authentication actually proved

Here is the header story, and it is clean. SPF passed. DKIM passed, signed by the sending domain. DMARC passed, under a policy set to no enforcement. Composite authentication passed with the strongest reason code available.

The sending domain was nifty[.]com, a longstanding Japanese internet service provider, connecting from 106[.]153[.]227[.]42 through its own outbound infrastructure straight into Microsoft 365 with no security gateway in the path. That result is genuine, and the ISP is a bystander: the mailbox behind it was either compromised or attacker-registered on a legitimate service (T1586.002), which is why inbound account takeover detection is a separate discipline from authentication.

What those checks proved is narrow: a real mailbox at a real provider sent this message. They proved nothing about the three humans quoted inside it. The Reply-To made the gap visible, pointing at alan[.]martin@sonercantemizlik[.]com, a separately registered Turkish domain with privacy-masked ownership records and no relationship to the consultancy named in the signature block. The authenticated domain, the reply domain, and the claimed company were three different entities, and DMARC, as specified in RFC 7489, was never designed to notice that.

The filter that disagreed with the envelope

The strange part is that Microsoft's own content scoring was not fooled. The same headers that recorded a clean DMARC pass also carried a spam confidence level of 9, a high-confidence phishing category, and a safety score of 9.25. Authentication said trusted; content analysis said the opposite, loudly, on the same message.

And it still reached a person. One mailbox, one judgment call about a thread carrying a forged approval from a colleague and a stack of clean PDFs. Our Adaptive AI put the message at 50% confidence, the honest score for mail whose envelope is beyond reproach and whose deception lives entirely in invented prose. Fifty percent is not a verdict, it is an invitation to look. The close came from a human: reported through the IRONSCALES community, manually confirmed as malicious, quarantined the same day it arrived.

That division of labor is the lesson. Machine scoring narrowed the volume down to what deserved attention, and a person supplied the check no header can encode: knowing a colleague never wrote that reply. Fraud that rides on manufactured trust rather than malicious code is why business email compromise protection has to model relationships and conversation history, not just envelopes. The 2024 Verizon Data Breach Investigations Report names pretexting, the family this belongs to, as the year's leading social-engineering type and puts the median business email compromise transaction near $50,000, while the 2023 FBI IC3 Internet Crime Report attributes roughly $2.9 billion in reported losses to the category. CISA's phishing guidance on stopping the attack cycle treats verification outside the message as the control that holds, which is exactly what this attack was built to skip.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Friday

The cheapest thing to forge in email is a conversation. Indentation, quoted headers, the whole visual apparatus of a thread is decoration your mail client renders on request, and none of it survives one question: is this reply in my own sent folder? When a message arrives carrying its own permission slip, especially one signed by somebody down the hall, that convenience is the attack. Verify the approval, not the formatting, and never let a tax form leave the building on the strength of a quoted block.