NTFS permissions and ACLs

Overview

Windows secures objects with ACLs: a DACL of ACEs granting/denying specific rights to SIDs (Deny wins, permissions inherit). The key risk: a low-priv user with Write/Modify on something a privileged process uses.

Why it matters

Weak ACLs are the most common Windows local privilege-escalation root cause — a writable service binary, scheduled-task script, or DLL search path turns a normal user into SYSTEM. accesschk/icacls audits are a standard step.

Core concepts

DACL / ACE. List of allow/deny rights per SID; Deny wins. Inheritance. Rights flow from parent objects unless broken. Dangerous grants. Write/Modify for Users/Everyone on privileged binaries or paths. Tooling. icacls, accesschk.

Lesson

Where Unix has rwx bits, Windows uses richer Access Control Lists (ACLs) on every file, registry key, and service.

ACL structure

A file's security descriptor holds a DACL — a list of Access Control Entries (ACEs). Each ACE says: this SID is Allowed/Denied these rights (Read, Write, Modify, Full Control, etc.). Deny ACEs win over Allow.

Inheritance

Permissions flow down from a folder to its children by inheritance, unless inheritance is broken on a child. This is why a misconfigured top-level folder can expose a whole tree.

Dangerous permissions to spot

• A low-privileged user with Write or Modify on a file that a privileged process runs (service binary, scheduled task, DLL) → privilege escalation.
• Full Control granted to broad groups like Everyone, Authenticated Users, or Users on sensitive paths.
• Writable directories in a privileged process's search path (DLL hijacking, covered in privesc).

Tools

icacls <path> shows the ACL; accesschk (Sysinternals) is the go-to for auditing "what can this user write?" — exactly the question a Windows privesc check asks.

Summary

NTFS/Windows objects carry ACLs of allow/deny ACEs with inheritance. The escalation question is always "can a low-priv user write something a privileged process trusts?" — audited with icacls/accesschk.