How X.509 Certificates Were Involved in the SolarWinds Attack

For a moment, we were ready to put 2020 behind us, until this week.

It started with reported theft of FireEye’s Red Team tools, and then came the bigger news. FireEye and the U.S. Treasury and Commerce departments had been infiltrated via SolarWinds Orion software updates, which included malicious code injected by Russian-backed hacking group Cozy Bear (APT 29).

This news doesn’t just affect SolarWinds, FireEye, and U.S. government agencies – it affects us all. When a nation-state attacks one of us, they attack us all, and we all feel the sting. It’s a sobering reminder of our everyday reality: anyone can be breached.

While the full details of the attack – now known as SUNBURST – are yet to be disclosed, we’ve learned much more about our adversaries and how they managed to evade defenses.

Let’s break down what we know so far:

• On December 8^th, FireEye disclosed the theft of their Red Team assessment tools from a GitHub repository. Despite the hype, most of these tools and exploits were already well-known.
• On December 13^th, FireEye discovered in their own investigation that attack involved malicious code that was inserted into legitimate software updates from SolarWinds Orion Platform dating back to between March 2020 and May 2020.
• On the same day, the U.S. Treasury and Commerce departments announced their systems were breached by a Russian-backed hacking group known as CozyBear (APT 29). CISA then released Emergency Directive 21-01, “Mitigate SolarWinds Orion Code Compromise.”
• On December 15^th, Microsoft commandeered the malicious domain name used to control affected systems to prevent and even mitigate the attack with a ‘kill switch’.

Sorting out the scope and scale of this incident will probably a while, but over the past week, we’ve learned a lot about the tools and techniques used by the attackers.

As the dust settles and more details emerge, one thing has become clear: attackers misused X.509 certificates and keys as a part of their toolkit to impersonate trust and avoid detection. It started with SolarWinds, but it doesn’t end there.

A recently released article by the Microsoft Security Response Center runs through some of the technical details involved in the supply chain attack. Here are some key insights into how X.509 certificates were used by attackers to forge and undermine trust:

A trail of breadcrumbs leads us back to SolarWinds, where attackers modified source code to include a malicious backdoor, which was then compiled, signed, and delivered unknowingly by SolarWinds to nearly 18,000 customers via their software update and code-signing systems.

The initial breach was not the result of a stolen code-signing certificate, but the tampered library was signed by SolarWinds, making it appear legitimate to end user systems. While there is no evidence that the signing certificate or process itself was compromised, the build and review process prior to signing was compromised, allowing the malicious code to slip through.

This isn’t the first time either. Attackers are increasingly weaponizing the trust we rely on. Similar supply chain attacks involved either the theft of code-signing certificates, such as attacks conducted by APT41 and Kimsuky, or similarly slipstreamed tampered code through the signing process, including the attack on ASUS last year.

According to Microsoft, “once in the network, the intruder then uses the administrative permissions acquired through the on-premises compromise to gain access to the organization’s global administrator account and/or trusted SAML token signing certificate.”

In this case, attackers forged SAML tokens and signed them with legitimate, compromised certificates to impersonate trusted users and accounts, allowing them to move laterally without detection.

In some cases, the malicious actor made modifications to Azure Active Directory settings to gain long-term access, including “adding credentials (X.509 keys or password credentials) to one or more legitimate OAuth Applications…”

Once they’ve gained a foothold, the next priority for attackers is often finding ways to stay inside. Here they leveraged X.509 certificates to create legitimate OAuth access to the network.

As I mentioned earlier, there is no silver-bullet solution to preventing these sophisticated attacks. This was a highly sophisticated attack that involved many different tools and techniques.

We’re here not to speculate, but rather, to bring awareness to a growing problem we see in the industry: the increasing misuse and theft of keys and digital certificates. It’s not about this breach, or the next, it’s about the need to effectively track and monitor the use of certificates across apps, cloud and network infrastructure.

Here are some recommended best practices to mitigate the misuse of keys and certificates:

• Maintain an active inventory of all certificates, where they are installed, who they were issued from, and who owns them (and your domains).
• Control certificate issuance and approval workflows to ensure that every certificates is trusted, compliant with policy, and up-to-date.
• Regularly test your certificate re-issuance and revocation capabilities to ensure you can respond effectively to a compromise.
• Never store code-signing keys on developer workstations or build servers. Private keys should be kept in a FIPS 140-2 validated HSM and never leave the hardware.
• Segregate duties between who is authorized to sign code, who can approve the request, and who can monitor and enforce compliance with signing policies.
• Define policies to limit access to code-signing keys by user, machine, location, duration, time of day, signing method or other parameters that make sense to your organization.

If you want to learn more about the trends we’re seeing when it comes to the use (and misuse) of cryptography, check out our 2021 Cryptography Trends Report.