Top 7 Privilege Escalation Tricks and How to Defend against them

In this post, I will show you 7 ways you can use right now for privilege escalation to get Root on any Linux target! And you can replicate the exact steps in publicly accessible hands-on labs. This is also for defenders who want to learn how to prevent these attacks.

Penetration testers typically have limited access when they get into a system for the first time. But thanks to extensive enumeration, and some sloppy errors made by developers and sysadmins, they inevitably gain complete control. In Windows, they aim at getting SYSTEM-level privileges, and in Linux, they target the root user. 

You can reproduce the same techniques I will show you on online platforms or locally on your machine.

Privilege Escalation using public exploits

Coming last is one of the easiest. With this technique, you can become root in seconds without knowing anything more than how to run basic Linux commands. Have you guessed it? It’s reusing public exploits for outdated Linux kernels. It’s game over for the target when you stumble upon a situation like this. Here is how the attack goes:

1. You tell the compromised server to spit out its kernel version using uname -a
2. You search online for public exploits targeting the kernel version you got.
3. If you are lucky, you find the exploit and how to compile it. Usually, you will just have to copy paste the gcc command. Sometimes, you must compile it on your attacking machine and upload it to the target server.
4. Run it and enjoy!

Here is a demonstration of such a workflow. You can replicate the same steps on the online challenge BilluBox available on Vulnhub and root-me. 

If you wanna stay secure, always use up to date systems. Otherwise, hackers will either get root or crash your server. Like what happened here during one of my privilege escalation attempts using the dirtycow exploit.

Privesc using writable files

Next is a cool misconfiguration that will expose any server to privilege escalation. No one can stop you from getting that beloved root shell when you encounter it. This vulnerability will allow you to update the password of any user in the system, including root. Have you guessed it? Yep, It’s when the file /etc/passwd is writable. Agreed, you will not find this misconfiguration everywhere, but it’s a lovely card in your deck when the opportunity presents itself. The attack plan is as simple as generating a dummy password and updating the user of your choice or creating a new one to avoid raising immediate attention from defenders. Watch how I do it in this portion of the challenge Bulldog 2.

It’s always a good idea to check for file permissions on critical files in your system. You can use the auditd service to monitor for file operations, or write a small cronjob script to check for weak permissions, and revert the exposed files to their old secure configuration.

Get root by abusing weak passwords

Next on the list is a little trick that I try when I exhaust all my cards. It’s one of my least favorites, but it works like a charm when sysadmins are so sloppy. You can teach them a lesson, you know. Introducing…online SSH brute force. Now, how do we pull this off? Well, my trusty tool for this is Hydra, a nifty tool that packs a punch. Watch this portion of the challenge Born2root. And for sysadmins out there, please ensure you never use weak passwords.

Privilege escalation through overly permissive rights

In Linux servers lies a trick that never fails to send shivers down sysadmin spines. Brace yourselves as I present one of my all-time favorites: the enigmatic permissive sudo rights. Oh, the thrill it brings! This cunning technique, found more often than not during my engagements, holds the key to unlocking root access. Sometimes, sysadmins give all the keys of the kingdom to other users, and when I get my hand on one of them, it’s game over! Watch this portion of the Born2rootv2 challenge where I pwn a Joomla website and get root.

Sometimes, the sysadmins allow only a few commands. And here is where it gets more interesting. Because I love some challenge from serious sysadmins. In this portion of the Gallery CTF on tryhackme, the sysadmin only allowed a script to run as root, but it used nano in one of its features to read some files. So I leverage nano to spawn a root shell.

Sysadmins should always avoid giving all privileges to other accounts. Ideally, you should opt for PAM solutions; they have more power than sudo. Agreed, they require some learning curve, but they will save your weekend when hackers attempt to strike on a Friday afternoon!

Abuse Cron Jobs for Privesc

Next is a technique that abuses a feature you will certainly encounter in almost every engagement. You see, sysadmins have to automate stuff by running crucial scripts at a precise time, usually with elevated privileges. And hackers always get excited when they find them. Have you guessed it? Yep, they are no other than cron jobs. In this portion of the Bulldog challenge, I found a writable cron job running as root!

To defend against this, always make sure you follow the least privilege principle, don’t be lazy; it will bite you when you least expect it. Ensure you only run your cron jobs with the minimum privileges required for the task. And also, make sure you write good-quality scripts that do not open the door to hackers. Speaking of poor code, the following technique is a great example.

Get admin using weak SUID scripts and binaries 

When I find an executable with the suid bit or when I find a cron job that runs commands as root but without specifying the absolute path, I immediately abuse it to get root on the system. Here is a demonstration taken from the challenge Reativilty, where I found a poorly-written script configured to run with sudo.

Find and exploit progras running as root

Another use case of poor privilege management I find frequently is when sysadmins run programs as root. I can’t stress it enough! Please respect the least privilege principle! It’s there for a reason. In this portion of the Gemini CTF, I leverage a redis server running locally as root to give myself root privileges through SSH.

Conclusion

You can still get root even if you don’t find any of the previous vulnerabilities during your engagement. It all boils down to how much you understand about the system, which in turn cannot be acquired without extensive enumeration.