Skip navigation

Log in to create and rate content, and to follow, bookmark, and share content with other members.

Targeted Threat Protection: Impersonation Protect

Document created by user.oxriBaJeN4

on Apr 11, 2016•Last modified by user.oxriBaJeN4

on Feb 5, 2019

Version 13Show Document

Like • Show 1 Like1
Comment • 19
View in full screen mode

Identifiers
External Messages
See Also...

Targeted Threat Protection - Impersonation Protect is part of our Targeted Threat Protection suite. You must have another product from this suite (e.g. Targeted Threat Protection - Attachment Protect or Targeted Threat Protection - URL Protect) to use the Targeted Threat Protection - Impersonation Protect product.

The increasing number of "whaling" attacks, usually targeting an organization's senior management, means additional protection is required against email threats that do not contain attachments or URLs. Traditional spam filtering systems are unable to detect these as suspicious, due to their minimal content. Targeted Threat Protection - Impersonation Protect solves this, by:

Looking for combinations of key identifiers commonly found in these attacks.
Tagging a message to make it clear that it is coming from outside your organization.

Identifiers

In the Impersonation Protection Definition, you can specify the number of identifiers that must be triggered before any action is taken. The available identifiers are:

Similar Internal Domain: This checks the similarity of the sender's domain to your internal domains.
Newly Observed Domain: This checks the sender's domain against a list of domains that have only been seen sending traffic in the last week.
Internal User Name: This identifies if the sender's display name (usually the first and last name), is the same as one of your internal user display names, excluding the recipient’s internal username.
Reply to Address Mismatch: This identifies if a mismatch has occurred between the sender’s email address (both Header and Envelope) and the Reply To email address.
Targeted Threat Dictionary: This checks the message content against a one of our Targeted Threat Dictionaries.

Based on whether the required number of identifiers is triggered, you can specify the action to take if an email is identified as suspicious. The action can be:

Bounce
Hold
Tag

External Messages

Additionally, you can help users identify all messages as coming from an external domain regardless of whether any identifiers are triggered. This takes the form of text that can be added to a message's:

Body
Subject
Header

See Also...

3 people found this helpful

Attachments

Outcomes

19 Comments

user.GWD5B2F8vE Jul 14, 2016 8:33 AM
Is it possible to determine what words are noted in the Targeted Threat Dictionary?
1 person found this helpful
Like • Show 1 Like1
Actions
- user.oxriBaJeN4 @ user.GWD5B2F8vE on Jul 14, 2016 11:58 AM
  That's a good question Michael. Unfortunately the dictionary's contents are a moving target. It is updated fairly regularly, so publishing a list of words in it would be out of date pretty quickly. However if you are an Administrator, the notification received contains the word found in the message that matches the entry in the dictionary.
  1 person found this helpful
  Like • Show 1 Like1
  Actions
  - user.GWD5B2F8vE @ user.oxriBaJeN4 on Jul 14, 2016 12:10 PM
    I understand that the list can changed but for testing purposes. It would be good to know what gets picked up.
    1 person found this helpful
    Like • Show 1 Like1
    Actions
user.27lOB6tNEW Aug 3, 2016 3:12 PM
Is there any type of logging to see what messages may have triggered the policy?
1 person found this helpful
Like • Show 2 Likes2
Actions
- user.rYx9BfRmGRA @ user.27lOB6tNEW on Nov 10, 2016 8:27 PM
  bump. trying to troubleshoot something that perceivably should have triggered a TTP Impersonation Protect rule.
  1 person found this helpful
  Like • Show 1 Like1
  Actions
user.4Q3dBNtL1rRo Jan 27, 2017 9:41 AM
Another bump on this thread. Just today we received what looked like a spear phishing email. The display name was for one of our staff who is in an administrator role; however, the email address, which was not hidden, originated from an unknown gmail address. Should impersonation protect have caught this? Thank you.
2 people found this helpful
Like • Show 1 Like1
Actions
user.oXxABNhXG5YL Feb 1, 2017 4:00 PM
We have noticed an increased occurrence of receiving impersonations from different name formats. For example, our internal display name format is "Last name, First name" so "Doe, John." If we receive an external email from someone named "Doe, John" Mimecast will block it. However, if we receive email from "John Doe" Mimecast will let it through. I did not see attackers trying this for many months but it has been on a rapid rise.

Is there any way to have impersonation protect protect against this?

For our CEO we added a new mailbox in the "John Doe" format, but now other attackers are attempting to user other internal employee names and we cannot create fake mailboxes for everyone.
1 person found this helpful
Like • Show 2 Likes2
Actions
- user.oXxABNhXG5YL @ user.oXxABNhXG5YL on May 2, 2017 9:13 AM
  Bumping to hope that Mimecast sees this and responds.
  1 person found this helpful
  Like • Show 1 Like1
  Actions
- user.6eaeBS1pll1 @ user.oXxABNhXG5YL on Jul 20, 2017 1:35 PM
  I use a content exam filter for our C-Level users and do an Administrative Hold, but if they are doing this for every single employee, then that would be an issue...
  
  Activation Score 1
  Fuzzy Hash: 95% probably (for those cases where they alter spelling of names)
  
  phrase list (for each user I have 2 entries):
  1 "From: First Last"
  1 "From: Last First"
  
  Scan Message Headers: True
  1 person found this helpful
  Like • Show 1 Like1
  Actions
  - user.oxriBaJeN4 @ user.6eaeBS1pll1 on Jul 21, 2017 4:41 AM
    Hi Brett REASOR and Aguero, Tom. I've had a word with our Security product team about this. Currently there is no way to add multiple users to an Impersonation Protect policy.
    
    One way forward would be to change impersonation protection to use a group of users. This would require you to add the users you want to protect to a group, and this could be added to a definition. If you go over to Share Ideas and add an idea, they can look into the possibility of including this functionality.
    Like • Show 0 Likes0
    Actions
user.8JDOB2h0xeJx Apr 13, 2017 2:19 PM
Seems comments in this thread are being virtually ignored by folks at Mimecast, but figured it's worth a shot to mention a need to release messages on hold for admin review through email. Logging into and navigating the portal to release a message that is actually safe is a bit cumbersome and time consuming. Thanks...
Like • Show 1 Like1
Actions
- user.wX4DBZtD3oVO @ user.8JDOB2h0xeJx on Apr 20, 2017 10:41 PM
  Moderators can release Moderated Hold from their Outlook add-in or from the Mobile app.
  Don't know if those are extra but that's what we're doing.
  
  As for the "whaling", is anyone using email tagging for external emails?
  We are adding an [EXTERNAL SENDER] tag to all subject lines from external sources.
  I believe this would be a way to signal to your users that the email from the "CEO" isn't legit.
  Like • Show 1 Like1
  Actions
user.rYx9BfRmGRA Sep 19, 2017 4:56 PM
Is there a record of Impersonation Protect polices being triggered (aside from notification emails)?
Like • Show 0 Likes0
Actions
- user.rYx9BfRmGRA @ user.rYx9BfRmGRA on Sep 19, 2017 4:58 PM
  ...that extends beyond one month? (just found the Impersonation Protect Log).
  Like • Show 0 Likes0
  Actions
user.kJMwB1hrA Nov 15, 2017 1:29 PM
The Impersonation protection features still feel very much like version 0.5. The issues pointed out in the posts above are very real and cause targeted emails to still get through.
The fact that you have to set up a separate policy for specific display names is unmanageable. The fact that "Doe, John" in our directory doesn't match on inbound emails that use the format "John Doe" is inexcusable.
The fact that the "newly observed domain" feature relies on a 3rd party source to "See" emails from that domain in the wild in the previous 7 days before those emails sent to you are flagged means the feature is nearly worthless. If someone creates a new domain and only sends email to you, those will never be flagged.
The inability to search for your domain within a sending domain makes it very hard to catch domains like ABC-email.com when your domain is ABC.com.
The inability to flag all inbound emails from domains that you haven't recently sent to recently means you can't flag messages that you likely don't trust and haven't sent anything to in the past.
The "tag" text in the body of an email only lets you compose text with very few characters... especially if you want to format it with any HTML.
The "tag" text can't give the end-user any indication of what policies caused the message to be flagged - just try asking them to look in the header to find it!
The message header "Exposes" the policy names that you used! There needs to be a policy ID that can be matched with the policy name so people don't know what you're checking for!
You can't see the body of the email on the TTP log page! You can only view/export the last month. You can't easily filter on each policy.
Setting up exceptions is a nightmare too. You have to create a separate exception on every policy, for example, if you know there's an external source of "impersonated" messages that need to get through. Try keeping a set of allowed IP addresses up to date on dozens of IP exception policies.
Like • Show 5 Likes5
Actions
user.dqQ3BbHq2Gqp Jun 6, 2018 3:03 PM
Your documentation drowns in terms and phrases that are ambiguous and never fully defined.
Like • Show 0 Likes0
Actions
- user.oxriBaJeN4 @ user.dqQ3BbHq2Gqp on Jun 7, 2018 6:47 AM
  Thank you for this feedback Gary. Can you elaborate on what terms you're having issues with, and we'll see what we can do to help you. We can see how the "Identifiers" section may need more detail, so we've added some summary detail. However these are explained in detail in the configuration page for the definition. We've linked to that page also.
  Like • Show 0 Likes0
  Actions
user.dq6XBEFA9QQ3 Jul 20, 2018 7:13 PM
My office just went through penetration testing, and EVERY email test that was sent through should have set off the Impersonation protection, but it did not. Changing the policy from 3 to 2 item match is now tagging nearly every email we receive. I've even checked the header information from one of the most recent, and according to the header information, it should have been fine!

X-Mimecast-Impersonation-Protect:
Policy=Impersonation Protection 2018-06;
Similar Internal Domain=false;
Newly Observed Domain=false;
Internal User Name=false;
Reply-to Address Mismatch=false;
Targeted Threat Dictionary=false;
Mimecast Threat Dictionary=false;
Custom Threat Dictionary=false;
External=true;
Like • Show 0 Likes0
Actions
- user.oxriBaJeN4 @ user.dq6XBEFA9QQ3 on Jul 22, 2018 7:51 AM
  Hi Kvladmin. I'd reach out to our support desk who will be able to look into this in more detail with you. You can find details of how to do this at Raising a Mimecast Support Case.
  1 person found this helpful
  Like • Show 0 Likes0
  Actions

Recommended Content

Incoming Links

Targeted Threat Protection - Impersonation Protect Getting Started