It is Time to Take Action - How to Defend Against FireEye’s Red Team Tools

In the article we published yesterday, “It is Time to Take Action - Tactics, Techniques and Procedures (TTPs) Utilized by FireEye’s Red Team Tools”, we tried to help the community understand  FireEye’s announcement, on the Red Team tool stolen by threat actors. As a crucial part of the offensive security teams' arsenal, red team tools are used to evaluate assessed systems' security posture. Like any weapon that falls into the wrong hands, red team tools may cause severe security breaches worldwide.

Before continuing to read this article, it is strongly recommended to read our previous report.

Executive Summary

After our article was published, we received lots of interest and gratitude from all over the world. And also, there were a significant number of demands to extend Blue Team Recommendations. 

In this article, we expanded and added more tangible explanations and shared our detection contents as SIGMA and vendor-specific queries and also vendor-based prevention signatures related to defending against FireEye Red Team tools.

We categorized these recommendations into five topics:
1. Extended FireEye Red Team Tools Countermeasures with Sigma and Snort
This recommendation includes open-source mitigation content from Picus Mitigation Library for both detection and prevention layers as both the SIGMA rules developed by Picus Labs Blue Team and the Snort rules are mapped to the related threats by the Picus Labs Blue Team.

2. Extended FireEye Red Team Tools Countermeasures with QRadar, Splunk, Carbon Black, and ArcSight
Vendor (SIEM and EDR) specific detection rules developed by Picus Labs Blue Team are provided in this section.

3. Vendor-Specific Signature Coverage for Fireye Red Team Tools
Vendor(NGFW, IPS, and WAF) specific prevention signatures which are mapped to the related threats by Picus Labs Blue Team are provided under this topic.

4. How To Leverage FireEye Countermeasure Recommendations
Extended and more tangible explanations from the previous article about how to leverage FireEye Countermeasures.

5. Lessons Learned and Looking Forward
Picus Labs’ Blue Team prepared a list of future recommendations with lessons learned from this incident.

Picus in Action

Picus technology partners develop state-of-the-art technologies, and they are the backbone of cybersecurity efforts globally. Picus steps in to support its customers to make the most out of these technologies, with carefully designed integrations that start at the research level and extend to the solution delivery.

Built on technology alliances, Picus Mitigation Library delivers immediate value by providing mitigation insights in Network Security, Endpoint Detection and Response, and Security Information and Event Management categories.

The Picus Threat Library includes most of the stolen tools in this breach, and the Picus Mitigation Library contains actionable mitigation recommendations and detection rules against them. Picus Labs’ Red Team and Blue Teams are working on the missing tools and adding them and their techniques to our libraries.

So this means, Picus users have already assessed their cyber defense against most of the stolen red team tools and their attack techniques. And, they fixed the identified gaps using actionable recommendations provided by the Picus platform.

We decided to share these actionable recommendations with the community in this article to help defend against these tools.

Extended FireEye Red Team Tools Countermeasures with Sigma and Snort

Picus Labs Blue Team develops, tests, and verifies detection rules as SIGMA, a generic and open signature format for SIEM products, based on threats developed by Picus Labs Red Team. Also, Blue Team simulates these threats against Snort IPS, an open-source Intrusion Prevention System, and then analyzes the results and maps with the right signatures.

In this section, you can find the SIGMA rules and Snort signatures to defend against FireEye Red Team tools. The SIGMA rule names and Snort signature categories are below as a list, but detailed information about these contents are published in Picus Labs’ Github repository [1].

SIGMA Rules:

• Script File Execution via WScript or CScript Tool
• Persistence by Adding a User to Local Administrator Group
• TCP Connection Creating via PowerShell Script
• Pass the Key with Rubeus
• Suspicious RC4 Encrypted Kerberos Service Ticket Request
• Kerberoasting with Rubeus
• Code Execution via Microsoft Build Engine
• Suspicious Credential Vault Client Library Load
• Execution Through Module Load via PowerShell
• Symmetric Cryptography Encryptor and Decryptor Utilization via PowerShell
• Execution of C# Compiler
• Suspicious DISM Core Framework Portable Executable Load

Snort Signature Categories/Sources:

• MALWARE-TOOLS
• MALWARE-OTHER
• MALWARE-CNC
• MALWARE-BACKDOOR
• EMERGING THREATS

Extended FireEye Red Team Tools Countermeasures with QRadar, Splunk, Carbon Black, and ArcSight

Picus is working with SIEM and EDR vendors in a Technical Alliance Partnership program. Picus Labs Blue Team develops SIEM (IBM QRadar, Splunk, Micro Focus ArcSight) and EDR (VMware Carbon Black) specific detection rules based on the SIGMA rules defined in the chapter above. Following the development, they test and analyze the results on each vendor environment and finalize the rules with the specific product’s query language.

In this section, you can find the IBM QRadar, Splunk, Micro Focus ArcSight, and VMware Carbon Black rules to defend against FireEye Red Team tools. The rule names mapped with each vendor are given in the below table, but detailed information about these contents are published in Picus Labs’ Github repository.

 The below figure shows use interface of Picus platform's detection rules interface.

Vendor-Specific Signature Coverage for FireEye Red Team Tools

Picus is also working with network security vendors through its Technical Alliance Partnership (TAP) program. Picus Labs Blue Team simulates the threats developed by Picus Labs Red Team against TAP vendor environments and then analyzes the results and maps with the right signatures to eliminate F/P issues.

In this section, you can find the vendor-specific network prevention signatures to defend against FireEye Red Team tools. The vendor and product names are given in the below list, but detailed information about these signatures is published in Picus Labs Github repository.

• Check Point NGFW
• Cisco Firepower
• Citrix Netscaler VPX
• F5 BigIP ASM
• Forcepoint NGFW
• Fortinet AV, IPS, WAF, WEB
• McAfee NSP
• ModSecurity WAF
• Palo Alto Networks NGFW
• Snort IPS
• Trend Micro TippingPoint IPS

We recommend that you first activate the relevant signatures of your prevention products in your test environments. Then, activate them in detection mode in your production environment and put them into prevention mode after making sure that there is no F/P situation.

How To Leverage FireEye Countermeasure Recommendations

Picus Labs’ Blue Team prepared a list of recommendations for preventing and detecting the stolen tools and exploits based on FireEye’s shared countermeasures.

1. Vulnerabilities

Assess your systems against vulnerabilities listed in the below table using vulnerability scanning and monitoring tools. If there are any gaps you haven't patched yet, you must fix them, and you should check if they have been abused in your systems. 

When we look at shared CVEs, we see that they are generally vulnerable to 2019 and 2020, which are up to date. These vulnerabilities are still used today, and it is important to patch them quickly. For example, when we look at CVE 2020 1472, it is possible to find tools [2] to test your systems.

There are resources for necessary recovery methods related to this vulnerability [3], [4].

2. Compromise Assessment

You can conduct compromise assessments on your systems by using released Yara rules by FireEye. To utilize Yara rules, you can use an open-source Yara scanning tool or enterprise product and distribute it to the endpoints on your systems, then add the rules and get the results. Moreover, you can use IoCs included in Yara rules and search them in your SIEM environment.

You can use free tools to scan YARA rules on your systems. As an example of these tools, three tools are shared below:

• Yara Endpoint [5] 
• Spyre [6]
• Loki [7]

You can also access the list of products from VirusTotal [8]  that support YARA and use their features if you have these products in your systems.

3. Utilize IOCs

To prevent and detect future related threats, you can add IOCs given in our previous report to your security products, such as EDR, EPP, and SIEM. However, keep in mind that these IoCs can easily be changed by adversaries. But at least you can start a quick threat hunting process with these IoCs.

4. Utilize Snort Rules

Some network security products support Snort rules. You can automatically or manually (depending on the product’s capabilities) convert and add released Snort rules to your security devices that support Snort rules [9]. If you are already using Snort, you can check the current rules are up to date. You can see the related Snort signatures given in this report.

5. Update Your Security Products

Security vendors are releasing new signatures and rule sets that include countermeasures against these stolen tools. You need to update your security products and their rule and signature sets. Related contents can be found in the latest update packs. If you can’t find any, we recommend you to contact the related product’s support team.

6. Hunting with OpenIOC

FireEye released some countermeasures in the OpenIoC format. You can add these rules to your security devices by developing detection and hunting rules using IoC editors such as FireEye’s Open IoC Editor [10]. In the editor, you can find some critical patterns to use in detection or hunting rules.

Lessons Learned and Looking Forward

Picus Labs’ Blue Team prepared a list of recommendations for future preparations using lessons learned from the FireEye incident.

1. Increasing Visibility & Monitoring Metrics

Visibility is the most crucial factor in detecting cyber threats and incidents. For this reason, organizations need to implement and configure security technologies at the endpoint and network level. In addition, logs collected from security technologies should always be validated and kept for historical threat hunting. MITRE ATT&CK framework’s data source mappings [11] can be used as a starting point.

2. Managing Vulnerabilities With Strong Inventories and Threat Intelligence

Vulnerability management needs well-prepared internal inventories to be successful. In this way, it will be easier to detect security vulnerabilities within the organization. However, it is essential to match security vulnerabilities with threat intelligence to take the right action at the right time. Taking action against security vulnerabilities used by threat actors in cyberattacks will be beneficial in eradicating cyberattacks.

3. Incident Response Plans Depend on Organization Specific Planning

The purpose of cyber incident response plans is to remediate the incident with the least damage. These plans need to be developed regarding the organization’s specific business requirements.  While developing the incident response plan, care should be taken that it is applicable. Therefore, the plan must be simulated with tabletop exercises. Also, the plan will have a better form with lessons learned.

4. Threat and Incident Investigation Toolkits

Tools may be needed to investigate, detect, and respond to security attacks and incidents. Preparation with both open source and enterprise tools before the cyber incident will help fast detection and response of the incident. Especially for malware analysis, an isolated environment should be created, and analysts' capabilities on tools and techniques should be increased. You can find a good tool list for these purposes.

5. Hunting for Lurking and Undetected Threats

The art of proactively searching for threat actors hidden in the network is called threat hunting. The essential point of threat hunting has to know what to look for. Tactics, Techniques, and Procedures (TTP) used by adversaries should be well known. With this knowledge, a strong threat hunting plan should be developed. You may want to take a look at the Threat Hunter Playbook project [12]. 

6. Building an Adversary Emulation Plan

Adversary Emulation Plans are very helpful for organizations to test their defenses based on real-world threats and attack scenarios. These plans are critical in building a strong defense, prioritizing requirements, and designing a road map. Blue Teams need to react and respond quickly and also measure the effectiveness of SOC processes, people, and technology infrastructure. To make these improvements continuously, you need to build an Adversary Simulation Plan.

References

[1] Picus Security, “picussecurity/picuslabs.”https://github.com/picussecurity/picuslabs
[2] SecuraBV, “SecuraBV/CVE-2020-1472.”https://github.com/SecuraBV/CVE-2020-1472
[3] “Security Update Guide - Microsoft Security Response Center.”https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-1472
[4] “Tenable Community.”https://community.tenable.com/s/article/Plugins-associated-with-the-FireEye-Red-Team-toolkit-leak.
[5] Yara-Rules, “Yara-Rules/yara-endpoint.”https://github.com/Yara-Rules/yara-endpoint
[6] spyre-project, “spyre-project/spyre.”https://github.com/spyre-project/spyre
[7] Neo23x, “Neo23x0/Loki.”https://github.com/Neo23x0/Loki.
[8] “YARA - The pattern matching swiss knife for malware researchers.”https://virustotal.github.io/yara
[9] fireeye, “fireeye/red_team_tool_countermeasures.”https://github.com/fireeye/red_team_tool_countermeasures
[10] “IOC Editor.”https://www.fireeye.com/services/freeware/ioc-editor.html
[11] “Techniques - Enterprise.” https://attack.mitre.org/techniques/enterprise/
[12] “Threat Hunter Playbook.” https://threathunterplaybook.com/introduction.html