Overview

Protecting your infrastructure from prying eyes is an important part of landing a phish and maintaining access to a client’s network. The process of setting up redirectors and reverse proxies has traditionally been difficult and hard to automate across different cloud platforms.

Today, we’re going to solve that problem with our new repository, sneaky_proxy, which will allow you to automate your efforts.

GitHub - puzzlepeaches/sneaky_proxy
A reverse proxy allows you to quickly and transparently proxy traffic to and from your infrastructure. Traditionally, it has been difficult to automate this process. ...until now.

https://github.com/puzzlepeaches/sneaky_proxy


The problem

Well, well, well. Google flagged your site as malicious before you could even get it in an email to send during a phishing campaign. We’ve all been there.

Malware Warning

To protect our phishing sites and C2 infrastructure we have traditionally done the following:

  • Setup a GoPhish server by hand
  • Set up an Apache server and reverse proxy by hand
  • Installed some redirect rules to shield ourselves from the boys in blue
  • Pray that we don’t get permabanned off the face of the internet before we can send a phishing email 

The situation

Let me paint a picture for you. You created an awesome phishing landing page that looks like this:

Office 365 Login


Looks terrible right?!


This site is hosted at the URL listed below:

You send out a phishing email containing this link. Users are supposed to click, navigate to the page, and enter their credentials. If it works, you made this engagement.

Unfortunately, you’re sending this email to a client using a Proofpoint mail gateway. The second that email hits the mail gateway, automated tooling crawls your webpage and realizes it’s a phishing page. The URL is blocked and you lost hours of work.

The solution

To solve this problem, testers started implementing transparent reverse proxies and redirection rules to hide that page from prying eyes. They did so by redirecting traffic originating from:

  • Cloud services , as they most often host security solution scanners
  • User agents associated with Google’s bots and other URL crawling services
  • IP ranges from countries not shared by your target client

We collect this information and build a big list of predefined indicators stating that the traffic your web server receives isn’t from your client but instead originates from Google, Microsoft, Proofpoint, etc.

We then use this information to define rule lists that redirect all unwanted traffic to a benign location. Most often we use NGINX or Apache web application frameworks to do this.

With Apache, for example, we take the information we collected and use it to generate Apache and NGINX redirect rules. In Apache, we use the mod_rewrite module to accomplish this task.

Redirecting and Remapping with mod_rewrite
This document supplements the mod_rewrite reference documentation. It describes how you can usemod_rewrite to redirect and remap request. This includes many examples of common uses of mod_rewrite, including detailed

https://httpd.apache.org/docs/2.4/rewrite/remapping.html

A redirect file is created and included in the Apache configuration. Someone automated the creation of this file for us. 0xZDH did and their repository is included below.

GitHub - 0xZDH/redirect.rules: Quick and dirty dynamic redirect.rules generator
Redirect Rules Generation Tool. This is a Python rewrite and expansion of: Code architecture based on: This tool dynamically generates a redirect.rules file that will redirect Sandbox environments away from our payload hosting/C2 servers.

https://github.com/0xZDH/redirect.rules

This is all well and good, but we aren’t really saving much time here. Instead, we’re only adding more work. We’re pentesters for Christ’s sake! We need to automate this! Luckily, we did and we’re sharing it with you for the first time today. We containerized the process and made it easy to deploy.

Let’s walk through the process using our new repository sneaky_proxy. This repo will allow us to quickly set up a reverse proxy without all the fuss. It does this using Docker and everyone’s usual tooling. The container does the following on launch:

  • Downloads the latest version of 0xZDH’s redirect.rules
  • Provisions an Apache server
  • Downloads and installs a certificate associated with a DNS record
  • Configures and starts a reverse proxy while also shielding you from prying eyes

The setup

First, we need to set up a couple of cloud hosts. One will host our GoPhish instance and the other our Apache reverse proxy. We’re going to use AWS to accomplish this.

Standing up your servers

Use the following launch options to configure two micro Ubuntu AWS instances:

AMI Details Screenshot


Setup your security groups to allow inbound traffic over 22/tcp, 443/tcp and 3333/tcp. Restrict access to your personal IP range for now!


Installing Docker

Once they’re created, SSH into each host install docker and docker-compose with the following command:

curl https://raw.githubusercontent.com/its-a-feature/Mythic/master/install_docker_ubuntu.sh | sudo bash



Sneaky GoPhish install

On one host, then clone our project sneaky_gophish. Go through the install steps included in the repository and our linked blog article.

GitHub - puzzlepeaches/sneaky_gophish
Hiding GoPhish from the boys in blue! See my blog article linked below for details on all the changes made during compilation of GoPhish before using! GoPhish by default tips your hand to defenders and security solutions. The container here strips those indicators.

https://github.com/puzzlepeaches/sneaky_gophish


Creating an A Record

On the second server, grab the host’s public IP and navigate to your DNS registrar. For this exercise, we’re using Route53 in AWS. Assign an A record for whatever domain you would like to the IP address of your second EC2 instance.

Creating an A Record

Installing and configuring sneaky_proxy

Once your record is assigned, SSH into your second EC2 instance and clone our sneaky_proxy repository.

git clone https://github.com/puzzlepeaches/sneaky_proxy && cd sneaky_proxy


Variables used by the sneaky_proxy container are set in a .env file within the repository. Open up the file in your favorite editor and modify the values to meet your needs.

Redirect scanner traffic to this domain
REDIRECT_URL=outlook.office365.com

The domain you have assigned to the second EC2 instance
PROXY_DOMAIN=signup.endpointenroll.com

The location of your GoPhish server
HIDDEN_HOST=3.45.22.33:8080


The REDIRECT_URL variable is the location you want to send traffic coming from places such as Microsoft, Google, and VirusTotal. The PROXY_DOMAIN variable is the domain you just assigned to the proxy server. The HIDDEN_HOST variable is the location of your GoPhish server listener. This can be C2 as well.

Building the container

Once setup is complete, execute the command below to build the container.

docker-compose build


It should look something like this:

docker-compose build view

Running the container

Once the container builds successfully, execute the command below to get the reverse proxy up and running.

docker-compose up -d


You now have a working transparent reverse proxy that will redirect bad traffic to the Office 365 login page.

Working transparent reverse proxy


You can check container logs using the command
docker logs -f sneaky_proxy


Navigate to the URL you specified PROXY_DOMAIN variable ,and you should see the default GoPhish 404 page included with sneaky_gophish.

GoPhish 404 page

Even better, navigating to the phishing link we listed above won’t reveal the IP address of your landing page. Instead, the A record you set is always shown as the URL of the page in your status bar.

Configuring network restrictions

Following this, you always want to create a security group that only allows inbound traffic to the GoPhish server from your reverse proxy.

GoPhish Server Reverse proxy Flowchart


Don’t ignore this part!


What we did

So what did we do?

  • We set up two micro EC2 instances
  • Assigned a DNS record to one of the instances
  • Set up GoPhish using sneaky_gophish
  • Set up a transparent reverse proxy using sneaky_proxy

Why all this matters

Evading controls is getting harder and harder. Simply standing up GoPhish and sending out an email is going to get you flagged and cause your engagement to fail.

Even more so, setting up new infrastructure is difficult and time-consuming. Baking your infrastructure with pre-built defenses against defenders is key to successful social engineering engagements.



About the Author

Nicholas Anastasi, penetration tester

As an Offensive Security Certified Professional (OSCP), Nicholas is focused on pushing the boundaries of clients’ networks, ensuring they are protected against the latest attacks and vulnerabilities. He joined Sprocket in early 2019 and has a particular interest in cloud technologies and DevOps. Email him at nanastasi@sprocketsecurity.com