SolarWinds — Sunburst supply-chain compromise
Russian SVR operators compromised SolarWinds' Orion build server and pushed the Sunburst backdoor via a signed software update to 18,000 customers including nine federal agencies.
- Target
- SolarWinds — Sunburst supply-chain compromise
- Date public
- 13 December 2020
- Sector
- Technology
- Attack type
- Supply Chain
- Threat actor
- APT29 / Cozy Bear / Nobelium (Russian SVR)
- Severity
- Critical
- Region
- Global — US federal government and Fortune 500 customers
In late 2020 it became clear that Russian intelligence operatives had backdoored an update to SolarWinds Orion, a network-monitoring product widely deployed across US federal agencies and Fortune 500 enterprises. Roughly 18,000 organisations downloaded the poisoned update — including the US Treasury, State Department, Justice Department and several others — though the attackers selectively activated the backdoor only against approximately 100 high-value targets. Once inside, they pivoted from the Orion backdoor to forging cloud authentication tokens, retaining access to victim Microsoft 365 environments long after the original backdoor was removed. SolarWinds is the case study for software-supply-chain trust: every customer was breached by doing exactly what their controls told them to do — install signed updates from trusted vendors.
In December 2020 FireEye disclosed that it had been breached and that the entry point was a backdoored update to SolarWinds Orion, a network-monitoring product widely deployed across US federal agencies and Fortune 500 enterprises. The attackers — later attributed by US intelligence services to Russia’s Foreign Intelligence Service (SVR), tracked variously as APT29, Cozy Bear and Nobelium — had compromised SolarWinds’ build server in mid-2020 and inserted a malicious payload, dubbed Sunburst, into the Orion software that SolarWinds then signed and shipped to its customers as a routine update. Roughly 18,000 organisations installed the backdoor between March and June 2020, though the attackers selectively activated it only against approximately 100 high-value targets.
The activated victims included the US Departments of State, Treasury, Commerce, Energy, Homeland Security and Justice, the National Telecommunications and Information Administration, Microsoft, FireEye, and the National Nuclear Security Administration. The actors used the Orion backdoor as initial access, then pivoted to forging SAML tokens via stolen Active Directory Federation Services signing keys, granting themselves persistent access to victim cloud environments — particularly Microsoft 365 — that did not depend on the compromised Orion installation. This second-stage technique, dubbed “Golden SAML”, allowed access to remain even after the Orion update was reverted.
The remediation effort took years. CISA’s Emergency Directive 21-01 ordered federal agencies to disconnect or power down Orion installations within 24 hours of disclosure; subsequent guidance dealt with rotating ADFS signing keys and reviewing all M365 sign-ins back to mid-2020. SolarWinds’ market capitalisation halved within weeks. The SEC subsequently charged SolarWinds and its CISO with disclosure-controls failures in 2023, the first time a sitting CISO had been named personally in such an SEC action.
Defender takeaway: Sunburst is the case study for software-supply-chain trust. Every customer that installed the backdoor did so in good faith from a signed update by a trusted vendor; none of them did anything wrong by their existing controls. The defensive shifts that followed — software bills of materials, build-environment hardening, reproducible builds, more conservative trust models for vendor-pushed updates — have all been driven by the policy and standards response to this one incident. The other lasting lesson is the second-stage pivot: even after Orion was disabled, the actors persisted via cloud-identity infrastructure that the affected organisations did not initially associate with the breach. Modern incident response on a SolarWinds-class compromise has to assume that any token-issuance authority touched by the attacker is also compromised, and rotate credentials accordingly.
Controls that would have helped
Defender controls catalogued in the Controls Desk that would have changed the outcome of this incident, or limited its blast radius. Sourced from regulator and framework guidance — never vendors.
- Just-in-time privilege elevation, not standing admin Standing admin rights on a privileged account give the attacker the same window the legitimate admin has. Just-in-time elevation collapses that window to minutes.
- Protective DNS — block command-and-control and known-bad domains at the resolver Almost every modern intrusion phones home over DNS. A protective resolver that blocks known-bad domains breaks the chain after initial access, often before the operator notices.
- Active Directory tier-0 hardening — protected accounts, no SPNs on privileged users, monitored sensitive groups AD remains the highest-blast-radius identity tier in most enterprises. A small set of hardening configurations turns the most reliable lateral-movement playbooks into observable, blockable failures.
- Centralised log collection with bulk-export anomaly alerting The most common dwell-time signal in the catalogue is a bulk-query or bulk-export pattern that nobody alerted on. Collect the logs, retain them, and alert when they tell you what's happening.
- Privileged Access Workstations for tier-0 administration Domain admins and cloud-tenant root holders should not be checking email and admining the directory from the same laptop. Separate the device, separate the trust tier.