BEC scale in Malaysia
Business Email Compromise is the highest-loss cybercrime category against Malaysian enterprises and remains under-reported. PDRM's Commercial Crime Investigation Department (CCID) publishes annual statistics on commercial-crime losses, with online and email-related fraud consistently representing the largest share of reported business losses; the precise figures should be cited from the most recent CCID public statement rather than summarised here, as the absolute numbers move materially year-over-year. The pattern is consistent: a single successful BEC against a mid-market Malaysian enterprise routinely lands in the RM 500,000 to RM 5,000,000 single-incident loss band, well above the lifetime cost of the defensive controls that would have prevented it.
The under-reporting is the structural problem. Boards are reluctant to disclose internal fraud incidents; insurers are reluctant to publish aggregated figures; the actual prevalence is multiples of the reported prevalence. We see at least one BEC engagement per quarter across our incident-response caseload, almost always at organisations with mature general security postures but specific gaps in email authentication or out-of-band wire verification.
Top BEC patterns in 2026
The threat-actor playbook has not changed materially in five years; the technical sophistication has. Generative-AI-assisted lure crafting has eliminated the spelling-and-grammar tells that previously gave BEC away. The patterns:
1. CEO fraud / executive impersonation
A spoofed or look-alike-domain email purporting to be from the CEO or CFO instructs the finance team to wire funds urgently, typically for a ‘confidential acquisition’ or ‘urgent vendor payment’. Variants include WhatsApp-based impersonation (a new number claiming to be the CEO, sometimes paired with deepfake voice) and Microsoft Teams chat impersonation. Pressure is the universal lever — urgency, secrecy, deference to seniority. Defences are out-of-band verification (call the executive on a known number, never the number provided in the email) and finance-team training that no urgent request bypasses the normal process.
2. Vendor invoice hijack
The most reliable BEC pattern against Malaysian SMEs and mid-market. The attacker compromises the vendor's mailbox first (or compromises the customer's mailbox and waits for a vendor email thread). At the moment a real invoice is due, the attacker injects a forged invoice with new bank-account details, often from a registered company account at a different bank. The customer pays the new account; the funds are gone within hours. Defence: any change to vendor banking details must trigger out-of-band verification with a known vendor contact via a known channel — never via reply to the requesting email.
3. Payroll diversion
An attacker spoofs an employee asking HR or payroll to update their bank-account details for the next pay run. The change is processed; the next salary lands in the attacker account; the employee notices weeks later. Defence: bank-account changes from employees must be verified out-of-band against a known phone number on file or in person with the employee.
4. Real-estate and conveyancing wire fraud
The conveyancing-fraud pattern: at the moment of property settlement, the buyer receives forged settlement-account details that route the deposit to attacker-controlled accounts. Common against Malaysian property purchases involving multiple parties (buyer, seller, two solicitor firms, bank). Defence: property settlement parties must agree banking details in advance via signed paper or in-person verification, never via email at the moment of settlement.
5. Account takeover and internal-thread injection
The most technically sophisticated pattern: the attacker compromises an internal mailbox (typically via phish-then-MFA-bypass or session-token theft), then waits inside the mailbox observing legitimate email threads. At the right moment the attacker injects a reply into an existing thread between the compromised employee and a counterparty — same thread, same context, same writing style — but with new banking instructions. Detection requires mailbox-anomaly monitoring (unusual login locations, mailbox rules silently forwarding finance-team email externally) and is the strongest argument for moving the corporate email tenant to a stack with rich audit logging (Microsoft 365 E5, Google Workspace Enterprise).
Defence layers
Layer 1: Email authentication
SPF, DKIM and DMARC published correctly, with DMARC at p=reject on all production domains. p=none is monitoring only and stops nothing; p=quarantine sends fraudulent mail to spam where users still find it. Only p=reject prevents the inbound delivery. Most Malaysian enterprises we audit have SPF and DKIM published but DMARC at p=none for years ‘until we're sure’. Move to p=reject; the controlled rollout takes 6-8 weeks of DMARC reporting analysis.
BIMI publication is a nice-to-have signal of authentication maturity but does not itself prevent fraud. Hosted-domain-monitoring services (look-alike-domain detection) close the gap on cousin-domain spoofing that DMARC cannot prevent.
Layer 2: MFA on email — phishing-resistant
Every mailbox must require MFA. Time-based OTP (TOTP) and SMS OTP are now considered insufficient against phish-then-relay attacks (modern Adversary-in-the-Middle phishing kits like EvilProxy and Tycoon defeat them in real time). Phishing-resistant MFA — FIDO2 security keys or Microsoft Entra Conditional Access with device-bound passkeys — is the realistic baseline for executives, finance and any role with payment-authorisation power.
Layer 3: Out-of-band wire verification
The single most effective control. Every payment above a threshold (RM 50,000 is a common Malaysian cutoff for SMEs; lower for higher-risk industries), every change to vendor or employee banking details, every new payee — verified by callback to a known phone number or in-person. The verification policy must be enshrined in finance-team standard operating procedures, trained quarterly, and audited annually. Most BEC losses we investigate would have been stopped by a single 30-second callback that policy required and the attacker's pressure prevented.
Layer 4: Vendor portal hardening
Where the volume of vendor banking-detail changes justifies it, move the entire process out of email into a vendor portal with MFA, out-of-band confirmation and audit logging. Email is removed from the change-of-banking-details workflow entirely. Portal-based change requests are signed by the vendor and verified against a known vendor identity.
Layer 5: Inbound email filtering and impersonation detection
Modern email-security gateways (Microsoft Defender for Office 365, Proofpoint, Mimecast, Abnormal Security and others) ship dedicated impersonation-detection — flagging messages from cousin-domains, executive-display-name impersonation, urgency-and-payment-language combinations, and behavioural anomalies on internal senders. The capability is the realistic baseline for any enterprise above SME tier.
Layer 6: Mailbox-anomaly monitoring
For account-takeover-then-thread-injection attacks, the only credible detection is mailbox-anomaly monitoring: alerting on unusual sign-in locations, MFA-bypass attempts, mailbox-forwarding rules being created silently, OAuth application consents that grant external apps access to mail. This functionality is part of Microsoft 365 E5 (Entra ID Identity Protection + Defender for Office 365) and equivalent in Google Workspace Enterprise.
Incident response when BEC happens
The first 24 hours determine whether funds are recoverable. The playbook:
- Lock the compromised mailbox; revoke active sessions and OAuth grants; reset passwords; enrol new MFA from clean device.
- Contact the receiving bank immediately requesting a recall; the recall window is typically hours, not days, before funds are withdrawn.
- File a police report at the nearest district headquarters CCID and obtain the report number — required for the bank recall and any subsequent legal action.
- Notify the cyber-insurance carrier within the policy notification window (typically 48-72 hours).
- Engage incident response to determine the dwell time, identify all compromised mailboxes, preserve forensic evidence and identify the initial-access vector.
- Notify counterparties in the affected email threads; their mailboxes may also be compromised.
NACSA Cybersecurity Act 854 §22 reporting
The Cybersecurity Act 2024 (Act 854) creates statutory cybersecurity-incident reporting obligations on National Critical Information Infrastructure (NCII) entities. Section 22 (and accompanying regulations) sets the trigger conditions and timing for incident notification to NACSA. For NCII entities a successful BEC that compromised a corporate mailbox or that resulted in fraudulent fund transfer typically meets the reporting threshold; the notification timing under the regulations is short (the operative window is hours, not days). Non-NCII organisations have no statutory reporting obligation under Act 854 but may have parallel obligations under PDPA (if customer data was exposed in the compromised mailbox) or sector regulator requirements (BNM, Bursa Malaysia disclosure, etc.). Engage your compliance counsel within the same 24-hour window. See our Cybersecurity Act readiness practice for the full readiness pathway.
Operationalising the playbook
BEC defence is a programme, not a project. The defensive layers must be paired with quarterly finance-team simulation training (a controlled BEC simulation that tests whether out-of-band verification actually happens), regular DMARC report review, periodic email-tenant configuration audit, and continuous mailbox-anomaly monitoring. The investment is small relative to a single avoided incident. See our security training service, our MDR service for mailbox-anomaly monitoring, and our incident response retainer for the day the training fails.
For execution: see our incident response service, security training, and our managed detection & response.