Red Teaming: Easy Phishing Infrastructure Setup (For SOC Analysts & Red Teamers)

Introduction

In red teaming assessment, red teamers simulate the real-world attack scenarios in order to achieve their goals. Phishing is one of the attack scenarios for gaining initial access.

From the context of red team scenario, phishing is an action that entails sending emails from seemingly trustworthy sources to collect personal information or influence email recipients to perform an action in the interest of the attacker.

Although, phishing as a concept seems to be relatively simple, getting the phishing infrastructure setup and toolkit/frameworks required for it, is usually a tedious and time-consuming task in itself. As a result, someone conducting a phishing campaign finds oneself occupied with the phishing infrastructure setup and configuration of what is required for the engagement rather than the engagement itself.

This blog focuses on making this red team attack scenario of phishing easy and providing a consistent and predictable environment for conducting phishing campaigns.

What do we need for conducting a successful phishing campaign?

Phishing can occur over multiple mediums such as email, instant message, text message, etc. Usually in red team scenario, it is done through email because it is relatively formal way of communication that is best suited for a typical corporate environment. The ultimate goal is to steal sensitive information or to deliver malware to the victim. But this blog would be focusing on the former i.e., credential harvesting.

Following are the key components to run a successful phishing campaign:

1. Pretext Scenario
2. Domain Name
3. Campaigning Framework
4. Phishing Framework
5. Mailing Service
6. Reverse Proxy
7. Virtual Private Server

For the context of ‘How’, there is a need to discuss ‘What’ and ‘Why’ of these.

1. Pretext Scenario

The first key step is to come up with a pretext scenario for the successful campaign. A pretext is a made-up story used by social engineers to persuade a victim to give confidential information or commit a criminal act.

In a red team scenario, a phishing attack exploits the victims’ behaviour, leveraging their curiosity or fear to encourage them to act according to us, despite their better judgement. Popular mechanisms include job applications, healthcare contract updates, invoices, or human resources requests, depending on the target organization and specific employees followed by a URL that sends the victim to a login page for harvesting credentials. Some ideas pertaining to this can be found here.

2. Domain Name

Domain is the heart of a phishing engagement. It is the victim’s gateway to troubles and a red teamer’s gateway inside the internal network of the target organization. Selection of a domain name for a phishing engagement greatly depends upon the nature of the Pretext Scenario.

A typical case of credential harvesting is mimicking a login page of a genuine web application, which would demand a domain name that is aesthetically close to the original one.

Techniques like typosquat domains, domains with uncommon TLD, expired domains, legitimate domains that have been compromised, etc can be considered to get a luring domain name. A general thumb rule is to avoid getting homoglyph domain names (those with special characters, e.g. éxámple.org, ḛxamƿle.org, etc.)

3. Campaigning Framework

For the process of setting up users, templates, and a full campaign from scratch, Gophish as a framework is the best open-source solution. It is essential for a campaign because an analyst can otherwise get lost in keeping track of victim email addresses, email templates and schedule of campaigns.

Some of the essential components of Gophish and their respective usage is listed below

• Campaigns : Gophish is all about starting campaigns. This entails sending emails to one or more groups and keeping track of which ones have been opened, which links have been clicked, and whose credentials have been supplied.
• Users & Groups : Gophish allows you to manage groups of users who are part of the campaign.
• Sending Profiles : Gophish requires you to configure SMTP relay details known as “Sending Profiles” in order to send emails. For this, services like AWS SES, Mailgun, etc. can be used.
• Email Templates : The content of emails delivered to targets is referred to as a “template.” Templates can be built from scratch or imported from an existing email. They also allow you to send attachments. Templates can also include tracking graphics, allowing Gophish to track when a person views an email.
• Landing Pages : When users click the phishing links they receive, landing pages are the actual HTML pages that are delivered to them. Templating, capturing credentials, and redirecting users to another website once they submit their credentials are all possible using landing pages. This functionality is least likely to be used with the advent of multi-factor authentication as credential harvesting alone is not enough.

4. Phishing Framework

Due to the increasingly widespread use of two-factor-authentication methods (2FA), the majority of users think it is no longer possible to be phished. This feeling is reinforced by the fact that more and more websites are using HTTPS protocol by default.

Evilginx is a man-in-the-middle attack framework used for phishing login credentials along with session cookies, which in turn allows to bypass 2-factor authentication protection.

With each successful login, the website generates an authentication token for that session, which is included in every request the user sends to the website (cookie).

Evilginx2 steals authentication tokens supplied as cookies, allowing it to bypass user/pass login and two-factor authentication. It essentially duplicates the session. The attacker is treated as a fully/successfully logged in user with the cookies and token(s) in place.

An important term worth mentioning is Phishlet.

Phishlets are the building blocks of Evilginx. These are the configuration files in YAML format for proxying a legitimate web application into a phishing web application.

These files contain the subdomains that needs to be phished, real-time changes to the web page, when and what cookies to be captured, URI of the login page etc.

Writing your own phishlet is important when you have a custom web application that you want to phish. For learning how you can create your own phishlet you can go here.

5. Mailing Service

To send out emails, GoPhish requires a set of valid SMTP credentials to an SMTP server. A thumb rule in this case is to avoid setting up an SMTP server from scratch as the email marketing industry greatly competes to increase the sending reputation of their SMTP servers.

This in turn, ensures that their emails are delivered to the recipients’ inbox instead of spam. The probability of emails being flagged as spam for a newly setup SMTP server is very close to being obvious.

There are plenty of solutions in the market like – AWS SES, Mailgun, Office 365 for the mass mailing. These are already well accepted and have good sending reputation.

6. Reverse Proxy

It is very essential to make sure the metadata of the entire infrastructure remain hidden at all times. This includes – IP addresses, service provider/vendor names, etc. – of the phishing infrastructure. Additionally, there should be a way out to implement conditional traffic routing and firewall rules to combat bots and crawlers.

All this should be done on a physically separate location than the rest of the infrastructure. All of this can be easily achieved with a typical reverse proxy but there is a more efficient and convenient solution at no cost, Cloudflare.

There are countless benefits of using Cloudflare to manage the phishing domain name, some of which are hassle free SSL certificates, DDoS protection, WAF rules, captcha verification, reverse proxy, CDN etc.

7. Virtual Private Server

For components mentioned above, some are SaaS, while others are open source that are required to be self-hosted. In case GoPhish and Evilginx2 are to be used, a VPS has to be included in the scope of the infrastructure as well. Most popular options are AWS EC2, DigitalOcean Droplets, etc.

How do we get phishing infrastructure setup, the easy way?

With this, the ‘What’ and ‘Why’ of the components of a basic phishing infrastructure are completed.

It seems like a lot of work to set up all of this manually. Considering how subjective and dynamic phishing campaigns might get, it is also not easy to automate the provisioning of all the components as a lot of variables would require assumptions.

Before listing down what all is included under the automation through this blog post and what is deliberately not, it is important to get familiar with the problems and issues that were faced by the red teamers at Payatu initially and what exactly does an Easy Phishing Infrastructure Setup mean.

Problem Statements

1. There are a lot of complexities while setting up GoPhish and Evilginx2. Both are open source, written in Golang and require compilation from source code. This very fact can lead to a lot of frustration during an engagement.

For an example, some dependency conflicts can occur while compiling these projects due to a faulty commit that would require a lot of manual inspection of the codebase to fix. There is absolutely zero predictability over the successful compilation of code every time a phishing campaign needs to be set up.

Moreover, even if the best is to be assumed, compilation and configuration does take significant time. Both the challenges can easily be eliminated by creating docker images for these projects. For more context on Docker and containerization, read here.

1. Another challenge was to make GoPhish and Evilginx2 both run on the same server simultaneously. Both require port 80 and 443 and thus cannot co-exist without a reverse proxy like NGiNX. NGiNX can listen on let’s say 80/tcp or 443/tcp and based on the subdomain, the traffic can either be routed to Evilginx2 container or GoPhish container.

So, another Docker container of NGiNX along with a well written docker-compose YAML definition would be all that is required.

1. Evilginx2 by default prompts to generate SSL certificates from Let’s Encrypt and hence require the verification of the domain. This is absolutely useless as Cloudflare already takes care of the SSL needs.

So, using a self-signed certificate works like a breeze, for which Evilginx2 needs to be running in developer mode.

1. The only thing left was to have a convenient wrapper script that would take inputs like domain name, subdomains, phishlet to use, etc. and do all the magic (docker-compose.yml modifications, self-signed certificate generation, NGiNX/GoPhish/Evilginx2 configuration, etc.) itself. Bash can pretty much take the care in this case.

All of this good work has already been done under the name, PACU and can be found here. More details about PACU including the setup and usage will follow shortly.

(Optional)

Although this paragraph is optional, but it is interesting to document some more challenges that were experienced in creating PACU. First of all, to get Evilginx2 to work behind NGiNX, these lines are required in the NGiNX’s configuration file.

Secondly, considering the fact that all three containers are in a private network and for Evilginx2, the traffic appears to be coming from the private IPv4 assigned to NGiNX, Evilginx2 would never ever know the actual public IPv4 address of the victim visiting the phishlet and would instead log the private IPv4 address of the NGiNX container for every request.

This was rectified by making a small change in Evilginx2 code to utilize the value from X-Real-IP instead, which is the HTTP header used by NGiNX to provide the real client IP. But, even with this, the IP that Evilginx2 would get is that of Cloudflare.

To enable NGiNX to have access to the victim IP communicating with Cloudflare’s infrastructure, another modification was made in NGiNX’s configuration file to set the X-Real-IP header as the value of CF-Connecting-IP header that it receives from Cloudflare. This value represents the actual public IP of the visitor.

By now, it’s clear that there are indeed a lot of challenges in setting up and configuring Evilginx2 and GoPhish for a typical phishing engagement and how these have already been eliminated (theoretically till now) through PACU including the automated provisioning with the help of Docker, docker-compose and a simple wrapper script, which is yet to be showcased. Before that, one last thing…

PACU only automates the setup and configuration of two of the components discussed already – GoPhish (Campaigning Framework) and Evilginx2 (Phishing Framework).

As discussed earlier, these are the only two components in question that are required to be self-hosted and have most uncertainties and challenges associated with them. Although integrating other components like Cloudflare, AWS, MailGun, etc. are possible, these are managed services and SaaS solutions. Some are paid, some provide trials and other provide limited features for free.

By integrating a few of such services, the utilization of PACU would require the exact same service stack. Keeping in mind the same, the provision of getting visitor’s real IP from Cloudflare by modifying NGiNX’s configuration file has been kept optional in PACU.

To summarize the entire phishing infrastructure setup discussed above, a visual representation of it is shown below.

Architectural Diagram

PACU

The name comes from the omnivorous South American freshwater serrasalmid fish that are related to the piranha. Since these fishes are pretty aggressive, it relates well with the offensive nature of red teaming and phishing (fishin’) campaigns.

Setup

To make it as convenient as possible, the installation and setup of PACU has been made available with a single command for Ubuntu 20.04 LTS on AWS EC2.

curl -sSL raw.githubusercontent.com/thirdbyte/pacu/main/init.sh | bash

This invokes the init.sh script that installs all the dependencies such as docker, docker-compose, etc. and clones the repo. Also, it copies the setup.sh which is the actual wrapper script, to /usr/local/bin with the name pacu so that it can be invoked from anywhere.

(Optional)

To make sure that PACU is usable on other Linux distribution and environments that are not AWS EC2, a manual approach of setting it up is also available. This assumes that dependencies like docker and docker-compose are pre-installed.

git clone https://github.com/thirdbyte/pacu
cd pacu
chmod +x *.sh
./build.sh

./setup.sh can be invoked to start a campaign.

Usage

Invoking pacu from shell would give the following output.

Usage: pacu -d example.org -p github           # Initializes Evilginx2
       pacu -d example.org -g url              # Initializes GoPhish
       pacu -d example.org -p github -g url    # Initializes Evilginx2 with GoPhish
       pacu -d example.org -p github -g url -c # Enables support for Cloudflare while initializing
       pacu evilmux                            # Gets into Evilginx2 tmux session
       pacu evilmux-print                      # Prints stdout from Evilginx2 tmux session
       pacu nginx-juice                        # Prints juicy log from NGiNX
       pacu nginx-stop                         # Stops NGiNX
       pacu nginx-start                        # Starts NGiNX
       pacu remove                             # Removes pacu

The usage prompt is self-explanatory.

1. -d is used to provide the domain name that will be used in the campaign.
2. -p is to provide the phishlet name without the .yaml extension. These phishlets are located at /opt/pacu/evilginx/phishlets/. So, in case github.yaml needs to be used, it would be -p github in the complete command.
3. -g is used to define the subdomain that will be pointing to the GoPhish’s phish server.
4. -c without any argument value specifies that Cloudflare is being used as a reverse proxy in the infrastructure and thus nginx-proxy is supposed to get the real client IP from CF-Connecting-IP HTTP header from Cloudflare.

It is interesting to note that in case there is no -p, Evilginx2 would not be used and similarly if -g is not there, GoPhish would not be used. This is useful for some engagements with special requirements where only one of the two are required.

Once, the initial command is executed, for an instance, the following command

pacu -d evil.com -p github -g track -c

All the configuration and lure creation happen through the wrapper script only. Evilginx2 lure would be printed to stdout directly. Moreover, a comma separated list of hostnames that need to be configured as DNS records on Cloudflare or any other DNS hosting service being used. These hostnames are derived automatically from the phishlet being used and the domain name provided along with -d.

There are some additional functionalities explained below.

1. evilmux connects to the tmux session where Evilginx2 is running to interact with it.
2. evilmux-print prints the tmux session content to stdout.
3. nginx-juice prints some juicy logs from NGiNX which includes, source IP address, Cookies, POST body request, User Agent, etc. (Another perk of using PACU)
4. nginx-stop stops NGiNX resulting in the phish URL being unresponsive in case the engagement is supposed to be paused temporarily.
5. nginx-start starts NGiNX back after stopping it through nginx-stop.
6. remove completely removes PACU.

In case -g is used, GoPhish admin server is available at https://172.16.238.4:3333. To access it from another client, use SSH local port forwarding as follows.

ssh -L 127.0.0.1:3333:172.16.238.4:3333 user@remotehost

Credentials: admin:admin@gophish

The GoPhish configuration needs to be done manually including setting up the Sending Profiles, Landing Page, Email Templates, Users & Groups, Campagins, etc.

Conclusion

The motive behind this blog was to point out the challenges that a red teamer usually faces while getting a phishing infrastructure setup for social engineering activities and propose an easy solution for the phishing infrastructure. There are many more challenges to come, so look forward to more blog posts.