- Phishing is still the entry point for most healthcare ransomware, because clinical mail volume and third-party senders make aggressive filtering impractical.
- Domain authentication (SPF, DKIM, DMARC at enforcement) blocks direct spoofing but does nothing against lookalike domains or compromised vendor accounts.
- A real defence stack layers inline mail protection, identity controls and rehearsed response, not a single gateway product.
- Assessors care less about the vendor logo than whether you can produce logs, response times and a tested playbook.
Why hospitals are a harder email target than most enterprises
A retail bank can enforce strict sender allow-lists because most of its inbound mail is internal or from a known set of partners. A hospital cannot. Referring clinics, insurance networks, medical device vendors, locum staffing agencies and lab couriers all send mail from domains the security team has never seen before, and clinicians are trained to treat urgency in a message (an abnormal result, a pre-authorisation deadline) as something to act on quickly, not something to interrogate. That combination, high volume of legitimate unknown senders plus a workforce rewarded for fast action, is exactly the profile phishing preys on.
The technical estate compounds it. Many GCC hospital groups still run a mix of on-premises Exchange, a cloud tenant added during a merger, and a handful of departmental systems (PACS, lab middleware, patient portals) that send transactional mail through their own SMTP relays. Each relay is a potential spoofing vector if it is not covered by the domain's SPF record, and each acquisition or clinic onboarding tends to add senders faster than the security team updates authentication records.
How the attacks actually work
Three patterns account for most successful healthcare email compromises, and none of them require a sophisticated attacker.
Lookalike domain phishing. The attacker registers a domain that differs from the real one by a character, a hyphen, or a different top-level domain, then sends a message that looks like it comes from a portal, an insurer or internal IT. Because the domain is genuinely new, it has no reputation history yet in most filtering engines, so a purely blocklist-based gateway lets it through on day one. This is the single biggest reason "we already have a filter" is not the same as being protected: filters that key on sender reputation are structurally blind to brand-new infrastructure.
Credential harvesting through fake authentication pages. The email itself carries no malware, only a link to a page that mimics a real login screen, often Microsoft 365 or a patient portal. Because there is no attachment and no obvious payload, static scanning finds nothing to flag. The compromise happens entirely on the credential the user types in. Once the attacker has that password, they check whether multi-factor authentication is enforced and, if it is not, log in directly; if it is, they pivot to session-token theft or MFA fatigue prompts.
Business email compromise through account takeover. Rather than spoofing a domain, the attacker takes over a real mailbox, usually a vendor's or a partner clinic's, and waits inside it. From there they study real invoice patterns and insert themselves into an existing thread, changing bank details on a legitimate-looking follow-up. This defeats domain authentication entirely because the mail genuinely originates from the real domain. It is caught, if at all, by anomaly detection on sending behaviour or by a finance process that verifies payment changes out of band.
Where filtering actually breaks down
Most GCC healthcare providers already run some form of secure email gateway, so the honest question is not whether to add filtering but why the filtering already in place keeps missing things.
The most common gap is domain authentication configured but not enforced. SPF and DKIM records exist, but DMARC is set to a monitoring policy rather than reject or quarantine, because someone was worried it would break a legitimate mail flow and never went back to fix it. That leaves a spoofable window open indefinitely. The second gap is treating attachment sandboxing and URL rewriting as sufficient on their own; both help against known malware and known bad domains, but neither stops a credential-harvesting page hosted on infrastructure that has not yet been flagged as malicious, which is most of them in the first hours of a campaign. The third gap is scope: gateway policies applied to the primary mail domain but not to subsidiary domains, legacy clinic brands kept alive after an acquisition, or the outbound relay a lab system uses for automated result notifications.
What a workable defence stack actually looks like
None of the following is exotic. The value is in doing all of it together and keeping it maintained, not in any single control.
Domain authentication at enforcement
Publish SPF for every sending source, sign outbound mail with DKIM, and move DMARC from monitoring to quarantine or reject once the reporting shows legitimate senders are covered. This is the control that stops direct domain spoofing outright, and it is also the one most organisations configure once and never revisit as new systems start sending mail under the domain. Dedicated DMARC management platforms exist specifically to manage this lifecycle, because tracking every legitimate sender by hand does not scale past a handful of systems.
Inline mail protection
A gateway that sandboxes attachments, rewrites URLs to check them at click time rather than only at delivery, and applies computer vision or brand-impersonation detection to catch lookalike login pages closes most of the gap that basic reputation filtering leaves open. Microsoft Defender for Office 365 and Proofpoint both cover this ground; the real differentiator between them for a hospital buyer is usually integration depth with the identity stack already in place and how the sandbox handles the file types clinical systems actually exchange, rather than a headline detection percentage from a vendor data sheet.
Threat intelligence feeding the gateway, not just a dashboard
A gateway that judges a domain only on its own signature struggles against infrastructure registered hours before a campaign starts. Email threat intelligence closes that gap: feeds of indicators of compromise and newly observed malicious domains, contributed by other organisations and vendors that have already seen the campaign, ingested by the gateway or the SIEM/SOAR platform so a flagged domain is blocked within minutes rather than after it builds enough of a bad reputation against your own mail flow alone. The distinction that matters operationally is automation. A threat intelligence feed that lands in a dashboard for an analyst to read an hour later has already lost the race, because a phishing campaign only needs one click. Wired into the gateway as an automatic block list update instead, the same feed stops the message before a clinician ever sees it. Sector-specific feeds, where a hospital group can access one, add value over general commercial threat intelligence because they surface infrastructure targeting healthcare specifically before it reaches a wider blocklist.
Identity controls that assume a click will happen
Assume some staff member will click the link and enter credentials, because across a workforce of any size, someone eventually will. Phishing-resistant MFA (FIDO2 or certificate-based, not SMS) removes most of the value of a stolen password. Conditional access that blocks sign-in from unfamiliar countries or unmanaged devices catches the rest. Session-token protection matters increasingly as attackers shift toward adversary-in-the-middle kits that steal the live session rather than just the password.
A workforce that reports instead of just avoids
Training that measures click rate alone tells you how many people fell for a simulation; it does not tell you how fast a real attack gets contained. The more useful metric is report rate: the percentage of staff who forward a suspicious email to security rather than deleting it or clicking through. Tools such as KnowBe4 support this with localised, role-specific simulation content, but the operational win is a one-click report button wired into the SOC queue, so a genuine campaign gets flagged by employee three or four instead of discovered after employee thirty has already clicked.
What assessors actually ask for
Under frameworks referenced across the region (NESA-aligned controls, NCA ECC, and sector-specific data protection rules), the ask is rarely "which product do you run." It is evidence: authentication records with enforcement policy shown, not just existence; a documented incident response process specific to email-borne compromise, with named owners and response time targets; logs proving alerts were actioned within a stated window; and a training programme with attendance and outcome records, not a policy document nobody has read. Building that evidence trail is easier when phishing alerts feed a documented playbook rather than an inbox someone checks when they remember to. A structured incident response plan that names who quarantines a mailbox, who resets credentials, and who notifies affected departments turns an email compromise from a scramble into a rehearsed procedure, and it is exactly the artefact an assessor wants to see exercised, not just written.
Common failure patterns worth checking for
A few things show up repeatedly across GCC healthcare email deployments, independent of which vendor is in place. DMARC left in monitoring mode years after go-live is the most frequent. Close behind it: MFA enforced for the primary Microsoft 365 tenant but not for a legacy webmail portal or a third-party patient system still using basic authentication, which attackers specifically hunt for once the front door is locked. Sandboxing configured for email attachments but not for links shared through collaboration tools that the same mail security budget never covered. And security awareness training run once a year as a compliance checkbox, with no simulation and no feedback loop, which measurably does less than a single well-timed simulated campaign with immediate, specific feedback to the people who clicked.
Metrics that actually indicate progress
Track report rate over click rate; a falling click rate with a flat report rate usually means people are just getting better at ignoring the simulation, not at recognising real threats. Track time from a phishing report to mailbox quarantine, which should be measured in minutes once a playbook exists, not hours. Track the proportion of domains and subdomains actually covered by an enforced DMARC policy, since partial coverage is where spoofing persists. And track whether privileged accounts (clinical system administrators, finance approvers) have phishing-resistant authentication, because a single compromised privileged account does more damage than a hundred compromised standard mailboxes.
Where to start if none of this exists yet
Fix domain authentication first: it is the cheapest control per unit of risk removed and it stops the crudest attacks outright. Move MFA to phishing-resistant methods for anyone who can approve payments or administer clinical systems before extending it everywhere else. Only after both of those are solid does investing further in gateway sophistication or simulation tooling pay off, because a better filter cannot compensate for an unenforced DMARC record or a password that still works on its own.
