Table of Contents
A manufacturing engineering staffer opened an email from a supplier contact they already knew. The display name was exact. The pitch was routine: lower your beveling costs, can we grab a short call. The signature carried a title, a phone number, a street address, and a company website. Nothing about it raised a hand.
The sender's domain was one hyphen off the real one.
That single character is the entire attack. This is vendor email compromise (VEC), a targeted impersonation in which an attacker exploits the trust between an organization and one of its suppliers. What makes this case worth a teardown is not the lure, which was unremarkable, but how cleanly it slipped past every control built to stop it: authentication passed, the policy that should have enforced was disarmed, and the only thing standing between the recipient and a foothold was analysis of the relationship itself.
The contact was real, the domain was not
The legitimate supplier exists. It has a real, established domain registered back in 2016, a real business address, and a contact the recipient had corresponded with before. The attacker did not compromise any of that. They rebuilt it.
In a single registration batch, the attacker stood up two lookalike domains: one hyphenated near-miss of the supplier's name used as the sending and reply-to address, and a second non-hyphenated variant used to mirror the known contact's identity. Both were registered the same day through GoDaddy with WHOIS privacy, both on one-year terms, both with unsigned DNSSEC. They were nine years younger than the domain they imitated.
The message then borrowed the contact's exact display name and pointed everything back toward the supplier's real website, so a recipient who clicked through landed on a genuine-looking page. The deception lived entirely in the From line. The eye reads a familiar name and a familiar-looking domain and stops there. It does not diff strings.
How the message was built and sent
The headers show this was not a one-off. Embedded campaign, sequence, step, and outbox identifiers reveal the message was generated by a cold-email sales-engagement platform and delivered through the Gmail API over an authenticated HTTP request. The attacker was running the lookalike domain through commodity outreach tooling, the same automation a legitimate sales team would use.
That tooling is why the authentication came back clean. Because the attacker actually owned the lookalike sending domain and had published valid records for it, the message earned legitimate signatures.
This maps to two MITRE ATT&CK techniques. Acquire Infrastructure: Domains covers the deliberate registration of the lookalike domains ahead of the campaign. Impersonation covers the exact display-name match used to borrow the supplier contact's identity. The same playbook drives the broader vendor email compromise category, where the trust being abused belongs to a third party the victim already does business with.
Authentication passed, enforcement was switched off
Here is the uncomfortable part. SPF (Sender Policy Framework, which checks whether the sending server is authorized) passed. DKIM (DomainKeys Identified Mail, which cryptographically signs the message) passed, signed by the lookalike domain itself. DMARC (Domain-based Message Authentication, Reporting and Conformance, which ties the two together and tells receivers what to do on failure) passed as well, with composite authentication scoring a perfect result.
None of that means the message was safe. Authentication answers one question: was this sent from infrastructure authorized for the From domain. When the attacker controls the From domain, the answer is yes. The checks never compare the lookalike against the supplier's real domain, so the one-character gap is invisible to them.
The lookalike's DMARC policy was set to p=none, monitor-only. Even in a world where alignment had failed, p=none instructs receivers to take no enforcement action. The attacker chose a policy that guarantees delivery. Proper DMARC management and monitoring hardens your own domain against being spoofed, but it cannot reach into an attacker-owned lookalike and turn enforcement back on.
The link did not go where it said
The body carried a link whose displayed text mimicked the lookalike domain string, while the actual destination resolved elsewhere. Link scanning flagged the elements malicious on exactly that displayed-versus-destination mismatch. A recipient reading the visible text would never see the divergence; scanning compared the two and caught it.
This is the practical lesson for business email compromise protection: when the sender is unblockable because authentication is genuine, the defensible layers are the link destination and the relationship history.
Indicators of compromise
| Type | Indicator | Context |
|---|---|---|
| Domain | hxxps://precision-bevelus[.]com | Attacker lookalike, sending and reply-to domain, registered 2025-08-21 |
| Domain | precisionbevelinc[.]com | Second attacker lookalike registered the same day, used to mirror the known contact identity |
| iantonow@precision-bevelus[.]com | Spoofed-display-name sender on the lookalike domain | |
| Behavior | Exact display-name match from a new domain | Known contact name arriving from a domain the contact never used |
| Behavior | Displayed link text vs href mismatch | Link elements flagged malicious by scanning |
| Auth | SPF pass, DKIM pass, DMARC pass (p=none) | Genuine authentication on attacker-owned domain, no enforcement |
What actually caught it
Authentication cleared the message. The recipient's eye cleared it too. What flagged it was relationship analysis: the system already knew this contact from the supplier's real domain, recognized that an exact display-name match was now arriving from a domain that contact had never used, and weighed that against community reputation and the malicious link verdict. That behavioral comparison is the layer that survives when SPF, DKIM, and DMARC all say yes.
The industry data backs the priority. Verizon's 2026 Data Breach Investigations Report puts the human element in 62 percent of breaches and phishing in 16 percent of initial-access cases. The FBI's IC3 2024 report continues to rank BEC and vendor fraud among the costliest categories by reported losses, a pattern the FTC Consumer Sentinel Network echoes in its fraud tallies. Microsoft's 2024 Digital Defense Report documents the same shift toward identity and impersonation over malware. CISA's guidance on recognizing and reporting phishing reinforces the operational fix: verify a payment or relationship change through a known channel, never the one in the message.
See Your Risk: Calculate how many threats your SEG is missing
A secure email gateway (SEG) inspects content and reputation, but a genuinely authenticated message from an attacker-owned domain gives it little to fault. IRONSCALES data shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes each month, and lookalike VEC is precisely the gap. The defense is not a better signature check. It is knowing which domain your supplier actually emails from, and noticing the moment a familiar name arrives from a new one.
Verify the relationship, not just the headers. The attacker counted on you reading the name and skipping the hyphen.
Related attacks
| Attack | What happened |
|---|---|
| The GitLab Alert That Passed Every Filter (Except One Detail Nobody Checked) | A GitLab sign-in alert cleared Proofpoint URL Defense and passed SPF/DMARC — then listed a private RFC1918 IP as the sign-in source. |
| Microsoft Bookings as a Weapon: When DMARC Says Trust Me and ARC Quietly Disagrees | A phishing email sent from bookings.microsoft.com passed every authentication check. |
| The Timestamp That Gave It Away: Oracle Identity Cloud Phishing Targets K-12 with a Stale Timezone | A phishing email impersonating Oracle Identity Cloud targeted a Florida school district employee. |
| The Phishing Simulation Platform That Powered a Real Attack | A salary adjustment lure routed through SendGrid and a Carrd landing page used phishing kit images hosted on a commercial phishing simulation vendor's own... |
| DocuSign Lure, Diverted Replies: How Reply-Path Manipulation Turns a Legitimate Envelope Into a BEC Trap | An authenticated DocuSign notification arrived with its Reply-To silently diverted to an external attacker-controlled domain. |
Explore More Articles
Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.