- Business email compromise, not malware, drives most reported phishing losses in regional banks and insurers
- DMARC at enforcement (p=reject) stops exact-domain spoofing but does nothing against lookalike domains or a genuinely compromised vendor mailbox
- A secure email gateway and a native cloud filter (Defender for Office 365, Mimecast) catch different failure modes; running only one leaves a predictable gap
- Assessors increasingly want simulation click and report rates, not a policy document, as evidence the control works
Why banks with mature security programmes still get phished
Financial institutions in the UAE and wider GCC generally have layered mail defences already: a secure email gateway, native Microsoft 365 or Google Workspace filtering, and a security awareness vendor running quarterly simulations. Budget is not the constraint. The constraint is that most of that spend was designed against the phishing of five years ago, malicious attachments and obvious credential-harvesting pages, while the attacks that actually produce financial loss have moved to identity and payment workflow.
Banks and insurers are targeted specifically because they run high volumes of external correspondence tied to money movement: SWIFT and correspondent banking messages, supplier invoices, loan disbursements, treasury instructions. An attacker does not need to breach the core banking platform. A convincing email inserted into an existing payment conversation, timed against a real invoice or settlement, gets money moving faster than most exploit chains.
How the phishing that succeeds actually works
Three patterns account for most of what gets past a mature stack:
Business email compromise through thread hijacking. An attacker who has already compromised one mailbox, often at a supplier or law firm rather than the bank itself, waits inside a live email thread and inserts a bank-detail change at the point in the conversation where it looks routine. There is no malicious link or attachment to catch, because the attacker is working from an already-authenticated mailbox.
OAuth consent phishing. Instead of stealing a password, the attacker gets a user to authorise a malicious application in Entra ID or Google Workspace with mail read and send scopes. Multi-factor authentication does not stop this, because the user never enters a password on a fake page; they approve a permission dialog that looks like a normal app connection request.
QR code and image-based lures. Embedding the malicious link in a QR code or an image rather than plain text is now common specifically because it defeats URL rewriting and text-based link scanning in older gateway configurations. The payload only becomes a URL once a phone camera reads it, off the corporate network and its inspection tools.
None of these rely on a user clicking an obviously bad link. That is the practical reason phishing simulation results and technical control effectiveness have started to diverge: an organisation can have a low simulation click rate and still be exposed to thread hijacking and consent phishing, because those attacks are not what a standard simulation tests for.
Where the technology layer genuinely differs
The secure email gateway versus native cloud filtering debate is not settled by picking one vendor over another; the two architectures cover different ground. A gateway that only inspects mail at the MX record, before Microsoft 365 or Google Workspace ever sees it, has no visibility into internal-to-internal mail or a mailbox that is already compromised and sending from inside the tenant. Native, API-integrated filtering such as Defender for Office 365 or an API-based deployment of Mimecast sits inside the mailbox itself, which is what lets it flag post-delivery threats, unusual mailbox rule creation, and impossible travel on sign-in, the signals that actually surface an account takeover in progress.
DMARC is necessary and frequently misunderstood. Set correctly with SPF and DKIM alignment and enforced at reject rather than left at none or quarantine, it stops an attacker from sending mail that appears to come from your exact domain. It does nothing about a lookalike domain one character off, and nothing about a genuinely compromised third-party mailbox sending from its own legitimate domain, which is why thread hijacking evades it entirely. Domain protection platforms such as DMARCS or comparable DMARC monitoring services close the reporting and enforcement gap, but they are one layer among several, not a phishing solution on their own.
What assessors and regulators actually expect to see
Financial sector oversight in the UAE increasingly asks for evidence rather than a written policy. In practice that means: simulation results tracked over time with report rates alongside click rates, since a falling click rate paired with a flat report rate suggests people are just getting quieter about being fooled; an audit trail of mailbox forwarding rule changes, because silent auto-forwarding to an external address is one of the most common indicators of an active compromise; conditional access tied to sign-in risk rather than MFA alone, since MFA fatigue and consent phishing both route around a password check; and a payment fraud runbook that names who calls the receiving bank to attempt a recall, on what timeline, separate from the general incident response plan. A generic incident response document that does not name a wire-recall path is usually the first gap an assessor will flag.
Building a stack around how these attacks actually happen
The practical shift is away from buying more of the same filtering and toward closing the specific gaps described above:
- Native, API-based mail security that inspects internal mail and post-delivery activity, not only inbound traffic at the gateway
- DMARC at enforcement, paired with ongoing monitoring for newly registered lookalike domains rather than a set-and-forget SPF record
- Conditional access rules driven by identity risk signals, so a session token or consented app is caught even when the password was never touched
- Simulation programmes measured on report rate and speed to report, not click rate alone, run through a dedicated awareness platform, with results reported to the board
- A payment-specific verification step, ideally an out-of-band call to a known number, for any change to bank details or urgent transfer request, regardless of how convincing the email thread looks
A short test before signing off on an email security stack
Ask whether the current deployment would catch a thread hijack originating from a compromised supplier mailbox, an OAuth consent grant, or a QR-coded lure, since those are the three patterns doing the damage now, not attachment-borne malware. If the honest answer for any of them is "we are relying on user awareness alone," that is the gap to close first, and it usually costs less to fix than the next platform migration. For a closer look at how the detection engines behind these filters actually work, see how AI-based email security actually works in UAE banking.
