Spoof and impersonation detections by sender IP

Hunt Hypothesis

Adversaries may spoof sender IP addresses to impersonate legitimate users or systems, enabling phishing or credential theft. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate potential impersonation attacks before they lead to data exfiltration or lateral movement.

KQL Query

EmailEvents 
|where Timestamp > ago (30d) and (DetectionMethods contains 'spoof' or DetectionMethods contains "impersonation")  
| project Timestamp, EmailDirection, SenderFromAddress, AdditionalFields, SenderIPv4 
| summarize count() by SenderIPv4

Analytic Rule Definition

id: b3180ac0-6d94-494a-8b8c-fcc84319ea6e
name: Spoof and impersonation detections by sender IP
description: |
  This query helps reviewing count of spoof and impersonation detections done per sender IP
description-detailed: |
  This query helps reviewing count of spoof and impersonation detections done per sender IP using Defender for Office 365 data.
  Reference - https://techcommunity.microsoft.com/t5/microsoft-defender-for-office/email-protection-basics-in-microsoft-365-spoof-and-impersonation/ba-p/3562938#:~:text=It%20detects%20impersonation%20based%20on%20each%20user%E2%80%99s%20individual
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - EmailEvents
tactics:
  - InitialAccess
relevantTechniques:
  - T1566
query: |
  EmailEvents 
  |where Timestamp > ago (30d) and (DetectionMethods contains 'spoof' or DetectionMethods contains "impersonation")  
  | project Timestamp, EmailDirection, SenderFromAddress, AdditionalFields, SenderIPv4 
  | summarize count() by SenderIPv4
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/Spoof and impersonation detections by sender IP.yaml)

False Positive Guidance

• Scenario: Legitimate scheduled job using cron or task scheduler to send automated reports
  Filter/Exclusion: Exclude IP addresses associated with internal cron jobs or scheduled tasks (e.g., 10.0.0.0/8 or specific hostnames like report-scheduler.example.com)

• Scenario: System administrator using ssh to remotely manage servers and send logs via scp or sftp
  Filter/Exclusion: Exclude IPs from known admin workstations or use user field to filter out admin accounts (e.g., root, admin, sysadmin)

• Scenario: Internal tool like Ansible or Puppet performing configuration pushes to multiple hosts
  Filter/Exclusion: Exclude IPs from known orchestration tools or use destination field to filter out internal hosts (e.g., 192.168.1.0/24)

• Scenario: Email relay from a legitimate email server using Postfix or Exchange for internal communication
  Filter/Exclusion: Exclude IPs from internal email servers or use sender field to filter out known internal email domains (e.g., @internal.corp.com)

• Scenario: Log collection agent like Fluentd or Logstash sending logs to a central logging server
  Filter/Exclusion: Exclude IPs from log aggregation tools or use source field to identify log collection agents (e.g., log-agent-01.example.com)