Microsoft 365 outbound connector rerouting
An outbound Exchange connector was created or modified — mail flow itself re-pointed at an external host.
What it detects
An outbound Exchange connector was created or modified — mail flow itself re-pointed at an external host.
Where an inbox rule diverts ONE mailbox, a connector diverts the TENANT. Routing outbound mail through an attacker's smart host puts every message the company sends through infrastructure they control, and it does so at a layer most incident response never looks at: the mailboxes are clean, the rules are clean, and the mail is still being read.
Connector changes are infrastructure work — planned, rare, and done by someone who can say why. That makes this both high-signal and cheap to confirm.
MITRE ATT&CK mapping
False positives and triage
Real connectors exist for real reasons — a hybrid on-premises Exchange, a third-party archiving or security gateway, a partner domain with enforced TLS — and each is a deliberate, documented change. The question is not whether connectors are legitimate but whether THIS change was: check the smart host in the record against the tenant's known mail infrastructure, and whether the actor administers mail flow as part of their job. An unfamiliar host, or any connector change close in time to an identity finding, should be treated as live rerouting until proven otherwise.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/m365_outbound_connector_rerouting.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_outbound_connector_rerouting
version: 1.0.0
status: stable
severity: critical
confidence: 0.7
platforms: [application]
mitre_techniques: [T1114, T1071.003]
description: |
An outbound Exchange connector was created or modified — mail flow itself
re-pointed at an external host.
Where an inbox rule diverts ONE mailbox, a connector diverts the TENANT. Routing
outbound mail through an attacker's smart host puts every message the company
sends through infrastructure they control, and it does so at a layer most
incident response never looks at: the mailboxes are clean, the rules are clean,
and the mail is still being read.
Connector changes are infrastructure work — planned, rare, and done by someone who
can say why. That makes this both high-signal and cheap to confirm.
match:
provider: Office365
event_action_any:
- New-OutboundConnector
- Set-OutboundConnector
- New-InboundConnector
- Set-InboundConnector
correlation_keys: [user_name]
false_positive_guidance: |
Real connectors exist for real reasons — a hybrid on-premises Exchange, a
third-party archiving or security gateway, a partner domain with enforced TLS —
and each is a deliberate, documented change. The question is not whether
connectors are legitimate but whether THIS change was: check the smart host in
the record against the tenant's known mail infrastructure, and whether the actor
administers mail flow as part of their job. An unfamiliar host, or any connector
change close in time to an identity finding, should be treated as live rerouting
until proven otherwise.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.