> 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/gate-1-execution.md). # Gate 1: Execution
**Audience:** Windows administrators deploying a layered Keeper EPM anti-ransomware baseline. *** For an overview of the layered anti-ransomware model and how this gate fits in, see [Anti-Ransomware Policies](/en/keeperpam/endpoint-privilege-manager/policies/policy-examples/anti-ransomware-policies.md). This policy is the **execution gate** in a layered Keeper EPM anti-ransomware deployment on Windows. It requires written justification before any user can launch the Living-off-the-Land (LOTL) binaries that ransomware loaders, droppers, and post-exploitation toolkits routinely abuse — `powershell.exe`, `powershell_ise.exe`, `cmd.exe`, `wscript.exe`, `cscript.exe`, `wmic.exe`, `certutil.exe`, `mshta.exe`, `regsvr32.exe`, and `rundll32.exe`. Ransomware loaders cannot satisfy a justification prompt, so the attack stops at the first stage. Legitimate admin use is not blocked — it is recorded, with the user's stated reason captured in the audit log. ### How Keeper EPM Stops Windows Ransomware Ransomware on Windows must pass three gates to do real damage. Keeper EPM enforces a policy at each: 1. **Execution gate** — A File Access policy on LOTL binaries requires Justification, MFA, or Approval before the binary runs. Ransomware loaders cannot satisfy any of those workflows. **This policy.** 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 (`vssadmin.exe`, `wbadmin.exe`, `bcdedit.exe`, etc.) hard-blocks the recovery-removal step regardless of which shell or path invoked them. Every prompt and block emits an audit event to the Admin Console and to the SIEM stream. A burst of justification prompts on a single endpoint with unusual command-line arguments **is** the high-fidelity ransomware detection signal that the SOC keys on. ### Step-by-Step: Create the Policy {% stepper %} {% step %} ### Create the Application Collection Before creating the policy, the LOTL binaries must be organized into an Application Collection. Filename-only resources match the executable regardless of disk location. 1. From the Keeper Admin Console, navigate to **Endpoint Privilege Manager → Collections → Applications**. 2. Click **New Collection**. 3. In the **New Collection** modal: * **Type**: `Applications` * **Name**: `LOTL Binaries (Windows)` * Click **Next**. 4. In the **Add Item to Collection** modal, check **Manually define resource** to add each binary as a custom resource. 5. Add each of the following entries, one at a time, clicking **Add** after each: * `powershell.exe` * `powershell_ise.exe` * `cmd.exe` * `wscript.exe` * `cscript.exe` * `wmic.exe` * `certutil.exe` * `mshta.exe` * `regsvr32.exe` * `rundll32.exe` 6. Save the collection. Note the collection's UID — you will reference it in `ApplicationCheck` when importing the policy JSON, or select it from the picker when creating the policy in the UI. {% hint style="info" %} **Tuning tip:** Some environments rely heavily on `powershell.exe` for legitimate workflows (configuration management, monitoring agents, deployment scripts). If pilot monitoring shows excessive prompts for `powershell.exe`, consider either narrowing the user scope (apply only to standard users, exempt IT service accounts) or splitting it into a separate higher-friction policy with certificate constraints to allow signed Microsoft builds without prompting. {% endhint %} {% endstep %} {% step %} ### Create the Policy 1. Navigate to **Endpoint Privilege Manager → Policies** and click **Create Policy**. 2. Fill in the policy details: * **Policy Name**: `Justify LOTL Binary Execution (Windows)` * **Policy Type**: `File Access` * **Status**: `Monitor` for the initial pilot. Switch to `Enforce` once you have confirmed the prompt volume is operationally acceptable. {% endstep %} {% step %} ### Add the Justification Control 1. Click **Add Control**. 2. Select **Require Justification**. {% hint style="info" %} **Escalation paths:** If audit review shows justifications that look illegitimate or unexplained, edit this policy and add **Require MFA** for higher friction, or replace Justification with **Require Approval** to route execution to a human approver. Controls stack additively — all controls on a policy must be satisfied before the action proceeds. {% endhint %} {% endstep %} {% step %} ### Set Filters 1. **User Groups**: Select **All Users and Groups** (wildcard). If you have a defined service-account or IT-administrator user collection that should be exempt, create a separate higher-priority Allow policy scoped to that collection rather than excluding them here. 2. **Machine Collections**: Select your Windows machine collection, or **Select All** for a baseline rollout. 3. **Applications**: Select the `LOTL Binaries (Windows)` collection created in Step 1. 4. Leave **Date & Time Window** unset — ransomware operates at any hour. {% endstep %} {% step %} ### Set the Notification and Risk Level 1. **Notification Message**: `Keeper EPM requires justification before this tool can run. These utilities are commonly abused by malware. Please enter a brief reason describing your legitimate business need.` 2. **Requires Acknowledge**: check this box. The user must explicitly acknowledge the prompt in addition to providing a justification, which strengthens the audit record. 3. **Risk Level**: `75` — high enough to surface LOTL justification events prominently in security reviews without overwhelming the higher-severity DENY events from the recovery-destruction gate. {% endstep %} {% step %} ### Save and Pilot 1. Click **Save**. The policy is pushed to all in-scope endpoints within approximately 30 minutes; users on affected endpoints can trigger an immediate sync via **Refresh Policies** in the Keeper agent. 2. Run in **Monitor** mode for 7–14 days. Review the audit log in **Endpoint Privilege Manager → Dashboard** to gauge prompt volume and identify any service accounts that need exemption. 3. When prompt volume is operationally acceptable and exemption policies are in place for legitimate automation, edit the policy and change **Status** to `Enforce`. {% endstep %} {% endstepper %} ### Reference: Policy JSON The following JSON is the exported form of the finished policy. The `` and `` placeholders are filled in by the Admin Console when the policy and collection are created. ```json { "PolicyName": "Justify LOTL Binary Execution (Windows)", "PolicyType": "FileAccess", "PolicyId": "", "Status": "enforce", "Actions": { "OnSuccess": { "Controls": [ "JUSTIFY" ] }, "OnFailure": { "Command": "" } }, "NotificationMessage": "Keeper EPM requires justification before this tool can run. These utilities are commonly abused by malware. Please enter a brief reason describing your legitimate business need.", "NotificationRequiresAcknowledge": true, "RiskLevel": 75, "Operator": "And", "Rules": [ { "RuleName": "UserCheck", "ErrorMessage": "This user is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckUser()" }, { "RuleName": "MachineCheck", "ErrorMessage": "This Machine is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckMachine()" }, { "RuleName": "ApplicationCheck", "ErrorMessage": "This application is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckFile(false)" }, { "RuleName": "DateCheck", "ErrorMessage": "Current date is not covered by this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckDate()" }, { "RuleName": "TimeCheck", "ErrorMessage": "Current time is not covered by this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckTime()" }, { "RuleName": "DayCheck", "ErrorMessage": "Today is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckDay()" }, { "RuleName": "CertificateCheck", "ErrorMessage": "Certificate hash is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckCertificate()" } ], "UserCheck": [ "*" ], "MachineCheck": [ "*" ], "ApplicationCheck": [ "" ], "DayCheck": [], "DateCheck": [], "TimeCheck": [], "CertificationCheck": [], "Extension": {} } ``` --- # 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/gate-1-execution.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.