Privilege Escalation: Linux and Windows

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Getting in is rarely getting control. A foothold almost always lands you as a low-privileged user — able to do little. Privilege escalation is the climb from that limited access to full administrative power: root on Linux, Administrator/SYSTEM on Windows. It is where a minor breach becomes a major one — and, told from the other side, it is the single best argument for the principle of least privilege.

Part 1: The Problem

Pages 3.2 and 3.3 ended the same way: you have a foothold — access on a machine — but as a low-privileged user. A limited account can’t read other users’ files, can’t change system configuration, can’t access the most sensitive data, can’t fully control the machine.

The attacker’s goal is administrative privilege: root on Linux, Administrator or the even-higher SYSTEM on Windows. With it, the machine is wholly theirs — all files, all configuration, all credentials stored on it, the ability to use it as a launch point for the rest of the network (3.5).

The climb from low-privileged user to administrator is privilege escalation (often “privesc”). It is one of the most important offensive skills — and understanding it is what makes the defensive principle of least privilege (which you’ve met since page 0.2) finally click into full focus.

Part 2: The Concept — Two Directions of Escalation

Recall the two escalation directions from 2.7, now at the operating-system level:

   VERTICAL escalation          HORIZONTAL movement
   low-priv user → ADMIN/ROOT   user A → user B
   (gaining HIGHER privilege)   (same level, different account)
   ── the main focus here ──    (a stepping stone toward vertical,
                                 or toward another user's data)

This page is mostly about vertical escalation — climbing to administrative control — because that’s the dramatic, impactful step. Horizontal movement (becoming a different same-level user) often appears along the way as a stepping stone.

The foundational concept underneath all of it is the privilege model you’ve known since the start: Linux’s users and root (0.2), and Windows’ equivalent of standard users versus Administrator/SYSTEM. Privilege escalation is, fundamentally, finding a flaw or misconfiguration in how that privilege model is enforced — a way to get the system to run something as a more powerful user than it should.

Part 3: The Concept — Enumeration Is (Almost) Everything

Here is the single most important truth about privilege escalation, and where beginners go most wrong:

Privilege escalation is overwhelmingly an enumeration problem, not an exploit problem.

You don’t usually escalate by firing a clever exploit. You escalate by thoroughly examining the machine you’re on and finding the misconfiguration, the mistake, the overlooked weakness that hands you higher privilege. The escalation path is almost always already there — the work is finding it.

So the core skill is post-exploitation enumeration: systematically gathering information about the compromised machine. What’s running? As whom? What’s misconfigured? What’s stored here? What’s readable that shouldn’t be?

This is why automated enumeration scripts exist and are widely used: they rapidly collect the vast amount of system information a privilege-escalation check needs and flag likely paths. They’re a standard part of the toolkit. But — exactly as with Metasploit in 3.3 — a script that flags a path doesn’t explain it. You must understand why something is an escalation path, or you can’t use it, can’t adapt it, and can’t recognize one the script missed.

Part 4: Common Escalation Paths — The Categories

Privilege-escalation paths are misconfigurations and weaknesses in well-known categories. The categories matter far more than memorized specifics — learn to think in them and you can examine any system. These apply, in their own forms, to both Linux and Windows.

Misconfigured permissions. Files, scripts, or programs with permissions set too loosely (recall the rwx model from 0.2). The classic: a file writable by your low-privileged user that gets executed by a privileged user or process. You change the file’s contents; the privileged process runs your version. The 0.2 lab — where you broke and fixed permissions — was a direct preview of this.

Programs that run with elevated privilege. Mechanisms exist (legitimately) for certain programs to run with higher privilege than the user invoking them — sudo configurations and special permission bits on Linux; various service and token mechanisms on Windows. When these are configured too generously, a low-privileged user can abuse a permitted program to execute commands as the powerful user. Misconfigured sudo rights are a textbook Linux escalation path.

Privileged processes and services. Services running as root or SYSTEM that are themselves weak — a service with a vulnerability, or a service whose executable or configuration the low-privileged user can modify — let the user inherit that service’s privilege.

Stored credentials. Passwords, keys, and tokens left lying on the machine — in configuration files, scripts, history files, readable locations. A credential for a more privileged account, found in a file your low-privileged user can read, is an instant escalation. (This connects to 2.9 and to 3.5 — credentials on one machine are gold.)

Scheduled tasks / cron jobs. Tasks that run automatically on a schedule, often with high privilege. If a low-privileged user can modify what such a task executes, they get their code run with that privilege at the next scheduled run.

Kernel and OS vulnerabilities. The operating-system kernel itself can have vulnerabilities; a “kernel exploit” can escalate directly to full privilege. This is the closest privesc gets to “exploitation” rather than enumeration — but it’s risky (kernel exploits can crash the machine) and often a last resort behind the configuration-based paths above.

The unifying pattern: in nearly every case, something a low-privileged user can influence is trusted or executed by a high-privileged context. That single sentence is the lens. When you examine a machine, you’re looking for any place where your limited power touches something powerful.

Part 5: The Escalation Workflow

How privilege escalation actually proceeds, in practice:

   1. FOOTHOLD     — you have low-privileged access (from 3.2 / 3.3)
            │
            ▼
   2. ENUMERATE    — systematically examine the machine:
            │         users, permissions, running services,
            │         scheduled tasks, sudo/privilege config,
            │         stored credentials, OS version, ...
            │         (manually + with enumeration scripts)
            ▼
   3. IDENTIFY     — find a candidate escalation path from the
            │         categories in Part 4
            ▼
   4. UNDERSTAND   — confirm WHY it's a path; understand it before
            │         acting (don't blindly run a flagged result)
            ▼
   5. ESCALATE     — use the path to gain admin/root
            │
            ▼
   6. FULL CONTROL — administrative control of the machine
            │         → enables 3.5 (attacking the wider network)

Step 2 is where the real time and skill go. Step 4 is what separates someone who understands from someone running a script. And note where step 6 leads — full control of one machine is, again, not the end. It’s the platform for 3.5: the credentials, access, and position it provides are what let an attacker move from one machine to an entire network.

⚖️ Privilege escalation, by definition, means gaining access and powers you were not granted. On an authorized engagement this is in scope by agreement; anywhere else it is squarely the “unauthorized access / exceeding authorization” that page 1.0 described as criminal. Your lab and authorized targets only.

Part 6: The Defense — A Preview of Phase 4

The offense/defense mirror — and this page makes the central defensive principle of the whole curriculum land with full weight. Defenses against privilege escalation are built across Phase 4 (hardening 4.4, monitoring 4.6, and the secure-design thinking of 4.3). The shape:

• Least privilege — the master defense. You’ve carried this principle since 0.2; privilege escalation is what it defends against. Every user, every process, every service should have the minimum privilege needed and no more. A service that runs as a normal user instead of root simply cannot be a root-escalation path. Most escalation paths in Part 4 exist because something had more privilege than it needed. Least privilege closes them at the source.
• Correct, tight permissions. Files, scripts, and programs configured with appropriate (not loose) permissions — no privileged process trusting something a low-privileged user can write (the direct fix for the most common path; the 0.2 lab in reverse).
• No stored credentials. Don’t leave passwords, keys, or tokens in files, scripts, or histories on machines. Proper secrets management (a theme from 2.9 and revisited in 4.x).
• Patch the OS and kernel. Keeps kernel-exploit escalation paths closed (the patching lesson from 3.3 and 2.10, applied to the operating system).
• Careful configuration of privilege mechanisms. sudo rights, service accounts, scheduled tasks, and special permissions configured tightly and reviewed — generous configuration is a gift to an attacker.
• System hardening baselines. Both Linux and Windows have established hardening baselines that close many escalation paths by default — central to 4.4.
• Monitoring for escalation activity. Privilege-escalation attempts and post-exploitation enumeration generate signals; detecting them (4.6) catches an attacker mid-climb.
• Defense in depth. Assume a foothold will happen (assume breach, 1.1); design so that a foothold doesn’t automatically become full control, and so that one compromised machine doesn’t doom the network.

🔑 The deep lesson, and the reason every page of this curriculum has quietly repeated “least privilege”: privilege escalation is the attack that least privilege exists to stop. Seeing how readily an over-privileged service or a too-loose permission becomes root access is what turns least privilege from an abstract principle into something you will enforce instinctively, for the rest of your career — whether you end up attacking systems or defending them.

📓 Key Terms

🧪 Hands-On Lab

Your own lab VMs (Phase 0.5) and authorized practice platforms only. Privilege escalation is, by definition, gaining unauthorized power — strictly your own machines or explicitly authorized targets.

Task 1 — Start from a foothold. Use the low-privileged access you obtained on a victim VM in 3.2 or 3.3. Confirm who you are and your privilege level. (If you need a fresh one, re-establish a foothold on a deliberately vulnerable VM.)

Task 2 — Manually enumerate (Linux). On a Linux victim, manually examine the machine: current user and groups, sudo rights available to you, file permissions in sensitive locations, running services and as whom, scheduled tasks, OS and kernel version, readable files that might hold credentials. Take thorough notes — this is the skill.

Task 3 — Use an enumeration script. Run a well-known privilege-escalation enumeration script against the same Linux machine. Compare what it flags to what you found by hand. For each flagged item, make yourself answer: why is this a potential escalation path?

Task 4 — Escalate (Linux). Using a path you identified and understood (Part 4 categories — a misconfigured permission, a generous sudo right, a stored credential, a writable scheduled task), escalate to root on the victim VM. Document the path step by step.

Task 5 — Do it on Windows. Repeat the enumerate → identify → understand → escalate cycle on a Windows-based vulnerable practice target. Note how the categories are the same even though the specifics differ.

Task 6 — Connect to least privilege. For the escalation path you used, write the precise Part 6 defense — and state, specifically, how least privilege or a tight permission would have eliminated it. Add this to your hardening checklist (started in 2.9).

Task 7 — Reflect. In Notion, write a short reflection: how easy was the climb from foothold to root once you found the path? How does that change how you think about least privilege? Keep this — it’s a genuine mindset shift, and it’s the heart of why this page exists.

⚠️ Common Mistakes

• Treating privesc as an exploit problem. It’s overwhelmingly an enumeration problem. The path is usually already on the machine — the skill is thorough examination, not a clever exploit.
• Running enumeration scripts without understanding their output. A flagged “potential path” you don’t understand can’t be used, adapted, or trusted. Always answer why it’s a path.
• Skimping on enumeration. Miss one readable credential file or one loose permission and you miss the escalation. Privesc rewards patience and thoroughness above all.
• Reaching for kernel exploits first. They’re risky (they can crash the machine) and often unnecessary. Check the configuration-based paths first; treat kernel exploits as a later resort.
• Stopping at root on one machine. Full control of one machine is the platform for 3.5, not the finish line.
• Practicing privesc anywhere but your own lab. It is, by definition, gaining unauthorized power — a textbook crime off authorized targets.

✅ Recap & What’s Next

• A foothold is usually low-privileged; privilege escalation is the climb to administrative control (root / Administrator/SYSTEM) — where a minor breach becomes a major one.
• It is overwhelmingly an enumeration problem: thoroughly examine the machine and find the path — misconfigured permissions, over-privileged programs/services, stored credentials, writable scheduled tasks, or (last resort) kernel vulnerabilities.
• The master defense is least privilege (plus tight permissions, no stored credentials, patching, and hardening) — and seeing how easily over-privilege becomes root is what makes that principle instinctive. Built in Phase 4.

Next (3.5): Full control of one machine is a launch point. Page 3.5 enters the environment where most corporate networks actually live — Active Directory — and shows how attackers move from a single compromised machine to an entire domain.