The “From” field in an email–or even in snail mail–is just an address line that the sender types in. Just like anyone can go to a post office and send a card that comes from Santa, anyone can do that with email.
Most users never actually do this–it’s done automatically by their email program. You open up Gmail to send an email and it’s assumed it’s coming from your email.
However, it’s not a guarantee that it will match.
A program can easily send emails from some.server.com and write in the address line anything they like. For example, the program can write in something like From: Info@avanan.com
For the end-user, they will check the from field and think that is the sender, often without thinking twice about it.
Naturally, security tools on the receiving end will try to check whether the ‘From’ address is legitimate. If they see an email received from some.server.com having the address line of info@avanan.com, it would be rejected by the recipient’s server because the sender server(some.server.com) has nothing to do with avanan.com.
However, hackers have found a new way to get around this, by inserting a relay in between the server and the inbox.
An SMTP relay service can be a valuable service for organizations that like to send out mass emails. Essentially, businesses use SMTP relay services--of which there are many-- to send marketing messages to a vast database of users without being blocklisted. Utilizing trusted SMTP relay services ensures messages get delivered.
Many organizations offer this service. Gmail does as well, with the ability to route outgoing non-Gmail messages through Google.
However, these relay services have a flaw. Within Gmail, any Gmail tenant can use it to spoof any other Gmail tenant. That means that a hacker can use the service to easily spoof legitimate brands and send out phishing and malware campaigns. When the security service sees avanan.com coming into the inbox, and it’s a real IP address from Gmail’s IP, it starts to look more legitimate.
Starting in April 2022, Avanan researchers have seen a massive uptick of these SMTP Relay Service Exploit attacks in the wild, as threat actors use this service to spoof any other Gmail tenant and begin sending out phishing emails that look legitimate. Over a span of two weeks, Avanan has seen nearly 30,000 of these emails. In this attack brief, Avanan will analyze how hackers are using exploits in this service to get into the inbox.
Attack
In this attack, hackers are taking advantage of Google’s SMTP Relay service to send spoofed emails.
Hackers can utilize any Gmail tenant, from small companies to large, popular corporations. This works when DMARC=reject is not set up.
Once spoofed, they can send out phishing emails that are more likely to get into the inbox, as it leverages the inherent trust of legitimate brands.
Once in the inbox, hackers hope that end-users will click on a malicious link or download a malicious document, to steal credentials.
- Vector: Email
- Type: Credential Harvesting
- Techniques: SMTP Relay Exploit
- Target: Any end-user
In this attack, threat actors are utilizing the SMTP relay service to spoof brands and get into the inbox.
Email Example #1
The key is using smtp-relay.gmail.com as the SMTP service. This email is sent through one domain, but is delivered into the inbox from venmo.com
Here are the details:
Received: from 20.78.147.119 ([20.78.147.119]) by smtp-relay.gmail.com
X-Relaying-Domain: sedkahusa66.com
From: venmo@venmo.com <venmo@venmo.com>
Email Example #2
Techniques
Hackers are using the SMTP Relay Service of Gmail to spoof domains and send phishing emails into the inbox.
Phishingemail@phishing.com wouldn’t want to send their email from that domain. They would want the legitimacy of a major brand. So, using this service, they instead send their email from, say, paypal.com (assuming paypal.com uses Gmail). Email scanners see that it’s coming from Gmail’s trusted relay service–and for good measure, often a trusted brand–and it sails right through to the inbox. One bad domain is able to send emails from another good domain.
Think about it this way: Company x sets up a Gmail Relay. They can use it to send emails from any other Gmail tenant. This ensures an SPF pass when the recipient runs a check. This ensures that the phishing email will reach the inbox, assuming DMARC=reject is not enabled.
Companies–and individuals–use the SMTP Relay Service precisely because it’s trusted and its purpose is to ensure an email doesn’t end up in the junk folder. And depending on the Google plan, they can send a maximum of 4,600,000 million emails in a 24-hour span (although that would only truly apply to large companies).
This works only if the impersonated brand has its DMARC policy set to none. That's because Google, along with other systems, will point out an explicit mismatch on the email from headers when there is one. (For example, if phisher.com sends out a message from google.com, there will be an indicator of such discrepancy for downstream email systems to see.) Most companies will have a DMARC=reject policy, as Netflix does:
(MX Records, shown above, are public knowledge and can be accessed via sites like MXToolbox.) Following strong DMARC policies like the one seen above is essential and will help protect from these attacks. For example, we haven't seen any spoofs of Netflix while researching this attack, in large part due to their DMARC=reject setup.
Trello, spoofed above, does not have its DMARC reject policy enabled.
One of the reasons they may have disabled DMARC is because they have Proofpoint, a Secure Email Gateway, installed.
All the attacker had to do was send emails from Gmail’s IP address, and SPF would be passed.
It's important to note that any SMTP relay could be vulnerable to this attack. There are a number of SMTP relay services out there.
Avanan has seen a massive increase in these attacks. Through two weeks of April, we’ve seen over 27,000 of these emails.
Avanan notified Google of how hackers were using this relay on April 23rd, 2022.
Best Practices: Guidance and Recommendations
To guard against these attacks, security professionals can do the following:
- Check sender address before interacting with any email
- Set DMARC policy to reject
- Always hover over any link to see the destination URL before clicking on it
- Ensure your email authentication standards are up to par, utilizing best practices from the Messaging, Malware and Mobile Anti-Abuse Working Group, found here.
