D3-LFP Local File Permissions: Deploy and Verify

An attacker who lands on a host with a low-privilege account can still read secrets, plant persistence and tamper with logs wherever file and directory permissions are looser than the job requires. MITRE D3FEND names the countermeasure Local File Permissions (D3-LFP) and defines it as "the systematic process of defining, implementing, and managing access control policies that dictate user permissions for accessing files on a local system through the configuration of operating system functionality." It sits under the Isolate tactic as a child of Access Policy Administration (D3-APA), alongside Domain Trust Policy and User Account Permissions. This card covers what D3-LFP restricts, the ATT&CK techniques D3FEND relates to it, how Windows and Linux implement it, how to audit and verify permissions, and where the control stops. It is written for system engineers and detection teams; the Linux mechanics are covered in more depth in the Linux File Permissions, SUID and ACLs Guide.

Key takeaways

It restricts Files and Directories. Those are the two digital artefacts D3FEND attaches to D3-LFP, which is why its inferred ATT&CK footprint is broad: almost every technique that reads, writes, deletes or plants a file touches it.
Write access to execution paths is the main risk. Writable service binaries, startup folders, DLL search paths and shell profiles turn a normal user into a persistence or privilege escalation path.
Read access to secrets is the second. Credential files, private keys, shell history and browser credential stores readable by other accounts give away non-human and human credentials alike.
Changes to permissions are a detection signal. Windows event 4670 and Linux audit rules on attribute changes show who loosened a permission and with which process.
Permissions do not stop the owner or an administrator. D3-LFP limits other principals; malware running as the file's owner, or as root or SYSTEM, is outside its reach, so it pairs with least privilege and mandatory access control.

D3-LFP at a glance

Attribute	Value
D3FEND ID	D3-LFP (d3f:LocalFilePermissions)
Tactic	Isolate
Parent technique	Access Policy Administration (D3-APA)
Siblings	Domain Trust Policy (D3-DTP), User Account Permissions (D3-UAP), User Group Permissions (D3-UGPH)
Digital artefacts	restricts File; restricts Directory
D3FEND reference	Microsoft, File and Folder Permissions (user manual reference)
ATT&CK mitigations D3FEND relates to it	M1022 Restrict File and Directory Permissions; M1018 User Account Management
Main limitation	Does not constrain the file owner, administrators or code running with their rights

How it works on each platform

Platforms are listed alphabetically.

Linux and Unix

Mode bits: read, write and execute for owner, group and other, plus setuid, setgid and sticky bits. New files take their mode from the creating call and the umask.
POSIX ACLs: the acl(5) manual describes entries for the owner (ACL_USER_OBJ), named users (ACL_USER), the owning group (ACL_GROUP_OBJ), named groups (ACL_GROUP), a mask (ACL_MASK) and everyone else (ACL_OTHER). The mask caps what named users, named groups and the owning group can receive, and when a mask exists the group bits shown by ls reflect the mask, not the owning group, which regularly confuses reviews.
Default ACLs: a directory can carry a default ACL that new files and subdirectories take as their access ACL, trimmed to the creation mode. Without one, new objects get permissions from the mode and umask.

Windows

DACLs: Microsoft defines the DACL as the list that "identifies the trustees that are allowed or denied access to a securable object". If an object has no DACL the system grants full access to everyone; if the DACL exists but has no entries, all access is denied. The two cases are easy to mix up in scripts.
Evaluation: the system checks access control entries in sequence until all requested rights are allowed or any requested right is denied. icacls preserves the canonical order: explicit denials, explicit grants, inherited denials, inherited grants.
icacls rights and inheritance: simple rights N, F, M, RX, R, W and D; inheritance flags (OI) object inherit, (CI) container inherit, (IO) inherit only, (NP) do not propagate and (I) inherited. /save and /restore snapshot and reapply DACLs, /reset returns files to inherited ACLs, /verify finds non-canonical ACLs and /setintegritylevel adds a mandatory integrity label.
SACLs: the separate system access control list decides which access attempts are audited, so file auditing depends on SACL entries, not the DACL.

ATT&CK techniques D3FEND relates to D3-LFP

Relationship type: inferred only. D3FEND derives these relations through the File and Directory artefacts and labels them "inferred, experimental" (D3FEND 1.6.0, checked November 2026). The table lists the ATT&CK techniques that act directly on a File or Directory in the D3FEND ontology. Each ID was checked against ATT&CK v20.

ATT&CK ID	Technique	Relation to the artefact	What tighter permissions change
T1005	Data from Local System	accesses File	Low-privilege accounts cannot read data outside their scope
T1083	File and Directory Discovery	accesses File, Directory	Restricted directories cannot be listed by other accounts
T1119	Automated Collection	accesses File	Collection scripts see less
T1552.001	Credentials In Files	accesses File	Secret files readable only by their owning service account
T1074.001	Local Data Staging	may create File	Fewer writable staging locations
T1036.005, T1036.006	Match Legitimate Resource Name or Location, Space after Filename	creates File	System and program directories not writable by users, so masquerading files cannot be dropped there
T1070.004	File Deletion	deletes, may modify File	Logs and evidence not deletable by the accounts an attacker holds
T1072	Software Deployment Tools	adds File	Deployment shares and package caches writable only by the deployment identity
T1220	XSL Script Processing	adds File	Fewer writable locations for script files
T1486	Data Encrypted for Impact	encrypts File	Limits which files a compromised account can encrypt
T1564.006, T1564.012	Run Virtual Instance, File/Path Exclusions	creates File, Directory	Exclusion paths and VM images not writable by standard users
T1565.001	Stored Data Manipulation	modifies File	Write access limited to the owning application
T1566.003	Spearphishing via Service	produces File	Downloaded files land in a location with restricted execute rights

The D3FEND site also lists a much wider set of inferred relations through sub-artefacts of File, including the DLL and path hijacking sub-techniques of T1574, logon and startup scripts (T1037), event-triggered execution such as T1546.013 PowerShell Profile and T1546.004 Unix Shell Configuration Modification, boot or logon autostart such as T1547.001 Registry Run Keys / Startup Folder, T1505.003 Web Shell, T1548.003 Sudo and Sudo Caching, T1003.008 /etc/passwd and /etc/shadow and T1552.003 Shell History. Some entries on that list carry IDs ATT&CK has since revoked; their v20 successors are T1574.001 DLL (for DLL side-loading), T1647 Plist File Modification, T1690 Prevent Command History Logging and T1685.006 Clear Linux or Mac System Logs. The hijacking cases are covered in the T1574 Hijack Execution Flow Defensive Guide.

Where identity fits

Service accounts and workloads keep their credentials in files: key files, kubeconfig files, database connection strings, cloud credential files and token caches. D3-LFP is the control that keeps those readable only by the identity that uses them. A credential file readable by every local user is effectively shared with any process an attacker can start. See the MITRE ATT&CK T1552 Unsecured Credentials Guide.

Implementation steps

Define the protected set. List the paths that matter per platform: credential and key files, service binaries and their directories, startup and profile locations, log directories, deployment shares, and application data stores. Assign an owner identity to each.
Baseline current permissions. On Windows, icacls <path> /save captures DACLs for later comparison and rollback. On Linux, record mode, owner and ACLs (getfacl) for the protected set and search for world-writable files and directories and unexpected setuid binaries.
Fix the high-risk patterns first. Remove write access for standard users on any directory in an execution path (service binary folders, directories on the system PATH, startup folders). Restrict secret files to the owning account (for example mode 0600 on Linux, an explicit DACL with inheritance removed on Windows).
Set safe defaults for new files. Use a restrictive umask or default ACLs on Linux directories that hold sensitive data, and inherited DACLs on Windows parent folders, so new files are correct without manual work.
Turn on change auditing. On Windows, enable Audit File System and add SACL entries for Change Permissions and Take Ownership on protected paths, which is what makes event 4670 appear. On Linux, add audit rules with the attribute (a) and write (w) permissions on protected paths; the auditctl manual recommends syscall rules with -F path= or -F dir= and -F perm=wa over the older -w watch form for performance.
Pilot and roll out. Apply changes to a test ring first and watch for application errors (access denied in application logs). Roll back with icacls /restore or the saved getfacl output if a service breaks.
Enforce through configuration management. Encode permissions in Group Policy file system settings, configuration management or image build so drift is corrected automatically.

How to verify it works

Negative tests: as a standard test user, attempt to read each protected secret file and write to each protected execution path. Every attempt should fail and, where auditing is on, produce an event.
Drift scans: compare current permissions with the saved baseline on a schedule; on Windows, icacls /verify also finds ACLs that are not canonical.
Permission change alerts: follow Microsoft's 4670 guidance: on high-value computers monitor every 4670 event (for example on ntds.dit on domain controllers), and flag changes made by processes outside expected locations.
Integrity monitoring: pair permission checks with content checks. See the File Integrity Monitoring Guide.

Metric	Example target (NHI Mgmt Group suggestion, not a standard)	Why it matters
World-writable files or directories in execution paths	Zero	Removes the most common local persistence and escalation path
Secret and key files readable by accounts other than their owner	Zero	Protects non-human credentials at rest
Protected paths with permission change auditing enabled	100% of the protected set	Makes loosening visible
Permission drift findings corrected within the agreed window	Above 95%	Shows enforcement keeps up with change
Unexplained permission change events per month	Trending to zero	Signals either attacker activity or uncontrolled administration

Limits, bypasses and failure patterns

Privileged code ignores permissions: root, SYSTEM, backup privileges and the file owner can read or change files regardless of other principals' entries. Keep the number of such identities small; see the Least Privilege Techniques Guide.
Mask and inheritance surprises: a POSIX ACL mask silently limits named entries, and a Windows folder with inheritance turned off keeps stale access forever. Review effective permissions, not only the entries.
No DACL versus empty DACL: a script that removes the DACL instead of emptying it grants everyone full access, the opposite of the intent.
Permissions loosened to fix an outage: "grant Everyone full control" during an incident is rarely reverted. Alert on 4670 and on Linux attribute changes and require a ticket reference.
Secrets copied out of protected paths: backups, support bundles and container image layers copy files with default permissions; the protected original does not protect the copy.
Discretionary control only: owners can share their own files. Where that is unacceptable, add mandatory access control; see the Reference Monitors and Mandatory Access Control Guide.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-3 Access Enforcement, AC-6 Least Privilege	Enforcing approved authorisations on files and limiting them to what is needed
NIST SP 800-53 Rev 5	CM-6 Configuration Settings	Permissions as enforced configuration
NIST CSF 2.0	PR.AA-05, PR.DS-01	Access permissions managed and enforced; data at rest protected
MITRE ATT&CK	M1022 Restrict File and Directory Permissions, M1018 User Account Management	Mitigations D3FEND relates to D3-LFP
MITRE D3FEND	D3-APA, D3-LFP	Parent and technique

The mitigation view is in M1022 Restrict File and Directory Permissions; the parent technique in the MITRE D3FEND Access Policy Administration Implementation Guide. The sibling technique for trust between domains is D3-DTP Domain Trust Policy.

Practitioner checklist

Keep a list of protected paths per platform, each with an owning identity.
Baseline permissions with icacls /save or getfacl before changing anything.
Remove standard-user write access from every directory in an execution path.
Restrict credential and key files to the account that uses them.
Set restrictive umask, default ACLs or inherited DACLs so new files start correct.
Enable permission change auditing (SACL plus Audit File System, or Linux audit rules with perm=wa).
Run negative access tests with a standard test account after each change.
Scan for drift on a schedule and correct it through configuration management.
Check backups, support bundles and images for copied secrets with loose permissions.

D3-LFP Local File Permissions: Locking Down Files and Directories and Verifying the Result