Impersonation Detections Trend

Hunt Hypothesis

Adversaries may be using impersonation tactics to mimic trusted entities in emails, increasing the likelihood of successful phishing attacks. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate potential business email compromise (BEC) incidents early.

KQL Query

let TimeStart = startofday(ago(30d));
let TimeEnd = startofday(now());
EmailEvents 
| where DetectionMethods has 'Impersonation' 
| make-series Count = count() default = 0 on Timestamp from TimeStart to TimeEnd step 1d 
| extend Details = "ImpersonatedEmails"
| render timechart

Analytic Rule Definition

id: 761e4ddd-6b87-4c00-b033-55c3d0e4fe2e
name: Impersonation Detections Trend
description: |
  This query visualises total emails with Phish (BEC) - Impersonation detections over time.
description-detailed: |
  This query visualises total emails with Phish Business Email Compromise (BEC) Impersonation detections over time summarizing the data daily.
  Query is also included as part of the Defender for Office 365 solution in Sentinel: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/part-2-build-custom-email-security-reports-and-dashboards-with-workbooks-in-micr/4411303
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - EmailEvents
tactics:
  - InitialAccess
relevantTechniques:
  - T1566
query: |
  let TimeStart = startofday(ago(30d));
  let TimeEnd = startofday(now());
  EmailEvents 
  | where DetectionMethods has 'Impersonation' 
  | make-series Count = count() default = 0 on Timestamp from TimeStart to TimeEnd step 1d 
  | extend Details = "ImpersonatedEmails"
  | render timechart
version: 1.0.0

Required Data Sources

MITRE ATT&CK Context

• Tactic: InitialAccess
• Technique: T1566 — T1566

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/Microsoft 365 Defender/Email and Collaboration Queries/Spoof and Impersonation/Impersonation Phishing detections trend.yaml)

False Positive Guidance

• Scenario: System administrator sends a test phishing email to a subset of users for training purposes.
  Filter/Exclusion: Exclude emails sent from known admin accounts (e.g., [email protected]) or use a filter based on the sender_email field to exclude internal training emails.

• Scenario: A scheduled job runs a script that sends automated emails to users for system updates or notifications.
  Filter/Exclusion: Exclude emails sent from known automation accounts (e.g., [email protected]) or use a filter based on the sender_email field to exclude system-generated emails.

• Scenario: A user receives a legitimate email from a third-party service (e.g., Microsoft 365, Google Workspace) that mimics internal communication.
  Filter/Exclusion: Exclude emails from known trusted domains (e.g., @microsoft.com, @google.com) or use a filter based on the sender_domain field to exclude external service emails.

• Scenario: An IT support team member sends an email to multiple users to inform them about a security update or policy change.
  Filter/Exclusion: Exclude emails sent from known support accounts (e.g., [email protected]) or use a filter based on the sender_email field to exclude internal communication emails.

• Scenario: A user receives a legitimate email from a partner or vendor that uses the company’s domain in the email header for branding purposes.
  Filter/Exclusion: Exclude emails where the from field does not match the actual sender’s domain or use a filter based on the header_from field to exclude emails with mismatched domains.