Examine our research from the last year in the ReliaQuest 2024 Annual Cyber-Threat Report
Reduce Alert Noise and False Positives
Boost your team's productivity by cutting down alert noise and false positives.
Automate Security Operations
Boost efficiency, reduce burnout, and better manage risk through automation.
Dark Web Monitoring
Online protection tuned to the need of your business.
Maximize Existing Security Investments
Improve efficiencies from existing investments in security tools.
Beyond MDR
Move your security operations beyond the limitations of MDR.
Secure with Microsoft 365 E5
Boost the power of Microsoft 365 E5 security.
Secure Multi-Cloud Environments
Improve cloud security and overcome complexity across multi-cloud environments.
Secure Mergers and Acquisitions
Control cyber risk for business acquisitions and dispersed business units.
Operational Technology
Solve security operations challenges affecting critical operational technology (OT) infrastructure.
Force-Multiply Your Security Operations
Whether you’re just starting your security journey, need to up your game, or you’re not happy with an existing service, we can help you to achieve your security goals.
Detection Investigation Response
Modernize Detection, Investigation, Response with a Security Operations Platform.
Threat Hunting
Locate and eliminate lurking threats with ReliaQuest GreyMatter
Threat Intelligence
Find cyber threats that have evaded your defenses.
Model Index
Security metrics to manage and improve security operations.
Breach and Attack Simulation
GreyMatter Verify is ReliaQuest’s automated breach and attack simulation capability.
Digital Risk Protection
Continuous monitoring of open, deep, and dark web sources to identify threats.
Phishing Analyzer
GreyMatter Phishing Analyzer removes the abuse mailbox management by automating the DIR process for you.
Integration Partners
The GreyMatter cloud-native Open XDR platform integrates with a fast-growing number of market-leading technologies.
Unify and Optimize Your Security Operations
ReliaQuest GreyMatter is a security operations platform built on an open XDR architecture and designed to help security teams increase visibility, reduce complexity, and manage risk across their security tools, including on-premises, clouds, networks, and endpoints.
Blog
Company Blog
Case Studies
Brands of the world trust ReliaQuest to achieve their security goals.
Data Sheets
Learn how to achieve your security outcomes faster with ReliaQuest GreyMatter.
eBooks
The latest security trends and perspectives to help inform your security operations.
Industry Guides and Reports
The latest security research and industry reports.
Podcasts
Catch up on the latest cybersecurity podcasts, and mindset moments from our very own mental performance coaches.
Solution Briefs
A deep dive on how ReliaQuest GreyMatter addresses security challenges.
White Papers
The latest white papers focused on security operations strategy, technology & insight.
Videos
Current and future SOC trends presented by our security experts.
Events & Webinars
Explore all upcoming company events, in-person and on-demand webinars
ReliaQuest ResourceCenter
From prevention techniques to emerging security trends, our comprehensive library can arm you with the tools you need to improve your security posture.
Threat Research
Get the latest threat analysis from the ReliaQuest Threat Research Team. ReliaQuest ShadowTalk Weekly podcast featuring discussions on the latest cybersecurity news and threat research.
Shadow Talk
ReliaQuest's ShadowTalk is a weekly podcast featuring discussions on the latest cybersecurity news and threat research. ShadowTalk's hosts come from threat intelligence, threat hunting, security research, and leadership backgrounds providing practical perspectives on the week's top cybersecurity stories.
March 26, 2024
About ReliaQuest
We bring our best attitude, energy and effort to everything we do, every day, to make security possible.
Leadership
Security is a team sport.
No Show Dogs Podcast
Mental Performance Coaches Derin McMains and Dr. Nicole Detling interview world-class performers across multiple industries.
Make It Possible
Make It Possible reflects our focus on bringing cybersecurity awareness to our communities and enabling the next generation of cybersecurity professionals.
Careers
Join our world-class team.
Press and Media Coverage
ReliaQuest newsroom covering the latest press release and media coverage.
Become a Channel Partner
When you partner with ReliaQuest, you help deliver world-class cybersecurity solutions.
Contact Us
How can we help you?
A Mindset Like No Other in the Industry
Many companies tout their cultures; at ReliaQuest, we share a mindset. We focus on four values every day to make security possible: being accountable, helpful, adaptable, and focused. These values drive development of our platform, relationships with our customers and partners, and further the ReliaQuest promise of security confidence across our customers and our own teams.
More results...
In our previous extended blog, Tackling Phishing: The Most Popular Phishing Techniques and What You Can Do About It, we covered a range of the different techniques attackers (whether sophisticated nation state or low-level hacker) choose when performing their phishing campaigns. One of the most prevalent was email spoofing. In this blog we’ll explain email spoofing in more detail, as well as providing a practical guide for how you and your organization can fight this tactic and reduce the risk of successful phishing attempts.
We also put out a podcast recently on this topic – check it out here.
For as long as there have been electronic communications, or any communications for that matter, there have been people attempting to intercept or impersonate the sender and the message. Back in the Roman Empire that involved faking seals on the backs of letters. In the modern day, it’s all about spoofing the “From” address in an email.
Email spoofing has been around for a long time and it’s still going strong, flooding inboxes and spam folders with the usual malicious documents or links to a landing page cloned from a legitimate service.
Figure 1 – Simple Python code for sending a spoofed email through an open relay
Spoofing an email is a relatively easy process: all it takes is for the attacker to create, compromise or find a Simple Mail Transfer Protocol (SMTP) server that allows the forger to send the spoofed emails.
In order to understand spoofing in more detail, we should first look at what an email in composed of.
You can think of an email in the same way you would an old-fashioned letter. Just as that letter would need to be addressed to a specific person and/or location, so too do emails.
RCPT TO: [email protected]
Return Address: sender + address
From: Sender
Subject: Document Title
Date: Date of writing.
Body: Message content, often text or HTML formatted.
From: Author
Title: Document Title
Date: Date of writing
Body: Letter content
As you can see, postal letters and emails have very similar structures, aside from, perhaps, the return addresses.
When an email is sent from your email client of choice, the process is generally the same. You provide the To, From, Subject and Body, and the client application will then deal with the rest.
Sending the content is straightforward and achieved with three commands.
The first two commands are part of the envelope detailing where the email needs to go.
The next commands detail any information to be populated inside the envelope (The letter), which will contain, To, From, Subject, Date, and other headers. The end of the DATA section is identified by a line containing a single period.
From: “Sender Name” <[email protected]>
To: “Recipient Name” <[email protected]>
Subject: Test Email
Date: Wed, 2 Jan 2019 10:00:00
Hello,
This is just a test!
Regards
Sender
.
For an email to be spoofed, it is as simple as changing the from email address on the envelope. As an example, if you were to replace the “MAIL FROM” value with a different sender email address, and populated the required commands and headers, you have yourself a spoofed message.
The most common mail providers implement measures that allow the recipient to check where the MAIL FROM domain should originate from, such as SPF (more on that shortly).
Spoofing really is as simple as that. For example, the recent sextortion campaigns spoofed the recipient email addresses to convince the recipient that the sender has control over their email. They are also often used to perform Business Email Compromise or CEO fraud, by spoofing the email address of a colleague or executive level member of the organization.
MAIL FROM: [email protected]
While there are many techniques and tools that can be used to craft and distribute phishing emails, the tooling is designed to run phishing engagements for organizations (at least for the most part). The tools may aid in the creation of phishing landing pages, or email content. Of course, this would require an existing mail server, which could be gained or provisioned in many ways.
While creating your own mail server is pretty straightforward, there is a significant digital trail that is left behind in order for an email to be received successfully. Done incorrectly, and it will end up in a spam folder or rejected by the server. Configuring domain name system (DNS) records for the server, ensuring the hosting IP has not been involved in similar campaigns and has not ended up on blacklists: these activities can all be very time consuming.
These days most sites and servers have a SMTP server for sending alerts or marketing emails. SMTP is a protocol for sending e-mail messages between servers. However, compromising a site and then modifying the configuration and sending domain to reflect the spoofed domain is always an option, though this is a lot more hands-on and again requires time and some level of know-how.
Ecommerce sites often have some kind of email feature that is commonly abused to spoof or send spam, but even “hardened” servers that may require authentication are continuously being brute-forced, with successfully compromised accounts then sold or traded online.
If the forger is looking for mass-distribution, then Open Relay servers would be the likely choice. Simple misconfigurations of SMTP servers often leave them open to allow anyone to connect without authentication and to specify the “To” and “From” addresses, as well as the content and any other fields they want to populate.
By looking at Shodan we can identify more than 6,000,000 SMTP servers; while not all of these will allow Open Relay, the amount that do would surprise you. These can be pretty ephemeral too. Quite often you will find that a development or staging servers are deployed with default or weak SMTP service configurations leaving them open to abuse. Threat actors will often scan for these open relay services, validate them, and then share them publicly or trade them on forums. The attacker now has a large list of servers that they can send their spoofed emails through.
Figure 2 – SMTP Servers running on the standard port (Port 25 with SMTP banner)
So, we all know this happens and now we know how, but how can we prevent spoofing?
SMTP is an aged protocol with security plugins bolted on. Unfortunately, like many protocols, the threat model has changed since the standard was proposed. That said, as the need and demand has increased, multiple duct tape-style fixes have become available. Let’s look at a few of them.
This type of SPF does not protect you from the sun. It was designed to help detect and block spoofed e-mail messages, but it doesn’t really do that very well either.
Sender Policy Framework – or SPF as it is commonly known – is a solution created in an attempt to validate the source of an email message received by a mail system.
Unfortunately, SPF policies rely on the receiving mail server to actually do something about it. SPF policies work by adding a TXT record to your email domain’s DNS (domain name server) that identifies the authorized mail servers for sending email for this domain. When the recipient mail server receives the message, its spam filter, if configured to do so, will check for the existence of a SPF record in the “From” domain’s DNS entries. If it exists, it will then check if the origin server matches those included in the record. The action that is taken next is up to the spam filter.
Here is an example record:
v=spf1 include:mail.example.com -all
This very basic example first identifies the SPF record version, and then provides the fully qualified domain name (FQDN) for the authorized e-mail server for this domain. This is followed by the action, which is set to hard fail. The intention of a hard fail is to instruct a recipient mail system to reject the message, this is noted by the “hyphen all (-all)”.
These records can also be used to specify IP addresses and blocks, and you have several actions to choose from. “~all” for instance is a soft fail that is used when the source of legitimate emails is less certain; this tends to just increment the spam likelihood score. On the other hand, “?all” is neutral for when you are really unsure about where your domains emails are coming from.
The actions taken with each of these actions is down to the recipient mail server and spam filter. The policy actions such as neutral, soft or hard failures are often used to determine whether the email is spam or a legitimate message, with multiple other factors are also being considered.
Figure 3 – Spoofed email without SPF (Inbox)
Figure 4 – Spoofed email with SPF hard fail (Junk)
We have seen with SPF that there are flaws and this is what DMARC tries to make up for. While the action of an SPF failure is down to the receipt systems with SPF alone, DMARC gives the receipts some assistance by providing instructions in the event of policy failure such as SPF. DMARC not only advises the receipt to quarantine or reject the email message on failure, but also asks for a report of the message to be sent to a reporting address. This is a great step for gaining some insight into spam/malspam campaigns spoofing your organisation.
V=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected];
This example again identifies the DMARC _dmarc TXT record that needs to be added to the email domain’s DNS. The record starts with its record version, followed by the policy that is set to none for reporting only, though this could be set to something like quarantine or reject. Reporting gives you a good initial view of any legitimate sender mail servers you may have missed from the SPF includes or DKIM configurations. The rua value is the address for sending the aggregate (rua) report, which is useful for gaining insight into all messages reported to have been sent from your domain. The ruf mailto is for policy failure reports. Additionally, both ruf and rua allow multiple mailto addresses for reports, providing a good way to get the information into multiple systems if required.
Delivery for DMARC reports are generally sent every 24 hours by most major mail providers. The delivery timeframe is configurable in the TXT records; however, these are often ignored.
Figure 5 – Email delivery failure due to DMARC policy
Figure 6 – Extract from daily DMARC report
DKIM is a bit more complex and has a habit of breaking mail systems if incorrectly configured. On the other hand, if correctly configured it can provide a level of integrity and authenticity to outbound messages, providing recipients with the confidence that the email message is legitimate by using a digital signature to sign email messages as they leave the origin mail server.
As with SPF and DMARC, TXT DNS records are required; however, with DKIM this is used to publish the signer’s public key, which the recipient mail server then uses to verify that the content signed by the digital signature is included in the email message headers.
Here is an example DKIM record:
V=DKIM1; k=rsa; p=PUBLICKEY
Like the version records for SPF and DMARC, the record starts with the version. With DKIM you then have the “k=” that identifies the algorithm used for the public key, followed by a base64 encoded public key itself.
With DKIM there are many services that provide help with generating public keys and entries for DKIM records. Most cloud-based mail solutions have built in functionality for creating these records, with some even integrating directly with your domain registrar in order to automate the record configuration.
Figure 7 – Successful delivery with SPF, DKIM and DMARC
While all these solutions work well together, it all comes down to the recipient mail systems checking the records and taking action. It is worth keeping in mind that certain cloud mail providers such as Outlook365 take configurations such as SPF and DKIM very liberally, only using them to classify the failed messages as spam, effectively sending them to the junk folder. The outcome of this is that if any client-side configurations such as domain trust are implemented, spoofed messages will bypass these policies and arrive in the user’s inbox.
These solutions are what we have to work with in order to protect our organizations’ brands and reputations, but they won’t prevent typo or domain squat-based brand spoofing, or even malware infections distributing spoofed emails through legitimate domains.
As previously mentioned, if you are using cloud-based mail providers there is generally a lot of support and even automation when it comes to setting up the records for these deployments. Though keep in mind that DMARC reporting with no action is always a good place to start in order to ensure that you are not accidentally instructing recipient mail solutions to reject the messages that your marketing team have sent out through a third party, or your cloud mail solution pool of mail server IP addresses.
By implementing additional security measures such as SPF, DMARC and DKIM you are not only reducing some of the risks to your employees (by making the spoofing of your domain more difficult), you are also reducing some of the risk to your customers and lowering the risk of brand misuse and the knock-on reputational damage.