Privilege escalation on Linux

Objective 4.3 in this course covers host-based attacks — CompTIA describes it as conducting privilege escalation, process injection and credential dumping. This lesson takes Linux escalation and is the applied lab for the objective; lesson 28 takes Windows. Runs on a deliberately weak VM you built, in the lab from lesson 2.

Why this matters

Getting onto a host rarely gets you onto it as somebody useful. A web application runs as a restricted service account; a stolen user credential gets you that user. Escalation is what turns a foothold into control, and it is the step that decides whether a finding reads as "an attacker could read the web directory" or "an attacker could take the server".

It is also the most systematic part of Domain 4. Escalation is mostly enumeration — the flaw is usually already present, and the work is noticing it.

The lesson

Enumerating the host you already landed on

Before looking for an exploit, look at where you are. Most escalations come from this step, not from a CVE.

• Who am I, and what groups am I in? Group membership is frequently the whole answer — a group with access to a container runtime, a virtualisation device or a backup tool is often equivalent to root.
• What can I run as someone else? The sudo configuration is the first place to look, and it is covered below.
• What is running, and as whom? Processes owned by privileged accounts, and the files they read and write, are attack surface reachable from your account.
• What is scheduled? Recurring jobs running as root that touch a file or directory you can write are a classic path.
• What is unusual? Custom software, non-standard configuration, and anything the administrator built by hand tend to be where the mistakes are.

Automated enumeration scripts exist and are useful, but read what they check rather than only their conclusions — the same rule as lesson 14. A script's "nothing found" is lesson 19's problem in miniature.

SUID, sudo rules and writable paths

The three most common Linux escalation primitives, and the ones the exam expects:

• SUID and SGID binaries run with the owner's privileges regardless of who starts them. A SUID-root binary that can be made to run arbitrary commands, or read or write arbitrary files, is a direct path to root. The interesting cases are usually not the standard system binaries but something an administrator made SUID to solve a problem.
• Sudo rules that permit running a specific command as root. Many commands that look narrow can be escaped into a shell — an editor, a pager, an interpreter, anything with a shell-out feature. A sudo rule is only as tight as the command it names is escape-proof, and most are not.
• Writable paths in a privileged context. A file a root process reads and trusts, a directory in a privileged binary's library search path, a configuration file with loose permissions — anywhere your write becomes someone else's execution.

The pattern under all three: a privilege you hold is used, unchecked, by something more privileged. Escalation is finding that seam.

Kernel and service exploits, and their risk to uptime

When the configuration is clean, the remaining route is a flaw in the kernel or a privileged service — and this is where lesson 24's caution applies hardest.

• Kernel exploits are the least safe thing you can run. A failed kernel exploit does not fail politely; it frequently panics the machine. On a production server that is an outage you caused, so kernel exploitation belongs in the scope in writing, or in the lab.
• Version is a lead, not a finding. Lesson 18's backported-patch problem is acute in kernels: distributions patch heavily while keeping the version, so a version-based "vulnerable" is frequently wrong.
• Prove it on a replica. Reproduce the target's kernel and distribution in your lab, demonstrate there, and report that you did — rather than firing a kernel exploit at the client's box to see.

Privileged service exploits carry the same shape: a service running as root with a memory-safety flaw is a path, and crashing it is a denial of service you should not perform on production without permission.

Escalating on your own deliberately-weak VM

The applied lab for objective 4.3, on a lab VM from lesson 2 that you weaken on purpose so you know the answer.

1. Build a VM and snapshot it clean.
2. Plant one escalation path — a sudo rule to an escapable command, a world-writable file a root cron job reads, or a hand-made SUID binary.
3. Land as an unprivileged user, as though from lesson 24.
4. Enumerate, and find the path you planted using the checks above rather than your memory of where you hid it.
5. Escalate, and confirm you have root.
6. Read the logs, then roll back to the snapshot.

Then plant a different path and repeat, so you practise the enumeration rather than one trick. The goal is that finding the seam becomes systematic — you run the same checks every time and let them surface whatever is there.

Evidence a defender would have seen

The defender's half, which every Domain 4 lesson ends on because Domain 5 needs it.

Escalation leaves traces, and knowing them is what makes the remediation specific:

• Sudo invocations are logged, so a sudo-based escalation is visible if anyone reads them — and often nobody does, which is itself a finding.
• New SUID files appearing on a system is a change file-integrity monitoring is built to catch.
• A kernel exploit often leaves crash artefacts, unusual kernel messages, or a reboot in the record.
• A shell spawned by a service account that normally never opens one is an anomaly worth alerting on.

So the report says: here is the path, here is what your system recorded, and here is whether anything would have told you. If the escalation was invisible to their monitoring, the monitoring gap ranks alongside the escalation itself.

What to take into the exam

• Escalation is mostly enumeration — groups, sudo rules, running processes, scheduled jobs, and anything hand-built.
• SUID/SGID binaries, escapable sudo rules and writable paths in a privileged context are the three staple primitives; all are "a privilege you hold used unchecked by something more privileged".
• Kernel exploits risk a panic and an outage — lab or written scope only — and version alone is unreliable because of backporting.
• Escalation leaves logged traces; if the client's monitoring saw none of it, that gap is a finding.