Mitigate commodity malware attacks with Windows Firewall rules

Note: This article was originally written in October 2017 and is now over 7 years old. Please consider this guide as a conceptual reference rather than a current implementation guide.

That said, even at the time of re-publishing this in May 2025 I’ve rarely seen any clients that implement this level of management of Windows Firewall in my 6+ years of cyber security consulting so far. It’s a severely under-utilised tool.

There’s so much that can be done with the built-in Windows tools to prevent commodity malware or ransomware attacks before you even spend a cent on 3rd party tools. All of these things can (and should be) combined to create a good multi-layered strategy:

• Restricting use of administrative credentials
• Ensuring that UAC is enabled
• Using Application Whitelisting (SRPs, AppLocker, Device Guard)
• Associating malicious filetypes (such as .JS) with Notepad through Group Policy
• Controlling or preventing the execution of Office macros
• Using newer Office features to prevent execution of macros in files downloaded from the Internet
• Patching applications, keeping them up-to-date
• Preventing script hosts and command interpreters from connecting to the Internet

The last point has been on my to-do list for some time now. I was again reminded of it the other day while watching Sami Laiho’s recent Microsoft Ignite session about PAWs.

A lot of email-delivered malware begins with a macro or via DDE attack, and then attempts to connect to the Internet to pull down more nasties.

Today I came across this great blog post by Branden, in which he describes a handy method to prevent applications from communicating with hosts out on the Internet, while still allowing them to communicate within the internal network.

I set about manually creating a list of outbound firewall rules, including a whole bunch to mitigate the application whitelisting bypasses highlighted by the brilliant Casey Smith here. Doing this via the GUI is painful, and I wouldn’t wish it on anybody.

There are obviously going to be exceptions to these rules, for example to enable your IT staff to access Entra ID or other cloud-based services via PowerShell, but those things should be done from dedicated administrative hosts anyway. This ruleset is more for the general user population.

When the time came to think about sharing this ruleset here on my blog, I discovered that it’s possible to export the rules from the registry and re-import them elsewhere, however that has its own potential issues.

I instead created the following PowerShell script that will generate all of the appropriate rules using the New-NetFirewallRule cmdlet. It’s also much easier to review this script to see what it does, rather than read a registry export file.

You could extend this script to apply the rules directly to the appropriate GPO by using the -GPOSession parameter on the New-NetFirewallRule cmdlet.

As usual, run at your own risk, and test thoroughly before deploying:

If the embedded Github Gist doesn’t show up on mobile devices, here’s a direct link to the raw script file: https://gist.githubusercontent.com/dstreefkerk/800a9e0a22a6242a28b058be423cf0ba/raw/c2be1189f88fb5ad9acaab708ad985587a576ceb/Create-MitigationFirewallRules.ps1