Avanan has been catching multiple attacks against its customers using a new phishing method called Mailsploit. We have observed this attack on both Office 365 and Gmail customers.
What makes this attack extremely dangerous is that there is absolutely no way for the end-user to distinguish a phishing email from a genuine one. They look exactly the same. Here’s how it works and what you can do to protect yourself.
Pretending to be someone else is nothing new when it comes to email attacks. In a standard attack, the email server and the email client that present the email to the end-user analyze and show the same email. Therefore, the hackers cannot just spoof an internal sender because it will fail the security checks at the server. Hackers need to find ways to impersonate a trusted entity to the end-user while also being trusted by the email server and its security layers. This results in the hackers leaving some noticeable clues for the end-users, such as misspelled URLs or companies that don't match the domain.
What's unique about Mailsploit is that it allows hackers to spoof two email addresses in the sender field: one to be presented to the end-user as a trusted sender, possibly another internal user, and another to show to the email server and the email security layers to pass all security checks in SPF, DKIM, or DMARC. This creates a very dangerous and elusive way to conduct a phishing attack.
This is possible as a result of hackers exploiting an implementation difference between email clients and email servers/email security layers when crafting the sender address. Here's an example of how an email using Mailsploit would look to a recipient:
An example from the mailsploit.com website shows an email spoofed to come from potus@whitehouse.gov.
Email headers, most importantly the “From:” field, are only supposed to contain ASCII characters. However, recommendation rfc1342 (from 1992) allows one to encode non-ASCII characters into an email header without breaking the field. It is through taking advantage of this loophole that Mailsploit rewrites these fields.
The email server and the email security layers standard implementation take the email domain of the sender as all characters after the last '@' sign. Everything before the '@' is the sender name/mailbox within that domain. For example, the hacker will put the following code in the sender header,
From: =?utf-8?b?${base64_encode('potus@whitehouse.gov')}?==?utf-8?Q?=00?==?utf-8?b?${base64_encode('(potus@whitehouse.gov)')}?=@mailsploit.com
which is then read by the server and security layers as
From User: potus@whitehouse.gov\0(potus@whitehouse.gov)
In Domain: mailsploit.com
The domain, “mailsploit.com”, is the token that is checked for legitimacy to make sure it was not spoofed. Therefore, what the hackers need to do is send the email from an account in a legitimate domain.
After the email passes the server checks and is put in the end user's inbox, your email client attempts to present the entire string of the email:
From: =?utf-8?b?${base64_encode('potus@whitehouse.gov')}?==?utf-8?Q?=00?==?utf-8?b?${base64_encode('(potus@whitehouse.gov)')}?=@mailsploit.com
When converting the non-ascii encoding from ascii to non-ascii, the 'From' string translates into:
From: potus@whitehouse.gov\0(potus@whitehouse.gov)
And as in most coding languages, Null termination ('\0') is used to mark the end of a string. What the client actually processes and presents is potus@whitehouse.gov.
So, to summarize the scheme: the hackers can send an email from a trusted domain to bypass the email security at the receiving server, and then show a completely different 'From' address—any address they want to choose—on the email client that opens the email to the end-user.
We searched through the attacks we've seen against our customers and still haven't seen Mailsploit used with code injection against our customer base, but as illustrated in the original article about Mailsploit, crafting the "From" field can be used to inject malicious code right into the header fields.
Email security tools only scan the email body for malicious code because the header fields aren’t designed to contain non-ASCII characters. But in this case, through the "From" field, code can get into the email header, pass security unscanned, and reach the end-user.
Avanan’s multi-layered impersonation detection goes beyond what any email client or MTA can provide, scanning 300+ indicators in every email that feed into a machine learning algorithm. In this case, Avanan security layer detected this as a suspcious 'From' pattern. By finding an email address within the 'From' string that was different than the reported sender, this email was flagged as a 'user impersonation' attempt.