Monthly Archives: December 2017

Building resilient phishing campaign infrastructure

When running a multi-stage phishing campaign, building and securing our mailing infrastructure can be a tedious and time consuming task. Consider a phishing engagement where the first wave of messages is ineffective against the defender’s network, or the messages are reported to IT staff. If you want a second wave of emails to get through, you’ll need to reroll your setup to a new server to keep the blue team from correlated your attacks by IP address.

Also consider a “pre-phishing” campaign where emails are sent without attempt to achieve command-and-control, but only to gather data about the defender’s network or test egress filtering. If this is detected, we don’t want it to be easy to correlate the attack with the recon.

For these reasons, we’ll adhere to the design considerations of @bluescreenofjeff’s Red Team Infrastructure wiki page. My infrastructure will contain:

  • One backend server (Cobalt Strike, GoPhish, Phishing Frenzy, SET, etc). This server will remain throughout the engagement
  • Multiple SMTP relays to act as redirectors for each stage of attacks

Whenever a new wave needs to be sent, all we would need to do is buy another domain name, configure our DNS to point to a new SMTP relay, and replace the relay address for our backend server.

To ensure my mail is delivered properly, I also wanted to make sure my messages are:

  • SPF compliant
  • DKIM signed
  • Conforming to DMARC
  • Reverse DNS for mail domain (domain.com in screenshots/configs)
  • Mail domain WHOIS data anonymized
  • Mailing domain name in good standing
  • Mailing IP addres in good standing

This Postfix-Server-Setup script will take care of most of configuration of the backend server, including server hardening, mail server configuration using Postfix and Dovecot, SPF/DKIM/DMARC configuration, Gophish installation, and iRedMail administrative and webmail servers. Steps 3, 5, and 8 are required. Step 4 (SSL certificates) is recommended to ensure the

Then configure a second server to use as an SMTP relay to stand as a redirector between our target and our backend server.

#install and configure postfix
apt-get install postfix
postconf -e 'mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 [GOPHISH IP]'

service postfix restart

You should consider restricting access to port 25 with iptables to only allow connections from your GoPhish mailing server.

I’ll also configure Postfix to remove some of the sensitive headers from our messages sent from the phishing server.

cat << EOF > /etc/postfix/header_checks 
/^Received:.*with ESMTPSA/ IGNORE 
/^X-Originating-IP:/ IGNORE 
/^X-Mailer:/ IGNORE 
/^User-Agent:/ IGNORE 
EOF 
postconf -e 'mime_header_checks = regexp:/etc/postfix/header_checks' 
postconf -e 'header_checks = regexp:/etc/postfix/header_checks' 
postmap /etc/postfix/header_checks 
service postfix reload

Now that your relay is configured, make sure you add it as the relay for your backend GoPhish server.

postconf -e 'relayhost = [REDIRECTOR]:25'

If you send mail with this configuration, your messages will probably go to spam in Office365 and Gmail mailboxes. I believe this happens because if Microsoft/Google have never seen mail coming from your IP before, they assume it is spam.

We can bypass this defense by relaying mail through a service like Sendgrid or Mailgun. I created a free Sendgrid account. You only need your username and password to configure your server.

On your SMTP redirector, run the following commands (from the Sendgrid docs):

postconf -e 'mydestination = $myhostname, domain.com, smtp-redirector-02, localhost.localdomain, localhost' 
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd' 
postconf -e 'smtp_sasl_security_options = noanonymous' 
postconf -e 'smtp_sasl_tls_security_options = noanonymous' 
postconf -e 'smtp_tls_security_level = encrypt' 
postconf -e 'relayhost = [smtp.sendgrid.net]:587'

#sendgrid authentication 
echo -e '[smtp.sendgrid.net]:587 SENDGRID-USERNAME:SENDGRID-PASSWORD' > /etc/postfix/sasl_passwd 
postmap /etc/postfix/sasl_passwd 
chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db 
chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db 
service postfix restart

That’s all that’s required. You may be asking why the redirector is necessary with this setup? It’s because I couldn’t find a way for Sendgrid to remove mail headers in the final message that point to our backend phishing server. In our current setup, the only addresses that will appear in the headers of the phishing email are Sendgrid’s and our redirector’s addresses.

My DNS records appear in NameCheap’s Advanced DNS pane like such.

If my campaign involves a web server for capturing credentials, that would be hosted elsewhere. The @ and mail records should point to the redirector, not the GoPhish server.

The Postfix-Server-Setup script option 7 will print the required DNS entries for you to copy and paste. We do NOT need a DMARC record, as this is taken care of by SendGrid.

My reverse DNS is configured by the VPS provider of my redirector. I used Vultr:

I like to test my phishing messages’ spaminess against mail-tester.com. It shouldn’t rate below a 9 with this configuration.

Happy phishing!