LetsDefend - Suspicious MSHTA Behavior

LetsDefend

Investigation:

Suspicious MSHTA Behavior

Overview

Today we're going to deep dive into the LetsDefend Blue Team Training investigation over suspicious MSHTA behavior. But first, what exactly is MSHTA?


MSHTA stands for the Microsoft HTML Application, and is a signed, native application to the Windows operating system and its operation is responsible for handling HTML Application (HTA) files, which are applications whose source code consists of HTML, Dynamic HTML and one or more scripting languages supported by Internet Explorer, such as VBScript or JScript. If you'd like to read up more on HTA files, you can do so here on CodeDocs.

When you have a file which runs as a trusted document with a binary that has the ability to execute that code, you have a keen target for adversaries and having a better understanding of what we're going up against here will definitely play in our favor in determining if its usage is malicious or not.

Investigation:

To begin, we open up our SOAR platform and assign the alert to ourselves. This alert is categorized as an LOLBin type and is rated at a high severity for its execution of a low reputation HTA file.




At a first glance, we can see that the file "Ps1.hta" was executed on a host named "Roberto" using mshta.exe and the action being successful. As we investigate, it's important that we remember the EDR action because we know that whatever we find with this HTA file will have executed successfully on the host.


We see the MD5 hash of the HTA file, and a quick VirusTotal search shows that this file has been detected by 27 vendors as malicious. That's not a good sign.




So, the first thing I'm going to do is open up our Endpoint Security tool and check out exactly what was going on with this HTA file. Let's search for the host name and dig into this host.




As we were able to see from the alert details, a file named "Ps1.hta" was ran using mshta.exe, so let's grab the time of the alert, and open up the command history to see what was going on around that time.




While we look at the command history, we see some basic commands being ran where the user is changing directories and viewing what's in them. They make their way to the user Roberts desktop, wait about 2 hours and then execute the malicious HTA file that triggered the alert. 1 minute following the execution of the HTA file we see an obfuscated PowerShell command being ran. Now I'm not the best in PowerShell as I'm still relatively new to scripting languages, so I wasn't able to fully de-obfuscate this script to a tee and for the sake of time, we are able to make out enough to get an idea of what's happening with what we can see at face value. Within the obfuscation, we see at the end of the 3rd line where it creates a new variable called $H2. We see it call the new-object cmdlet which creates a new .NET or COM instance and can be used to download files from web servers by creating a System.Net.WebClient object, and calling the DownloadFile method on a provided URL. We can make out the 'WebCL", "net" and "ient" which is in a random order but makes out Net.WebClient when re-ordered. So, we can assume that the command is going to attempt to download something over HTTP(S).


Also, if you look at the second to last line we can see a variable being created called $H8, and it's value is a URL to a file called "Server.txt" hosted on a web server with the IP 193[.]142[.]58[.]23. This appears that the PowerShell command is obfuscating the syntax, and using the variables to concatenate it back to it's correct syntax where it will use iEX to download the Server.txt file from the external IP in the URL.


If we also look at the network connections, we can see that there was a connection to the IP in the PowerShell command.




Lastly, we can look at the process history, and see that mshta.exe was a child process of explorer.exe, meaning this file was executed from the File Explorer which would tell us that this was ran by a user.



Knowing all of this, we can head over to our SIEM and see if we can find the logs of this file being downloaded.

We are going to be looking for an HTTP request and response, and so we're going to search for the external IP address from the PS command.



So, we pull back two log entries. One sourced from our internal host to the external IP, and vice versa. We're looking at the HTTP request and response entries. If we look at the first entry, sourced from our internal host we can see the request to the URL for the file "Server.txt". This is expected from what we know.

Now what we're really interested in is the response from the server, because that's going to tell us whether the download of the resource was successful or not.



Some good news is we can tell from the server response that the file was not downloaded successfully. We view a 404 Not Found error, meaning the server was not able to locate the file "Server.txt" and so nothing could be provided to download.

We still want to know a little more about this IP address though, so lets do a quick search for the IP on VirusTotal.










From viewing the results, we observe that it has been detected as malicious by 4 vendors, we can view some WHOIS information, and can see that the files that have been observed communicating with this IP are fairly suspicious looking based on the amount of detections. Now, IP's are not always the best indicators of compromise, because they're easy to change. If you're familiar with the IOC Pyramid of Pain, you'll know that IP is the second from the lowest, with the lowest being the easiest to change/mask. But we do see some suspicious files communicating with it, and combined with knowing how this IP was called in the first place, it's a pretty good indicator that this is a malicious IP and more than likely a C2 server.

Analysis

Let's summarize everything that we know so far. We have an alert for suspicious MSHTA behavior, and we have witnessed the execution of an HTA script by someone using File Explorer which spawned a PowerShell instance and ran a command that attempted to download a file from an external IP but failed due to receiving a 404-response code from the web server. While this is good news, it still doesn't account for the fact that someone ran that script on this host. For that reason, we should attempt to mitigate this by requesting a containment of the device, and escalating this alert.

Mitigation

We head back over to Endpoint Security, pull back up the Roberto host and request containment.

Playbooks

Let's head back to the investigation dashboard and create a case.



We start our playbook, and we get some information about ways to investigate this alert. We have already done them, so we skim over them as it never hurts to read, but we click through till we get to the play that provides information for determining suspicious activity.




We select Yes, Suspicious and move ahead where we're asked about what type of suspicious activity is happening.

This asks us what the suspicious activity is. From the last prompt, we were given a link to LOLBAS where we can see the types of activity that can be performed by the binary.





We can see by going to the page for mshta.exe that this is an Execute, because mshta.exe was used to call the malicious HTA script.


We see in the photo above that the next prompt asks us who performed the activity. If we go back to our investigation, remember that we observed that mshta.exe was spawned by explorer.exe, the GUI application called File Explorer which provides a user a graphical interface to view/edit the file system. Meaning, a User performed the activity, so that's what we'll select. We move to the next prompt.


The next prompt tells us to go contain the machine, which we already have requested containment so we can select "Next"


Next, we'll add our artifacts that we observed. The MD5 of the HTA file, the external IP address that was called and the URL that contained the Server.txt file that was attempted for download.


We provide our Analyst Note and select "Next"


We're pretty confident in our investigation and analysis at this point, so let's go ahead and finish up the Playbook!


Doing so takes us back to the investigation dashboard so we can close the alert. We will mark this as a True Positive, because the HTA file was ran successfully and malicious activity was observed.



Alright, we have finished our investigation and it looks like we got all our answers correct!

Conclusion

Overall, this was a very fun investigation and also provides great insight on how a signed, legitimate Microsoft binary can be abused to perform malicious actions. Taking a deeper dive into LOLBAS shows that there are other ways other than the one shown in this walkthrough that mshta.exe can be abused.


I hope this walkthrough helped anyone who may have needed it!