Tag Archives: postfix

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.

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 data to and from the server is encrypted.

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

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.

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!

About me

My name is David. I'm a penetration tester/security consultant.

I will write posts about what I've been working on, thinking about, or researching in the field of information security.