Defending Against Spear-Phishing and Executive Impersonation in the UAE

Short answer. Require out-of-band verification for every payment instruction and supplier bank-detail change, on a number held on file, enforced regardless of who is asking. Back it with an enforcing DMARC policy, visible external-sender marking, lookalike domain monitoring, phishing-resistant multi-factor authentication, and alerting on mailbox rule changes. Then rehearse it with an unannounced simulation aimed at finance.

The regional business context does most of the attacker's work. Groups operate across several jurisdictions with genuine urgency in cross-border payments. Senior people travel, so a request arriving from an unfamiliar network at an odd hour is normal rather than suspicious. Hierarchy is real, and querying an instruction that appears to come from a chairman carries social cost. Supplier relationships often involve intermediaries, so a change of bank details is not inherently strange.

None of those are security failures. They are ordinary features of how business works here, and an attacker only has to find one process where a single person can move money on the strength of a message.

Out-of-band verification, enforced without exception. Every payment instruction above a defined threshold and every change to supplier bank details is confirmed on a channel the request did not arrive on, using a contact number already held in your records, never a number contained in the message itself.

Two details decide whether this control survives contact with reality. First, the threshold has to be low enough that splitting a payment does not bypass it. Second, the rule has to be enforced regardless of seniority. A verification process that a director can wave through is not a control, it is a suggestion, and impersonating that director is the entire attack.

Give finance staff an explicit, blame-free escalation path. The attack depends on nobody asking, and people ask when asking is free.

Publish SPF, DKIM and DMARC with an enforcing policy. A DMARC record at p=none is monitoring, not protection. Until the policy is at quarantine or reject, your own domain can be spoofed outright, which turns a sophisticated attack into a trivial one.

Mark external mail visibly, including on mobile. Most impersonation succeeds on a phone screen where the display name is shown and the address is not.

Monitor for lookalike domains. Certificate transparency logs and registrar feeds will show you a newly registered domain that differs from yours by one character, usually days before it is used.

Deploy phishing-resistant multi-factor authentication. Hardware-backed factors defeat credential capture and real-time relay in a way that push approvals and one-time codes do not.

Alert on mailbox rule and forwarding changes. Creating a rule that hides replies is the usual first action after an account takeover, and it is the earliest reliable signal you will get.

Contact the bank before anything else. Recall windows are measured in hours, and the finance team should already know which number to call without looking it up. Preserve the message with full headers rather than forwarding it, since forwarding rewrites the evidence.

Then determine whether this is impersonation from outside or a genuine account takeover, because the response diverges completely. Check the account for new mailbox rules, unfamiliar sign-in locations and any password or MFA changes. If the account is compromised, revoke sessions and reset credentials before you notify anyone through that mailbox.

Notify the other party through a channel the attacker does not control. If the compromise touches personal data, the UAE PDPL brings notification duties with it, which is a decision to make deliberately rather than in the third hour of an incident. See our UAE PDPL reference page.

An unannounced simulation aimed at the finance team and executive assistants tells you more about your exposure than any policy document. Measure the right thing: not the click rate, but whether the out-of-band verification step happened, and whether anyone who did click reported it.

We run these exercises as part of an information security audit in Dubai, and rebuild the payment verification process afterwards as part of cyber security consulting in Dubai. The second attempt is the one that matters, and it usually comes.