Study guide
8.5 Windows File System, Share & Registry Permissions
CREST Practitioner Security Analyst CPSA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Soft Skills, Legal Framework & Assessment Management
1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards
2 Chapter 2: Core Networking: IP Protocols & Network Architectures
2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies
3 Chapter 3: Cryptography & Secure Communication Protocols
3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH
4 Chapter 4: Background Information Gathering & OSINT Reconnaissance
4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance
5 Chapter 5: Networking Equipment & Infrastructure Protocols
5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet
6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification
6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review
7 Chapter 7: Vulnerability Identification & Tool Output Analysis
7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files
8 Chapter 8: Microsoft Windows Security Assessment & Active Directory
8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications
9 Chapter 9: Unix & Linux Security Assessment & Legacy Services
9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow
10 Chapter 10: Web Architectures, Technologies & Testing Methodologies
10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components
11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities
11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis
12 Chapter 12: Database Security Assessment & SQL Injection
12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening
8.5 Windows File System, Share & Registry Permissions
Key Takeaways Explain This Topic AI
NTFS security descriptors combine an owner SID, a DACL of allow/deny ACEs and a SACL for auditing; deny ACEs are evaluated before allow ACEs.
When a resource is reached over SMB the effective permission is the most restrictive of the share permission and the NTFS permission.
A standard user who holds Write or Modify on a service executable, or FullControl on its containing directory, can replace the binary and escalate to SYSTEM.
Weak ACLs on the HKLM\SYSTEM\CurrentControlSet\Services keys let a low-privileged user rewrite a service's ImagePath and gain SYSTEM.
icacls, accesschk and Get-Acl are the tools that expose these ACLs; effective-access analysis must account for group membership and inheritance.
Last updated: September 2026
8.5 Windows File System, Share & Registry Permissions
Syllabus item B13 pairs Unix and Windows: "File permission attributes within Unix and Windows file systems and their security implications" , plus "Analysing registry ACLs." Section 9.1 handled the Unix side; this section is the Windows half. It is also where a great many real privilege-escalation findings live, because Windows permissioning is intricate enough that misconfigurations are common and easy to miss.
1. The NTFS Security Model
Every securable object on NTFS — file, directory, registry key, service, printer — carries a security descriptor containing:
an Owner SID (the owner can always change the object's permissions, regardless of the DACL);
a DACL (Discretionary Access Control List), an ordered list of ACEs (Access Control Entries) that grant or deny rights to specific security principals (SIDs);
a SACL (System Access Control List) that specifies which access attempts are audited;
a group SID (largely vestigial, present for POSIX compatibility).
ACE Evaluation Order
This is precise and examinable:
An explicit Deny ACE always wins.
Otherwise the system accumulates matching Allow ACEs until the requested access is fully granted.
Explicit ACEs take precedence over inherited ACEs; within each class, deny precedes allow.
If, after processing the whole DACL, the requested access is not fully granted, access is denied.
A null DACL (no DACL at all) grants everyone full control — very different from an empty DACL (a DACL with zero ACEs), which denies everyone.
Standard and Special Permissions
The friendly permissions in the GUI are masks over 14 special rights:
- Standard permission Notable special rights it includes
- Read ReadData, ReadAttributes, ReadEA, ReadPermissions
- Read & Execute Read + ExecuteFile / Traverse
- Write WriteData, AppendData, WriteAttributes, WriteEA
- Modify Read & Execute + Write + Delete
- Full Control Everything, including WriteDAC (change permissions) and WriteOwner (take ownership)
WriteDAC and WriteOwner are the dangerous ones: a principal holding either can grant itself any other right, so they are effectively equivalent to Full Control from an attacker's point of view.
2. Share Permissions vs NTFS Permissions
When a file is accessed locally , only the NTFS DACL applies. When it is accessed over SMB , two independent checks apply and the more restrictive wins : Share permission NTFS permission Effective over the network
- ---------------------------------------------------------------
- Everyone: Full Users: Read Read (NTFS is tighter)
- Everyone: Read Users: Full Read (share is tighter)
- Authenticated:Change Users: Modify Modify/Change
The classic misconfiguration is Share = Everyone: Full Control , left as a default with the reasoning that "NTFS will protect it". That works only until the NTFS side is also loose, and it means the share permission provides no defence in depth. Legacy Everyone: Full Control shares combined with permissive NTFS ACLs are how an unauthenticated or low-privileged user reads payroll data or drops a malicious file into a scripts directory.
- Enumerate shares and their permissions with: Get-SmbShare | Get-SmbShareAccess
- net share # From an attacker host
- smbclient -L //10.20.30.52 -N
- crackmapexec smb 10.20.30.0/24 -u user -p pass --shares
Writable shares are a first-class finding: they enable malware staging, DLL planting, and tampering with scripts that run with higher privilege.
3. NTFS Permissions as a Privilege-Escalation Vector
Two patterns recur:
Weak permissions on a service executable. If a service runs as LocalSystem but a standard user has Modify or Write on its .exe , the user replaces the binary with a payload and restarts the service (or waits for a reboot) to run code as SYSTEM. # Find the binary path, then check who can write it
- Get-CimInstance Win32_Service | Select Name,PathName,StartName
- icacls "C:\Program Files\VulnApp\service.exe"
- # BUILTIN\Users:(M) <-- Modify for all users: escalation
- accesschk.exe -quvw "C:\Program Files\VulnApp\service.exe"
Weak permissions on the containing directory. Even if the .exe itself is protected, Write / FullControl on its directory lets an attacker rename the original and drop a replacement, or exploit an unquoted service path (covered in 8.4) by planting C:\Program.exe . WriteDAC anywhere in the chain lets the attacker simply grant themselves the missing rights.
- Enumerate the whole class quickly: accesschk.exe -uwcqv "Authenticated Users" * # writable services
- accesschk.exe -uwdqs Users c:\ # writable dirs for Users
- accesschk.exe -uwdqs "Authenticated Users" c:\
- 4. Analysing Registry ACLs
The registry is a securable-object tree exactly like the file system, and its keys carry DACLs with the same ACE model. Registry-based escalation is a staple of Windows privilege escalation and is named explicitly in the syllabus.
The Service Keys
Each service is defined under HKLM\SYSTEM\CurrentControlSet\Services\<name> , and its ImagePath value is the command line Windows runs as the service account. If a low-privileged principal can write to a service's key, they can point ImagePath at their own payload: reg query "HKLM\SYSTEM\CurrentControlSet\Services\VulnSvc"
- # check the key ACL
- Get-Acl "HKLM:\SYSTEM\CurrentControlSet\Services\VulnSvc" | Format-List
- accesschk.exe -kvuqsw hklm\System\CurrentControlSet\Services
# if writable:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\VulnSvc" /v ImagePath /t REG_EXPAND_SZ /d "C:\temp\payload.exe" /f
Autostart and Elevation Keys
Run / RunOnce under HKLM\...\CurrentVersion\Run — writable HKLM Run keys give code execution in the context of the next user to log on, including administrators.
AlwaysInstallElevated — if both HKLM and HKCU copies of SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated are 1 , any user can install a crafted MSI as SYSTEM (covered in 8.4; the point here is that it is a registry ACL / value finding).
HKLM\SAM and HKLM\SECURITY — normally readable only by SYSTEM. If their ACLs are loosened, or the hive files are readable on disk or in a backup, offline credential extraction follows (see 8.3).
- Reading and Reasoning About Registry ACLs # Effective rights on a key, expanded
- (Get-Acl "HKLM:\SYSTEM\CurrentControlSet\Services\VulnSvc").Access |
- Format-Table IdentityReference,RegistryRights,AccessControlType,IsInherited
When you read any ACL — file, share or registry — reason about effective access , not just the literal ACEs: expand group memberships (a user in BUILTIN\Users inherits everything granted to Users), account for inheritance from parent keys, and remember that WriteDAC / WriteOwner are silently equivalent to full control. accesschk -uwqs "Users" and PowerShell's Get-Acl are the everyday tools; automated privilege-escalation enumerators (WinPEAS, PowerUp's Invoke-AllChecks ) apply exactly these checks at scale.
5. Reporting Permission Findings
A good permission finding names the object, the principal, the excessive right, and the concrete escalation it enables — for example: " BUILTIN\Users holds Modify (M) on C:\Program Files\VulnApp\service.exe , which runs as LocalSystem; any interactive user can replace the binary and obtain SYSTEM at the next service start." The remediation is equally concrete: remove the excessive ACE, apply least privilege ( Users should have Read & Execute at most on program directories), enable inheritance from a correctly-permissioned parent, and audit changes to service keys via a SACL. Vague advice to "tighten permissions" is not actionable; the specific ACE and the specific escalation are what let the client fix it.