The One-Letter Typosquat That Passed Every Authentication Check

The From address was legitimate. SPF passed. DKIM passed. DMARC passed. The email arrived inside an active invoice thread between a manufacturing vendor and its customer's accounts payable team, referencing four real invoice numbers and requesting payment using "updated bank details."

Every authentication gate cleared it. Three enterprise email gateways (Microsoft 365, Barracuda, and Mimecast) processed it without objection. The only thing wrong with the email was a single missing letter in the CC field.

The domain technlform.com (no "i") had been registered 31 days earlier.

One Letter, Four Fake Mailboxes

The attacker's strategy was precise. The From header displayed the real vendor's name and email address on the legitimate domain (registered in 1996). All visible branding, signature blocks, and hyperlinks pointed to the actual vendor's website. The email body referenced a prior conversation about invoice #29659, worth $148,751.40, that the victim's accounts payable team had genuinely been discussing.

But the CC field told a different story. Four addresses appeared on the typosquat domain: accounting@, a Jharrison@, a bharrison@, and a Cfortner@. Each one mirrored a real employee at the legitimate vendor. The names were right. The domain was one keystroke off.

This is what the FBI's Internet Crime Complaint Center calls the most expensive category of cybercrime. BEC and investment fraud accounted for $6.57 billion in reported losses in 2023 alone. Vendor email compromise (VEC), where attackers impersonate a trusted supplier to redirect payments, is the sharpest edge of that blade.

Why the Authentication Stack Said "Clean"

Here is where the attack gets interesting from an infrastructure perspective. The email's DKIM signature was valid for TechniformofTexas.onmicrosoft.com, the vendor's actual Microsoft 365 tenant. SPF passed because the sending IP (on Barracuda's outbound gateway, 209.222.82.149) is an authorized sender for the legitimate domain. ARC seals from Microsoft, Barracuda, and Mimecast all validated cleanly across three relay hops.

The attacker likely had access to the vendor's real M365 tenant. That is the only way to generate a valid DKIM signature from that specific onmicrosoft.com subdomain and send through the vendor's authorized mail path. This is not just domain spoofing. This is account compromise weaponized for invoice fraud.

DMARC's job is to verify that the From domain aligns with SPF and DKIM results. It did. The From domain was real. The authentication infrastructure was real. DMARC had nothing to flag. As the Microsoft Digital Defense Report 2024 notes, BEC attacks increasingly exploit legitimate cloud infrastructure to bypass authentication controls entirely.

The typosquat domain (technlform.com) never appeared in any field that authentication protocols evaluate. It only lived in the CC addresses, where SPF, DKIM, and DMARC do not look.

CC Field Poisoning: The Persistence Mechanism

The CC addresses were not just camouflage. They were the attack's persistence mechanism.

When anyone in the thread hit "Reply All" (the default behavior in most email clients for multi-party business threads), their response would go to both the legitimate recipients and the four attacker-controlled mailboxes. The attacker could then continue the conversation, adjust payment instructions, and answer questions, all while the real vendor remained unaware.

The typosquat domain was registered on February 23, 2026, through Wild West Domains, with MX records pointed at Microsoft 365 name servers (ns1.bdm.microsoftonline.com). This gave the attacker a fully functional mail environment on the lookalike domain in minutes. WHOIS privacy concealed any registrant details.

According to the Verizon 2024 Data Breach Investigations Report, pretexting (which includes BEC invoice fraud) now accounts for more than 40% of social engineering breaches. The IBM Cost of a Data Breach Report 2024 puts the average cost of a BEC compromise at $4.88 million, the highest of any attack vector.

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

The Attachments That Scanners Could Not Read

The email included four PDF attachments (Invoices #30034, #29962, #29904, and #30092) along with an embedded image. Automated sandbox analysis could not extract content from the PDFs. The files returned "clean" verdicts from scanners, but that is because the scanners could not open them, not because they verified the contents were safe.

This is a known evasion technique mapped to MITRE ATT&CK T1036.005 (Masquerading: Match Legitimate Name or Location). The invoice file names matched the numbers referenced in the email body, reinforcing the social engineering pretext. The actual bank routing changes, the entire point of the attack, were embedded in documents that automated analysis could not reach.

How the Attack Was Caught

This email was a first-time message from this sender to the recipient mailbox. That behavioral signal, invisible to authentication protocols, was immediately flagged by the IRONSCALES Adaptive AI engine. Combined with natural language analysis that identified ACH/bank detail change instructions (a high-confidence BEC indicator), the platform escalated the message before any payment could be processed.

A security-aware employee in the accounts payable department also reported the email through the IRONSCALES phishing report button, confirming the AI assessment. Across four affected mailboxes, the message was quarantined. No funds were diverted.

The detection here was not about authentication. It was about behavior. A new sender. Payment-change language. A thread that looked right but came from someone who had never emailed before. That combination is something a community-driven platform with 35,000+ security professionals can pattern-match across organizations. A gateway checking SPF records cannot.

What This Attack Teaches About Invoice Fraud Defense

Verify payment changes out-of-band. Any request to update ACH details, bank accounts, or wire instructions should be confirmed by phone using a number from your vendor master file, never from the email itself.

Audit CC fields on financial threads. Train accounts payable teams to inspect CC addresses character by character on any email involving payment instructions. One-letter domain swaps are designed to survive a quick glance.

Do not trust authentication alone. SPF, DKIM, and DMARC validate infrastructure, not intent. When the attacker controls (or has compromised) the legitimate sending infrastructure, authentication passes by design.

Flag first-time senders on existing threads. If someone appears for the first time in an ongoing financial conversation, that is a high-priority signal regardless of what the headers say. This is the exact pattern that MITRE ATT&CK T1534 (Internal Spearphishing) and T1566.002 (Spearphishing Link) describe in practice.

Indicators of Compromise