Mshta.exe is a Windows utility that runs Microsoft HTML Application (HTA) files. HTAs are standalone applications built on the same models and technologies as Internet Explorer, but they run outside the browser. MITRE ATT&CK tracks the abuse of this utility as T1218.005, Mshta, a System Binary Proxy Execution sub-technique in the Stealth tactic. The platform is Windows.
MITRE notes that several different threats have used mshta.exe during initial compromise and to execute code.
How attackers use it
Two forms are documented. Mshta can run content from an inline script that uses VBScript to fetch and execute a remote scriptlet. It can also run an HTA directly from a URL. In both cases the content comes from a server the attacker controls, and the local process is a trusted Windows utility.
There are two reasons it works, according to MITRE:
- Mshta.exe can bypass application control solutions that do not account for its potential use.
- Since mshta.exe runs outside Internet Explorer's security context, it also bypasses browser security settings.
That second point is easy to overlook. Hardening the browser does nothing for a process that is not the browser.
Where it shows up in a typical attack chain
MITRE's description mentions mshta in initial compromise as well as in later code execution. In practice that means you may meet it right after a user opens an attachment or a link, so treat an mshta launch from an email client, an Office application or a shortcut file as especially suspicious. The procedure examples on the MITRE page include shortcut files launching HTA content.
How to detect it
The MITRE strategy looks for mshta.exe execution where the command line references remote or local HTA or script content in VBScript or JScript. It then looks for what follows: file creation, network retrieval, or process spawning that suggests payload execution outside the standard Internet Explorer security context. Correlation uses parent process lineage, command line inspection, and network connections to untrusted or anomalous endpoints.
Concretely:
- Process creation with command line. Look for mshta.exe with a URL, with a script protocol such as vbscript or javascript, or with an HTA from a user writable folder.
- Parent process. Mshta started by winword.exe, outlook.exe, a script host or a shortcut launch is a strong lead.
- Network connections from mshta.exe (Sysmon event ID 3). Normal need for internet access is close to zero.
- Child processes of mshta.exe. A shell or PowerShell child is a high quality alert.
Sysmon event IDs 1, 3 and 11 give you process, network and file creation views.
Tuning
Most enterprises have almost no legitimate mshta use. If you find some, document it, then restrict the rule to everything else. If you find none, a single alert on any mshta process creation is cheap to run.
How to reduce the risk
MITRE lists two mitigations.
- Execution prevention. Use application control to block mshta.exe if it is not required. In Windows 10 and Windows Server 2016 and above, Windows Defender Application Control policy rules can be applied to block the application and prevent abuse.
- Disable or remove the feature or program. Mshta.exe's functionality is tied to older versions of Internet Explorer that have reached end of life, so it may not be necessary.
Add egress filtering as a backstop. If mshta.exe cannot reach the internet, the remote content forms of this technique stop working.
Check your own environment
- Is mshta.exe blocked by application control on every machine that does not need it?
- Do you capture command lines for process creation?
- Are .hta attachments blocked at the mail gateway?
- Can your proxy logs show which processes asked for HTA or scriptlet content?
This read-only PowerShell command lists recent Security log process creation events mentioning mshta, if command line auditing is on:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 500 | Where-Object { $_.Message -match 'mshta' } | Select-Object TimeCreated, Message
This read-only command shows whether the policy that records command lines is enabled (cmd.exe):
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled
What good looks like
A mature setup for mshta is boring. Application control blocks it on nearly every machine. Where it is allowed, a short rule alerts on any URL or script protocol in its command line. Egress rules stop it from reaching the internet. And the mail gateway drops HTA attachments before they get to a user. If you can say yes to all four, this technique has very little room to work.
Quick check
Why does hardening Internet Explorer settings not stop mshta abuse?
Mshta.exe runs HTA content outside the Internet Explorer security context, so browser security settings do not apply to it.
Name two forms of mshta use that MITRE documents.
Running an inline script that fetches a remote scriptlet, and running an HTA file directly from a URL.
What is the cheapest control for most organizations?
Blocking mshta.exe with application control, since few environments still need it.
Sources
- MITRE ATT&CK, T1218.005: https://attack.mitre.org/techniques/T1218/005
