Here phishy phishy phishy…

As a red teamer, I will often phish my targets. Most of the time I’ll do this to gain an initial foothold in to the target environment, however sometimes I may also phish victims as part of my escalation methodology. To be honest, sometimes I may also phish the targets just to feed my own curiosity regarding how people think and respond to different scenarios presented to them.

I am often asked what type of setup I use, what protections I put in place for my infrastructure, which framework do I like to use, etc etc.. so I had a light bulb moment; why don’t I just write up some details so that others may learn and so I don’t have to repeat the same conversations too many times. There’s also the added bonus that a write-up could act as informal documentation should I lose my mind some day and forget how I do what it is that I do.

This write-up is not going to go into detail regarding my permanent red team infrastructure setup. Why? Because it’s mine. What I am going to do however is show you how you can stand up a ‘once off’ server instance for your phishing needs, which will also be just as relevant if you decide to build a phishing server within your own permanent red team setup. So sit back, grab a nice cup of tea, and let’s go phishing.

Some assumptions first up:

  1. This box will be built in the cloud, I.E. on someone else’s computer. I choose to use Digital Ocean for my quick one-off boxen, however you can just as easily use Vultr, Linode, or whatever other provider you’re aligned with this given week.
  2. I’ll be using Debian 9 for this build. However, once again choose whatever distro suits your style.
  3. I will use the domains “example1.com” and “example2.com” as the domains for our phishing emails.
  4. This is just how I set up my infrastructure as it has proven successful for me many many times. There are one thousand and one other ways to do this setup differently, so take what you need to from this build and tweak it where you wish.

 


 

Digital Ocean:

Digital Ocean have a great guide to setting up Debian 9 here. Have a read and follow the bouncing ball to get the base system up and running. The summary steps I use are as follows:

  1. Create a droplet on a standard plan. The $5/month option works well for short sharp gigs.
  2. I generally use Singapore as the DC, but pick what suits your needs.
  3. Add your SSH key/s so you can connect to the server. If you’re not sure how to do this, take a look here.
  4. For the hostname, enter mail.example1.com, which is our first phishing domain.
  5. Finally create the droplet.

Before we get carried away building our server, it’s important to check that the IP address your droplet has been assigned is not currently on any blacklists. Why?
Simple… reputation scores are extremely important when building phishing infrastructure. Any blemishes on your server’s record will go against you when the victim’s email infrastructure checks to determine whether your email is malicious or not. Grab your public IP address, and throw it into whatismyip’s blacklist checker, which can be found here

Ideally you want to see a ‘No’ against every provider in the blacklist check.

Onward we march. With the following steps, we’re going to install a firewall on our server, install a handful of necessary packages to get the job done, create a new user so that we’re not abusing the ‘root‘ account, as well as lock down the ‘root‘ user from being able to SSH in to our server. No pretty pictures for this as it’s 101 *nix work.. let’s roll!

  1. SSH on to the server as root@ipaddress
  2. Install ‘ufw‘; a noob friendly firewall management package.
  3. Install some tools to make our life a bit easier when debugging.
  4. Enable OpenSSH connections ingress to our server and enable the firewall.
  5. Next up, let’s create a new user so we can leave ‘root‘ alone. We’ll also give the new account full permissions to execute commands as the user root by adding the new user to sudo.
  6. Next we will copy root’s SSH key over to the phisherman user. This is usually a big no no, but for our quick shot server this will be fine. Feel free to generate your own keys etc etc if this is going to be a permanent server in your red team infrastructure.
  7. Next up we’ll disable root from being able to SSH into this server. But first, it’s always worth making sure your new user account can get to the server prior to doing this. This may have bitten me once or twice in my sysadmin days of old. ;)
  8. If the SSH connection is successful, go back to your root SSH session and disable the root account from being able to SSH in to the server.

Attempt to open up a new SSH session as root and observe that it fails.. or.. it should unless you stuffed up.

For the rest of this guide, make sure you do all actions with root privileges. If you have closed down your original root SSH session, just make sure your phisherman account executes all commands with sudo. Personally, for tasks like this quick setup, I’ll run a complete shell as root so that I don’t have to type sudo every time I decide to install packages or edit configurations. You can do this simply by executing

 


 

DNS:

Next up, let’s set up DNS. We’ll be adding quite a few DNS records during this server build, but for starters simply create the following records on your domain’s DNS server to point to your droplet public IP address. Quick note, when creating your MX record, give it a priority value of 1.

If you are using two or more domains for this server, go ahead and create the same DNS records for each domain.

Okay, now we need to generate some SSL certificates for our domain/s. For this we will be using Let’s Encrypt, which can be installed as follows:

  1. Install the Let’s Encrypt certbot package:
  2. Next, temporarily allow http connections ingress to our server.
  3. Before requesting a certificate, make sure that no services are bound to port 80. Normally Nginx will be bound, but depending on your build other processes may be using port 80, so make sure you check.
  4. Next, let’s use certbot to grab our SSL certificates. Note that I am grabbing certs for both example domains in this command; obviously omit if you are only using one domain.
  5. If the command executed successfully, close down ingress HTTP connections to our server.

 


 

Postfix:

Next up, let’s install an MTA for sending and receiving emails. For my installs I like to use Postfix as my MTA.

  1. As always, installing packages is easy with Debian’s package manager. When installing Postfix, make sure you choose ‘Internet Site’ when prompted for the mail server configuration type, and set the system mail name to your first domain, in my case mail.example1.com.
  2. Next, edit Postfix’s main configuration file and add/modify the following. Note that you only add virtual_alias_domains if using more then one domain on your server.
  3. Create /etc/postfix/virtual and add the following to send all mail delivered to the domain to our local phisherman user:
  4. Create our Postfix lookup table.
  5. Now start the Postfix service and check that all is running as successfully.
  6. If successful, you should receive a service status of loaded and active. Next, allow ingress SMTP connections to our Postfix service.

 


 

Theory time:

In the following sections, we’ll be setting up SPF, DKIM, and DMARC. Now I know that most people will just skip past this short bit of theory, but it’s worth knowing what each of these records do as it definitely affects reputation scores of mail servers.

SPF: Sender Policy Framework. Very simply this is a DNS record which helps to prevent spammers and malicious folk from spoofing our domain name when sending email. The SPF record assigns which mail servers are permitted to send mail on our behalf. Now while we don’t really care too much about this, most mail servers will assign a trust score to an incoming email if an SPF record is set. Remember, we need our reputation to be as clean as possible to run a successful phishing campaign.

DKIM: DomainKeys Identified Mail. With DKIM, we set up a DNS record with a public key which can be used to verify that an email has come from a designated domain and has not been spoofed. Furthermore, the DKIM public key also confirms to the recipient that any attachments have not been tampered with in transit. Again, for our purposes, we’re all about racking up those reputation points.

DMARC: Domain-based Message Authentication, Reporting & Conformance. Another DNS record, however the purpose of DMARC is to allow recipient emails to authenticate any messages which are sent from our domain. If authentication is successful, the email will be delivered. If unsuccessful the email will fail it’s check and depending on the recipient email server the email may be rejected.

Okay, that’s about as short and simple I can keep the theory for you. Let’s continue on with setting up SPF.

 


 

SPF:

  1. Install SPF for Postfix.
  2. Append the following to /etc/postfix/master.cf:
  3. Append the following to /etc/postfix/main.cf:
  4. Now restart the Postfix service and check the status to make sure the service is loaded and active.
  5. Finally add a TXT record for SPF in our domain’s DNS

 


 

DKIM:

  1. Install OpenDKIM and the OpenDKIM-tools:
  2. Add or modify the following variables in /etc/opendkim.conf:
  3. Add or modify the following in /etc/default/opendkim:
  4. Add or modify the following in /etc/postfix/main.cf:
  5. Create a directory to store our OpenDKIM keys:
  6. Create a /etc/opendkim/TrustedHosts file with the following contents:
  7. Create a /etc/opendkim/KeyTable file with the following contents:
  8. Create a /etc/opendkim/SigningTable file with the following contents:
  9. For each domain we’re using for our phishing server, perform the following:
  10. Next copy the public key from mail.txt to a TXT record in DNS for mail._domainkey.
  11. Finally, restart the Postfix and OpenDKIM services and ensure the status is loaded and active.

 


 

DMARC:

Setting up DMARC is as simple as adding a DNS record to your domain with as follows:

 


 

Local email account:

I find it helpful to have local email access on my server for a few reasons:

  • So that I can check for any bounce messages or errors.
  • For testing email functionality is working correctly.
  • And most importantly, to communicate with phishing victims who respond with emails such as “Thanks for sending that spreadsheet through” or “Thanks for helping me with my account problems” etc etc. ;)

Personally I use Pine, which you can setup as follows.

  1. Install Pine (now known as Alpine)
  2. Open up alpine as the user phisherman, (E)xit the welcome page, navigate to (S) Setup, and then (C) Config
  3. Enter the following information to be able to send and read emails sent to your domain.
  4. Exit and save the configuration, and then exit Pine. Edit /home/phisherman/.pinerc and enter the following into the inbox-path field:

If you want to send email from multiple domains do some googling for Pine ‘Roles’.

 


 

Test your score:

Now for the important bit, testing the reputation of our domain. I like to use mail-tester to “test the spammyness of your emails”; it’s simple, fast, and accurate. Just remember when you send a test email from your server, make sure the email resembles a real life email; just putting in test/test will see you lose a couple of points.

 


 

Gophish:

Now for the part that all of this mail server and domain tuning has been all about… Gophish!

  1. Create our gophish directory:
  2. Fetch the latest Gophish zip file:
  3. Unpack Gophish:
  4. Copy across our Let’s Encrypt certificates so we can use TLS:
  5. Edit the config.json file and modify the 'phish server' configuration as per below:
  6. Allow ingress SSL traffic to our Gophish service:
  7. Now run Gophish. Note, I like to run Gophish using screen so I can tear down SSH sessions without the service stopping. Take a look here if you want to run Gophish as a service.
  8. Next create an SSH tunnel from our *nix box to our phishing server so that we can access the admin panel. I prefer not to expose my Gophish admin panel to the wild interwebz and find this a much more desirable approach.
  9. Now if you have performed everything correctly, you should be able to access the admin panel locally:

Well that’s all for this write-up. I hope you have learnt something and I have given you some ideas on how you could make this even better. Gophish have some really good documentation online to help you get started if you haven’t used the framework before, so be sure to take a look.

In the future, I’ll do a write-up looking at Evilginx + Gophish, which is great for 2FA authentication bypass and session hijacking phishing based attacks, but until then, enjoy, happy hacking, and tight lines.