- Backups fail most often because attackers reach domain admin and delete or encrypt them before the ransomware payload ever runs.
- Unconstrained delegation, Kerberoastable service accounts, and flat Active Directory trusts are the paths that get an attacker from one compromised workstation to a domain controller.
- Detection has to catch privilege abuse, shadow copy deletion, and mass file access before encryption starts, not the encryption event itself.
- Assessors increasingly want evidence that a restore actually worked within a stated time window, not a backup policy document.
Prevention buys time, it does not buy certainty. Every organisation with a mature security programme still assumes a phishing click or an exposed remote access portal will eventually get an attacker onto an endpoint. The question that decides whether that becomes an outage or a headline is how far that foothold can travel before someone notices, and whether the recovery path survives the attacker's attempt to burn it down.
Modern ransomware operations are rarely a single automated payload anymore. Most active groups run double extortion: exfiltrate data first, then encrypt, then threaten publication if the ransom is not paid. That changes the calculus for defenders in two ways. First, egress monitoring and data loss prevention on large or unusual outbound transfers matter as much as endpoint controls, because the exfiltration step often happens hours or days before encryption and is quieter than the encryption event itself. Second, a clean restore from backup does not close the incident if customer or employee data has already left the network, which is why the containment and legal response tracks have to run in parallel rather than one after the other.
Backups are necessary, not sufficient
Backups get treated as the ransomware control, when they are really the last resort after every other control has already failed. The recurring pattern in ransomware incidents is straightforward: the attacker does not encrypt first. They enumerate the backup infrastructure, and if the backup service account has domain admin rights, or the backup credentials sit in the same directory as the rest of IT, they delete or encrypt the backups before deploying the payload. A backup policy that has never been tested against a privileged-account compromise is not a control, it is an assumption.
The fix is architectural rather than procedural. Backup infrastructure needs its own credential tier that domain admin cannot reach, immutability that a privileged account cannot override even with valid credentials, and at least one copy that is genuinely offline or air gapped. Object lock on cloud storage and hardware write once configurations both work; what matters is that no single compromised account, however privileged, can shorten the retention window.
Identity is the real perimeter
Multi factor authentication at the login screen does not stop an attacker who is already inside the domain and requesting Kerberos tickets. Once a service account is compromised, an attacker with the right delegation rights can request a ticket granting ticket, impersonate a higher privileged account, and move to a domain controller using nothing but built in Windows tooling. No malware, no exploit, just native protocols behaving exactly as designed.
Unconstrained delegation and excessive Kerberos ticket lifetimes are among the most consistently cited findings in Active Directory security reviews, and Gulf enterprises are not an exception. Legacy delegation is often left in place because a line of business application was configured against it years ago and nobody wants to be the one who breaks it. The mitigation is to inventory every delegation relationship, replace unconstrained delegation with constrained or resource based constrained delegation where the dependency is real, and remove it everywhere else.
What identity threat detection actually needs to catch
Identity threat detection and response tools such as Microsoft Defender for Identity exist specifically because signature based endpoint tools do not see ticket abuse, DCSync style replication requests, or a service account authenticating from a host it has never touched before. The signal set that matters for ransomware precursors is narrow and specific: replication rights being exercised by an account that has never used them, Kerberoasting patterns against service accounts with weak passwords, and privileged accounts logging in outside their normal pattern of hosts and hours. Periodic access reviews catch stale entitlements. They do not catch a ticket forged an hour ago.
Lateral movement: the part perimeter tools cannot stop
Lateral movement prevention means removing an attacker's ability to reuse legitimate credentials and native admin tooling once they are past the initial compromise. In practice that means restricting remote PowerShell, WMI, and PsExec style tooling to a small, monitored set of jump hosts, enforcing application allow listing on servers that should never run arbitrary binaries, and treating every administrative session as something to log and alert on rather than something to trust because it authenticated correctly.
Endpoint detection and response is the layer that is supposed to catch this in flight, and it is worth being honest about its limits. EDR platforms such as CrowdStrike Falcon are strong at catching known tooling and behavioural anomalies on the endpoint, but they can be disabled through group policy or tamper protection gaps if the attacker already holds domain admin, which is exactly why identity containment has to happen before that point, not instead of it. EDR and identity threat detection are complementary controls, not substitutes for each other.
Segmentation policies rot faster than the network does
Network segmentation built for a single entity does not survive a merger, an acquisition, or an IT and OT convergence project without deliberate review, and in practice it rarely gets one. VLANs and firewall rules designed for availability rather than containment let an attacker move from a corporate segment into an operational technology environment using credentials that were never meant to cross that boundary. The practical fix is to segment by identity and data classification rather than IP range, and to treat segmentation policy as something that gets revisited on every organisational change, not something set once during a network refresh and left alone.
Detection engineering: catching the behaviour, not the file
By the time a SIEM alerts on mass file encryption, the outcome is already decided. Detection engineering for ransomware means building correlation rules around the behaviours that precede encryption: shadow copy deletion commands, security tooling being disabled through group policy, a spike in failed then successful authentication from a single account, or a service account touching file shares it has never accessed before. A platform like FortiSIEM is only as good as the use cases tuned into it. Out of the box correlation rules generate volume; the rules that catch ransomware early are the ones built around the specific privilege and access patterns of the environment they run in, which takes deliberate tuning rather than a default rule pack.
Cloud workloads complicate this further. Identity and access events in Azure or AWS often live in a different logging pipeline than on-premises authentication, with different retention and different access controls, and that split is exactly where lateral movement between cloud and on-premises identities goes unnoticed. Centralising identity-aware logging and setting a consistent retention window across both environments closes a gap that otherwise sits unmonitored by default.
Recovery has to include identity, not just files
Restoring encrypted files from backup does not help if the domain that issues trust for those files is still compromised. A recovery plan that only covers data restoration will hand a rebuilt file server back to an Active Directory forest that may still contain the account the attacker used to get in. Recovery validation needs to cover rebuilding or re-certifying the identity infrastructure alongside the data, and that means a documented sequence for resetting krbtgt, rotating privileged credentials, and re-establishing trust before production traffic resumes.
Annual restore tests catch whether backup media works. They do not catch whether the organisation can restore a domain controller, validate that no persistence mechanism survived, and bring services back in an order that does not reintroduce the same exposure. Isolated recovery environments that mirror production without exposing live data let a team practise this sequence without the risk of testing against production.
Incident response: the decisions that cannot wait
The first hour of a ransomware incident is about containment and evidence preservation, not root cause analysis. Organisations that recover fastest have already decided, before an incident happens, who has authority to isolate a segment or take a system offline, what the communication plan looks like internally and to regulators, and which business processes have a manual fallback. A written and rehearsed incident response plan turns those into decisions made in advance rather than arguments held during the outage.
For groups with subsidiaries or shared services spanning more than one GCC jurisdiction, that plan also needs to answer who owns regulatory notification in each jurisdiction and how quickly, because breach notification timelines and authorities differ across the region. Getting that wrong compounds a technical incident into a regulatory one.
What assessors actually ask to see
NESA and CBUAE control frameworks describe outcomes, and the way they get tested in practice is through evidence, not intent. An assessor asking about ransomware readiness typically wants to see a tested incident response plan with a recorded exercise date, evidence that backups were restored within a stated recovery time objective, a current network segmentation diagram that matches the actual environment rather than the one from the last audit cycle, and a list of privileged accounts with delegation and group membership documented. A policy document describing what should happen is not evidence that it does.
Where to start if the programme is behind
If none of this exists yet, the sequence that reduces the most risk fastest is: separate backup credentials from the rest of the domain and enable immutability, inventory Active Directory delegation and remove what is unconstrained and unused, restrict remote administrative tooling to monitored jump hosts, and run one recovery drill that includes an identity rebuild rather than only a file restore. None of these require a new platform purchase to start. They require someone with domain admin access and a mandate to change configuration that has been sitting untouched since it was first set up.
