On Tuesday, December 8^th, 2020, FireEye, a leading cybersecurity firm used by governments and companies for penetration testing and forensic services announced that it had been the target of an attack by nation-state actors “with top-tier offensive capabilities,” and that a suite of tools used by FireEye for penetration testing had been stolen.

What do these tools show us about the current state of defenses that FireEye staff had to contend with on their engagements? And what does it show us about the way organizations are performing vulnerability management?

FireEye Handled its Own Breach Very Well

It was later revealed that FireEye was only one of as many as 18,000 organizations compromised by a trojaned update to SolarWinds network management software.

FireEye is working with the FBI, and further investigation revealed that the “nation-state” here is Russia, specifically APT29, also known as “Cozy Bear.” This is associated with the Russian state Foreign Intelligence Service, SVD. As the investigation continues, further details will undoubtedly be forthcoming. In the meantime, what does this mean for companies that may be concerned about attackers gaining access to a sophisticated toolset used by one of the nation’s most highly regarded security firms?

First, it’s important to be clear about what FireEye did right. It detected the breach, announced it, took action to protect its customers and the industry, and is collaborating with law enforcement. It has shared details on the vulnerabilities that its tools targeted and provided signatures and configuration advice to help organizations defend themselves.

The fact of the matter is, given sufficiently skilled and motivated attackers, every organization runs some risk of being breached. Given this, the ability to detect breaches when they happen and handle the incident in a transparent and accountable way matters at least as much as the front-line defenses any organization may have in place. There have been similar incidents in the past in which organizations didn’t detect breaches for years. Once they were detected, these companies weren’t as forthcoming with details, and even tried to hide the fact they had been breached. In this author’s opinion, FireEye’s response has been exemplary.

Older Vulnerabilities Still Work

The currently released list of vulnerabilities from the stolen tools can be found at https://github.com/FireEye/red_team_tool_countermeasures/blob/master/CVEs_red_team_tools.md The details reveal several useful conclusions about what techniques attackers and penetration testers find useful.

First, the age range of the vulnerabilities show that not every organization handles vulnerability management effectively. We already know that many organizations struggle to patch known vulnerabilities. The Kenna and Cyentia Prioritization to Prediction series states “over 75% remain open at least one year after the associated CVE was published” and the vulnerabilities contained within the FireEye toolset bear that out. Most of the vulnerabilities listed here are from within a three- to four-year time period. The presence of these “old” vulnerabilities in the set show that in many cases, the opportunity window for the use of a given vulnerability is much longer than might be naively supposed.

One standout is CVE-2014-1812, a Windows Local Privilege Escalation vulnerability. The oldest on the list, it nevertheless shows that while many organizations prioritize patching and defense of their perimeter, many fall short when it comes to patching against attacks that originate from attackers that have already managed to gain a foothold, such as the compromise of a less privileged account.

This aligns well with the general understand that attackers will first attempt to gain any sort of access, then assert elevated privileges once inside. It strongly implies that detection and defense inside the perimeter are equally important.

Public Exploits are Effective; Severity Levels Less So

Next, we took a look at which of these 16 CVEs had publicly available exploits. Eleven out of 16 did. Five did not. The presence or absence of a publicly available exploit is often used as a metric when it comes to patching prioritization. If a severe vulnerability is announced and an exploit is available, the priority of deploying some sort of mediation or patch should be high. In the absence of a publicly available exploit, it might be classed as a lower priority, at least in relation to the first scenario. However, it seems that in some organizations, the necessary follow-through is not always brought to bear. Instead of patching the most critical bugs with public exploits first, followed by critical bugs without public exploits, then less-severe bugs and so on down the line, organizations instead only complete part of this process.

By doing so, they may have reduced the most obvious risk, but have left themselves open to attack from those with enough skill to write their own exploits. This is not as uncommon a skill as some would believe.

Following this logic, many companies are simply defending themselves against a particular level of attacker—the ones who can manage to get a public exploit to work—but are essentially ignoring the next tier up. They do so at their own risk. Generalized arguments around the likely skill level of likely attackers don’t hold up well when one considers that the final target of those attackers may be business partners or customers, and targeting your organization is merely a means to an end.

Just as some companies mistakenly assume that having defenses in place against the OWASP Top 10 means they are “secure,” they forget that the OWASP Top 10 is meant as a bare minimum for security, and is a wholly inadequate level of defense against any but the most basic of threat actors.

Lower Severity in General, Higher Severity in Context

Finally, while most of the 16 identified vulnerabilities allow remote-code execution (which leads to a quick foothold or even complete compromise of the target) and several more allow privilege escalation, there are three that allow attackers to read or create file-system objects. Of these three, two allow for file-reading, and one allows for file upload. The file upload vulnerability is the only one of the CVEs listed that is ranked as “medium” severity. Nevertheless, a brief reading of the public exploit code indicates that this bug could allow an attacker to upload a web-based shell and gain command execution as an unprivileged user. Depending on how the software was deployed, what an attacker could accomplish with this bug would vary. However, it does go to show that one cannot trust severity levels as the sole indicator of patching priority. Care must be taken to understand each vulnerability within the context of the overall network architecture and make risk decisions based on that. Organizations that rely on simplistic metrics for vulnerability classifications may find themselves surprised when they are successfully compromised by “less severe” vulnerabilities.

Some readers may worry more about the overall toolset that was stolen, rather than the specific vulnerabilities that it leverages. Will the theft of this toolset lead to new attacker techniques?

It may. It could be that FireEye had automated and embedded its expert knowledge into its toolset, and those who stole it may learn new ways of avoiding detection or defeating defenses.

However, it is more likely that the tooling was an expression of the process flow and discipline of the red team that developed it. As such, it may not be very useful to the attackers. Each team develops its own habits and processes, as well as a base of knowledge and talent that it relies on. These teams streamline and focus their tooling on the efficient use of those skills. In this case, it is likely that the attackers already have their own tooling, and that it is quite useful to their process. They may get a few new ideas, but it seems unlikely to be a game changer.

Vulnerability Management in Full Context

In summary, this event is a reminder of the tools and techniques of advanced attackers, and a useful view into how high-end penetration testing and hacking are done. Attackers use known vulnerabilities with public exploits because they continue to work long after they have been announced. They write custom exploits when they need to. They refine and automate their processes. They seek to patiently and reliably gain an initial foothold, then elevate access, then continue their penetration of an organization. They hide their tracks and too often remain undetected for long periods of time until they reach their eventual goals. While not all attackers demonstrate this level of skill, it would be a mistake to believe that none of them do.

To defend against them, we must view our vulnerability management in context: patch the riskiest things immediately, but not stop there. We must understand our environments well enough to know that sometimes lower severity vulnerabilities will be much more efficacious to attackers than might be indicated by the severity score. We must find ways to detect and respond to the inevitable breaches that will occur, even with best practices of defense in place. And we must do so using all the tools we have available to us and focus on automating and streamlining our processes for doing so. Attackers are doing this exact thing: relying on the basics, automating, streamlining, and applying extra effort where it is needed. If we wish to defend against them, we must do the same.