Elevation - Rising from the Mud

Getting in is not enough. You have to rise. You have to take control.

Accessing a system doesn't mean you've won. You're inside, yes, but chained. The real game begins when you need more. More permissions. More control. More power.

That's privilege escalation. And this lesson is a map to find the cracks in a structure built by hands that make mistakes.

What is Privilege Escalation?

Privilege escalation happens when a user with limited access manages to perform actions reserved for higher authority accounts, like root.

Types:

• Vertical Escalation: From an unprivileged user to a privileged user (root).
• Horizontal Escalation (or lateral movement): Moving from one user to another with the same permissions. Useful if the other user has access to files, credentials, or vulnerable configurations.

Why it happens

Because systems are configured by humans.
And humans make mistakes.

Common mistakes that allow escalation:

• Poorly defined permissions on binaries or files.
• Files with the SUID bit set unnecessarily.
• Access to sudo without restrictions or without a password.
• Poorly implemented scripts or services.
• Weak, predictable, or reused passwords.

SUID: The Razor's Edge

The SUID (Set User ID) bit, when set on an executable file, allows any user to run the file with the owner's permissions.

For example:

1ls -l /usr/bin/passwd
2-rwsr-xr-x 1 root root 54256 Jan  1 00:00 /usr/bin/passwd

That s instead of the x indicates it has SUID.
The passwd binary needs to modify /etc/shadow, but normal users don't have that permission. SUID allows this action in a controlled way.

But when custom or insecure binaries have this bit... unexpected paths open up.

How to identify SUID binaries

1find / -perm -4000 -type f 2>/dev/null

If you find a binary owned by root, has SUID, and you can execute it… you know what to do.

What about sudo?

`sudo