Click me if you can, Office social engineering with embedded objects
Yorick Koster, August 2018
Introduction
Microsoft Office documents provide attackers with a variety of ways to trick victims into running arbitrary code. Of course an attacker could try to exploit an Office vulnerability, but it is more common to send victims Office documents containing malicious macros, or documents containing embedded (Packager) executable files.
To make these attacks harder, Microsoft has been adding security measures to Office that are aimed at protecting victims from running malicious code. A well-known measure is to open documents in Protected View when they are downloaded from the internet. Office 2016 and Office 365 contain additional security measures like a GPO to disable macros altogether when a document is downloaded from the internet. And the Packer file extension blacklist that blocks running of blacklisted file types.
Naturally these protections are not perfect, but they help in reducing these type of attacks. Recently, Matt Nelson demonstrated that SettingContent-ms files could be used to run arbitrary commands. These files were originally not on the file extension blacklist and could thus be used to trick a victim into running an embedded SettingContent-ms file from an Office document. This file type has now been added to the blacklist, protecting Office 2016/365 users. During the August 2018 Patch Tuesday Microsoft also released a fix the prevents opening of these files if they are not opened from %WinDir%\ImmersiveControlPanel.
In this blog I'll show two other ways to trick victims into running malicious code. Both methods require a certain amount of user interaction. MSRC states that "this technique requires significant social engineering: the victim must say 'Yes' to a security warning and not be running in protected mode" and will therefore not issue a fix for this issue.
Shell.Explorer.1
The Shell.Explorer.1 OLE object (CLSID {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}) acts as an embedded Windows Explorer or embedded Internet Explorer. This OLE object can be embedded in Office documents, and is saved as a persisted object in the document. A proprietary format is used for persisting the Shell.Explorer.1 object, a familiar structure be found at offset 76 (0x4C). It appears that the structure located at this offset is a ShellLink (LNK) structure [MS-SHLLINK].
When the Shell.Exporer.1 object is initialized (loaded), the ShellLink structure is parsed as a regular LNK file. The object then takes the ID list from the ShellLink, and uses it to navigate (browse) to the provided file, (shell) folder or website.
Figure 1: ID list from ShellLink structure is passed to CWebBrowserOC::BrowseObject()
Embedded Explorer
When a folder path is provided, the object will behave like Windows Explorer. It is possible to browse through files or folders and even execute files by double clicking on them. An attacker might abuse this to embed Windows Explorer that opens a remote share containing an executable file. If the attacker can convince its victim into double clicking an attacker-controlled file it is possible to run executable code from this remote share.
This attack seems hard to pull off. First of all the OLE object requires click to activate, second the user needs to double click on the OLE object to actually get a usable Windows Explorer view. Finally, the user also needs to double click on a file within the Windows Explorer view.
Embedding a Windows Explorer object can be convenient in situations where the admins have restricted the possibility to browse to certain folders or drives. For example if access to the C: drive is restricted, a local user could use an Office document containing an embedded Windows Explorer to circumvent this restriction. In addition, the object could be used to steal NetNTLM hashes, but since this is not hard to do with Office documents it doesn't make sense to use an OLE object that is click to activate for this.
Figure 2: browsing the local computer using an embedded Windows Explorer
Internet Explorer
Things get a bit more interesting when Shell.Explorer.1 acts as an embedded Internet Explorer. Besides the possibility to embed a web browser within a document, it also allows browsing to files on the local machine, and browsing to files on remote locations (shares and websites). This is not possible without some user interaction. Click to activate also applies in this mode, clicking on the object will trigger the file download functionality of Internet Explorer, meaning that a File Download dialog is presented to the user. If the user clicks on Run or Open (depending on the file format) the file will be executed.
Figure 3: File Download dialog shown after clicking on the embedded Internet Explorer object
Some file types, like EXE files, will trigger another warning dialog. But this dialog can easily be avoided by using other executable file types, for example the SettingContent-ms file found by Matt (other file formats also work).
Figure 4: certain file types will trigger an additional warning dialog
Protected Mode IE is disabled for the control, which does prevent other dialogs from being shown - like the UAC dialog. Consequently, only two clicks are needed to cause malicious code to run, namely click to activate, and Run/Open. The Shell.Explorer.1 object is also a good workaround for the file extension blacklist in Office 2016/365 as the blacklist is not used by Shell.Explorer.1.
Proof of concept
The PowerShell script below will try to create a Word document containing an embedded Internet Explorer object. The script uses the Packager object to create an object that looks like an embedded file, clicking the object will trigger the file download functionality.
Figure 5: embedded Internet Explorer that opens an Internet Shortcut file from a remote website that launches Calculator
Microsoft Forms 2.0 HTML controls
The Microsoft Forms 2.0 Object Library contains a number of 'HTML' ActiveX controls that can be used in Office documents. These controls are marked safe for initialization and don't require the user to enable ActiveX for the document that embeds them. The storage format is a lot simpler than the Shell.Explorer.1 object. Essentially, it consist of the object's CLSID followed by an HTML fragment (UTF-16 encoded). The HTML fragment doesn't necessarily have to be properly formatted, the object will just search for attributes it supports. Two objects support the action attribute, which takes a URL. These objects are:
Forms.HTML:Image.1(CLSID{5512D112-5CC6-11CF-8D67-00AA00BDCE1D})Forms.HTML:Submitbutton.1(CLSID{5512D110-5CC6-11CF-8D67-00AA00BDCE1D})
Clicking on an embedded object with the action property set, will cause the defined URL to be opened. Regular URLs will opened in the default browser, however file URLs (include files on shares) will be opened directly. A warning dialog is shown, but this dialog is a bit different from other warning dialogs as can be seen in Figure 6. This warning dialog is the same for all file types.
Figure 6: warning dialog when a file URL is opened from an HTML control
Forms.HTML:Image.1 accepts a src that can be used to configure the image that is shown in the document. Using an image it is possible to disguise the object, for example disguise it as an embedded document to entice a victim into clicking it.
It should be noted that an additional warning dialog is shown when the Office document contains a Mark of the Web, indicating it was downloaded from the internet. This dialog is more explicit, making this technique less useful from a remote attacker's perspective.
Figure 7: warning dialog shown when document was downloaded from the internet
Proof of concept
The following PowerShell script can be used to create a Word document with an embedded Forms.HTML:Image.1 object that when clicked will cause Calculator to be opened.
Figure 8: embedded Forms.HTML:Image.1 that when clicked opens Calculator
Protected View
As mentioned above, it is possible that the document contains a Mark of the Web to flag the file as being downloaded from the internet. When present, the document will be opened in Protected View. Any embedded objects that are present in the document will be disabled in this mode. Unless the attacker uses a vulnerability that allows bypassing Protected View, additional social engineering is needed to trick the user into clicking Enable Editing.
Figure 9: documents downloaded from the internet are opened in Protected View
Defense
Defenders should be on the lookout of documents that contain any of the following objects:
Shell.Explorer.1/{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}Forms.HTML:Image.1/{5512D112-5CC6-11CF-8D67-00AA00BDCE1D}Forms.HTML:Submitbutton.1/{5512D110-5CC6-11CF-8D67-00AA00BDCE1D}
For Shell.Explorer.1 objects extract the LNK file from the object and retrieve the ID list to find out what is opened when clicking the object. The ShellLink .NET Class Library on our GitHub page can be used for reading the ID list from LNK files. Normally, the LNK file starts at offset 76 in persisted Shell.Explorer.1 objects.
HTML Forms objects are easier to parse as these are UTF-16 encoded HTML fragments prefixed with a 16 byte GUID. Defenders should be aware that there are various methods for storing objects in Office documents. For example ActiveX controls can also be embedded as PersistPropertyBag objects where the object's properties are set in an XML file (eg, activeX1.xml).
In conclusion
Tricking victims into running malicious executable remains a popular method for getting a foothold into organizations. Because Microsoft is constantly raising the bar in Office & Windows, attackers should be looking for alternative means to attack victims. From the two alternatives presented in this blog, the Shell.Explorer.1 technique appears to be the most useful for attackers due to the additional warning dialog shown for HTML Forms objects in documents opened from the internet.
It is a known fact that people can be tricked into clicking on Enable Editing / Enabled Content in Office documents. It is not hard to imagine that users will click through additional warning dialogs, which was also demonstrated in the past with DDE attacks and more recently attacks utilizing SettingContent-ms files.
Red Teamers (and attackers) are always looking for new ways for getting into organizations, they aren't concerned about what meets the bar for a security fix. If they see an opportunity, they will take it. As a defender knowing what attacks are out there helps in stopping them. It shouldn't stop there, raise the bar for attackers by deploying things like Application Whitelisting and Attack Surface Reduction Rules (or similar alternatives). But more importantly, make sure to have visibility of what happens on the network, assume breach, and hunt for intruders.
Thanks for reading!