Privilege Escalation on Linux: The Principles
A first foothold on a system, as you saw in chapter 4, often comes with limited privileges. Privilege escalation is the process of moving from that limited access to a more powerful account, typically an administrative one. This lesson introduces the general categories of weaknesses that allow this on Linux systems, as concepts to understand and to recognise, not as ready-made attacks.
Why initial access is often limited
Services exposed to a network (a web server, a mail server) are usually configured, by good practice, to run with the minimum privileges they need, following the principle of least privilege you met earlier in this track. This means that exploiting a weakness in such a service typically gives a tester, or an attacker, the privileges of that limited service account, not full administrative control over the machine. Privilege escalation asks: from here, can this limited position be used to obtain more?
A framework for categorising Linux privilege escalation
Rather than a long list of specific commands, which quickly become outdated and are better learned through a specific, legitimate training platform's own material, focus on the categories of underlying causes, since recognising the category is what actually helps both as a tester and as a defender:
- Misconfigured permissions: a file, script, or program that a limited account should not be able to modify or execute with elevated rights, but can, due to an overly permissive configuration. For example, a script run automatically by a privileged scheduled task, but which a limited user is mistakenly allowed to edit.
- Excessive granted privileges: a limited account being explicitly allowed, through system configuration, to run one or more specific commands as an administrator, where that configuration is broader or more permissive than actually intended, sometimes allowing an unexpected path to full control.
- Vulnerable privileged software: a program that itself runs with elevated privileges (sometimes by design, to perform a specific administrative task on behalf of ordinary users) but that contains a weakness allowing a limited user to make it do something beyond its intended function.
- Outdated system software: the operating system kernel or core system components themselves containing a known, publicly documented weakness (identified through a CVE, exactly as discussed in chapter 3) that allows a limited user to gain elevated privileges, when a patch has not yet been applied.
- Exposed sensitive information: credentials, configuration files, or cached data accidentally readable by a limited account, which then grant access to a more privileged account through entirely legitimate means, such as a password reused inappropriately in a configuration file.
The tester's general approach
Rather than trying every possible technique, a disciplined approach examines the system systematically, looking at each category above in turn: what can the current limited account read, write, or execute that seems unexpectedly permissive, which scheduled tasks or background processes run with higher privileges, what version of the system and its key components is installed, and whether any accidentally exposed sensitive information is readable. Many legitimate training platforms provide dedicated "privilege escalation" tools and checklists built specifically to help a learner work through this systematically on a deliberately vulnerable practice machine, which is the right place to learn the precise commands.
Why this matters so much in a report
A finding described as "privilege escalation was possible from the initial limited account" is far more significant to a client than the initial foothold alone, because it demonstrates that even a relatively minor initial weakness (perhaps in a low-value, limited service) can cascade into full control of a machine. This is exactly the kind of impact chain that chapter 3's prioritisation factors (especially "business value" and "severity") should capture, and that chapter 7's report must explain clearly.
Legal reminder
Privilege escalation testing must only ever be practised on machines in your own authorised lab or an explicitly authorised training platform built for this purpose, using that platform's own legitimate, educational material. Attempting to escalate privileges on any system without explicit authorisation covering this specific activity is a serious offence, regardless of how the initial access was obtained.
Your fil rouge: a categorised review for Lighthouse Labs
Using a legitimate training-platform machine built specifically to teach Linux privilege escalation (follow that platform's own official instructions and hints), work through the five categories listed above systematically, and write, in your journal, which category ultimately led to successful escalation on that specific machine, what you observed that revealed it, and how you verified your new, elevated access safely, using the same "safe, read-only confirmation" principle from chapter 4.
Your turn: categorise a scenario
A tester, with limited access on a Linux machine, notices that a script executed automatically every few minutes by a scheduled, privileged task is a plain text file that their limited account has permission to edit. Which category from this lesson does this belong to, and what is the underlying lesson for a defender?
See a solution
This is an example of misconfigured permissions: a file that should only be editable by an administrative account is instead writable by a limited one, even though the file itself is executed with elevated privileges by the scheduled task. The underlying lesson for a defender is that permissions on any file or script executed by a privileged process deserve particular scrutiny and should follow the principle of least privilege just as strictly as the process's own account does; a privileged task is only as secure as everything it reads, writes, or executes.
Tip
When you find a privilege escalation path, resist describing it in your notes only as "it worked". Write down specifically which of the five categories it belongs to; this single habit makes your eventual report far more useful to the client's defenders.
Key takeaways
- Initial access is often limited, following the principle of least privilege applied to exposed services.
- Linux privilege escalation generally falls into misconfigured permissions, excessive granted privileges, vulnerable privileged software, outdated system software, or exposed sensitive information.
- A systematic review of each category is more effective than randomly trying techniques.
- A successful escalation finding dramatically changes the real-world severity of the original weakness.
- This kind of testing must only be practised on authorised lab or training-platform machines.
The next lesson covers the same question for Windows systems, which have their own distinct categories of privilege escalation weaknesses.