The SolarWinds Supply Chain Attack Explained

In December 2020, FireEye disclosed that it had been breached by a nation-state actor — and that the intrusion path ran through a piece of trusted network monitoring software running in roughly 18,000 organizations worldwide. The SolarWinds attack, later codenamed SUNBURST (also referred to as Solorigate), remains the clearest large-scale demonstration of what a compromised software build pipeline can do: attackers didn't need to breach each victim individually, they only needed to breach one vendor's build server and let that vendor's own auto-update mechanism do the rest. Alongside SUNBURST, investigators also uncovered a separate, unrelated authentication bypass in the same product — CVE-2020-10148 — which a different set of attackers exploited to drop a webshell called SUPERNOVA. Together, the two incidents turned SolarWinds Orion into a case study on why supply chain security and reachability-aware vulnerability management now sit at the center of enterprise risk programs.

What happened

SolarWinds Orion Platform is IT infrastructure monitoring software used by government agencies, Fortune 500 companies, and managed service providers to keep tabs on networks, servers, and applications. Between September 2019 and February 2020, an actor that the U.S. government later attributed to Russia's SVR foreign intelligence service (tracked as APT29, Nobelium, or Cozy Bear) gained access to SolarWinds' software build environment. Rather than exploiting a flaw in Orion's code, the attackers compromised the build process itself, inserting malicious code into the source of a legitimate Orion component: SolarWinds.Orion.Core.BusinessLayer.dll.

That trojanized DLL was then digitally signed with SolarWinds' own legitimate code-signing certificate and shipped to customers as part of routine software updates between March and June 2020. Because the update was signed and delivered through official channels, it passed every conventional trust check an organization's endpoint and network defenses would normally rely on.

The embedded backdoor, SUNBURST, was deliberately patient. It stayed dormant for up to two weeks after installation, checked for the presence of security tools and sandbox artifacts, and only then began communicating with attacker infrastructure over HTTP using a protocol designed to blend in with normal Orion telemetry. Command-and-control traffic resolved through a subdomain-generation scheme rooted at avsvmcloud[.]com, allowing the operators to selectively activate the backdoor on the small number of high-value targets they actually cared about, while the vast majority of the ~18,000 organizations that received the trojanized update were never actively exploited.

For the targets the attackers did pursue — including the U.S. Departments of Treasury, Commerce, State, Homeland Security, and Energy, as well as Microsoft and FireEye itself — SUNBURST was a stepping stone. Operators used it to deploy a memory-only dropper called TEARDROP, move laterally, and in several documented cases forge SAML authentication tokens ("Golden SAML") to impersonate users and access cloud email and productivity systems without triggering conventional password-based alerts.

Separately, and unrelated to the Russian campaign, researchers found that a different actor had exploited CVE-2020-10148, an authentication bypass in the Orion API that allowed a remote, unauthenticated attacker to execute API commands and ultimately achieve remote code execution. That flaw was used to install a webshell dubbed SUPERNOVA. The two incidents being discovered at nearly the same time — one a nation-state build-system compromise, the other an opportunistic API vulnerability in the same product — underscored how a single widely deployed piece of software can carry multiple, independent layers of risk.

Affected versions and components

• SUNBURST-affected releases: SolarWinds Orion Platform versions 2019.4 through 2020.2.1, specifically builds released between March 2020 and June 2020 that contained the trojanized SolarWinds.Orion.Core.BusinessLayer.dll.
• CVE-2020-10148-affected releases: Orion Platform versions prior to 2020.2.1 HF2, via the exposed Orion API authentication logic.
• Downstream exposure: any product built on the shared Orion Platform framework (e.g., Network Performance Monitor, NCM, Server & Application Monitor) inherited the same core DLL and was potentially in scope.

CVSS, EPSS, and KEV context

CVE-2020-10148 carries a CVSS v3.1 base score of 9.8 (Critical) — network-exploitable, no authentication required, no user interaction, and full impact on confidentiality, integrity, and availability. It is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, reflecting confirmed active exploitation via SUPERNOVA. Because EPSS (Exploit Prediction Scoring System) launched in 2021, it did not exist at the time of initial disclosure, but a vulnerability with this profile — critical severity, public proof-of-concept, confirmed exploitation, and KEV listing — would today sit at or near the top percentile of EPSS scores, which is exactly the kind of signal defensive teams should treat as an automatic patch-now trigger rather than something to be triaged against a generic severity threshold alone.

Timeline

• September 2019: Suspected initial access to SolarWinds' network and build environment.
• October 2019: Test injections of modified code into Orion builds, believed to validate the attackers' ability to tamper with the build process undetected.
• February 2020: SUNBURST backdoor code inserted into the Orion source tree ahead of a production build.
• March–June 2020: Trojanized Orion updates signed and distributed to customers; SUNBURST begins selectively activating on high-value targets.
• December 8, 2020: FireEye discloses that its own Red Team assessment tools were stolen.
• December 13, 2020: FireEye, SolarWinds, and Reuters publicly reveal the supply chain compromise; SolarWinds files an SEC Form 8-K.
• December 14, 2020: SolarWinds releases hotfix 2020.2.1 HF1, removing the SUNBURST-affected component.
• December 15, 2020: CISA issues Emergency Directive 21-01, ordering federal civilian agencies to disconnect or patch affected Orion instances immediately.
• Late December 2020 – January 2021: SUPERNOVA and CVE-2020-10148 are identified as a separate exploitation path; SolarWinds ships 2020.2.1 HF2.
• April 2021: The U.S. government formally attributes the campaign to Russia's SVR and imposes sanctions.

Remediation steps

1. Patch to a clean build. Upgrade every Orion Platform instance to 2020.2.1 HF2 or later — this removes the SUNBURST-affected DLL and closes the CVE-2020-10148 API authentication bypass.
2. Assume compromise, don't just patch. If any instance ran an affected build between March and June 2020, treat the host and its network segment as potentially compromised; rebuild from known-good media rather than trusting an in-place patch alone.
3. Rotate credentials broadly. Reset credentials for any accounts that authenticated to or from the Orion server, including service accounts, and rotate SAML token-signing certificates on federated identity infrastructure to invalidate any forged tokens.
4. Hunt for IOCs. Search logs and endpoints for known SUNBURST/TEARDROP/Raindrop file hashes and for DNS resolutions to avsvmcloud[.]com and related subdomains.
5. Segment monitoring infrastructure. Restrict outbound internet access from network management servers like Orion, since legitimate monitoring tools rarely need broad egress and this connectivity is exactly what SUNBURST relied on for command-and-control.
6. Verify software provenance going forward. Require signed, verifiable build attestations and SBOMs from vendors, and monitor for anomalous changes in vendor-delivered binaries rather than trusting code signing alone as proof of safety.

How Safeguard Helps

The SolarWinds attack is the canonical argument for treating your software supply chain as an attack surface, not just a compliance checkbox. Safeguard ingests and generates SBOMs across your build pipeline so you have a verifiable record of every component and version in production, making it possible to instantly identify which systems ran an affected Orion build the moment a case like SUNBURST or CVE-2020-10148 breaks. Our reachability analysis goes further than CVSS or EPSS scores alone, tracing whether a vulnerable API path or component is actually invoked by your code so teams can prioritize the CVE-2020-10148-style critical-and-exploited flaws that matter most instead of drowning in advisory noise. Griffin AI continuously correlates new KEV entries and threat intelligence against your live SBOM inventory, surfacing exposure the moment a vendor discloses a compromise. And when a fix is available, Safeguard's auto-fix PRs open the version bump directly against your repositories, cutting the gap between disclosure and remediation from weeks to hours.