Email Spoofing since 2017

Back in 2017, I wrote this post for Bishop Fox based on some research I did for social engineering engagements.

Since then, things have changed a lot.

The industry has put a crazy amount of work into solving the "email phishing" problem since email-based social engineering caused so many problems during the mid-2010s, and all that effort paid dividends. Phishing emails clearly still exist and represent a threat to organizations, but getting them delivered is a much harder proposition than it once was.

Background

One of the first things that got fixed was the basic email spoofing problems I described back in 2017. Essentially, email servers started to respect SPF records for domains without DMARC records. The trivial email spoofing attack that used to be possible has gotten fixed, and an era of simple email-based attacks has finally come to a close.

That was, until one of my co-workers got a phishing email from an @circleci.com email address. Naturally, we were shocked. The email was clearly spoofed, which based on what I knew at the time meant that it should have gotten totally blocked. After reviewing this email, I've come to the following conclusion:

Email spoofing may be dead, but misconfiguration is forever.

So, how's this all possible?

In the case of this email, the main misconfiguration seems to be in the DMARC record:

~> dig txt _dmarc.circleci.com

;; ANSWER SECTION:
_dmarc.circleci.com.    300    IN    TXT    "v=DMARC1; p=none; rua=mailto:dmarc-reports@circleci.com"

Looking up the DMARC record for circleci.com shows that it has a policy set to none explicitly. That means that the domain explicitly tells any receiving mail relays any emails from @circleci.com addresses that fail SPF or DKIM alignment should still be treated as normal emails and delivered to a user's inbox. This is obviously a dangerous configuration, but is frequently used by companies who are transitioning to a stronger email protection configuration or by companies who care more about ensuring availability of email delivery than authentication of all emails coming from that address.

In the case of the CircleCI email, review of the headers made it clear that the email was using a classic technique: From/MailFrom confusion. Essentially, the email used different addresses in the From and MailFrom headers. MTAs only performed SPF checks against the address listed in the MailFrom header, which was set to an address owned by the attacker and correctly aligned with SPF.

This is the exact scenario that the DMARC protocol was designed to prevent. A domain with a properly-configured DMARC record ensures that all receiving MTAs validate alignment between the From and MailFrom headers, ensuring that they are the same and valid, for both SPF and DKIM authentication, and if an email fails alignment the MTA is supposed to follow the policy set by the DMARC record.

And when the policy is explicitly set to none, well, the MTA treats it like a legitimate, unspoofed email.

Real Operational Impact

So, we got that spoofed email from @circleci.com -- that can be impactful for any organization actually using CircleCI, but what if we're a red team on an engagement with a customer who doesn't use them? Well, this same vector should theoretically work with any domain with the same policy configuration. So naturally, I made a tool to search for other domains like this. It can be found here:

https://github.com/lunarca/DmarcHijack

I ran it against the domains from the Alexa Top 1M data set and got the following results:

Out of the 250,946 domains present in the Alexa Top Million domains, this scan showed that about 13% (31,268 domains) were configured with a DMARC record containing an explicit policy of none, and were configured to be vulnerable to spoofing. This is a far cry from the 98% of domains that could be spoofed back in 2017, but that still means that over 30,000 domains could be used for social engineering attacks.

In part 2 of this series we'll work through spoofing emails using this From/MailFrom confusion technique.

Until then, stay safe and vigilant!