The Key to Success - Enabling Blocklists with Inverse Ranges

Have you ever been doing some task and have some random connection happen in the back of your mind regarding a completely unrelated subject and leaving you with no idea how it happened? That is what happened to me after my initial roadblock when trying to configure Windows Firewall with Advanced Security (WFwAS) to limit internet access for some applications. I knew that if it could control applications in this way it would mitigate all sorts of app AppLocker bypasses and quite a bit of malware. I had shelved my work on the matter though, until I had one of these particular random connection events happen to me while I happened to be taking a shower.

To recap my last post, I had been looking into the ability of WFwAS to limit access to IP addresses or ranges based off of individual executables, but ran into a dead end with the peculiar way that it handles rule order of operations. I didn't yet have enough data or comfort with the tool to deploy it in a way that only allowed pre-defined applications to my entire organization, and had to shelve my active work on it because I couldn't find another way to deploy it. If only I had a way to block some high risk applications that I was pretty sure had little legitimate internet use!

So there I was washing my hair in the shower, and then it hit me. "What if I block all IP addresses except the range that I want to allow, and then just configure the default rule to 'Allow' to handle the rest?" I thought it through for a little while and realized that this could be the key to solving my problem!

After that I couldn't wait to get to work and when I did I jumped right in and started setting it up on my test machine. Sure enough it behaved as expected and worked immediately! Unable to contain myself I bubbled over and had to share my success with a coworker who had been patiently listening to my drama about Windows' firewall. The key to the whole thing was something I called "inverse ranges". But what were these "inverse ranges"? To understand that, let's look back at the example from my last post.

This type of rule is what I spent years configuring and is what defined how my mind thought about rule sets.

My last post illustrated why this wouldn't work with WFwAS. To overcome this I had to think outside of the allow range and instead take the same end goal (blocking the stuff I didn't trust, allowing the stuff I have to trust) and make it fit in the WFwAS "process blocks first" mentality.

The key for this was to block what was not allowed, and then default allow to permit the rest. 

Here is the logic spelled out:

1. Rule to block IP ranges not allowed that were before the IP address range I want to allow.
2. Rule to block IP ranges not allowed that were after the IP address range I want to allow.
3. Default allow the rest.

In other words define what I don't want and assume what I do want, thus the "inverse". Block what I want to block, the default allow permits the rest.

Let's take a look at what that looks like in our WFwAS configuration. I will use the 64bit version of PowerShell.exe as an example, and deny it to everything but RFC1918 IP address space. After watching our pen testers, studying malware in my test lab, and reading other people's blogs I knew that this was becoming a common method used by criminals to use initial execution on a machine to download and execute malicious code and would be high on my list to mitigate. As cool as that sounds, it was probably also due in large part to PowerShell web connections being one of the few things I could actually reproduce for testing that still had real world application.

(I apologize for the picture roll, especially if you are reading this on a mobile device).

Key here is that it is enabled and the Action is set to "Block the connection".
A reasonable name helps too.

Here is where we get to define the path and executable.
Remember that most systems have 32 bit and 64 bit .exe for many system files, so they will take at least 2 rules.
Also, check out that "Services" section... is that what I think it is? You bet, a great topic for another post!

Here is the "inverse range" concept in action. Look closely at the IPs and remember that these are being blocked.

Hard to see, and can't get it all on a single shot, but here is what part of the rule looks like after being configured.

Technically this could be done with subnet ranges, but I decided to simplify my rules by taking advantage of a WFwAS feature by using basic start-finish ranges. This allowed me to take what would require quite a few subnet statements and put it into a single basic range and greatly simplify managing my rule sets.

That's it, my secret is out. Isn't that cool? Well, I think it is anyway. I was able to get a successful PowerShell web download from a server on my allowed range (my internal network), but when I tried something from the internet that was previously working it puked red text onto my console window. But this time it was a welcomed and good puking of red text... in a twisted sort of way where my anthropomorphisation of a consoles behavior begins to quickly fall apart. Because it wasn't just my command puking; no, it was every piece of malware and crypto ransomware that used PowerShell to do its dirty deeds that would be puking all over consoles that were running hidden, and that could now be ignored and left to suffer alone in a world of STDERR!!!

So my next task was to take this and apply it to one of my original goals. I wanted to mitigate Casey Smith's clever use of system utilities to download code from the internet and execute it while bypassing application AppLocker. So I went over to his GitHub page and decided to create a rule for each item on his list of AppLocker techniques that used an executable to download code. I couldn't stop them from executing, but I could substantially limit their capabilities by limiting which IP addresses they needed access to.

I wrote up rules that covered the 32 and 64 bit locations for the utilities on the list and then proceeded to test it in our environment. There were a few applications that did have legitimate needs to access IP address space outside of my organization, but it was easy enough to just add in the appropriate "inverse ranges" to the block statements. There were a few challenges to be sure, but I had an effective mitigation that covered a wide swath of malicious activity. It would be worth my time to continue down this path and see how far it would take me.

With the basic functionality operating, I now had to tackle the challenges presented by long lists of IP addresses across multiple rules. To top that off, several of my applications were running up against the bane of many a firewall administrator - large lists of IP space owned by companies such as Microsoft, Amazon, and Akamai. I decided to tackle it, but that will have to wait until a future post for details.

I really hope that others see the benefit in this and find it helpful. Sound off in the comments or on Twitter if you have any questions about it. I plan to have more good things to come!

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

Branden
@limpidweb