none
Mail rule to stop phishing message with fraudulent DisplayName and external address RRS feed

  • Question

  • Hi, 

    We are on Exchange Online (Office 365 Business Essentials) and we keep getting emails in like the following:

    > From: John Cahill <ceooconnect@naver.com>
    > Sent: 14 March 2017 11:22:22
    > To: Sarah Smith
    > Subject: Urgent Request

    > Hi Sarah,

    >
    > We need to send a fast payment of £16,605 GBP to England, what information do you need to get this processed > now?
    >  
    > Thanks,
    > John Cahill

    This is a phishing message as the email address is external to the organisation, but the Display Name is correct (this is a user in our organisation) and this is worrying.

    I went into the Exchange Admin Center > Mail Flow > Rules and created the following rule for the organisation:

    

    However, when I test this rule with an external email address with the DisplayName "John Cahill", it does not work and the email arrives unchanged directly into my inbox.

    What am I doing wrong?

    Note that I cannot block the sender in Spam filters as the email addresses change regularly, but the DisplayName does not.


    Tuesday, March 14, 2017 6:31 PM

Answers

  • Ok, found the solution myself.

    Based on this article: http://markgossa.blogspot.ie/2016/01/spoofed-email-display-name-exchange-2016.html

    You use

    "A message header matches...." From header matches John Cahill

    and

    Sender is external to the organisation.

    • Marked as answer by mccannf Tuesday, March 14, 2017 9:29 PM
    Tuesday, March 14, 2017 9:29 PM

All replies

  • You might want to change the rule to The Sender... Domain is naver.com
    Tuesday, March 14, 2017 8:25 PM
  • Thanks, but these phishing attempts come from different domains. Only the Display Name is consistent.

    In any case, should the rule not catch that this is an external address?


    • Edited by mccannf Tuesday, March 14, 2017 8:50 PM
    Tuesday, March 14, 2017 8:49 PM
  • Thanks, but these phishing attempts come from different domains. Only the Display Name is consistent.

    In any case, should the rule not catch that this is an external address?



    I haven't tested that specific rule. have you looked at the headers and/or message tracking to see if the IPs are the same sending server? You could simply block that IP

    Exchange 2007 reaches end of life on April 11th. What’s your plan to move?

    Tuesday, March 14, 2017 9:15 PM
    Moderator
  • Hey,

    Take a look at this rule:

    http://markgossa.blogspot.com.br/2016/01/spoofed-email-display-name-exchange-2016.html

    Transport rule


    The way to get Exchange to recognize this email is to set up a custom transport rule which we can use to identify the email and perform any action on it. To identify the display name in the email, we need to set up our transport rule conditions to include emails which have "Rick Mehew” in the email’s “From” header and only email from senders outside the organization so it doesn’t affect the internal email delivery for Rick Mehew. 

    Note that if Rick Mehew has an external account (i.e. a personal email account which is not part of the Exchange organization) then you'll need to add this email address as an exception to the rule so it is not marked as spam.

    In this example we are prepending the subject line of the email with SPAM to notify users:

    image

    Now when we get emails from rick.mehew@gmail.com, they will appear as below with “SPAM” prepended to the subject to inform users:

    image

    This should help you out with this type of issue. All the best!


    Por favor, se te ajudei, não esqueça de marcar como resposta. Acesse meu blog: http://msexperts.blog.br ____________________________________________________________ Please remember to mark the replies as answers if they help.

    Tuesday, March 14, 2017 9:21 PM
  • Ok, found the solution myself.

    Based on this article: http://markgossa.blogspot.ie/2016/01/spoofed-email-display-name-exchange-2016.html

    You use

    "A message header matches...." From header matches John Cahill

    and

    Sender is external to the organisation.

    • Marked as answer by mccannf Tuesday, March 14, 2017 9:29 PM
    Tuesday, March 14, 2017 9:29 PM
  • Glad to hear that you have got it.

    Thank you for the sharing.


    Best Regards,
    David Wang
    TechNet Community Support


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, March 15, 2017 3:42 AM
    Moderator
  • Has anyone actually found the setting "A message header matches..." anywhere in the transport rules section? I am simply not seeing it. I also opened a case with microsoft and they couldnt give me any answers and (surprise!) were of no help.
    Wednesday, April 4, 2018 1:59 PM
  • I'm not seeing it in my tenant either.
    Wednesday, April 4, 2018 5:04 PM
  • I'm not seeing it in my tenant either.

    Look at the bottom choice.

    Its phrased a little differently

    Wednesday, April 4, 2018 6:54 PM
    Moderator
  • I'm not seeing it in my tenant either.
    Are you hitting the "More options..." link near the bottom of the rule? That should open up a number of new options including "A message header... > matches these text patterns" where the setting can be configured.
    Friday, April 6, 2018 5:24 PM
  •   

    My problem is exactly the same as you had but there was one additional thing that might keep the rule from working.  In the email header, it shows that it is passing all  of MS security tests  because in some manner the hacker has managed to added the Fake external domain used in the fake sender address to our own Domain resulting in MS scans reporting that we "authorized" email to be sent by the Fake domain (which also varies like yours).

    Even though the AntiSpam tests shows a result of "Untrusted" and several others also say "untrusted" It still passes through because apparently it appears to Outlook to be another of our own domains.  It even shows the fake domain adjacent to our own separated by a semicolon in the header.

    So I am not sure if that will still work as meeting the "outside the organization" part of the rule. Outlook might consider this as still being INSIDE since it says we authorized the email.

    I am definitely going to test the rule you applied and I fully understand some of the comments following your post as it seems MS has decided to hide all kinds necessary to know  sub>sub>sub option in various More Options’ or similar.  It took forever to set up a rule that allows people who are using an Alias to be able to tell which email was sent to the alias and which was sent to their real email address for the same reason. 


    I can't take credit for all that work.   Luckily I found someone like you that had already figured it out for the same use.  It requires you to figure out which fields and what option can be modified and in what way to make the rule work BEFORE you even start writing the rule.   

    I really appreciate your posting the full “How” to get to where you went.  There is no "Roadmap" for many of these functions nor is there a good way to figure out exactly what the choices made will do as you cannot see ALL those choices.  They don’t even show up until you select the one ahead of the one you need.



    • Edited by Questorfla Friday, August 31, 2018 5:44 PM
    • Proposed as answer by Bob Ruckdeschel Wednesday, November 14, 2018 5:33 AM
    • Unproposed as answer by Bob Ruckdeschel Wednesday, November 14, 2018 5:33 AM
    • Proposed as answer by Bob Ruckdeschel Wednesday, November 14, 2018 5:33 AM
    • Unproposed as answer by Bob Ruckdeschel Wednesday, November 14, 2018 5:33 AM
    Friday, August 31, 2018 5:33 PM