[Suggestion]: Block LOLBin/LOLBas access to internet via Windows Firewall

[Raieverr]

Are you sure the Security measure is not already implemented?

• [x] Yes, I have checked and the Security measure I'm suggesting to be implemented is not duplicate. 🫡

Please explain your new Security measure suggestion

Back again with a suggestion this time! 👋🏻

I want to suggest a new function to block outbound internet access for common LOLBins/LOLBas using Windows Firewall. This old-school technique can be added as a misc. Item or under the Firewall section, or... A handful of sections, but that's beside the point.

These binaries (e.g., certutil.exe, mshta.exe, wmic.exe, etc.) are frequently abused in post-exploitation stages for C2 and data exfiltration, and blocking their outbound traffic via Windows Firewall would help harden systems by preventing these tools from being used to reach the internet, while still allowing their use for internal operations where necessary.

A prime example is the ClickFix malware attacks, abusing MSHTA and Win+R run commands. Rather than disabling Win+R, you can block outbound MSHTA, and boom. The entire attack is dead. Ideally, this would be implemented as a configurable option or profile toggle for more flexible environments. A sample list of items that are commonly restricted by other utilities:

C:\Windows\System32\bitsadmin.exe
C:\Windows\System32\certreq.exe
C:\Windows\System32\certutil.exe
C:\Windows\System32\cmstp.exe
C:\Windows\System32\cmd.exe
C:\Windows\System32\cscript.exe
C:\Windows\System32\forfiles.exe
C:\Windows\System32\hh.exe
C:\Windows\System32\mshta.exe
C:\Windows\System32\msiexec.exe
C:\Windows\System32\netsh.exe
C:\Windows\System32\powershell.exe
C:\Windows\System32\presentationhost.exe
C:\Windows\System32\reg.exe
C:\Windows\System32\regsvr32.exe
C:\Windows\System32\rundll32.exe
C:\Windows\System32\schtasks.exe
C:\Windows\System32\wscript.exe
C:\Windows\System32\wmic.exe
C:\Windows\System32\xwizard.exe
C:\Windows\SysWOW64\bitsadmin.exe
C:\Windows\SysWOW64\certreq.exe
C:\Windows\SysWOW64\certutil.exe
C:\Windows\SysWOW64\cmstp.exe
C:\Windows\SysWOW64\cmd.exe
C:\Windows\SysWOW64\cscript.exe
C:\Windows\SysWOW64\forfiles.exe
C:\Windows\SysWOW64\hh.exe
C:\Windows\SysWOW64\mshta.exe
C:\Windows\SysWOW64\msiexec.exe
C:\Windows\SysWOW64\netsh.exe
C:\Windows\SysWOW64\powershell.exe
C:\Windows\SysWOW64\presentationhost.exe
C:\Windows\SysWOW64\reg.exe
C:\Windows\SysWOW64\regsvr32.exe
C:\Windows\SysWOW64\rundll32.exe
C:\Windows\SysWOW64\schtasks.exe
C:\Windows\SysWOW64\wscript.exe
C:\Windows\SysWOW64\wmic.exe
C:\Windows\SysWOW64\xwizard.exe

Per usual, thank you for your amazing work and awesome applications! We, the community, greatly appreciate you!

[HotCakeX]

Hi, Thank you for the suggestion and kind words 🙏

Blocking the LOLBin executables have been a security technique for a long time, when i search for them i can find documents and guides about them from many years ago. The module actually did what you're suggesting early on but i ended up removing that because of lack of proper testing to see what the outcome will be and if they break any other part of the OS or cause incompatibility issues.

I'm mostly a fan of allowlisting/whitelisting over block/blacklisting. The way i see it, there are a couple of well known executables that can be used by TAs for malicious purposes and we can apply best efforts to block Internet access to them, even though they might need Internet access for legitimate purposes.

We could do that but we will soon have more robust ways to prevent that attack vector. Windows will soon have Zero-Trust DNS: https://techcommunity.microsoft.com/blog/networkingblog/announcing-public-preview-of-zero-trust-dns/4405802

It will allow us to define a list of trusted domains that can connect to a device and anything else will be automatically blocked. It's just like App Control where you can define a list of trusted apps and anything not in that list will be automatically blocked. App Control can actually be used in place of LOLBin blocking because in order for those built-in executables to be abused, there needs to be an initial access where attacks can execute their code and with a proper App Control policies that simply won't be possible.

When it comes to firewall management, however, we have another option (upcoming). It's called AppID Tagging which relies on App Control policies to define Firewall rules. It's been on the roadmap for a long time and soon i'll begin working on it to complete it: https://github.com/HotCakeX/Harden-Windows-Security/issues/281

With that, you could for example say only files signed by Microsoft, Adobe, Nvidia etc. can connect to the Internet and anything else will be blocked by the Firewall.

So please let me know what you think ^^

[Raieverr]

I apologize for the delayed response; it’s been a hectic week for the SOC.

Thanks for walking through the rationale and roadmap. I agree that an allow–list–first model is the right long-term approach, and I’m excited to see Zero-Trust DNS and AppID tagging land soon. In the meantime, I still see optional outbound firewall blocks for high-risk LOLBins as a valuable, opt-in hardening step with minimal impact when scoped correctly.

From a technical perspective, these outbound blocks operate purely at the network layer, so they won’t stop local or offline use of these binaries. Instead, they’ll prevent them from reaching the internet. To avoid unexpected breakages, though, you could implement a few checks and balances to give security, but keep flexibility:

• By default, the rules should be scoped to Public and Private profiles, leaving the Domain profile open for corporate-managed networks where CRL retrieval (via certutil.exe) or BITS transfers (via bitsadmin.exe) are still required.
• Verify that the block rules sit above the default outbound “allow” policy by placing them in their rule group or using the –Group parameter in PowerShell, so they always take priority.
• Reference the full executable path for both 32-bit and 64-bit variants (e.g. %SystemRoot%\System32\mshta.exe and %SystemRoot%\SysWOW64\mshta.exe), rather than relying on just the filename, which could lead to unintended matches or bypasses.

As I mentioned in my original post, a prime example of this option being helpful is the ongoing ClickFix campaigns. For users not running Application Control policies (which, while powerful, are still a bit advanced for most home setups, even with how approachable your app is!), we’re seeing mshta.exe abused by threat actors to download and launch additional PowerShell payloads. (ProofPoint Write-up and Any.Run example)

This attack chain can be effectively disrupted by either disabling the Windows + R command via GPO or, more accessibly, blocking outbound traffic from mshta.exe using the firewall. It’s a fully reversible, audit-friendly mitigation (denials appear in the Windows Firewall log and can be ingested into SIEM/EDR as telemetry). It doesn’t interfere with internal communications or legitimate system functionality.

Common post-exploitation frameworks also often rely on PowerShell.exe or wmic.exe to call home. Blocking outbound access for these binaries helps prevent silent C2, data exfiltration, or second-stage payloads. And to my knowledge, Microsoft services like Windows Update, Edge, and Office/Teams updates don’t depend on these binaries for internet connectivity, so these firewall blocks are unlikely to interfere with regular daily use or system updates.

No matter the decision, I greatly appreciate the shared knowledge (Somehow, I completely missed the new DNS features... which is awesome!). I look forward to seeing #281 come together and aligning these ideas once those capabilities are available. 💃🏻

[Raieverr]

Side note, Mr. John Hammond just dropped a video on this very same conversation, entirely by chance: https://www.youtube.com/watch?v=x7L-F4yDXvI