Adrian Pruteanu shows how to evade Intrusion Detection Systems using Proxy Cannon [Tutorial]

These days, it is fairly common for mature companies to implement Intrusion detection system (IDS), intrusion prevention systems (IPS), and security information and event management (SIEM) when they detect abuse against a particular application. When an unknown IP is performing too many operations in a short time on a protected application, IDS or IPS may take action against the source. If we are conducting a password spraying attack, we may avoid lockouts but we're still hammering the server from one source: our machine.

A good way to evade these types of detection systems is to distribute the connection requests from the attacker machine over many IPs, which is commonly done by malicious actors through networks of compromised hosts. With the advent of cloud computing and computing time becoming increasingly cheap, even free in some cases, we don't have to stray outside of the law and build a botnet.

In this article we'll see how to use Proxy cannon to evade intrusion detection systems (IDS).

This article is taken from the book Becoming the Hacker written by Adrian Pruteanu. This book will teach you how to approach web penetration testing with an attacker's mindset. While testing web applications for performance is common, the ever-changing threat landscape makes security testing much more difficult for the defender.

The Tor Project was started to provide a way for users to browse the internet anonymously. It is by far the best way to anonymize traffic and best of all, it's free. It is an effective way to change the public IP during an attack.

The Tor network

Tor is a network of independently operated nodes interconnected to form a network through which packets can be routed.

The following graphic shows how a user, Alice, can connect to Bob through a randomly generated path or circuit, through the Tor network:

Figure 1: The Tor network traffic flow (source: https://www.torproject.org/)

Instead of connecting directly to the destination, the client connection from Alice to Bob will be routed through a randomly chosen set of nodes in the Tor network. Each packet is encrypted and every node can only decrypt enough information to route it to the next hop along the path. The exit node is the final node in the chain, which will make the connection to the intended destination on behalf of the client. When the packet arrives at Bob's machine, the request will look like it's coming from the exit node and not Alice's public IP.

Note: More information on Tor can be found on the official site: https://www.torproject.org.

While Tor is important for anonymity, we're not really concerned with staying completely anonymous. We can, however, leverage the randomly chosen exit nodes to mask the public IP when attacking an application.

There are a couple of issues with conducting attacks through the Tor network. The routing protocol is inherently slower than a more direct connection. This is because Tor adds several layers of encryption to each transmission, and each transmission is forwarded through three Tor nodes on top of the normal routing that internet communication requires. This process improves anonymity but also increases communication delay significantly. The lag is noticeable for normal web browsing, but this is a tolerable trade-off. For large volume scans, it may not be the ideal transport.

Warning:

It should also be noted that Tor is used heavily in regions of the world where privacy is of utmost importance. Conducting large volume attacks through Tor is discouraged, as it can lead to unnecessary network slowdowns and can impact legitimate users. Low and slow attacks shouldn't cause any problems. Some red-team engagements may even require testing from the Tor network to verify related IDS/IPS rules are working as intended, but caution should be taken when launching attacks through a limited-resource public medium.

Proxy cannon

An alternative to using Tor for diversifying our attack IPs is to simply use the cloud. There are countless Infrastructure as a Service (IaaS) providers, each with a large IP space available for free to VM instances. VMs are cheap and sometimes free as well, so routing our traffic through them should be fairly cost effective.

Amazon, Microsoft, and Google all have an easy-to-use API for automating the management of VM instances. If we can spawn a new VM with a new external IP periodically, we can route our traffic to the target application through it and mask our true origin. This should make it much more difficult for automated systems to detect and alert on our activities.

Cue ProxyCannon, a great tool that does all the heavy lifting of talking to Amazon's AWS API, creating and destroying VM instances, rotating external IPs, and routing our traffic through them.

Note: ProxyCannon was developed by Shellntel and is available on GitHub: https://github.com/Shellntel/scripts/blob/master/proxyCannon.py.

ProxyCannon requires boto, a Python library that provides API access to Amazon's AWS. We can use Python's pip command to install the required dependency:

root@kali:~/tools# pip install -U boto

Collecting boto

 Downloading boto-2.48.0-py2.py3-none-any.whl (1.4MB)

[...]

Installing collected packages: boto

Successfully installed boto-2.48.0

The ProxyCannon tool should now be ready to use with the -h option showing all of the available options:

root@kali:~/tools# python proxyCannon.py -h

usage: proxyCannon.py [-h] [-id [IMAGE_ID]] [-t [IMAGE_TYPE]]

            [--region [REGION]] [-r] [-v] [--name [NAME]]

            [-i [INTERFACE]] [-l]

            num_of_instances

positional arguments:

 num_of_instances   The number of amazon instances you'd like

to launch.

optional arguments:

 -h, --help         show this help message and exit

 -id [IMAGE_ID], --image-id [IMAGE_ID]

            Amazon ami image ID. Example: ami-d05e75b8. If not

            set, ami-d05e75b8.

 -t [IMAGE_TYPE], --image-type [IMAGE_TYPE]

            Amazon ami image type Example: t2.nano. If not

            set, defaults to t2.nano.

 --region [REGION] Select the region: Example: us-east-1. If

            not set, defaults to us-east-1.

positional arguments:

 num_of_instances   The number of amazon instances you'd like

to launch.

optional arguments:

 -h, --help         show this help message and exit

 -id [IMAGE_ID], --image-id [IMAGE_ID]

            Amazon ami image ID. Example: ami-d05e75b8. If not

            set, ami-d05e75b8.

 -t [IMAGE_TYPE], --image-type [IMAGE_TYPE]

            Amazon ami image type Example: t2.nano. If not

            set, defaults to t2.nano.

 --region [REGION] Select the region: Example: us-east-1. If

            not set, defaults to us-east-1.

Output is to /tmp/

By default, ProxyCannon creates t2.nano virtual instances in AWS, which should be free for a limited time with new accounts. They have very little resources but are typically enough for most attacks. To change the type of instance, we can supply the -t switch. The default region is us-east-1 and can be adjusted using the --region switch.

ProxyCannon will create as many instances as specified in the num_of_instances and using the -r switch, it will rotate them regularly. The -l switch is also useful to keep track of what public IPs ProxyCannon is using over the course of the execution. This is useful for reporting purposes: the blue team may need a list of all the IPs used in the attack.

In order for the tool to be able to communicate with our AWS account and to manage instances automatically, we have to create API access keys in the AWS console. The interface is fairly straightforward and can be accessed in the account Security Credentials page.

The access key ID and the secret keys are randomly generated and should be stored securely. Once the engagement is over, you should delete the keys in the AWS console.

Figure 2: Generating a new AWS API access key

We can start ProxyCannon using the -r and -l switches, and specify that we want 3 instances running at the same time.

root@kali:~/tools# python proxyCannon.py -r -l 3

What is the AWS Access Key Id: d2hhdCBhcmUgeW91IGRvaW5n

What is the AWS Secret Access Key:

dW5mb3J0dW5hdGVseSB0aGlzIGlzIG5vdCB0aGUgcmVhbCBrZXku

[...]

Upon first run, ProxyCannon will ask you for these values and store them in the ~/.boto file.

root@kali:~/tools# cat ~/.boto

[default]

aws_access_key_id = d2hhdCBhcmUgeW91IGRvaW5n

aws_secret_access_key =

dW5mb3J0dW5hdGVseSB0aGlzIGlzIG5vdCB0aGUgcmVhbCBrZXku

As you can see, these are stored in plaintext, so make sure this file is properly protected. Amazon recommends that these keys are rotated frequently. It's probably a good idea to create new ones for each engagement and delete them from AWS as soon as they're not required anymore.

ProxyCannon will connect to Amazon EC2, setup the SSH keys, adjust the security groups, and start the VM instances. This process may take a couple of minutes to complete.

[*] Connecting to Amazon's EC2...

[*] Generating ssh keypairs...

[*] Generating Amazon Security Group...

[~] Starting 3 instances, please give about 4 minutes for them to

fully boot

[====================] 100%

ProxyCannon will overwrite the current system iptables configuration to properly route all traffic through whatever instance is chosen:

[*] Provisioning Hosts.....

[*] Saving existing iptables state

[*] Building new iptables...

[*] Done!

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ Leave this terminal open and start another to run your commands.+

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[~] Press ctrl + c to terminate the script gracefully.

[...]

As promised, ProxyCannon will periodically rotate our effective external IP using SSH tunnels and by modifying the routing table. All of this is done automatically, in the background, while Burp Suite or ZAP runs the password spraying attack.

The following is the periodic output from ProxyCannon showing the IPs being rotated:

[*] Rotating IPs.

[*] Replaced 107.21.177.36 with 34.207.187.254 on tun0

[*] Replaced 34.234.91.233 with 52.91.91.157 on tun1

[*] Replaced 34.202.237.230 with 34.228.167.195 on tun2

[*] Replaced 34.207.187.254 with 34.228.158.208 on tun0

[*] Replaced 52.91.91.157 with 54.198.223.114 on tun1

On the AWS console, we can see the started t2.nano instances and their public IPs:

Figure 3: AWS instances created to route our traffic through

We can test ProxyCannon by repeating a curl request to our target application using the watch command. We don't need to drop in a shell similar to torsocks because ProxyCannon modifies the local system routing to help us change our external IP.

root@kali:~# watch -n30 curl http://c2.spider.ml

On the target application side, c2.spider.ml, the server log, shows connection attempts from various IPs belonging to the Amazon address space:

52.91.91.157 - - [13:01:16] "GET / HTTP/1.1" 200 -

52.91.91.157 - - [13:01:22] "GET / HTTP/1.1" 200 -

34.228.158.208 - - [13:01:43] "GET / HTTP/1.1" 200 -

34.228.158.208 - - [13:01:48] "GET / HTTP/1.1" 200 -

54.198.223.114 - - [13:06:34] "GET / HTTP/1.1" 200 -

54.198.223.114 - - [13:06:39] "GET / HTTP/1.1" 200 -

It should be noted that there is a lower limit to how often we can rotate the IPs on Amazon or any cloud provider for that matter. It takes a while for instances to boot and IP addresses to be reserved, associated, and become active. ProxyCannon has a hardcoded value of about 90 seconds to ensure the effective IP actually changes.

In this article, we looked at Proxy cannon for staying under the radar while conducting brute-force attacks during an engagement.

Becoming the Hacker is a playbook to help you become an ethical hacker and protect the web. Learn about the tricks of a web attacker.

6 common use cases of Reverse Proxy scenarios

MarioNet: A browser-based attack that allows hackers to run malicious code even if users’ exit a web page

Black Hat hackers used IPMI cards to launch JungleSec Ransomware, affects most of the Linux servers