Poking Holes in the Firewall: Egress Testing With AllPorts.Exposed

Beau Bullock //

If you have been even remotely in touch with technology in the past thirty years you have probably heard of this thing called a “firewall”. If not, a “firewall” decides what does and does not get to proceed through it. Most organizations have one of these protecting their network from the rest of the Internet. Some organizations place them in the most opportune spots to segment off specific areas of their internal network. The system you are using right now to read this blog post most likely has a firewall built-in.

The general consensus about what a firewall does is that it keeps “bad stuff” from entering a protected network or system. But firewalls can also keep things from leaving a network or system. This is called “egress filtering”.

Why Should We Care What Leaves?

The simple answer is the more ports allowed out, the easier it is for an attacker to establish command and control. If there are no outbound filters put in place an organization can quickly lose visibility into what is leaving the network. This can lead to malware infections, command and control sessions going unnoticed, or insider employees getting around corporate network policies.

If you are the one in charge of the firewall at your organization, how do you go about knowing what is allowed out of your network quickly without diving into your firewall rule sets?

If you are a pentester, how can you quickly find out what ports are allowed out of a network that can be used as a command and control channel?


AllPorts.Exposed is an Internet-resident system with (as the name suggests) all 65535 TCP ports open on it. If you were to portscan it from a system/network without firewall protection you should see that all ports are “open”. Now, if you were to portscan this system from within your network protected by a firewall, and you see open ports, these ports can be assumed as being allowed outbound through the firewall.

How To Test It?

Yes, you could use something like Nmap to do a simple portscan but I prefer PowerShell for this task as it is built into Windows operating systems. Often-times, when we are performing a pentest we are working from a Windows-based system and are typically not an administrator user. So, installing external tools can be difficult.

Here is a short PowerShell portscanning script you can use to test ports 1-1024 against allports.exposed.

  1. Open up a command terminal.
  2. Type ‘powershell.exe -exec bypass’ and hit enter.
  3. Copy the below script into the terminal window and run it.
1..1024 | % {$test= new-object system.Net.Sockets.TcpClient; 
$wait = $test.beginConnect("allports.exposed",$_,$null,$null); 
($wait.asyncwaithandle.waitone(250,$false)); if($test.Connected)
{echo "$_ open"}else{echo "$_ closed"}} | select-string " "

In the following screenshot you can see where the script prints ‘open’ to the terminal window for ports that were discovered as being open.

Alternatively, if you would like to just check for certain ports you can comma-separate each port you would like to scan at the beginning of the script in place of “1..1024”. For example, the following script will only scan ports 21, 22, 23, 25, 80, 443, and 1337.

21,22,23,25,80,443,1337 | % {$test= new-object system.Net.Sockets.
TcpClient; $wait = $test.beginConnect("allports.exposed",$_,$null,
$null); ($wait.asyncwaithandle.waitone(250,$false)); if
($test.Connected){echo "$_ open"}else{echo "$_ closed"}} | 
select-string " "

Here is the same script, but this time we are testing the top 128 ports in use on the Internet as defined by the Nmap project.

1031,1071,5901,9102,9000,2105,636,1038,2601,7000 | % {$test= 
new-object system.Net.Sockets.TcpClient; $wait = $test.beginConnect
("allports.exposed",$_,$null,$null); ($wait.asyncwaithandle.waitone
(250,$false)); if($test.Connected){echo "$_ open"}else{echo "$_ 
closed"}} | select-string " "

In conclusion, knowing what ports are allowed out of a network is very important for both pentesters and network admins. Each port allowed outbound from a network creates an additional exit point for attackers to utilize. BHIS recommends locking down egress traffic to only the ports required for the business to function. If possible, implement a web proxy and only allow outbound web traffic from it. Block all outbound traffic from client systems, and force their web browsers to use the web proxy to perform web browsing.