Business Email Compromise is Australia's highest-value cybercrime. Most victims don't realise until the money has moved.
BEC hits hardest where payment changes, supplier relationships and time pressure intersect. Property, construction, legal and professional services environments are especially exposed because transactions are high value, multi-party and easy to disrupt with a convincing email.
See the three control layers that reduce exposureThis page explains how BEC works, where organisations are most exposed, and the combination of email security, identity controls and payment-verification process that reduces the risk materially. In short: BEC can involve spoofing or real-account compromise; technical and process controls are both required; payment-change verification is critical; and Microsoft 365 and email security are strongly involved. The Microsoft 365 controls that reduce BEC exposure are email authentication (SPF, DKIM, DMARC), Conditional Access and phishing-resistant MFA, Defender for Office 365 anti-impersonation, and process controls with payment verification.
Business Email Compromise is targeted fraud, not indiscriminate phishing.
Attackers research the organisation, understand its processes and relationships, and send highly specific requests designed to look like a normal business transaction. Many BEC attacks contain no malicious links or attachments, so they bypass email security filters that look for those indicators. The damage is financial, not technical: funds transferred to attacker-controlled accounts.
Why standard email security misses BEC. BEC attacks are designed to look identical to legitimate business communication. The email may arrive from a real account that has been compromised, from a domain that closely resembles a trusted supplier, or from a display name that matches an executive. There is often no malware, no suspicious link and no attachment to trigger automated detection. The attack succeeds when a human makes a decision based on a trusted-looking request.
Most organisations do not look at BEC until a transaction feels wrong, a supplier requests account changes, or an insurer or customer starts asking harder questions about email security and payment controls.
The trigger situations below are the most common reasons Australian organisations start this conversation.
Finance or operations teams are processing supplier payment changes, settlement instructions or payroll updates based on email requests alone, without a separate verification step.
A supplier requests unexpected bank-account changes, an invoice looks slightly off, or a staff member flags an unusual request. The organisation realises it has no documented process for what to do next.
Microsoft 365 is in place, but DMARC enforcement, Conditional Access, anti-impersonation policies and legacy authentication have not been properly configured or reviewed.
Cyber insurance renewal or a customer security questionnaire is asking about email authentication, MFA type or payment-change processes. The organisation cannot answer with confidence.
SPF, DKIM and DMARC posture across all sending domains. Microsoft 365 anti-impersonation and email authentication configuration. Conditional Access, MFA type and legacy authentication exposure. Mailbox forwarding rules, delegation changes and consent grant risk. Shared mailbox and finance mailbox controls. Payment-change approval process and out-of-band verification steps. Payroll bank-detail change process. Escalation path when a suspicious request is identified.
The distinction matters for how you defend against it.
Phishing is broadly indiscriminate. It targets many people with generic lures, typically to steal credentials or install malware. Defences against phishing focus on detecting malicious links, attachments and spoofed sender domains at the email gateway.
BEC is deliberately targeted and financial in intent. Attackers spend time researching the organisation before sending anything. They understand who approves payments, who the CFO is, which suppliers are used and what normal transaction patterns look like. The attack is engineered to look like a normal business event.
Standard email security filters are designed to catch phishing. They are far less effective against a well-crafted BEC attack that contains no malicious content and arrives from a domain that is not on any blocklist. BEC is the highest-value cybercrime category by total financial loss in Australia. The ASD's annual cyberthreat report consistently identifies it as the number one business cybercrime by self-reported financial impact.
These are the patterns consistently reported in Australia's annual cyberthreat reporting and in post-incident reviews across professional services, construction, property and healthcare sectors.
The attacker impersonates a CEO, director or senior executive and sends an urgent payment request to finance. The aim is to use authority and urgency to override normal approval steps.
The attacker impersonates or compromises a supplier and sends revised bank details or a fraudulent invoice. The request looks legitimate because it sits inside a familiar commercial relationship. Example: a conveyancer receives an email appearing to be from the seller's legal firm advising that settlement account details have changed.
The attacker gains access to a real mailbox, studies existing conversations and inserts revised payment details into a live transaction at the right moment. Example: the attacker responds to an existing settlement thread using the compromised account, substituting updated bank details at the point of transaction.
The attacker impersonates an employee and asks payroll to update bank details before the next pay run. If processed without separate verification, the salary goes to the attacker.
The attacker impersonates a lawyer or conveyancer involved in a transaction and sends revised trust-account or settlement instructions designed to look time-critical and legitimate. Example: an email appearing to be from the organisation's solicitor advises that funds must transfer to a new trust account immediately due to a compliance issue.
The attacker uses a compromised supplier mailbox to send genuine-looking invoices or payment instructions from the real account of a trusted contact. Example: a supplier's email account is compromised and used to send the accounts team a revised invoice with updated bank details.
No single signal proves fraud. But any request involving money, account changes or confidentiality should be verified separately when one or more of these signs appears.
Any request to update a bank account, BSB or payment destination should require out-of-band verification via a known phone number, regardless of how the request appears. This is the single highest-risk trigger in any BEC scenario.
Attackers use urgency to prevent victims from following standard approval procedures. Phrases like "before end of day," "I'm unavailable," "don't loop in anyone else," and "handle this personally" are designed to create pressure that overrides process.
The sender's domain is slightly different from the real domain (acme-corp.com vs acmecorp.com), or the display name matches a known contact while the actual sending address does not. External email warning banners make this easier to catch.
Attackers research when executives are at conferences, on annual leave or in non-contactable situations. A request from a "travelling CEO" that cannot easily be verified in person or by phone is a pattern attackers deliberately exploit.
Legitimate business transactions rarely require secrecy within the organisation. A request to keep a payment confidential, not to discuss it with colleagues, or to proceed without normal approvals is a strong indicator of fraud rather than genuine business need.
The payment amount is unusually large, the destination account is new or previously unseen, or the transaction falls outside the organisation's normal payment patterns. Finance teams with a clear picture of typical transaction profiles are better placed to identify outliers.
MFA reduces credential theft risk. It does not prevent impersonation-based BEC attacks.
Many BEC attacks do not involve compromising an account at all. An attacker who sends a fraudulent request from a lookalike domain never touches the victim's credentials. MFA protects the account. It does not stop an email sent from a different account that looks like a trusted contact.
When account compromise is part of a BEC attack, adversary-in-the-middle techniques are specifically designed to defeat standard MFA. An AiTM phishing page sits between the victim and the real Microsoft 365 login. The victim completes the MFA challenge against the real service, and the attacker captures the resulting session cookie, which provides authenticated access without needing the credential or the MFA method.
This is why BEC cannot be treated as an MFA-only problem. Some attacks target identity. Others target trust, process and transaction approval.
Password spray attacks, credential stuffing from breached credential lists and brute force attacks where only the password was obtained. Standard MFA makes these attacks significantly harder and is far better than no MFA.
Adversary-in-the-middle phishing that captures session cookies after a successful MFA challenge. MFA fatigue attacks. SIM swapping for SMS OTP. Impersonation-based BEC where no account compromise occurs.
AiTM phishing. FIDO2 and certificate-based authentication are domain-bound: they will not complete authentication against a phishing page because the domain does not match. This is the meaningful distinction for high-privilege accounts.
A well-crafted impersonation email from a lookalike domain that contains no malicious content and triggers no automated alerts. Process controls are the primary defence for this scenario.
Different BEC attacks fail at different control points. The defence only works when all three layers are in place.
Email authentication helps with spoofed-domain attacks. Identity and M365 controls help with compromised-account attacks. Process controls help when the email itself looks entirely legitimate. None of these layers is optional. Each catches a different failure mode.
SPF (Sender Policy Framework) publishes a list of authorised mail servers for the domain; receiving servers check whether the sending server is authorised. SPF alone does not prevent display-name spoofing, which is why DKIM and DMARC are also required. DKIM (DomainKeys Identified Mail) cryptographically signs outgoing messages so receiving servers can verify the message was sent by an authorised source and has not been altered; it should be configured for all sending domains including subdomain senders. DMARC is the policy layer that tells receiving servers what to do when SPF or DKIM checks fail: monitor only (p=none), quarantine or reject. A DMARC policy of p=reject provides the strongest protection against domain spoofing; moving from p=none to p=reject requires a monitored rollout to avoid blocking legitimate mail.
Many DMARC records sit at p=none — reports without enforcement, the appearance of authentication without the protection
Phishing-resistant MFA for all email accounts: Conditional Access policies enforcing FIDO2 or certificate-based MFA for privileged accounts and standard MFA for all users, with legacy authentication protocols blocked to prevent MFA bypass via Basic Auth. Defender for Office 365 anti-impersonation: policies that protect against emails impersonating specific users (executives, finance contacts) or domains (known suppliers), requiring configuration of protected users and domains. External email warning banner: a banner on emails arriving from outside the organisation, simple and effective at reducing display-name spoofing impact. Mailbox auditing and alert policies: audit logging for all mailboxes with alerts on auto-forwarding or deleting inbox rules, mailbox delegation changes, and new OAuth application consent grants — the persistence mechanisms attackers use after gaining access.
Process controls are the primary defence against BEC attacks that pass technical checks. When the email arrives from a real or convincing account and contains no malicious content, email authentication does not protect against this scenario. Out-of-band verification for bank-account changes via a known phone number independently obtained — not the contact details in the email — is the single most effective process control against supplier invoice fraud. Dual authorisation for payments above a threshold: two separate approvals from two different people. No payroll changes processed via email only: a signed form through a verified channel or a direct verbal confirmation with the employee. Defined escalation for unusual requests so employees know the path when a request feels unusual, regardless of how authoritative the sender appears.
Security awareness training with BEC scenarios: realistic BEC simulation exercises, not just generic phishing simulations. Supplier callback protocol: bank-account changes from known suppliers handled by direct callback to a previously verified contact, not any number provided in the email requesting the change. Domain monitoring for lookalike registrations: attackers often register lookalike domains ahead of a campaign; early detection allows the domain to be reported and blocklisted before use.
High value, many parties, hard deadlines.
Property development, construction and professional services organisations are disproportionately targeted by BEC because of the high-value transactions involved, the multiple parties in a typical transaction, and the time pressure that characterises settlements and project payments.
For these sectors, out-of-band verification of payment details is not optional. It is the control that BEC attackers are specifically working around.
The combination of large transaction amounts, multiple trusted parties and inherent deadline pressure is exactly the environment BEC attackers target. A property settlement involves the buyer's solicitor, the seller's solicitor, the conveyancer, the agent and the bank. Each one is a credible-looking sender. Each one represents a payment-direction handshake that an attacker can target. The same dynamic applies to construction project payments, professional services invoicing and trust account transactions.
The organisations that avoid large BEC losses in these sectors are the ones that have made out-of-band verification a non-negotiable requirement, embedded it into the workflow rather than treating it as a checklist item, and rehearsed it under time pressure before they needed it.
BEC defence runs across email, identity, M365 configuration and process, which is why the right starting point is a scoped exposure review, not a single technical fix.
BEC is not a single-vector problem. It involves email authentication, identity controls, Microsoft 365 configuration, mailbox monitoring, payment process controls and detection of compromised accounts. The defence requires those layers to be active and integrated, not running as disconnected initiatives.
That makes the first useful step a Cyber Security Review, a scoped review of where current BEC exposure sits across the layers that matter. Where is the M365 email security posture weak? Where is identity exposed? Where do payment workflows rely too heavily on email alone? Where are supplier-verification processes informal? The review identifies the gaps that matter most commercially and sequences remediation accordingly.
For organisations whose review reveals that the BEC defence layers need to be operated together as an ongoing discipline rather than fixed once and left, that ongoing operation runs as part of Managed Cyber Security, the service that integrates email security posture management, identity governance, mailbox monitoring and evidence production into one operating layer. For organisations whose primary need is a tighter M365 configuration as a discrete engagement, the Microsoft 365 Security page covers the configuration depth of that work.
The Inlight IT view on BEC.
Most organisations think BEC is primarily a technology problem. It is partly a technology problem. The part that technology cannot fully solve is why it keeps succeeding.
The technical controls matter and they reduce exposure materially. Properly configured DMARC at enforcement, phishing-resistant MFA on privileged accounts, anti-impersonation policies in Defender for Office 365 and external email banners all make BEC harder. But none of them catch a well-crafted request from a real compromised account, or an impersonation from a domain that passes all authentication checks on its own records.
The organisations that avoid large BEC losses are the ones that have made out-of-band verification of bank account changes a non-negotiable process requirement, not a suggestion. That one control stops the highest-value attack vector regardless of what happens at the email layer. It does not require any technology investment. It requires a process that people actually follow under time pressure.
The technical controls reduce the surface area. The process controls are what stop the attacks that get through the technical layer.
Could you say which of these routes your current controls would actually stop? If any answer is a guess, that is the review.
Check your controls →Questions Australian business owners, finance managers and IT teams ask when researching BEC protection.
What is business email compromise?
What is the difference between BEC and phishing?
What are the red flags of business email compromise?
Can you be hacked with MFA enabled?
What is the average cost of a BEC attack in Australia?
What technical controls prevent business email compromise?
Is the property and construction sector particularly at risk?
How is BEC defence delivered by Inlight IT?
Close the gaps BEC actually exploits.
A cyber security review tests email authentication, identity hardening and the payment-verification process together — the combination that materially reduces BEC risk.
Book a cyber security review