Skip to content

SC-015: Business Email Compromise (BEC) Deep Dive

Scenario Header

Type: Email / Financial Fraud  |  Difficulty: ★★★★☆  |  Duration: 2–3 hours  |  Participants: 4–8

Threat Actor: eCrime group — financially motivated, vendor email compromise specialist

Primary ATT&CK Techniques: T1566.001 · T1534 · T1114.002 · T1078.004 · T1036.005 · T1565.003 · T1657


Threat Actor Profile

CRIMSON LEDGER is a West African cybercrime syndicate active since 2019, specializing in vendor email compromise (VEC) — a sophisticated variant of Business Email Compromise where the attacker compromises a trusted vendor's email infrastructure rather than the target organization directly. This approach bypasses traditional BEC detection because the phishing emails originate from legitimate, trusted domains with valid DKIM signatures.

The group targets procurement and accounts payable departments at enterprises with annual revenue between $500M and $10B. Their average campaign yield is $1.2M–$4.5M per successful operation. They demonstrate exceptional patience — maintaining access to compromised vendor mailboxes for 30–90 days before executing the fraud, meticulously studying invoicing patterns, approval workflows, and banking relationships.

Motivation: Financial — invoice fraud via wire redirection, typically laundered through money mule networks across Eastern Europe and Southeast Asia.

FBI IC3 — BEC Statistics (Public Data)

According to the FBI's Internet Crime Complaint Center (IC3), BEC remains the most financially damaging cybercrime category:

  • 2023 IC3 Report: $2.9 billion in reported BEC losses (12,500+ complaints)
  • 2022 IC3 Report: $2.7 billion in reported BEC losses
  • Average loss per BEC incident: $125,000+ (but outliers exceed $35M)
  • Recovery rate: Only ~29% of funds are recovered when recall is attempted within 24 hours
  • Vendor Email Compromise is the fastest-growing BEC subtype, accounting for ~40% of dollar losses

Scenario Narrative

Phase 1 — Reconnaissance & Vendor Compromise (~25 min)

CRIMSON LEDGER identifies GlobalCorp as a target through LinkedIn reconnaissance and publicly filed SEC procurement disclosures. They map GlobalCorp's top 20 vendors using open-source intelligence — press releases, LinkedIn posts by procurement staff, and Dun & Bradstreet data. They identify Meridian Industrial Supply as a high-value, high-frequency vendor with a predictable monthly invoicing cycle of $200K–$400K.

The attacker sends a spearphishing email to j.williams@meridian-supply.com (Accounts Receivable Manager at Meridian) containing a malicious PDF disguised as a purchase order from another Meridian customer. The PDF exploits a known vulnerability in the Meridian employee's unpatched PDF reader, dropping a credential-harvesting implant. Within 48 hours, CRIMSON LEDGER has j.williams's O365 credentials and establishes persistent access via an OAuth app with Mail.ReadWrite and Mail.Send permissions.

For the next 45 days, the attacker silently monitors Meridian's mailbox, cataloging every invoice sent to GlobalCorp — noting invoice formats, numbering conventions, payment terms, authorized signatories, and banking details.

Evidence Artifacts:

Artifact Detail
Meridian O365 Sign-in Log 2025-12-01T14:22:17Zj.williams@meridian-supply.com — Source IP: 203.0.113.42 (NG, residential proxy) — UserAgent: Chrome/119 — MFA: Satisfied (SMS OTP intercepted)
Meridian M365 Audit Log AppInstalled — App: DocSync Manager — Permissions: Mail.ReadWrite, Mail.Send, offline_access — User: j.williams@meridian-supply.com2025-12-01T14:28:33Z
Meridian Exchange Logs MailItemsAccessed — 2,847 items read via OAuth token over 45-day period — Focus: threads containing GlobalCorp, invoice, payment
DNS Registration meridian-supply-portal[.]com registered 2026-01-10 — Registrar: Namecheap — WHOIS: privacy-protected — Typosquat of meridian-supply.com
Phase 1 — Discussion Inject

Technical: The attacker compromised the vendor's mailbox rather than GlobalCorp's directly. Why does this make traditional email security controls (SPF, DKIM, DMARC) at GlobalCorp ineffective? What alternative detection strategy would you deploy?

Decision: Your threat intelligence team receives a report that meridian-supply-portal[.]com was registered 10 days ago. This is a typosquat of a known vendor domain. Do you (A) proactively block the domain and alert your procurement team, or (B) investigate further before taking action to avoid disrupting a legitimate vendor communication? What's the cost of each wrong answer?

Expected Analyst Actions: - [ ] Run domain registration analysis on meridian-supply-portal[.]com — WHOIS, hosting, SSL cert - [ ] Check email gateway logs for any inbound mail from this domain - [ ] Alert the procurement team about the typosquat domain - [ ] Contact Meridian Industrial Supply through a verified channel to confirm account integrity - [ ] Add the typosquat domain to your email gateway blocklist and DNS sinkhole


Phase 2 — Invoice Manipulation & Email Interception (~30 min)

On 2026-01-15, Meridian sends GlobalCorp a legitimate invoice (#MIS-2026-0142) for $387,500 for Q1 industrial equipment deliveries. The email is sent from j.williams@meridian-supply.com to p.nakamura@globalcorp.com (Procurement Manager) and ap-team@globalcorp.com.

CRIMSON LEDGER intercepts this email in j.williams's Sent Items within 3 minutes. The attacker creates an inbox rule in the Meridian mailbox that redirects all replies from @globalcorp.com to a hidden folder, preventing the real Meridian AR team from seeing GlobalCorp's responses.

Within 2 hours, the attacker sends a follow-up email from j.williams's legitimate mailbox to GlobalCorp:

"Hi Priya, following up on invoice MIS-2026-0142 — we've recently changed our banking partner. Please update our payment details to the attached new bank verification letter. Going forward, all payments should be directed to the updated account."

The attached "bank verification letter" is a convincing forgery on Meridian letterhead (obtained from previous invoices), directing payments to a fraudulent account at a Lithuanian bank: IBAN LT603250012345678901.

Evidence Artifacts:

Artifact Detail
GlobalCorp Email Gateway Inbound from j.williams@meridian-supply.com — SPF: PASS, DKIM: PASS, DMARC: PASS — Subject: "RE: Invoice MIS-2026-0142 — Updated Banking Details" — 2026-01-15T11:42:08Z
GlobalCorp Email Gateway Attachment: Meridian_Bank_Verification_2026.pdf — 142KB — No malware detected (clean PDF, no exploits)
Meridian M365 Audit Log New-InboxRule — Rule: "Archive-GC" — Condition: From contains globalcorp.com — Action: Move to RSS Feeds folder — 2026-01-15T11:38:22Z
Meridian Sent Items Original invoice email and follow-up banking change email both sent from legitimate j.williams session via OAuth app
Phase 2 — Discussion Inject

Technical: The banking change email passed SPF, DKIM, and DMARC because it was sent from the legitimate Meridian mailbox. What email authentication mechanism or organizational process would detect this type of vendor impersonation even when email authentication passes?

Decision: Priya Nakamura in procurement receives the banking change request. Your accounts payable policy states: "Banking detail changes require verbal confirmation." However, the policy hasn't been enforced consistently — in the last quarter, 3 out of 7 banking changes were processed without callback verification. How do you redesign this control to ensure consistent enforcement?

Expected Analyst Actions: - [ ] Analyze email headers — verify X-Mailer, X-Originating-IP, and client type - [ ] Check if the email was sent via OAuth app vs. native Outlook client - [ ] Compare the "bank verification letter" PDF metadata against known Meridian documents - [ ] Initiate callback verification to Meridian using a phone number from your vendor master file (not from the email) - [ ] Flag all banking detail change requests for secondary approval


Phase 3 — Wire Fraud Execution (~25 min)

GlobalCorp's accounts payable coordinator, Daniel Okonkwo, processes the banking detail change. He updates Meridian's payment record in the ERP system (SAP) with the new Lithuanian IBAN. The change is approved by Priya Nakamura, who recalls the email from "j.williams" but does not perform a callback verification — she's processing 47 invoices that day and the email came from a known, trusted sender.

On 2026-01-22, the weekly payment batch runs. Three payments totaling $1,247,800 are wired to the fraudulent IBAN:

Invoice Amount Description
MIS-2026-0142 $387,500 Q1 industrial equipment
MIS-2026-0156 $412,300 Emergency parts order
MIS-2026-0163 $448,000 Maintenance contract renewal

The funds arrive at the Lithuanian bank at 14:32 UTC. By 15:10 UTC, $890,000 has been transferred to a secondary account in Hong Kong. The remaining $357,800 is moved to a cryptocurrency exchange and converted to Monero within 6 hours.

Evidence Artifacts:

Artifact Detail
SAP ERP Audit Trail Vendor master record V-MIS-0042 — Banking details modified by d.okonkwo — Approved by p.nakamura2026-01-16T09:14:22Z — Previous IBAN: DE89370400440532013000 → New IBAN: LT603250012345678901
Wire Transfer Records 3 transfers totaling $1,247,800 — Beneficiary: "Meridian Industrial Supply" — IBAN: LT603250012345678901 — Bank: AB SEB bankas, Vilnius — Executed: 2026-01-22T14:32:00Z
Bank Fraud Team Recall request initiated 2026-01-28T16:45:00Z (6 days post-transfer) — Status: Partial recovery possible — $357,800 still in Lithuanian account (frozen) — $890,000 unrecoverable (Hong Kong transfer completed)
GlobalCorp AP Workflow Callback verification checkbox: Not completed — System allows bypass when "trusted vendor" flag is set
Phase 3 — Discussion Inject

Technical: The SAP ERP system allowed a banking detail change with only single-person approval. What ERP-level control would enforce segregation of duties for vendor master changes? How would you integrate your ERP audit trail with your SIEM for real-time alerting on banking detail modifications?

Decision: You've discovered the fraud 6 days after wire execution. The bank says they can freeze the remaining $357,800 in Lithuania but need a law enforcement request within 48 hours. Simultaneously, you must decide: (1) Do you notify Meridian that their mailbox is compromised? This will help them but may trigger the attacker to destroy evidence. (2) Do you notify your cyber insurance carrier now or after completing the investigation? What's the contractual notification window?

Expected Analyst Actions: - [ ] Immediately contact the bank's wire fraud team — initiate recall for all 3 transfers - [ ] File FBI IC3 complaint (ic3.gov) — required for international wire fraud recovery - [ ] Contact Meridian via verified phone to inform them of the mailbox compromise - [ ] Preserve all email evidence via eDiscovery hold before Meridian remediates - [ ] Engage forensic accountant to trace fund movement through banking channels - [ ] Notify cyber insurance carrier within policy notification window (typically 48–72 hours)


Phase 4 — Detection, Containment & Notification (~30 min)

On 2026-01-28, the real Meridian Industrial Supply contacts GlobalCorp asking about three overdue invoices totaling $1,247,800 that were due on January 22. Priya Nakamura confirms the payments were sent — to the IBAN Meridian provided in their January 15 email. Meridian denies sending any banking change notification. The fraud is confirmed.

GlobalCorp's security team launches an investigation. They discover:

  • The banking change email was sent from j.williams's legitimate mailbox via an OAuth app (DocSync Manager), not the native Outlook client
  • Email headers show X-Mailer: Microsoft Graph API v1.0 rather than Outlook 16.0
  • The inbox rule redirecting GlobalCorp replies was still active in Meridian's mailbox
  • 2,847 emails were read by the attacker over the 45-day monitoring period
  • The Lithuanian IBAN was opened 3 weeks before the first fraudulent transfer
  • The account holder name matched "Meridian Industrial Supply" — a shell entity
  • $890,000 was cascaded through 4 intermediate accounts before reaching Hong Kong
  • $357,800 remains frozen in Lithuania pending law enforcement action
  • All attacker activity originated from 3 residential proxy IPs in Nigeria (203.0.113.42, 203.0.113.78, 203.0.113.91)
  • The typosquat domain meridian-supply-portal[.]com hosted a credential phishing page (now defunct)
  • SSL certificate for the typosquat domain was issued by Let's Encrypt 72 hours before the initial phish

Evidence Artifacts:

Artifact Detail
GlobalCorp SIEM Retroactive correlation: 14 emails from j.williams@meridian-supply.com in Jan 2026 — 9 sent via Graph API (OAuth), 5 sent via native Outlook — Baseline: 100% native Outlook in prior 12 months
Meridian O365 OAuth app DocSync Manager — Active since 2025-12-01 — Permissions: Mail.ReadWrite, Mail.Send — Last used: 2026-01-22T14:28:00Z
GlobalCorp DNS Logs Zero queries to meridian-supply-portal[.]com from GlobalCorp network — attack vector was vendor-side, not GlobalCorp-side
Law Enforcement FBI IC3 complaint filed 2026-01-28 — Case assigned to Cyber Division — Mutual Legal Assistance Treaty (MLAT) request initiated for Lithuanian bank records
Phase 4 — Discussion Inject

Technical: The attacker used Microsoft Graph API to send emails, which produces a different X-Mailer header than the native Outlook client. How would you build a detection rule in your SIEM to flag emails from known vendors that suddenly change their sending client? What's the false positive risk?

Decision: Your total financial exposure is $1,247,800 with only $357,800 potentially recoverable. The CFO wants to know: (1) Does cyber insurance cover BEC wire fraud? (Most policies do, but with sub-limits.) (2) Should you pursue civil litigation against the Lithuanian bank for releasing funds? (3) What's the business case for implementing the BEC prevention controls you're about to recommend? Prepare a cost-benefit analysis.

Expected Analyst Actions: - [ ] Complete full timeline reconstruction — from initial vendor compromise through fund recovery attempts - [ ] Conduct email header analysis across all vendor communications for the past 90 days - [ ] Audit all vendor banking detail changes in SAP for the past 12 months - [ ] Implement immediate hold on all pending vendor payment changes until verification is complete - [ ] Coordinate with legal on regulatory notification requirements - [ ] Prepare board-level incident briefing with financial impact assessment


Detection Opportunities

Phase Technique ATT&CK Detection Method Difficulty
1 Vendor mailbox compromise T1566.001 Monitor vendor email sending patterns — OAuth vs. native client changes Hard
1 Typosquat domain registration T1583.001 Domain monitoring services (e.g., DomainTools, PhishLabs) for vendor typosquats Medium
2 Email from OAuth app T1534 Email header analysis: X-Mailer change detection for known vendors Hard
2 Banking detail change request T1565.003 NLP-based email content scanning for financial instruction modification Medium
3 Vendor master record change T1657 SIEM integration with ERP: alert on banking detail modifications Easy
3 Callback verification bypass Process audit: flag vendor payments where callback verification was skipped Easy
4 Wire to high-risk geography T1657 Transaction monitoring: flag transfers to FATF grey/black list jurisdictions Medium

BEC Prevention Checklist

BEC Prevention Controls

Email Security:

  • [ ] Deploy AI-based email security (e.g., Abnormal Security, Proofpoint TAP) that analyzes sender behavior, not just authentication
  • [ ] Implement DMARC enforcement (p=reject) on your own domain
  • [ ] Monitor vendor email patterns for sudden changes in sending infrastructure
  • [ ] Deploy typosquat domain monitoring for your top 50 vendors

Financial Controls:

  • [ ] Require verbal callback verification for ALL banking detail changes — no exceptions
  • [ ] Use a verified phone number from your vendor master file — never from the email
  • [ ] Implement dual-authorization for wire transfers exceeding $50,000
  • [ ] Enforce segregation of duties: the person who changes banking details cannot approve the payment
  • [ ] Require 48-hour hold on all payments to newly changed banking details

Process Controls:

  • [ ] Train accounts payable staff on VEC-specific scenarios quarterly
  • [ ] Conduct tabletop exercises simulating vendor email compromise annually
  • [ ] Audit all vendor master banking changes monthly
  • [ ] Establish a dedicated vendor verification hotline
  • [ ] Include BEC coverage and sub-limits in your cyber insurance policy review

Key Discussion Questions

  1. Your email gateway correctly authenticated the fraudulent email (SPF/DKIM/DMARC all passed). Does this mean email authentication is useless against BEC? What does it protect against, and what gap remains?
  2. The callback verification policy existed but wasn't consistently enforced. What organizational and technical controls would you implement to make this a hard control rather than a soft one?
  3. The attacker maintained access to the vendor mailbox for 45 days before executing the fraud. What vendor risk management practices would help detect a compromised vendor earlier?
  4. Of the $1,247,800 lost, only $357,800 is potentially recoverable. What factors determine wire fraud recovery success, and how would you optimize your organization's response time?
  5. The attacker used residential proxies in Nigeria. How useful is IP geolocation as a detection mechanism for BEC, given the prevalence of VPNs and residential proxy services?

Debrief Guide

What Went Well

  • Email authentication (SPF/DKIM/DMARC) was properly configured on GlobalCorp's domain — the gap was in vendor-side monitoring
  • SAP ERP maintained a complete audit trail of vendor master changes — forensic reconstruction was possible
  • FBI IC3 and law enforcement coordination resulted in partial fund freeze ($357,800)

Key Learning Points

  • Vendor email compromise bypasses email authentication — because the emails come from the legitimate vendor domain, traditional SPF/DKIM/DMARC checks pass
  • Callback verification is the single most effective BEC control — but only if enforced consistently as a hard control, not a checkbox
  • 45-day dwell time in vendor mailbox — attackers invest weeks studying invoicing patterns before executing fraud
  • Wire fraud recovery is time-critical — success rate drops from ~29% (within 24 hours) to near-zero after 72 hours
  • BEC is a process failure, not a technology failure — the attack succeeded because of inconsistent control enforcement
  • [ ] Implement mandatory callback verification for all vendor banking changes — integrate into ERP workflow as a blocking control
  • [ ] Deploy AI-based email security that detects behavioral anomalies in vendor communications
  • [ ] Establish vendor risk management program — require key vendors to demonstrate email security controls
  • [ ] Integrate SAP vendor master change alerts into SIEM for real-time monitoring
  • [ ] Conduct quarterly BEC simulation exercises for accounts payable staff
  • [ ] Review cyber insurance policy for BEC/wire fraud coverage limits and notification requirements
  • [ ] Implement 48-hour payment hold for all transactions to newly modified banking details

References