What The FireEye Breach Means for Security Operations Teams

On December 8, 2020, FireEye announced that they had been “attacked by a highly sophisticated threat actor” and that they “found that the attacker targeted and accessed certain Red Team assessment tools” that FireEye uses in their red team engagements. How does the theft of these tools affect your company? It’s possible the tools could be used against your company, either by threat actors or by penetration testers in future pentest engagements. It’s also possible that the tools have already been used against your company.

Using the LogRhythm NextGen SIEM Platform to Detect Theft of Red Team Tools

How can LogRhythm users detect the use of red team tools against your company in the future, and how can you retroactively hunt for prior use of these tools? As usual, we need to go back to basics and ensure your security tools are up-to-date and that their logs are being collected successfully in the LogRhythm NextGen SIEM Platform.

FireEye has been forthcoming with actionable information about the stolen tools. In addition to their blog post announcing the breach, FireEye plans to release hundreds of countermeasures to help the broader security community protect themselves against similar threats aimed at exploiting red team tools.

You may not want to solely rely on the detections from your antivirus, endpoint detection and response (EDR), and firewall/intrusion detection system (IDS) products for alerts of FireEye tools in your environment. Another option is to use the information provided in FireEye’s GitHub red_team_tool_countermeasures repository to build your own searches and real-time security analytics.

FireEye’s GitHub repository provides you with indicators of compromise (IOCs), such as file hashes, that help you identify instances of the red team tools in your environment. Keep in mind that IOCs are most valuable when used in a retroactive (retro) hunt since tools, and thus their indicators, change over time.

LogRhythm Labs has also set up a GitHub repository with information distilled from FireEye’s repository to use it more readily in LogRhythm. You can find the repo here.

It’s important to note that the FireEye repository continues to change. We will continue to monitor the information that FireEye has disclosed, but we cannot guarantee that our repository will always contain the latest information.

Below we discuss how to use the information that we provided in the repository and how we extracted the information.

How to Retroactively Hunt for Indicators of Compromise (IOCs)

Hunt for File Hashes

Following is an example of a retroactive hunt using the YARA rules provided in the all-yara.yar file in the GitHub repository. Although LogRhythm does not ingest Yara rule definitions directly, you can take advantage of the information in the rules such as the md5 hashes of the files:

You can extract the md5 hashes from the file with a regex search. For example, the screenshot below shows how to find all the md5 hashes using Sublime Text with the regular expression:

[a-f0-9]{32}

Next, you can Find All and copy and paste the results into a text file. If you prefer a *nix command-line approach you could use a grep/sort/uniq combination such as the following to output a list of hashes to a file:

grep -o -E [a-z0-9]{32} all-yara.yar |sort|uniq > hashes.txt

You can then put the list of hashes in a LogRhythm list for use in AI Engine (AIE) rules or searches:

Retroactive Hunt for Threats Matching YARA Definitions

Another example of an IOC-based retroactive hunt would involve searching for matches against the FireEye-provided YARA rules. Keep in mind that YARA rules do not directly apply to logs — they are used to find matches in a corpus of files. However, we can perform an indirect search based on the analysis of the provided YARA rules against VirusTotal samples. Security researcher Florian Roth performed such an analysis and provided results in this spreadsheet, which details which files matched the YARA definitions and the names assigned to the threats by security vendors.

From this spreadsheet one could compile a list of threat names from a given vendor and search retroactively against the SIEM.

By way of an example, if you are a Microsoft Windows Defender shop, you could download the spreadsheet as a .csv file and extract the Microsoft-assigned threat names with:

grep -o -E ‘Microsoft: \S*’ matches.csv | sort | uniq | cut -d ” ” -f 2 > MSthreats.txt

The resulting list can then be imported into a LogRhythm list and then be used for searches against the ThreatName field:

 

 

Vulnerability Management

FireEye has released a list of CVEs related to their red team tools. Addressing these CVEs reduces the effectiveness of the tools. We have provided a list of the CVE numbers on our GitHub. You can feed them into your vulnerability management tools or search for the CVE numbers in your logs.

Assess Your MITRE ATT&CK Technique Detections

As discussed earlier, detections based on IOCs tend to lose their relevance over time. Detections are more resilient if they are focused on the broader technical approach taken by the adversary and if they account for multiple variations of that approach.

Mapping adversarial behavior to a set of MITRE ATT&CK sub-techniques and implementing detections for those techniques will ensure a more resilient and comprehensive approach to detection over time.

FireEye maps MITRE ATT&CK sub-techniques to their red team tools and includes those mappings in the table of contents file signatures_table_of_content.csv. Regex can be employed once again to extract the list of sub-techniques:

grep -o -E ‘T\d{4}(\.\d{3})?’ signatures_table_of_content.csv | sort | uniq > MITRE_subtechniques.txt

With the list of sub-techniques in hand, you can review them against the coverage provided by your security products and determine where your coverage gaps exist.

If you’re a LogRhythm customer and haven’t done so already, take advantage of our MITRE ATT&CK Module by reviewing the log source requirements and enabling the module’s AI Engine rules. The LogRhythm MITRE ATT&CK module provides detections for roughly a quarter of the techniques listed in the FireEye repo (note that FireEye’s repo continues to be updated as of this writing).

Any discussion of detecting MITRE technique execution would be incomplete without discussing data source requirements. In short, make sure you are logging your endpoints! To demonstrate this point, we took the list of MITRE techniques initially cited by FireEye and ran them through our MITRE analysis Jupyter notebook to aggregate the data source requirements. As you can see, process monitoring and process command-line parameter logging are the log sources most often required.

Protect Yourself From Red Team Tool Exploits

The disclosure of the FireEye breach may come as startling news to everyday security practitioners. But we can protect ourselves from the fallout of this breach with security best practices and taking advantage of the threat intelligence provided, endpoint monitoring, vulnerability management, and threat hunting. Learn more about the LogRhythm Labs team and the work we do here.