Linux Incident Surface TryHackMe Writeup | THM Detailed Walkthrough | SuNnY

The Linux Incident Surface refers to all potential points within a Linux system where incidents, such as security breaches or malicious activities, could occur or leave traces. This includes log files, running processes, network connections, and system configurations that attackers may exploit or alter. The incident surface overlaps with the Linux Attack Surface, which comprises the entry points attackers could use to compromise the system.

In this introductory guide, we will explore key incident points from a defensive perspective, focusing on how to identify and interpret signs of an attack. By understanding these attack-related activities, defenders can better translate them into actionable insights, strengthening the system’s overall security posture.

Kudos to The Creators of this Room :

Room Type :

Free Room
Anyone can deploy virtual machines in the room
(without being subscribed)!

Task 1 : Introduction

It’s adviced to give Task 1 a good read .

Task 2 : Lab Connection

This Task is a VM based Task

Let’s Fire up the Machine ! 🔥

We’re provided with the credentials inside the Task 2 module

All the important files are place in /home/activities/processes directory as mentioned in the module .

After starting the VM , an AttackBox on TryHackMe is deployed

Task 2 — Question 1 : Connect with the lab. How many files and folders are in the /home/activities/processes directory?

Let’s open the Terminal and change the Directory to /home/activities/processes

The Question asks us to check the number of files and folders inside the directory → /home/activities/processes

By listing the above directory we see files by executing the command → ls

We find 3 files inside -

netcom
simple.c
suspicious

Task 2 Question 1 Answer :

3

Task 3 : Linux Incident Surface — An Overview

Task 3— Question 1: Linux Incident Surface — An Overview

In this task , The Linux Attack Surface refers to the collection of entry points in a Linux system that could be exploited by attackers. These include open ports, running services, vulnerable software, and network communications. Reducing this surface involves minimizing exposed services, patching vulnerabilities, and controlling user interactions to limit potential risks.

In contrast, the Linux Incident Surface involves areas where security incidents are detected, managed, and responded to after a compromise. Key areas include system logs, network traffic, and running processes. Monitoring and understanding this surface help in mitigating damage and recovering from attacks.

It's recommended to thoroughly read this module before proceeding to the next.

Task 4 : Processes and Network Communication

Task 4 — Question 1 : What is the remote IP to which the process netcom establishes the connection?

To solve this task, follow these steps :

1. Become the Root User ( This is Important )

To begin, change to the root user to ensure you have the necessary privileges:

Since this room involves working with the TryHackMe attackbox ,
Let’s set a password for root before switching to super user

sudo passwd root

Now Let’s set the password to 123 when prompted — This can be anything

Next Let’s Switch to Super User by entering the same password set above →

sudo su

2. Compile and Run the simple.c Program

You need to compile the simple.c program and run it to observe its behavior:

( Check the GIF snippet below for a clear process )

Since we have switched to root in the previous task —
it’s important to change directory to /home/activities/processes before proceeding :

gcc simple.c -o /tmp/simple
/tmp/simple

gcc simple.c -o /tmp/simple

This part compiles the C program simple.c and creates an executable named simple in the /tmp/ directory.

• gcc is the GNU C Compiler used to compile C code.
• simple.c is the source file containing the C program.
• -o /tmp/simple specifies the output file, which will be an executable located at /tmp/simple.

This command creates the executable file /tmp/simple.

/tmp/simple

This part runs the newly created executable /tmp/simple.

• By executing this, the compiled program will be launched, and whatever behavior is defined in simple.c (such as printing output, performing computations, or interacting with the system) will take place.

it’s very important to Leave this process running.

Yes — This is a simple program should not be terminated

3. Investigate Running Processes

Open a new terminal while the simple program is still running and list all running processes to locate the one associated with the compiled program:

ps aux | grep simple

We have to Look for the process related to /tmp/simple and note its Process ID (PID).

PID we found and this could be different for you →

PID - 2233

4. Use lsof to Investigate Process Files

To identify which files and resources the process is using, run the lsof command with the PID you found in the previous step:

lsof -p <PID>

This will list all open files and resources used by the process.

Next up is using the command lsof with the PID we found above →

5. Investigate Network Connections for the netcom Process

Now, execute the netcom process located in /home/activities/processes:

./netcom

This executes netcom , let this program run like simple , the whole objective is to gather the PID of this running program

6. Confirm that the netcom Process is Running

Once the process is running, confirm its presence by searching for it:

ps aux | grep netcom

By executing the above command we will find the PID of the netcom process from the output.

7. Examine Network Connections for the Process Using lsof

To investigate if the netcom process has established any network connections, use the lsof command to view network activity associated with the PID:

lsof -i -P -n | grep <PID>

This will display the remote IP address to which the netcom process is connecting, along with port information.

( Make sure to switch to root account )

We got an IP address and a port number from the Output

netcom 2388 root 3u IPv4 46098 0t0 TCP 10.10.156.36:47980->68.53.23.246:443 (SYN_SENT)

8. Use osquery to Further Investigate Network Connections

For deeper analysis, you can use osquery to find more details about the process and its network connections. Start osquery:

osqueryi

Run the following query to examine the sockets and network connections for the process:

SELECT pid, fd, socket, local_address, remote_address 
FROM process_open_sockets WHERE pid = <PID>;

This will show the local and remote IP addresses associated with the process.

By following these steps, you will be able to identify and investigate the network connections made by the netcom process, including the remote IP address it connects to.

We found the Same IP address here

Task 4 is now Done

Task 5 : Persistence

Task 5 — Question 1 : What is the default path that contains all the installed services in Linux?

The default path that contains all installed services in Linux is typically:

• /etc/systemd/system/ for system-wide services created by the user or administrator.

Answer for Task 5 Question 1 :

/etc/systemd/system/

Task 5 Question 2 : Which suspicious service was found to be running on the host?

According to the Task 5 module , The suspicious service found running on the host is called labeled as → “suspicious.service.” This service is created to execute a malicious script and is configured to restart automatically on system failure, allowing the attacker to maintain persistent access to the compromised system.

With our results after listing the contents of the directory benign.service , we found that benign.service is similar to the suspicious.service

Answer to Task 5 Question 2 :

benign.service

Task 5 — Question 3 : What process does this service point to?

By checking the contents of benign.service we find interesting information

Answer to Task 5 Question 3 can be found under the service tag :

benign

Task 5 — Question 4 : Before getting this service stopped on 11th Sept, how many log entries were observed in the journalctl against this service?

According to the Task 5 module we find this piece of info →

There are total 7 entries , Before getting this service stopped on 11th Sept

Answer to Task 5 Question 4 →

7

Task 5 is now successfully completed !

Task 6 : Footprints on Disk

Task 6 — Question 1 : Create a suspicious Debian package on the disk by following the steps mentioned in the task. How many log entries are observed in the dpkg.log file associated with this installation activity?

To answer the question about how many log entries are observed in the dpkg.log file associated with the installation activity, follow the steps below:

Step-by-Step Solution

1. Creating the Suspicious Debian Package

In the first step, you create a directory to organize the files and structure necessary for building the Debian package.

Let’s Create the package directory:

mkdir malicious-package

cd malicious-package

mkdir DEBIAN

2. Next We are going to Create the control file:

1. Use a text editor to create a file called control inside the DEBIAN folder.
2. And Adding the following content to the file :

Package: malicious-package
Version: 1.0
Section: base
Priority: optional
Architecture: all
Maintainer: attacker@test.com
Description: This is a malicious Package

We are going to use nano Text editor and then Save the file as → control

3. Add the Malicious Script

Create a postinst script file inside the DEBIAN folder:

Let’s also use nano for this one and create a file inside folder DEBIAN named → postinst

Add the following content to the postinst script:

#!/bin/bash
# Malicious post-installation script
# It will run this script after installation

# Print a suspicious message - for demonstration
echo "something suspicious"

Save the file as name postinst .

we now have 2 files named → control and postinst

4. Make the Script Executable

Now Let’s Change the permission of the script postinst to make it executable:

chmod 755 malicious-package/DEBIAN/postinst

4. Build the Package

Building the .deb package using dpkg-deb:

dpkg-deb --build malicious-package

To build the full package we have to move two directories back to the present one , in order to move out of the malicious-package folder to build it to .deb file

5. Install the Package

Time to Install the package using the following command:

dpkg -i malicious-package.deb

6. Check dpkg.log for Entries

Once we have installed the package , now let’s check the log entries in the dpkg.log file by using the following command:

cat /var/log/dpkg.log | grep “malicious-package”

This command will filter the log to only show entries related to the package installation.

We find 6 entries in the log file →

(1)  2024-09-22 22:17:06 install malicious-package:all <none> 1.0
(2)  2024-09-22 22:17:06 status half-installed malicious-package:all 1.0
(3)  2024-09-22 22:17:06 status unpacked malicious-package:all 1.0
(4)  2024-09-22 22:17:06 configure malicious-package:all 1.0 1.0
(5)  2024-09-22 22:17:06 status half-configured malicious-package:all 1.0
(6)  2024-09-22 22:17:06 status installed malicious-package:all 1.0

We have solved Task 6 Question 1

Answer for Task 6 Question 1

6

We have found the answer to our First Question for Task 6 but we will also do the last step to verify the number of Log entries by grepping the malicious-package folder and counting the wordlist

7. Count the Log Entries

1. To count the number of log entries for the package, use the following command:

cat /var/log/dpkg.log | grep “malicious-package” | wc -l

This command will return the number of log entries associated with the installation of the malicious package.

This process will provide you with the number of log entries observed in the dpkg.log file related to the installation of the suspicious Debian package.

We have found the similar answer for the Question 1

Answer for Task 6 Question 1 :

6

Task 6 — Question 2 : What package was installed on the system on the 17th of September, 2024?

To investigate and identify suspicious installed packages, particularly one installed on the 17th of September 2024, follow these steps:

1. List All Installed Packages

• Use dpkg -l to list all the installed packages on the system. This command will display all installed packages and their versions. You can filter through this list to spot any suspicious or unknown packages.

Command:

dpkg -l

This shows the package name, version, and status. If you already know the name of the suspicious package, you can look for it here.

Also we can use the command to get specific result →

dkpg -l | grep malicious 

2. Check Installation Logs in dpkg.log

• The /var/log/dpkg.log contains the history of package installations and removals. Using grep, you can filter out the installation events that occurred on a specific date. This will help pinpoint packages installed on a particular day, such as September 17, 2024.

Command:

grep “ install “ /var/log/dpkg.log | grep 2024–09–17

This command will list all packages that were installed on the 17th of September 2024.

• We have Example output shared to us inside the Task 6 module and it might look like this :

2024–09–17 15:21:47 install malicious-package:amd64 <none> 1.0

In this case, the suspicious package installed on that date is malicious-package.

We have Found the answer to Task 6 Question 2

2024-09-17 10:45:50 install c2comm:all <none> 1.0

Answer to Task 6 Question 2 →

c2comm

Task 6 is now Solved !!

Task 7 : Linux Logs

Task 7 Question 1 : Examine the auth.log files. Which user attempted to connect with SSH on 11th Sept 2024?

We need to check the /var/log/ for the auth file and check the entries of the auth log to check for the SSH login →

Now we have to check for the SSH logins
we can filter the above command using a grep flag with SSH to show results

on exploring the /var/log directory we found 3 files —

auth.log
auth.log.1
auth.log.2.gz

After checking the auth.log we find the other file auth.log.1 is of interest to us

Using the below command we can grep all the entries for SSH login to find our user name

grep ssh /var/log/auth.log.1

We solve our first Question for Task 7

Answer for Task 7 — Question 1

saqib

Task 7 Question 2 : From which IP was this failed SSH connection attempt made?

Further using the grep command we can view the full connection log for the SSH of saqib user

We found the answer to our Question 2 for Task 7 as well

Answer for Task 7 Question 2 :

10.11.75.247

Task 7 is now complete !!

Task 8 : Conclusion

We have now successfully done this room

Creating detailed write-ups like this takes time and effort, and by following me on Medium, you’ll help keep me inspired and motivated to continue sharing valuable content.
If you enjoyed this article, you to follow and notify via email updates to get more insights on TryHackMe future rooms !

Room Pwned !! Congratulations !!

Hope you have enjoyed this room as much i did

if you want to get the latest Try Hack Me writeups delivered go ahead and follow me on Medium and also hit the notify via email

Let’s Connect on Linkedin → https://linkedin.com/in/sunnysinghverma

You can also add me Respect on — Hack The Box if you want i would really appreciate it :)

https://app.hackthebox.com/users/1585635

My TryHackMe Profile Page →

https://tryhackme.com/p/SuNnY

if you did you can add a clap to this article to let me know and if you loved this article you can click clap icon upto 50 times to let me know and that will make my day 🤗
You can also follow me on medium to get more articles about CTFs and Cybersecurity in the near Future but don’t forget to hit that email notification icon right next to the follow me button

Thank you !
SuNnY