Email Threats in UAE Finance: Why Banks Keep Failing

Why banks take the worst of it

Every sector gets phished. Banks lose more money to it because banking runs on one-off payment instructions that arrive by email as a matter of course: a correspondent bank confirming settlement details, a corporate client asking to redirect a payment, a vendor updating its account number ahead of an invoice run. A payments clerk who processes dozens of these a week cannot treat every one as suspicious, and that is exactly the gap business email compromise is built to exploit. The fraud does not need to beat a filter. It needs to look like Tuesday.

Multiple approval layers do not close this gap by themselves. A four-eyes process still fails if both approvers trust the same forged thread, and offshore branches or correspondent relationships mean a request from an unfamiliar sender name is normal rather than a red flag. The attack surface is not the mail server. It is the number of legitimate reasons someone might ask a bank to move money based on an email.

How business email compromise actually works

Most BEC that reaches a UAE bank follows a small number of patterns, and understanding the mechanics matters more than the label.

Domain and display-name spoofing is the crude version: a lookalike domain (a swapped character, an extra letter, a different top-level domain) or a spoofed display name on a free or newly registered domain, sent to a target identified from a website, a tender document, or LinkedIn. This is what SPF, DKIM and DMARC exist to stop, and it is the version most secure email gateways catch reliably.

Thread hijacking is more dangerous because it does not need to spoof anything. An attacker who has compromised one mailbox in a vendor or client organisation reads live conversations, waits for a genuine invoice or payment thread, and replies into it from the real, unspoofed account with a plausible request to redirect the next payment. Every authentication check passes because the sender is genuine. The only thing wrong is the beneficiary.

Mailbox rule abuse is what makes thread hijacking durable. Once an attacker has valid credentials or an OAuth token for a mailbox, a single inbox rule can silently forward, mark as read, or delete anything containing words like "invoice", "payment" or "urgent", hiding both the fraud and the eventual complaint from the account owner for weeks.

Credential and session theft is how attackers get that access in the first place, and this is where the threat has moved fastest. Adversary-in-the-middle phishing kits proxy a real login page in real time, capturing the password and the MFA response and walking away with the live session token. SMS codes and push approvals do not stop this, because the victim is authenticating on the attacker's proxy, not on a fake page the attacker has to guess correctly.

Where UAE bank email security actually breaks

The gaps I see repeatedly are less about missing tools and more about tools left half-configured.

DMARC is present but not enforced. Most banks have SPF and DKIM records and a DMARC record at p=none, which only reports on spoofing rather than blocking it. Moving to p=quarantine or p=reject requires first identifying every legitimate system sending on the bank's behalf, marketing platforms, HR systems, ticketing tools, and getting each one properly authorised. That inventory work is unglamorous, takes a monitoring period of real DMARC aggregate reports, and gets skipped in favour of buying another detection product instead.

Lookalike domains sit outside DMARC entirely, because DMARC only governs the bank's own domain. Nobody is watching for typosquats or homoglyph registrations of the bank's brand unless someone has specifically bought a domain-monitoring service or capability for it.

MFA exists but is not phishing-resistant. SMS OTP and push notifications satisfy a checkbox but not an adversary-in-the-middle attack. The staff who can approve payments or change banking details are frequently the ones still on the weakest MFA method, because hardware keys or platform passkeys were rolled out to IT first and never extended to finance.

Payment-change requests still have no out-of-band step. The single most consistent gap in BEC losses is that a request to change a beneficiary's bank details is verified by replying to the same email thread the request arrived on, rather than by calling a phone number obtained before the request, from a source other than that email.

What assessors actually check

Under the CBUAE cybersecurity framework and comparable regional expectations, assessors are less interested in which product a bank bought and more interested in evidence: DMARC records showing enforcement rather than monitoring-only status, a documented and tested process for verifying payment instruction changes, records of mailbox rule audits and privileged or shared mailbox access reviews, phishing simulation results tracked over time rather than a single annual exercise, and incident response timelines for reported suspicious email. A gateway subscription with no evidence behind it does not satisfy that expectation.

The controls that actually reduce BEC losses

Ranked by what stops real losses, not by what is easiest to sell.

Callback verification on payment or beneficiary changes is the highest-value control available, and it is a process change, not a product. Any request to change bank details, however it arrives, gets confirmed by phone on a number sourced independently of that request. This alone stops the overwhelming majority of successful redirect fraud, because it does not depend on detecting the deception, only on refusing to act on an email alone.

DMARC enforcement at p=reject, reached through the monitoring-and-fix cycle rather than skipped straight to, closes off domain spoofing of the bank's own name.

Phishing-resistant MFA, FIDO2 hardware keys or platform passkeys, for anyone who can approve or redirect payments removes the value of stolen passwords and OTP codes to an adversary-in-the-middle kit.

Conditional access that blocks legacy authentication protocols and flags risky sign-ins closes the path attackers use once they do get valid credentials, before they can set up the forwarding rules that make an intrusion durable.

Simulated testing that mirrors an actual BEC attempt, a spoofed vendor payment change or a thread-hijack style request, tells a bank far more about its real exposure than a generic phishing click-rate exercise, because it tests the verification workflow, not just whether staff notice a bad link.

A secure email gateway such as Mimecast layered in front of, or alongside, native Microsoft Defender for Office 365 protection adds impersonation and vendor-email-compromise detection that catches display-name and lookalike-domain attempts before the human step is even needed, though it will not by itself catch a hijacked thread from a genuinely compromised sender.

Where AI actually helps, and where it does not

AI-driven detection in email security earns its place on anomaly detection: writing-style analysis, sender-relationship graphs, and unusual timing or geography can flag a message that passes every authentication check but does not read like the person who normally sends it. That is a real improvement over pure signature and reputation filtering.

It is not a replacement for the verification workflow. Generative tools have also raised the floor on attacker-side writing quality, so the grammatical tells that used to flag phishing are disappearing, and a bank that treats an AI-labelled gateway as sufficient on its own is trading one single point of failure for another. The callback step exists precisely because detection, AI-assisted or not, will keep missing some fraction of attempts.

Building the stack

A workable UAE bank email security stack usually has four separate pieces, not one product doing everything. Native Defender for Office 365 filtering, or equivalent, handles the baseline for mail estates already on Microsoft 365. A dedicated secure email gateway layered on top adds impersonation-specific detection and archiving that native tooling does not match. Dedicated DMARC enforcement consulting, such as the work DMARCS does moving domains from monitoring to enforcement, handles the aggregate-report analysis needed to reach p=reject without breaking legitimate mail flow, which is genuinely hard to do by hand at bank scale. And a security awareness platform such as KnowBe4 runs the ongoing simulation and training that turns "staff were told once" into a measured, trending metric an assessor can actually review.

None of these four pieces substitutes for the callback verification rule. They reduce how often that rule gets tested.

Where to start this quarter

If a bank can only fund one initiative, callback verification for any payment or beneficiary change is it, because it is free, fast to mandate, and closes the gap that actually produces losses. After that: pull DMARC aggregate reports and start the authorisation inventory needed to reach enforcement; move finance approvers off SMS and push MFA onto phishing-resistant hardware or passkeys; audit mailbox forwarding rules across finance and executive accounts on a recurring schedule, not a one-off; and replace the annual generic phishing test with simulations built around actual payment-change and thread-hijack scenarios. None of this requires a new platform. Most of it requires deciding that a process gap, not a missing product, is the reason these losses keep happening.