T1684.002No distinct observable

Email Spoofing

StealthLinux, macOS, Office Suite, Windows

Where this stands

A reviewer read the telemetry and concluded there is nothing here to detect that a sibling technique does not already cover.

T1684.002 lists four platforms (Linux, macOS, Office Suite, Windows) but the brief supplies logsources for only two of them, and both are ones this corpus has already established cannot be written against. AN1203's only source is {product: linux, service: syslog} -- no rule in this corpus has an established Sigma field vocabulary for linux:syslog, and the analytic's own note, 'SPF fail OR DKIM fail OR DMARC fail OR mismatched from_domain vs return_path_domain', is free text with no field names attached to it, so the only expressible form would be a keyword-only search over an unparsed message line, which AUTHORING.md rule 4 forbids because no backend renders it -- the same reasoning already recorded against linux:syslog for T1557.003, T1036.006, T1037.004, T1059.004 and T1668. […]

Covered instead by T1557.003, T1668.

What the technique is

Adversaries may fake, or spoof, a sender’s identity by modifying the value of relevant email headers in order to establish contact with victims under false pretenses. In addition to actual email content, email headers (such as the FROM header, which contains the email address of the sender) may also be modified. Email clients display these headers when emails appear in a victim's inbox, which may cause modified emails to appear as if they were from the spoofed entity. Enterprise environments can use Domain-based Message Authentication, Reporting, and Conformance (DMARC) as an email authentication protocol that references results of the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) configurations. SPF and DKIM are configured separately in DNS: SPF verifies that the sending server is authorized for the domain, while DKIM uses a digital signature to verify email integrity and domain authentication. Together, they validate email authenticity and specify how receiving servers should handle authentication failures. Without enforced identity authentication, adversaries may compromise the integrity of an authentication check with altered headers that would not have otherwise passed. An example of a weak or absent DMARC policy is v=DMARC1; p=none; fo=1;. The p=none. […]

Read it on attack.mitre.org

What MITRE says you would watch

AN1202
Monitor email message traces and headers for failed SPF, DKIM, or DMARC checks indicating spoofed sender identities. Correlate abnormal sender domains or mismatched return-paths with elevated spoofing likelihood.
AN1203
Detects spoofed emails by analyzing mail server logs (e.g., Postfix, Sendmail) for mismatched header fields, failed SPF/DKIM checks, and anomalies in SMTP proxy logs. Defender observes discrepancies between sending domain, return-path domain, and message metadata.
AN1204
Detects suspicious inbound mail traffic where SPF/DKIM/DMARC authentication fails or where sender and return-path domains mismatch, observable in Apple Mail unified logs or MDM-controlled logging pipelines.