Home Intel Hub T02 FireEye Products and Services Central Detect and Block Email Threats with Custom YARA Rules

Detect and Block Email Threats with Custom YARA Rules

FireEye Stories 2020-11-19

We are happy to announce client defined custom YARA rules are now available for FireEye Email Security – Cloud Edition, making it easier than ever to migrate from FireEye Email Security – Server Edition. YARA is an open-source tool used mainly, but not exclusively, for identifying and classifying malware based on string or binary pattern matching.

Many vendors, including FireEye, use YARA rules to manage and enhance detections, stop the latest threats, and identify ongoing campaigns within the product. Organizations can now introduce their own YARA rules to enhance their detection efficacy.

Defining Custom YARA Rules in Email Security – Cloud Edition

Let’s take a look at the creation of a YARA rules policy. Like other policies, this type of policy can be assigned to a domain or domain group. A YARA rules policy can contain multiple YARA ‘RuleSets’, with rules defined in a ‘.yara’ file. Each ruleset file can contain one or more YARA rules.

It is useful to define rules that target a specific section of the email. For instance, a pattern in an attachment could easily misfire in the body or header sections of the email. To avoid these unintentional matches, rules must be written to target a specific section (i.e. email header, email body or attachments).

Custom YARA rules are treated as Advanced Threats (AT). Rules defined in block mode will quarantine emails and generate AT alerts, which can be viewed in the UI as seen in the following screenshot. Monitor mode, on the other hand, will tag an email with the YARA rule match without quarantining the email. Alert notifications will be issued as standard for block mode based on notification settings and role-based access control (RBAC).

The details of the alerts can be viewed in the Message Details section.

The name of the YARA rule(s) triggered against an email can be viewed in the Events section, as highlighted in the following screenshot.

Email Trace results can be filtered to show the YARA hits using the ‘YARA Verdict’ filter, as seen in the following screenshot. There is a known limitation in this first release where rules deployed in Monitor mode are not filtered by the YARA Verdict: Fail value. This is scheduled to be patched in the next release.

Sample Use Cases

In Email Security - Cloud Edition, we have three main areas where YARA rules can be applied:

  1. Attachments
  2. The email header
  3. The email body

While this post is not intended to serve as a tutorial on writing YARA rules, we provide an example of a YARA rule for each type.

Attachments

Lately, a file type we have been seeing used maliciously is Excel IQY files. In the following Tweet, Nick Carr, senior manager of our Advanced Practices Team, highlights an example of Temp.Metastrike leveraging an IQY file.

Nick shared a quick hunting rule he wrote looking for IQY files that have a URL within:

rule Hunting_Downloader_ExcelIQYSyntax

{     meta:         author = "nicholas.carr - @itsreallynick"     strings:         $WEB1 = { 57 45 42 0d 0a 31 0d 0a }         $URL = "http"     condition:         filesize < 2MB         and $WEB1 at 0         and all of them }

Adding the YARA Rule
  1. In the Top navigational header in ETP, go to Configuration>Policies.
  2. To apply a YARA rule to this policy, go ahead and open it. Otherwise create a new policy by clicking the “Create Policy” button, choosing “YARA Rules” rule type, and giving the policy a name and a description.
  3. With the YARA rule created, now click “Manage” on the YARA rules section.
  4. Click the “Add Ruleset” button.
  5. In the "Create New RuleSet" form:
    1. Give the RuleSet a name [A]
    2. Optionally add a description [B]
    3. Upload the rules file by using the file browser or dragging into the text box (rules file must end with .yara) [C]
    4. Choose where the rule should be applied (attachments, headers, or body) [D]
    5. Choose to have this be a blocking or monitoring RuleSet [E]
    6. Click Save [F]  
  6. The policy and rules set are now ready for use. Lastly, ensure the policy is enabled and is applied to a domain. Notice in the following screenshot, the “Ian_Custom_Yara” policy is enabled, but not assigned to a domain. If done correctly there will also be an entry in the “Assigned To” column, as seen with the other entries.
The Email Header

Email headers contain a wealth of data that can be used in detection. In a recent blog post by our colleagues on a possible APT29 phishing campaign, they described some features of the phishing email headers that could be leveraged for YARA detections:

Some key elements they call out are:

  • Sender was “DOSOneDriveNotifications-svCT-Mailboxe36625aaa85747214aa50342836a2315aaa36928202aa46271691a8255aaa15382822aa25821925a0245@northshorehealthgm[.]org”
  • Subject was “Stevenson, Susan N shared "TP18-DS7002 (UNCLASSIFIED)”

Given this information, a rule could be written as follows:

rule demo_apt29_phish

{     meta:         author = "Ian Ahl - @TekDefense"         description = "Did not test this rule, just for demo purposes"     strings:         $fullSender = "DOSOneDriveNotifications-svCT-Mailboxe36625aaa85747214aa50342836a2315aaa36928202aa46271691a8255aaa15382822aa25821925a0245@northshorehealthgm.org"         $nbi1 = "northshorehealthgm.org" ascii         $Subject1 = "Stevenson, Susan"         $Subject2 = "N shared"         $Subject3 = "TP18-DS7002"         $Subject4 = "(UNCLASSIFIED)"     condition:         (               (any of ($fullSender*))               or               (2 of ($Subject*) and 1 of ($nbi*))               or               (3 of ($Subject*))         ) }

To deploy this rule, follow the same steps from the "Adding the YARA Rule" section, and modify the "Applies to" portion in step 5D to "Header".

The Email Body

The body of a message can also have some great data for detection via YARA. For instance, FIN7 and FIN8 love to send phishing emails to restaurants. Often the verbiage these groups use is predictable. For instance, these groups typically include language related to:

Similar logic can be applied to many phishing campaigns.

For the FIN7 email in Nick's Tweet, a rule that could be implemented is:

demo_fin7_findigestion_phishbody {     meta:         author = "Ian Ahl - @TekDefense"         description = "Did not test this rule, just for demo purposes"     strings:         $body1 = "Enclosed File"         $body2 = "edit button"         $body3 = "unlock content"         $body4 = "stomach"         $body5 = "diarrhea"         $body6 = "dinner"

    condition:         4 of them }

To deploy this rule, follow the same steps from the "Adding the YARA Rule" section, and modify the "Applies to" portion in step 5D, to "Body".

What’s Next?

While this is our initial implementation of custom YARA rules in FireEye Email Security – Cloud Edition, we have much more planned. Be on the lookout for the following future additions:

  • Deploying custom YARA rules to scan against active content such as macros in Office files, which can be obfuscated in the base file
  • Searching by YARA rule names in Email Trace
  • Adding an inline editor to modify YARA rules
  • Introducing APIs to modify and update YARA policies programmatically

Conclusion

YARA rules can be used to detect and block various types of threats, and now with the capability available in FireEye Email Security – Cloud Edition, organizations can apply their own custom rules against attachments, email headers, and the body of emails to help detect threats. With this feature and also Smart Custom Rules, users are gaining more control to manage email flow and detect threats in custom and creative ways.