☑️Information Gathering
Environment Enumeration
Typically we'll want to run a few basic commands to orient ourselves:
whoami- what user are we running asid- what groups does our user belong to?hostname- what is the server named, can we gather anything from the naming convention?ifconfigorip -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 likesudo suand 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.
Operating System
We'll start out by checking out what operating system and version we are dealing with.
cat /etc/os-releaseNAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.4 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focalWe can see that the target is running Ubuntu 20.04.4 LTS ("Focal Fossa"). For whatever version we encounter its important to see if we're dealing with something out-of-date or maintained. Ubuntu publishes its release cycle and from this we can see that "Focal Fossa" does not reach end of life until April 2030. From this information we can assume that we will not encounter a well-known Kernel vulnerability because the customer has been keeping their internet-facing asset patched but we'll still look regardless.
Current Path
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.
For now we'll note it down and add it to our notetaking tool of choice.
Env Variables
We can also check out all environment variables that are set for our current user, we may get lucky and find something sensitive in there such as a password. We'll note this down and move on.
Kernel Version
Next let's note down the Kernel version. We can do some searches to see if the target is running a vulnerable Kernel 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.
CPU type / Version
We can next gather some additional information about the host itself such as the CPU type/version:
Shells
What login shells exist on the server? Note these down and highlight that both Tmux and Screen are available to us.
Defenses
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:
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.
Drives / Shares
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.
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?
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?
Routing Table / ARP Table
Check out the routing table by typing route or netstat -rn. Here we can see what other networks are available via which interface.
We'll also want to check the arp table to see what other hosts the target has been communicating with.
Active Directory
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.
Users
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:
Username
Password
User ID (UID)
Group ID (GID)
User ID info
Home directory
Shell
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.
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$...
Groups
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.
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.
/Home
We can also check out which users have a folder under the /home directory. We'll want to enumerate each of these to see if any of the system users are storing any sensitive data, files containing passwords. We should check to see if files such as the .bash_history file are readable and contain any interesting commands and look for configuration files. It is not uncommon to find files containing credentials that can be leveraged to access other systems or even gain entry into the Active Directory environment. Its also important to check for SSH keys for all users, as these could be used to achieve persistence on the system, potentially to escalate privileges, or to assist with pivoting and port forwarding further into the internal network. At the minimum, check the ARP cache to see what other hosts are being accessed and cross-reference these against any useable SSH private keys.
Config Files
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!
Mounted FS
In Linux, there are many different places where such files can be stored, including mounted file systems. A mounted file system is a file system that is attached to a particular directory on the system and accessed through that directory. Many file systems, such as ext4, NTFS, and FAT32, can be mounted. Each type of file system has its own benefits and drawbacks. For example, some file systems can only be read by the operating system, while others can be read and written by the user. File systems that can be read and written to by the user are called read/write file systems. Mounting a file system allows the user to access the files and folders stored on that file system. In order to mount a file system, the user must have root privileges. Once a file system is mounted, it can be unmounted by the user with root privileges. We may have access to such file systems and may find sensitive information, documentation, or applications there.
Unmounted file systems can be viewed as follows:
Hidden Files & Directories
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.
Considering our name is htb-student:
Temporary Files
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.
Linux Services & Internals Enumeration
At this stage we will ask:
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/hostsfile?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_historyfile 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?
Internals
When we talk about the internals, we mean the internal configuration and way of working, including integrated processes designed to accomplish specific tasks. So we start with the interfaces through which our target system can communicate.
Users last login
Currently logged in users
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
Finding history files
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.
Cron jobs
It's also a good idea to check for any cron jobs on the system. Cron jobs on Linux systems are similar to Windows scheduled tasks. They are often set up to perform maintenance and backup tasks. In conjunction with other misconfigurations such as relative paths or weak permissions, they can leverage to escalate privileges when the scheduled cron job runs.
Process Filesystem
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. It is virtual and does not exist as a real filesystem but is dynamically generated by the kernel. It can be used to look up system information such as the state of running processes, kernel parameters, system memory, and devices. It also sets certain system parameters, such as process priority, scheduling, and memory allocation.
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
Sudo Version
It's also a good idea to check if the sudo version installed on the system is vulnerable to any legacy or recent exploits.
Binaries
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.
GTFObins
GTFObins provides an excellent platform that includes a list of binaries that can potentially be exploited to escalate our privileges on the target system. With the next oneliner, we can compare the existing binaries with the ones from GTFObins to see which binaries we should investigate later.
Trace System Calls
We can use the diagnostic tool strace on Linux-based operating systems to track and analyze system calls and signal processing. It allows us to follow the flow of a program and understand how it accesses system resources, processes signals, and receives and sends data from the operating system. In addition, we can also use the tool to monitor security-related activities and identify potential attack vectors, such as specific requests to remote hosts using passwords or tokens.
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.
Configuration Files
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.
Scripts
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.
Running servies by the user
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.
Credentials 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:
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).
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.
Last updated