Detect BEC Financial Theft — Fraudulent Wire/ACH Transfer Initiation via Mailbox Tampering and Invoice Fraud in CrowdStrike LogScale
This detection covers the final, financially damaging stage of a Business Email Compromise (BEC) intrusion: fraudulent wire or ACH transfer initiation (T1657 — Financial Theft) that follows mailbox rule tampering and invoice/payment-detail modification. Having already gained access to a mailbox (via phishing, OAuth token theft, or credential stuffing), the attacker creates hidden inbox rules that forward, redirect, or delete messages matching finance-related keywords so the victim never sees replies from the real vendor or their own finance team. The attacker then sends or intercepts an invoice, purchase order, or payroll email and modifies the banking details — swapping the legitimate account/routing number or IBAN for an attacker-controlled mule account — while adding urgency language ("process today", "do not call, I am in a meeting") to pressure the victim into skipping out-of-band verification. Groups such as Cosmic Lynx (Russian-speaking, CEO-fraud wire transfers averaging $1.27M) and SilverTerrier (West African vendor-invoice-swap BEC) follow this exact three-stage pattern: mailbox tampering, payment-detail modification, then transfer initiation. Because banking-portal telemetry is rarely centralized in a SIEM, this detection correlates the two upstream stages that ARE consistently observable in mail and identity telemetry — malicious inbox rule creation and financial-fraud-pattern email content — as the highest-fidelity proxy for an active wire fraud attempt, with escalation criteria pointing responders at the actual funds-transfer confirmation step.
MITRE ATT&CK
- Tactic
- Impact
LogScale Detection Query
// BEC Financial Theft: Mailbox Tampering Correlated with Wire/ACH Fraud Email Content
#repo=base_activity
(
// Branch 1: mailbox rule tampering
Operation IN ["New-InboxRule", "Set-InboxRule", "Set-Mailbox", "UpdateInboxRules"]
AND Parameters = /(?i)(ForwardTo|RedirectTo|ForwardAsAttachmentTo|DeleteMessage|MoveToFolder)/
AND Parameters != /(?i)Junk Email/
AND EventSource = "O365"
| groupBy(
[UserId, ClientIP, Operation],
function=[
count(aid, as=RuleEvents),
min(timestamp, as=FirstSeen),
max(timestamp, as=LastSeen),
collect(Parameters, as=RuleParams)
]
)
| eval Stage = "MailboxTampering"
| sort(RuleEvents, order=desc)
)
UNION
(
// Branch 2: wire/ACH/bank-detail-change email with urgency language
EventSource = "O365"
AND Subject = /(?i)(wire transfer|ACH transfer|routing number|account number|swift code|IBAN|beneficiary|new bank details|change of bank account|payment instructions|vendor payment)/
AND Subject = /(?i)(urgent|immediately|ASAP|time sensitive|confidential|do not call|process today)/
| groupBy(
[UserId, SenderFromAddress, RecipientEmailAddress],
function=[
count(aid, as=EmailEvents),
min(timestamp, as=FirstSeen),
max(timestamp, as=LastSeen),
collect(Subject, as=Subjects)
]
)
| eval Stage = "FinanceFraudEmail"
| sort(EmailEvents, order=desc)
)CrowdStrike LogScale CQL detection split into two correlated branches for BEC wire/ACH financial theft: (1) mailbox rule tampering with forward/redirect/delete/move parameters, and (2) email content matching wire-transfer/bank-detail-change language paired with urgency-pressure phrasing. Results grouped by user for downstream correlation of both stages within a 72-hour window.
Data Sources
Required Tables
False Positives & Tuning
- AP/finance staff filing paid invoices via inbox rules coinciding with routine urgent payment confirmations
- Payroll automation mailboxes generating high-urgency payment email at pay-cycle close
Other platforms for THREAT-Impact-BECFinancialTheftWireTransfer
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 1Create BEC-Style Mailbox Forwarding Rule Targeting Finance Keywords
Expected signal: OfficeActivity records a New-InboxRule operation with Parameters containing ForwardTo, DeleteMessage, and the finance-related SubjectContainsWords condition.
- Test 2Send Simulated Vendor Invoice Email with Bank-Detail-Change and Urgency Language
Expected signal: EmailEvents records the inbound message with Subject matching finance/urgency keyword patterns; message trace shows sender domain external-test.com.
- Test 3End-to-End BEC Wire Fraud Simulation (Rule Tampering + Fraud Email in Sequence)
Expected signal: OfficeActivity and EmailEvents both record events for the same UserId within the 72-hour correlation window.
Response Playbook
Triage
- Identify the mailbox(es) flagged for rule tampering and pull all inbox rules currently active for that user (Get-InboxRule in Exchange Online PowerShell); confirm whether the forwarding/redirect/delete rule was created by the legitimate user (call them directly, do not use email or Teams if the account may be compromised).
- Pull the flagged finance-fraud email(s) and inspect the sender's actual return-path and reply-to address versus the display name — look for domain look-alikes (e.g. 'df00-tech.com' vs 'df00tech.com') or a mismatched reply-to that routes replies to an attacker-controlled address.
- Check whether the banking details (account number, routing number, IBAN, SWIFT code) in the flagged email differ from the last known-good banking details on file for that vendor/employee — compare against the AP vendor master or a prior undisputed invoice.
- Review Azure AD sign-in logs for the mailbox in the 24 hours preceding the rule creation for anomalous IP address, impossible travel, or new device/user-agent — evidence the mailbox itself was compromised rather than the request being a first-party spoof.
- Determine whether any payment was actually initiated or completed against the modified banking details by contacting Treasury/AP directly and checking the banking portal or ERP payment-approval queue for a pending or recent transaction matching the invoice/PO referenced in the email.
- Check for prior BEC precursor activity on the same mailbox: OAuth consent grants, MFA method changes, or other inbox rules created in the prior 30 days.
Containment
- If the mailbox is compromised, revoke all active sessions/refresh tokens immediately (Revoke-AzureADUserAllRefreshToken) and force a password reset plus MFA re-enrollment.
- Disable or delete the malicious inbox rule immediately so the victim regains visibility of the real vendor/finance thread.
- Place an immediate hold/stop-payment request with Treasury/AP and the receiving bank for any transaction matching the fraudulent banking details — banks can often recall ACH/wire transfers within 24-72 hours if notified quickly.
- Notify the actual vendor or employee (via a verified, out-of-band phone number pulled from an existing contract, not from the suspect email) that their invoice/payment details may have been spoofed.
- Block the sender domain/IP if external spoofing is confirmed, and quarantine any other emails from the same sender infrastructure across the tenant.
Evidence Collection
- Exchange Online: full inbox rule history for the affected mailbox (Get-InboxRule, Get-TransportRule) and the OfficeActivity audit trail of who created/modified each rule and from what IP.
- The flagged email(s) in full including headers (Received, Return-Path, Reply-To, Authentication-Results/SPF/DKIM/DMARC) to establish spoofing vs. genuine account compromise.
- Azure AD Sign-In logs for the mailbox covering 30 days prior to the incident.
- AP/Treasury payment records, banking portal transaction logs, and any wire/ACH confirmation for the referenced invoice or PO number.
- Any prior correspondence thread with the legitimate vendor/employee to compare banking details and writing style against the suspect email.
Escalation Criteria
- !Confirmation that a wire or ACH transfer was actually completed against the fraudulent banking details — escalate immediately to Treasury, Legal, and law enforcement (FBI IC3 / local field office) for a recall/reversal attempt, time-critical within the first 24-72 hours.
- !Evidence the compromised mailbox belongs to an executive (CEO/CFO) or has access to multiple finance workflows, indicating potential CEO-fraud targeting beyond a single vendor-invoice swap.
- !Multiple mailboxes across the organization show the same tampering pattern, indicating a broader compromise or coordinated campaign rather than an isolated incident.
- !The fraudulent banking details or sender infrastructure match known threat intelligence indicators (e.g. mule account patterns, known BEC infrastructure) warranting a formal incident declaration.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Exchange Online inbox rule audit trail (OfficeActivity: New-InboxRule/Set-InboxRule/Set-Mailbox operations, Parameters field) - >
Email headers of the fraudulent invoice/payment email: Return-Path, Reply-To, Received chain, SPF/DKIM/DMARC authentication results - >
AP/Treasury vendor master banking details history and change log - >
Azure AD Sign-In logs for the affected mailbox (IP, location, device, user-agent) around the rule creation timestamp - >
Banking portal or ERP payment-approval audit log for the transaction matching the referenced invoice/PO - >
Any prior legitimate correspondence thread for comparison of writing style, signature block, and banking details
Tuning Guidance
The highest-fidelity signal is the correlation itself — mailbox tampering AND finance-fraud-pattern email content for the same user within a tight window — rather than either signal alone, since legitimate finance staff routinely create filing rules and send urgent payment email independently. Build an allowlist of known AP/Treasury/payroll service accounts that legitimately combine both behaviors as part of normal operations, and exclude rules created by IT via documented change tickets (correlate ClientIP against known admin/automation IP ranges). Extend the finance-fraud keyword list with your organization's actual bank name, ERP vendor-portal domain, and known vendor names to reduce noise from unrelated 'invoice' mentions. Where available, enrich with vendor-master change history so the alert only fires when the banking details in the email genuinely differ from the details on file, which nearly eliminates false positives at the cost of requiring an ERP/AP system integration.
Hunting Queries
Hunt for inbox rules whose parameters explicitly reference finance/invoice/payroll keywords — attackers frequently name or target rules to specifically suppress finance-thread visibility, a higher-fidelity signal than generic forward/delete rules alone.
OfficeActivity
| where TimeGenerated > ago(30d)
| where Operation in ("New-InboxRule", "Set-InboxRule", "Set-Mailbox")
| where Parameters has_any ("ForwardTo", "RedirectTo", "DeleteMessage")
| where Parameters has_any ("invoice", "payment", "wire", "bank", "finance", "accounting", "payroll", "cfo", "ceo")
| project TimeGenerated, UserId, ClientIP, Operation, Parameters
| sort by TimeGenerated descindex=o365 sourcetype="o365:management:activity" Operation IN ("New-InboxRule", "Set-InboxRule", "Set-Mailbox") Parameters="*ForwardTo*" OR Parameters="*RedirectTo*" OR Parameters="*DeleteMessage*"
| regex Parameters="(?i)(invoice|payment|wire|bank|finance|accounting|payroll|cfo|ceo)"
| table _time, UserId, ClientIP, Operation, Parameters
| sort - _timeHunt broadly for any email referencing a change of banking details regardless of urgency language, to catch slower-moving or lower-pressure BEC variants that skip the explicit urgency phrasing but still swap payment instructions.
EmailEvents
| where TimeGenerated > ago(30d)
| where Subject has_any ("routing number", "account number", "swift code", "iban", "new bank details", "change of bank account")
| summarize EmailCount=count(), Recipients=make_set(RecipientEmailAddress), Subjects=make_set(Subject) by SenderFromAddress
| where EmailCount >= 1
| sort by EmailCount descindex=o365 sourcetype="o365:defender:email" Subject="*routing number*" OR Subject="*account number*" OR Subject="*swift code*" OR Subject="*new bank details*" OR Subject="*change of bank account*"
| stats count AS EmailCount, values(RecipientEmailAddress) AS Recipients, values(Subject) AS Subjects BY SenderFromAddress
| sort - EmailCountAtomic Red Team Tests
Simulates attacker-created inbox rule that forwards and deletes finance-related email to hide replies from the compromised mailbox owner, the core mailbox-tampering precursor to wire fraud.
Command
Connect-ExchangeOnline; New-InboxRule -Name 'Test_FinanceHide' -SubjectContainsWords 'invoice','payment','wire' -ForwardTo '[email protected]' -DeleteMessage $true -Enabled $trueCleanup
Remove-InboxRule -Identity 'Test_FinanceHide' -Confirm:$falseExpected Telemetry
OfficeActivity records a New-InboxRule operation with Parameters containing ForwardTo, DeleteMessage, and the finance-related SubjectContainsWords condition.
Expected Detection
Alert fires on mailbox rule tampering with forward/delete parameters; combined with a matching finance-fraud email within 72 hours, the correlated high-confidence alert fires.
Simulates the fraudulent invoice/payment email stage of BEC financial theft, containing wire-transfer/bank-detail-change keywords paired with urgency-pressure phrasing sent to a finance-team test mailbox.
Command
swaks --to [email protected] --from [email protected] --header 'Subject: URGENT - Updated Payment Instructions - New Bank Details for Invoice #4471' --body 'Please process this wire transfer today using our new routing number and account number, do not call to confirm as I am in meetings all day.' --server smtp.external-test.comExpected Telemetry
EmailEvents records the inbound message with Subject matching finance/urgency keyword patterns; message trace shows sender domain external-test.com.
Expected Detection
Alert fires on finance-fraud-pattern email content; if a mailbox-tampering event exists for the recipient within 72 hours, the correlated critical alert fires.
Chains the mailbox-tampering and fraud-email atomics within a short window on the same test mailbox to validate the full correlation logic fires the combined high-confidence alert.
Command
Connect-ExchangeOnline; New-InboxRule -Name 'Test_FinanceHide2' -SubjectContainsWords 'invoice','payment' -DeleteMessage $true -Enabled $true; Start-Sleep -Seconds 60; Send-MailMessage -To '[email protected]' -From '[email protected]' -Subject 'URGENT - Change of Bank Account for Vendor Payment' -Body 'Please update our banking details and process the ACH transfer immediately, this is time sensitive.' -SmtpServer 'smtp.external-test.com'Cleanup
Remove-InboxRule -Identity 'Test_FinanceHide2' -Confirm:$falseExpected Telemetry
OfficeActivity and EmailEvents both record events for the same UserId within the 72-hour correlation window.
Expected Detection
The KQL/SPL correlation join fires the ThreatType=BEC_WireFraud_MailboxTamper_Correlation critical alert.
Related Detections
Tactic Hub
Detection Variants (1)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.