Suspicious email forwarding: establish where messages actually went

Integration scope: Seculogik uses a source-agnostic architecture to ingest security alerts and events through its own data map. Wazuh and OpenSearch are the first integrations. Other named sources describe planned connector targets; their availability must be confirmed for each evaluation.

An alert reports a new forwarding rule pointing to an unfamiliar address. Deleting the rule and resetting a password may feel like a complete response. Two questions still need answers: which messages actually followed that route, and what prevents the same access from creating it again?

MITRE ATT&CK documents forwarding-rule abuse as T1114.003, an email collection technique. Changing credentials can leave an existing forwarding configuration intact. This is a useful investigation hypothesis, not a reason to classify every forwarding rule as malicious. Source: MITRE ATT&CK, Email Forwarding Rule

This guide separates configuration, history and observed effects. Its technical examples use Exchange Online, but the investigation method does not depend on a particular SIEM or case-management tool. It makes no claim about available Seculogik product capabilities.

1. Keep three different states in the case

We recommend distinguishing what is configured, what was possible during the relevant period and what the evidence shows happened.

An enabled rule describes a processing instruction. Its existence does not establish that a message matched its conditions or that the destination received anything. Equally, a rule missing when an analyst investigates does not necessarily describe yesterday’s configuration.

Record the mailbox, organisation, detection time, earliest known change and exact destination. Include the reason for concern: an unfamiliar address, an unapproved change, an owner denying the action or messages disappearing. A harmless-looking rule name provides no assurance. An external domain alone does not establish an attack either.

Reach the mailbox owner through a channel whose reliability has been established. If email may be compromised, avoid making it the sole channel for validating its own security.

2. Capture the mechanism before changing it

Microsoft’s compromised-account response guidance distinguishes mailbox-level forwarding from Inbox rules and recommends checking both. It includes hidden rules by using Get-InboxRule with IncludeHidden. Source: Microsoft, responding to a compromised email account

For an authorised investigator, these two reads are a starting point. Substitute the exact mailbox identity:

Get-Mailbox -Identity <mailbox> |
  Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Get-InboxRule -Mailbox <mailbox> -IncludeHidden |
  Format-List Identity,Name,Enabled,Description,RedirectTo,ForwardTo,ForwardAsAttachmentTo

Preserve the relevant rules’ full details, including conditions, exceptions, actions, enabled state and processing order. Record when and where each export was obtained. If several mailboxes are involved, or an actor held administrative rights, examine transport-level mechanisms rather than extending one mailbox’s findings to the whole organisation.

Keep collection proportionate. An initial case can often begin with identifiers, settings and event references without copying every message body. Do not delay urgent, authorised containment solely to capture a perfect snapshot. Document anything that could not be preserved.

3. Establish the recorded actor and the change

Microsoft identifies New-InboxRule, Set-InboxRule and Remove-InboxRule as operations for investigating rule creation, modification and deletion. Its guidance separates current-state inspection from historical audit searches. Source: Microsoft, identifying mailbox rule changes

Mailbox-level forwarding follows another path: Microsoft describes investigating Set-Mailbox activity and its parameters to identify who configured it. Searching only for new Inbox rules can therefore miss the relevant change. Source: Microsoft, audit-log investigation scenarios

Our recommendation is to join each change to the recorded technical identity, target mailbox, timestamp and available parameters. Compare that evidence with approved changes and sign-in context. The recorded identity attributes an operation to an account or technical context; it does not by itself identify the human controlling it.

Avoid filtering only on the mailbox owner. An administrator or another authorised actor may have made the change. When a search returns nothing, check its scope and filters before treating the empty result as a finding.

4. Reconstruct the actual message route

Exchange Online message trace describes how the service handled messages and reports states such as receipt, rejection, deferral and delivery. Available periods, delays and result limits vary by report type. Source: Microsoft, message trace in Exchange Online

Build an evidence record connecting relevant messages, recipients, times and observed states. Separate confirmed delivery to the suspicious destination, blocked attempts and messages whose outcome remains unresolved. A transport state does not establish that a person read the content.

Review the controls that could have applied. Microsoft documents multiple external-forwarding controls, including outbound spam policies, remote domains and mail-flow rules. Forwarding configuration alone therefore does not describe the effective outcome. Source: Microsoft, controlling automatic external forwarding

Do not use today’s policy as automatic proof that yesterday’s messages were blocked. Seek its history where available. An internal destination also needs context: who could access that mailbox, and what happened to messages after they reached it?

5. Bound the exposure without inventing a total

We recommend reporting a period supported by recovered evidence, followed by any possible but unresolved period. The former starts with the observations available; it does not claim to locate the incident’s true beginning.

Document collection, retention and search limitations. Verify which activities were audited and available in the environment. Microsoft distinguishes owner, delegate and administrator contexts and documents audit settings and exceptions. Source: Microsoft, managing mailbox auditing

A fictional case statement might read: “The retrieved traces confirm delivery to the examined destination for the messages referenced in this case. Available records do not cover every other message in the period.” Neither “the entire mailbox was exfiltrated” nor “no data left” follows from that statement.

Bring in the appropriate owners to assess the consequences for the data categories actually involved. The SOC supplies evidence and its limitations; it does not replace business or legal decisions.

6. Verify a targeted response

The response plan should address both the unwanted forwarding mechanism and the access that created it. Changes, revocations and restrictions belong with authorised responders, with an explicit scope and consideration for legitimate business use.

We recommend four closure checks:

1. Read the configuration again after the change instead of relying solely on a successful command response.
2. Verify that the suspicious access has been addressed according to its mechanism, without assuming one action closes every route.
3. If a test is needed, use a synthetic message containing no sensitive data and destinations under your control. Never reactivate forwarding to the suspicious destination to test it.
4. Set an observation window for recurring changes and traffic, with an owner and a clear closure criterion.

The completed case should make five answers easy to find: which change was unauthorised, which effects are established, what remains outside visibility, what action was taken and which check demonstrates its effect?

For a related access path, see our guide to application access granted through OAuth consent. Follow that path when the case evidence calls for it, rather than treating forwarding as the whole incident.