Executive impersonation & CEO fraud defense

The attacker pattern

Executive impersonation attacks (a class of Business Email Compromise, or BEC) use one of two technical patterns. In the first, the attacker registers a domain that includes the target executive's name — [firstname]-[lastname]-personal.com, ceo-[lastname].com — and sends pretextual mail from it (SPF and DKIM all pass; it's the attacker's domain). In the second, the attacker spoofs the From header on your real corporate domain, which only works if your DMARC policy isn't at p=reject.

Either way, the target is your finance team or executive assistant. The payload is a request for a wire transfer, gift card purchase, sensitive-document handover, or change of a vendor's banking details. According to the FBI's Internet Crime Complaint Center, BEC consistently ranks as the highest-loss cybercrime category — far above ransomware in dollar terms.

How PhishFence detects it

1. 1

   Executive-name variant set

   The lookalike scanner generates an additional executive-impersonation set: firstname-lastname.com, lastname-firstname.com, and the same variants with title prefixes like ceo-, cfo-, md-. Configured per monitored domain.

2. 2

   DMARC aggregate report ingestion

   PhishFence ingests RUA reports from Gmail, Microsoft, Yahoo, and the long tail. Reports surface every source IP that sent claiming to be your domain, with per-IP pass/fail counts. Spoofing attempts show up as fail-fail records from IPs not in your SPF.

3. 3

   Forensic-style detail on individual failures

   For DMARC failures with forensic (RUF) reports configured, PhishFence captures the full message envelope so your IR team can see the actual spoofed headers.

4. 4

   Severity-based alert routing

   Spoofing attempts trigger real-time webhook alerts to your SIEM or Slack security channel. Lookalike registrations roll into the daily digest unless the variant scores critical (active TLS + MX configured + recently registered).

5. 5

   DMARC enforcement runway

   If you're not yet at p=reject, PhishFence's DMARC ramp playbook tells you exactly when it's safe to escalate the next step based on observed pass rates — closing the spoofing channel for good.

What it looks like in PhishFence

Common pitfalls to avoid

• Assuming DMARC alone is enough. p=reject stops attackers from spoofing your real domain but does nothing about attacker-registered lookalikes where SPF and DKIM legitimately pass. You need both channels covered.

• Staying at p=none indefinitely. A monitoring-only DMARC policy is useful for the first month while you find your senders. Past that, it's leaving the door wide open to spoofing the real domain. Ramp the policy.

• Skipping the display-name spoofing problem. DMARC and lookalike monitoring don't catch display-name spoofing — where an attacker uses a throwaway @gmail.com address but sets the friendly name to your CEO's. That's a mail-filter and user-training problem, not a domain-monitoring one. Pair the technical defense with finance-team training on out-of-band verification.

• Ignoring subdomains. Many DMARC deployments forget sp=, which controls subdomain policy. If you don't set it explicitly, subdomains inherit the parent policy — sometimes that's wrong (e.g. a transactional subdomain that genuinely sends from many places).

Which PhishFence tier?

Related tools & guides