> For the complete documentation index, see [llms.txt](https://newdocs.keeper.io/en/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://newdocs.keeper.io/en/keeperpam/endpoint-privilege-manager/policies/policy-examples/anti-ransomware-policies.md). # Anti-Ransomware Policies
## 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
GatePolicy TypePurpose
Gate 1: ExecutionFile 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: EscalationLeast PrivilegeRemove 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-DestructionFile 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 ProtectionFile 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://newdocs.keeper.io/en/keeperpam/endpoint-privilege-manager/policies/policy-examples/anti-ransomware-policies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.