Financial Theft

BEC-style financial theft sits at the very end of a short chain: credential phishing or password-spray gets the attacker into a mailbox (Valid Accounts, T1078), the inbox rule (T1114.003 or T1564.008) establishes persistence and visibility without ever touching the endpoint, and the fraudulent payment request is the last message sent before the attacker moves on. There is rarely lateral movement or privilege escalation involved, which is precisely why EDR-centric detection strategies miss it: the entire operation happens inside a SaaS mailbox.

MITRE's own procedure notes place SilverTerrier's BEC campaigns against high-tech, higher-education, and manufacturing targets in this category, and groups like Scattered Spider are called out specifically for the mailbox-hiding-rule pattern that Splunk's T1564.008 analytic detects. On the extortion side, Akira, Medusa, Play, and Storm-0501 all run double-extortion chains where the financial-theft demand follows exfiltration and encryption rather than preceding it, which is why a shadow-copy-deletion alert should be read as a financial-theft precursor, not just a data-integrity event.

Legitimate inbox rules forward mail constantly: an employee setting up a personal Gmail forward, an out-of-office delegate rule, a shared-mailbox routing rule maintained by IT, or a vacation auto-forward all trigger the same New-InboxRule or Set-InboxRule operation the BEC detections watch. A rule pointed at a known partner domain, created through a documented change-management ticket, or matching an existing delegation policy is routine, not an indicator of compromise.

The tuning that holds up is scoring, not the raw event. Splunk's entropy-and-length approach exists because a single field (rule exists, forwards externally) drowns analysts in normal traffic; requiring multiple suspicious attributes together, short random rule name, auto-mark-as-read, a hidden destination folder, and an external forward, cuts the false-positive rate sharply. Allow-list forwards to verified partner and personal domains employees have registered through IT, and treat any rule touching a finance, executive, or HR mailbox as inherently higher-priority regardless of score.

When a suspicious mailbox rule fires, the first question is who created it and from where: pull the ClientIP and compare it against the user's normal sign-in geography and device. A rule created from an unfamiliar IP right after a sign-in from the same IP is a compromised-account chain, not a self-service change. Next, read the rule's actual parameters, ForwardTo, RedirectTo, MoveToFolder, MarkAsRead, to understand exactly what mail the attacker is capturing or hiding, and search the mailbox for any thread involving invoices, wire transfers, or vendor payment details that the rule would have touched.

If a fraudulent payment instruction went out or a transfer is pending, this becomes a race against the banking cutoff window, not a routine ticket: notify the finance team and the bank immediately to attempt a recall, since wire fraud recovery windows are measured in hours. Reset the compromised account's credentials, revoke all active sessions and app passwords, and remove the malicious rule rather than just disabling it (attackers sometimes re-enable disabled rules). For extortion-driven theft, treat the recovery-inhibition or encryption alert as the escalation trigger and isolate affected hosts immediately, since by the time a ransom note appears the financial-theft outcome is already close to locked in.