The ‘Friendly From’ is not your friend

In writing this blog I’m presented with a dilemma. I don’t know who is going to read this, black hat or white hat. However, I take the view that it’s better to be aware of the issue so you can mitigate against it, rather than be blind to it and find out about it only after you or your organization has fallen victim to it.

As part of my everyday job as a Sales Director at Red Sift, I have to show organizations how easy it is to send a spoof email that will pass through their mail gateways and security systems without detection. When I send someone an email using their own email address, or that of their boss, 95 times out of 100 it will arrive in their mailbox within seconds. I never get bored of seeing the shock on people’s faces when this happens. It always makes me think about a famous quote:

“Any sufficiently advanced technology is indistinguishable from magic.”

Arthur C Clarke’s third law

Why do people in IT roles – even those responsible for security – react to a spoof email cutting through their security defenses, like a hot knife through butter, as if they have just seen a magic trick?

Is it because people have been told that they are safe: Protected by antivirus systems, secure email gateway, URL filtering systems, etc? This lulls you into a false sense of security, despite the fact that we all keep getting told that phishing is by far the number one vector of choice for hackers to get into your enterprise.

The problem is that all these inline systems are looking for something bad. A piece of malware in an attachment, malicious links, or language that appears spammy. If a phishing email contains none of these things but is well crafted to look and read like a legitimate business email, then it will slip through the cracks and reach your inbox.

Let’s look at a recent email that was shared with me by one of my customers. I have anonymized the email to protect the innocent.

The email was supposedly from the CEO and both the ‘Friendly From’ field and the ‘From’ were perfect.  (In the example below, the ‘Friendly from’ field is just a text field ‘John Smith’, and the ‘From’ field is what the recipient sees as the email address of the sender – in this case (john.smith@correctdomain.com). It was sent to the General Manager of the organization.

EG it was in the from –        John Smith <john.smith@correctdomain.com>

The email got through to the GM’s inbox, but they were suspicious about the context and a quick look at the email headers revealed it was a fake email.

But here is the truly clever part – the return address was in the from

John Smith (john.smith@correctdomain.com) <contact@sslwebxxx.xxx>

When the intended victim hit reply they might only see the following in the reply window

John Smith (john.smith@correctdomain.com)

and not the actual email address going back to the hacker. Eg. contact@sslwebxxx.xxxx

The round brackets make it look like there is a real email address there, but in actual fact, all you are looking at is the ‘friendly from’ field which is just text. If you hover over the reply address it reveals the true email address you are replying to namely ‘contact@sslwebxxx.xxxx

Most people would not realize that unless the email address is bound by angle brackets ‘< >’ then it is not a real email address.

Let me illustrate that in some screenshots.

Here is an email I sent with a ‘Friendly From’ address of Grant Revan (grant.revan@redsift.io) – the part in the round brackets appears to be an email address but in fact is just text. What is surprising is that there are no restrictions on the special characters you can use in this field, – for example, you can use the @ symbol and () signs.

So in the above screenshot, the list window in Outlook only displays the ‘Friendly From’ and the use of the round brackets makes this look very legitimate. In the preview window, there are what appear to be two email addresses but only the one inside the <> is the real one. A user may not spot this.

Here is the really worrying thing – if the recipient clicks ‘reply’ here is what they see:

At the bottom right of this screen shot it shows the ‘reply address’ to which the response is going to be sent.

In this instance, the email client displays the ‘Friendly From’ field not the real email address! This varies by email service provider.

It looks like you are replying to grant.revan@redsift.io – but in fact, it’s going to the hacker’s address which is “admin@fake.com”.

Start by rejecting fake emails from your own domains with DMARC 

One of the only surefire ways of defending against email attacks, which we see so often, is to implement the email protocol, DMARC. And it’s not ok to just have it in place, you need to configure it so it’s set to the ‘reject’ policy, meaning fake emails don’t pass go, don’t collect £200 and don’t trick users into handing over confidential information. The anonymised attack example I first showed you would have been prevented by DMARC. Take a look at OnDMARC, our cloud-based application, that will guide you through how to quickly and easily configure DMARC for all your legitimate email sources.

However, the second illustrated example would not have been prevented by DMARC –  but was detected by our inbound email solution OnINBOX.

As I have shown in the example above, the use of round brackets around a legitimate email address inserted into a ‘Friendly From’ field can result in emails that may look very convincing to many users. This will be the case on most mobile devices too.

If you want to know how to highlight this to the recipient inside the email, take a look at OnINBOX, our inbound solution for Office 365 or G Suite. OnINBOX will flag that the email is impersonating a trusted contact and is not actually coming from the real email address associated with them (in fact, you can see this in the example above – the RED icons for ‘Authentication’ and ‘Trust’ show this email should not be trusted). OnINBOX acts like a security analyst in every email.

Finally, should this type of attack have a name? How about the “REVAN attack” as there is history of naming attacks after star wars characters: Google it.

Want to know more? You can contact me via the email address shown throughout this blog or visit the Red Sift website.

Red Sift find out more

PUBLISHED BY

Grant Revan

22 Apr. 2020

SHARE ARTICLE:

Categories

Recent Posts

VIEW ALL
Email

The best tools to protect yourself from SubdoMailing

Francesca Rünger-Field

In late February 2024, ‘SubdoMailing’ became a trending search term overnight. Research by Guardio Labs uncovered a massive-scale phishing campaign that had been going on since at least 2022. At the time of reporting, the campaign had sent 5 million emails a day from more than 8,000 compromised domains and 13,000 subdomains with several…

Read more
Product Release

Red Sift’s Spring 2024 Quarterly Product Release

Francesca Rünger-Field

This early into 2024, the cybersecurity space is already buzzing with activity. Emerging standards, such as Google and Yahoo’s bulk sender requirements, mark a new era of compliance for businesses reliant on email communication. At the same time, the prevalence of sophisticated cyber threats, such as the SubdoMailing campaign, emphasizes the continual hurdles posed…

Read more
Email

Navigating the “SubdoMailing” attack: How Red Sift proactively identified and remediated a…

Rebecca Warren

In the world of cybersecurity, a new threat has emerged. Known as “SubdoMailing,” this new attack cunningly bypasses some of the safeguards that DMARC sets up to protect email integrity.  In this blog we will focus on how the strategic investments we have made at Red Sift allowed us to discover and protect against…

Read more
Email

Where are we now? One month of Google and Yahoo’s new requirements…

Rebecca Warren

As of March 1, 2024, we are one month into Google and Yahoo’s new requirements for bulk senders. Before these requirements went live, we used Red Sift’s BIMI Radar to understand global readiness, and the picture wasn’t pretty.  At the end of January 2024, one-third of global enterprises were bound to fail the new…

Read more