Spam Detections (High) by delivery location

Hunt Hypothesis

Adversaries may be using compromised email accounts to send high-confidence spam emails from specific delivery locations to exfiltrate data or spread malware. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify potential command and control channels or phishing campaigns originating from known malicious regions.

KQL Query

EmailEvents
| where OrgLevelPolicy != "Phishing simulation" and OrgLevelPolicy != "SecOps Mailbox"
| where ConfidenceLevel has_any ('Spam":"High')
| summarize count() by LatestDeliveryLocation
| sort by count_ desc
| render piechart

Analytic Rule Definition

id: 42b9d582-8519-4217-a6b3-996326e55257
name: Spam Detections (High) by delivery location
description: |
  This query visualises emails with Spam detections (High confidence) summarizing the data by Delivery Location.
description-detailed: |
  This query visualises emails with Spam detections (High confidence) summarizing the data by Delivery Location which are subject to User/Admin overrides and Policy actions.
  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: |
  EmailEvents
  | where OrgLevelPolicy != "Phishing simulation" and OrgLevelPolicy != "SecOps Mailbox"
  | where ConfidenceLevel has_any ('Spam":"High')
  | summarize count() by LatestDeliveryLocation
  | sort by count_ desc
  | render piechart
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/Mailflow/Spam Detections by Delivery Location - High.yaml)

False Positive Guidance

• Scenario: Scheduled Email Reports from SIEM Tool
  Description: A SIEM tool like Splunk or IBM QRadar generates daily reports that include email headers and are mistakenly flagged as spam due to the presence of “spam” in the subject or body.
  Filter/Exclusion: Exclude emails where the source is a known SIEM tool or where the email is part of a scheduled report (e.g., source = "Splunk" OR email_subject LIKE "%Daily Report%").

• Scenario: Internal Email Notifications from Collaboration Tools
  Description: Emails sent by internal collaboration tools like Microsoft Teams or Slack to notify users of activity or updates may contain spam-like headers or content due to automated messages.
  Filter/Exclusion: Exclude emails where the sender is an internal service account (e.g., from = "teams@company.com" OR from = "slack@company.com") or where the email is part of a notification system.

• Scenario: Automated System Alerts via Email
  Description: System alerts or notifications sent via email by tools like Nagios, Puppet, or Ansible may be flagged as spam due to the use of terms like “alert” or “error” in the subject line.
  Filter/Exclusion: Exclude emails where the sender is a system alert account (e.g., from = "nagios@company.com") or where the email is part of an automated alerting system.

• Scenario: User-Generated Email with “Spam” in Subject
  Description: Employees may use the word “spam” in the subject line of legitimate emails (e.g., “Spam Filter Test” or “Spam Report”).
  Filter/Exclusion: Exclude emails where the sender is a known internal user or where the subject line contains “Spam” as part of a test or report (e.g., `from