Email is an essential tool in modern communication; however, the underlying technology is often taken for granted. This lack of understanding can lead to serious security issues and unintended behavior of a company’s mail system such as email spoofing.
Email spoofing is a type of cyberattack in which an attacker sends an email that appears to come from a legitimate server but actually comes from an attacker's server. When a successful spoof is combined with a phish, it can be difficult for even the most informed users and sysadmins to tell if email is legitimate.
In this blog, we introduce you to Spoofy, an open-source tool that is specifically designed to help identify and protect against email spoofing. Spoofy checks if a list of domains can be spoofed based on SPF and DMARC records. You may be asking, "Why do we need another tool that can check if a domain can be spoofed?"
Well, Spoofy is different and here is why:
1. Authoritative lookups on all lookups with known fallback (Cloudflare DNS)
2. Accurate bulk lookups
3. Custom, manually tested spoof logic (No guessing or speculating, real world test results)
4. SPF lookup counter
The original design for Spoofy was based on a tool developed by Bishop Fox’s Alex Defreese called Spoofcheck. This program was simple and checked if a domain can be spoofed via SPF and DMARC records to check for weak configurations that allow spoofing. The tool also shows the domain’s DMARC configuration that sends mail or HTTP requests on failed SPF/DKIM emails.
In 2022, I created Spoofy as an updated version of Spoofcheck to scan multiple domains simultaneously, since the original version was retired and only worked with Python 2.
How does it work
The Spoofy tool follows a specific order of operations to check the spoof-ability of a domain. First, it checks the domain's DNS server by looking for it in the SOA Record. If it finds the DNS server, it uses that; otherwise, it defaults to using Cloudflare. Next, it checks the SPF record, looking for the number of “all” strings. Having too many all strings can indicate potential problems. The tool also checks for the number of includes in the SPF record, recursively. If there are too many, it can indicate a potential issue.
After that, Spoofy checks the DMARC record, and specifically the DMARC policy. It also checks where the reports are supposed to go, the PCT number and the ASPF. This helps to ensure that the domain is properly configured to prevent spoofing. Additionally, the tool checks for subdomain policies, and runs all the checks through a master table that was created by Alec Sirois.
By following this specific order of operations, Spoofy can provide a comprehensive analysis of the spoof-ability of a domain and can help organizations protect themselves from email spoofing attacks.
Using Spoofy
Spoofy has a very simple command line interface that is used to operate the program. To find out if a single domain is spoof-able, we can use Spoofy by performing the following command:
As shown above, the domain “bishopfox.com” is not spoof-able. The tool also shows exactly why, since the DMARC policy is set to reject, aspf is “r”, pct is 100 and there are no misconfigurations with the SPF record, the domain is safe and cannot be spoofed!
Now let's dive into checking a list of domains by running the following command:
The next domain in our scan has been identified as being susceptible to spoofing. This is determined by the configuration of its SPF, subdomain, and DMARC policies. Specifically, the "all" mechanism in the SPF record is set to hard-fail, the subdomain policy is set to "none" and the DMARC policy is set to "reject". This combination of settings in the SPF and DMARC records creates a vulnerability that allows the domain to be easily spoofed.
Lastly, we have a domain that allows for subdomain spoofing! This is a unique combination where the SPF and DMARC configurations allow for subdomains to be spoof-able.
Problems Faced in Development
When building Spoofy, I found that there were very few libraries available that could handle both SPF and DMARC records at the same time. Since Spoofy relies on both SPF and DMARC records to determine if a domain is spoof-able, I had to create a custom logic table to capture all the possible combinations of these records.
To create the custom logic table, I partnered with Alec Sirois, a security researcher and email security expert. Together, we captured all the edge cases and combinations that could occur with SPF and DMARC records. Alec built a custom master table using a list of 10,000 real-world domains to validate the logic tables and create a fool-proof and reliable table for Spoofy.
What we found was that there are an enormous number of combinations being used in the wild for SPF and DMARC records. Therefore, we grouped them into categories and manually tested each combination to determine if it was spoof-able or not. This process ensures that Spoofy can accurately detect email spoofing by taking into account all of the possible combinations of SPF and DMARC records.
The unique combinations were too large to fit into this blog post but can be found in the Spoofy GitHub Files.
The Master Table shows the variations of spoof-ability:
- Not Spoof-able
- Organizational domain spoofing may be possible (depending on mailbox)
- Organizational domain spoofing possible
- Spoofing may be possible (depending on mailbox and the first all string)
- Spoofing possible
- Subdomain and organizational domain spoofing possible (depending on mailbox)
- Subdomain spoofing possible
To get the most accurate results out of Spoofy, we utilized different mail providers such as Gmail, ProtonMail, and O365 to validate if mail service providers were accepting the emails, putting them in spam, or rejecting them all together.
It's important to note that Spoofy isn't 100% accurate as it is still in late development. Also, there are some limitations regarding what Spoofy can see depending on how a domain's DNS is set up by the domain's owner.
Syntax Don’t Syntax
One of the weird edge cases we found while evaluating the SPF records was that the syntax didn’t really matter and could be used in very odd ways. Specifically, we identified multiple domains that had a correct SPF record, but the formatting was a little strange.
Can you see the problem? The RFC specifies that to have a valid SPF record, the record must contain a “-all”, “~all” or “?all”. What Alec and I found while testing Spoofy is that mail servers do not care if it is “-all” or “-al l”, they are both evaluated the same!
SOA Points to a DNS Server that Doesn’t Exist
Lastly, for 99% of the domains in the 10k list I was testing with, this worked like a charm. Unfortunately, there’s always that 1%.
When scanning the domain ustda.gov, the SOA record points to the DNS server max.gov.
The problem here is… when you attempt to get the DNS information from max.gov, you run into errors. After a quick Nmap scan, it’s clear why this is the case:
See the problem? A DNS server with DNS closed!!
MXtoolbox vs. Spoofy
When scanning lists of domains through MXtoolbox’s bulk lookup tool, I noticed there were inaccuracies between what MXtoolbox was producing and what Spoofy was producing. Specifically, as shown in the screenshot below MXtoolbox was not finding DMARC records accurately:
This is seemingly an issue with using Google DNS for the lookups.
Don't Take Email Security for Granted
To sum up, email spoofing is a tactic used by cybercriminals to trick recipients into believing that an email is coming from a legitimate source. This is a serious issue as it can lead to the theft of sensitive information or the execution of actions that benefit the attacker. It is crucial to understand the risks associated with email spoofing and to take the necessary steps to safeguard against it, as email is a vital means of communication for individuals and organizations alike. Email security should be a top priority, since it is a primary target for cyberattacks such as phishing, malware, and ransomware .
If you want to level up your email spoofing skills, take a deep dive into Spoofy by watching the ninth episode of our Tool Talk series with Matt Keeley, the tool's creator.
Subscribe to Bishop Fox's Security Blog
Be first to learn about latest tools, advisories, and findings.
Thank You! You have been subscribed.
