Overview
Windows permission misconfigurations on files, directories, and objects create escalation paths, much as on Linux. This lesson covers Windows permission-based escalation, defensively.
Learning objectives
- Explain Windows permissions in the escalation context.
- Identify permission misconfigurations that enable escalation.
- Connect to Windows permission hardening.
Core concept
Windows controls access via permissions (ACLs) on files, directories, registry keys, and other objects. Escalation-relevant misconfigurations include: files/directories or registry keys writable by low-privilege users that privileged processes rely on, weak permissions on sensitive objects, and accessible locations storing credentials or secrets. As on Linux, the pattern is that an overly permissive ACL weakens a privilege boundary, letting a standard user influence a privileged process or harvest secrets to escalate toward Administrator/SYSTEM.
How it works
If a privileged (SYSTEM/Administrator) process reads or executes a file, or reads a registry value, that a standard user can write, the user can influence the privileged process. If sensitive files or registry locations storing credentials are readable by low-privilege users, those secrets can be harvested to escalate. Windows adds the registry as an object type with ACLs (a difference from Linux). In authorized testing, enumeration checks permissions on files, directories, and registry keys used by privileged processes, and searches for accessible stored credentials. Defensively, correct ACLs (least privilege), protect sensitive files/registry locations, and avoid storing recoverable credentials accessibly.
Practical example
In an authorized Windows lab, the tester finds a registry key used by a privileged process that is writable by the standard user, and a location storing credentials readable by that user. Either enables escalation — the writable key lets the user influence the privileged process; the readable credentials could grant higher access. Both are documented with fixes (correct the registry key's ACL; protect the credential store). The paths came from Windows permission misconfigurations, including the registry, mirroring the Linux permissions pattern.
Cybersecurity relevance
Windows permission misconfigurations (including on the registry) are common escalation causes and prime testing/hardening targets. Defensively: apply least privilege via correct ACLs, ensure files/directories/registry keys used by privileged processes are not writable by low-privilege users, protect sensitive objects and stored secrets, and monitor for ACL changes. This is the Windows counterpart to the Linux permissions lesson, extended to the registry. Understanding these paths lets defenders close them and testers (in authorized labs) identify them.
Common mistakes
- Files/directories/registry keys used by privileged processes writable by low-privilege users.
- Sensitive objects or credential stores readable by low-privilege users.
- Overlooking the registry as an ACL-controlled object type in escalation.
Key takeaways
- Windows permissions (ACLs) apply to files, directories, and registry keys; overly permissive ACLs on objects privileged processes rely on create escalation paths.
- A standard user can leverage writable objects (including registry keys) to influence privileged processes, or harvest accessible credentials to escalate.
- Mitigate with least-privilege ACLs, protected sensitive objects/credential stores, and ACL-change monitoring — the Windows counterpart to Linux permissions, extended to the registry.
Check your understanding
- How can a writable registry key used by a privileged process enable escalation on Windows?
- What is a key Windows-specific object type (beyond files) that ACL misconfigurations can affect?