Description

For a social engineering campaign, an individual may attempt to impersonate senders at the target domain via email. This practice, known as Spear Phishing, uses information gathered previously in the campaign, including technical, organizational, and personal components to gain confidence from the recipient. The result is an email most often impersonating a C-level employee, accountant, or direct supervisor that can be nearly indistinguishable from the real thing.

Two vastly different approaches are most commonly employed in these communications:

In some cases, the email will either present an urgent situation in the first communication asking the recipient to help with resolution immediately. This is used for shorter engagements, with often less preliminary information and the goal of more immediate results. The sender may try multiple recipients in the hopes of finding "low hanging fruit."

The second approach is to build rapport more gradually over a series of casual communications before making a request. This will more often be the culmination of a more significant effort, where the sender is attempting to avoid detection if at all possible. This will usually be directed at one or a few recipients who have been identified ahead of time as high risk.

In both scenarios, the end goal is typically either recipient engagement with a malicious attachment to gain access to the internal network, or more immediate financial gain through a direct payment or disclosed banking information. In some cases, however, the goal can be information gathering in preparation for the next steps in the campaign.

End-user education will always be a necessary last line of defense in combating spear-phishing attempts. However, Mailprotector offers options via Message Rules that can help inform recipients of inconsistencies in an email or prevent them from reaching the recipient entirely.

Prerequisites

For specific rules, checking From name will require that first and last names be provided in the From field of any emails that are sent from them. This occurs by default as long as their mail client is configured with correct first and last name.

Example

Message's contents are left relatively simple to avoid being caught by heuristics. The sender added a From name matching the CEO, but there was no address spoofing to prevent being caught by any spoofing filters. There also are no attachments.

Implementation

A message rule can be created to check the From name against a known Sender address with the following steps:

1. At the domain level of the console, navigate to the Filtering tab, enter the name for your new rule in the Message rules creation panel, and click Create.

 

 2. From the Criteria tab, enter any known email addresses that your CEO sends from in the "Sender - Does not match any of:" field, and the CEO's First and Last name in the "From - Matches any of."

​

NOTE: If the individual is a Bracket user, an additional "Sender does not match any of:" criteria for ses.bracket.email will be necessary to prevent false positives on Bracket notification delivery.

ADDITIONAL SECURITY: The rule works by checking the From field for the CEO's first and last name, and then comparing that with the expected Sender address. The above screenshot does not account for spacing, so for example, "CEO      Name" would still pass, since the string is no longer an exact match with "CEO Name." Multiple criteria can be added to the From field to account for this if you'd like. Fortunately, a high number of spaces and long subject lines are common criteria in most spam filters, so it is not a common practice with this sort of phishing attempt to use extra spaces. This is also uncommon because the sender's goal is to make the email look as authentic as possible.

3. From the Actions tab, select what action should be taken if the rule is triggered. Most often, this will be Hold for Review > Policy, but subject text, headers, or footers can be used instead if you would prefer not to disrupt delivery but still warn the recipient. The message also can be automatically deleted, though this may impede an investigation, so it is not recommended for most cases.

NOTE: To avoid informing a malicious sender, we do not provide any feedback when a message hits quarantine or is deleted due to a rule. The sender will be unaware that this rule is in place to reduce the likelihood that they adjust their practices on future attempts.

End-user Education Reminder

While message rules provide valuable automated protection against spear phishing. End-user education will always be a necessary last line of defense in dealing with social engineering attempts since a particularly determined sender can still find ways around the above message rules.