The Forward That Was Typed, Not Forwarded

A sales account manager at a promotional products distribution company opened a short message about an unpaid bill. The subject line read [External Email] lNV #3483920. The display name belonged to a senior executive at the company, someone whose approval on a payment question would end most internal debate. The address behind that display name was a consumer Gmail account with no relationship to the executive, the company, or anyone in the thread.

Two things in that message were built to be read by a person and misread by a machine: one letter typed wrong on purpose in the invoice reference, and a block of plain text below the request arranged to look like a forwarded message that had never been forwarded. Together they are the whole case, because there was no malware, no link, and no compromised infrastructure to trace.

The invoice abbreviation with no capital I in it

Look at the subject again: lNV #3483920. The first character is not a capital I. It is a lowercase L.

In the sans-serif faces that Outlook, Gmail, and effectively every other mail client use for message lists, a lowercase L and a capital I are drawn as the same unadorned vertical stroke. A reader scanning a subject line sees the three letters they expect, reads the abbreviation for invoice, and moves on. Nothing looks wrong because nothing looks like anything at all.

A filter does not see strokes. It compares character codes, and those two characters are simply not the same character. Any rule watching for the string INV, any keyword list containing invoice, any regular expression built to catch billing-themed subject lines from unfamiliar senders, all of it slides straight past. The word that would have triggered the rule was never written.

The attacker used the substitution twice, which is what makes it deliberate rather than a typing accident. It appears in the subject, and it appears again inside the body, where the request reads as a quick reminder that lNV. 00#3483920 is still outstanding. Two placements, both at the exact points where a text-matching control would look. This is masquerading applied one character at a time.

The same trick works downstream. Optical character recognition resolves the stroke to whichever letter its model favors, so an image-based inspection path can return the wrong spelling too.

A forwarded message with nothing underneath it

Below the request sat what appeared to be a forwarded email. There was a From line naming an accounts receivable contact at an outside consultancy address, a Sent line with a weekday and a time, a To line pointing at the executive whose name was on the outer message, and a Subject line repeating the misspelled invoice reference.

None of it was a forwarded message. It was plain text, typed into the body, arranged to look like message headers.

A genuine forward carries the original as structured content. Your client knows it is there, renders it as its own block, lets you expand it, and resolves the addresses inside it against your directory. This message had none of that. Strip the visual arrangement away and the header lines are sentences in the same font, color, and size as the paragraph above them, with nothing behind them to click, expand, or verify. The Sent line was set to a Friday morning some weeks earlier, far enough back to imply a bill that had already been chased once.

The purpose of that block is not to deceive a scanner. It is to answer the recipient's first objection before she raises it. Is this a cold request? No, look, it was already sent to the executive. Has anyone else touched this? Yes, he forwarded it to you. Is there a history here? The timestamp says weeks. The fabricated paper trail manufactures the authority that the attacker cannot otherwise borrow, and it costs nothing to type. That combination, impersonation of a real internal figure plus an invented record of prior discussion, is the load-bearing structure of most business email compromise that succeeds without a single stolen credential.

Why authentication had nothing useful to say

The headers were clean, and honestly so. SPF passed. DKIM passed, signed by the consumer mail provider. DMARC passed. Microsoft composite authentication returned a pass with its strongest reason code.

There was no spoofing to detect. Somebody genuinely opened a free mailbox at a major provider and genuinely sent mail through it, so the provider genuinely signed it. Authentication resolves one question, whether the domain in the From header authorized the message, and here the answer was a truthful yes. It has no mechanism for noticing that the display name attached to that authorized account belongs to an executive at an unrelated company.

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

Two attachments, both clean, both furniture

The message carried two PDFs: an invoice matching the misspelled reference, and a completed tax form for the same fabricated outside organization. Both scanned clean. No macros, no embedded scripts, no active content of any kind.

That pairing is deliberate. An accounts payable team creating a new payee record wants exactly those two documents, so supplying both makes the request feel procedurally finished and shifts the conversation from whether to pay toward where to send the funds. Classified as a spearphishing attachment in service of financial theft, the documents were props rather than payload, which is precisely why an attachment sandbox had nothing to report.

What actually resolved it

Detection came from relationship history, not content. The display name on the message had been seen before on this tenant, arriving from the executive's real internal address. This instance carried the same display name from a consumer Gmail account, and that mismatch between a known identity and an unknown sender was scored as impersonation at 84% confidence. The incident was automatically resolved as phishing across the affected mailboxes, part of a small wave that had also probed the tenant weeks earlier.

Nothing in the envelope produced that outcome. It came from modelling who normally writes to whom, which is the work adaptive AI email security has to do when the protocol layer is genuinely clean, and why business email compromise protection has to reason about identity and conversation rather than grading headers.

The economics favour this shape of attack. The 2024 Verizon Data Breach Investigations Report names pretexting, largely business email compromise, as the leading social-engineering type and puts the median transaction around $50,000, while reported losses from the category ran to roughly $2.9 billion in the FBI Internet Crime Report for 2023. No exploit, no infrastructure, no payload. Two documents, one borrowed name, and one letter typed wrong on purpose. Both CISA phishing guidance and the NIST definition of phishing land on out-of-band verification as the control that holds, which is the one step this message was shaped to make feel redundant.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Friday

The clever part of this one is how cheap it was. No kit, no redirect chain, no compromised mail estate. An attacker opened a free mailbox, typed four lines of fake headers, attached two harmless documents, and pressed one key wrong twice. Everything that made it dangerous lived in the gap between what a person reads and what a filter matches. Close that gap the old way: if a bill arrives with an executive's name on it, verify through a route the message did not supply, and read the header block closely enough to notice it cannot be expanded.