November 8, 2024
Hey there, fellow lifelong learner! I´m Rosana, and I’m genuinely excited to join you on this adventure.
It´s part of my
Perform real-time file system analysis on a Linux system to identify an attacker's artefacts.
Access this 🆓 TryHackMe CTF Room clicking Linux File System Analysis.
Summary
Introduction ▪️ Investigation Setup ▪️ File, Permissions, and Timestamps ▪️ Users and Groups
Users Directories and Files ▪️ Binaries and Executables ▪️ Rootkits ▪️ Conclusion ▪️ Room Complete ▪️ My Journey
No answer needed
2.1. After updating the
PATHandLD_LIBRARY_PATHenvironment variables, run the command >code>check-env. What is the flag that is returned in the output?
THM{5514ec4f1ce82f63867806d3cd95dbd8}
$ investigator@ip-[Target_IP]:~$ export PATH=/mnt/usb/bin:/mnt/usb/sbin
investigator@ip-[Target_IP]:~$ export LD_LIBRARY_PATH=/mnt/usb/lib:/mnt/usb/lib64
investigator@ip-[Target_IP]:~$ check-env
THM{5514ec4f1ce82f63867806d3cd95dbd8}
$ ls -al /var/www/html/
total 32
drwxr-xr-x 4 root root 4096 Feb 12 2024 .
drwxr-xr-x 3 root root 4096 Feb 12 2024 ..
drwxr-xr-x 2 www-data www-data 4096 Feb 13 2024 assets
-rw-r--r-- 1 root root 10918 Feb 12 2024 index.html
-rwxr-xr-x 1 www-data www-data 905 Feb 12 2024 upload.php
drwxr-xr-x 2 www-data www-data 4096 Feb 13 2024 uploads
investigator@ip-10-10-229-35:~$ ls -al var/www/html/uploads
ls: cannot access 'var/www/html/uploads': No such file or directory
investigator@ip-10-10-229-35:~$ ls -al /var/www/html/uploads
total 224
drwxr-xr-x 2 www-data www-data 4096 Feb 13 2024 .
drwxr-xr-x 4 root root 4096 Feb 12 2024 ..
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 ABHz3aj.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 AhVpDoS.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 AqLnBvC.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 AsDfGhJ.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 AzSxWqE.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 BcFvGtR.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 BcNmLoP.jpeg
...
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 YmLnXhP.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 YtGfHjK.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 ZtXcVbN.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 ZxVbNmQ.jpeg
-rw-r--r-- 1 www-data www-data 1908 Feb 12 2024 ZxXcVuY.jpeg
-rw-r--r-- 1 www-data www-data 30 Feb 13 2024 b2c8e1f5.phtml
investigator@ip-10-10-229-35:~$ ls -al /var/www/html/uploads | grep -v ".jpeg"
total 224
drwxr-xr-x 2 www-data www-data 4096 Feb 13 2024 .
drwxr-xr-x 4 root root 4096 Feb 12 2024 ..
-rw-r--r-- 1 www-data www-data 30 Feb 13 2024 b2c8e1f5.phtml
investigator@ip-10-10-229-35:~$ cat /var/www/html/uploads/b2c8e1f5.phtml
investigator@ip-10-10-229-35:~$ investigator@ip-10-10-229-35:~$ find / -user www-data -type f 2>/dev/null | less
/var/www/html/assets/reverse.elf
/var/www/html/uploads/MzCxVeR.jpeg
/var/www/html/uploads/AzSxWqE.jpeg
/var/www/html/uploads/QaWsEdR.jpeg
/var/www/html/uploads/TyHjKlM.jpeg
/var/www/html/uploads/PrTgHfD.jpeg
/var/www/html/uploads/YmLnXhP.jpeg
/var/www/html/uploads/LuDjYnW.jpeg
/var/www/html/uploads/LvXcBvN.jpeg
/var/www/html/uploads/AsDfGhJ.jpeg
/var/www/html/uploads/CoSaBmQ.jpeg
/var/www/html/uploads/XkFgHtD.jpeg
/var/www/html/uploads/RfTbMeG.jpeg
/var/www/html/uploads/AqLnBvC.jpeg
/var/www/html/uploads/WzRmDnT.jpeg
/var/www/html/uploads/DnCvBzX.jpeg
/var/www/html/uploads/ZxVbNmQ.jpeg
/var/www/html/uploads/ABHz3aj.jpeg
/var/www/html/uploads/ZxXcVuY.jpeg
/var/www/html/uploads/XcVbNmQ.jpeg
/var/www/html/uploads/KtXoRlN.jpeg
/var/www/html/uploads/RoNpIqU.jpeg
/var/www/html/uploads/XcVbNkL.jpeg
/var/www/html/uploads/VbNmLoP.jpeg
/var/www/html/uploads/YtGfHjK.jpeg
/var/www/html/uploads/BcNmLoP.jpeg
/var/www/html/uploads/LrOjfHa.jpeg
/var/www/html/uploads/LmKdFgH.jpeg
/var/www/html/uploads/FgHyJuK.jpeg
/var/www/html/uploads/BcFvGtR.jpeg
/var/www/html/uploads/DvBnMcP.jpeg
/var/www/html/uploads/QwErTyU.jpeg
/var/www/html/uploads/NcVbOpQ.jpeg
/var/www/html/uploads/FeWcNzT.jpeg
/var/www/html/uploads/PwSaBcZ.jpeg
/var/www/html/uploads/FgHjKlM.jpeg
/var/www/html/uploads/JnKmLoP.jpeg
/var/www/html/uploads/PqAwSdE.jpeg
/var/www/html/uploads/LkMjNhB.jpeg
/var/www/html/uploads/ZtXcVbN.jpeg
/var/www/html/uploads/MqQwErT.jpeg
/var/www/html/uploads/AhVpDoS.jpeg
/var/www/html/uploads/PoGmHsR.jpeg
/var/www/html/uploads/JyGtFdS.jpeg
/var/www/html/uploads/QeRtYuI.jpeg
/var/www/html/uploads/JiRpKaW.jpeg
/var/www/html/uploads/VwPyLoR.jpeg
/var/www/html/uploads/HjGfSdA.jpeg
/var/www/html/uploads/TRWaPSB.jpeg
/var/www/html/uploads/UiJhYtG.jpeg
/var/www/html/uploads/EpSjZxM.jpeg
/var/www/html/uploads/PlKjHgF.jpeg
/var/www/html/uploads/b2c8e1f5.phtml
/var/www/html/uploads/EsKyLbQ.jpeg
/var/www/html/uploads/GQzVDrM.jpeg
/var/www/html/upload.php
...
ls -l /var/www/html/assets/reverse.elf
-rwxr-xr-x 1 www-data www-data 250 Feb 13 2024 /var/www/html/assets/reverse.elf
ls -l /var/www/html/assets/reverse.elf
-rwxr-xr-x 1 www-data www-data 250 Feb 13 2024 /var/www/html/assets/reverse.elf
-rwxr-xr-x 1 www-data www-data 250 Feb 13 2024 /var/www/html/assets/reverse.elf
investigator@ip-10-10-229-35:$ ^C
investigator@ip-10-10-229-35:$ exiftool /var/www/html/assets/reverse.elf
ExifTool Version Number : 11.88
File Name : reverse.elf
Directory : /var/www/html/assets
File Size : 250 bytes
File Modification Date/Time : 2024:02:13 00:26:28+00:00
File Access Date/Time : 2024:02:13 00:32:59+00:00
File Inode Change Date/Time : 2024:02:13 00:34:50+00:00
File Permissions : rwxr-xr-x
File Type : ELF executable
File Type Extension :
MIME Type : application/octet-stream
CPU Architecture : 64 bit
CPU Byte Order : Little endian
Object File Type : Executable file
CPU Type : AMD x86-64
investigator@ip-10-10-229-35:~$
investigator@ip-10-10-229-35:~$ md5sum /var/www/html/assets/reverse.elf
c6cbdba1c147fbb7239284b7df2aa653 /var/www/html/assets/reverse.elf
investigator@ip-10-10-229-35:~$ sha256sum /var/www/html/assets/reverse.elf
ee0ea8d8bc205c4e2e2cc9ff7ddb71dee22ac0a50c2042701d49e565e0821410 /var/www/html/assets/reverse.elf
3.1. To practice your skills with the
findcommand, locate all the files that the userbobcreated in the past 1 minute. Once found, review its contents. What is the flag you receive?
THM{0b1313afd2136ca0faafb2daa2b430f3}
investigator@ip-10-10-229-35:~$ find / -user bob -type f -cmin -1 > bob
investigator@ip-10-10-229-35:~$ cat bob | grep .txt
investigator@ip-10-10-229-35:~$ cat /var/tmp/findme.txt
THM{0b1313afd2136ca0faafb2daa2b430f3}
3.2. Extract the metadata from the
reverse.elffile. What is the file's MIME type?
application/octet-stream
investigator@ip-10-10-229-35:~$ exiftool /var/www/html/assets/reverse.elf
ExifTool Version Number : 11.88
File Name : reverse.elf
Directory : /var/www/html/assets
File Size : 250 bytes
File Modification Date/Time : 2024:02:13 00:26:28+00:00
File Access Date/Time : 2024:11:08 19:55:06+00:00
File Inode Change Date/Time : 2024:02:13 00:34:50+00:00
File Permissions : rwxr-xr-x
File Type : ELF executable
File Type Extension :
MIME Type : application/octet-stream
CPU Architecture : 64 bit
CPU Byte Order : Little endian
Object File Type : Executable file
CPU Type : AMD x86-64
3.3. Run the
statcommand against the/etc/hostsfile on the compromised web server. What is the fullModify Timestamp (mtime)value?
2020-10-26 21:10:44.000000000 +0000
investigator@ip-10-10-229-35:~$ stat /etc/hosts
File: /etc/hosts
Size: 221 Blocks: 8 IO Block: 4096 regular file
Device: ca01h/51713dInode: 49 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-11-08 19:31:25.108000000 +0000
Modify: 2020-10-26 21:10:44.000000000 +0000
Change: 2020-10-26 23:32:25.957900650 +0000
Birth: -
As we continue our investigation, we should focus on the system's users and groups. In doing so, we may uncover evidence of the attacker moving laterally or maintaining access throughout the system by exploiting additional vulnerabilities.
Within UNIX-like systems, the /etc/ directory is a central location that stores configuration files and system-wide settings. Specifically, when investigating user accounts, /etc/passwdcode> is a colon-separated plaintext file that contains a list of the system's accounts and their attributes, such as the user ID (UID), group ID (GID), home directory location, and the login shell defined for the user.
Let's view the user accounts on the affected system by reading the file:
investigator@ip-10-10-226-120:~$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
...
lxd:x:998:100::/var/snap/lxd/common/lxd:/bin/false
bob:x:1001:1001::/home/bob:/bin/bash
jane:x:1002:1002:Jane Walkers,103,9399499494,2029384958:/home/jane:/bin/bash
investigator:x:1003:1003:Investigator,1,1,1,1:/home/investigator:/bin/bash
postfix:x:113:120::/var/spool/postfix:/usr/sbin/nologin
b4ckd00r3d:x:0:1004::/home/b4ckd00r3d:/bin/sh
Attackers can maintain access to a system by creating a backdoor user with root permissions. We can leverage the cut and grep commands to identify this type of user account backdoor quickly. The following command extracts and displays all user accounts with the user ID (UID) of 0. The presence of a user with UID 0, other than the legitimate root user account, can quickly suggest a potential backdoor account.
investigator@ip-10-10-226-120:~$ cat /etc/passwd | cut -d: -f1,3 | grep ':0$'
root:0
b4ckd00r3d:0
In the above command, we first display the contents of the /etc/passwd file. We then take the contents and perform a cut action to extract only the first (username) and third (user ID) fields from each line, delimited (-d by the : character. We then use the grep command to extract specific entries containing :0, signifying a user ID of 0.
This, however, is not a foolproof method, as the backdoor account could have been created with legitimate user and group IDs. For further investigation, we can take a look at groups.
In Linux systems, certain groups grant specific privileges that attackers may target to escalate their privileges. Some important Linux groups that might be of interest to an attacker include:
.................
We can view all of the groups (and their respective group IDs) on the system by reading the /etc/groupcode> file:
investigator@ip-10-10-226-120:~$ cat /etc/group
root:x:0:
daemon:x:1:
bin:x:2:
sys:x:3:
adm:x:4:syslog,ubuntu,investigator
tty:x:5:syslog
...
backup:x:34:
operator:x:37:
list:x:38:
irc:x:39:
src:x:40:
...
bob:x:1001:
jane:x:1002:
investigator:x:1003:
postfix:x:120:
postdrop:x:121:
b4ckd00r3d:x:1004:
To determine which groups a specific user is a member of, we can run the following command:
investigator@ip-10-10-226-120:~$ groups investigator
investigator : investigator adm dialout cdrom floppy sudo audio dip video plugdev netdev lxd
To determine which groups a specific user is a member of, we can run the following command:
investigator@ip-10-10-226-120:~$ groups investigator
investigator : investigator adm dialout cdrom floppy sudo audio dip video plugdev netdev lxd
Alternatively, to list all of the members of a specific group, we can run the following command:
p>investigator@ip-10-10-226-120:~$ getent group admin
admin:x:116:
If multiple users are in a group (as seen above), their usernames will be listed in a comma-separated format in the entry.
To list all users in the sudo group, we can provide either the name "sudo" or the group ID, typically 27.
investigator@ip-10-10-226-120:~$ getent group 27
sudo:x:27:ubuntu,investigator
Checking user logins and activity is valuable for performing a real-time analysis of a compromised system. Fortunately, a couple of useful utilities and logs can assist us.
last and lastb
The last command is an excellent tool for examining user logins and sessions. It is used to display the history of the last logged-in users. It works by reading the /var/log/wtmp file, which is a file that contains every login and logout activity on the system. Similarly, lastb specifically tracks failed login attempts by reading the contents of /var/log/btmp, which can help identify login and password attacks.
investigator@ip-10-10-226-120:~$ last
investig pts/0 10.100.2.80 Fri Nov 8 22:52 still logged in
reboot system boot 5.4.0-1029-aws Fri Nov 8 22:50 still running
investig pts/1 10.10.101.34 Tue Feb 13 02:23 - crash (269+20:26)
investig pts/0 10.10.101.34 Tue Feb 13 02:16 - 02:22 (00:05)
reboot system boot 5.4.0-1029-aws Tue Feb 13 02:14 still running
jane pts/1 10.10.101.34 Tue Feb 13 00:36 - crash (01:37)
jane pts/1 10.10.101.34 Tue Feb 13 00:35 - 00:36 (00:01)
investig pts/0 10.10.101.34 Tue Feb 13 00:31 - crash (01:43)
reboot system boot 5.4.0-1029-aws Tue Feb 13 00:28 still running
ubuntu pts/0 10.13.46.43 Mon Feb 12 23:05 - crash (01:23)
reboot system boot 5.4.0-1029-aws Mon Feb 12 23:05 still running
ubuntu pts/0 10.13.46.43 Mon Feb 12 21:22 - crash (01:42)
reboot system boot 5.4.0-1029-aws Mon Feb 12 21:21 still running
...
reboot system boot 5.4.0-1029-aws Mon Feb 12 16:30 still running
ubuntu pts/0 10.13.46.43 Mon Feb 12 16:24 - crash (00:05)
ubuntu pts/1 10.13.46.43 Mon Feb 12 16:20 - crash (00:09)
ubuntu pts/0 10.13.46.43 Mon Feb 12 16:16 - 16:20 (00:04)
reboot system boot 5.4.0-1029-aws Mon Feb 12 16:11 still running
lastlog
Unlike the last command, which provides information about all user logins, the lastlog command focuses on a user's most recent login activity and reads from the /var/log/lastlogcode> file.
investigator@ip-10-10-226-120:~$ lastlog
Username Port From Latest
root **Never logged in**
...
Failed Login Attempts
In addition to lastb, there are other ways to view failed login attempts on Linux through specific log files. The /var/log/auth.log file (or /var/log/secure on some distributions like CentOS or Red Hat) contains records of authentication-related events, including both successful and failed login attempts.
who
The who command is a very straightforward command that can be used to display the users that are currently logged into the system. The output of this command can provide details such as the name of the user logged in, the terminal device used, the time that the session was established, idle activity, the process ID of the shell, and additional comments that may include details such as the initial command used to start the session.
investigator@ip-10-10-226-120:~$ who
investigator pts/0 2024-11-08 22:52 (10.100.2.80)
The /etc/sudoers file is a particularly sensitive configuration file within Unix-like systems. It determines which users possess sudo privileges, enabling them to execute commands as other users, typically the root user.
As a result, it can be a target for attackers seeking persistence. For instance, if an attacker can find a way to insert their user account (or one that they control) into the sudoers file, they could grant themselves elevated privileges without requiring authentication. Alternatively, they may alter existing entries to broaden their access.
For example, a line in a sudoers file might look like this:
investigator@ip-10-10-226-120:~$ sudo cat /etc/sudoers
[sudo] password for investigator:
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaultsenv_reset
...
More specifically, this line specifies:
..............................
With this configuration, Richard can execute ifconfig with elevated sudo privileges to manage network interfaces as necessary.
4.1. Investigate the user accounts on the system. What is the name of the backdoor account that the attacker created??
b4ckd00r3d
investigator@ip-10-10-226-120:~$ lastlog
Username Port From Latest
root **Never logged in**
daemon **Never logged in**
bin **Never logged in**
sys **Never logged in**
sync **Never logged in**
games **Never logged in**
...
bob pts/0 10.13.46.43 Mon Feb 12 19:00:00 +0000 2024
jane pts/1 10.10.101.34 Tue Feb 13 00:36:37 +0000 2024
investigator pts/0 10.100.2.80 Fri Nov 8 22:52:37 +0000 2024
postfix **Never logged in**
b4ckd00r3d **Never logged in**
4.2. What is the name of the group with the group ID of
46?
plugdev
investigator@ip-10-10-226-120:~$ getent group 46
plugdev:x:46:ubuntu,investigator
4.3. View the /etc/sudoers file on the compromised system. What is the full path of the binary that Jane can run as sudo?
/usr/bin/pstree
investigator@ip-10-10-226-120:~$ sudo cat /etc/sudoers
[sudo] password for investigator:
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaultsenv_reset
Defaultsmail_badpass
Defaultssecure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
rootALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudoALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
jane ALL=(ALL) /usr/bin/pstree
In the previous task, we identified a backdoor account that the attacker created and gained access to. However, we should take a step back and determine how the attacker got the privileges to create that account in the first place. To expand our investigation into the system's users and groups, we should also look into each user's personal directory, files, history, and configurations..
User home directories in Linux contain personalised settings, configurations, and user-specific data. These directories are typically located under the /home directory and are named after the corresponding usernames on the system. Recall viewing the /etc/passwd file and identifying various users and their home directories.
We can list out the home directories with a simple ls -l command:
investigator@ip-10-10-226-120:~$ ls -l /home
total 16
drwxr-xr-x 4 bob bob 4096 Feb 12 2024 bob
drwxr-xr-x 3 investigator investigator 4096 Feb 13 2024 investigator
drwxr-xr-x 4 jane jane 4096 Feb 13 2024 jane
drwxr-xr-x 5 ubuntu ubuntu 4096 Feb 12 2024 ubuntu
Hidden Files
Hidden files, identified by a leading dot in their filenames, often store sensitive configurations and information within a user's home directory. By default, we cannot list out these hidden files using ls. To view them, we need to provide the -a argument, which will include all entries starting with a dot.
To list out the hidden files within Jane's home directory, run:
investigator@ip-10-10-226-120:~$ ls -a /home/jane
. .. .bash_history .bash_logout .bashrc .cache .profile .ssh
Some common files that would be of interest during an investigation include:
................
Additionally, we can look at other files and directories of interest, like browser profiles and the .ssh directory.
The .ssh directory is a susceptible area containing configuration and key files related to SSH connections. The authorized_keyscode> file within the directory is critical because it lists public keys allowed to connect to a user's account over SSH.
If a malicious user gains unauthorised access to a system and wants to persistently access another user's account (for example, Jane's account) by adding their public key to the authorized_keys file, we can potentially uncover artefacts that hint at these actions.
First, navigate to the .ssh directory within Jane's home folder. From here, we can run an ls -al to list the contained files:
investigator@ip-10-10-226-120:~$ ls -al /home/jane/.ssh
total 20
drwxr-xr-x 2 jane jane 4096 Feb 12 2024 .
drwxr-xr-x 4 jane jane 4096 Feb 13 2024 ..
-rw-rw-rw- 1 jane jane 1136 Feb 13 2024 authorized_keys
-rw------- 1 jane jane 3389 Feb 12 2024 id_rsa
-rw-r--r-- 1 jane jane 746 Feb 12 2024 id_rsa.pub
Let's view the file to see if we can identify any unintended authorised public keys:
investigator@ip-10-10-226-120:~$ cat /home/jane/.ssh/authorized_keys
ssh-rsa [Redacted]
ssh-rsa A[Redacted]
investigator@ip-10-10-226-120:~$
Notice that there are two entries. The first belongs to Jane, as signified by the ending comment. However, the second entry appears to be related to an entirely different keypair with the comment "backdoor". The attacker was likely able to edit this file and append their own public key, allowing them SSH access as Jane.
We can further confirm this by returning to the stat command. By running it on the file, we can see that it was last modified around a similar timeframe to when we confirmed the attacker gained an initial foothold on the system.
investigator@ip-10-10-226-120:~$ stat /home/jane/.ssh/authorized_keys
File: /home/jane/.ssh/authorized_keys
Size: 1136 Blocks: 8 IO Block: 4096 regular file
Device: ca01h/51713dInode: 257561 Links: 1
Access: (0666/-rw-rw-rw-) Uid: ( 1002/ jane) Gid: ( 1002/ jane)
Access: 2024-11-08 23:42:25.784000000 +0000
Modify: 2024-02-13 00:34:16.005897449 +0000
Change: 2024-02-13 00:34:16.005897449 +0000
Birth: -
If we look back to the output of the ls -al command, we can identify the permission misconfiguration that made this possible:
investigator@ip-10-10-226-120:~$ ls -al /home/jane/.ssh/authorized_keys
-rw-rw-rw- 1 jane jane 1136 Feb 13 2024 /home/jane/.ssh/authorized_keys
As identified by the third rwpermissions, this file is world-writable, which should never be the case for sensitive files. Consequently, by exploiting this misconfiguration, the attacker gained unauthorised SSH access to the system as if they were Jane.
5.1. View Jane's
.bash_historyfile. What flag do you see in the output?
THM{f38279ab9c6af1215815e5f7bbad891b}
investigator@ip-10-10-226-120:/home/jane$ sudo cat .bash_history
[sudo] password for investigator:
whoami
groups
cd ~
ls -al
find / -perm -u=s -type f 2>/dev/null
/usr/bin/python3.8 -c 'import os; os.execl("/bin/sh", "sh", "-p", "-c", "cp /bin/bash /var/tmp/bash && chown root:root /var/tmp/bash &
& chmod +s /var/tmp/bash")'
ls -al /var/tmp
exit
useradd -o -u 0 b4ckd00r3d
exit
THM{f38279ab9c6af1215815e5f7bbad891b}
investigator@ip-10-10-226-120:/home/jane$
5.2. What is the hidden flag in Bob's home directory?
THM{f38279ab9c6af1215815e5f7bbad891b}
investigator@ip-10-10-226-120:/home/bob$ ls -la
total 36
drwxr-xr-x 4 bob bob 4096 Feb 12 2024 .
drwxr-xr-x 6 root root 4096 Feb 12 2024 ..
-rw-r--r-- 1 bob bob 220 Feb 12 2024 .bash_logout
-rw-r--r-- 1 bob bob 3771 Feb 12 2024 .bashrc
drwx------ 2 bob bob 4096 Feb 12 2024 .cache
...
-rw-rw-r-- 1 bob bob 38 Feb 12 2024 .hidden34
-rw-rw-r-- 1 bob bob 0 Feb 12 2024 .hidden35
-rw-rw-r-- 1 bob bob 0 Feb 12 2024 .hidden36
-rw-rw-r-- 1 bob bob 0 Feb 12 2024 .hidden37
...
-rw-rw-r-- 1 bob bob 0 Feb 12 2024 .hidden7
-rw-rw-r-- 1 bob bob 0 Feb 12 2024 .hidden8
-rw-rw-r-- 1 bob bob 0 Feb 12 2024 .hidden9
drwxrwxr-x 3 bob bob 4096 Feb 12 2024 .local
-rw-r--r-- 1 bob bob 807 Feb 12 2024 .profile
-rw-rw-r-- 1 bob bob 66 Feb 12 2024 .selected_editor
investigator@ip-10-10-226-120:/home/bob$ cat .hidden34
THM{6ed90e00e4fb7945bead8cd59e9fcd7f}
5.3. Run the
statcommand on Jane'sauthorized_keysfile. What is the full timestamp of the most recent modification?
2024-02-13 00:34:16.005897449 +0000
investigator@ip-10-10-226-120:/home/jane/.ssh$ ls -la
total 20
drwxr-xr-x 2 jane jane 4096 Feb 12 2024 .
drwxr-xr-x 4 jane jane 4096 Feb 13 2024 ..
-rw-rw-rw- 1 jane jane 1136 Feb 13 2024 authorized_keys
-rw------- 1 jane jane 3389 Feb 12 2024 id_rsa
-rw-r--r-- 1 jane jane 746 Feb 12 2024 id_rsa.pub
investigator@ip-10-10-226-120:/home/jane/.ssh$ stat authorized_keys
File: authorized_keys
Size: 1136 Blocks: 8 IO Block: 4096 regular file
Device: ca01h/51713dInode: 257561 Links: 1
Access: (0666/-rw-rw-rw-) Uid: ( 1002/ jane) Gid: ( 1002/ jane)
Access: 2024-11-08 23:42:25.784000000 +0000
Modify: 2024-02-13 00:34:16.005897449 +0000
Change: 2024-02-13 00:34:16.005897449 +0000
Birth: -
Another area to look at within our compromised host's file system is identifying binaries and executables that the attacker may have created, altered, or exploited through permission misconfigurations.
We can use the find command on UNIX-based systems to discover all executable files within the filesystem quickly:
investigator@10.10.226.120:~$ find / -type f -executable 2> /dev/null
/snap/core/16574/etc/init.d/single
/snap/core/16574/etc/init.d/ssh
/snap/core/16574/etc/init.d/ubuntu-fan
/snap/core/16574/etc/init.d/udev
...
The following command recursively traverses the file system starting from the root directory and lists any executable file it finds. Note that this provides a huge amount of output. As such, it's often a good idea to limit the scope of the search through additional parameters.
Once we identify an executable or binary that we want to investigate further, we can perform metadata analysis as we have done previously, performing integrity checking on it using checksums or inspecting its human-readable strings and raw content.
The strings command is valuable for extracting human-readable strings from binary files. These strings can sometimes include function names, variable names, and even plain text messages embedded within the binary. Analysing this information can help responders determine what the binary is used for and if there is any potential malicious activity involved. To run the strings command on a file, we need to provide the file as a single argument:
user@tryhackme$ fstrings example.elf
Like the integrity checking we performed earlier, debsums is a command-line utility for Debian-based Linux systems that verifies the integrity of installed package files. debsums automatically compares the MD5 checksums of files installed from Debian packages against the known checksums stored in the package's metadata.
If any files have been modified or corrupted, debsums will report them, citing potential issues with the package's integrity. This can be useful in detecting malicious modifications and integrity issues within the system's packages. We can perform this check on the compromised system by running the following command:
investigator@10.10.226.120:~$ sudo debsums -e -s
debsums: changed file /***/******* (from sudo package)
In the above command, we provide the -e flag to only perform a configuration file check. In addition, we provide the -s flag to silence any error output that may fill the screen.
SetUID (SUID) and SetGID (SGID) are special permission bits in Unix operating systems. These permission bits change the behaviour of executable files, allowing them to run with the privileges of the file owner or group rather than the privileges of the user who executes the file.
If a binary or executable on the system is misconfigured with an SUID or SGID permission set, an attacker may abuse the binary to break out of a restricted (unprivileged) shell through legitimate but unintended use of that binary. For example, if the PHP binary contained a SUID bit to run as root, it's trivial for an attacker to abuse it to run system commands through PHP's system exec functions as root.
Identifying SetUID (SUID) binaries on a Linux system involves examining the file permissions and explicitly looking for executables with the SetUID bit set. We can return to the find command to retrieve a list of the SetUID binaries on the system:
investigator@10.10.226.120:~$ find / -perm -u=s -type f 2>/dev/null
...
/usr/bin/fusermount
/usr/bin/python3.8
/usr/bin/at
/usr/bin/mount
/var/tmp/bash
/mnt/usb/lib/dbus-1.0/dbus-daemon-launch-helper
...
Specifically, the above command looks for files where the user permission has the SUID bit set (-u=s).
Much of the output here is expected as these binaries require the SUID bit and are not vulnerable. However, two of these results stand out. Firstly, Python should never be given SUID permission, as it is trivial to escalate privileges to the owner. Additionally, any SUID binaries in the /tmp or /var/tmp directory stand out as these directories are typically writable by all users, and unauthorised creation of SUID binaries in these directories poses a notable risk.
We can investigate further by looking in Jane's bash history for any commands related to Python or bash:
investigator@10.10.226.120:~$ sudo cat /home/jane/.bash_history | grep -B 2 -A 2 "python"
ls -al
find / -perm -u=s -type f 2>/dev/null
/usr/bin/python3.8 -c 'import os; os.execl("/bin/sh", "sh", "-p", "-c", "cp /bin/bash /var/tmp/bash && chown root:root /var/tmp/bash && chmod +s /var/tmp/bash")'
ls -al /var/tmp
/var/tmp/bash -p
exit
From the output, we've discovered evidence of Jane's user account identifying SUID binaries with the find command and abusing the SUID permission on the Python binary to run system commands as the root user. With this level of command execution, the attacker was able to create a copy of the /bin/bash binary (the Bash shell executable) and place it into the /var/tmp folder. Additionally, the attacker changed the owner of this file to root and added the SUID permission to it (chmod +s).
After making an SUID copy of /bin/bash, the attacker elevated to root by running /var/tmp/bash -p. We can further verify the bash binary by performing an integrity check on the original:
investigator@10.10.226.120:~$ investigator@10.10.226.120:~$ md5sum /var/tmp/bash
7063c393************d3b340f1ad2c /var/tmp/bash
investigator@10.10.226.120:~$ md5sum /bin/bash
7063c393************d3b340f1ad2c /bin/bash
The output above shows that the two binaries are identical, further enhancing our understanding of the attacker's actions to escalate to root.
6.1. Run the
debsumsutility on the compromised host to check only configuration files. Which file came back as altered?
/etc/sudoers
investigator@ip-10-10-226-120:/etc$ sudo debsums -c -e
[sudo] password for investigator:
/etc/sudoers
6.2. What is the
md5sumof the binary that the attacker created to escalate privileges to root?
7063c3930affe123baecd3b340f1ad2c
investigator@ip-10-10-226-120:/etc$ md5sum /var/tmp/bash
7063c3930affe123baecd3b340f1ad2c /var/tmp/bash
A rootkit is a type of malicious set of tools or software designed to gain administrator-level control of a system while remaining undetected by the system or user. The term "rootkit" derives from "root", the highest-level user in Unix-based systems, and "kit", which typically refers to a set of tools used to maintain this access.
Rootkits are particularly dangerous because they can hide their presence on a system and allow attackers to maintain long-term access without detection. Attackers can also use them to stage other malicious activities on the target, exfiltrate sensitive information, or command and control the compromised system remotely.
Fortunately, we can use some automated tools on UNIX-based systems to help detect and remove rootkits.
Chkrootkit (Check Rootkit) is a popular Unix-based utility used to examine the filesystem for rootkits. It operates as a simple shell script, leveraging common Linux binaries like grep and strings to scan the core system programs to identify signatures. It can use the signatures from files, directories, and processes to compare the data and identify common patterns of known rootkits. As it does not perform an in-depth analysis, it is an excellent tool for a first-pass check to identify potential compromise, but it may not catch all types of rootkits.
Additionally, modern rootkits might deliberately attempt to identify and target copies of the chkrootkit program or adopt other strategies to evade its detection.
We can access the chkrootkit on the compromised system using our mounted binaries. We can perform a simple check by running chkrootkit:
investigator@10.10.226.120:~$ sudo chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `crontab'... not infected
Checking `date'... not infected
...
This scan will produce a large output, but it indicates the results of various checks for known rootkit-related files or patterns.
https://rkhunter.sourceforge.net/
RKHunter (Rootkit Hunter) is another helpful tool designed to detect and remove rootkits on Unix-like operating systems. It offers a more comprehensive and feature-rich rootkit detection check compared to chkrootkit. RKHunter can compare SHA-1 hashes of core system files with known good ones in its database to search for common rootkit locations, wrong permissions, hidden files, and suspicious strings in kernel modules. It is an excellent choice for a more comprehensive assessment of the affected system.
Because rkhunter leverages a live database of known rootkit signatures, checking for database updates (rkhunter --update) before running in the field is crucial. Because this system is isolated, we won't be able to run a database update here, but the latest version was acquired before mounting our tools to the system.
To perform a simple scan with rkhunter, we can run the following command:
investigator@10.10.226.120:~$ sudo rkhunter -c -sk
[ Rootkit Hunter version 1.4.6 ]
Checking system commands...
Performing 'strings' command checks
Checking 'strings' command [ OK ]
Performing 'shared libraries' checks
Checking for preloading variables [ None found ]
...
This check will take some time to run but we have bypassed the user interaction prompts with the -sk argument. Afterwards, you will receive a system check summary detailing what was found.
7.1. Run chkrootkit on the affected system. What is the full path of the
.shfile that was detected?
/var/tmp/findme.sh
investigator@ip-10-10-226-120:/$ sudo chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
...
Searching for common ssh-scanners default files... nothing found
Searching for Linux/Ebury - Operation Windigo ssh... nothing found
Searching for 64-bit Linux Rootkit ... nothing found
Searching for 64-bit Linux Rootkit modules... nothing found
Searching for Mumblehard Linux ... * * * * * /var/tmp/findme.sh
Possible Mumblehard backdoor installed
Searching for Backdoor.Linux.Mokes.a ... nothing found
...
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... chkproc: nothing detected
chkdirs: nothing detected
Checking `rexedcs'... not found
Checking `sniffer'... lo: not promisc and no packet sniffer sockets
eth0: PACKET SNIFFER(/usr/lib/systemd/systemd-networkd[2918])
Checking `w55808'... not infected
Checking `wted'... 1 deletion(s) between Mon Feb 12 20:03:27 2024 and Mon Feb 12 20:26:45 202
4
2 deletion(s) between Mon Feb 12 20:27:22 2024 and Mon Feb 12 20:51:02 2024
2 deletion(s) between Mon Feb 12 21:22:31 2024 and Mon Feb 12 23:05:01 2024
1 deletion(s) between Mon Feb 12 23:05:27 2024 and Tue Feb 13 00:28:29 2024
Checking `scalper'... not infected
7.2. Run rkhunter on the affected system. What is the result of the
(UID 0) accountscheck?
Warning
investigator@ip-10-10-226-120:~$ sudo rkhunter --check --sk --rwo | grep UID
[sudo] password for investigator:
investigator@ip-10-10-226-120:~$ sudo rkhunter --check --sk --rwo | grep UID
Warning: Account 'b4ckd00r3d' is root equivalent (UID = 0)
Congratulations! You made it to the end of this exploration into Linux file system forensic analysis. Our investigation covered several topics, including examining digital artefacts, system logs, users, and file structures. Remember, the analysis and identification of compromised system artefacts represent only one phase of the incident response process—the following rooms in the module expand on other equally crucial areas for performing live forensics on Unix-based systems in the field.
Additionally, if you enjoyed exploring the methodologies of identifying system vulnerabilities and want more insight into hardening these systems, check out the Bulletproof Penguin room! To test your skills in identifying persistence mechanisms on Linux machines, be sure to attempt the Tardigrade challenge!
8.1. Click and continue learning!
No answer needed
Keep learning, keep growing!
| Date | Streak | All Time | All Time | Monthly | Monthly | Points | Rooms |
|---|---|---|---|---|---|---|---|
| WorldWide | Brazil | WorldWide | Brazil | Completed | |||
| November 8, 2024 | 186 | 1,266ª | 28ª | 4,182ª | 59ª | 54,318 | 409 |
Thank you for coming. Hope to learn together again!!