If you’ve been following the rise of AI at all, you can tell how much the technology has improved since we’ve seen the first iteration of an AI-generated video (one famous example is that of Will Smith eating spaghetti in 2023). The technology has progressed by leaps and bounds since, making deepfake voice and video not only tremendously convincing but also lowering the effort of criminals to impersonate leaders or suppliers.
However, one thing hasn’t changed: urgency and authoritative language as the core tactic. The new risk lies in fraud attempt that are consistent across channels (e.g. email, phone and Teams). Why? Because even out-of-band verification without extra steps – like a phone call with the CEO -can get manipulated thanks to voice cloning.
We’ve addressed BEC in great detail in our last blog post, but here are some of the approaches we see out in the field:
Route A: Compromised mailbox through AI phishing leads to token/session capture and as a consequence mailbox rules/forwarding.
Route B: Lookalike domains and display-name spoofing - no compromise needed
Route C: Compromised third party (supplier account compromised)
Route D: Teams/SharePoint abuse via malicious links, filesharing, and impersonation
And what’s the end point? Payment redirection, payroll diversion, invoice fraud or gift scam cards.
From Impersonation to Payment Request in Six Steps
But not all hope is lost, below a list of things for you to consider in Entra ID to make it more difficult for criminals to get in.
Enforce Multi-Factor Authentication (MFA) if you haven’t already done this, so that even if a criminal has acquired login credentials, they would still need to overcome the barrier of an additional step of verification. This is especially important for those high-risk IDs of executives, finance, payroll and admins.
Implement Conditional Access (CA) policies that block legacy authentication (as it doesn’t support MFA), and require compliant devices and approved apps for high-risk users via Intune. This means you’ll prevent devices that don’t meet certain requirements (e.g. minimum operating system and being anon-rooted device) and “random” apps hackers may be using from accessing your systems
Another step further is implementing risk-based policies (if you have Entra ID P2/Entra Suite) to respond to risky sign-ins as indicated by an unusual location, device, behaviour patterns, and known compromised infrastructure.
And lastly, reduce privilege by creating separate admin accounts and also limit who can change payment-related systems. If a hacker happened to gain access to an account, they would at least still be bound by the limitations you’ve given it.
Next, lets look at email controls.
Ensure you have anti-phishing and impersonation protection turned on (especially for executives/finance), but equally safe links/safe attachments.
Also important are external sender labelling and warning banners (but this setting shouldn’t be too sensitive, otherwise users will just end up ignoring them) according to domain authentication basics. Sender Policy Framework (SPF), DKIM (Domain Keys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting &/ Conformance) are email authentication standards that help stop attackers from spoofing (= imitating) your domain. SPF tells recipients which mail servers are allowed to send on your behalf, DKIM adds a cryptographic signature to prove a message really came from an authorised sender and hasn’t been altered, and DMARC ties the two together by telling receiving systems what to do when checks fail (monitor, quarantine, or reject) and providing reporting. They’re very effective at reducing straightforward “this looks like it’s from yourcompany.com” spoofing, especially once DMARC is enforced but unfortunately don’t stop lookalike domains, display-name impersonation, or BEC where criminals use compromised real accounts inside Microsoft 365. That’s why authentication is a necessary baseline but needs further measures.
When attackers compromise a mailbox, one of the first things they try to do is set up external forwarding (or a redirect rule) so that every relevant email also lands in an attacker-controlled inbox. That allows them to keep receiving email even if you reset the password or kick them out and to watch supplier threads, invoices, approvals, and internal comms in real time. Why? Finding the exact moment to jump in when payment is due or details are being discussed. What can you do to prevent it? Restrict external auto-forwarding.
Cybercriminals also commonly create mailbox rules and permissions changes to hide evidence and control conversations. “Send as” and “send on behalf” also lets the attacker send convincing messages from the real identity and run multiple conversations from a single compromised identity. While you usually use mailbox rules to keep it tidy, a hacker would move or delete supplier responses, move finance messages or mark them as read using them to keep under the radar while being able to send emails from the victim’s address. Using rules prevents the victim from seeing replies, so they won’t realise someone else is responding. Additionally, finance-related trigger keywords for rules like “invoice”, “payment”, “bank” and “IBAN” allows threat actors to target relevant conversations with laser precision. For this reason, monitor and alert on mailbox rule creation and delegate changes.
Attackers increasingly use OAuth (standard way for an app to get passwordless access to data) consent abuse by tricking a user into granting a malicious (or compromised) app permission to access Microsoft 365 data.
They use this to:
What to do: introduce app consent governance – and admin consent for high-risk scopes.
It’s a known fact that higher security unfortunately also inconveniences users if not implemented without prior testing/piloting. For that reason, it’s important to scope and prioritise on a practical basis.
This includes defining “high-risk roles” and why they’re targeted and creating a “high-risk users” group for stronger policies
We suggest the following security as the baseline for this group:
How can this go wrong? Common pitfalls we see are too many exemptions, shared accounts for finance workflows and approvals that are handled entirely in email.
While obviously not every business uses the same tools,there’s still a few ground rules you should observe to protect yourself:
1. Never change bank details from an email request alone
Build a simple workflow…
Request → Verification → Approval Recorded → Payment Executed
… and standardise by using a) templates/scripts for call-backs and b) an audit trail of who verified what.
Fraud is stopped by process. Monitoring tells you when the process is under attack.
In summary, here’s what to look out for:
If you want to reduce BEC risk quickly, start with a 30-day programme that locks down the approval process, tightens access for the people attackers truly target, and makes the quiet takeover behaviours visible. The goal is simple: make it hard to change payment details, and easy to detect and contain compromised mailboxes before money moves.
This is the leadership piece, and it’s non-negotiable .Define the rules that apply every time, even when the request sounds like the CEO.
Now you reduce the chance that one successful phish becomes a sustained fraud.
This is the detection piece. Most BEC isn’t discovered because an alert fires but because one of your suppliers rings after the fact. You want to be proactive and discover it before that happens.
Prioritise alerting on:
Make it operational:
This is where you turn theory into a usable response. Keep it short, conversational, and decision-led.
Run a scenario such as:
Test these questions:
Finish with a simple close-out:
This month-long playbook won’t solve everything, but it will dramatically reduce the odds of a successful BEC event and, just as importantly, reduce the time it takes to spot and stop one.
Deepfakes make BEC feel like a brand-new threat, but it actually still succeeds for the same reason it always has: someone is able to push an approval or a payment change through faster than your organisation can verify it. Microsoft controls can reduce the likelihood of compromise and make the quiet takeover behaviours visible, but what you really need is combining them with non-negotiable process rules and clear authority to pause payments and contain accounts. If you implement the 30-day playbook above, you’re building a system where impersonation attempts are harder to execute, easier to spot, and far less likely to cost you money.