Isolating Malicious Exchange Inbox Rules: Preventing Wire Fraud & BEC Loops

An unexpected inbox rule can be an important clue during a business email compromise investigation, especially if it hides, deletes, redirects, or forwards messages. It is still a clue, not a verdict. A rule may be legitimate, created by an administrator, or part of a user’s normal workflow. Preserve the evidence and establish who created it, when it changed, what it does, and whether surrounding activity supports the concern.

Begin with a mailbox and time window approved for the investigation. Use a read-only configuration view and include hidden rules when the assigned role and environment support that query. Limit the output to relevant condition and action fields, and handle forwarding destinations as sensitive personal or business data. Do not paste the mailbox’s full rule set into a general chat prompt.

$mailbox = '<approved-mailbox-to-review>'
Get-InboxRule -Mailbox $mailbox -IncludeHidden -ResultSize 100 |
  Select-Object Name, Enabled, Priority, RedirectTo, ForwardTo,
    ForwardAsAttachmentTo, DeleteMessage, MoveToFolder, StopProcessingRules

This example is illustrative and read-only. It uses a placeholder, not a real address, and a fixed maximum of 100 results. It does not call Set-InboxRule, disable a rule, delete a rule, change mailbox forwarding, or run an arbitrary AI-supplied command. If more than 100 rules may exist, mark collection as partial rather than implying that the returned page is exhaustive.

Review actions that could conceal business correspondence: redirecting messages externally, forwarding as an attachment, moving invoices or security notices, deleting items, or stopping later rule processing. These actions can be consistent with fraud, but the same property may have an approved explanation. Validate the destination with an independent channel; do not reply to a suspicious message or trust contact details found inside it. Record the rule’s current state and preserve the operator who collected the evidence.

Next, correlate the current configuration with audit records. Microsoft documents the New-InboxRule, Set-InboxRule, and Remove-InboxRule operations and shows Search-UnifiedAuditLog for researching rule changes. A search should use a bounded date interval, appropriate operation filter, and a result limit. A missing audit row does not establish that a rule is safe: audit coverage, retention, query settings, permissions, and client behavior all affect what is available. The source result should retain its own collection timestamp and limitation statement.

For example, after connecting to Exchange Online PowerShell through the organization’s approved administrative process, a scoped audit search can look for rule changes. Replace the dates with the incident window and mailbox placeholder with an authorized value. Treat the output as sensitive evidence; this example is not executed by OpsPilot:

$start = [datetime]'2026-10-01T00:00:00Z'
$end = [datetime]'2026-10-08T00:00:00Z'
Search-UnifiedAuditLog -StartDate $start -EndDate $end `
  -FreeText '<approved-mailbox-to-review>' `
  -Operations New-InboxRule,Set-InboxRule,Remove-InboxRule `
  -ResultSize 100

A useful timeline compares the rule event with sign-in attempts, successful sign-ins, mailbox access, delegated access changes, forwarding configuration, and reports from the account owner. Use only sources available and authorized in the tenant. Keep actor identities, IP addresses, recipient addresses, and raw audit records in the approved incident system rather than a broad AI conversation. Ask the owner whether the rule, recipient, and timing are expected using a verified contact path.

Wire-fraud and BEC response is not a single rule operation. If a payment or bank-detail change is involved, follow the organization’s incident plan, contact the financial institution using a known number, and involve security and finance leadership. Preserve mail and audit evidence. Do not promise that removing a rule will recover messages, reverse a transfer, or establish account compromise. A detection report should separate observed facts from analyst hypotheses and immediate response decisions.

Avoid automatic remediation in the report pipeline. The PowerShell cmdlet Set-InboxRule changes existing conditions, exceptions, and actions. Microsoft documents that creating, modifying, removing, enabling, or disabling rules through Exchange PowerShell can remove client-side Outlook rules. Even when a rule is confirmed harmful, a separate operator should review the exact mailbox, rule identity, intended change, impact, rollback plan, and post-change verification. No detection output should execute a change by itself.

A concise evidence record includes the selected mailbox scope, query time, result cap, rule properties inspected, relevant audit operations and interval, missing sources, and analyst notes. Mark “no records returned” as an observation. Avoid labels such as “clean” or “malicious” until a human has reviewed enough context. Keep each data source’s limits visible when report sections are combined.

Sources: Get-InboxRule reference, Set-InboxRule behavior, identify mailbox-rule changes, and Search-UnifiedAuditLog reference. Permissions and retention depend on configuration.

Keep the source record, analysis, approval, and remediation as distinct events. If no suspicious change is found, say only that this bounded search found no matching evidence during the stated window. If a rule appears harmful, preserve its state before a separately approved response. This approach gives the incident team a defensible path without turning an investigative query into a mailbox-management action.