Adding Egress Brute Force to PowerShell Payloads

We’ve all been there. You craft the perfect phishing email, register a great domain name, your multi handler is set up ever so perfectly. And then you wait and nothing happens. Egress packet filtering has destroyed all your hard work.

Now there are payloads and listeners designed specifically for this sort of thing, and they usually work well. But if you’re like me you want to have options. PowerShell has been my bread and butter as of late, so I decided to write a few lines of script that would allow me to try every port out towards my listener until I found an open one, and then use that port in my payload.

Be sure to set your own host address for your listener, also note the $wait variable has 2000 set as the timeout, you can increase this number to ensure you have enough time between client and server, but then it takes longer to get through all the ports so tweak as needed.

On the server side I wanted to have just as many options. No matter the listener; metasploit multi/handler, or any of the various cats (nc, ncat, PowerCat, gcat, dnscat, etc), I wanted a solution that could handle my reverse shells coming in on any port. IPtables to the rescue! This little one liner forwards all ports 65k and change to one of my choosing. (4444 in this case)

After setting the IPtables, fire up the metasploit reverse tcp listener.
Remember to use the port you specified in the iptables command (4444)

Throw the first bit of code in front of your favorite PowerShell reverse tcp payload. I generated mine with the Social Engineering Toolkit (SET). I simply had to modify the code to use the IP address I set in the Egress loop ($address = $Computername) and comment out  the line below that that is setting the port as I already set the variable named $port in my Egress loop.

Watching the PowerShell in action it fires the shell when it hits port 25 as this is the first open port to the listener.

That Is Nothing New

I am aware that Metasploit has an multi/shell/reverse_tcp_allports payload to listen on all ports. But like I said, we want flexibility. We aren’t always going to be in a situation where we can use a fancy pants Metasploit reverse tcp listener. Maybe you got root access to an old unused development web server on the DMZ and you want to use that as the landing place for your payloads? There are often constraints in place that can get in the way of installing all the tools of the trade. Perhaps you popped a box that has ncat already running on it because the user installed it with Nmap. Whatever your reason for not having the multi/shell/reverse_tcp_allports payload, this technique may be able to help.

The Same Concept with a Powercat Payload

I got Powercat up and rolling, so I generate a payload.

This spits out a ton of code but at the bottom there is the execution of the main function.

This looks like as good of a place as any to stick some variables.

So I throw my loop in there right above the call to the Main function so it executes before everything else. And I change the IP address and port number in the function call to their respective variables from my loop. (Powercat Payload didn’t like PS ISE, so I used Notepad++)

I save this script as payload.ps1  and start my PERSISTENT netcat listener. Again I use port 4444. We must be persistent as the payload hits the port twice and will kill the listener.

Then I execute payload.ps1

Once it hits port 25 (first open port)…. Success!

Conclusion

So there you have it. A few lines of PowerShell, and some iptables, and you have a way to potentially brute force your way out of some networks that are attempting to block egress traffic. If you are going to take the time to get code on a system, why not add a few more lines to increase your chances of getting that shell out? Even if you are in a situation where you can use theallports flavors of Metasploit Multi/Handler listeners, adding a simple loop to your PowerShell payload can greatly increase the odds of success.

Research Limitations

I tested this against iptables using both REJECT and DROP on the packets and it worked. You may or may not experience different results behind enterprise firewalls.

There are other ways to test for open ports with PowerShell. During my research, the method I used allowed me to make full connections with a timeout, which seemed to work the best.