Linux Manual Exploitation
Linux privesc in brief
sudo -l
Kernel Exploits
OS Exploits
Password reuse (mysql, .bash_history, 000-default.conf...)
Known binaries with suid flag and interactive (nmap)
Custom binaries with suid flag either using other binaries or with command execution
Writable files owned by root that get executed (cronjobs)
MySQL as root
Vulnerable services (chkrootkit, logrotate)
Writable /etc/passwd
Readable .bash_history
SSH private key
Listening ports on localhost
/etc/fstab
/etc/exports
/var/mail
Process as other user (root) executing something you have permissions to modify
SSH public key + Predictable PRNG
apt update hooking (Pre-Invoke)
Capabilities
File System
/root root user's home directory. Usually only accessible by root user.
/home user's directory. Good to remember user's names.
/etc system configuration files. passwd and shadow files are here.
/bin and /sbin System binaries. useful for telling you which commands you can run
/usr user's binaries and libraries can be found here,
/var Contains logs and if apache, web files can be found here.
/dev device drivers
/lib contain shared libraries
/boot files for booting the system
/mnt mount point for media
/proc contains processes marked as a file by process number
/tmp Holds temporary files and is usually globally readable/writable
One liner
Here you have an old linpeas version script in one line, just copy and paste it;)
The color filtering is not available in the one-liner (the lists are too big)
This one-liner is deprecated (I'm not going to update it any more), but it could be useful in some cases so it will remain here.
The default file where all the data is stored is: /tmp/linPE (you can change it at the beginning of the script)
Collecting Information
OS, Kernel & Hostname -
Important for kernel exploit
This will print information about operating system and kernel related information , useful in kernel exploitation
Users -
/etc/passwd
The passwd file stores essential user account information required during login. The passwd file is stored in the /etc directory and contains information such as the user ID, group ID, home directory and the path to the command shell. An ‘x’ character means that the encrypted password is stored in the /etc/shadow file.
The following commands can be used to retrieve information about the current user and active session:
Network Information
Network Adapters -
Will print adapter target connected with , this will give us insight of how many networks are connected with box and also information about internal network if available
Print Routing tables
Information related different network routes , give us information about target network reach , useful in pivoting through different networks
Print the active connections
This will list all connections going on withing target system , this way we can determine what services are running and will be useful for us to extract important information
Print the arp entries
/proc/net/
more discreet, all the information given by the above commands can be found by looking into the files under /proc/net, and this approach is less likely to trigger monitoring or other stuff
Application and Services
Retrieve information about services
knowing which services are running with root privileges can be very important for priv esc because exploiting them will result in root-level access
Service exploits can be found using Searchsploit, Google, and GitHub, just like with Kernel exploits.
To retrieve installed applications
important to check if any application that is installed vulnerable to any known exploits
Sudoers
Make sure you pay attention to the groups to which the privileged user belongs. One especially important group is the sudo (‘Super User Do’) group. A user that is a member of the sudo group is able to execute commands in the context of the root user without providing the root password – depending on the settings in the sudoer file you may only need to enter the password for the current user or none at all.
Useful commands
If you are part of group and can run specified , check https://gtfobins.github.io/ with that binary on how to liverage your access to gain root with that binary
LD_PRELOAD
LD_PRELOAD is an environment variable which can be set to the path of a shared object (.so) file.
When set, the shared object will be loaded before any others.
By creating a custom shared object and creating an init() function, we can execute code as soon as the object is loaded.
Exploitation -
1. Run sudo -l to check if env_keepoption is set

2. Create a file (preload.c) with the following contents:
3. Compile preload.c to preload.so:
4. Run any allowed program using sudo, while setting the LD_PRELOAD environment variable to the full path of the preload.so file:
LD_LIBRARY_PATH
The LD_LIBRARY_PATH environment variable contains a set of directories where shared libraries are searched for first.
The ldd command can be used to print the shared libraries used by a program:
ldd /usr/sbin/apache2
By creating a shared library with the same name as one used by a program, and setting LD_LIBRARY_PATH to its parent directory, the program will load our shared library instead.
Exploitation -
1. Run lld against the apache2 program file -
Hijacking shared objects using this method is hit or miss. Choose one from the list and try it (libcrypt.so.1 seems to work well).
2. Create a file (library_path.c) with the following contents:
3. Compile library_path.c into libcrypt.so.1:
4. Run apache2 using sudo, while setting the LD_LIBRARY_PATH environment variable to the current path (where we compiled library_path.c):
Cron Jobs
Cron jobs are programs or scripts which users can schedule to run at specific times or intervals.
Cron jobs run with the security level of the user who owns them.

Weak File Permission
Misconfiguration of file permissions associated with cron jobs can lead to easy privilege escalation. If we can write to a program or script which gets run as part of a cron job, we can replace it with our own code (Most of time reverse shell)
PATH Environment Variable
The crontab PATH environment variable is by default set to /usr/bin:/bin
The PATH variable can be overwritten in the crontab file.
If a cron job program/script does not use an absolute path, and one of the PATH directories is writable by our user, we may be able to create a program/script with the same name as the cron job.
Steps to check -
1. First print $PATH variable to see if we can manipulate it according to our need
2. Adding our own path to $PATH where we can write our own malicious binary , in this example /tmp directory
it will add /tmp in front of PATH variable so now when cron job run , it will start looking for that particular binary through $PATH variable and since we put our own path in starting , it will first look for that file in that directory so we ned to put our own malicious binary with same name in our directory
3. Put your malicious binary in directory which you added to $PATH
/etc/shadow
1. If you are able to read this file ,
1. Extract the root user's password
2. Save the password hash in a file
3. Crack the password hash using john
2. If you have writable permission ,
1. Generate a new SHA-512 password hash -
2. Edit the /etc/shadow and replace the root user’s password hash with the one we generated.
/etc/passwd
If you have writable permission -
1. Generate a password using opnssl
2. Edit the /etc/passwd file and enter the hash in the second field of the root user row in the place of 'x'
3. Or you can do it append a new row to it to create an alternate root user
SUID - SGID
Finding SUID and SGID
If you get any unusual binary set with SUID or SGID bit , always check on https://gtfobins.github.io/ to get exploitation steps to achieve root
Shared Object Injection
When a program is executed, it will try to load the shared objects it requires.
By using a program called strace, we can track these system calls and determine whether any shared objects were not found.
If we can write to the location the program tries to open, we can create a shared object and spawn a root shell when it is loaded.
Exploitation -
1. Find SUID/SGID files on the target:
The suid-so file should execute with root user permissions.
2. Run strace on the SUID file:
The libcalc.so shared object could not be found, and the program is looking in our user’s home directory, which we can write to.
3. Create the /home/user/.config directory
4. Create the file libcalc.c with the following contents:
5. Compile libcalc.c into /home/user/.config/libcalc.so:
6. Run the SUID executable to get a root shell:
Path Manipulation
It is very simple to view the Path of the relevant user with help of echo command.
Exploitation -
If you find that you can write inside some folder of the $PATH you may be able to escalate privileges by creating a backdoor inside the writable folder with the name of some command that is going to be executed by a different user (root ideally) and that is not loaded from a folder that is located previous to your writable folder in $PATH.
Example -
we came with one suid that executing some other binaries


so it's executing /bin/ps binary to get process status , so what we can do is , make our own ps binary containing malicious payload and execute it with adding PATH to it
Creating malicious binary -
Exporting current path in front -
it will add /tmp in front of PATH variable so now if someone execute that binary it will try to run ps and thus our own ps binary executed giving us root access
Passwords and configs
Finding different information
Scan for password or credential word in files
Find all directories which can be written to
Find all writable files and readable files
Configs
Last updated