Privilege Escalation on Windows: The Principles — Ethical Hacking: Penetration Testing Methodology

Windows systems organise privileges differently from Linux, so privilege escalation on Windows has its own characteristic categories, even though the underlying goal, moving from a limited account to a more powerful one, is identical. This lesson covers these categories at the same principled level as the previous lesson.

A different model of privileges

You studied the basics of Windows accounts and permissions in the second course of this track: built-in groups, specific named privileges that can be granted to an account beyond simple group membership, and services that frequently run under their own dedicated accounts, often with significant system-level rights. This richer, more granular privilege model gives Windows some additional categories of escalation issues beyond what you saw for Linux.

Common categories on Windows

Weak service configurations: a Windows service that runs with elevated, often system-level privileges, but whose program file, configuration, or associated folder permissions allow a limited account to replace or modify what actually gets executed when the service runs.
Specific elevated privileges mistakenly granted: Windows allows very granular privileges to be assigned to an account independently of broader group membership (for example, a privilege related to a specific system administration function). If such a privilege is granted more broadly than intended, a limited account holding it can sometimes use it to gain full control, even without being a member of any administrative group.
Unquoted or ambiguous file paths: historically, some systems referenced program locations in a way that could be misinterpreted, allowing a file placed by a limited user in an unexpected location to be executed instead of the intended, legitimate one, when a privileged process starts.
Outdated system software: exactly as with Linux, the operating system kernel or core components can themselves contain a known, publicly documented weakness (again, traceable through CVE records as in chapter 3) allowing privilege escalation when unpatched.
Exposed sensitive information: credentials or configuration data stored in scripts, scheduled tasks, or configuration files that a limited account can read, exactly the same underlying idea as on Linux, simply in Windows-specific locations and formats.

Why naming the category matters, again

As with Linux, the value of a structured category is that it translates directly into a specific, actionable recommendation for the client's defenders. "A service was found with a weak, limited-user-writable configuration" leads naturally to "review and restrict service file and folder permissions following least privilege", which is a concrete, implementable fix, far more useful than a vague instruction to "improve security".

A systematic review approach

Just as with Linux, a disciplined tester works through the categories methodically on a legitimate training machine: which services are installed and what runs them, what permissions apply to their files and folders, which specific elevated privileges the current limited account actually holds (which can sometimes be checked directly through the operating system's own built-in tools), what patch level the system is at, and whether any readable configuration or script reveals sensitive credentials. Many legitimate training platforms provide dedicated Windows privilege escalation machines with official walkthroughs built exactly for learning this systematic process, which remains the right place to learn specific commands and tools.

Legal reminder

Exactly as for Linux in the previous lesson, Windows privilege escalation testing must only be practised on your own authorised lab machines or an explicitly authorised training platform, using that platform's own legitimate material, and never on any system without explicit authorisation covering this specific activity.

A note on defensive tooling and monitoring

Modern Windows environments increasingly include built-in and third-party monitoring specifically designed to detect common privilege escalation patterns, feeding into the kind of detection and alerting themes you met in earlier courses of this track. A professional tester, when permitted by the engagement's rules (recall the "announced versus unannounced" distinction from chapter 1), sometimes deliberately checks whether such monitoring actually catches a successful escalation attempt, which is itself a valuable, separate finding from the escalation technique's success or failure alone.

Your fil rouge: comparing Linux and Windows findings

Using a legitimate training-platform Windows machine built specifically for privilege escalation practice (follow its own official instructions), work through the categories above, and write a short comparison in your journal: which category led to successful escalation on this Windows machine, and how does it compare, conceptually, to the Linux finding from the previous lesson, in terms of what it would mean for a defender's remediation priorities.

Your turn: write the recommendation

During an authorised engagement, you find that a Windows service, running with system-level privileges, has its program folder configured so that any authenticated local user, including low-privilege accounts, can write new files into it, and that the service automatically executes whatever file matches a specific expected name. Write the finding and the recommendation, in two short sentences each, as you would for a professional report.

See a solution

Finding: "A service running with system-level privileges stores its program files in a folder where any authenticated local user, including low-privilege accounts, can create or replace files; because the service automatically executes a file matching a specific expected name in that folder, a limited user could potentially cause their own code to run with the service's elevated privileges." Recommendation: "Restrict write permissions on the service's program folder so that only trusted administrative accounts can modify its contents, following the principle of least privilege, and review other services on the system for the same class of misconfiguration."

Tip

Windows and Linux privilege escalation categories often rhyme with each other (misconfigured permissions, vulnerable privileged software, outdated patches, exposed secrets) even though the specific mechanisms differ. Learning the categories on one system makes the other faster to understand.

Key takeaways

Windows privilege escalation often involves weak service configurations, mistakenly broad specific privileges, path ambiguities, outdated patches, or exposed sensitive information.
Windows' more granular privilege model creates categories specific to it, alongside ones shared conceptually with Linux.
A systematic, category-based review on a legitimate training machine is the right way to learn specific techniques.
Naming the category of a finding translates directly into a concrete, actionable recommendation.
Testing whether monitoring detects an escalation attempt can be its own valuable, separate finding.

The next lesson looks at persistence, but deliberately from the defensive point of view: how to recognise that someone may have established lasting access to a system.