Bishop Fox named “Leader” in 2024 GigaOm Radar for Attack Surface Management. Read the Report ›

The Stolen FireEye Red Team Tools Are Mostly Open Source

Person standing in front of a subway going by


The breaking news about an attack against FireEye by a nation-state group is ongoing and will continue to develop. We’re not in the business of speculating about how an attack group would or could use the information stored in the GitHub repository that was accessed. We can, however, share some relevant context about what’s in the repository and offer our take on what those stolen “red team tools” do.

Tl;dr: there’s nothing particularly unusual in the GitHub repository, nor is there anything we wouldn’t expect to see from a security firm like FireEye. From what’s been made available in the repo, the tools are mostly open source and not developed by FireEye.

It’s a shame to see that this happened to FireEye, and it’s a sobering reminder that this can happen to any company. We’re impressed by how the team has handled the disclosure and hope that they’re able to resolve the issue and move forward as soon as possible.


The GitHub repository contains YARA rules (i.e., signatures for identifying malware and other files) for detecting the stolen “Red Team Tools” from FireEye. While FireEye hasn’t released many details about what these tools do, some are speculating that the stolen tools present an acute threat in the hands of adversaries. However, FireEye has released the YARA rules for detecting stolen tools, and we can glean the following information:

The release contains YARA rules for roughly 60 tools; however from the names it appears many are existing publicly available open-source tools not developed by FireEye. For example:

There are also several references to PowerSploit, BloodHound, and Pupy. Based on the YARA rules, it appears the majority of the stolen “Red Team Tools” are just public open-source projects, or perhaps modified open-source tools, that are well-known and used throughout the industry.

Several of the release YARA rules do appear to be for FireEye internally developed projects, and we won’t know the capabilities of those until FireEye releases additional details or the source code. However, even these YARA rules seem to reference well known tactics, techniques, and procedures (TTPs). For example, the “GoRat” appears to be an internally developed Remote Access Tool (RAT), possibly written in Golang (appears to be unrelated to the similarly named open-source projects) and supports named pipes, SOCKS proxying, and staged loading. These are well-known techniques implemented in a variety of open-source implant/RAT frameworks.

Again, there’s nothing shocking or particularly alarming in this repository from our point of view. It’s a collection of tools that are commonly used and perhaps slightly modified to work for FireEye’s purposes. We’ll update this article, if needed, as the story continues to develop. We’re pleased to see that FireEye reported this event as transparently as they’re able and hope that other organizations take note of how this has been handled.

Updated Dec 9, 2020 3:00PM EST

As previously stated, none of the vulnerabilities accessed by the attack group were emerging threats or zero days and all have patches or updates available. While very sophisticated attackers and attack groups -- such as nation states -- may be able to get around these barriers to entry, we don’t have enough information to speculate about the specific targets or potential attack vectors.

Looking simply at the known information of the vulnerabilities in the dump, our analysis revealed that some require local or authenticated access to be exploited. Meanwhile, the remote code execution exploits have been identified and patched for some time.

Any risk carried here for most organizations is mitigated by applying the latest patches or updating to the latest version. Additional recommendations follow at the end of this post.

Analysis of Vulnerabilities in FireEye GitHub Repository

The following is our analysis of the vulnerabilities associated with the dump, along with the associated security rating (CVSS 1-10, with 10 indicating the highest risk) and a link to the related advisories and updates/patches:

Our recommendations for security teams:

  1. Ensure any of the above CVEs have been patched within your organization, if applicable, and if not, update as soon as possible
  2. View the FireEye GitHub repository and update any applicable firewall rules.

Subscribe to Bishop Fox's Security Blog

Be first to learn about latest tools, advisories, and findings.

Default fox headshot purple

About the author, Bishop Fox

This represents research and content from the Bishop Fox team.

More by Bishop

This site uses cookies to provide you with a great user experience. By continuing to use our website, you consent to the use of cookies. To find out more about the cookies we use, please see our Privacy Policy.