Two Look-Alike Domains. One Email Man-in-the-Middle. Nobody Noticed Until It Was Too Late.
By the time security got involved, there was no malware to sandbox. No credential to reset. No exploit to reverse. Just an email thread between professionals and a payment that went to the wrong account.
This analysis reflects generalized patterns from documented BEC attack methodology. Technical artifacts illustrate actual attack techniques. All entities are fictional. The lessons are real.
The Setup: Why It Worked Before Anyone Noticed
The attacker didn't compromise anything. They registered a domain.
Legitimate domain: zelvapay.com
Attacker domain: zelvpay.com
One letter dropped. "Zelva Pay" became "Zelv Pay." Both look like real company names at a glance. That's it. That's the whole attack surface.
But the domain registration was just the start. The attacker configured it to mirror the real vendor infrastructure exactly. Same MX provider. Valid SPF. Valid DKIM. No DMARC. Same as the vendor.
When the emails arrived, every authentication check came back clean.
The Full Picture: This Wasn't One-Sided
This is where it gets more interesting than a typical BEC.
Most BEC attacks work like this: attacker impersonates a vendor, victim gets deceived, damage is done. One fake domain. One victim.
This attack ran two deceptions simultaneously.
The attacker registered two domains:
Attacker domain 1: zelvpay.com ← impersonates the vendor
(deceives Orvex Corp into thinking it's the real vendor)
Attacker domain 2: orvexcorp.com ← impersonates the victim company
(deceives Zelva Pay into thinking it's Orvex Corp)
The real vendor wasn't silent either. They were actively replying throughout the whole thing. But their replies were going to orvexcorp.com, the attacker's inbox. Orvex Corp's emails were going to zelvpay.com, which was also the attacker.
The attacker sat in the middle. Reading everything. Forwarding selectively. Controlling both sides of the conversation.
Reality of the communication flow: ORVEX CORP → zelvpay.com (attacker) → ZELVA PAY NEVER RECEIVED IT ZELVA PAY → orvexcorp.com (attacker) → ORVEX CORP NEVER RECEIVED IT What both sides thought was happening: ORVEX CORP ←────────────────────────────→ ZELVA PAY
- Zelva Pay thought they were talking to Orvex Corp. They weren't.
- Orvex Corp thought they were talking to Zelva Pay. They weren't.
- Every reply, every update, every clarification went through the attacker first.
- Neither side had any reason to be suspicious. Responses kept coming.
The real vendor had no idea any of this was happening. The impersonation ran entirely outside their infrastructure. Their replies went to the attacker. They had zero visibility into either side of the conversation.
This is not phishing. This is a full email man-in-the-middle operation.
No account compromise. No traffic interception. No malware. Just two domains and patience. Normal human communication did the rest.
The Technical Evidence
Header Analysis: Why Every Gate Passed
Return-Path: <billing@zelvpay.com> Received: from mail.zelvpay.com (198.51.100.47) DKIM-Signature: v=1; a=rsa-sha256; d=zelvpay.com Authentication-Results: spf=pass (zelvpay.com: 198.51.100.47 is authorized) dkim=pass header.d=zelvpay.com dmarc=pass action=none header.from=zelvpay.com
Everything passed. Because it was all valid for the attacker's domain.
SPF, DKIM, and DMARC validate sending infrastructure. That's it. They don't tell you whether a domain should actually be trusted by your organization.
Infrastructure Comparison
Legitimate domain: zelvapay.com Registrar: Major registrar Created: Early 2000s MX: cloud-based mail routing infrastructure SPF: v=spf1 include:[cloud-mail-provider] ~all DMARC: Not configured Attacker domain: zelvpay.com Registrar: Privacy-protected Created: Several months before the attack MX: cloud-based mail routing infrastructure SPF: v=spf1 include:[cloud-mail-provider] ~all DMARC: Not configured
The attacker mirrored the vendor's mail setup deliberately. Same MX provider, same configuration. To any mail server or email gateway, both domains looked identical.
Months in advance. This wasn't opportunistic.
Thread Reconstruction via Message-ID
Message 1: From: contact@zelvapay.com ← real vendor
Message-ID: <A001@zelvapay.com>
Message 2: From: internal-user@orvexcorp.com ← internal reply
In-Reply-To: <A001@zelvapay.com>
Message 3: From: billing@zelvpay.com ← attacker enters here
In-Reply-To: <A001@zelvapay.com> ← correctly references real thread
The attacker entered mid-thread. By that point, context and trust were already established between the real participants. Once inside, they were indistinguishable from anyone else in the conversation.
What the Security Stack Saw
The organization had a standard enterprise setup. Email gateway, SIEM, MFA, EDR. Here's what each control saw:
Email Gateway: SPF check → PASS (valid for zelvpay.com) DKIM verification → PASS (valid signature for zelvpay.com) DMARC policy → PASS (no DMARC on attacker domain = no enforcement) Malware scan → CLEAN (no payload, no URLs, plain text) Attachment sandbox → N/A (no attachments) SIEM: Authentication anomalies → None Endpoint alerts → None Lateral movement → None What happened: Successful impersonation. Serious operational impact.
Nothing failed. Every tool did what it was built to do. The attack lived in the gap between what email authentication validates and what business trust actually requires.
The DMARC Gap (Commonly Misunderstood)
Neither the legitimate vendor domain nor the attacker's lookalike had DMARC configured:
zelvapay.com: _dmarc → No record (NXDOMAIN response) zelvpay.com: _dmarc → No record (NXDOMAIN response)
This matters, but it's also widely misunderstood. Even if the vendor had DMARC at p=reject, it wouldn't have stopped this attack.
DMARC protects against someone spoofing your domain. When an attacker registers a completely separate domain and sets up their own mail infrastructure, your DMARC record means nothing. They're not spoofing zelvapay.com. They own zelvpay.com and everything on it is legitimate from a protocol perspective.
With no DMARC on either domain, both looked the same to any receiving mail server. Neither enforcing, neither rejecting. The symmetry actually made the switch harder to catch.
DMARC is a spoofing defense. It is not a lookalike domain defense. These are different threat vectors requiring different controls.
What the Investigation Revealed
The domain forensics told one story. The investigation surfaced a few more.
Free Email Provider Used in Attack Chain
Analysis of the email headers revealed that at least one message in the attack chain originated from a free consumer email provider rather than the attacker's registered lookalike domain.
Expected: billing@zelvpay.com ← registered lookalike domain Observed: [attacker]@freemail.com ← free consumer provider, no corporate infrastructure
A free email address in a corporate financial thread is a hard stop. Should be an automatic escalation trigger. It wasn't.
Email Client Security Warnings Were Present but Ignored
The email client displayed security warnings on messages arriving from the unverified sender. These warnings were visible to the recipient and were not acted upon.
When a warning is surfaced and dismissed without escalation, the technical control has functioned correctly. The process control has failed.
The warning fired. The workflow did not have a step for what to do next.
Side-by-Side Technical Comparison of Vendor vs. Attacker Domain
WHOIS COMPARISON
─────────────────────────────────────────────────────────
zelvapay.com zelvpay.com
(legitimate) (attacker)
─────────────────────────────────────────────────────────
Created: Early 2000s Recent registration
Registrar: Established provider Major registrar
Privacy: Standard Fully redacted
Registration length: 10+ years 1 year
Nameservers: Legacy provider NS Cloud-based DNS
DNSSEC: Unsigned Unsigned
─────────────────────────────────────────────────────────
MX RECORDS
─────────────────────────────────────────────────────────
zelvapay.com: mx001.[provider].net
mx002.[provider].net
zelvpay.com: cloud-based mail routing infrastructure
─────────────────────────────────────────────────────────
SPF RECORDS
─────────────────────────────────────────────────────────
zelvapay.com: v=spf1 include:[legacy-mail-provider] ~all
zelvpay.com: v=spf1 include:[cloud-mail-provider] ~all
─────────────────────────────────────────────────────────
DMARC
─────────────────────────────────────────────────────────
zelvapay.com: NOT CONFIGURED
zelvpay.com: NOT CONFIGURED (NXDOMAIN)
─────────────────────────────────────────────────────────
A RECORD (web hosting)
─────────────────────────────────────────────────────────
zelvapay.com: No A record (not web-hosted)
zelvpay.com: Resolves to commodity shared hosting infrastructure
─────────────────────────────────────────────────────────
The legitimate domain is exactly what an established business looks like. Long registration history, legacy mail provider, no website. Boring in the best way.
The attacker domain: privacy-protected, 1-year registration, stood up months before the attack. Mail infrastructure configured immediately. Commodity shared hosting IP, no history. No DMARC.
Neither domain had DMARC. No policy enforcement on either side. The attacker knew this and mirrored it deliberately.
A vendor without DMARC can't protect against impersonation of their own domain. That gap becomes your gap the moment you start sending them money.
Human Factors
Three human failures. Each one independent of the technical controls.
Nobody caught the domain difference. When you're mid-thread with a vendor you've worked with for years, you're not scrutinizing sender addresses.
No out-of-band verification when payment details changed. The request came in the middle of an ongoing conversation. It felt routine. That's the point.
The attacker picked this vendor relationship specifically. Long history, established trust. Scrutiny goes down over time. That's the condition they were looking for.
The Attack Campaign Fingerprint
One detail stands out above everything else. The clearest proof this wasn't opportunistic.
Both domains. Registered within a short window of each other. Weeks before the attack started.
Domain registration timeline: zelvpay.com ← impersonates vendor Registered: Weeks before the attack Configured: Cloud mail infrastructure + SPF active immediately Purpose: Deceive Orvex Corp orvexcorp.com ← impersonates victim organization Registered: Within the same short window Configured: Cloud-based mail infrastructure Purpose: Deceive Zelva Pay Time between registration and attack execution: short window
The sequencing strongly suggests prior awareness of the vendor relationship. You don't register a lookalike of a specific vendor unless you already know that vendor is being used and money flows through them.
There was a reconnaissance phase before any of this. Someone identified the relationship, identified both domain names, and registered lookalikes of both. Then waited.
1-year registrations on both domains. Long enough to run the fraud and walk away. This was a targeted strike, not a long-term operation.
Identical mail infrastructure on both domains. Single operator, repeatable playbook. The configuration choices aren't random. Major registrar, cloud MX, privacy protection, SPF softfail, no DMARC. That's a template.
This is the difference between phishing and targeted fraud. Phishing is volume-based and opportunistic. What happened here was researched, prepared, and executed with specific knowledge of the target organization's vendor relationships. The infrastructure was built before the first email was sent.
The Authentication Posture Problem
Post-incident authentication review surfaced a gap on the victim's own domain too.
DMARC wasn't at p=reject. No aggregate reporting either, so no visibility into who was spoofing the domain. Moving to full rejection with reporting fixed both problems.
Won't stop a lookalike attack. But it closes the spoofing vector and gives you visibility into who's trying.
SPF had multiple authorized senders: cloud mail, marketing tools, CRM. Normal for any enterprise. But you need to validate DKIM alignment on each one before pushing to reject. Move too fast and you break legitimate mail.
Lessons Learned
For Security Teams
Lookalike monitoring needs to go both ways: inbound domains impersonating your vendors, and outbound domains impersonating you. This attack ran both simultaneously. Run dnstwist quarterly. Any domain within 1-2 characters of yours with active MX records is worth watching. And get DMARC aggregate reporting (rua=) turned on. Without it you have no visibility into who's trying.
For Detection Engineers
Gateway rules without business context are noise. The signal is in correlation: domain similarity + domain age + new thread participant + financial keywords. Build those rules. They don't exist out of the box. And treat Message-ID and In-Reply-To headers as your primary forensic tool in any BEC investigation. They tell you exactly when the attacker entered and what they had access to.
For Incident Responders
Start with the headers, not the endpoint. There's no compromise to find. The attack surface is the email thread itself. Trace every participant, verify every domain, reconstruct the timeline through Message-ID correlation. Out-of-band verification for banking changes needs to be a mandatory process step, not left to individual judgment.
For Leaders
Financial processes are designed for efficiency, not adversarial conditions. If your payment change workflow has no verification step, threat-modeling your infrastructure doesn't help. Security can flag anomalies. The process has to require verification before money moves.
What Would Have Actually Stopped This
Every technical control worked. The attack still succeeded. The fix isn't in better tooling. It's in the controls that were never built in the first place.
Five things that would have stopped this:
1. A vendor contact inventory
A maintained list of confirmed email domains for every active vendor. Check every inbound financial email against it. zelvpay.com not in the registry? It doesn't reach finance.
2. Lookalike domain monitoring
Automated scanning for newly registered domains close to your known vendors. Both attacker domains were registered weeks before the attack. That window exists for every one of these cases. Almost no one uses it.
3. Out-of-band verification for payment changes
Any banking detail change requires a phone call to a pre-registered number. Doesn't matter how trusted the thread looks. Doesn't matter how familiar the sender seems. Not email. Not a number in the same message. A number you already have on file.
4. Thread-aware detection
A SIEM rule flagging new external participants in existing financial threads, combined with domain age and first-time sender signals. The attacker's entry point was sitting in the headers the whole time. Nothing was watching for it.
5. Vendor email posture in third-party risk
The real vendor had no DMARC. That gap was part of what made this work. Vendor email authentication should be in your third-party risk assessment, not just contracts and compliance certifications.
None of this requires buying new tools. All of it requires deliberate process design.
The Uncomfortable Truth
Every technical gate passed. Authentication worked. Gateway worked. SIEM worked. Nothing failed in the way security tools are designed to detect failure.
The failure was architectural. No security control was asking: should this entity be trusted by this business, for this specific request, right now?
Email authentication answers one question: is this message legitimately from the domain it claims? It doesn't answer whether that domain should be trusted for financial instructions. That's a business context question. It requires vendor registries, verified contact lists, mandatory verification workflows, and thread-aware detection. Until organizations start threat-modeling their financial workflows the same way they threat-model their infrastructure, BEC will keep working.
The fix isn't better email security tooling. It's building verification into the workflow itself.
The fix isn't better email security tooling. It's building verification into the workflow itself.