MSHTA Files & Exploitations

What is it:

Microsoft HTML Application Host and CHM files. The program is located at C:\Windows\SysWOW64

An outdated relic on Windows machines used to host help documents.

Microsoft has documented that this is no longer supported:

The Internet Explorer team is increasingly focused on standards compliance, and markup-based behaviors are not part of modern web standards. In IE10 mode support for markup based behaviors has been removed, and this includes hta:application.

Some companies and hardware vendors are still using these file formats to manage their software.

FireEye outlines an effective attack exploiting HTA:

1. A threat actor emails a Microsoft Word document to a targeted user with an embedded OLE2 embedded link object
2. When the user opens the document, winword.exe issues a HTTP request to a remote server to retrieve a malicious HTA file
3. The file returned by the server is a fake RTF file with an embedded malicious script
4. Winword.exe looks up the file handler for application/hta through a COM object, which causes the Microsoft HTA application (mshta.exe) to load and execute the malicious script

How it works:

The rough outline for how it works can be seen in the last step of the attack outlined above. To go into more detail; the word document makes a request to the DCOMLaunch service which causes the service host process (svchost) hosting the word document to execute the Microsoft HTML Application Host(MSHTA) service which then executes the VBScript embedded in the HTA document (paraphrased from FireEye).

There are multiple areas of potential exploit using this method. The two biggest are that these HTA files run as a fully trusted application and that the VBS they can execute also has a high level of inherent trust. This means that these applications will very rarely cause a UAC prompt to pop.

Affected Versions:

Up to Windows 10 Version 1607

Mitigation:

Anti-virus and end point protection products like Sophos stop these threats out of the box most of the time. If you don't have an end point solution already in use, then an app locker policy should help quite a bit. See an example one below. We will use the file hash of the file since that should not change as it is no longer under development.

1. In Local Security Policy, expand Application Control Policies -> AppLocker
2. Right click Executable Rules -> Create New Rule
3. Select Deny and the user or group who it should be denied to
4. Since the Path of the file can be changed, select the File Hash option for blocking
5. Browse to the file in question, and add it
6. Create!

Documentation:
https://www.fireeye.com/blog/threat-research/2017/04/cve-2017-0199-hta-handler.html

https://web.archive.org/web/20130925022744/https://connect.microsoft.com/IE/feedback/details/785055/hta-application-tag-does-not-work-in-ie10

https://blog.checkpoint.com/2015/05/12/the-microsoft-help-file-chm-may-enslave-you/