You’re In. Now Become root.
You landed on a Linux box. But as a nobody.
A standard user. You can’t:
- read other people’s files
- edit system config
- touch
/etc/shadow
Privilege escalation is the climb out of that hole.
From an unprivileged foothold up to root, UID 0, the account that owns the machine completely.
Every technique in this chapter is the same move you met on Windows, just wearing Linux clothes:
Find something that runs with more power than you, but that you are allowed to change.
That “something” takes different shapes:
- a script root runs on a timer that you can overwrite
- a program that runs as its owner instead of as you
- a
sudorule that’s too generous
Same idea, different door.
But here’s the catch: you can’t exploit what you haven’t found.
So this note is pure reconnaissance. Two jobs:
- Understand how Linux hands out power
- Map the machine to spot where that power leaks
Everything Is a File
One idea makes Linux permissions click:
Almost everything is a file.
Documents, directories, devices, even network sockets, all represented in the filesystem. So one permission system governs nearly the whole machine.
And every file answers the same three questions, for three different audiences.
The three questions (what can you do?):
| Permission | Symbol | Means |
|---|---|---|
| Read | r | look at it |
| Write | w | change it |
| Execute | x | run it |
The three audiences (who’s asking?):
- the owner of the file
- the owner’s group
- everyone else (others)
Run ls -l and you see all nine at once (three permissions times three audiences), plus a leading type character:
That -rw-r----- decodes cleanly once you chunk it:
| Chunk | Audience | Meaning |
|---|---|---|
- | file type | just a regular file (ignore it for permissions) |
rw- | owner (root) | read + write, no execute |
r-- | group (shadow) | read only |
--- | others | nothing at all |
So /etc/shadow is readable only by root and the shadow group. That matters, because that file holds every user’s password hash.
One subtlety worth pinning down: x means different things for a file and a directory.
r | w | x | |
|---|---|---|---|
| File | read its contents | change its contents | run it as a program |
| Directory | list what’s inside | create or delete files inside | cd into it, reach known entries |
Write on a directory lets you delete and replace the files in it, even files you don’t own. That distinction quietly powers several escalation tricks later.
Who Am I?
First move after landing a shell: figure out who you are and what you can touch.
This prints your UID (user ID), GID (group ID), and every group you belong to:
uid=1000(joe) gid=1000(joe) groups=1000(joe),24(cdrom),29(audio),...Two numbers matter most:
- root is always UID 0. That’s the summit you’re climbing to.
- Regular users start at UID 1000 and count up. So
1000is the first human account made on the box.
Your groups are not just noise. Membership in a group like
sudo,docker,adm, orlxdcan be an entire escalation path on its own. Always read the full list.
Next, enumerate every user by reading the world-readable account list:
Each line is one account, colon-separated:
joe:x:1000:1000:joe,,,:/home/joe:/bin/bash| Field | Value | Tells you |
|---|---|---|
| login name | joe | the username |
| password | x | the real hash lives in /etc/shadow, not here |
| UID / GID | 1000 / 1000 | a normal human account |
| home | /home/joe | a real home dir = a real person to target |
| shell | /bin/bash | an interactive login (vs /usr/sbin/nologin) |
Two reading habits pay off immediately:
- Accounts with a real home and a real shell (
/bin/bash) are humans worth targeting. Accounts ending in/usr/sbin/nologinare service accounts that can’t log in, sowww-dataandsshdjust tell you a web server and SSH are installed. - That
xin the password field means the actual hash sits in/etc/shadow, readable only by root. If you can ever read that file, you can crack hashes offline, which links straight back to the credential attacks chapter.
Situational Awareness
With the model understood, you sweep the machine. You’re not running commands at random, every one is a lens looking for the same thing: something privileged that you might be able to influence.
The core checklist:
| What | Command | Why you care |
|---|---|---|
| OS / kernel | uname -a, cat /etc/os-release | Kernel exploits are version-exact. A mismatched one crashes the box, so you need the precise version. |
| Processes | ps aux | Anything running as root, especially custom or unusual software, is a target. |
| Network | ip a, ss -anp, routel | Multiple interfaces means this box could be a pivot. A service bound to 127.0.0.1 is reachable only locally, hidden attack surface. |
| Firewall | read /etc/iptables/rules.v4 | Rule files are often left world-readable and reveal what’s blocked, and what’s quietly open locally. |
| Cron jobs | ls -la /etc/cron*, crontab -l | Scheduled scripts running as root with weak permissions are a classic way up (a later note). |
| Installed software | dpkg -l (Debian), rpm -qa (Red Hat) | Version numbers feed a public-exploit search. |
| Writable places | find / -writable -type d 2>/dev/null | The sharpest lens of all: it asks directly what can I change? |
That last
findis worth internalizing.2>/dev/nullthrows away the permission-denied noise so you see only the directories you can actually write to. Privileged and writable is the whole game.
The mindset: you’re running a funnel. A fresh shell sees a machine full of facts, most of them noise. Each command narrows it. What survives, runs with more power than you and can be changed by you, is your escalation shortlist.
Automate It, Then Distrust It
Doing that entire sweep by hand is thorough but slow, and real engagements have deadlines. So there are scripts that run every check for you in one shot:
- LinPEAS, the popular one, color-codes findings by how exploitable they are
- LinEnum, unix-privesc-check, and linux-exploit-suggester cover similar ground
Run one, read the highlights, save hours.
But there’s a catch you must respect, the same one from the Windows side:
Automated tools find the common stuff. They miss the weird one-off misconfiguration, which is exactly the thing that’s often the real way in. A custom setting some admin made at 2am is precisely what a generic scanner has no rule for.
The discipline: automate to triage fast, then verify by hand. Let LinPEAS narrow a thousand files to fifty, but never let it be your only pass.
Where This Leads
You now understand how Linux hands out power, rwx across owner, group, and others, and you’ve mapped the machine: who’s privileged, what’s installed, what’s listening, and where you’re allowed to write.
Often that map alone hands you the win: a password someone left lying around. Hunting down those forgotten secrets, in history files, configs, and service trails, is Hunting Exposed Secrets.