Mouse Trap
Follow Jom and Terry on their purple teaming adventures, emulating attacks and investigating the leftover artefacts. - by ar33zy, DrGonz0 & Aashir.Masood
Last updated
Was this helpful?
Follow Jom and Terry on their purple teaming adventures, emulating attacks and investigating the leftover artefacts. - by ar33zy, DrGonz0 & Aashir.Masood
Last updated
Was this helpful?
The following post by 0xb0b is licensed under
Follow the adventures of Jom and Terry, members of the TryMouseMe purple team, as they work through a thrilling exercise of Attack and Defense. From initial access to persistence, you will emulate a three-stage attack on a Windows environment.
We start with a Nmap scan of mousetrap.thm, this revealed several open ports on a Windows system. The host is running Microsoft services such as RPC (port 135), NetBIOS-SSN (port 139), and SMB (port 445). Remote Desktop Protocol (RDP) is available on port 3389. WinRM is accessible via Microsoft HTTPAPI on port 5985. Port 9099 seems to be unknown.
With a default script and service scan, we see that port 9099 is identified as a Mobile Mouse Server.
By visiting the index page, we see the info that the server is running on MOUSETRAP.
With a little research, we can find the following exploit of CVE-2023-31902:
The exploit has two versions, one that uses SMB and one that uses HTTP. It allows an attacker to execute arbitrary code on the target machine by sending a specially crafted request to the Mobile Mouse server
The room asks us to do the following to gain remote code execution:
Once you’ve found the CVE and exploit, use the version that uses SMB, not HTTP
Generate a Windows stageless reverse TCP (x64) shell
Ensure that your reverse shell is called
shell.exe
We found an exploit targeting both SMB and HTTP, now we need to generate a reverse shell called shell.exe. We generate the shell.exe using msfvenom.
After we generated the shell, we set up a listener on 4445 and run the exploit:
We get a connection back and we are purpletom.
In the users' directory of purpletom, we find the user flag.
The room now challenges us to abuse an unquoted service path to escalate privileges:
Use
SharpUp.exefor enumeration, located in C:\Users\purpletomTarget the
Mobile Mousedirectory while executing the unquoted service path abuse
An Unquoted Service Path vulnerability occurs in Windows systems when a service's executable path contains spaces but is not enclosed in quotes. This misconfiguration can allow us to execute a malicious file placed in a higher-priority directory along the path, potentially escalating privileges.
We use SharpUp.exe as adivsed to find the vulnerability. The service runsHelperService.exe in an unquoted path in Mouse Uilities. So placing a Mouse.exe in Mobile Mousefolder should then execute Mouse.exe on runnning the service.
Next, we create a suitable executable that will run when placed in the unquoted path and the service is run.
As a user, we are allowed to write to C:\Program Files (x86)\Mobile Mouse.
Next, we set up a python web server on our machine and use the PowerShell curl alias to download our crafted shell. We place it into C:\Program Files (x86)\Mobile Mouse.
We list the available services via the following command:
There is the mobile mouse service:
Next, we set up a listener on port 4446. Via net start "Mobile Mouse Service" we run the service.
We get a connection back. We are NT Authority System. On the Desktop of the Administrator user, we find the root flag.
Furthermore, we are able to spot some credentials for the admin user.
Next thing to do is to apply persistence by adding the key shell to Windows\CurrentVersion\Run with the value C:\Windows\Temp\shell.exe and adding a user terry.
Use the
HKEY_CURRENT_USERregistry hiveUse the
SYSTEM userwhen creating the run key persistenceSpecify the registry key name (
shell)Use the following path for the payload (
C:\Windows\Temp\shell.exe)Specify the name of the backdoor user (
terry)
After using the following two commands we can run the checker.exe at C:\Users\Administrator\Desktop to reveal the final flag..
Now we switch to the blue side and try to understand what happened using the Sysmon Event Logs with Sysmonview. We follow the steps shown in the room to export the Sysmon logs as XML and import them afterwards in Sysmonview.
The first question asks us the name of the payload that was shared. On the first page, we have a list of DLLs and executables. By clicking on each of them, we can determine the image path. The executable payload.exe looks a bit suspicious. After clicking on it, we can see that the image path is indeed a shared folder.
We have identified that suspicious executable. The IP is already present in the image path.
For the following questions, we will follow the steps below: Clicking on the image path displays a session. By clicking on it, we can see an event graph. Each event can be inspected.
Clicking on Process Create reveals the same info for the second question.
As we have already shown above, we inspect the Process Create event. Here we see the command line issued.
Besides the event graphs, we can also use the View All Events tab. Since we know from the previous red part, we had to use SharpUp.exe, and find the full command line for the tool here.
At the same entry, we are able to locate the time executed.
The actual time of execution was a bit earlier:
Since we already know the IP of the attacker, we can search for this in All Events View. There we will find the command used to transfer the reverse shell.
As we know from the attack, we are looking for something like Mouse.exe. We use the All Events View again, drag and drop the column GUID into the field (2) and search for Mouse.exe. We have now several sessions available. Of interest are those around the time of the attack (8/6/2024 4:20). We find some session pointing to cmd.exe. By clicking on the following below (4) + (5) we see an Event graph. By clicking on the Process Create event, we see the parent command line having the path for the HelperService.exe.
The next question asks us about the password set for the user created by an attacker. We could go through all the sessions around the time of the attack to find the password, but we could also go back to the Process View tab. Here we look for net.exe, which can be used to add new users. Here we find a session where a user was created around the time of the attack.
As with the user, we could now go through all sessions in the View All Event tab at the time of the attack. However, we can also explicitly search for reg.exe in the Process View tab. There we will find a session revealing us the key and the target path used by the attacker.
As with the user, we could now go through all sessions in the View All Event tab at the time of the attack. However, we can also explicitly search for reg.exe in the Process View tab. There we will find a session revealing us the key and the target path used by the attacker.
