Which SIEM platforms have a T1656 detection rule?

df00tech provides T1656 (Impersonation) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What severity and confidence is the T1656 detection?

The T1656 detection is rated high severity with medium confidence.

What are common false positives for T1656?

Common false positives for T1656 include: 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.

T1656: Impersonation — Detection (KQL, SPL, Sigma + 5 SIEMs)

Q: What data sources are required to detect Impersonation (T1656)?

Detecting Impersonation requires the following data sources: Microsoft Defender for Office 365, Microsoft Entra ID / Azure AD, Microsoft 365 (OfficeActivity).

Microsoft Sentinel / Defender

kusto

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 desc

Detects 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.

high severity medium confidence

Data Sources

Microsoft Defender for Office 365 Microsoft Entra ID / Azure AD Microsoft 365 (OfficeActivity)

Required Tables

EmailEvents AADUsers OfficeActivity

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

Splunk

spl

index=* (sourcetype="o365:management:activity" OR sourcetype="ms:o365:management")
| eval op=coalesce(Operation, operation)
| eval user=coalesce(UserId, user_id)
| eval client_ip=coalesce(ClientIP, client_ip)
| eval subject=coalesce(Subject, "")
| eval sender=coalesce(SenderAddress, FromAddress, user)
| eval recipient=coalesce(RecipientAddress, ToAddress, "")
| eval auth_result=coalesce(AuthenticationDetails, SpfVerdict, DkimVerdict, DmarcVerdict, "")
[
  search (op="MessageSent" OR op="Send" OR op="SendAs" OR op="SendOnBehalf")
  | return 100000 op user client_ip subject sender recipient auth_result
]
| eval urgency_hit=if(match(lower(subject), "(urgent|wire.?transfer|payment|invoice|request|verify|immediate|overdue|final.?notice|password.?reset|account.?update)"), 1, 0)
| eval auth_fail=if(match(lower(auth_result), "(spf=fail|dkim=fail|dmarc=fail|softfail|fail)"), 1, 0)
| eval delegation_abuse=if(op IN ("SendAs", "SendOnBehalf") AND user!=sender, 1, 0)
| where urgency_hit=1 OR auth_fail=1 OR delegation_abuse=1
| eval detection_type=case(
    delegation_abuse=1, "SuspiciousDelegation",
    auth_fail=1 AND urgency_hit=1, "AuthFailWithUrgency",
    auth_fail=1, "AuthFailure",
    urgency_hit=1, "UrgencyKeyword",
    true(), "Unknown"
  )
| eval risk_score=if(auth_fail=1, 50, 0) + if(urgency_hit=1, 30, 0) + if(delegation_abuse=1, 70, 0)
| where risk_score >= 50
| table _time, detection_type, risk_score, user, sender, recipient, subject, client_ip, auth_result, op
| sort -risk_score, -_time

Detects impersonation activity in Office 365 management activity logs by scoring events across three risk dimensions: email authentication failures (SPF/DKIM/DMARC), urgency keyword presence in email subjects associated with BEC fraud patterns, and delegation abuse where SendAs or SendOnBehalf operations are performed by identities different from the mailbox owner. Events scoring 50+ risk points are surfaced as alerts.

high severity medium confidence

Data Sources

Microsoft 365 / Office 365 Management Activity Microsoft Defender for Office 365

Required Sourcetypes

o365:management:activity ms:o365:management

False Positives

Marketing automation platforms (Marketo, HubSpot, Pardot) sending on behalf of sales reps via SendOnBehalf delegation legitimately fail certain auth checks — verify by correlating sender domain against known marketing vendor IP ranges
Automated billing and finance systems that send invoices and payment reminders with urgency language will match the keyword filter — build a suppression list of known finance system service accounts
IT helpdesk ticketing systems (ServiceNow, Zendesk) that use SendAs to reply from team mailboxes will trigger delegation detection — validate against known IT service account UPNs

Elastic Security (EQL)

eql

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.

high severity medium confidence

Data Sources

Microsoft 365 Elastic O365 Integration

Required Tables

logs-o365.audit-* logs-email.*

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

IBM QRadar (AQL)

sql

SELECT
    DATEFORMAT(devicetime, 'yyyy-MM-dd HH:mm:ss') AS EventTime,
    LOGSOURCENAME(logsourceid) AS LogSource,
    "username" AS SenderAddress,
    "RecipientAddress" AS RecipientAddress,
    "Subject" AS EmailSubject,
    CASE
        WHEN "SPFResult" = 'fail' AND "DKIMResult" = 'fail' THEN 90
        WHEN "DMARCResult" = 'fail' THEN 80
        WHEN "SPFResult" ILIKE '%fail%' THEN 65
        ELSE 50
    END AS RiskScore
FROM events
WHERE
    LOGSOURCETYPENAME(devicetype) IN ('Microsoft Exchange', 'Office 365')
    AND ("SPFResult" ILIKE '%fail%'
        OR "DKIMResult" ILIKE '%fail%'
        OR "DMARCResult" ILIKE '%fail%')
    AND RiskScore >= 65
ORDER BY EventTime DESC
LAST 1 HOURS

IBM QRadar AQL detection for Impersonation (T1656). Queries QRadar event pipeline for indicators consistent with impersonation adversary techniques using MITRE ATT&CK-aligned event categorization.

high severity medium confidence

Data Sources

IBM QRadar SIEM Windows Security Events Endpoint Agent

Required Tables

events

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

Sumo Logic CSE

sql

_sourceCategory=o365/management
| json auto
| where operation in ("Receive","MessageDelivered","New-InboxRule","Set-InboxRule","UpdateInboxRules")
| where spf_result matches /(fail|softfail)/i OR dkim_result = "fail" OR dmarc_result = "fail"
    OR operation matches /InboxRule/i
| if(spf_result = "fail" AND dkim_result = "fail", 90,
    if(dmarc_result = "fail", 80,
    if(operation matches /InboxRule/i, 85, 65))) as risk_score
| if(operation matches /InboxRule/i, "MailboxRule",
    if(dmarc_result = "fail", "DMARCFail", "AuthFailure")) as detection_type
| where risk_score >= 65
| count by sender_address, recipient_address, detection_type, risk_score
| sort - risk_score

Sumo Logic detection for Impersonation (T1656). Identifies adversary impersonation behaviors using Sumo Logic's search pipeline with field extraction and anomaly classification.

high severity medium confidence

Data Sources

Sumo Logic Cloud SIEM Windows Event Logs Endpoint Telemetry

Required Tables

_sourceCategory=o365/management OR _sourceCategory=microsoft/exchange

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

Google Chronicle / SecOps

yaral

rule detection_t1656 {
  meta:
    author = "Argus Detection Platform"
    description = "Detects Impersonation email activity - T1656"
    severity = "HIGH"
    mitre_attack = "T1656"
    reference = "https://attack.mitre.org/techniques/T1656/"

  events:
    $e.metadata.event_type = "EMAIL_TRANSACTION"
    $e.principal.user.email_addresses = $sender
    $e.network.email.to = $recipient
    $e.network.email.subject = $subject
    (
      re.regex($e.network.email.subject, `(?i)(urgent|wire.?transfer|payment|invoice|final.?notice)`) or
      $e.security_result.action = "BLOCK"
    )

  condition:
    $e
}

Google Chronicle YARA-L 2.0 rule for detecting Impersonation (T1656). Uses Chronicle UDM event model to identify impersonation behaviors across endpoint and cloud telemetry.

high severity medium confidence

Data Sources

Microsoft 365 Google Workspace

Required Tables

EMAIL_TRANSACTION

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

CrowdStrike LogScale (CQL)

cql

#event_simpleName = "EmailActivityEvent"
| EmailDirection = "Inbound"
| SPFResult = /(?i)(fail|softfail)/ OR DKIMResult = "fail" OR DMARCResult = "fail"
    OR Subject = /(?i)(urgent|wire.?transfer|payment|invoice|final.?notice)/
| case {
    SPFResult = "fail" AND DKIMResult = "fail" | RiskScore := "High" ;
    DMARCResult = "fail" | RiskScore := "High" ;
    Subject = /(?i)(wire.?transfer|payment)/ | RiskScore := "High" ;
    * | RiskScore := "Medium"
}
| table([SenderFromAddress, RecipientEmailAddress, Subject, SPFResult, DKIMResult, DMARCResult, RiskScore, DeliveryAction])
| sort(@timestamp, order=desc, limit=100)

CrowdStrike LogScale CQL detection for Impersonation (T1656). Queries Falcon telemetry for impersonation behavioral indicators aligned with MITRE ATT&CK T1656.

high severity medium confidence

Data Sources

CrowdStrike Falcon Email Protection

Required Tables

EmailActivityEvent

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

Impersonation

What is T1656 Impersonation?

MITRE ATT&CK

Data Sources

Required Tables

False Positives

Data Sources

Required Sourcetypes

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Sigma rule & cross-platform mapping

Platform-specific guides for T1656

Testing Methodology

Response Playbook

Investigation Guide

Atomic Red Team Tests

Unlock Pro Content

Related Detections

Tactic Hub

Related Techniques

Same Tactic: Defense Evasion

Popular Detections

What is T1656 Impersonation?

MITRE ATT&CK

Data Sources

Required Tables

False Positives

Data Sources

Required Sourcetypes

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Sigma rule & cross-platform mapping

Platform-specific guides for T1656

Testing Methodology

Unlock Pro Content

Related Detections

Tactic Hub

Related Techniques

Same Tactic: Defense Evasion

Popular Detections

Get new detections in your inbox