• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar

Red Sift Blog

Red Sift Blog
  • redsift.com
  • Featured
  • Who are we?
  • Get in touch
You are here: Home / OnINBOX / The ‘Friendly From’ is not your friend

The ‘Friendly From’ is not your friend

by Grant Revan
April 22, 2020August 24, 2022Filed under:
  • DMARC
  • OnINBOX

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

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)

Related

Tagged:
  • email security
  • Phishing
  • spoofing

Post navigation

Previous Post Featured: Sifted – Cybersecurity startups come to the rescue
Next Post Introducing the Red Sift Partner Program

Primary Sidebar

Subscribe to our blog and be the first to get updates!

Categories

  • AI
  • BEC
  • BIMI
  • Brand Protection
  • Coronavirus
  • Cybersecurity
  • Deliverability
  • DMARC
  • DORA
  • Email
  • Finance
  • Labs
  • News
  • OnINBOX
  • Partner Program
  • Red Sift Tools
  • Work at Red Sift
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • October 2016

Copyright © 2023 · Milan Pro on Genesis Framework · WordPress · Log in