Behavioural BEC detection: why static rules fail against modern business email compromise

Business email compromise (BEC) is the highest-loss attack pattern in cyber crime by absolute dollar value. The FBI Internet Crime Complaint Center reported $2.77 billion in BEC losses in 2024 (FBI IC3, 2025) — exceeding ransomware losses for the seventh consecutive year. In South Africa, the SABRIC Annual Crime Statistics put 2024 digital banking fraud losses at R1.888 billion, up 74% year-on-year, across 97,959 reported incidents (SABRIC, 2025).

The pattern that drives those numbers has shifted. The 2018-2022 BEC playbook — typo-ridden lures from look-alike domains, asking for gift cards or wire transfers — has been replaced by a more competent class of attack. Modern BEC starts with a real mailbox compromise via adversary-in-the-middle (AiTM) phishing, uses the legitimate sender's actual account to send the fraud email, and lands the wire transfer before the legitimate user notices.

The AiTM kill chain

AiTM phishing inserts a proxy between the user and the legitimate authentication endpoint. The user sees a perfect Microsoft login page, enters credentials, and completes MFA. The proxy harvests the resulting session cookie and uses it to authenticate to the real Microsoft tenant. The user gets logged in normally and notices nothing.

Once the attacker has a session cookie, they have authenticated access to the mailbox without needing the password again. They typically install an inbox rule that auto-deletes or auto-forwards specific keywords ("invoice", "payment", "wire") and then wait. When a legitimate invoice arrives, the attacker intercepts it, modifies the bank details, and forwards the modified version to the finance team — from the legitimate compromised mailbox, fully DMARC-aligned.

Why static rules fail

Static-rule detection looks for known-bad patterns: lookalike domains, typo-squatted brands, suspicious attachment types, banking-related keywords. None of these patterns are present in AiTM-driven BEC because the lure is being sent from a real mailbox, the language is the legitimate user's normal language, and the modification is to a banking-detail field that does not look syntactically suspicious.

The static-rule pattern can occasionally catch the lower-skill end of BEC — Hotmail addresses, obvious typos, requests from "the CEO" to junior staff. It cannot catch the AiTM end of the spectrum because the AiTM end does not match any pattern. The signal is not "what does the email look like" but "is this normal for this relationship at this time."

Per-user, per-tenant, per-relationship baselines

A behavioural baseline records, per pair of sender and recipient, the normal communication shape. Typical send hours. Typical subject patterns. Typical link domains. Typical reply chains. Typical financial-instruction frequency. When a message deviates from baseline (the CEO emails the finance director at an unusual hour, with a banking-detail change, on a thread that is fork-replied rather than reply-all), the deviation is the signal.

Per-relationship baselines are more powerful than per-sender baselines because the CEO emails finance differently from how they email engineering. A baseline keyed on (sender, recipient) catches deviations a sender-only baseline misses. The model needs sufficient data to converge — typically 30-90 days of mailbox history per tenant before the baseline is meaningful. Vendors that claim instant baseline are either over-promising or doing something else under the hood.

Multi-signal consensus over single-rule detection

No single signal is sufficient. A behavioural deviation alone can be a legitimate change (the CEO is travelling and emailing at unusual hours). Banking-detail changes can be legitimate (the supplier did update their bank). Inbox rules that auto-delete specific keywords can be legitimate (a user who hates Slack notifications). The consensus model treats each signal as a vote — when three or four signals all deviate together, the verdict is high-confidence.

Common consensus signals for BEC detection: behavioural deviation on (sender, recipient) baseline; intent classification flagging financial-action language; new-or-recently-modified inbox rule on the sender mailbox; banking-detail change pattern in attached invoice; thread-hijack detection (reply to a real thread but with off-baseline content). Two-of-five consensus is high-confidence; three-of-five typically warrants automatic quarantine and SOC alert.

POPIA Section 22 implications

Where BEC compromises a mailbox in a way that exposes personal information of data subjects (customers, employees, suppliers), the responsible party has a Section 22 notification obligation under POPIA (Republic of South Africa, 2013). The notification has to specify what information was accessed, by whom, and what remediation is being taken. Behavioural-detection systems that log their findings into a tamper-evident audit chain make the notification defensible — the regulator can verify the timeline and the response.

References

FBI IC3 (2025) Internet Crime Report 2024. Federal Bureau of Investigation Internet Crime Complaint Center. Available at: https://www.ic3.gov/AnnualReport (Accessed: 8 May 2026).

SABRIC (2025) Annual Crime Statistics 2024. South African Banking Risk Information Centre. Available at: https://www.sabric.co.za (Accessed: 8 May 2026).

Republic of South Africa (2013) Protection of Personal Information Act, No. 4 of 2013. Government Gazette of the Republic of South Africa.