SANS Penetration Testing

Pen Test Poster: "White Board" - PowerShell - Add a Firewall Rule

Board Elements_clean_Add a Firewall Rule

By Matthew Toussain, Grant Curell

In many lab and training environments firewalls are disabled to facilitate the learning experience. As part of live pentests however, bypassing and manipulating firewalls is all in a day's work. The Windows firewall is the most common packet filtering hurdle encountered today. While it is not necessarily the most robust solution, it can be tricky to manipulate without direct access to the GUI. Fortunately, PowerShell supports a potent set of integrations that we can leverage.

 

powershell_addfirewallrule_01

 

Methods Covered in this Section

Set-NetFirewallProfile to Disable/Enable the Windows Firewall:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

New-NetFirewallRule to add allow a specific IP address to connect:

New-NetFirewallRule -Action Allow -DisplayName Pentester-C2 -RemoteAddress

New-NetFirewallRule to allow connections on a specific port:

new-netfirewallrule -action allow -localport 80 -direction inbound -protocol tcp -displayname pentester-c2

 

Scenario: You successfully compromise an internal host. Awesome! In order to move laterally, your next step is to serve up your toolkit inside the target network. This reduces the risk of being caught by keeping all nefarious traffic internal to the target environment, and allows for direct access and invocation by way of protocols that might be filtered from an egress perspective (often the case with SMB traffic, PORT: 445). Unfortunately, your network sports that pesky Windows firewall. You could turn it off, but that isn't exactly incognito:

Set-NetFirewallProfile to Disable/Enable the Windows Firewall:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

powershell_addfirewallrule_02

 

Hope the users weren't watching when you did that! Furthermore, Windows is fairly aggressive about reminding users that their firewall is disabled. Cutting a more precise hole through the firewall is definitely the preferred method here.

 

Turning Meterpreter into PowerShell

Let's backtrack for a moment. In your initial compromise did you end up with a PowerShell session, or a Meterpreter session? Starting with the Metasploit meterpreter and somehow transitioning might feel like turning water into wine, but with the Metasploit payload_inject post-exploitation module miracles are possible.

post/windows/manage/payload_inject

powershell_addfirewallrule_03

 

Alternately, PowerShell is also available as a payload option directly. That said, it is often most convenient from a tradecraft perspective to begin with meterpreter and leverage the payload_inject module as needed.

 

Ripping a hole in the space-time continuum... (aka the firewall)

Now that we have a PowerShell session on the target we just need to rip a hole in the space-time (firewall) continuum to pop out on the other side of the Windows firewall! Naturally, there is a PowerShell cmdlet built just for this. Consider the following:

We can identify a packet filter on our target host by scanning with nmap:

powershell_addfirewallrule_04

 

The STATE "filtered" in nmap typically indicates that a firewall dropped the probes sent out by the scanner. This corresponds with the typical TCP connection behavioral differences between an operating system and packet filters. When an attempt is made to connect to a port on which an operating system is not listening, the underlying OS is kind enough to respond with a TCP reset (RST).

This tells us that nothing is here and we can therefore move on. Firewalls, on the other hand, tend to drop packets that have no business being there in the first place. From a scanning perspective this slows us down, but when it comes to identifying live services it is a good indicator that either the host does not exist, or that there is a firewall filtering and dropping inbound traffic. This gives us three general states in Nmap: open (unobstructed access), closed (received a RST, nothing here), filtered (I wonder what's behind door number 1?). Let's open the door shall we?

New-NetFirewallRule to add allow a specific IP address to connect:

New-NetFirewallRule -Action Allow -DisplayName Pentester-C2 -RemoteAddress 192.168.1.100

powershell_addfirewallrule_05

 

Running Nmap to test the connection again we can observe a new set of results:

powershell_addfirewallrule_06

 

Command Breakdown

New-NetFirewallRule -Action Allow -DisplayName Pentester-C2 -RemoteAddress 192.168.1.100

1. New-NetFirewallRule - PowerShell cmdlet for creating new firewall rules
2. -Action Allow - Either block or allow. The default is allow
3. -DisplayName Pentester-C2 - The name of the rule when viewed in the GUI or via the command line
4. -RemoteAddress 192.168.1.100 - The address to permit inbound connections from

 

How about something bigger?

The above command is all finesse. It limits access to a trusted host only, but what if we want to allow everyone to connect to the hole we just punched through the firewall?

New-NetFirewallRule to allow connections on a specific port.

new-netfirewallrule -action allow -localport 80 -direction inbound -protocol tcp -displayname pentester-c2

powershell_addfirewallrule_07
This cmdlet is pretty extensive and virtually anything imaginable is possible. The official documentation is available here.

Command Breakdown

New-NetFirewallRule -action allow -localport 80 -direction inbound -protocol tcp -displayname pentester-c2

1. -localport 80 - The local port to apply the rule against
2. -direction inbound - The direction to apply the rule to. This is either inbound or outbound.
3. -protocol tcp - When specifying a TCP/UDP port, the user must also specify which of the two protocols to apply the rule against. 
The value could also be a protocol number 0-255 or another protocol name (ex: ICMPv4).

 

Conclusion

For interested readers, there are also Get-NetFirewallRule, Set-FirewallRule, Enable-NetFirewallRule, Show-NetFirewallRule, and Remove-NetFirewallRule commands. With this set of tools, complete and granular control of the Windows firewall is available all through PowerShell.

 

SANS Note:

Matthew Toussain is teaching, SANS SEC560: Network Penetration Testing and Ethical Hacking in Reston, VA in May, and San Antonio in August. Or you can take SEC560 at anytime - online - by taking it OnDemand.

 

SANS OnDemand - Online Training:

OnDemand

  • 4-months of access to course materials, taught by authors of the course
  • Pause | Play | Rewind
  • Hands-on labs
  • Support from subject-matter-experts in case of questions
  • Checkpoint quizzes to help you better grasp the material
  • Learn more about SANS OnDemand Training: https://www.sans.org/ondemand/

Post a Comment






Captcha


* Indicates a required field.