Detecting and Mitigating Email Spoofing (MITRE ATT&CK T1684.002)

Email Spoofing (T1684.002) is a sub-technique of Social Engineering in which an adversary fakes a sender's identity by changing email header values. MITRE places it in the Stealth tactic and lists Linux, macOS, Office Suite and Windows as platforms.

How attackers use it

Email clients show header values such as the From address, so changing them can make a message appear to come from the spoofed party. The attacker can then contact victims under false pretenses.

MITRE explains the defenses and where they fail. Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol that uses the results of the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). Both are set up separately in DNS. SPF checks that the sending server is authorized for the domain. DKIM uses a digital signature to verify message integrity and domain authentication. Together they let a receiving server decide what to do with mail that fails.

Without enforced authentication, altered headers may get through. MITRE's example of a weak policy is v=DMARC1; p=none; fo=1;. The p=none setting means no action is taken, so a message that fails SPF or DKIM is still delivered to the inbox. Adversaries have abused weak or missing DMARC policies to get around authentication checks and hide social engineering attempts, for example by altering headers to include legitimate domain names with fake usernames.

How to detect it

MITRE's detection strategy looks at authentication results and header mismatches:

• Message traces and headers. Failed SPF, DKIM or DMARC checks, and abnormal sender domains or mismatched return-paths.
• Mail server logs on Linux (Postfix, Sendmail). Mismatched header fields, failed SPF and DKIM checks, and anomalies in SMTP proxy logs, especially differences between sending domain, return-path domain and message metadata.
• macOS. Inbound mail with failed authentication or mismatched sender and return-path domains, visible in unified logs or MDM-controlled logging.
• Office 365 and Google Workspace audit logs. Spoofed sender addresses, failed authentication and delivery metadata anomalies tied to suspicious campaigns.

Authentication results are in the message headers. Many mail platforms add an Authentication-Results header you can search on.

How to reduce the risk

MITRE lists one mitigation, Software Configuration: use anti-spoofing and email authentication to filter messages based on the validity of the sender domain (SPF) and the integrity of messages (DKIM). Enabling these through policies such as DMARC lets recipients, inside and outside the organization, run the same filtering. MITRE adds a caution: extra filtering may be needed if mail comes from legitimate sources.

The steps in order:

1. Publish SPF for every domain you own, including ones that never send mail.
2. Sign outbound mail with DKIM.
3. Publish DMARC at p=none with reporting turned on, and read the reports to find legitimate senders you forgot about.
4. Fix those senders, then move to p=quarantine, and then p=reject.
5. Keep watching the reports.

Check your own environment

These read-only DNS lookups work on macOS and Linux with the dig tool. Replace example.com with your domain.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

The first shows your SPF record, which starts with v=spf1. The second shows your DMARC policy. Check:

• Is there exactly one SPF record?
• Does DMARC exist, and is the policy none, quarantine or reject?
• Do you also protect parked and unused domains?
• Are DKIM selectors in place for every service that sends on your behalf?

Quick check

Sources

• MITRE ATT&CK, Email Spoofing (T1684.002): https://attack.mitre.org/techniques/T1684/002