Information Gathering

Environment Enumeration

Enumeration is the key to privilege escalation. Several helper scripts (such as LinPEAS and LinEnum) exist to assist with enumeration. Still, it is also important to understand what pieces of information to look for and to be able to perform your enumeration manually. When you gain initial shell access to the host, it is important to check several key details.

OS Version: Knowing the distribution (Ubuntu, Debian, FreeBSD, Fedora, SUSE, Red Hat, CentOS, etc.) will give you an idea of the types of tools that may be available. This would also identify the operating system version, for which there may be public exploits available.

Kernel Version: As with the OS version, there may be public exploits that target a vulnerability in a specific kernel version. Kernel exploits can cause system instability or even a complete crash. Be careful running these against any production system, and make sure you fully understand the exploit and possible ramifications before running one.

Running Services: Knowing what services are running on the host is important, especially those running as root. A misconfigured or vulnerable service running as root can be an easy win for privilege escalation. Flaws have been discovered in many common services such as Nagios, Exim, Samba, ProFTPd, etc. Public exploit PoCs exist for many of them, such as CVE-2016-9566, a local privilege escalation flaw in Nagios Core < 4.2.4.

Gaining Situational Awareness

Typically we'll want to run a few basic commands to orient ourselves:

• whoami - what user are we running as

• id - what groups does our user belong to?

• hostname - what is the server named, can we gather anything from the naming convention?

• ifconfig or ip -a - what subnet did we land in, does the host have additional NICs in other subnets?

• sudo -l - can our user run anything with sudo (as another user as root) without needing a password? This can sometimes be the easiest win and we can do something like sudo su and drop right into a root shell.

Including screenshots of the above information can be helpful in a client report to provide evidence of a successful Remote Code Execution (RCE) and to clearly identify the affected system. Now let's get into our more detailed, step-by-step, enumeration.

We'll start out by checking out what operating system and version we are dealing with.

cat /etc/os-release

Next we'll want to check out our current user's PATH, which is where the Linux system looks every time a command is executed for any executables to match the name of what we type, i.e., id which on this system is located at /usr/bin/id. As we'll see later in this module, if the PATH variable for a target user is misconfigured we may be able to leverage it to escalate privileges. For now we'll note it down and add it to our notetaking tool of choice.

echo $PATH

or

env

Next let's note down the Kernel version. We can do some searches to see if the target is running a vulnerable Kernel (which we'll get to take advantage of later on in the module) which has some known public exploit PoC. We can do this a few ways, another way would be cat /proc/version but we'll use the uname -a command.

uname -a

We can next gather some additional information about the host itself such as the CPU type/version:

lscpu

What login shells exist on the server? Note these down and highlight that both Tmux and Screen are available to us.

cat /etc/shells

We should also check to see if any defenses are in place and we can enumerate any information about them. Some things to look for include:

• Exec Shield

• iptables

• AppArmor

• SELinux

• Fail2ban

• Snort

• Uncomplicated Firewall (ufw)

Often we will not have the privileges to enumerate the configurations of these protections but knowing what, if any, are in place, can help us not to waste time on certain tasks.

Next we can take a look at the drives and any shares on the system. First, we can use the lsblk command to enumerate information about block devices on the system (hard disks, USB drives, optical drives, etc.). If we discover and can mount an additional drive or unmounted file system, we may find sensitive files, passwords, or backups that can be leveraged to escalate privileges.

lsblk

The command lpstat can be used to find information about any printers attached to the system. If there are active or queued print jobs can we gain access to some sort of sensitive information?

We should also check for mounted drives and unmounted drives. Can we mount an umounted drive and gain access to sensitive data? Can we find any types of credentials in fstab for mounted drives by grepping for common words such as password, username, credential, etc in /etc/fstab?

cat /etc/fstab

Check out the routing table by typing route or netstat -rn. Here we can see what other networks are available via which interface.

route

In a domain environment we'll definitely want to check /etc/resolv.conf if the host is configured to use internal DNS we may be able to use this as a starting point to query the Active Directory environment.

We'll also want to check the arp table to see what other hosts the target has been communicating with.

arp -a

The environment enumeration also includes knowledge about the users that exist on the target system. This is because individual users are often configured during the installation of applications and services to limit the service's privileges. The reason for this is to maintain the security of the system itself. Because if a service is running with the highest privileges (root) and this is brought under control by an attacker, the attacker automatically has the highest rights over the entire system. All users on the system are stored in the /etc/passwd file. The format gives us some information, such as:

1. Username

2. Password

3. User ID (UID)

4. Group ID (GID)

5. User ID info

6. Home directory

7. Shell

cat /etc/passwd

Occasionally, we will see password hashes directly in the /etc/passwd file. This file is readable by all users, and as with hashes in the /etc/shadow file, these can be subjected to an offline password cracking attack. This configuration, while not common, can sometimes be seen on embedded devices and routers.

cat /etc/passwd | cut -f1 -d:

With Linux, several different hash algorithms can be used to make the passwords unrecognizable. Identifying them from the first hash blocks can help us to use and work with them later if needed. Here is a list of the most used ones:

Algorithm	Hash
Salted MD5	$1$...
SHA-256	$5$...
SHA-512	$6$...
BCrypt	$2a$...
Scrypt	$7$...
Argon2	$argon2i$...

We'll also want to check which users have login shells. Once we see what shells are on the system, we can check each version for vulnerabilities. Because outdated versions, such as Bash version 4.1, are vulnerable to a shellshock exploit.

grep "*sh$" /etc/passwd

Each user in Linux systems is assigned to a specific group or groups and thus receives special privileges. For example, if we have a folder named dev only for developers, a user must be assigned to the appropriate group to access that folder. The information about the available groups can be found in the /etc/group file, which shows us both the group name and the assigned user names.

cat /etc/group

The /etc/group file lists all of the groups on the system. We can then use the getent command to list members of any interesting groups.

getent group sudo

We can also check out which users have a folder under the /home directory.

Check for:

• SSH Keys

• .bash_history (or other shell history files)

• credentials

• AD files

ls /home

Finally, we can search for any "low hanging fruit" such as config files, and other files that may contain sensitive information. Configuration files can hold a wealth of information. It is worth searching through all files that end in extensions such as .conf and .config, for usernames, passwords, and other secrets.

If we've gathered any passwords we should try them at this time for all users present on the system. Password re-use is common so we might get lucky!

We may have access to such file systems and may find sensitive information, documentation, or applications there.

Mounted File Systems

df -h

Therefore, if we can extend our privileges to the root user, we could mount and read these file systems ourselves. Unmounted file systems can be viewed as follows

Unmounted File Systems

cat /etc/fstab | grep -v "#" | column -t

Many folders and files are kept hidden on a Linux system so they are not obvious, and accidental editing is prevented. Why such files and folders are kept hidden, there are many more reasons than those mentioned so far. Nevertheless, we need to be able to locate all hidden files and folders because they can often contain sensitive information, even if we have read-only permissions.

All Hidden Files

find / -type f -name ".*" -exec ls -l {} \; 2>/dev/null | grep htb-student

All Hidden Directories

find / -type d -name ".*" -ls 2>/dev/null

In addition, three default folders are intended for temporary files. These folders are visible to all users and can be read. In addition, temporary logs or script output can be found there. Both /tmp and /var/tmp are used to store data temporarily. However, the key difference is how long the data is stored in these file systems. The data retention time for /var/tmp is much longer than that of the /tmp directory. By default, all files and data stored in /var/tmp are retained for up to 30 days. In /tmp, on the other hand, the data is automatically deleted after ten days.

In addition, all temporary files stored in the /tmp directory are deleted immediately when the system is restarted. Therefore, the /var/tmp directory is used by programs to store data that must be kept between reboots temporarily.

Temporary Files

ls -l /tmp /var/tmp /dev/shm

Linux Services & Internals Enumeration

In this phase we will enumerate the following which will help to inform many of the attacks discussed in the later sections of this module.

• What services and applications are installed?

• What services are running?

• What sockets are in use?

• What users, admins, and groups exist on the system?

• Who is current logged in? What users recently logged in?

• What password policies, if any, are enforced on the host?

• Is the host joined to an Active Directory domain?

• What types of interesting information can we find in history, log, and backup files

• Which files have been modified recently and how often? Are there any interesting patterns in file modification that could indicate a cron job in use that we may be able to hijack?

• Current IP addressing information

• Anything interesting in the /etc/hosts file?

• Are there any interesting network connections to other systems in the internal network or even outside the network?

• What tools are installed on the system that we may be able to take advantage of? (Netcat, Perl, Python, Ruby, Nmap, tcpdump, gcc, etc.)

• Can we access the bash_history file for any users and can we uncover any thing interesting from their recorded command line history such as passwords?

• Are any Cron jobs running on the system that we may be able to hijack?

At this time we'll also want to gather as much network information as possible. What is our current IP address? Does the system have any other interfaces and, hence, could possibly be used to pivot into another subnet that was previously unreachable from our attack host? We do this with the ip a command or ifconfig, but this command will sometimes not work on certain systems if the net-tools package is not present.

Internals

Network Interfaces

ip a

Hosts

cat /etc/hosts

It can also be helpful to check out each user's last login time to try to see when users typically log in to the system and how frequently. This can give us an idea of how widely used this system is which can open up the potential for more misconfigurations or "messy" directories or command histories.

User's Last Login

lastlog

In addition, let's see if anyone else is currently on the system with us. There are a few ways to do this, such as the who command. The finger command will work to display this information on some Linux systems.

Logged In Users

w

It is also important to check a user's bash history, as they may be passing passwords as an argument on the command line, working with git repositories, setting up cron jobs, and more. Reviewing what the user has been doing can give you considerable insight into the type of server you land on and give a hint as to privilege escalation paths.

Command History

history

Sometimes we can also find special history files created by scripts or programs. This can be found, among others, in scripts that monitor certain activities of users and check for suspicious activities.

Finding History Files

find / -type f \( -name *_hist -o -name *_history \) -exec ls -l {} \; 2>/dev/null

It's also a good idea to check for any cron jobs on the system.

Cron

ls -la /etc/cron.daily/

The proc filesystem (proc / procfs) is a particular filesystem in Linux that contains information about system processes, hardware, and other system information. It is the primary way to access process information and can be used to view and modify kernel settings

Proc

find /proc -name cmdline -exec cat {} \; 2>/dev/null | tr " " "\n"

Services

If it is a slightly older Linux system, the likelihood increases that we can find installed packages that may already have at least one vulnerability. However, current versions of Linux distributions can also have older packages or software installed that may have such vulnerabilities. Therefore, we will see a method to help us detect potentially dangerous packages in a bit. To do this, we first need to create a list of installed packages to work with.

Installed Packages

apt list --installed | tr "/" " " | cut -d" " -f1,3 | sed 's/[0-9]://g' | tee -a installed_pkgs.list

It's also a good idea to check if the sudo version installed on the system is vulnerable to any legacy or recent exploits.

Sudo Version

sudo -V

Occasionally it can also happen that no direct packages are installed on the system but compiled programs in the form of binaries. These do not require installation and can be executed directly by the system itself.

Binaries

ls -l /bin /usr/bin/ /usr/sbin/

GTFObins provides an excellent platform that includes a list of binaries that can potentially be exploited to escalate our privileges on the target system

GTFObins

for i in $(curl -s https://gtfobins.github.io/ | html2text | cut -d" " -f1 | sed '/^[[:space:]]*$/d');do if grep -q "$i" installed_pkgs.list;then echo "Check GTFO for: $i";fi;done

We can use the diagnostic tool strace on Linux-based operating systems to track and analyze system calls and signal processing.

The output of strace can be written to a file for later analysis, and it provides a wealth of options that allow detailed monitoring of the program's behavior.

Trace System Calls

strace ping -c1 10.129.112.20

Users can read almost all configuration files on a Linux operating system if the administrator has kept them the same. These configuration files can often reveal how the service is set up and configured to understand better how we can use it for our purposes. In addition, these files can contain sensitive information, such as keys and paths to files in folders that we cannot see. However, if the file has read permissions for everyone, we can still read the file even if we do not have permission to read the folder.

Configuration Files

find / -type f \( -name *.conf -o -name *.config \) -exec ls -l {} \; 2>/dev/null

The scripts are similar to the configuration files. Often administrators are lazy and convinced of network security and neglect the internal security of their systems. These scripts, in some cases, have such wrong privileges that we will deal with later, but the contents are of great importance even without these privileges. Because through them, we can discover internal and individual processes that can be of great use to us.

Scripts

find / -type f -name "*.sh" 2>/dev/null | grep -v "src\|snap\|share"

Also, if we look at the process list, it can give us information about which scripts or binaries are in use and by which user. So, for example, if it is a script created by the administrator in his path and whose rights have not been restricted, we can run it without going into the root directory.

ps aux | grep root

This would give us a pretty good overview of our target system, so we can go into more detail next and figure out the individual permissions for the components we found.

Credential Hunting

When enumerating a system, it is important to note down any credentials. These may be found in configuration files (.conf, .config, .xml, etc.), shell scripts, a user's bash history file, backup (.bak) files, within database files or even in text files. Credentials may be useful for escalating to other users or even root, accessing databases and other systems within the environment.

The /var directory typically contains the web root for whatever web server is running on the host. The web root may contain database credentials or other types of credentials that can be leveraged to further access. A common example is MySQL database credentials within WordPress configuration files:

cat wp-config.php | grep 'DB_USER\|DB_PASSWORD'

The spool or mail directories, if accessible, may also contain valuable information or even credentials. It is common to find credentials stored in files in the web root (i.e. MySQL connection strings, WordPress configuration files).

find / ! -path "*/proc/*" -iname "*config*" -type f 2>/dev/null

SSH Keys

It is also useful to search around the system for accessible SSH private keys. We may locate a private key for another, more privileged, user that we can use to connect back to the box with additional privileges. We may also sometimes find SSH keys that can be used to access other hosts in the environment. Whenever finding SSH keys check the known_hosts file to find targets. This file contains a list of public keys for all the hosts which the user has connected to in the past and may be useful for lateral movement or to find data on a remote host that can be used to perform privilege escalation on our target.

ls ~/.ssh