There is a saying in the security community that it is not if an organization will suffer a cybersecurity event but when. Current events prove that this statement stands true even for sophisticated security firms such as FireEye.
We are closely monitoring the situation and wanted to share our perspective at this point. I share the opinion of at least a few of my peers who have published articles on the topic. We believe that FireEye is modeling the right way for an organization to deal with a cybersecurity event.
If you are not familiar with how cybersecurity incidents are handled and how information is typically disclosed, we first need to set the stage. It sounds like an investigation is still ongoing. It does not appear that FireEye is attempting to downplay the incident, and they are being forthcoming with information. However, based on what we know at this point, I am concerned that many are overreacting and assuming that the worst case scenario occurred. We see this happen quite often when the ugly “B” word (breach) starts getting thrown around.
It is our understanding that red team attack tools were stolen from FireEye, likely by a nation state. FireEye has not reported the exact capabilities of the stolen red team tools. There is also no reports of unauthorized access or disclosure of customer data or personably identifiable information. There is not even any language that security professionals, like myself, can use to read between the lines and say “yeah, I know what that really means.” I am very curious where the tool kits were stored and what steps were taken to obtain them; I hope this information will be released at some point. My peers and I have discussed that many times the red team systems do not have the same security monitoring and controls that corporate systems do. We wonder if one of those systems could have been exploited directly or indirectly, which resulted in this event.
This event is damaging to the organization because it exposes FireEye’s tools and potentially their trade craft; however, based on our knowledge and experience, unauthorized access to or disclosure of the type of information that was purportedly stolen likely would not require any type of public disclosure. If anything, we are used to seeing a very generic statement that a cybersecurity event occurred but did not result in unauthorized access or disclosure of protected data. FireEye is taking a different approach. FireEye reported in their blog post on 12/8/2020 that they hope to share the details of their investigation, which they believe will “better equip the entire community to fight and defeat cyber attacks.”
FireEye has begun sharing indicators of compromise and counter measures on their GitHub repo. This information will help other companies and vendors detect if hackers are using any of FireEye’s stolen tools. FireEye reported that the tool kits were designed to mimic various threat actor groups’ attacks and that the tool kits did not contain zero-day exploits. Many researches have reported, after reviewing FireEye’s GitHub repository, that most of the tools appear to be open source tools and likely were not developed by FireEye. The YARA rules posted on Github reference tools such as PowerSploit, BloodHound and Pupy, and point to many of the current CVEs we commonly see being used by threat actor groups today to target their victims. These are the types of tools we would expect an organization like FireEye to use on their red team engagements. That said, these are the same tools threat actors are using today to carry out their attacks. Security firms purposefully use the same tools the threat actors do; we want to make sure we make our simulations as realistic as possible and help our clients protect against the enemy we know.
Many security-monitoring vendors, including some of our endpoint detect and response (EDR) partners, have reported that detections were already in place to identify and detect the use of the types of tools contained in the FireEye tool kit. I believe it is safe to say that all security-monitoring vendors are using the information contained in the FireEye GitHub repository to update their detection capabilities. It is unfortunate that FireEye had to burn their red team tool kit or a portion if it as a result of this event; they will rebuild. This event may have put additional tools in the hands of the adversaries, but I believe this event also benefits the security community, as intelligence gained from the incident and the supplemental investigation are being shared.
FireEye reported that they were targeted by a sophisticated nation state that used “novel techniques” that were not previously observed by FireEye or their partners. I am still left wondering: What was the goal of this threat actor group? Was it FireEye’s red team tool kit? Did they accomplish their mission? Is there more to the story? And lastly, did the threat actors “waste” their new novel attack techniques on an organization that will likely stop at nothing to dissect every piece of the attack?
What can your organization do today?
If your organization needs any support implementing any of the countermeasures below, please do not hesitate to reach out to our security team.
FireEye’s red team tool kit contained tools similar to the tools that many of today’s advanced adversaries are using. In my opinion, the disclosure of this tool kit alone does not significantly elevate the risk landscape.
If your organization considers one security enhancement following this event, we recommend implementing an advanced EDR tool. EDR may not detect every attack, but there is no other type of product on the market that will do a better job of identifying, detecting and potentially blocking the type of attack the FireEye red team tool kit will simulate.
Visit the FireEye GitHub repository and update any applicable firewall rules or security tool detections
Utilize the prioritized list of CVEs below, and implement appropriate patches. By doing so, your organization will limit the effectiveness of the red team tools. FireEye recommended addressing the CVEs in this order; however, your organization may decide to make their own priorities based on their unique environments.
- CVE-2019-11510—pre-auth arbitrary file reading from Pulse Secure SSL VPNs—CVSS 10.0
- CVE-2020-1472—Microsoft Active Directory escalation of privileges—CVSS 10.0
- CVE-2018-13379—pre-auth arbitrary file reading from Fortinet Fortigate SSL VPN—CVSS 9.8
- CVE-2018-15961—RCE via Adobe ColdFusion (arbitrary file upload that can be used to upload a JSP web shell)——CVSS 9.8
- CVE-2019-0604—RCE for Microsoft Sharepoint—CVSS 9.8
- CVE-2019-0708—RCE of Windows Remote Desktop Services (RDS)—CVSS 9.8
- CVE-2019-11580—Atlassian Crowd Remote Code Execution—CVSS 9.8
- CVE-2019-19781—RCE of Citrix Application Delivery Controller and Citrix Gateway—CVSS 9.8
- CVE-2020-10189—RCE for ZoHo ManageEngine Desktop Central—CVSS 9.8
- CVE-2014-1812—Windows Local Privilege Escalation—CVSS 9.0
- CVE-2019-3398—Confluence Authenticated Remote Code Execution—CVSS 8.8
- CVE-2020-0688—Remote Command Execution in Microsoft Exchange—CVSS 8.8
- CVE-2016-0167—local privilege escalation on older versions of Microsoft Windows—CVSS 7.8
- CVE-2017-11774—RCE in Microsoft Outlook via crafted document execution (phishing)—CVSS 7.8
- CVE-2018-8581—Microsoft Exchange Server escalation of privileges—CVSS 7.4
- CVE-2019-8394—arbitrary pre-auth file upload to ZoHo ManageEngine ServiceDesk Plus—CVSS 6.5