Policy: Living off the Land File Access Justification

Living Off the Land (LOTL) Scenario

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

1

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.

2

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.

3

Policy Type

Select File Access from the Policy Type select list.

4

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.

5

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.

6

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.

7

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.

8

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.

9

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.

10

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.

---

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.