Mshta is attractive to adversaries both in the early and latter stages of an infection because it enables them to proxy the execution of arbitrary code through a trusted utility.
Editors’ note: While the analysis and detection opportunities remain applicable, this page has not been updated since 2021.
Why do adversaries use Mshta?
Mshta.exe is a Windows-native binary designed to execute Microsoft HTML Application (HTA) files. As its full name implies, Mshta can execute Windows Script Host code (VBScript and JScript) embedded within HTML in a network proxy-aware fashion. These capabilities make Mshta an appealing vehicle for adversaries to proxy execution of arbitrary script code through a trusted, signed utility, making it a reliable technique during both initial and later stages of an infection.
How do adversaries use Mshta?
There are four primary methods by which adversaries leverage Mshta to execute arbitrary VBScript and JScript:
- 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
RunHTMLApplicationexport function of
rundll32.exeas an alternative to
The two most commonly abused Mshta technique variations we observed in 2020 were inline and file-based execution.
Inline execution of code doesn’t require the adversary to write additional files to disk. VBScript or JScript can be passed directly to Mshta via the command line for execution. This behavior gained notoriety several years ago with Kovter malware, remnants of which we still observed in 2020 despite this threat vanishing from the landscape following the 2018 indictment and arrest of the operators. Here’s an example of Kovter persistence in action:
Ursnif has used similar inline execution combined with code stored in the registry as part of its multistage initial access. Zscaler put out a great report detailing Ursnif’s technique shift from PowerShell to Mshta. Notice the use of
regread in both the Kovter example above and the Ursnif example below. Key terms like these make for reliable detection logic and are a good indication that Mshta is being mischievous.
Conversely, some adversaries choose to execute code stored in a file. Adversaries can direct Mshta to execute HTA content stored in a local or remote file by passing a location on disk, a URI, or a Universal Naming Convention (UNC) path (i.e., a path prefixed with
\\ that points to a file share or hosted WebDAV server) to the file in the command line. This technique is popular because the malicious payload is not directly visible in the command line, as it is with inline execution, and permits the execution of remotely hosted HTA content in a proxy-aware fashion. One threat we observed leveraging this technique in 2020 dropped Remcos via HTA content hidden behind a shortened URL:
Emerging Mshta tradecraft
Adversaries know that defenders are aware of Mshta’s potential for abuse. Therefore, it’s no surprise that in 2020 we observed an increase in adversary techniques to disguise Mshta execution and evade brittle detection logic. The Agent Tesla, Azorult, Lockbit, Lokibot, and Ursnif malware families all used inline execution of VBScript or JScript, or file-based execution of HTA content in files that did not have the commonly associated
.hta file extension. This is because Mshta will execute HTA content in files with any extension (or none at all) as long as the file extension is not mapped to a
text/plain MIME type (e.g., Mshta will not execute a file with a
.txt extension). To further disguise Mshta execution, TA551 renamed the binary in attempts to evade detection logic, which relied on Mshta executing with its expected filename of
Process and command-line monitoring
Monitoring process execution and command-line parameters will offer defenders visibility into many behaviors associated with malicious abuse of Mshta. Similarly, process lineage is also helpful for detecting adversary use of Mshta. At a minimum, collect parent-child process relationships, and, if possible, consider collecting information about “grandparent” relationships too.
We observed multiple adversaries this year renaming the Mshta binary to evade brittle detection logic. While we cover this extensively in our analysis of T1036.003: Rename System Utilities, binary metadata like internal process names are an effective data source to determine the true identity of a given process.
File monitoring and network connections
File monitoring and network connections—sometimes used in conjunction with one another—are also useful data sources for defenders seeking to observe potentially malicious Mshta abuse.
Two fundamental and complementary ways that you can think about detection for a given technique are to:
- Build analytics around the ways you’ve observed or otherwise know that adversaries have leveraged a technique in the past
- Identify all of the possible variations in the way a technique can be leveraged, a process discussed in detail in this blog post, and develop methods for detecting variations that deviate from what you expect
In our experience, it’s best to combine these two strategies while setting priorities that ensure you have sufficient coverage against actualized threats in the wild.
Inline script execution and protocol handlers
Mshta permits a user to execute inline Windows Script Host (WSH) script code (i.e., VBScript and JScript). The way that Mshta then interprets that code is dependent on the specified protocol handle, which is a component of Windows that tells the operating system how to parse and interpret protocol paths (e.g.,
Defenders can build detection analytics for inline Mshta script execution around these protocol handlers appearing in the command line. A specific detection example for this would be to look for the execution of
mshta.exe in conjunction with a command line containing any of the protocol handlers that are relevant to Mshta:
about, to name a few options. The following offers an example of what that might look like in the wild:
Suspicious process ancestry
While Mshta execution can be pretty common across an environment, there are a handful of process lineage patterns that warrant alerting. For example, an adversary conducting a phishing attack might embed a macro in a Microsoft Word document that executes a malicious HTA file. Given that there are very few cases in which Word should be spawning Mshta, it makes sense to alert when
mshta.exe. In 2020, we observed TA551 delivering weaponized Word documents that executed Mshta as a child process. Note that in this case, Mshta was renamed to
calc[.]com—more on that below.
Another example of suspicious process ancestry would be Mshta spawning other scripting engines, like PowerShell, as child processes. As such, looking for
powershell.exe could serve as a high-fidelity detection analytic for a specific behavior. The following Kovter persistence example does just this, with the HTA code pulled from the registry subsequently spawning an instance of PowerShell:
As is illustrated in the image above (where
mshta is masquerading as
calc[.]com), adversaries will occasionally rename Mshta to evade short-sighted detection logic. In these cases, defenders can bolster their detection of Mshta abuse by alerting on activity where the internal binary name is consistent with
mshta.exe but the apparent filename is not. A renamed instance of Mshta should be highly suspicious and provide a high signal-to-noise analytic.
In 2020, we observed adversaries not only renaming Mshta but also moving it out of its normal location in the
SysWOW64 directories. In addition to building analytics that look for inconsistencies between internal and apparent names, defenders should develop analytics looking for Mshta executing from locations other than
C:\Windows\System32\. In this example from testing,
mshta.exe is renamed
notepad.exe, which could fool detection analytics that don’t account for the possibility of masquerading:
Also note that the above example includes the
Network connections and HTA content
Normal file-based execution of Mshta content is typically observed on disk and executes HTA content in files ending with the
.hta file extension. Detection analytics targeting the execution of remotely hosted HTA content—either via URI or UNC path, from an alternate data stream, or from files without the
.hta extension—can provide defenders with high-signal analytics.
A behavioral analytic that might be helpful in certain environments is to simply look for
mshta.exe executing and making an external network connection. Of course, you’ll need to baseline against normal behaviors and tune out alerting that comes from legitimate software. Another detection opportunity relates instances of Mshta downloading and executing HTA content from a URI. When looking for this technique variation, make sure to look for HTA content regardless of whether it has the expected
.hta file extension.
Additionally, file monitoring data sources that provide a file’s MIME type is particularly useful for identifying HTA files masquerading as other file types. HTA files normally have a MIME type of
application/hta. Detection analytics built around identifying HTA content in files without the typical
.hta extension can provide high-fidelity detections.
Weeding out false positives
Detection analytics that are based on
mshta.exe spawning untrusted or unsigned binaries can be especially prone to high numbers of false positives. This can be alleviated in parts by effectively tuning detection logic to account for related activity that is benign in your environment.
Start testing your defenses against Mshta using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
View atomic tests for T1218.005: Mshta. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using Command Prompt:
mshta.exe "about:<hta:application><script language="VBScript">Close(Execute("CreateObject(""Wscript.Shell"").Run%20""powershell.exe%20-nop%20-Command%20Write-Host%20Hello,%20MSHTA!;Start-Sleep%20-Seconds%205"""))</script>'"
What to expect
mshta.exe will spawn a child
powershell.exe process that displays “Hello, MSHTA” to the console.
Useful telemetry will include:
Process command-line parameters
Command-line logging will capture the context of what is executed.
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.