Ransomware Prevention Guide

Ransomware is rarely a single piece of malware that arrives and encrypts; it is usually the last step of an intrusion that began earlier with a stolen credential, an exposed remote service or an unpatched edge device. Prevention therefore means breaking that chain at several points: closing initial access paths, hardening endpoints and servers so that operators cannot spread or switch off defences, adding controls that stop bulk encryption, and keeping backups the attacker cannot reach. This guide covers those prevention controls in practical detail, drawing on the CISA #StopRansomware Guide, NCSC guidance and NIST IR 8374 Rev. 1. It is written for security engineers, infrastructure teams and the managers who own ransomware readiness. Incident response and recovery are covered only where they shape prevention decisions.

Key takeaways

• Most ransomware starts with access, not malware. CISA lists internet-facing vulnerabilities and misconfigurations, compromised credentials, phishing, precursor malware and third parties as the common initial access routes, so identity and patching controls carry as much weight as endpoint tools.
• Backups decide the outcome. NCSC states that "Up-to-date backups are the most effective way of recovering from a ransomware attack", but only if at least one copy is offline or otherwise out of the attacker's reach and restores are tested.
• Protect the recovery mechanisms on the endpoint. Operators delete shadow copies, backup catalogues and boot recovery settings before encrypting (ATT&CK T1490), and stop database and backup services (T1489). These commands are a high-confidence detection opportunity.
• Hypervisors are the fastest route to mass encryption. Encrypting VMware ESXi datastores takes down every virtual machine at once, and hypervisors sit outside most endpoint controls, so they need their own hardening and monitoring.
• Privileged identities spread the payload. Domain administrator rights, Group Policy and management tools are how ransomware reaches large numbers of devices quickly; tiered administration, LAPS and phishing-resistant MFA limit the blast radius.

The ransomware kill chain and where to break it

Human-operated ransomware follows a recognisable sequence. Each stage has its own prevention control, and every stage blocked is another chance to stop the attack before anything is encrypted.

Double extortion changes the maths: even perfect backups do not stop the threat to publish stolen data. The original NIST IR 8374 describes attackers who "may also steal an organization's information and demand an additional payment", which is why the earlier stages matter as much as recovery.

Closing initial access paths

• Remote access: CISA says "Do not expose services, such as remote desktop protocol, on the web." Put remote access behind a VPN or zero trust network access gateway, require MFA on every remote access point, and remove dormant accounts. In the Colonial Pipeline attack, a single unused VPN account was enough. See the Remote Access Identity Guide.
• Credentials: CISA recommends "phishing-resistant MFA for all services". The Change Healthcare breach began with one Citrix login without MFA. See the MFA Guide.
• Edge devices: NCSC advises patching "known vulnerabilities in all remote access and external facing devices immediately". Prioritise vulnerabilities on CISA's Known Exploited Vulnerabilities catalogue and keep an inventory of every internet-facing service.
• Email: filter attachment types you do not expect to receive, enforce DMARC and disable macros in Office files that arrive by email, as the CISA guide recommends.
• Third parties and help desks: CISA asks for least privilege and separation of duties for third-party access. Help desk social engineering is another route in, as the Marks and Spencer attack showed. See the Account Recovery and Help Desk Security Guide.
• Cloud keys: ransomware does not always need an endpoint. In the Codefinger S3 ransomware campaign, stolen AWS keys were used to encrypt buckets with AWS's own server-side encryption. ATT&CK suggests an IAM policy that restricts SSE-C on S3 where you do not use it.

Hardening endpoints and servers

Settings below come mainly from CISA and NCSC.

• Application allowlisting: CISA recommends "allowlisting rather than attempting to list and deny every possible permutation of applications", using App Control for Business (WDAC) or AppLocker. Start with servers and administrative workstations, where software changes least.
• EDR everywhere: "Use application allowlisting and/or endpoint detection and response (EDR) solutions on all assets." Servers without EDR give operators an unwatched place to stage tools. See the Active Directory and Entra ID Hardening Guide for domain controller hardening.
• SMB: disable SMBv1, move to SMBv3, and require SMB signing on clients and servers, with SMB encryption preferred where supported.
• Local accounts: deploy LAPS and use Group Policy to block network sign-in by local accounts, so one cracked local password does not open every machine.
• PowerShell: remove earlier PowerShell versions, restrict PowerShell use to specific users through Group Policy, enable enhanced logging and keep PowerShell logs for at least 180 days, per CISA. NCSC also recommends Constrained Language mode.
• Host firewalls: NCSC advises host-based and network firewalls "disallowing inbound connections by default". Blocking SMB, RDP and WinRM between workstations removes a common path for peer-to-peer spread.
• Domain controllers: CISA notes that attackers "often target and use DCs as a staging point to spread ransomware network wide". Patch them promptly, install minimal software and block their direct internet access.
• Golden images: maintain and regularly update "golden images" of critical systems, and use infrastructure as code for cloud resources, so you can rebuild rather than clean.

Anti-ransomware controls on the endpoint

These controls aim to stop or limit encryption on the device itself. The examples use documented Microsoft Defender features; most EDR platforms offer equivalents.

Canaries and rollback

D3FEND defines a decoy file as "A file created for the purposes of deceiving an adversary", with access monitored so that any interaction signals adversary activity. For ransomware, place decoy documents in shared folders and at the start of directory listings, enable object access auditing on them (Security event 4663 with a SACL) or use your EDR's file monitoring, and route any modification straight to an automated isolation playbook. Some EDR products also offer file rollback after a ransomware detection. Before relying on it, ask the vendor where rollback data is stored, because operators routinely delete Volume Shadow Copies and backup catalogues (T1490), and rollback that depends on them may not survive.

Hypervisors and ESXi

ATT&CK notes that adversaries "may also encrypt virtual machines hosted on ESXi or other hypervisors", and that on ESXi they may delete or encrypt VM snapshots to remove them as backups. Ransomware families also stop running virtual machines before encrypting their disks (T1489). CISA warns that ransomware has begun targeting ESXi servers, enabling fast encryption at scale.

• Patch and isolate management: keep ESXi and vCenter current, never expose management interfaces to the internet, and place them in a management network reachable only from privileged access workstations.
• Review Active Directory integration: Microsoft reported in July 2024 that ransomware operators exploited CVE-2024-37085, where members of a domain group named "ESX Admins" received full administrative access to domain-joined ESXi hosts by default, with membership matched "by name and not by security identifier (SID)". The fixes are VMware's update or, where that is not possible, changing the advanced setting Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd and hardening the group. Consider whether hypervisors need to be domain-joined at all.
• Lockdown and logging: enable lockdown mode, disable SSH and the ESXi Shell except during maintenance, and forward ESXi logs to the SIEM. ATT&CK lists esxcli commands that disable syslog, the firewall or lockdown mode as a detection signal (T1685).
• Backups outside the cluster: keep VM backups and disk images off-system (ATT&CK M1053), with backup infrastructure that does not share credentials with vCenter.

Backups that survive an attack

CISA's guidance is to "Maintain offline, encrypted backups of critical data" and to test them regularly, because "many ransomware variants attempt to find and subsequently delete or encrypt accessible backups". NCSC adds that backup devices should not be "permanently connected to your network" and that backups should be scanned for malware before restoring.

• 3-2-1 plus offline: the NCSC blog Offline backups in an online world notes that the 3-2-1 rule (three copies, two devices, one offsite) does not on its own require any copy to be offline, so add the rule of never having all backups connected at the same time.
• Separate backup identities: administer backups from privileged access workstations with their own accounts, use PAM to remove direct admin access, and keep the MFA method off the device used for backup administration (NCSC).
• Limit what backup clients can do: clients that can only create or append backups cannot overwrite existing ones. Backup clients should not hold valid credentials while storage is idle.
• Cloud backups: enable object versioning, copy backups to a separate account or region, and restrict snapshot and backup deletion with policy (ATT&CK T1490 mitigations M1053 and M1018). CISA suggests a multi-cloud approach for cloud-to-cloud backups.
• Immutability with care: CISA notes immutable storage "does not meet compliance criteria for certain regulations", so check retention and deletion obligations before locking data.
• Verify before restoring: NIST IR 8374 Rev. 1 highlights RC.RP-03, verifying the integrity of backups before using them, so a restore does not reintroduce the attacker.

Small organisations: a managed cloud backup with versioning, MFA on the backup account and one offline or immutable copy is usually achievable and covers most risk. Large organisations: separate backup administration into its own identity tier, test full restores of tier 0 services (identity first), and measure recovery time against business impact tolerances rather than backup job success rates.

Implementation: a phased approach

1. Assess readiness. Use the NIST IR 8374 Rev. 1 profile as the checklist. Inventory internet-facing services, remote access accounts without MFA, local administrator exposure, backup coverage and when a full restore was last tested.
2. Fix the quick, high-value gaps. Remove exposed RDP, enforce MFA on remote access, disable dormant accounts, patch known exploited vulnerabilities on edge devices and take one offline backup copy of critical data.
3. Deploy endpoint controls in audit mode. ASR rules (event 1122) and controlled folder access (event 1124) in audit for two to four weeks; review which business applications would be blocked.
4. Pilot and enforce by ring. IT devices first, then business users, then servers. Allow-list legitimate applications for controlled folder access rather than disabling it.
5. Harden identity and lateral movement paths. LAPS, local account network sign-in restrictions, SMB signing, host firewall rules between workstations, separate administrator accounts and tiered administration.
6. Harden hypervisors and backups. ESXi lockdown and logging, backup credential separation, immutability or offline copies, cross-account cloud copies.
7. Test. Run a tabletop exercise (NCSC's Exercise in a Box is free), a full restore test and a controlled ransomware simulation in a lab to confirm detections fire.
8. Rollback. Every ASR rule can return to audit mode or take a per-rule exclusion; controlled folder access can return to audit mode (AuditMode) while an application is allow-listed. Record each rollback with an owner and a date to re-enforce.

Detection and measurement

Metrics that show prevention is working:

• Remote access MFA coverage: percentage of remote access and internet-facing accounts protected by phishing-resistant MFA (target 100 per cent).
• Edge patch latency: median days to remediate known exploited vulnerabilities on internet-facing systems.
• Endpoint control coverage: percentage of Windows devices with the ransomware ASR rule and controlled folder access in block mode, and with EDR healthy.
• Protected backup coverage: percentage of critical systems with at least one offline or immutable copy.
• Restore test success: number of full restores tested per quarter and the measured recovery time versus target.
• Privileged exposure: count of standing domain administrator and backup administrator accounts.

Where identity fits

Ransomware is an identity problem at both ends of the chain. Initial access is often a valid login, and mass deployment uses legitimate administrative rights. NIST IR 8374 Rev. 1 highlights PR.AA-01 (credentials managed), PR.AA-03 (users, services and hardware authenticated) and PR.AA-05 (access permissions managed and reviewed) for that reason.

• Hybrid identity: in the Storm-0501 attacks, stolen Entra Connect Sync credentials carried ransomware operators from on-premises into the cloud. Treat directory synchronisation accounts as tier 0. See the Service Account Security Guide.
• Administrators: separate administrator accounts from everyday accounts, keep administrators off email and the web, and use just-in-time elevation for domain and backup administration. See the Privileged Access Management Guide.
• Cloud and backup keys: long-lived access keys with write or delete rights on storage and backups are ransomware tools in their own right. Scope them, vault them and alert on use from unusual locations.

Common failure patterns

• Forgotten remote access accounts: legacy VPN or Citrix accounts outside MFA policy, as in the Colonial Pipeline and Change Healthcare incidents.
• Backups on the same domain: backup servers joined to the production domain, administered with domain admin credentials, so the attacker deletes them with the same account used to deploy ransomware.
• Restores never tested at scale: backup jobs report success, but nobody has rebuilt Active Directory or a core application from them, and recovery takes weeks.
• Hypervisors left out: endpoint controls cover Windows, while ESXi hosts sit domain-joined, SSH-enabled and unmonitored.
• Controls left in audit mode: ASR rules and controlled folder access deployed in audit during a pilot and never moved to block.
• Cloud storage without versioning: buckets written to by long-lived keys with no versioning or deletion protection, the pattern exploited in the Codefinger campaign.

Framework mapping

CIS Safeguard 11.4, "Establish and Maintain an Isolated Instance of Recovery Data", is the closest single control to the offline backup requirement in the CISA and NCSC guidance.

Practitioner checklist

• Remove internet-exposed RDP and require phishing-resistant MFA on every remote access path, including legacy VPN and Citrix accounts.
• Patch known exploited vulnerabilities on edge devices within days, not patch cycles.
• Deploy EDR on every server and endpoint, with tamper protection managed centrally.
• Move the ransomware, Safe Mode, PsExec/WMI and vulnerable driver ASR rules and controlled folder access from audit to block.
• Deploy LAPS, block network sign-in by local accounts, require SMB signing and block workstation-to-workstation SMB, RDP and WinRM.
• Alert and isolate on shadow copy deletion, backup catalogue deletion and recovery configuration changes.
• Place canary files on file shares and connect their alerts to automated isolation.
• Harden ESXi: patch, lockdown mode, SSH off, logs to the SIEM, review AD group-based admin access.
• Keep at least one offline or immutable backup copy with separate credentials, and test full restores every quarter.
• Exercise the ransomware response plan at least annually, including decision makers and legal obligations.

Standards and references

• CISA: #StopRansomware Guide
• NIST: IR 8374 Rev. 1, Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile
• NCSC: Mitigating malware and ransomware attacks
• NCSC: Offline backups in an online world
• MITRE ATT&CK: Inhibit System Recovery (T1490)
• MITRE ATT&CK: Data Encrypted for Impact (T1486)
• Microsoft Learn: Protect important folders with controlled folder access
• Microsoft Threat Intelligence: Ransomware operators exploit ESXi hypervisor vulnerability for mass encryption

Related NHI Mgmt Group resources: Privileged Access Management Guide · Remote Access Identity Guide · Active Directory and Entra ID Hardening Guide · MFA Guide