[Write-up] LetsDefend — Suspicious Mshta Behavior

Euler Neto
3 min readApr 6, 2022

For those who don’t know, LetsDefend is a plataform where, among other things, simulates a SOC and there are some alerts to be resolved. It’s a good alternative to shape the skills for those who already work in a SOC, but the most important is that it can helps those who are starting in cybersecurity and have to deal with job requirements like “to work in a SOC you need to have SOC experience”.

In this post I will write about one of the alerts, SOC164 — Suspicious Mshta Behavior.

First of all: what is Mshta?

Is a Windows-native binary designed to execute Microsoft HTML Application (HTA) files, so it can execute scripts, like VBScript and JScript, embedded within HTML.

There are four primary methods by which Mshta can execute scripts [1]:

  • inline via an argument passed in the command line to Mshta
  • file-based execution via an HTML Application (HTA) file
  • COM-based execution for lateral movement
  • by calling the RunHTMLApplication export function of mshtml.dll with rundll32.exe as an alternative to mshta.exe

The most common use from adversaries are the first two mentioned above. So, looking the information in the alert we can see this:

We also can check in LOLBAS, since it is a Windows-native binary, about this kind of execution and obtain the information that it’s associated to MITRE ATT&CK technique T1218.005.

Ok, we have a HTA file being called by Mshta and we have the hash (MD5) of this file. We can verify this hash in VirusTotal to get more information about it.

The hash belongs to a file which is known to be a malicious script. If we look at the Community tab we can see that this file is available in Malshare and a link to download it is provided.

Now we can download the file to perform a deeper analysis. To perform this analysis we can use Any.Run. There we can see that the HTA file calls a powershell command with some obfuscation and it downloads a file from hxxp://193[.]142.58.23/Server.txt

Backing to the case in LetsDefend, if we go to Log Management and search for communication with the IP mentioned above we can find two communication from Roberto’s endpoint.

Since the first result confirms that the machine called the URL showed in the powershell command, the second shows that it was not successfull, this was because the URL is not available anymore (HTTP 404).

The network connection was unsuccesfull but the execution of the malicious file was performed, so we can consider this case as a true positive and request a containment.


[1] https://redcanary.com/threat-detection-report/techniques/mshta/