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

Using One Defense to Mitigate Bypass of Another

I am a big fan of using several layers of defense, but it is even better if you can use one defense to mitigate the bypass of another. I have written about this a little before. I ran into one of those scenarios recently and wanted to share it because it ties in nicely with my previous entries for both Windows Firewall with Advanced Security (WFwAS) and AppLocker.

In my internet ramblings I happened across the following blog post by David Fletcher of Black Hills Information Security.

https://www.blackhillsinfosec.com/bypassing-cylance-part-4-metasploit-meterpreter-powershell-empire-agent/

The primary purpose of that post was on how they were able to get around a particular security tool. The approach was fascinating and surprisingly simple - rename or move powershell.exe and all of the protections that were intended for that executable will no longer work. This had me thinking - what would this do to WFwAS rules that limit powershell from downloading content from the internet? I immediately knew the answer. Windows firewall rules limiting powershell connections to the internet were limited to the path and executable name. This would go right around it and let the attacker do their business, even as a standard user!

In the words of US Brigadier General Anthony McAuliffe, "NUTS!"

I started thinking about how I would address this, and after a little while an idea came to me. What if I used an AppLocker deny rule to deny powershell.exe from every location except where it is expected to run (and where my firewall rules apply)? Let's get to work!

First I created an AppLocker executable rule set to deny to prevent PowerShell from running. It could be based off of a digital signature (preferred) or hash, but the hash would require maintenance for each version and each time the file was updated.

For the Publisher rule it is important that the File name is specified.

Next, I added an exception based off of the approved path location.

In this case, the exception location is %SYSTEM32%\WindowsPowerShell\v1.0\powershell.exe

That's it! Now to test.

Look at that beautiful red text! 

We can see here that the two technologies working together are effective at stopping this. Windows firewall stops the first attempt to use PowerShell to download external content, and AppLocker stops the workaround!

If possible, rules like this should be configured to ensure (by Publisher or Hash) that all executables with outbound WFwAS rules can only be run from their expected location to ensure that these are not trivially bypassed by moving or renaming the executables.

If a good list of allowed applications was in place this type of activity would be stopped in most cases. This rule could be added to an existing policy for extra assurance or to cover any loopholes in the existing policy. If AppLocker isn't configured in an environment, it would also be possible to configure a new AppLocker policy that did nothing else but block this particular workaround for any executables defined in WFwAS policies. It would just need a deny rule similar to what is shown above, as well as an Allow rule to allow everything else. (I wouldn't recommend this policy by the way, but it would be better than nothing if you were trying to protect WFwAS rules.)

Unfortunately this will only work on Windows Enterprise Edition, I was not able to find a way to do this with Software Restriction Policies. :-(

I think that this is a great illustration of the benefits of defense in depth, even at the endpoint level. If there are ways around a mitigation or a technology it doesn't necessarily mean that technology is no longer useful. It may just mean that we need to get creative and find ways to protect it with the tools available to us.

I have several exciting posts lined up, hopefully I will be able to get them published over the next few weeks.

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