Antignis: A data driven tool to configure Windows host-based firewall

Problem

To understand how hackers compromise networks, we must first understand how hackers operate, gain initial access and are able to move laterally through an internal network.

First, the attacker needs a foothold into the network. Sending a phishing mail is a lucrative way of getting access to the internal network of an organization. While brute forcing is less elegant, it also offers a way in, or exploiting vulnerabilities might also give an attacker its sought after initial foothold. Sending phishing mails however can be done on a large scale and with much lower effort, which is why it is such an attractive method.

Once the attacker has gained a foothold in the internal network, they need to increase its control over the network in order to (ultimately) roll out ransomware on as many devices as possible. To do this, there are a couple of ways, including:

• [Exploiting vulnerable services]: Eternal Blue in 2017 is a prime example of a vulnerability in the SMB protocol that allowed attackers to gain control over remote systems;
• [Guessing credentials]: Passwords like Welcome2022 or Autumn2022 are still very common;
• [Reusing credentials]: The attacker uses a previously obtained set of credentials and tries to authenticate to other systems;
• [Relaying attacks]: Some services in Windows^[2] can be used by hackers to collect credentials or gain access to remote systems by spoofing an authoritative source.^[3]

What these methods all have in common, is that all these tactics need an open port. When inbound traffic is blocked in the host-based firewall, services might still be vulnerable but cannot be interacted with, thereby reducing the attack surface for successful exploitation. The attacker might guess the correct password for a user account, but it would be difficult to test that password when the service to verify the credentials is not accessible. The same would be true for reusing a set of credentials or a relaying attack.

Windows has a built-in firewall, that comes with advanced prevention mechanisms. If you install Windows and take a look at the firewall settings that are configured by default, we can observe the following:

• The firewall is enabled by default;
• All inbound traffic is blocked, unless specifically allowed;
• It has three profiles; Public, Domain and Private. By default, the Public profile is used.

The public profile does not allow inbound traffic on most ports used by the aforementioned type of attacks. However, if you join the host to a corporate domain, the profile changes from Public to Domain. This also changes the effective firewall configuration, resulting in an added active inbound rule that allows access on a port used by one of the aforementioned attacks.

While ‘Remote Assistance’ is one way to describe getting remotely access to a system, it is important to emphasize that this is the default behavior of Windows. By using nmap we can see that this port is indeed open and accessible over the network. 

Those familiar with conducting penetration tests, have probably seen findings that details to (re)configuring the host-based firewall. This is the reason why these findings are so important, is because configuring the host-based firewall correctly has a significant effect on the overall security posture of the internal network.

Solution

The solution is – on paper – fairly simple: configure the host-based firewall in a way that reduces the attack surface to its bare minimum. While one might argue that having a next-generation firewall in place might fill gaps in your security posture, this often times proves to be insufficient to stop lateral moment in an internal network. The reason for this is that these firewalls are costly and therefore placed between different VLANs, instead of between hosts. That means that if an attacker is able to infect a workstation, even a next-generation firewall cannot prevent the attacker from moving laterally within the same VLAN.

Alternatively, implementing client isolation/ private VLANs within a network definitely makes it harder for an attacker to move laterally, however, it is not a substitute for configuring the host-based firewall, as it lacks the granularity of restricting access on a network port basis.

Approach

The first step to configure the host-based firewall to minimize the attack surface is to determine the ports often used for lateral movement. This includes, but is not limited to ports used for protocols such as SMB, WMI and RDP.

Next, we configure a baseline. Workstations are not servers, so there is no need for other workstations or servers to connect to workstations over the network. When a workstation is used for server functionalities, it is probably a better idea to migrate those features to a real server. On all workstations, we block inbound traffic on the lateral movement ports that we defined in the previous step.

Here comes the hardest part; configuring a baseline for servers. Servers offer functionality to other hosts in the network, so they need to be remotely accessible. A lot of Windows services use the ports that we described in the first step for legitimate purposes, which makes blocking access on all of these ports unfeasible.

For example, blocking port 445 – used by the SMB protocol – on file servers and domain controllers would result in users not being able to login or using their network shares. This makes it complicated, because the servers that have been configured as a fileserver or domain controller need to be filter out.

One would argue that this is trivial to enumerate, since a fileserver needs to have the Windows fileserver role configured in order to be a fileserver. But is that really the case? When we take a look at some Microsoft documentation,^[4] we can see that this role is installed by default. That means that by this logic every Windows server is a fileserver.

But maybe you are on top of your asset management and you know exactly where all the home folders reside and which servers host which file shares. That is a really good starting point, however, lots of Windows services or tooling – such as SCCM – also use shares to function correctly.

Unfortunately, there is no foolproof way of telling which ports can be safely disabled and which ports should be left enabled – not without any additional information and testing. This, amongst others,  depends on the type of organization, your infrastructure, how the server is used. But we can still create a baseline that blocks inbound access on ports regular users or clients do not need access to, such as, but not limited to, ports used for VNC, RDP, WinRM.

If you are a sysadmin, you might think: “But I need RDP, WinRM or other protocol to administer servers!?” and you would be correct. But access to these ports should only be configured for privileged user accounts, such as system administrators. Or maybe even system administrators that are logged in on a privileged systems, such as jump hosts.

Windows Firewall offers functionalities that allow you to do this. Normally when creating a deny rule, the deny rule has precedence over any allow rule with the same port in scope. However, an exception can be made when a connection between two endpoints is established using IPSEC. This results in a bypass rule that takes precedence over the deny rule, if the connection is made over an authenticated IPSEC connection.

In other words, this allows you to block RDP access for every host in the network, unless the connection has been established from an authenticated endpoint. That way, a system administrator can still administer servers using RDP while every other host or user cannot connect to the RDP port of the same server.

Let me summarize for a bit; we now have a baseline on which ports need to be made inaccessible. If needed it is also possible to make exclusions for users that still need to have access to these ports. But, how do you implement this in a practical way?

What if you are in an environment with 2.000 endpoints, 1.500 users and 500 servers? How do you configure this on such a scale rather than configuring every server by hand?

Antignis

The answer is Antignis. Created by Hunt & Hackett, Antignis is free, open source and aims to help configuring the Windows host based firewall using the aforementioned approach and group policies objects (GPOs). Antignis uses a data driven approach to support the configuration settings, which means that the configuration of the host-based firewall becomes specific to the type of asset.

Antignis is designed for Windows and aims to help configuring the host-based firewall on Windows workstations and servers that are joined to an Active Directory domain. This means that support for other platforms – such as Azure, Intune or Linux – is out of scope.

To use Antignis, at least the following information needs to be configured:

1. Group with admin users: This is required. Users in this group will be able to bypass all block rules for every GPO that Antignis will create. Therefore, the amount of members in this group should be kept to an absolute minimum. For every GPO, a dedicated bypass group is created, and this admin group is added as a member. This group can also be used to grant additional users’ access;
2. Group with bastion hosts: Optional setting. It is possible to restrict access to bastion hosts as well. If you use dedicated jump hosts/ stepping stones/ bastion hosts to administer servers and such, you can fill them in here;
3. Organizational Unit: This is required. Antignis needs to create groups with all assets in scope. This is the location in AD where the groups are created in.

Antignis will create and configure all objects in Active Directory, including the GPO and the groups in scope. However, the GPO is not automatically applied on any organizational unit; that must be done by the IT administrator.

Ingesting data

Antignis needs to know which host is a server and which host is a workstation. This information is queried from Active Directory and stored into a database. This database is stored locally. Antignis also comes with another utility which can be used for ingestion data as well, but more on that later.

Creating the baseline

Creating a baseline uses the exact methodology as described in the previous chapter. This means that for workstations, a GPO will be created that blocks inbound traffic on the following ports:

For servers, all of these ports are blocked as well, except for WMI (port 135) and SMB (port 445).

If you want to exclude other ports for servers and/ or workstations, this can be done as well.

Creating advanced rules

This is where the fun stuff begins. Antignis is shipped with an additional utility that can be run on every host in your network. How to rollout the utility is up to the reader and outside the scope of this blog.

The utility will gather the following data:

This information is written to a configurable location. Antignis comes with the option to create a directory, which every authenticated user can write to, even though these users do not have the access to read the files within said directory. This location can be used with the utility, and the output will be written to that location.

All the information written to that location can be ingested into the database. With this information, we can create GPOs that:

1. Blocks SMB on servers that have no exposed file shares
2. Blocks RDP on servers that do not have the Terminal Server role configured, no Citrix installed or that do not have any established TCP connection on the RDP port
3. Blocks WMI on servers where software or roles that uses WMI to function (SCCM, Active Directory) are not installed or configured.

This allows for data driven creation of firewall rules, where rules can be created based on the context of the machine and how it is used. It is also scalable and can be applied to all hosts that are part of the selection that has been made.

Every infrastructure and every company is different. That is why Antignis comes with a list of prebuilt queries, but also allows you to write your own. It is plain SQL(ite) which makes the sky the limit for creating inbound firewall rules that suits your infrastructure and organization.

Updating data

The utility can be run as many times as you want. All relevant data in the database will be updated. This is in particularly useful when you want to know if a server had any connection established on a given port over a period of time (say for a month).

How to use

If you want to see how it works before actually implementing it in your environment, Antignis got you covered. Antignis comes with a feature that generates a database with test data. This data can be used to query against, but it is also possible to create computer objects in Active Directory based on the test data, so that test policies are populated with test computer accounts. This makes testing more realistic and delivers a more hands-on approach. Please refer to our GitHub repository for details on how to create a test dataset. The repository can be found on: https://github.com/huntandhackett/Antignis

Please make sure that you use Antignis in a responsible manner: assess whether there are any characteristics of the environment, or applicable (internal or external) laws, rules or regulations, that prevent you from using Antignis. You remain solely responsible for any damage or consequences that might occur as a result of, or related to the use of Antignis, or any of the information as included in this blogpost.

Closing thoughts 

While we are proud to present Antignis to the world, we admit that it is not a magic bullet and will not solve all your security problems, nor will it render lateral movement impossible. It still requires in-depth knowledge of the organization and the software and services running on the endpoints to prevent downtime by misconfigured firewalls.

It does however, make it far more practical and hands-on to configure the host based firewall correctly, based on information that is actual and relevant. Furthermore, by frequently updating your threat model [6], the threat actors in your threat model and mapping their techniques to specific ports which are commonly used to execute these techniques, you can further enhance your host based firewall rules, by making sure that your firewall rules are continuously aligned with your threat landscape. 

That allows organizations to use data to implement a host-based firewall strategy that makes it far more difficult for (ransomware) attackers to achieve their goals. It will likely mean that attackers will have to shift their modus operandi to successfully exploit their initial foothold and to become successful in their attack objectives. This is troublesome for the attacker as it is time consuming and error prone. They will have to (re)commit to the attack and add time and resources to their cause, while at the same time providing the defenders with a much-improved change to mitigate the attack, particularly when detection is in place to detect the attack in its early stages.

Sources

1. https://www.gartner.com/reviews/market/network-detection-and-response
2. Like IPv6, Link Local Multicast Name Resolution, NetBios Name Service, WPAD and mDNS
3. https://attack.mitre.org/techniques/T1557/001/
4. https://learn.microsoft.com/en-us/microsoft-365/security/defender/playbook-detecting-ransomware-m365-defender?view=o365-worldwide
5. https://learn.microsoft.com/en-us/windows-server/administration/server-core/server-core-roles-and-services\
6. https://www.huntandhackett.com/blog/threat-modelling-as-starting-point