Detecting and Mitigating Impersonation (MITRE ATT&CK T1684.001)

Impersonation (T1684.001) is a sub-technique of Social Engineering. An adversary pretends to be a trusted person or organization to persuade a target to act. MITRE places it in the Stealth tactic and lists Linux, macOS, Office Suite, SaaS and Windows as platforms.

How attackers use it

MITRE explains that adversaries may contact victims through Phishing for Information (T1598), Phishing (T1566) or Internal Spearphishing (T1534) while posing as a known sender, such as an executive, a colleague or a third-party vendor. The trust that creates can then be used toward the adversary's real goal, sometimes against more than one victim.

In many business email compromise (BEC) and email fraud cases, impersonation is used to defraud victims, getting them to send money or give out information that leads to Financial Theft (T1657).

Several habits mark these campaigns:

• Persuasive language in subject lines and bodies, with words like payment, request or urgent, to push the victim to act before anyone notices.
• Targeting people whose job or access lets them do what the adversary wants.
• Prior reconnaissance, such as Gather Victim Identity Information (T1589) and Gather Victim Org Information (T1591).
• Acquiring infrastructure such as lookalike email domains (T1583.001) to support the false identity.

The technique page records impersonation of banks and government bodies, impersonation of officials in spearphishing emails, and impersonation of recruiters and investors to lure victims to malicious skills assessments or online meetings. It also notes the potential for multiple victims, for example when a compromised account is used to impersonate its owner to others.

How to detect it

MITRE's detection strategy has several data sources.

• Windows mail clients such as Outlook. The display name does not match the underlying SMTP address. Look for unusual volume of outbound messages with sensitive keywords such as "payment" or "wire transfer", or anomalous login locations for accounts that send mail.
• Mail servers on Linux (Postfix, Sendmail, Exim). From headers that do not match the authenticated SMTP identity, odd relay attempts, spoofed envelope-from values and large outbound campaigns aimed at internal users.
• macOS Mail. Mismatches between display name and authenticated identity, and third-party mail utilities that try to send on behalf of corporate identities.
• SaaS mail platforms such as Google Workspace and Microsoft 365. SendAs and SendOnBehalfOf operations with unusual or newly granted delegated permissions, and rules that auto-forward or auto-reply with impersonated content.
• Office applications. Automated message sending by macros or scripts, combined with phrases like urgent, payment or executive request.

A simple, high-value rule: flag external messages whose display name matches an internal executive or a known vendor but whose address is outside your domain or the vendor's.

How to reduce the risk

MITRE lists two mitigations.

1. User Training. Teach users to recognize impersonation tricks and to confirm requests through an independent platform, such as a phone call or an in-person check.
2. Threat Intelligence Program. Intelligence about common lures and active campaigns helps defenders and users know what to expect.

Build on these with process controls:

• Verify any change of bank details by calling a number you already hold.
• Require a second approver on payments over a set threshold.
• Tag external email clearly, and warn when a display name matches an internal person.
• Register the obvious lookalike versions of your own domain, and monitor for new ones.
• Enforce SPF, DKIM and DMARC on your domain (see Email Spoofing, T1684.002).

Check your own environment

• Pick five senior people and search your mail logs for external senders using their display names.
• List who has SendAs or SendOnBehalfOf rights on shared and executive mailboxes, and review each grant.
• Check for auto-forward rules in finance and executive mailboxes.
• Confirm that a changed payment instruction cannot be approved by the same person who received it.
• Review whether your staff know the call-back process, and test it.

Quick check

Sources

• MITRE ATT&CK, Impersonation (T1684.001): https://attack.mitre.org/techniques/T1684/001