Delen via

Combating Display Name Spoofing

  • Artikel

My lack of updates around these parts can be attributed to the craziness of work over the last few months. This afternoon I have some time and am typing this out as quickly as I can before someone notices and gives me something else to work on. Let’s begin.

I’ve recently seen a very big rise in display name spoofing. With technologies in place like DMARC, DKIM, and SPF, attackers are finding it harder and harder to spoof sending domains. Instead, they have reverted to something quite simple, changing their sending display name to be that of an executive in the targeted organization.

For example, an attacker will register a free email account and use any email address. Sometimes the addresses contain the name of the executive that they are trying to spoof. The attacker would then set their display name to match your CEO or some other executive, and then send phishing messages into your organization. The hope is that the recipient won’t look at the sending address, and instead just look at the sending display name. Some recipients may even assume that the sending email is the personal email of the executive and believe it to be real.

The other problem with an attacker using a consumer email account, or even their own domain, is that all checks like DMARC, DKIM, and SPF will all pass (as long as the records are set up correctly) as there is no domain name spoofing happening.

To combat this, I have had customers implement a transport rule that identifies messages that contain the names of key executives in the From field, and which originate from outside of the tenant. The transport rule would look something like that.

Under exceptions, you would add the personal addresses that the executives may use to send mail to the company to ensure those messages aren’t caught by this rule.

The rule is simple and straightforward, but I’ve had customers report having much success with it capturing phishing attempts.

Cheers!

Comments

  • Anonymous
    July 11, 2018
    Thanks for this great tip. Straight forward to setup, some minor change to the Recipient options but does not take long to setup and works well.
  • Anonymous
    August 02, 2018
    This is so helpful. I set up a rule like this in our organization as we can't afford pricey software like Mimecast to do this.
  • Anonymous
    October 17, 2018
    This is fantastic! Thanks so much. We needed this so badly at my org. I implemented and developed a spoof to test it. Worked perfectly.I routed them to Quarantine and set it up to send an incident report to the security group.
    • Anonymous
      October 26, 2018
      Awesome to hear Chyenne!!!
  • Anonymous
    December 13, 2018
    The comment has been removed
    • Anonymous
      December 18, 2018
      The comment has been removed
  • Anonymous
    January 18, 2019
    Why not just drop that third condition, and prepend a disclaimer that warns the users the message came from outside the company? This way, all external message are tagged with a warning, and you can train your users that if they see the warning, and a spoofed internal name, obviously the message is bogus.
    • Anonymous
      February 21, 2019
      You definitely could do that as well. It just depends on your mail flow. If you have a third party that is allowed to send as your domain, depending on the routing, the mail might not be seen as internal and so would trigger the rule which you may not want.
  • Anonymous
    January 22, 2019
    Any reason O365 ATP isn't suggested in your article as that's a premium service that Microsoft already provide? I know you've mentioned it in the comments section but thought it'd make an appearance in the actual post...
    • Anonymous
      February 21, 2019
      Originally I wrote this to target organizations that didn't buy ATP licensing, which is why I used a transport rule.
  • Anonymous
    February 13, 2019
    Hi,I try to replicate this rule, but it doesn't work!!
    • Anonymous
      February 21, 2019
      Can you provide some more details on what you are seeing? Is the rule not triggering at all in your testing?
  • Anonymous
    February 22, 2019
    Wow! I've been doing this for some Months now, Feels so good that other people are thinking alike. This is exactly the same way i set up the rules for my clients. If I had published a write-up on it I would say you copied me. lol
  • Anonymous
    February 27, 2019
    I setup this rule just like you have above and it is not working for me. I can still send emails as "Target User" my@gmail.com and it goes right through. I have it set as "A message header includes From header includes "Target User" or "User, Target"And it is not working.
  • Anonymous
    May 08, 2019
    This works but it has a lot of problems. Any "Send on Behalf of" SaaS or listserv will get blocked. A major problem is if an email is received from a DisplayName which contains the DisplayName which is being filtered. For example, if outside-the-organization user Steve Lunceford emails the organization and 'Steve Lunce' is in the DisplayName filter, it will get caught.This solution is probably fine for a small organization but scaling this would be a false-positive nightmare.
    • Anonymous
      June 12, 2019
      Spoof detection in ATP is the better solution, but if a tenant does not have ATP licensing, this is the next best place to start.