SecOps Mailbox Override Count

Hunt Hypothesis

This hypothesis targets adversaries who exploit overly permissive mail flow rules to bypass standard security gates and deliver phishing payloads or malicious attachments directly to the security operations team. Proactively hunting for this anomaly in Azure Sentinel is critical because a compromised SecOps mailbox grants attackers a trusted vantage point to pivot laterally, manipulate incident responses, or escalate privileges within the organization.

KQL Query

EmailEvents
| where Timestamp > ago(30d)
| extend Key = strcat(NetworkMessageId, "-", RecipientEmailAddress)
| summarize arg_max(Timestamp, *) by Key
| where OrgLevelPolicy == "SecOps Mailbox" and OrgLevelAction == "Allow"
| summarize ['SecOps Mailbox Deliveries'] = count()

Analytic Rule Definition

id: d4a0f7f4-1c9b-4c2f-9644-2c53cfd7af0f
name: SecOps Mailbox Override Count
description: |
  This query counts inbound emails delivered to the SecOps mailbox by an organisation-level allow override.
description-detailed: |
  This query counts inbound emails delivered to the SecOps mailbox in Microsoft Defender for Office 365 as a result of an organisation-level allow override (OrgLevelPolicy == "SecOps Mailbox" and OrgLevelAction == "Allow"), so the volume of deliberately-allowed SecOps deliveries can be isolated from other admin overrides. Messages are de-duplicated to the latest record per NetworkMessageId and recipient.
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - EmailEvents
tactics:
  - InitialAccess
relevantTechniques:
  - T1566
query: |
  EmailEvents
  | where Timestamp > ago(30d)
  | extend Key = strcat(NetworkMessageId, "-", RecipientEmailAddress)
  | summarize arg_max(Timestamp, *) by Key
  | where OrgLevelPolicy == "SecOps Mailbox" and OrgLevelAction == "Allow"
  | summarize ['SecOps Mailbox Deliveries'] = count()
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/Overrides/SecOps Mailbox Override Count.yaml)

False Positive Guidance

• Automated Ticketing System Integration: Many ITSM platforms (e.g., ServiceNow, Jira Service Management) or security orchestration tools (e.g., Cortex XSOAR, Splunk SOAR) often use a dedicated service account or API to post updates, case closures, or automated alerts directly into the SecOps mailbox. If the “allow override” is configured broadly for the domain or specific sender groups, these high-volume, programmatic messages will trigger the count.

  • Filter/Exclusion: Exclude senders matching known service account patterns (e.g., *.svc@domain.com, automation@domain.com, or specific Jira/ServiceNow bot addresses) or filter by message subject lines containing standard automated tags like [Auto], System Update, or Ticket #.

• Scheduled Reporting Jobs: Enterprise reporting tools (e.g., Power BI, Tableau, or internal SQL Server Reporting Services) frequently schedule daily or weekly summary reports to be emailed to key stakeholders, including the SecOps team. These reports are often sent from a generic distribution list or a reporting server account that falls under the organization-level allow override.

  • Filter/Exclusion: Exclude emails from known reporting service accounts (e.g., reports@domain.com, bi-server@domain.com) or filter based on attachment types (e.g., .pdf, .xlsx) combined with specific subject keywords like “Daily Report,” “Weekly Summary,” or “KPI Dashboard.”

• Mailbox Delegation and Shared Inbox Access: In many enterprises, the SecOps mailbox is a shared resource accessed by multiple analysts or managers via Outlook delegation. When a user with delegation rights sends an email from the SecOps mailbox or forwards internal communications to it, some mail flow rules or gateway configurations may count these as “inbound” if the routing logic is not perfectly isolated. Additionally, if the allow override includes internal domain