Top External Recipients Receiving Auto-forwarded Email (Mailbox Rule and SMTP)

Hunt Hypothesis

This hypothesis targets adversaries who establish persistent email forwarding rules to exfiltrate sensitive data or maintain covert communication channels, aligning with MITRE techniques T1114 (Network Sniffing) and T1020 (Automated Exfiltration). Proactively hunting for these patterns in Azure Sentinel is critical because automated forwarding to external domains often bypasses standard user awareness, allowing threat actors to siphon information or receive command-and-control instructions without triggering immediate user suspicion.

KQL Query

EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Outbound" and isnotempty(ForwardingInformation)
| extend Key = strcat(NetworkMessageId, '-', RecipientEmailAddress)
| summarize arg_max(Timestamp, *) by Key
| extend FwdInfo = parse_json(ForwardingInformation)
| extend ForwardingType = tostring(FwdInfo.ForwardingType),
         ForwardingUser = tostring(FwdInfo.ForwardingUser)
| summarize ForwardedMessages = count(),
            ForwardingUsers = dcount(ForwardingUser)
    by RecipientEmailAddress, ForwardingType
| top 20 by ForwardedMessages

Analytic Rule Definition

id: db98ab11-e0c2-4ece-9b31-1131bbdd7647
name: Top External Recipients Receiving Auto-forwarded Email (Mailbox Rule and SMTP)
description: |
  This query lists the top external recipients receiving automatically forwarded email, by forwarding type, using the EmailEvents table.
description-detailed: |
  Auto-forwarding to an external recipient is a common data-exfiltration technique after mailbox compromise. This query ranks the external recipient addresses receiving auto-forwarded mail, split by forwarding type (mailbox rule versus SMTP forwarding), with the count of forwarded messages and the distinct internal forwarding users. External addresses receiving high volumes from one or more internal users are worth investigating.
  This query is part of the Microsoft Defender for Office 365 Detections and Insights workbook in Microsoft Sentinel: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/part-3-build-custom-email-security-reports-with-power-bi-and-workbooks-in-micros/4490127
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - EmailEvents
tactics:
  - Collection
  - Exfiltration
relevantTechniques:
  - T1114
  - T1020
query: |
  EmailEvents
  | where Timestamp > ago(30d)
  | where EmailDirection == "Outbound" and isnotempty(ForwardingInformation)
  | extend Key = strcat(NetworkMessageId, '-', RecipientEmailAddress)
  | summarize arg_max(Timestamp, *) by Key
  | extend FwdInfo = parse_json(ForwardingInformation)
  | extend ForwardingType = tostring(FwdInfo.ForwardingType),
           ForwardingUser = tostring(FwdInfo.ForwardingUser)
  | summarize ForwardedMessages = count(),
              ForwardingUsers = dcount(ForwardingUser)
      by RecipientEmailAddress, ForwardingType
  | top 20 by ForwardedMessages
version: 1.0.0

Required Data Sources

MITRE ATT&CK Context

• Tactic: Collection
• Tactic: Exfiltration
• Technique: T1114 — T1114
• Technique: T1020 — T1020

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/Microsoft 365 Defender/Email and Collaboration Queries/Mailflow/Top External Recipients Receiving Auto-forwarded Email.yaml)

False Positive Guidance

• Shared Mailbox Auto-Forwarding for Ticketing Systems

  • Scenario: A shared mailbox (e.g., support@company.com) has a mailbox rule configured to automatically forward all incoming emails to an external ticketing system API endpoint (e.g., api.zendesk.com or service.jira.com) to trigger automated workflow updates. This is a standard integration pattern for ITSM tools.
  • Filter/Exclusion: Exclude recipients where the domain matches known ticketing/ITSM vendors (e.g., zendesk.com, jira.com, servicenow.com) or exclude senders that are shared mailboxes identified by specific attributes (e.g., MailboxType -eq "Shared").

• Dedicated External Notification Mailboxes for Monitoring

  • Scenario: A monitoring or alerting system (e.g., Datadog, Splunk, or a custom Python script) uses a dedicated internal mailbox to receive alerts and then auto-forwards them to an external on-call rotation service (e.g., PagerDuty webhook endpoint or Opsgenie API) or a third-party status page updater.
  • Filter/Exclusion: Exclude recipients associated with known monitoring/on-call platforms (e.g., pagerduty.com, opsgenie.com, statuspage.io) or exclude senders that are service accounts with specific naming conventions (e.g., svc-monitoring, alert-bot).

• Legal Hold or eDiscovery External Archive Synchronization

  • Scenario: A legal or compliance team uses a mailbox rule to auto-forward specific categories of email (e.g., contracts, audit logs) to an external eDiscovery vendor’s ingestion endpoint (e.g., relay.northdata.com or api.relativity.com) for long-term storage and processing.