Agent Foskett Investigation • Exchange Online • Mail Flow Rules • AuditLogs • EmailEvents • KQL
The Mailbox Wasn't Forwarding — But the Transport Rule Was
Finance reported that sensitive messages were reaching an external address.
The obvious place to look was mailbox forwarding.
Forwarding address: empty.
Inbox rules: clean.
No obvious redirect on the user's mailbox.
Yet the messages were still leaving Microsoft 365.
Agent Foskett widened the investigation from the mailbox to the organisation's mail flow configuration.
The mailbox wasn't forwarding anything. The transport rule was.
The Mailbox Was Clean Because the Forwarding Lived Somewhere Else
When email is being redirected, do not stop at mailbox settings and inbox rules. Organisation-level mail flow configuration can change delivery before the user ever sees the message.
✓ Verify mailbox forwarding
✓ Check inbox-rule evidence
✓ Investigate transport-rule changes
The obvious checks found nothing
The investigation began where most analysts would begin: the affected mailbox. But neither mailbox forwarding nor the user's inbox rules explained why messages were reaching an external recipient. That meant the mail path itself needed investigation.
Mailbox forwarding was emptyNo configured forwarding address explained the external delivery.
Inbox rules looked cleanThe user's visible mailbox rules did not contain the redirect.
External delivery was realMessage telemetry still showed mail reaching a destination outside the expected organisation.
Start with the affected messages
Use Defender XDR email telemetry to establish which messages were involved, who sent them, who received them and when the suspicious delivery occurred. This creates the time window for the configuration investigation.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
EmailEvents
| where Timestamp > ago(7d)
| where RecipientEmailAddress =~ "finance@contoso.com"
or SenderFromAddress =~ "finance@contoso.com"
| project Timestamp,
NetworkMessageId,
SenderFromAddress,
RecipientEmailAddress,
Subject,
DeliveryAction,
DeliveryLocation
| order by Timestamp ascConfirm there wasn't a mailbox rule story
Before moving away from the mailbox, review the available audit evidence for inbox-rule creation or modification. A clean current rule list is useful, but historical audit events matter because a malicious rule may have been changed or removed before the investigation began.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 13
- 14
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload == "Exchange"
| where Operation in
("New-InboxRule", "Set-InboxRule", "Remove-InboxRule")
| where UserId =~ "finance@contoso.com"
| project TimeGenerated,
Operation,
UserId,
ClientIP,
Parameters,
ResultStatus
| order by TimeGenerated ascThen the investigation moved to mail flow
Exchange Online transport rules — also known as mail flow rules — operate at the organisation level. A rule can inspect messages and take actions such as redirecting, adding recipients or modifying delivery. That makes transport-rule audit activity essential when mailbox-level evidence does not explain the behaviour.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload == "Exchange"
| where Operation in
("New-TransportRule",
"Set-TransportRule",
"Remove-TransportRule")
| project TimeGenerated,
Operation,
UserId,
ClientIP,
Parameters,
ResultStatus
| order by TimeGenerated ascThe new rule appeared just before the first redirected message
The timeline contained the key correlation. A transport rule had been created shortly before the first suspicious mail delivery. The rule parameters became the next evidence source: conditions, target addresses and redirect-related actions needed to be inspected rather than inferred from the rule name.
09:14 — rule createdAn Exchange Online mail flow rule appeared in the audit trail.
09:21 — first affected messageEmail telemetry showed the first message in the suspicious delivery sequence.
Rule parameters matched the storyThe recorded configuration identified conditions and actions relevant to the affected mail flow.
Inspect the rule parameters
The Parameters field can preserve the values supplied when an Exchange administrative operation was performed. Expand or search those values for external addresses, redirect actions and conditions associated with the affected users or message types.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
OfficeActivity
| where TimeGenerated > ago(30d)
| where Operation in
("New-TransportRule", "Set-TransportRule")
| extend RuleParameters = tostring(Parameters)
| where RuleParameters has_any
("RedirectMessageTo",
"BlindCopyTo",
"AddToRecipients")
| project TimeGenerated,
Operation,
UserId,
ClientIP,
RuleParameters
| order by TimeGenerated ascWho created or changed the rule?
A suspicious rule is only part of the incident. Identify the administrative identity and source context associated with the change, then pivot into Microsoft Entra sign-ins for that account. This helps determine whether the rule was an authorised mail-flow change, an administrator mistake or activity occurring during an account compromise.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let Admin = "exchangeadmin@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ Admin
| project TimeGenerated,
AppDisplayName,
IPAddress,
ResultType,
ConditionalAccessStatus,
DeviceDetail,
LocationDetails
| order by TimeGenerated ascScope the rule's potential impact
Do not assume the investigation is limited to the mailbox that first reported the problem. Review the rule conditions and use available email telemetry to identify other messages, senders or recipients that may have matched during the period the rule was active.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
EmailEvents
| where Timestamp between
(datetime(2026-08-25 09:14:00) ..
datetime(2026-08-25 12:30:00))
| summarize Messages=count(),
Senders=dcount(SenderFromAddress),
Recipients=dcount(RecipientEmailAddress)
by DeliveryAction, DeliveryLocation
| order by Messages descCurrent configuration and historical evidence are different
If the rule has already been disabled or removed, the current Exchange configuration may look clean. That does not erase the interval during which the rule existed. Preserve the audit timeline and message evidence before treating removal as proof that no exposure occurred.
Current stateDetermine whether the transport rule is still enabled, disabled or removed.
Historical stateUse audit events to reconstruct when the rule was created, modified and removed.
Message impactUse email telemetry and available message tracing evidence to establish which communications were affected.
What the evidence can and cannot prove
A transport-rule audit event can prove that an administrative configuration change occurred. Message telemetry can support the delivery timeline. Correlation between the two can be powerful, but do not attribute malicious intent solely from the existence of a redirect rule. Validate the administrator, business purpose, rule parameters and affected messages.
ProvenThe audit trail can establish who performed a recorded mail-flow rule operation and when it occurred.
CorrelatedMessage activity beginning immediately after the rule change can connect configuration and observed impact.
Requires validationWhether the change was malicious, accidental or authorised depends on the wider evidence.
Agent Foskett's investigation mindset
Email delivery is bigger than the mailbox. If forwarding evidence does not exist where you expected it, widen the investigation to the controls that can change mail flow elsewhere in Microsoft 365.
Don't stop at inbox rulesMailbox rules are one mechanism, not the entire mail-delivery path.
Follow configuration changesAdministrative audit events can explain behaviour that user-facing mailbox settings cannot.
Scope beyond one userOrganisation-level rules may affect many messages or recipients depending on their conditions.
Investigation findings
The affected mailbox did not contain the forwarding configuration the team expected to find. Instead, Exchange Online audit telemetry showed a transport rule created shortly before the suspicious deliveries began. The rule parameters, administrative identity and message timeline gave the investigation a new path: from an apparently clean mailbox to an organisation-level mail-flow change.
The mailbox was not the mechanismMailbox forwarding and inbox rules did not explain the external delivery.
The mail-flow audit exposed the changeA transport-rule operation aligned with the beginning of the suspicious message activity.
The scope became organisationalThe team investigated every message that could have matched the rule rather than only the mailbox that reported the issue.
Related Agent Foskett investigations
Continue with Microsoft 365 email, mailbox and identity investigations.
The Inbox Rule That Shouldn't ExistInvestigate suspicious mailbox-rule persistence and message manipulation.The User Clicked Accept… And Gave Away The Entire MailboxFollow OAuth consent into mailbox access and identity compromise.Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
Final thought
A clean mailbox does not prove clean mail flow. Exchange Online contains organisation-level controls capable of changing where messages go without creating an obvious forwarding entry inside the affected user's mailbox. Follow the message, follow the audit trail and inspect the configuration that existed at the time. The mailbox tells you what the user can see. The mail-flow logs can tell you what happened before the message got there.
Where did the message go?Establish the affected mail and delivery timeline first.
What changed the route?Investigate mailbox rules and organisation-level mail-flow configuration.
Who changed it?Correlate Exchange administrative activity with the identity and sign-in evidence.
