The email looked like it belonged. It landed in the inbox of a project engineer at a mid-size energy technology company, threaded neatly into a real accounts payable conversation about invoice #29659 for $148,751.40. The sender's name matched. The FROM address matched. SPF passed. DKIM passed. The message referenced real invoices, real people, real dollar amounts.
It was fraudulent. Every word of it.
See a live demo of how IRONSCALES catches attacks that pass authentication: Book a demo
The attack arrived as a reply to an existing thread between the energy company and a precision manufacturing vendor they regularly do business with. The FROM address belonged to the vendor's sales representative at the real vendor domain. Email authentication confirmed it. To anyone scanning their inbox, this was just another follow-up on outstanding invoices.
But buried in the CC line were four addresses that told a different story: Jharrison@technlform[.]com, accounting@technlform[.]com, bharrison@technlform[.]com, Cfortner@technlform[.]com.
Catch it? The real vendor domain uses an "i" in the name. The CC addresses drop that letter entirely. The typosquat domain technlform[.]com was registered in February 2026, weeks before the attack, specifically to support this operation.
This is the anatomy of a vendor email compromise (VEC) attack, and it represents one of the most dangerous evolutions in business email compromise that security teams face today. According to the FBI's 2024 Internet Crime Report, BEC attacks accounted for over $2.9 billion in reported losses, with vendor impersonation and invoice manipulation driving the highest per-incident losses. Abnormal Security's H1 2025 threat report found VEC attacks increased 137% year-over-year, with the average requested amount exceeding $128,000.
The attacker didn't start from scratch. They threaded their message on top of legitimate correspondence between the energy company's AP department and the manufacturing vendor. Earlier messages in the chain were real, exchanged between real employees about real invoices.
This technique, mapped to MITRE ATT&CK T1534 (Internal Spearphishing), exploits a fundamental human behavior: we trust conversations we're already part of. When a reply lands in an existing thread, we skip the mental checks we'd apply to a cold email from an unknown sender. Research from Osterman Research (2025) confirms that thread hijack attacks have a click-through rate roughly five times higher than standard phishing because recipients process them as continuations of trusted exchanges.
The forwarded portion of the message appeared to come from the vendor's accounting manager, using accounting@technlform[.]com. That's the typosquat domain again, but it's buried in a quoted block below the main message body, the part of an email most people never read carefully.
On top of that real conversation history, the attacker placed their payload: four invoice PDFs (Invoice 30092.pdf, Invoice 29904.pdf, Invoice 30034.pdf, Invoice 29962.pdf) and a clear, professional instruction to update bank details for all future payments.
Curious how many phishing emails your SEG is missing right now? Calculate your exposure
Here's what makes this attack particularly vicious: the FROM address passed SPF and DKIM for the legitimate vendor domain. ARC checks passed. From a technical authentication standpoint, this email was clean.
How? The FROM address used the real vendor domain. Whether the vendor's account was compromised or the attacker spoofed it in a way that aligned with the vendor's SPF records, the result was the same: authentication checks gave this email a green light. DMARC's design validates the FROM domain, and the FROM domain here was legitimate.
The typosquat lived only in the CC fields and the forwarded message block. Most secure email gateways evaluate the FROM domain and envelope sender for authentication. CC addresses? They're passengers, not drivers, in the authentication model. The email traversed Microsoft, Barracuda (209[.]222[.]82[.]149), Mimecast, and Google infrastructure before reaching the target. None of them stopped it.
This maps to MITRE ATT&CK T1036 (Masquerading) and T1566.001 (Spearphishing Attachment). The attacker masqueraded as the legitimate vendor while delivering invoice attachments designed to redirect payment flows.
According to Agari's analysis of BEC campaigns, 68% of successful vendor impersonation attacks use domains that pass standard email authentication. The attackers aren't bypassing your email security. They're working within its rules.
The attack reached four mailboxes at the energy company. The message was a first-time send to the primary recipient, a subtle signal, but not one that jumps out when the rest of the email looks perfectly routine.
IRONSCALES Themis flagged a suspicious link in the message body (a "click here" link pointing to YouTube, likely included to add legitimacy or test link-scanning behavior). But the real save came from an employee who recognized something was off and reported the email through IRONSCALES' in-mailbox reporting. That report triggered a manual review, and the phishing was confirmed.
Without that report, the likely outcome was straightforward: the AP team would have processed four invoices totaling well into six figures using the attacker's bank details. Once ACH payments clear (typically within 1-3 business days), recovery is nearly impossible. The Association for Financial Professionals' 2024 Payments Fraud Survey found that only 30% of organizations that fell victim to BEC-driven payment fraud recovered any of the stolen funds.
This is exactly why Adaptive AI combined with trained reporters changes the equation. Technology catches signals. People catch context. Together, they stop attacks that either one would miss alone.
Start protecting your organization with AI-powered email security: Try IRONSCALES free
This wasn't a lazy phish. The attacker researched the vendor relationship, obtained (or fabricated) real invoice context, registered a lookalike domain weeks in advance, and constructed a message that passed every automated authentication check. Here's what defenders should take from it.
Audit your CC fields, not just the FROM. Most recipients and most email security tools focus on the sender address. This attack hid the typosquat exclusively in CC addresses and forwarded message blocks. Train AP and finance teams to check every address in the header, not just the one that appears in the "From" line.
Treat bank detail changes as high-risk events. Any email requesting updated payment information should trigger an out-of-band verification process. Call the vendor using a known phone number (not one from the email). Confirm the change with a contact you've spoken to before. This single control would have stopped this attack cold.
Monitor for typosquat registrations. The domain technlform[.]com was registered in February 2026, weeks before the attack. Domain monitoring services can alert you when lookalike domains appear. That early warning can be the difference between preparation and incident response.
Don't trust authentication alone. SPF pass, DKIM pass, ARC pass. This email cleared every technical gate. Authentication tells you a domain is who it claims to be. It doesn't tell you whether the person sending from that domain is legitimate, or whether the CC addresses are safe.
Build a reporting culture. This attack was stopped because one employee reported it. Not because a filter caught it. Not because a rule blocked it. A person looked at the email, felt something was wrong, and clicked the report button. That instinct, reinforced by training and made frictionless by in-mailbox reporting tools, is the control that matters most when everything else passes.
| Type | Value | Context |
|---|---|---|
| Domain | technlform[.]com | Typosquat of legitimate vendor domain, registered February 2026 |
| Jharrison@technlform[.]com | CC address on typosquat domain | |
| accounting@technlform[.]com | Used in forwarded message block, typosquat domain | |
| bharrison@technlform[.]com | CC address on typosquat domain | |
| Cfortner@technlform[.]com | CC address on typosquat domain | |
| IP | 209[.]222[.]82[.]149 | Mail relay observed in transport headers |
| MITRE | T1566.001 | Phishing: Spearphishing Attachment |
| MITRE | T1534 | Internal Spearphishing (thread hijack) |
| MITRE | T1036 | Masquerading (typosquat domain) |