PREVENT Legitimate Windows Executables To Be Used To Gain Initial Foothold In Your Infrastructure

Security teams in many organizations are currently focusing on developing detections using the excellent work of MITRE ATT&CK framework. However, I doubt if the same organizations have the time or inspiration to work on security configurations to PREVENT at least some of the widely used TTPs.

In many cyberattacks reported during the last few years we have seen attackers of all levels (from ransomware to APTs) to use PowerShell.exe to download malicious code. Often, the execution of Powershell is triggered by the user clicking on “Enable Macros” in an attachment received in a spear phishing email. [1]

Detection techniques for that scenario include e.g the detection of MS Office executables or browser executables that are spawning powershell.exe as child process. Another example in the same context is the detection of regsvr32.exe being used with a special flag in the command line for downloading malicious code.

While it’s always nice to develop detections, I prefer to block bad things from happening wherever is possible. Why we should give an attacker the possibility to access our systems even for a few minutes in the best-case scenario if we can block them?

The Windows-host Firewall is a very powerful built-in tool inside the OS which often hasn’t been used as it should or could. Usually one or more central firewalls exist in organization’s networks and no attention is paid by system administrators to enable local firewalls on Windows hosts.

For more than 4 years we have configured the Windows Firewall on all our hosts to block widely used techniques like the use of PowerShell.exe or other LOLBAS (Living Off The Land Binaries and Scripts). This has been highly successful and during a recent discussion @FDezeure suggested me to share this experience with the community.

Assuming that we have a proxy server in our network and this is the ONLY way for outgoing http/https communications, we can block legitimate executables from connecting to C&C servers while they are still available for use on the internal network. In my opinion it is much easier and more effective to block outgoing connections of PowerShell.exe than trying to develop detections e.g for obfuscated PowerShell scripts or trying to restrict the use of PowerShell by blocking access to PowerShell DLLs. Priority should be given to prevention wherever possible especially when it’s easy to implement and free!

What we have to do is to create a GPO for distributing the host-based Windows Firewall rules to Windows hosts. In the Firewall rules we deny the connection of a number of executables to the IP address of the proxy server.

Which are these executables? Below a list that I know

• powershell.exe (ATT&CK T1086)
• regsvr32.exe (ATT&CK T1117)
• mshta.exe (ATT&CK T1170)
• bitsadmin.exe (ATT&CK T1197)
• certutil.exe (ATT&CK T1105)
• msbuild.exe
• hh.exe
• makecab.exe
• ieexec.exe
• expand.exe
• extrac.exe

It’s not bad if you can add to this list cmd.exe, wscript.exe and cscript.exe

Update 30–11–2019

If you are using MITRE ATT&CK its important to understand that not all the techniques are equal. Based on the research by Red Canary powershell is -by a wide margin- the most prevalent MITRE ATT&CK™ technique https://redcanary.com/blog/getting-started-with-attck-new-report-suggests-prioritizing-powershell/

In the case that laptops are used as endpoints with a split VPN configuration (not ideal from security point of view but common) the Windows Firewall configuration can have a whitelist approach ALLOWING network connections of the above mentioned executables ONLY to private address ranges e.g 10.x , 168.192.x . In this way laptops will be protected when are outside enterprise network and connected to Internet without using the proxy.

Implementation

A step by step guide on how to create a GPO to manage Windows Firewall is available at http://woshub.com/windows-firewall-settings-group-policy/#h2_1

Configure the outbound firewall rules to block the aforementioned executables

DON’T forget to test the policy! e.g

bitsadmin /transfer myDownloadJob /download /priority normal https://domain/filename c:\\filename

Another use case that we have implemented using Windows Firewall is to block ALL communication from workstation to workstation in our Windows domain by allowing incoming traffic (Inbound Rules section) to workstations only from admin workstations and servers subnets. Unless you have an application that requires point to point communication this can be done easily. Even if there is such application in the network, Windows Firewall can be configured to allow only the required traffic.

If this is in place attackers that potentially got foothold by a technique that we don’t block cannot easily move to other workstations by using e.g WMI.

This use case is decribed in details at https://medium.com/think-stack/preventing-lateral-movement-using-network-access-groups-7e8d539a9029

Conclusion

Windows Firewall is a powerful free tool that can provide quick wins to our defense in-depth strategy if configured properly.

Of course, there is always a risk that some operations can be broken when trying to implement preventive security controls but we have to think if these operations aren’t bad practices in the first place, deployed by IT operators for their convenience, and should be discovered and fixed.

However, always 1) test before deployment in production 2) deploy in production in phases e.g the GPO can be applied per Organizational Unit

[1] Ideally organizations should block macros in emails coming from the Internet by applying MS Office best configuration practices or by sanitizing active content at their email gateways. But very often this is not the case because of “business needs” e.g finance departments must receive excel sheets with macros. It’s not easily understandable from a security perspective why another channel e.g a web application is not used by IT teams to fulfill the business need of receiving documents with macros and at the same time eliminate a widely used attack vector.