Now that you understand Windows authentication and identity, we turn to authorization — how Windows decides what authenticated users can actually do with files, folders, and other resources. The NTFS (New Technology File System) permission model is the backbone of Windows file security, and misconfigurations here are among the most common findings in penetration tests.
This lesson covers NTFS permissions, Access Control Lists (ACLs), inheritance, and how attackers exploit weak file system permissions for privilege escalation and data exfiltration.
Windows supports multiple file systems, but NTFS is the standard for all modern Windows installations. Unlike FAT32, NTFS supports:
💡 Alternate Data Streams (ADS) are a unique NTFS feature that allows multiple data streams to be associated with a single file. Malware has historically used ADS to hide malicious code. For example, notepad.exe:malware.exe is a separate stream attached to notepad.exe. Use 'dir /r' to detect ADS on a file.
Every securable object in Windows (files, folders, registry keys, processes, services, etc.) has a security descriptor containing two types of Access Control Lists:
| ACL Type | Purpose | Example |
|---|---|---|
| DACL (Discretionary) | Defines who can access the object and how | Allow jsmith Full Control; Deny Guests Read |
| SACL (System) | Defines what access attempts to audit/log | Audit all failed write attempts by Everyone |
Each entry in a DACL is an Access Control Entry (ACE) that specifies a trustee (user or group) and a set of permissions. ACEs are processed in order: explicit deny ACEs come first, then explicit allow ACEs, then inherited deny, then inherited allow.
NTFS provides both basic (standard) and advanced (special) permissions. The standard permissions are combinations of more granular special permissions:
| Permission | What It Allows | Security Risk |
|---|---|---|
| Read | View files, folders, and attributes | Data exfiltration if overly permissive |
| Write | Create files and folders, write data | Malware planting, data tampering |
| Read & Execute | Read + run programs | Running malicious executables |
| List Folder Contents | View folder contents | Reconnaissance of file structure |
| Modify | Read, write, execute, delete | Full data manipulation except ownership change |
| Full Control | All permissions + change permissions + take ownership | Complete compromise of the resource |
# View the ACL of a folder
Get-Acl "C:\SensitiveData" | Format-List
# View ACL with detailed ACE information
Get-Acl "C:\SensitiveData" | Select-Object -ExpandProperty Access |
Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInherited
# Check effective access for the current user
Get-Acl "C:\SensitiveData" | Get-EffectiveAccess
# Find all files where 'Everyone' has write access (common misconfiguration)
Get-ChildItem -Path "C:\" -Recurse -ErrorAction SilentlyContinue |
ForEach-Object {
$acl = Get-Acl $_.FullName
$acl.Access | Where-Object {
$_.IdentityReference -match "Everyone" -and
$_.FileSystemRights -match "Write|FullControl|Modify"
} | Select-Object @{N='Path';E={$_.FullName}}
}⚠️ In the terminal output above, the 'Everyone' group has Write access to C:\CompanyData. This is a critical misconfiguration — any authenticated user (or even anonymous users, depending on the 'Everyone' definition) can write files to this directory. In a penetration test, this would be flagged as a high-severity finding. An attacker could plant malicious executables, scripts, or modify existing files.
NTFS permissions are inherited by default. When you set permissions on a parent folder, those permissions propagate to all child objects (subfolders and files). Inheritance can be disabled, which is sometimes necessary for security but can also lead to inconsistent permission configurations.
Key inheritance concepts:
# Check if inheritance is enabled on a folder
$acl = Get-Acl "C:\SensitiveData"
$acl.AreAccessRulesProtected # $true means inheritance is DISABLED
# Disable inheritance and copy existing ACEs (convert inherited to explicit)
$acl = Get-Acl "C:\SensitiveData"
$acl.SetAccessRuleProtection($true, $true) # $true, $true = disable inheritance, keep existing
Set-Acl "C:\SensitiveData" $acl
# Grant a specific user explicit permissions
$acl = Get-Acl "C:\SensitiveData"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
"DOMAIN\analyst", "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.SetAccessRule($rule)
Set-Acl "C:\SensitiveData" $aclBeyond standard permissions, several NTFS configurations are particularly dangerous from a security perspective:
One of the most common privilege escalation paths on Windows is finding a service running as SYSTEM whose executable or configuration file is writable by a low-privileged user. The attacker replaces the executable, restarts the service, and gains SYSTEM-level code execution. Tools like PowerUp and WinPEAS automate this enumeration.
When accessing files over the network (SMB shares), two layers of permissions apply: Share permissions and NTFS permissions. Windows enforces **the most restrictive combination** of both.
| Share Permission | NTFS Permission | Effective Permission |
|---|---|---|
| Full Control | Read | Read (most restrictive) |
| Read | Full Control | Read (most restrictive) |
| Change | Modify | Change (most restrictive) |
| Full Control | Full Control | Full Control |
# List all SMB shares on the local machine
Get-SmbShare
# View share permissions for a specific share
Get-SmbShareAccess -Name "DataShare"
# Create a new share with specific permissions
New-SmbShare -Name "SecureShare" -Path "C:\SecureData"
-FullAccess "DOMAIN\Admins"
-ChangeAccess "DOMAIN\Users"
-ReadAccess "DOMAIN\Guests"⚠️ The default share permission for a new SMB share is 'Everyone: Full Control'. Many administrators forget to restrict share permissions, relying solely on NTFS permissions. While NTFS permissions will still be enforced, this is a defense-in-depth failure. Always configure both share and NTFS permissions explicitly.
Every NTFS object has an owner. By default, the creator is the owner. The owner always has the ability to modify the object's permissions, even if they are explicitly denied access. This is a fundamental principle of Windows security: ownership trumps permissions.
The 'Take Ownership' privilege (SeTakeOwnershipPrivilege) allows a user to become the owner of any object, after which they can modify the DACL to grant themselves full access. This privilege is granted to the Administrators group by default.
# Take ownership of a file (requires Take Ownership privilege)
takeown /f "C:\ProtectedFile.txt"
# Grant yourself full access after taking ownership
icacls "C:\ProtectedFile.txt" /grant "jsmith:F"
# Alternative: use PowerShell to take ownership
$acl = Get-Acl "C:\ProtectedFile.txt"
$acl.SetOwner([System.Security.Principal.NTAccount]"jsmith")
Set-Acl "C:\ProtectedFile.txt" $aclVerify exercises to earn ★ 130 XP and unlock next lab level.