Three Ways To Send Spoofed Emails

Email spoofing comes in many forms and may incorporate social engineering techniques to 'trick' a user into thinking an email originates from a legitimate address. Before deep diving into these techniques, let's briefly recap what email spoofing is.

What Is Email Spoofing?

It's a deceptive practice that abuses a mixture of technical and human psychological vulnerabilities to meet its goal of masquerading a malicious sender as legitimate.

"Email spoofing is when the sender of an email forges (spoofs) the email header's 'From' address, so the message appears to have been sent from a legitimate email address." Email spoofing - Wikipedia

Email Spoofing Techniques

While email spoofing is a highly discussed topic, we frequently only see pieces of the overall issue discussed. In the following section, we'll walk through various spoofing techniques, how difficult they are to execute, and how frequently they're abused.

1. Using A Spoofed Email Display Name

Sophistication: Low - Difficulty: Low - Frequency: Widespread

How is this performed? Forging the 'From' display name is a feature that anyone can take advantage of in modern email clients. This is typically used for legitimate purposes, such as identifying yourself by title or the team you represent (e.g., Help Desk, Payroll, etc.). However, it's frequently also used for malicious intent.

When looking at Gmail, we can see how easy this type of attack is to execute by going to 'Settings > Accounts and Import > Send mail as' and changing this to appear as "Desktop Support".

When delivered to an unsuspecting victim, they may, at first glance, believe the email came from a legitimate source and click the link.

What mitigations exist? User awareness training and spam filtering (to a limited degree). As this is a feature available on all major email clients with no applicable email authentication checks, there's minimal that can be done regarding technical mitigation. Spam filtering engines can be trained to spot keywords, but the most effective mitigation is to train users to spot the real from the fake.

Never rely on the display name to identify a sender. It can display any name the sender wants without any form of authentication. Instead, defer your attention to the actual 'From' email address and assess whether the email passes the 'sniff' test (i.e., were you expecting the email? Is it from a known sender? Is it asking you to click on any links? open a file? forfeit sensitive information? are there uncommon spelling mistakes? etc.).

2. Using A Phishing Domain With Lookalike Sub-Domains

Sophistication: Moderate - Difficulty: Moderate - Frequency: Widespread

How is this performed? Purchasing lookalike domains for the sole purpose of tricking users into thinking they represent a legitimate service is a common mechanism used by threat actors (e.g., over 1,453,131 vetted phishing sites have been included in this open-source domain blocklist).

If we use PayPal as an example, you can purchase any of the below domains through AWS by simply searching against the "PayPal" keyword.

Noting this, a mechanism to further obfuscate the purchased phishing domain is to include a sub-domain that replicates the service being phished. To demonstrate this scenario, we'll create a McAfee-themed phishing email following the below steps:

1. Purchase a phishing domain (e.g. 'macnfee[.]com').
2. Acquire an email delivery service with a trusted IP/SMTP server. This is tricky as most cloud-hosted email delivery services work very hard to prevent malicious actors from utilizing their service as their global reputation ratings take a hit. Because of this, many threat actors end up using services in 'spammer' friendly countries (e.g., China, Russia, etc.).
3. Set up the domains DNS record to include an SPF entry for the sub-domain you plan on using for the delivery of phishing emails (e.g., McAfee-outreach).
4. Begin delivering phishing emails from the trusted IP/SMTP server that look alarmingly legitimate to an unsuspecting victim.

Note: The below email is for demonstration purposes only.

What mitigations exist? To prevent these types of attacks, many major service providers will proactively purchase lookalike domains and park them to prevent malicious abuse. This is only a stopgap and means threat actors must become more creative with their registered domains.

The more effective mitigation is to train spam filters to perform keyword searches of sender sub-domains and train users to spot the real from the fake.

How to spot the real from fake? Never rely on the display name OR sub-domain to identify a sender. Instead, defer your attention to the parent domain (e.g., macnfee[.]com) in the 'From' email address and assess whether the domain represents the service it appears to. This can be done by performing a WHOIS search of the domain to find the owner or by going to the service's website to locate the domain the service is run from.

In some cases, a WHOIS search won't provide meaningful results as some buyers purchase these domains through a proxy service or enter fake details - considering this, the final safeguard is the 'sniff' test (i.e., were you expecting the email? is it from a known sender? is it asking you to click on any links? open a file? forfeit sensitive information? are there uncommon spelling mistakes? etc.).

3. Using SPF-Bypass Through Abuse Of An Inadequately Configured DMARC Record

Sophistication: High - Difficulty: Moderate - Frequency: Common

How is this performed? Please see https://dmarc.org/wiki/FAQ for a detailed overview of each email authentication protocol (i.e., SPF, DKIM, and DMARC). Summing these protocols into a single sentence, each attempts to provide a way for senders to authenticate themselves to receivers as legitimate. For example, the Senders Policy Framework (SPF) is a list published within a domain DNS record that states if you receive an email from any of these ten or so IP addresses. It's from my domain, trust it as we authorize those addresses and discard any other emails purporting to be from us.

The issue is that many domain owners only set up SPF, meaning receivers can rely only on one email authentication protocol. Unfortunately, there's a weakness in the SPF protocol whereby threat actors can trick receivers and ultimately bypass the check. We won't delve deeper into this as SPF-bypass attacks are an entire topic on their own. To fix this loophole, the DMARC protocol was introduced, which includes a security fix. Unfortunately, if we look at the 100 most used domains on the internet today, we can see that 31 of the top 100 domains still haven't implemented a locked-down DMARC policy (this is a consistent theme across many enterprises).

Ultimately, the lack of a locked-down DMARC policy means threat actors can produce spoofed emails that do not indicate malicious intent to end users.

Note: The below email is for demonstration purposes only and was generated through the CanIPhish Cloud Platform.

What mitigations exist? Domain owners need to, at a minimum, implement a locked-down DMARC (quarantine or reject) policy for all domains under their ownership (including any parked domains).

How to spot the real from fake? End users will find it extremely difficult to spot the real from the fake when cyber criminals use this technique to send spoofed emails. Many email clients, such as those offered by Google and Microsoft, now provide an indication that this attack may be occurring - as shown in the above image with a "via cmail31[.]com" snippet at the end of the sender address.' But this is outside what non-technical users can be expected to understand, as the email still appears to come from a legitimate domain.

Wrapping Up

Email spoofing is commonly used to increase the effectiveness of phishing attacks. We hope this article arms its readers with the tools to communicate email spoofing risks effectively so mitigations can be implemented to remediate any weaknesses.

If you're unsure on whether your email infrastructure is vulnerable, you can use the free email spoofing tool provided by CanIPhish.

If you have any questions or need additional advice on detecting or mitigating this security risk, please feel free to contact the CanIPhish team through our contact us page.