That pesky little IE com object

The world is changed... Much that was once was is lost... History became legend, legend became myth... Until, when chance came, it ensnared a new bearer. - From the intro to "The Lord of the Rings - The Fellowship of the Ring"

Something has been bothering me. I hinted at it in an earlier blog post (see item #4 here: https://limpidwebblog.blogspot.com/2016/12/what-it-isnt.html). There is a nifty way to get a script (such as VB or PowerShell) to download additional payloads or perform C2 even with outbound firewall restrictions with Windows Advanced Firewall applied to the script engines. I have known about it for a while (shoutout to an acquaintance who showed me the PoC code), but I haven't made it a priority for various reasons and I wasn't hearing a whole lot about it. But in the last few weeks I have seen several people discuss it on Twitter, so I felt like it was past time to elevate it in the priority list. An evil from an age in the distant past had be rediscovered and it needs to be destroyed! (Ok, maybe not quite that dramatic.)

One of the challenges with a pre-defined allow list for outbound traffic from an endpoint by application is that there are some applications that are expected to go all over the internet, such as web browsers. The nice thing about modern web browsers though is that they are accustomed to the dangers of the net and are hardened against misuse and abuse probably more than almost any other app on the OS. Because they are hardened, it is generally considered safer to allow them liberal access from an endpoint firewall perspective - plus it is really hard to create a comprehensive allow list by IP for something like the web browser. That battle usually has to be fought at the DNS/proxy/I(D|P)s levels.

But there are some browsers who have been around for a very long time. Some that existed before our age, when the internet was more open, more vulnerable, more precious. One must go back, visit the tomes of TechNet, and clear the cobwebs that have collected over the last two decades. Be careful as you scroll through, these pages are delicate and it takes longer for the long dormant archive hard drives to spin up as you read through it: TechNet c. 1996: The Internet Explorer Scripting Object Model

Behold the prophecy:

The scripting object model, which provides access to the browser, is a collection of objects that can be accessed by any scripting engine. VBScript accesses the scripting object model when it is executing code in an HTML page. Developers can also exploit the scripting object model in VBScript code. https://msdn.microsoft.com/en-us/library/ms970457.aspx, Emphasis added.

Others have documented the fulfillment of the exploit potential already, here are a few examples that illustrate how this can be used (note that this list isn't exhaustive, just a few that I have read. If I left a good one out, feel free to reply with it):

@Carlos_Perez talks about it here:

https://www.darkoperator.com/blog/2017/11/6/windows-defender-exploit-guard-asr-vbscriptjs-rule

and here:

https://twitter.com/cyb3rops/status/883512138723209216

@harmj0y talks about how it was used in Empire 2.0 here:
https://www.harmj0y.net/blog/empire/the-empire-strikes-back/

A great example is the listeners/http_com module. This module uses hidden Internet Explorer COM objects to communicate instead of Net.WebClient.

@leoloobeek has a great writeup on both how to use this and how to detect it with Sysmon: 

https://adapt-and-attack.com/2017/12/19/internetexplorer-application-for-c2/

I want to avoid any network communications initiated from an exe that isn’t Internet Explorer (or Edge)

Detecting a bypass like this is very important. In fact, I would encourage anyone collecting the Windows Filtering Platform audit logs or Sysmon network audit logs to create an alert any time a previously unseen application reaches out to the internet.

I wanted to take this a step further though. I didn't want it to work at all. As was mentioned by @danielhbohannon, using an IE com object loads an interesting .dll - ieproxy.dll. Let's take a look at the file details.

Check out that interesting "File description" line.

When researching the InternetExplorer.Application object I ran into a few things that mentioned it was sometimes called IE ActiveX, so I suspected that this was the .dll that provided the COM functionality. To better understand how this worked I used PowerShell to create an IE COM object a few times and watched the system activity in Microsoft's Process Monitor. When PowerShell created the object, it would load this .dll, which was great news. This means that it wasn't loaded until it was called, which means PowerShell wasn't dependent on this .dll to run. And if it isn't a dependency, blocking it will only cause issues when someone tries to call it, which should be rare.

Based on my previous work of using EMET to block .dll access to limit malicious capability (see https://limpidwebblog.blogspot.com/2016/09/should-that-app-use-internet_94.html for more details) I already had a quick way to test this theory... I spun up my Windows 10 VM lab instance and installed and configured EMET ASR to block ieproxy.dll from the PowerShell.exe process - and nothing happened. Turns out this was not so quick - EMET stopped working in Windows 10 after 1703. I had to get a Windows 7 test VM up and running.

Three hours later, I finally had that beautiful red text:

The good news: I finally had a way to stop this in PowerShell. I haven't yet tested it in other script engines, but I suspect that cscript, wscript, and others would be worth blocking as well. My initial testing has shown that none of these scripting engines are using this for other purposes... if it stays quiet for a little while longer I think it will be fairly safe to block it.

The bad news: ASR mitigations in Windows Defender don't have this kind of capability (as far as I can tell) so to do this in Windows 10 >= 1703, requires use of a third party tool. There are a few out there that do, but often this isn't a primary use case and it takes a bit of tweaking to get it to work.

Here's hoping that Windows Defender re-introduces this capability and finally brings ASR back into parity with EMET!!!

Until then, work hard and spend time with your family.
Branden
@limpidweb