Detect Impersonation in Elastic Security
This detection identifies adversary impersonation activity targeting organizational users through email-based business email compromise (BEC), help desk social engineering, and lookalike sender patterns. The detection focuses on emails with authentication failures (SPF/DKIM/DMARC) combined with high-urgency subject language, display name spoofing where sender display names match internal user identities but originate from external domains, and abnormal SendAs or SendOnBehalf delegation activity. Coverage extends to AAD sign-in anomalies that may indicate successful credential theft following impersonation-based help desk attacks, as seen in LAPSUS$ and Storm-1811 campaigns.
MITRE ATT&CK
- Tactic
- Defense Evasion
- Technique
- T1656 Impersonation
- Canonical reference
- https://attack.mitre.org/techniques/T1656/
Elastic Detection Query
any where event.dataset : "o365.*" and event.action in (
"Receive", "MessageDelivered", "New-InboxRule", "Set-InboxRule"
) and (
o365.audit.Authentication_Details : ("spf=fail*", "dkim=fail*", "dmarc=fail*") or
o365.audit.Operation : ("New-InboxRule", "UpdateInboxRules")
)Elastic EQL detection for Impersonation (T1656). Identifies impersonation activity by correlating endpoint telemetry patterns consistent with known adversary techniques.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate third-party email service providers (Mailchimp, Salesforce, HubSpot) frequently fail DMARC when not properly configured in the sending domain's DNS, generating high-urgency transactional emails (payment confirmations, invoice delivery)
- Executive assistants or shared mailbox operators legitimately using SendAs or SendOnBehalf delegation on behalf of their principals will trigger the delegation abuse branch — validate by checking O365 delegation configuration in Exchange
- Vendors or contractors whose display names match internal employees with the same name (common surnames) will trigger DisplayNameSpoof detection — correlate with known vendor contact lists and verify recipient context
Other platforms for T1656
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1BEC Email Simulation via PowerShell SMTP with Spoofed Display Name
Expected signal: EmailEvents table: record with SenderDisplayName='John Smith (CEO)', SenderFromAddress='[email protected]', AuthenticationDetails showing dmarc=fail or spf=fail, Subject containing 'URGENT' and 'Wire Transfer'
- Test 2Mailbox Delegation Abuse Simulation via Exchange Online PowerShell
Expected signal: OfficeActivity: Add-RecipientPermission event (Operation=Add-MailboxPermission) followed by SendAs operation where UserId=attacker-test-account and MailboxOwnerUPN=finance-director-test. AADAuditLogs: 'Update user' or 'Add member to role' if escalation attempted.
- Test 3Inbox Forwarding Rule Creation Simulating Post-Compromise Email Persistence
Expected signal: OfficeActivity: New-InboxRule operation for compromised-user-test mailbox with Parameters containing [email protected]. Event logged within 60 seconds of rule creation.
References (5)
- https://attack.mitre.org/techniques/T1656/
- https://www.crowdstrike.com/blog/business-email-compromise-bec-trends-tactics-and-techniques/
- https://www.microsoft.com/en-us/security/blog/2023/05/24/volt-typhoon-targets-us-critical-infrastructure-with-living-off-the-land-techniques/
- https://www.mandiant.com/resources/apt42-charms-social-engineering
- https://www.cisa.gov/sites/default/files/2023-08/aa23-208a_lapsus_0.pdf
Unlock Pro Content
Get the full detection package for T1656 including response playbook, investigation guide, and atomic red team tests.