Blended Two Machines and Its Solution

I realized that I haven’t solved the machine-challenge for a long time. And I realized that I missed a lot.

That’s why I couldn’t get up to speed and decided to blend the two machines and write you a Walkthrough.

A blueteamlabs.online machine

and a cyberdefenders machine

When solving a machine, we will use a disk-based data analysis and forensic focused tool such as autopsy or FTK imager.

When solving a machine, we will use inspection tools such as Volatility and Wireshark.

Actually, I’m going to try to solve the two machines into a single scenario.

Let me first start by describing the scenario.

For the SAM machine I have sysmon logs, network traffic and a memory dump.

For the Azurepot machine, I have snapsots and memory dump of the drive.

So I have three files:

– sdb.vhd.gz — VHD of the main drive obtained through an Azure disk snapshot
– ubuntu.20211208.mem.gz — Dump of memory using Lime
– uac.tgz — Results of UAC running on the system

((I showed the file sizes, you can go to cyberdefenders from the links I shared above and download the zip, the password is also saved there):))

For the SAM machine, I used blueteamlab.online’s own virtual machine.

All the files I need are here:

My WINADMIN.rar memory ram image appears to be what the others already are.

This Ubuntu Linux honeypot was put online in Azure in early October to watch what happens with those exploiting CVE-2021–41773.

On the AzurePot machine,the scenario is a Linux honeypot was placed online in Azure and attackers exploited the machine using CVE-2021–41773 vulnerability.

Linux Honeypot: This is a specific type of honeypot that is set up using a Linux operating system. Its purpose is to attract malicious actors and capture their activities, allowing security professionals to study and analyze their tactics, techniques, and procedures.

She gave a little hint:

“Initially, there was a large number of crypto miners that hit the system. You will see one cron script meant to remove files named kinsing in /tmp. This was a way of preventing these miners so more interesting things could occur.”

Now, using the three files I have on a honeypot, I will first check what has been done, then I will find a script that runs every minute for cleaning purposes. After that I will find the malware files and collect their hashes.
I will find the C2s that Malware communicates with.

On the SAM machine, we will collect details of C2 (Command and Control) servers, malware, and compromised files using the network images we have.

Let’s start!!

First I will be getting the list of all the process that were running on the machine from memory image

I have all the list of the processess that were runnig on the system.

In the first lines, I can see normal windows processes and their chield parent child relationship.

As I scrolled down, it was the running powershell processes that caught my attention. And be careful with process ids.

Powershell with 3888 initiated calls another powershell.This is not a typical behavior and not expected.

I’m copying we should use this as a river pivot.3888. I will look for this id in the sysmon log file. It’s a json file and reads perfectly fine. I saw the first event when I called Find in the json file and searched for the relevant id.

I saw the related event in Record 768 and also caught the parent process calling this process. So this is mshta.exe that starts powershell.
How this exe download is also seen in the event.

And I can see an encoded command was executed right so using hidden window .

The coded command made me suspicious and I got this code. It was so long that I had a hard time copying it.

I tried to decode base64 code in terminal because my machine could not access internet.

It seems that the decode state is also obsufucate. Let this stay here for now.

Let’s go to other Powershell process id- 5056

Look what we saw when we went to this id.

Bingo!!

But don’t get too excited. We haven’t investigated whether this is really an http connection yet.

dest=172.16.0.5:80

src=172.16.0.4:50055

Let’s go to our pcap capture to verify.

Statistics don’t lie.

But let’s verify anyway:

I guess we can call it Bingo now. Ports are correct. The IPs are correct and we can see the outgoing SYN packets.

But when I saw TCP Stream , I got depressed.

Looking at this stream, all I understand is:
related to an executable some executable is getting transferred right so this is a typical behavior of a reverse shell.

So 172.16.0.5 starts a reverse shell on the victim’s machine.
I should verify this in volatility as well:

I checked the network activities with my suspected IP and yes I see the victim machine IP here as well (bonus: I can only see all network connections with netscan)

Now to find SAM’s password and Admin password, there are several ways for example I can definitely find it from pcap.

But I thought the purpose here is to use volatility for this.
When we say password, ntlm hashes should come to mind first. And at this point voaltility will help us with this command.

volatility -f WINADMIN.raw — profile=Win7SP1x86 hashdump

We need to crack the SAM MD5 hash:

3c1a570304d09f3327f43a967b97953f

You can do this by using hashcat and tools like JOHN THE RIPPER in the terminal, but I bought the hash because I was in Bluteam’s own lab, and I cracked it myself on an online site.

In the same way, you can break the Admin hash in this way.

Now let’s come to the disk image in AzurePot.
First of all if you have MAC or Kali Linux:
Autopsy default comes on Linux:

After clicking here

You can go directly to the browser from http://localhost:9999/autopsy.

if on MAC

sudo install autopsy

Let’s go to the relevant address.

New Case>

From here you can start the analysis.
But I continued my investigations with Autopsy installed on my Windows machine.
Let’s open sdb.vhd with Autopsy.

I see that there are 7 vol files. You can tamper with all of them. I tinkered with them and saw that there were files I wanted in vol6. So I will continue from there. Examining a Linux machine is easier and more enjoyable than Windows in my opinion :)

First of all, I downloaded Cryptographic Keys and Passwords files,Software and Package Management,Crontab and Scheduled Tasks,Cache and Temporary Files,Root User Activities ,Image and Video Files,Documents and Text Files,Running Processes and Services, Network Settings and Connections, User Accounts and Permissions, Databases fields, Internet History files.

vol6 > var > log

Let’s go under the directory
Will we be able to see auth.log, message.log, syslog, access_log, error_log etc.?

As you can see, even a superficial scan of these log files gives me some clues.

Or bash history files under home:

We will proceed by exporting some unopened files.

Now, let’s continue the investigations according to the questions asked from us for the machine solution.

There is a script that runs every minute to do cleanup. What is the name of the file?

vol6 > var > spool > cron > crontabs > root

We can see the running files of the schedule under crontabs.

The script in the Q#1 terminates processes associated with two Bitcoin miner malware files. What is the name of 1st malware file?

In fact, we found the answer to this question even in the superficial reviews above. But if we still want to look specifically:

The remove.sh file under root gives us the answer to the question. I found out what Kinsing malware is by researching here. Previously, this kinsing had caught my attention under var>temp.

While my investigations were continuing, the dk86 file written under tmp caught my attention. It caught my attention that it is an ELF file and its size is very large.

You can export and examine it, but if you do not have an isolated environment, I do not recommend exporting directly. If you already have a Windows machine, it is deleted from the folder 2 seconds after you export. That’s why I’m trying to illuminate the event by doing static analysis.

And Bingo! Static analysis gave me more than the data I wanted.

The botnet’s name is Tsunami, its hashes, which OSes it targets, etc. And of course Virustotal:

Let’s continue with another question:What IP address matches the creation timestamp of the botnet agent file in Q#4?

The following path leads us to the conclusion. However, I can continue by exporting this file. And you can even open this file with notepad++. I found the date that dk86 was created above, now I can verify it in the access log

vol6 > var > log > apache > access_log

I see that the IP address here matches the address 141.135.85.36.

next question:

What URL did the attacker use to download the botnet agent?

We know that the name of the botnet agent file is dk86. We can search the access_log for an entry with the agent filename, but you will not find any
Another Apache log that we saw in Q#6 was error_log. Let’s try and extract the file and search within for the filename

Another question:

What is the name of the file that the attacker downloaded to execute the malicious script and subsequently remove itself?

First of all, this part was very challenging.This one took a long time for me to find. I have no clue what file I was looking for, but the word “downloaded” at least tells me that the attacker would have used wget or curl to download the file like what we saw in Q#7.

I searched both files in error_logs. wget never appeared. But I found 3 command lines with curl. As well as a base64 encode:

It seems very confusing. I saved these 3 files in one place for you.

Now I am preparing my cyberchef to decode this inside.

And the decode state is as follows:

You can see the typical pattern for the CVE-2021–41773 RCE exploit in the request URI. The home directory and other directory paths match the deleted directory we observed elsewhere in the UAC data. And we can see the source of the malicious request is 116.202.187.77, which according to WHOIS belongs to a German hosting provider, Hetzner.

For UAC files analysis

As a result of my investigations, I saw many processes under proc and environ.txt running under them. The data I wanted was available under this process.

At the end of the day, we did memory analysis, network analysis and disk analysis of one linux machine on two machines :)

Don’t forget to apply what you read and add something to it…