Automatic External Email Forwarding Overview by Type (Mailbox Rule and SMTP)

Hunt Hypothesis

This hypothesis targets adversaries who establish persistent external email forwarding mechanisms, such as mailbox rules or SMTP configurations, to exfiltrate sensitive data or maintain covert communication channels without triggering standard alerting. Proactively hunting for these configurations in Azure Sentinel is critical because they represent a low-noise persistence and exfiltration vector that can remain dormant and undetected until a significant data breach occurs.

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),
         RecipientDomain = tostring(split(RecipientEmailAddress, '@')[1])
| summarize ForwardedMessages = count(),
            ForwardingUsers = dcount(ForwardingUser),
            ExternalRecipients = dcount(RecipientEmailAddress),
            ExternalDomains = dcount(RecipientDomain)
    by ForwardingType
| sort by ForwardedMessages desc

Analytic Rule Definition

id: d05eb85d-16e6-4bb9-a669-78da03ec6417
name: Automatic External Email Forwarding Overview by Type (Mailbox Rule and SMTP)
description: |
  This query summarises automatic external email forwarding across the tenant by forwarding type (mailbox rule versus SMTP forwarding), using the EmailEvents table.
description-detailed: |
  A compromised mailbox is often configured to automatically forward mail to an external address to exfiltrate data. This query summarises outbound messages auto-forwarded to external recipients, split by forwarding type (MbxRule and SmtpForwarding), with the number of forwarding users, external recipients and external domains for each type. Use it to size the auto-forwarding exposure and spot unexpected forwarding activity.
  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),
           RecipientDomain = tostring(split(RecipientEmailAddress, '@')[1])
  | summarize ForwardedMessages = count(),
              ForwardingUsers = dcount(ForwardingUser),
              ExternalRecipients = dcount(RecipientEmailAddress),
              ExternalDomains = dcount(RecipientDomain)
      by ForwardingType
  | sort by ForwardedMessages desc
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/Automatic External Email Forwarding by Type.yaml)

False Positive Guidance

• Shared Mailbox for Customer Support or Service Desk

  • Scenario: A shared mailbox (e.g., support@company.com) has a permanent rule set by an administrator to automatically forward all incoming tickets to a third-party helpdesk platform (e.g., Zendesk, Jira Service Desk) or an internal SLA monitoring tool via SMTP. This is a standard integration pattern, not user behavior.
  • Filter/Exclusion: Exclude mailboxes where MailboxType is Shared or Resource, or specifically exclude known shared mailbox names (e.g., *support*, *service*, *tickets*) from the “Mailbox Rule” count if they are registered in a CMDB or security group.

• Automated Notification Pipelines (CI/CD or Monitoring)

  • Scenario: DevOps or SRE teams use SMTP relay addresses (e.g., alerts@company.com or ci-notifications@company.com) to receive automated alerts from monitoring tools like Datadog, Prometheus Alertmanager, or GitHub Actions. These addresses often have SMTP forwarding rules configured to route emails to Slack, PagerDuty, or internal dashboards.
  • Filter/Exclusion: Exclude SMTP forwarding events where the source mailbox matches known automation patterns (e.g., names containing alert, notify, ci, cd, bot) or where the destination domain is a known SaaS provider (e.g., @slack.com, @pagerduty.com, @jira.com).

• Legacy Application Integration

  • Scenario: Older on-premises applications or legacy SaaS tools that lack modern API integrations use SMTP forwarding from a dedicated mailbox (e.g., legacy-app@company.com) to push transactional emails (invoices, receipts, status updates) to an external database or archive