A good enumeration helps in finding the right escalation technique
After gaining access to the system, enumeration is key to know the right exploitation/privilege escalation technique.
Finding host names
Using the hostname command, we can find the host name associated with the target system.
hostname
$ hostname
wade7363
Although this value can easily be changed or have a relatively meaningless string (e.g. Ubuntu-3487340239), in some cases, it can provide information about the target system’s role within the corporate network (e.g. SQL-PROD-01 for a production SQL server).
Kernel details using uname
The uname command will print system information giving us additional detail about the kernel used by the system. This will be useful when searching for any potential kernel vulnerabilities that could lead to privilege escalation.
uname-a
Linux wade7363 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Information from the proc file system
The proc file system (procfs) provides information about the target system processes.
cat/proc/version
Linux version 3.13.0-24-generic (buildd@panlong) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014
Finding system information from /etc/issue
Systems can also be identified by looking at the /etc/issue file. This file usually contains some information about the operating system but can easily be customized or changed.
cat/etc/issue
Ubuntu 14.04 LTS \n \l
List of available shells by command-line
The /etc/shells file contains the available shells in the target.
The aux option will show processes for all users (a), display the user that launched the process (u), and show processes that are not attached to a terminal (x).
The PATH variable may have a compiler or a scripting language (e.g. Python) that could be used to run code on the target system or leveraged for privilege escalation.
The sudo -l for Finding commands that the user can run with root privileges
The target system may be configured to allow users to run some (or all) commands with root privileges. The sudo -l command can be used to list all commands your user can run using sudo.
sudo-l
Matching Defaults entries for fvalkyrie on faraday:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty
User fvalkyrie may run the following commands on faraday:
(ALL : ALL) ALL
Finding User Id and Group Id
The id command will provide a general overview of the user’s privilege level and group memberships. The id command can also be used to obtain the same information for another user.
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.
Confirm target as pivoting point and find adjacent machines
The target system may be a pivoting point to another network. The ifconfig command will give us information about the network interfaces of the system.
Use the ip route command to see which network routes exist.
iproute
default via 10.10.0.1 dev eth0
10.10.0.0/16 dev eth0 proto kernel scope link src 10.10.14.143
169.254.0.0/16 dev eth0 scope link metric 1000
Looking into existing communications
Using the netstat command we can have information about the existing communications.
netstat-a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 localhost:ipp *:* LISTEN
tcp 0 1 ip-10-10-81-154.e:37517 ubuntu-mirror-2.ps:http SYN_SEN
netstat-at# t is for TCP. Can be used with u to show UDP connections
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 localhost:ipp *:* LISTEN
To find all the listening ports we can use -l which list ports in “listening” mode. These ports are open and ready to accept incoming connections. This can be used with the t option to list only ports that are listening using the TCP protocol.
netstat-l# lists all listening processes
netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 localhost:ipp *:* LISTEN
tcp6 0 0 [::]:ssh [::]:* LISTEN
tcp6 0 0 ip6-localhost:ipp [::]:* LISTEN
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 10074 /tmp/.X11-unix/X0
unix 2 [ ACC ] STREAM LISTENING 10513 /var/run/cups/cups.sock
unix 2 [ ACC ] STREAM LISTENING 10073 @/tmp/.X11-unix/X0
unix 2 [ ACC ] STREAM LISTENING 11311 /run/user/112/puls
To get the network usage statistics we can use the -s flag with -t or -u
netstat-st
Tcp:
97 active connections openings
3 passive connection openings
52 failed connection attempts
0 connection resets received
1 connections established
538 segments received
469 segments send out
70 segments retransmited
0 bad segments received.
52 resets sent
UdpLite:
TcpExt:
2 TCP sockets finished time wait in fast timer
5 delayed acks sent
Quick ack mode was activated 1 times
17 packet headers predicted
82 acknowledgments not containing data payload received
142 predicted acknowledgments
13 other TCP timeouts
1 DSACKs sent for old packets
TCPRcvCoalesce: 3
To know about the interface statistics, like eth0 or tun0, we can use the -i flag.
Find files that are readable, writable, and executable by all users
find / -type f -perm 0777 2>/dev/null
Find executables
find / -perm a=x 2>/dev/null
Find all files under /home directory for a particular user
find /home -user frank 2>/dev/null
Find files modified by time index and size
find / -mtime 10 # find files that were modified in the last 10 days
find / -atime 10 # find files that were accessed in the last 10 day
find / -cmin -60 # find files changed within the last hour (60 minutes)
find / -amin -60 # find files accesses within the last hour (60 minutes)
find / -size 50M # find files with a 50 MB size
Find world-writable folders
find / -writable -type d 2>/dev/null
find / -perm -222 -type d 2>/dev/null
find / -perm -o w -type d 2>/dev/null
Find world executable folders
find / -perm -o x -type d 2>/dev/null
Find Files with SUID set
find / -perm -u=s -type f 2>/dev/null
Find all scheduled scripts using crontab
Cron jobs are typically located in the spool directories. They are stored in tables called crontabs. The cron jobs or schedules scripts can be viewed by using the crontab command.
crontab -l
But sometimes the above command may be disabled for a user.
In such situations, we can find them in /var/spool/cron/crontabs. The tables contain the cron jobs for all users, except the root user.
cat /var/spool/cron/crontabs
We can dump the contents of the /etc/crontab file which stores the root user cron job details (also known as system-wide crontabs).
cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
*/5 * * * * root /home/user4/Desktop/autoscript.sh
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
Check if you are in a container environment
Check for the /proc/1/cgroup file:
Run the following command:
cat /proc/1/cgroup
If you see output that contains /docker/, /lxc/, or /kubepods/, it's likely that you are in a container. The exact string may vary depending on the container runtime being used (e.g., Docker, LXC, or Kubernetes).
Inspect the hostname:
Run the hostname command to check the hostname of the system.
Container hostnames often have a random or autogenerated name, which may indicate that you are in a container.
Examine the process tree:
Run the pstree -a command to view the process tree.
If the process tree looks isolated with only a few processes and lacks the typical system services, it might be a sign that you are in a container.
Check for container-specific environment variables:
Run env to list environment variables.
Some containers set specific environment variables (e.g., DOCKER_CONTAINER, KUBERNETES_POD_NAME, KUBERNETES_SERVICE_HOST, etc.) that can indicate containerization.
Look for container runtime commands:
Check if Docker, Podman, or another container runtime is installed and running on the system:
docker --version
podman --version
Inspect the filesystem:
Check the file system structure for signs of a container runtime's file layout. For example, Docker containers may have files in /var/lib/docker.
Examine network configuration:
Check the network configuration using commands like ifconfig, ip a, or docker network ls. Containers often have isolated network namespaces.
Check for limited access to system resources:
Containers are typically isolated and have limited access to system resources. You can check resource limitations using tools like ulimit or cat /proc/<PID>/cgroup.
