Ransomware Prevention Guide: Controls, Backups and Recovery

Preventing ransomware comes down to four things: close the common entry points (exposed remote access, unpatched edge devices, phishable credentials), limit how far one compromised account can reach, detect the attackers during the days or weeks they spend preparing, and keep immutable backups that you have actually restored. Encryption is the last step of an intrusion, not the first. The organizations that recover in days instead of months are the ones whose backups survived and whose restore process had been rehearsed.

Key takeaways

• Ransomware is an intrusion first and malware second. Attackers usually spend time gaining admin rights, finding backups and copying data before they encrypt anything.
• The common entry points are known: remote access without strong MFA, unpatched internet-facing devices, and phishing. Close those before anything clever.
• Standing admin rights turn one compromised account into a company-wide outage. Remove them, tier them, and monitor every use.
• Backups must be immutable, isolated from the production identity system, and restored on a schedule. An untested backup is a hope, not a control.
• Modern groups steal data before encrypting it. Backups solve encryption; they do nothing for extortion over leaked data.
• Decide the hard questions (who can isolate systems, whether you would ever pay, who calls law enforcement) before an incident, in writing.

How a ransomware intrusion unfolds

Understanding the sequence tells you where to put controls. In broad strokes, a human-operated ransomware intrusion moves through these stages:

The gap between initial access and encryption is the defender's opportunity. Every stage leaves traces: new admin logons, unusual remote management software, backup jobs being deleted, large transfers out. Detection is about seeing those traces before the last row.

Layer 1: close the common entry points

Remote access

Remote access with weak authentication is the most reliable way in. Concretely:

• No RDP or SSH exposed directly to the internet. Put administrative access behind a VPN with strong MFA or a zero-trust access proxy that checks identity and device before connecting anyone.
• Phishing-resistant MFA on VPN, email, SSO and cloud consoles. Code and push MFA are far better than passwords alone, but FIDO2 keys and passkeys resist the proxy phishing kits that capture codes in real time.
• Disable legacy authentication protocols that cannot do MFA. One forgotten legacy endpoint undoes the rest.
• Inventory approved remote management tools and alert on anything else being installed. Legitimate remote support software is a favorite way to keep access because it looks normal.

Internet-facing devices

VPN concentrators, firewalls, file transfer appliances and email servers sit on the internet, run privileged code and are often patched last. They have been the entry point in many major ransomware campaigns.

• Keep an inventory of everything internet-facing, including appliances that "the network team" owns.
• Patch internet-facing systems first, and prioritize vulnerabilities in CISA's Known Exploited Vulnerabilities catalog over raw CVSS scores. KEV means someone is exploiting it now.
• When a critical advisory lands for an edge device and the patch is not out, apply the vendor's mitigation or take the feature offline. Then check whether you were compromised before you patched; patching does not remove a backdoor already installed.
• Subscribe to vendor advisories for every edge product you run. Do not wait for your scanner to learn about it.

Email and phishing

Phishing still delivers credentials and malware. The full set of controls is in our phishing defense guide; the ransomware-relevant ones are attachment and link filtering, blocking macros from internet-sourced documents (now the default in current Microsoft Office), and fast reporting so one user's click does not become ten.

Layer 2: limit the blast radius

Assume an attacker gets a foothold. The next question is how far one account and one host can reach.

Privileged access

• No local admin rights on user workstations. Where admin access is needed, grant it just in time.
• Unique local administrator passwords on every machine, managed by Windows LAPS (built into supported Windows versions) or an equivalent. A shared local admin password lets an attacker move from one machine to all of them.
• Tiered administration. Domain controllers and identity systems (tier 0) are administered only from dedicated admin workstations by dedicated accounts that never log on to ordinary servers or laptops. Credentials left in memory on a compromised workstation are how domain admin gets stolen.
• Separate admin identities. Day-to-day work happens in an account with no admin rights. Admin accounts have no email and no web browsing.
• Protect cloud admin the same way: no standing owner or administrator roles, just-in-time elevation, and alerts on every privileged role activation.

Active Directory hygiene

Active Directory remains central to most on-premises ransomware incidents because domain admin rights reach every joined machine.

• Audit membership of Domain Admins, Enterprise Admins, Administrators and other privileged groups, and alert on changes.
• Add privileged accounts to the Protected Users group, and enable Credential Guard where supported.
• Disable LLMNR and NetBIOS name service, and reduce NTLM use where you can.
• Remove old service accounts and rotate the passwords of the ones you keep; prefer group managed service accounts.

Segmentation

Flat networks let one compromised laptop reach every server. At minimum, separate user devices, servers, management interfaces and backup infrastructure, and deny by default between them. Workstations rarely need to talk to each other at all; blocking workstation-to-workstation SMB and RDP removes a common path for spreading. Hypervisor and storage management interfaces belong on their own network, reachable only from admin workstations.

Layer 3: detect the preparation

EDR on every endpoint and server is the baseline, with tamper protection on and someone watching the alerts around the clock, whether that is your team, a managed detection provider or both. An EDR alert at 2 a.m. on a Saturday that nobody reads until Monday is a log entry, not a defense.

The signals worth alerting on, because they show up before encryption:

Centralize these events so they can be correlated; our SIEM and SOC guide covers collection and detection engineering. Where your EDR supports it, allow automatic isolation of a host on high-confidence ransomware behavior. A few minutes of human delay can be the difference between one encrypted machine and hundreds.

Layer 4: backups that survive the attack

Backups are what turn ransomware from an existential event into a bad week. Attackers know this, so they hunt for backups first.

The rules

A useful rule of thumb is 3-2-1-1-0: three copies of your data, on two different types of storage, one off-site, one offline or immutable, and zero errors in automated restore verification. The last two are the ones that matter against ransomware.

Beyond the rule:

• Separate identity. Backup consoles and storage must not be administered by accounts from the production directory. If domain admin can delete backups, an attacker with domain admin will.
• MFA on backup consoles, with hardware keys for the people who can change retention.
• Immutability that even an administrator cannot override before the retention period ends.
• Isolation. Backup infrastructure on its own network segment, or in a separate cloud account with no trust from production.

Immutable backups in AWS

For AWS, put backups in a dedicated account, then lock them. With AWS Backup, a vault lock in compliance mode cannot be removed once its grace period has passed:

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name prod-immutable \
  --min-retention-days 14 \
  --max-retention-days 120 \
  --changeable-for-days 3

For object storage, S3 Object Lock in compliance mode does the same at the object level:

aws s3api create-bucket --bucket acme-backups-immutable --object-lock-enabled-for-bucket
aws s3api put-object-lock-configuration --bucket acme-backups-immutable \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Compliance mode means exactly what it says: nobody, including the account root user, can shorten retention or delete locked versions early. Size the retention deliberately, because you will pay for storage for its full length.

If you do not use customer-provided encryption keys for S3, deny them. Attackers with stolen credentials have encrypted S3 objects using keys only they hold. This statement works as written in an SCP; to use it in a bucket policy, add a Principal:

{
  "Sid": "DenySSECUploads",
  "Effect": "Deny",
  "Action": "s3:PutObject",
  "Resource": "*",
  "Condition": { "Null": { "s3:x-amz-server-side-encryption-customer-algorithm": "false" } }
}

Azure (immutable blob storage, soft delete and vault immutability in Azure Backup) and Google Cloud (bucket retention locks, Backup and DR vaults) have equivalent controls. Our cloud disaster recovery guide covers recovery objectives and multi-region design.

Restore like you mean it

The restore is the control, not the backup. Test it:

• Automate restore verification for every critical dataset: restore to an isolated environment, start the service, run a check that real data is there.
• Rehearse a full recovery of the minimum set of systems the business needs to operate, at least once a year, and time it. That number is your real recovery time, whatever the policy says.
• Recover identity first. If the directory or identity provider is gone, nothing else can be restored with the right permissions. Have a documented, tested path to rebuild or restore it.
• Keep recovery documentation offline. A runbook on an encrypted file share is not available when you need it.
• Plan for reinfection. Restoring a backup taken after the attacker got in restores the attacker too. Know how far back your clean point is, and scan restored systems before reconnecting them.

Before the incident: decisions to make now

Write these down while nobody is under pressure, and put them in your incident response playbook:

• Who can isolate systems or take the network offline, without waiting for a meeting.
• Who you call: an incident response firm on retainer, your cyber insurer (many policies require using their panel), legal counsel, and law enforcement.
• Your position on payment, decided in principle with leadership and counsel. Payment does not guarantee a working decryptor or deletion of stolen data, and paying sanctioned groups can be illegal; in the US, OFAC has issued guidance on exactly this.
• Notification obligations, which may start the moment you become aware of a breach. In India, CERT-In expects specified incidents to be reported within 6 hours of being noticed; GDPR gives 72 hours for notifying the supervisory authority.
• Out-of-band communication, because email and chat may be down or compromised.

A prioritized plan

If you are starting from a typical mid-sized environment, an order that gets the most risk down first:

First: MFA on all remote access, email and admin consoles. No RDP exposed to the internet. EDR on every endpoint and server with alerts monitored. Confirm at least one backup copy is immutable and restore one critical system end to end.

Next: Patch program for internet-facing systems keyed to KEV. Remove local admin rights; deploy LAPS. Separate backup administration from the production directory. Segment backups and management interfaces.

Then: Tiered administration and privileged access management. Phishing-resistant MFA for admins and finance. Alerting on the preparation signals above. A ransomware tabletop using your actual recovery runbooks.

Ongoing: Automated restore verification, periodic full recovery rehearsals, privileged group reviews, and updating the plan after every exercise.

What goes wrong in production

• Backups in the same blast radius. The backup server is joined to the same domain, its storage is mounted from the same network, and the attacker deletes both before encrypting. Separate identity and immutability are not optional.
• Snapshots mistaken for backups. VM or volume snapshots in the same account and region are deleted with the same credentials that can delete the volumes. Copy to a separate, locked account.
• The restore takes far longer than anyone assumed. Bandwidth, dependency order and rebuilding identity are the usual surprises. Only a timed rehearsal tells you the real number.
• EDR coverage gaps. Servers left out "for performance", Linux hosts and hypervisors without agents, a subsidiary on a different tool. Attackers find the unmonitored hosts.
• Alerts nobody sees at the weekend. Intrusions are often timed for nights, weekends and holidays. If your monitoring is business hours only, plan for a managed service or an on-call rota.
• Patching the edge device, keeping the backdoor. A patch applied after exploitation leaves whatever the attacker installed. When a critical edge vulnerability is exploited in the wild, check for compromise as well as patching.
• Compliance mode retention set by accident. A test with compliance-mode Object Lock and long retention creates storage nobody can delete until it expires. Test immutability with governance mode or short retention first.

Frequently Asked Questions

What is the best way to prevent ransomware?

There is no single control, but four do most of the work: phishing-resistant MFA on remote access and email, fast patching of internet-facing systems prioritized by known exploitation, removal of standing admin rights so one compromised account cannot reach everything, and immutable backups that you restore regularly. EDR on every endpoint and server, monitored around the clock, catches what gets through. Backups are what decide whether an attack is an outage or a catastrophe.

How do ransomware attacks usually start?

Most start with stolen or guessed credentials for remote access, exploitation of a known vulnerability in an internet-facing device such as a VPN or firewall, or a phishing message. The encryption comes days or weeks later, after the attackers have gained admin rights, found the backups and often copied data out. That gap is the defender's best chance to detect and stop them.

Are backups enough to recover from ransomware?

Only if the attackers cannot delete or encrypt them, and only if you have tested restoring them at the speed the business needs. Backups do nothing about stolen data, which modern ransomware groups use for a second round of extortion. Treat backups as the recovery control and keep separate controls for preventing data theft.

What is an immutable backup?

An immutable backup is a copy that cannot be changed or deleted until a retention period ends, even by an administrator account. Examples include S3 Object Lock in compliance mode, AWS Backup Vault Lock, immutable blob storage in Azure and hardened backup appliances. Immutability protects against attackers who gain admin rights and try to destroy backups before encrypting production.

Should you pay a ransomware demand?

Paying is a business and legal decision to make with counsel, ideally decided in principle before an incident. Payment does not guarantee working decryption or deletion of stolen data, and paying certain groups can breach sanctions rules, such as those enforced by the US Treasury's OFAC. Organizations with tested, immutable backups rarely face the question in its hardest form.

Can ransomware affect cloud environments?

Yes. Attackers with stolen cloud credentials can delete snapshots and backups, encrypt storage objects with keys they control, or encrypt virtual machines and file shares directly. The defenses are the same in principle: least-privilege identities, MFA, logging, guardrails that block destructive actions, and backups in a separate account with immutability enabled.

Need help with ransomware readiness?

We build and operate infrastructure, so we approach ransomware from the recovery end: backups that cannot be deleted, restores that have been timed, and the access controls and alerts that stop an intrusion before the last step. Senior engineers do the work, and if we built it, we're on the pager for it.

• Cybersecurity and compliance
• Cloud architecture and infrastructure
• Talk to an engineer