Financial Theft — BEC Invoice Redirect - Hidden Inbox Rule Paired With Fraudulent Wire Transfer Instructions to Accounts Payable
Business Email Compromise crews executing invoice-redirect wire fraud follow a consistent two-step pattern once they have obtained credentials or an active session for a vendor-facing or internal finance mailbox (typically via phishing, MFA fatigue, or token theft — see THREAT-BEC-OAuthDeviceCode for the initial-access variant). First, the attacker creates or modifies an Exchange inbox rule that silently moves or deletes incoming messages containing invoice/payment-related keywords into Deleted Items, RSS Feeds/Subscriptions, or an obscure archive folder, so the legitimate mailbox owner never sees replies, confirmation calls, or the real vendor's follow-up correspondence about the transaction in flight. Second, from that same compromised mailbox (or a lookalike domain impersonating it), the attacker sends or replies to an active invoice/payment thread with 'updated' banking details — a new account number, routing number, or IBAN/SWIFT code — asking accounts payable or a customer to redirect an upcoming wire transfer. Individually, a new inbox rule or a payment-detail-change email can look mundane; the correlation of a hiding-behavior rule (move-to-folder or delete, scoped to invoice/payment terms) created on a mailbox, followed within a short window by an outbound email from that same mailbox to an accounts-payable/finance alias referencing altered banking instructions, is a high-fidelity indicator of active invoice-redirect fraud rather than routine mailbox housekeeping. Detection correlates Exchange admin audit events (New-InboxRule/Set-InboxRule in OfficeActivity) with Microsoft Defender for Office 365 mail flow telemetry (EmailEvents) for the same sending identity.
What is THREAT-BEC-InvoiceRedirectWireFraud BEC Invoice Redirect - Hidden Inbox Rule Paired With Fraudulent Wire Transfer Instructions to Accounts Payable?
BEC Invoice Redirect - Hidden Inbox Rule Paired With Fraudulent Wire Transfer Instructions to Accounts Payable (THREAT-BEC-InvoiceRedirectWireFraud) is a sub-technique of Financial Theft (T1657) in the MITRE ATT&CK framework. It maps to the Impact tactic — the adversary is trying to manipulate, interrupt, or destroy your systems and data.
This page provides production-ready detection logic for BEC Invoice Redirect - Hidden Inbox Rule Paired With Fraudulent Wire Transfer Instructions to Accounts Payable, covering the data sources and telemetry it touches: Microsoft 365 Unified Audit Log (Exchange admin audit events), Microsoft Defender for Office 365 (EmailEvents advanced hunting table), Microsoft Sentinel OfficeActivity table. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Impact
let Lookback = 14d;
let CorrelationWindow = 48h;
let PaymentKeywords = dynamic(["invoice", "remittance", "wire transfer", "bank details", "account number", "routing number", "payment instructions", "iban", "swift", "ach", "updated banking", "new bank"]);
let FinanceRecipients = dynamic(["ap@", "accountspayable@", "accounts.payable@", "finance@", "payments@", "treasury@"]);
let SuspiciousRules = OfficeActivity
| where TimeGenerated > ago(Lookback)
| where OfficeWorkload == "Exchange"
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend ParamText = tostring(Parameters)
| where ParamText has_any ("MoveToFolder", "DeleteMessage", "Delete")
| where ParamText has_any (PaymentKeywords)
| extend MailboxOwner = tolower(tostring(UserId))
| project RuleTime = TimeGenerated, MailboxOwner, ParamText, ClientIP;
EmailEvents
| where TimeGenerated > ago(Lookback)
| where Subject has_any (PaymentKeywords)
| extend SenderLower = tolower(SenderFromAddress)
| where RecipientEmailAddress has_any (FinanceRecipients)
| join kind=inner (SuspiciousRules) on $left.SenderLower == $right.MailboxOwner
| where (TimeGenerated - RuleTime) between (0min .. CorrelationWindow)
| project TimeGenerated, SenderFromAddress, RecipientEmailAddress, Subject, RuleTime, ParamText, ClientIP
| sort by TimeGenerated desc Joins Exchange admin audit events (OfficeActivity, Operation in New-InboxRule/Set-InboxRule) where the rule's action moves-to-folder or deletes messages AND the rule's conditions target invoice/payment keywords, against outbound mail from that same mailbox (EmailEvents) sent to an accounts-payable/finance-style recipient with a subject referencing invoice, banking, or payment-instruction language. A match within 48 hours of the rule's creation indicates the mailbox owner concealed inbound correspondence about the exact transaction they then used to solicit a payment redirect — the defining signature of invoice-redirect BEC rather than two unrelated benign events.
Data Sources
Required Tables
False Positives
- Legitimate finance/vendor-management inbox rules that route invoice emails into a dedicated 'AP Processing' or 'Invoices' folder as part of normal workflow automation, rather than to Deleted Items, RSS Feeds/Subscriptions, or Archive
- A real vendor legitimately updating its banking details through an authorized annual vendor-refresh or procurement onboarding campaign, verified out-of-band before the correlated rule was created for an unrelated reason
- A shared support/ticketing mailbox with a rule that moves messages containing 'payment' or 'invoice' into a triage folder for a helpdesk team, combined with an unrelated automated billing-system notification to a finance alias
- IT-driven mailbox migration or retention-policy cleanup that creates bulk move-to-folder rules referencing generic keyword sets across many mailboxes at once, including some that overlap with payment terminology
Sigma rule & cross-platform mapping
The detection logic for BEC Invoice Redirect - Hidden Inbox Rule Paired With Fraudulent Wire Transfer Instructions to Accounts Payable (THREAT-BEC-InvoiceRedirectWireFraud) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
product: azure Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for THREAT-BEC-InvoiceRedirectWireFraud
References (6)
- https://attack.mitre.org/techniques/T1657/
- https://attack.mitre.org/tactics/TA0040/
- https://www.ic3.gov/Media/Y2023/PSA230609
- https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-outlook-rules-forms-attack
- https://learn.microsoft.com/en-us/defender-office-365/advanced-hunting-emailevents-table
- https://learn.microsoft.com/en-us/powershell/module/exchange/new-inboxrule
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate Hiding Inbox Rule Scoped to Payment Keywords
Expected signal: OfficeActivity entry with Operation='New-InboxRule', OfficeWorkload='Exchange', UserId matching the test mailbox, and Parameters JSON containing MoveToFolder targeting 'Deleted Items' plus the SubjectOrBodyContainsWords condition list.
- Test 2Simulate Fraudulent Payment-Redirect Email to Test AP Alias
Expected signal: EmailEvents entry with SenderFromAddress matching the test mailbox, RecipientEmailAddress matching the test AP alias, and Subject/body containing payment-instruction and banking-detail keywords.
- Test 3Simulate Full Chained Sequence Within Correlation Window
Expected signal: An OfficeActivity New-InboxRule entry immediately followed by an EmailEvents entry from the same mailbox to the test AP alias, both within seconds to minutes of each other.
Response Playbook
Triage
- Pull the full New-InboxRule/Set-InboxRule audit record for the flagged mailbox — confirm the rule's exact conditions (SubjectContainsWords, BodyContainsWords, FromAddressContainsWords) and actions (MoveToFolder target, DeleteMessage, StopProcessingRules) to verify it is genuinely hiding replies rather than a benign folder-organization rule
- Retrieve the correlated outbound email in full: sender, all recipients (including Cc/Bcc), exact banking details referenced (account/routing number, IBAN/SWIFT), and whether it is a reply within an existing thread or a newly initiated message — a reply within an existing legitimate invoice thread is much higher confidence than a cold message
- Check sign-in logs (SigninLogs/AADSignInLogs) for the mailbox owner around the time the inbox rule was created for anomalous authentication: new device, atypical location/ASN, legacy auth protocol, or impossible travel relative to the owner's normal pattern
- Determine whether the sending domain is the organization's own verified domain or a lookalike/typosquat domain, and check SPF/DKIM/DMARC authentication results on the flagged message
- Search for other mailboxes with similarly-scoped inbox rules created in the same time window by the same client IP or user agent, indicating a broader compromise or a scripted campaign against multiple finance-adjacent mailboxes
- Contact accounts payable/finance directly (via a known-good, out-of-band channel — phone, not email) to confirm whether any payment was initiated or scheduled based on the flagged message, and whether it has already been released to the new banking details
Containment
- Disable or remove the malicious inbox rule immediately, and suspend the mailbox owner's active sessions/refresh tokens if account compromise is confirmed or suspected
- Place an immediate hold on any pending or scheduled wire transfer tied to the flagged invoice/payment thread — notify the bank's fraud department and request a recall if the transfer has already been released
- Reset the mailbox owner's credentials and re-register MFA through a verified channel; review and revoke any OAuth app consents or mail forwarding rules added around the same time
- Block the sending domain/IP if the message originated from a lookalike domain rather than the organization's own compromised mailbox, and add the fraudulent banking details as an indicator across the email security stack
- Notify all recipients of the fraudulent thread (internal and external) that the payment instructions are illegitimate, using a verified out-of-band channel
Evidence Collection
- Full OfficeActivity records for the New-InboxRule/Set-InboxRule operation, including the complete Parameters JSON showing conditions and actions
- Full message trace and EmailEvents records for the flagged email and the surrounding thread, including headers, SPF/DKIM/DMARC results, and any attachments (altered invoice PDFs are common)
- SigninLogs/AADSignInLogs for the mailbox owner covering the 7 days preceding the inbox rule creation
- Financial system records (AP system, banking portal) showing whether a payment was scheduled or released against the fraudulent banking details, and the transaction reference/wire confirmation if released
- A timeline correlating the original legitimate invoice thread, the inbox rule creation, and the fraudulent payment-redirect message for use in both incident response and any law-enforcement/bank-recall filing
Escalation Criteria
- ! A hiding-behavior inbox rule scoped to payment/invoice keywords is confirmed on a mailbox, correlated with an outbound payment-redirect message within the 48-hour window
- ! Any wire transfer has already been scheduled or released against the altered banking details — this requires immediate engagement with the bank's fraud/recall process and is time-critical (funds are frequently unrecoverable after 24-48 hours)
- ! Sign-in telemetry confirms the mailbox itself is compromised (as opposed to a lookalike-domain spoof), requiring full account takeover incident response
- ! Multiple mailboxes show the same rule pattern within the same time window, indicating a broader campaign rather than an isolated incident
Investigation Guide
Forensic Artifacts
- >
OfficeActivity New-InboxRule/Set-InboxRule audit entries with full Parameters JSON (conditions and actions) - >
EmailEvents / message trace records for the fraudulent payment-redirect email and the full original thread it replies within - >
SPF/DKIM/DMARC authentication results and header analysis (Authentication-Results, Received chain) for the flagged message - >
SigninLogs/AADSignInLogs for the mailbox owner in the days preceding the rule creation - >
AP/finance system payment-scheduling and release records tied to the affected invoice or vendor record
Tuning Guidance
Maintain an allowlist of known legitimate AP/finance-adjacent inbox rules (e.g. a shared AP mailbox's rule that files invoices into a processing folder) by mailbox and rule signature, since the keyword overlap between legitimate invoice triage and malicious concealment is high and rule name/target-folder is the most reliable discriminator — a MoveToFolder target of 'Deleted Items', 'RSS Feeds', 'RSS Subscriptions', or 'Archive' is far higher-confidence than a named business folder like 'AP Processing'. Extend FinanceRecipients and PaymentKeywords to match your organization's actual AP alias naming and language (adjust for non-English tenants). Treat any match where the message is a reply within an existing thread (In-Reply-To/References headers present) as materially higher confidence than a newly-initiated message, since replying inside a real thread requires either mailbox access or a convincing thread-hijack — validate against the second hunting query periodically since it does not depend on the rule ever being visible in-window. Correlate a firing alert with any concurrent account-compromise indicators (impossible travel, new OAuth app consent, legacy-auth sign-in) to distinguish attacker-driven concealment from a legitimate employee who independently created both artifacts by coincidence.
Hunting Queries
30-day baseline of all mailboxes creating move-to-folder/delete inbox rules, independent of keyword content, to establish which mailboxes routinely do this for legitimate organizational reasons versus first-time or anomalous rule creation worth individual review.
// Hunt: all hiding-behavior inbox rules (move-to-folder or delete) created in the last 30 days, regardless of keyword match, to baseline rule-creation volume per mailbox
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload == "Exchange"
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend ParamText = tostring(Parameters)
| where ParamText has_any ("MoveToFolder", "DeleteMessage", "Delete")
| extend MailboxOwner = tolower(tostring(UserId))
| summarize RuleCount = count(), Rules = make_set(ParamText, 10) by MailboxOwner, ClientIP
| order by RuleCount desc index=o365 sourcetype="o365:management:activity" Workload=Exchange (Operation="New-InboxRule" OR Operation="Set-InboxRule")
| eval ParamText=Parameters
| where match(ParamText, "(?i)(MoveToFolder|DeleteMessage|Delete)")
| eval MailboxOwner=lower(UserId)
| stats count as RuleCount, values(ParamText) as Rules by MailboxOwner, ClientIP
| sort - RuleCount Standalone hunt for banking-detail-change language sent to finance/AP mailboxes, run without the inbox-rule correlation, since the primary detection's 48-hour join window will miss cases where the concealment rule was created earlier or where the attacker never needed one (e.g. a lookalike-domain message with no legitimate reply thread to hide).
// Hunt: outbound emails referencing banking-detail changes sent to finance/AP recipients, without requiring a correlated inbox rule, to catch cases where the rule predates the lookback window
EmailEvents
| where TimeGenerated > ago(30d)
| where Subject has_any ("updated banking", "new bank", "routing number", "iban", "swift", "change of bank", "payment details update")
| where RecipientEmailAddress has_any ("ap@", "accountspayable@", "finance@", "payments@", "treasury@")
| project TimeGenerated, SenderFromAddress, RecipientEmailAddress, Subject
| order by TimeGenerated desc index=o365 sourcetype="o365:office365:email" (Subject="*updated banking*" OR Subject="*new bank*" OR Subject="*routing number*" OR Subject="*change of bank*" OR Subject="*payment details update*")
(RecipientEmailAddress="ap@*" OR RecipientEmailAddress="accountspayable@*" OR RecipientEmailAddress="finance@*" OR RecipientEmailAddress="payments@*" OR RecipientEmailAddress="treasury@*")
| table _time SenderFromAddress RecipientEmailAddress Subject
| sort - _time Atomic Red Team Tests
Creates a test inbox rule on a disposable test mailbox that moves messages containing invoice/payment keywords to Deleted Items, replicating the concealment step of the attack. Use only a synthetic test mailbox created specifically for this exercise, never a real user mailbox.
Command
Connect-ExchangeOnline; New-InboxRule -Mailbox [email protected] -Name "Archive" -SubjectOrBodyContainsWords "invoice","remittance","wire transfer","bank details","payment instructions" -MoveToFolder "[email protected]:\Deleted Items" -StopProcessingRules $true Cleanup
Remove-InboxRule -Mailbox [email protected] -Identity "Archive" -Confirm:$false Expected Telemetry
OfficeActivity entry with Operation='New-InboxRule', OfficeWorkload='Exchange', UserId matching the test mailbox, and Parameters JSON containing MoveToFolder targeting 'Deleted Items' plus the SubjectOrBodyContainsWords condition list.
Expected Detection
The SuspiciousRules sub-query matches on ParamText containing both a hiding action and a payment keyword for this mailbox.
Sends a test email from the same disposable test mailbox to a test accounts-payable alias, referencing updated banking details, replicating the payment-redirect step. Use only synthetic test accounts and clearly-fake banking details.
Command
Connect-MgGraph -Scopes "Mail.Send"; Send-MgUserMail -UserId [email protected] -Message @{ Subject = "Updated Invoice - Please Note New Bank Details"; Body = @{ ContentType = "Text"; Content = "Please update our payment instructions: new account number 000123456, routing number 000111222, effective immediately for the outstanding invoice." }; ToRecipients = @(@{ EmailAddress = @{ Address = "[email protected]" } }) } Cleanup
Delete the test message from Sent Items on the source mailbox and from the Inbox of the destination test AP alias; no production mail flow is affected since only synthetic test mailboxes are used. Expected Telemetry
EmailEvents entry with SenderFromAddress matching the test mailbox, RecipientEmailAddress matching the test AP alias, and Subject/body containing payment-instruction and banking-detail keywords.
Expected Detection
The EmailEvents leg of the join matches on Subject keyword and RecipientEmailAddress pattern for this message.
Runs the inbox-rule creation and the fraudulent payment-redirect email back-to-back within minutes on the same disposable test mailbox, replicating the complete attacker sequence the join-based detection is designed to catch. Run only against synthetic test accounts in a lab or sandbox tenant.
Command
New-InboxRule -Mailbox [email protected] -Name "Archive2" -SubjectOrBodyContainsWords "invoice","wire transfer","bank details" -MoveToFolder "[email protected]:\Deleted Items"; Send-MgUserMail -UserId [email protected] -Message @{ Subject = "Re: Invoice 4471 - Updated Wire Transfer Instructions"; Body = @{ ContentType = "Text"; Content = "Please use the updated bank details below for the pending wire transfer: routing number 000111222." }; ToRecipients = @(@{ EmailAddress = @{ Address = "[email protected]" } }) } Cleanup
Remove-InboxRule -Mailbox [email protected] -Identity "Archive2" -Confirm:$false; delete the test message from Sent Items and the destination test mailbox. Expected Telemetry
An OfficeActivity New-InboxRule entry immediately followed by an EmailEvents entry from the same mailbox to the test AP alias, both within seconds to minutes of each other.
Expected Detection
The full correlated KQL/SPL query fires, matching the rule and email within the 48-hour CorrelationWindow with a near-zero delta between RuleTime and TimeGenerated.
Related Detections
Tactic Hub
Detection Variants (1)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.