Phishing Attack Mitigation using AI

Why the classic gateway stopped being enough

Finance is targeted through email for one reason: email is where money movement gets authorised. Payment instructions, vendor invoices, salary file changes and treasury confirmations all travel through mailboxes, which makes a convincing forged message a direct path to funds rather than just a foothold.

The gateway model most GCC institutions bought a decade ago was built for a different problem. Reputation lists, signature engines and sandbox detonation are good at catching mass malware campaigns, and they still do. What they structurally miss is the mail that costs finance teams the most: a plain-text message from a lookalike domain, or from the genuinely compromised mailbox of a real supplier, asking accounts payable to update banking details. There is no attachment to detonate and no bad URL to look up. Every technical signal is clean because the attack is the text itself.

Attackers have also learned to host credential pages on infrastructure that reputation engines trust, including the major cloud file-sharing services. A link to a well-known collaboration platform passes a URL check by design. The detection problem has moved from "is this object malicious" to "is this conversation legitimate", and that is the specific gap AI-based detection exists to close.

What the AI layer actually analyses

Vendors use the same marketing words for very different machinery, so it helps to know the three signal families that do the work.

Sender behaviour graphs. The platform builds a baseline of who mails whom, from which infrastructure, at what times, in which language. A first-time sender asking for a payment, a reply arriving from different sending infrastructure than the rest of the thread, or a login followed by a new mailbox rule on an internal account all score as anomalies. This is the family that catches supplier account compromise, which no static rule can.

Content and intent classification. Language models classify what a message is asking for: urgency framing, requests to change bank details, payroll redirects, gift card asks, thread hijacks where the attacker replies inside a real conversation. Done well this works across English and Arabic; done poorly it produces the false positives that make finance teams distrust the tool, so ask any vendor to show verdicts on your own live mail rather than a demo set.

Visual and technical analysis. Computer vision compares rendered pages behind links against known brand login screens, reads QR codes out of image attachments, and measures how close a sending domain sits to your real ones. This family catches the credential harvest that the message text alone does not give away.

The operating truth that matters: these models learn each tenant's normal mail flow. That is why serious platforms want a learning period on live traffic before enforcement, and why day-one verdicts are noisy. Budget for tuning time, not just licences.

Gateway or API integration: the deployment decision that matters

There are two architectures, and the choice shapes everything downstream.

An MX-record gateway (Mimecast and Proofpoint built their names here) sits inline before delivery. It can block outright, it adds continuity and archiving features, and it keeps working when the mailbox platform has a bad day. Its blind spots: it never sees internal mail, so a compromised staff account phishing colleagues is invisible to it, and it cannot take back anything it has already delivered.

An API-integrated platform, with Microsoft Defender for Office 365 as the reference example on M365 estates, connects to the mailbox layer itself. It sees internal east-west traffic, and its strongest capability is post-delivery removal: when a verdict changes an hour after delivery, the message is pulled from every mailbox it reached. The honest tradeoff is the delivery window; a fast-clicking user can beat the verdict, which is why removal time is a metric worth testing rather than assuming.

In practice many GCC banks run both, and the real decision drivers are unglamorous: what the existing Microsoft agreement already includes (Defender for Office 365 Plan 2 ships inside E5, which changes the commercial conversation entirely), where the vendor processes data and whether that satisfies your regulator, and whether verdicts and incidents export cleanly to the SIEM your SOC actually works in. Detection accuracy differences between the serious vendors are smaller than the operational difference between a tuned deployment and a neglected one.

Where deployments actually go wrong

The failure modes I keep seeing in the region are consistent, and almost none of them are detection failures.

Monitor mode forever. The platform goes in, runs audit-only for the pilot, and nobody ever signs off enforcement because one false positive frightened a business unit. A year later it is an expensive reporting tool.

Empty impersonation lists. Executive impersonation protection only works when someone maintains the list of executives, finance staff and top suppliers it should cover. That list is a living control, and it is usually nobody's job.

No abuse mailbox process. Users report suspicious mail into a queue nobody triages. Report volume decays, the models lose a feedback signal, and the SOC loses its earliest warning of a campaign.

DMARC left at monitoring. If your own domain still publishes p=none, attackers can send exact-domain spoofs and your AI layer spends its effort on mail that authentication should have killed at the front door. Getting to enforcement is slow, political work across marketing platforms and third-party senders, which is exactly why DMARC enforcement deserves its own project rather than a checkbox inside the email security rollout.

Auto-remediation switched off. The clawback capability that justified the purchase gets disabled after one bad automated action, and nobody revisits the decision once tuning improves.

What analysts still own

No model confirms whether a supplier genuinely changed its bank account. That takes a phone call to a known number, and it belongs in the payments process as a verification rule, not in the mail filter. Analysts also own verdict disputes, tuning, and the incident work after a click: which identity was phished, what the session did, whether mailbox rules were planted, what the endpoint saw. AI detection shrinks the queue; it does not replace the judgement at the end of it. In my experience the institutions that get value fastest are the ones that planned analyst time for the first ninety days instead of treating the platform as fit-and-forget.

What assessors ask for

Regulated finance entities in the UAE and wider GCC should expect assessors to ask for evidence rather than product names: DMARC records at enforcement, phishing simulation results and report-rate trends, time-to-remove figures for confirmed phishing, and a documented playbook that covers credential phishing specifically, including forced re-authentication and mailbox-rule sweeps. A platform badge satisfies none of that. If you are building the wider control set around email, the email security service overview shows how the pieces fit together.

A short evaluation checklist for GCC finance teams

• Run any shortlisted platform against your own live mail in monitor mode and count what your incumbent missed, especially payload-free fraud.
• Test post-delivery removal time end to end, not in a demo tenant.
• Check verdict quality on Arabic and mixed-language mail with your own samples.
• Confirm where mail data is processed and get it in writing for your compliance file.
• Confirm native export of incidents to your SIEM before the commercial discussion, not after.
• Put DMARC enforcement and abuse-mailbox triage on the same project plan; the AI layer performs measurably worse without both.