Mshta

Editors’ note: While the analysis and detection opportunities remain applicable, this page has not been updated since 2021.

Analysis

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 RunHTMLApplication export function of mshtml.dll with rundll32.exe as an alternative to mshta.exe

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 ActiveXObject and 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 mshta.exe.

Definition

T1218.005: Mshta

"Adversaries may abuse mshta.exe to proxy execution of malicious .hta files and Javascript or VBScript through a trusted Windows utility. There are several examples of different types of threats leveraging mshta.exe during initial compromise and for execution of code. Mshta.exe is a utility that executes Microsoft HTML Applications (HTA) files. HTAs are standalone applications that execute using the same models and technologies of Internet Explorer, but outside of the browser."

Detection

Collection requirements

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.

Process metadata

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.

Detection opportunities

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., http:, ftp:, javascript:, vbscript:, about:, etc.).

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: javascript, vbscript, or about, to name a few options. The following offers an example of what that might look like in the wild:

vbscript: 
CreateObject("WScript.Shell").Run("notepad.exe")(window.close)

javascript:
dxdkDS="kd54s";djd3=newActiveXObject("WScript.Shell");vs3skdk="dK3";
sdfkl3=djd3. RegRead("HKCU\\software\\klkndk32lk");esllnb3="3m3d";eval(asdfkl2);dkn3="dks";

about:
about:<script>asdfs31="sdf2";ssdf2=new ActiveXObject("WScript.Shell");df2verew="sdfSDF";ddlk3nj=ssdf2.RegRead("HKCU\\software\\asdf\\
asdfs");asdfs="asdfasd";eval(ddlk3nj);asdfsd="Tslkjs";</script>

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 winword.exe spawns 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 mshta.exe launching 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:

Mshta masquerading

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 System32 or 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:

C:\Test\notepad.exe "javascript:a=new ActiveXObject("WScript.Shell");a.Run("powershell.exe%20-nop%20-Command%20Write-Host%20f83a289e-8218-459c-9ddb-ccd3b72c732a;%20Start-Sleep%20-Seconds%202;%20exit",0,true);close();"

Also note that the above example includes the javascript protocol handler, meaning that this style of detection will complement and provide added context to the protocol handler detection ideas listed above.

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.

Testing

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.

Getting started

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:

Data source	Telemetry
Data source: Process monitoring	Telemetry: An `mshta.exe` process will start. A `powershell.exe` process will also start as a child process of `mshta.exe`.
Data source: Process command-line parameters	Telemetry: Command-line logging will capture the context of what is executed.
Data source: DLL monitoring	Telemetry: `jscript9.dll` will load in the `mshta.exe` process indicating that script content is executed. Despite VBScript script code execution, `jscript9.dll` will load.

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.

Technique T1218.005