Linux forensics - Disgruntled

Linux logs and suspicious binary exmination

By Ren Sie

Refer to Disgruntled for the challenge room on TryHackMe

Task

An IT employee from CyberT has been arrested for running a phishing operation. CyberT has requested our assistance to determine if this individual compromised any of their assets.

Nothing suspicious... So far

Here’s the machine that our dissatisfied IT user last worked on. Please assess if there are any concerns for our client. My suggestion: Review the privileged commands that were executed. This will help you begin your investigation.

The user installed a package on the machine using elevated privileges. What is the full COMMAND?

All user authentication activities on a Linux host are recorded in the auth.log file, found at /var/log/auth.log. We can use the grep tool to search for the keywords "COMMAND" and "install," as the question mentioned installing a package.

cat /var/log/auth.log* | grep -i 'COMMAND.*install'

Note: The ‘.*’ in the regex pattern allows for any characters (including none) to appear between “COMMAND” and “install.

What was the present working directory when the previous command was run?

Refer to the previous screenshot for the present working directory (PWD) at the time the install command was executed.

Let’s see if you did anything bad

Please continue your assessment. Our dissatisfied IT user was only supposed to install a service on this computer, so check for any commands that are unrelated to that task.

Which user was created after the package from the previous task was installed?

There are two commands to add a user in Linux: adduser and useradd. Both commands can be found in the same log file (auth.log), so we will update the keyword to include either adduser or useradd.

cat /var/log/auth.log* | grep -i 'COMMAND.*adduser'

A user was then later given sudo priveleges. When was the sudoers file updated?

We will continue to examine the same log file (auth.log), but this time we will change the grep keyword to 'sudo', since the question relates to the sudoer file.

Two users used visudo to edit the sudoer file. Referring to the previous screenshot, we know that the compromised user, cybert, installed the package and added the user. Therefore, it is highly likely that this same user edited the sudoer file to grant it-admin user privileges.

Note: visudo is a command that edits the sudoers file.

cat /var/log/auth.log* | grep -i 'COMMAND.*sudo'

A script file was opened using the "vi" text editor. What is the name of this file?

We will continue to examine the same log file (auth.log) for any commands that executed vi, as the question suggests. The output indicates that a script file (.sh) was opened with vi.

cat /var/log/auth.log* | grep -i 'vi'

Bomb has been planted. But when and where?

The bomb.sh file is a significant concern. While the existence of this file raises suspicion, we still need to investigate its origin and contents. Unfortunately, the file is no longer present.

What is the command used that created the file bomb.sh?

By analyzing the previous screenshot, we see that bomb.sh is stored in the local directory of the it-admin user. Therefore, we need to navigate to this user's local directory and examine the command history.

/home/it-admin# cat .bash_history

Note: The command downloads the file (bomb.sh) from the IP address 10[.]10[.]158[.]38 on port 8080 and saves it as bomb.sh. Because the command curl does not use sudo or any privileged access, so it typically won’t generate entries in /var/log/auth.log

The file was renamed and moved to a different directory. What is the full path of this file now?

We know that vi can edit and save files to different locations, so we can begin by investigating the .viminfo file, which records the history of any activities with vi. From the output, we can see that there is a command history showing that the suspicious file was saved to a new location with a different name.

Note: We will look for this file in the same user’s directory, as we did in the previous question.

When was the file from the previous question last modified?

To find the last modification timestamp, we first need to navigate to the file's location and use the ls command with the --full-time option.

ls -l --full-time os-update.sh

What is the name of the file that will get created when the file from the first question executes?

To understand the function of the script file, we can investigate its content using the cat command. Based on the screenshot of the script content, we can see that the script uses the echo command to output data into the file we are looking for.

cat os-update.sh

Following the fuse

We have both a file and a motive. The key question now is: how was this file intended to be executed? It’s likely that he planned for it to run at some point.

At what time will the malicious file trigger?

At this point, we know that the suspicious file is a logic bomb and is set to be executed at some point. To determine the execution date, we can examine the cron file, which documents scheduled commands in Linux.

By examining the output, we know that the script will be executed daily at 8 in the morning as the root user.

cat /etc/crontab

Conclusion

Thanks to your insights, we now have a clearer understanding of the intentions of our dissatisfied IT employee. We’ve identified that he downloaded a pre-made script designed to delete all files related to the installed service if the user hasn’t logged in within the last 30 days. This is a classic example of a "logic bomb." Impressive work on your second day! Please let Sophie know I recommended a raise for you.

Share: X (Twitter) Facebook LinkedIn