# Policy: Living off the Land File Access Justification
This example shows a **File Access Policy** designed for a **Living Off the Land (LOTL) scenario**. When enabled, it targets a specifically identified built-in or commonly abused process and requires the user to provide a **justification** before the action is allowed, creating a targeted accountability and audit control point across all endpoints. After this **LOTL Justification Policy** is in place, additional policies can be layered to allow trusted users or automated processes to run the same tool without prompting, or to escalate the control to an Approval or Deny for higher-risk scenarios.
***
### What this Policy Does
When a user on any **in-scope endpoint** tries to launch the targeted LOTL process:
1. The request is evaluated by the **File Access** policy engine.
2. Because the policy targets a specific application identifier, it matches only execution attempts for that particular process on those endpoints.
3. The policy requires the user to provide a **Justification** before the action is permitted to proceed — the action is not blocked, but it is gated behind a mandatory explanation that is recorded.
### Why it Behaves this Way
This policy is intentionally written as a "targeted match" policy that adds accountability friction rather than an outright block:
* **Enforced**: The policy is active and will apply controls (not just log).
* **Justification control on success**: When the policy matches, the user is prompted to enter a written justification before the action can proceed. This justification is recorded in the audit log.
* **All users**: A wildcard user filter makes it apply to any user account on in-scope machines — no one is exempt from the justification requirement by default.
* **Specific application**: A single, defined application identifier targets only the specific LOTL process, so unrelated applications on the same endpoint are unaffected.
* **Acknowledgement required**: The user must actively acknowledge the notification in addition to providing a justification — ensuring the control is both recorded and explicitly communicated.
* **Built-in checks**: Standard checks (user, machine, file, date/time/day, certificate) are present. Because no date/time/day/certificate constraints are applied, the policy is always active for the targeted process on the targeted endpoints.
### What the User Experiences
* When a user attempts to launch the covered LOTL process on an in-scope endpoint, they will be presented with a **justification prompt** — a required text entry explaining their reason for using the tool.
* They must also **acknowledge the notification** before proceeding.
* After the justification is submitted and acknowledged, the action is permitted to continue. This policy is "prompt and record," not "block" — the friction is intentional, but work is not stopped for users with a legitimate need.
* The notification message should clearly explain which tool is being controlled and why a justification is required, so users understand the context rather than experiencing an unexplained interruption.
***
### Important Notes and Common Adjustments
* **Expand the application list** as needed:
* Add additional App IDs to cover other LOTL binaries or variants (e.g., different scripting engines, interpreters, or remote execution utilities) that warrant the same level of justification friction
* Use certificate constraints to scope the control to only unsigned or untrusted builds, avoiding prompts for legitimately signed system components
* **Narrow the user scope** for low-friction exceptions:
* Restrict the user filter to standard users if IT staff or automated service accounts need to run the tool freely without prompting
* Create a separate higher-priority Allow policy scoped to trusted users or specific machine collections
* **Escalate the control if patterns emerge**:
* If audit logs show repeated justifications that appear illegitimate or are unexplained, escalate to **APPROVAL** to require a human approver before the tool can run
* If the tool is determined to have no legitimate use in your environment, escalate to **DENY** to block it entirely
* **Add time/day/date restrictions** if the tool has defined legitimate use windows (e.g., only during maintenance windows or business hours)
* **Keep Risk Level meaningful**: The Risk Level value appears in reporting and dashboards. For a high-risk LOTL binary, consider raising this value (e.g., 75–90) so that justification events surface prominently in security reviews
***
## How Build a Global Allow File Access Policy
{% stepper %}
{% step %}
**Create Policy**
From the **Policies** tab of the Admin Console's Endpoint Privilege Manager page, click the **Create Policy** button.
This will open the **Create Policy Form** in a modal window.
{% endstep %}
{% step %}
**Policy Name**
Enter a descriptive name for your new LOTL Justification File Access Policy. Including the name of the targeted process in the policy name (e.g., `_FileAccess_Justify_WScript`) is recommended to make the policy easily identifiable in the policy list.
{% endstep %}
{% step %}
**Policy Type**
Select **File Access** from the **Policy Type** select list.
{% endstep %}
{% step %}
**Status**
Select the status that you would like your new **LOTL Justification File Access Policy** to be in upon submission of the completed **Create Policy** form. It is strongly recommended to begin in **Monitor** mode to confirm the correct application is being targeted before switching to **Enforce**.
{% endstep %}
{% step %}
**Controls**
Select **Require justification** from the **Add Control** sub-form. This will prompt the user to provide a written business justification each time the targeted process is launched, which is recorded in the audit log.
{% endstep %}
{% step %}
**User Groups**
Click the **Add Group** link in the Create Policy form. This will open the **Add Group** sub-form.
Check the **Select all users** checkbox in the **Add Group** sub-form then click off of the sub-form to close it. **All Users and Groups** will now appear under **User Groups** as applied to your **LOTL Justification File Access Policy.**
If specific users or service accounts should be exempt from the justification prompt (e.g., IT administrators), create a separate higher-priority **Allow** policy scoped to those users rather than excluding them here.
{% endstep %}
{% step %}
**Machine Collections**
Click the **Add Collection** link in the Create Policy form to the right of **Machine Collections**. This will open the **Add Collection** sub-form. Select the **Machine Collection** that you want to apply to your **LOTL Justification File Access Policy.** You may use the filter-as-you-type box to narrow your search for your Machine Collection.
Check the checkbox(s) of the Collection or Collections that you would like applied to your **LOTL Justification File Access Policy.**
The **Machine Collections** that you selected will now appear under **Machine Collections** as applied to your **LOTL Justification File Access Policy.**
{% endstep %}
{% step %}
**Applications**
Click the **Add Applications** link in the Create Policy form. This will open the **Add Applications** sub-form.
Search for and select the **specific LOTL process or processes** you want to target. Do **not** use the **Select all applications** checkbox — this policy is intentionally scoped to the specific high-risk binary or binaries that warrant justification friction. Check the checkbox(s) of each application you want to cover.
The **Applications** that you selected will now appear under **Applications** as applied to your **LOTL Justification File Access Policy.**
{% endstep %}
{% step %}
**Date & Time**
For a **LOTL Justification File Access Policy,** it is recommended that the **Date and Time Ranges** be set to **Always**, ensuring that the justification requirement is continuously enforced with no gaps — including outside business hours, when LOTL abuse is more likely to go unnoticed.
{% endstep %}
{% step %}
**Save Your New Global Allow File Access Policy**
Once the form has been sufficiently filled in per the previous steps, the **Save** button will be changed from an inactive to an active state. Click on the **Save** button. The **Create Policy** modal form will be closed and your **LOTL Justification File Access Policy** will be saved.
{% endstep %}
{% endstepper %}
***
## Use-Case Definitions
This pattern — a **targeted Justification control on a known LOTL binary** — occupies a deliberate middle ground in endpoint privilege management: more control than a passive audit log entry, less disruption than an outright block or approval workflow. Here's a full breakdown of the use-cases and the reasoning behind it.
### The Core Concept: "Accountability Friction for Dual-Use Tools"
**Living Off the Land binaries are legitimate system tools** — scripting engines, command-line interpreters, administrative utilities — that are also routinely abused by attackers precisely because they are native to the operating system and often trusted by security controls. The challenge is that these tools frequently have genuine business uses. A **Justification policy** resolves this tension: it does not block legitimate use, but it eliminates anonymous use. Every execution is now on the record, attributed to a specific user, with a stated reason. This changes the risk calculus for both insider threats and compromised accounts — both of which rely on undetected, unquestioned execution.
### Primary Use-Cases
**1. Auditing Dual-Use Administrative Tools**
Tools like `wscript.exe`, `mshta.exe`, `rundll32.exe`, `certutil.exe`, and `regsvr32.exe` are standard Windows components that also appear in a significant proportion of threat actor tradecraft. A Justification policy applied to these binaries creates a comprehensive audit record of every use, attributing each execution to a specific user with a recorded business reason — without disrupting IT and developer workflows that depend on them.
**2. Behavioral Baselining Before Escalation**
Before deciding whether to **Deny** or require **Approval** for a LOTL binary, organizations need to understand the real-world volume and nature of its use. A Justification policy deployed in Enforce mode provides this data organically: the justification submissions themselves reveal who uses the tool, how often, for what stated purpose, and from which machines. This intelligence directly informs the decision to escalate, relax, or retain the control.
**3. Compliance and Audit Evidence**
Many compliance frameworks (NIST 800-171, CMMC, CIS Controls) require documented evidence that access to high-risk system tools is monitored and attributed. A Justification policy produces a time-stamped, user-attributed audit record for every execution of the targeted binary — satisfying the documentation and accountability requirements of these frameworks without requiring a full approval workflow.
**4. Insider Threat Deterrence**
The act of requiring a written justification is itself a deterrent. Users who might casually or opportunistically misuse a powerful system tool are less likely to do so when they know the action will be logged with their identity and a required explanation. The friction is psychological as much as it is procedural — it signals that the organization is paying attention.
**5. Graduated Response to Threat Intelligence**
When threat intelligence identifies a specific LOTL binary as being actively exploited in campaigns targeting your industry or technology stack, a Justification policy can be deployed immediately as a rapid, low-disruption first response. It creates visibility and accountability at once, while the organization evaluates whether escalation to Approval or Deny is warranted — without the immediate operational risk of blocking a tool that may be in legitimate active use.
**6. Transitional Control During Policy Maturation**
As organizations mature their endpoint privilege management posture, Justification policies serve as a transitional layer. A binary that was previously uncontrolled can move to Justification first, generating data and user awareness, before graduating to Approval (for tools where every use should require a human sign-off) or Deny (for tools with no remaining legitimate use). This phased approach reduces the organizational risk of moving too fast to a hard block.
***
#### Why File Access Policy (Not Privilege Elevation) for these Use-Cases?
This is a nuanced but important distinction. A **File Access policy** intercepts the *execution* of a file (the moment a process is launched), while a Privilege Elevation policy only intercepts attempts to run something with elevated privileges. LOTL binaries are particularly dangerous precisely because they are often invoked at standard user privilege levels — no elevation required. By using a File Access policy here, the Justification control applies to **any launch attempt** regardless of the privilege level the user is operating at, ensuring complete coverage of the targeted process.
#### The Layered Policy Strategy That Follows
Once the LOTL Justification baseline is in place, a controlled exception and escalation model can be layered around it:
| Priority | Policy | Scope |
| --------------- | ------------------------------------------------------------------- | ----------------------------------------------- |
| High | **Allow** — Trusted IT/admin users with established legitimate need | Specific users/groups, targeted LOTL app |
| High | **Allow** — Automated service accounts or CI/CD pipelines | Specific machine collections, targeted LOTL app |
| Medium | **Approval** — Users who require occasional access with oversight | Specific users/groups, targeted LOTL app |
| Low (catch-all) | **Justify** — All other users | All users, targeted LOTL app |
Users matched by a higher-priority Allow policy pass through silently. Users matched by an Approval policy are gated by a human approver. All remaining users are required to provide a justification before proceeding.
***
### Key Operational Consideration
Because this policy uses a **Justification** control with mandatory acknowledgement, every affected user will be interrupted with a prompt each time they launch the targeted process. It is strongly recommended to deploy this policy in **Monitor** mode first to confirm the correct application identifier is targeted and to measure execution frequency, before switching to Enforce — particularly for binaries with high legitimate use volume that could generate significant prompt activity at scale.
