Anti-Ransomware Policies

Layered Keeper EPM policies that disrupt the Windows ransomware kill chain

Anti-Ransomware Policies

Audience: Windows administrators deploying a layered Keeper EPM anti-ransomware baseline.

Ransomware on Windows is not a single event — it is a sequence of stages, each of which depends on the one before it succeeding. A loader has to execute. The loader has to escalate. The escalated process has to destroy recovery options. The encryption stage has to write over user data. Stopping ransomware does not require detecting it; it requires preventing any one of those stages from completing.

How Keeper EPM Can Stop Windows Ransomware

Ransomware on Windows must pass three gates to do real damage. Keeper EPM enforces a policy at each:

1. Execution gate — File Access policies on LOTL binaries (powershell.exe, wscript.exe, cmd.exe, certutil.exe, wmic.exe, mshta.exe, regsvr32.exe, rundll32.exe) require Justification, MFA, or Approval before the binary runs. Ransomware loaders cannot satisfy MFA or an approver workflow.
2. Escalation gate — Under Least Privilege, the user is not in the local Administrators group. Any elevation attempt is policy-evaluated; the ransomware process inherits the user's non-admin token and cannot disable Defender, stop backup services, or write to protected paths.
3. Recovery-destruction gate — A File Access policy with DENY controls on the destructive utilities themselves hard-blocks the recovery-removal step regardless of which shell or path invoked them.

Every block emits an audit event to the Admin Console and to the SIEM stream. A burst of denials on a single endpoint is the high-fidelity ransomware detection signal that the SOC keys on.

Keeper EPM enforces a policy at each stage. Each gate stands on its own and disrupts the kill chain at a different point. Deployed together, they create defense in depth: a ransomware variant that evades one gate is stopped by the next.

The Four Gates

Gate	Policy Type	Purpose
Gate 1: Execution	File Access (Justify / MFA / Approval)	Require justification, MFA, or approval before LOTL binaries (powershell.exe, cmd.exe, wmic.exe, etc.) can run. Ransomware loaders cannot satisfy these workflows.
Gate 2: Escalation	Least Privilege	Remove users from the local Administrators group. Ransomware inherits the user's non-admin token and cannot disable Defender, stop backup services, or write to protected paths.
Gate 3: Recovery-Destruction	File Access (DENY)	Hard-block the destructive utilities ransomware uses to delete shadow copies and destroy backups — vssadmin.exe, wbadmin.exe, bcdedit.exe, wevtutil.exe, fsutil.exe, cipher.exe.
Gate 4: Data Protection	File Access (DENY / Approval)	Protect sensitive directories via NTFS ACL modification. Even an encryption process that reaches the file system is denied write access to protected paths.

How the Gates Work Together

A typical ransomware kill chain on Windows follows this sequence. Each gate disrupts a different step:

1. Phishing payload arrives. User opens a malicious document or downloads a dropper. The dropper attempts to invoke powershell.exe or wscript.exe to fetch and run the next stage. → Gate 1 (Execution) prompts for justification or MFA. The malware cannot complete the prompt; the loader never runs.
2. Loader attempts elevation. If the loader does run (for example, an admin user provides justification by mistake), it tries to escalate to disable defenses and stop backup services. → Gate 2 (Escalation) denies the elevation. The malware is stuck in the user's non-admin token.
3. Malware attempts to destroy recovery options. Even without elevation, some ransomware variants try to delete shadow copies directly via vssadmin or to disable Defender via Set-MpPreference. → Gate 3 (Recovery-Destruction) blocks the destructive utilities themselves. Shadow copies, backups, and Defender configuration survive.
4. Malware begins encrypting files. The encryption loop targets user documents, network shares, and any writable path it can find. → Gate 4 (Data Protection) denies write access to protected directories at the NTFS ACL level. Critical data is preserved even if the encryption process is running.

Every prompt, denial, and approval emits an audit event to the Admin Console and to the SIEM stream. A burst of denials or unusual justifications on a single endpoint is the high-fidelity ransomware detection signal that the SOC keys on. Keeper EPM is not a detection product — but its enforcement events are detection-grade telemetry for the products that are.

Deployment Order

Roll out the gates in the order listed. Each gate hardens the environment without depending on the others, and each successive gate is harder to deploy operationally:

1. Gate 3 (Recovery-Destruction) first. The destructive utilities have no legitimate non-administrative use case, so a DENY policy generates near-zero false positives. Start here to establish the highest-impact, lowest-friction baseline.
2. Gate 4 (Data Protection) second. Pick one or two protected directories (finance, source code, executive shares) and pilot. Expand as confidence grows.
3. Gate 1 (Execution) third. This generates user prompts and requires the most tuning. Run in Monitor mode for two weeks to gauge prompt volume before enforcing.
4. Gate 2 (Escalation) last. Removing users from the local Administrators group is the highest-friction change. Use the Phased Rollout Planning guide for pilot, cohort, and broad-deployment phases.

Defense in Depth

No single gate is a complete control. Modern ransomware operators are sophisticated and will adapt. The value of the layered model is that each gate disrupts a different prerequisite of the attack:

• A ransomware variant that runs entirely in userspace (no LOTL, no elevation) is still stopped by Gate 4 at the file write.
• A variant that uses BYOVD (bring-your-own-vulnerable-driver) to escalate is still stopped by Gate 3 when it tries to delete shadow copies.
• A variant that evades all execution and escalation gates is still detected as a burst of denials in the SIEM, giving the SOC a high-fidelity alert.

Each gate is documented in its own page in this section. Implement them in the order above for the smoothest operational rollout.