The SolarWinds compromise, disclosed in December 2020, remains the defining software supply chain attack. Attackers, later attributed by the US government to Russia's Foreign Intelligence Service (SVR), got into SolarWinds' build environment and slipped a backdoor, known as SUNBURST, into signed updates of the Orion IT monitoring platform. Up to 18,000 customers downloaded the tainted updates. For the victims the attackers chose to pursue, the next step was an identity attack: stealing SAML token-signing certificates, forging authentication tokens and adding credentials to cloud application identities to read email. Much of the damage was done with non-human identities.
Key takeaways
- SolarWinds says the attackers used compromised credentials to gain persistent access to its development environment and Microsoft Office 365 for at least nine months before a test run in October 2019.
- A tool called SUNSPOT injected SUNBURST into Orion builds released between March and June 2020, so the backdoor shipped in legitimately signed updates. Up to 18,000 customers downloaded affected versions; SolarWinds says fewer than 100 saw follow-on command-and-control activity.
- In victim environments, Microsoft saw attackers use admin access to steal the SAML token-signing certificate, forge tokens, and "add illegitimate credentials to existing application service principals".
- The White House said 9 federal agencies and about 100 private companies were compromised, and in April 2021 formally attributed the campaign to Russia's SVR.
- Build systems, signing keys, federation certificates and application credentials are all non-human identities. Each needs an owner, tight scope and monitoring.
At a glance
| Organisations | SolarWinds (supplier); downstream victims including US federal agencies and technology companies such as FireEye, Microsoft and Malwarebytes |
|---|---|
| When | Access to SolarWinds by early 2019; malicious builds released March to June 2020; disclosed December 2020 |
| Attacker | Attributed by the US government in April 2021 to Russia's Foreign Intelligence Service (SVR) |
| Entry point | Compromised credentials into SolarWinds' development environment; SUNSPOT injector in the Orion build process |
| Identities abused | SolarWinds build and code-signing trust; SAML token-signing certificates; application service principal credentials; privileged admin accounts |
| Impact | Up to 18,000 customers received the backdoor; 9 federal agencies and about 100 companies compromised (White House, February 2021) |
| Category | NHI, software supply chain |
What happened
SolarWinds' own investigation found that the attackers "compromised credentials and conducted research and surveillance" through persistent access to its software development environment and internal systems, including its Microsoft Office 365 environment, "for at least nine months prior to initiating the test run in October 2019". It could not confirm the original way in, listing a zero-day in a third-party application, a brute-force attack or social engineering as possibilities.
In October 2019 the attackers tested whether they could inject code into Orion builds. Then, using a tool now called SUNSPOT, they "surreptitiously injected the SUNBURST malicious code solely into builds of the Orion Software Platform", without changing the source code repository. The tampered builds were signed and shipped as normal updates between March and June 2020.
The compromise came to light in December 2020. In its 14 December 2020 SEC filing, SolarWinds said fewer than 18,000 of its roughly 33,000 Orion customers may have installed the compromised updates. Most never saw further activity; SolarWinds later said fewer than 100 customers experienced command-and-control contact. For selected targets, the attackers moved on to hands-on intrusion, with a strong focus on cloud identity and email.
On 17 February 2021, White House deputy national security adviser Anne Neuberger said "9 federal agencies and about 100 private sector companies were compromised". On 15 April 2021, the White House formally attributed the campaign to Russia's SVR and announced sanctions.
Timeline
| Date | Event |
|---|---|
| By early 2019 | Attackers have persistent access to SolarWinds' development environment and Office 365, using compromised credentials. |
| October 2019 | Test run of code injection into Orion builds. |
| March to June 2020 | Orion builds containing SUNBURST are released to customers. |
| December 2020 | The compromise is discovered and disclosed. |
| 14 December 2020 | SolarWinds SEC filing: fewer than 18,000 customers may have installed affected versions. |
| 21 December 2020 | Microsoft publishes recovery guidance for systemic identity compromise. |
| 17 February 2021 | White House: 9 federal agencies and about 100 companies compromised. |
| 15 April 2021 | US government attributes the campaign to Russia's SVR and announces sanctions. |
| 7 May 2021 | SolarWinds publishes its investigative update on the attack timeline. |
How it happened: the identity attack path
- Compromised credentials at the supplier. The attackers entered SolarWinds with compromised credentials and stayed for months across development systems and Office 365.
- Abuse of build trust. SUNSPOT modified builds on the fly, so the code signing process, a machine identity customers trusted implicitly, put SolarWinds' signature on the backdoor.
- Trusted update, trusted foothold. Customers installed the signed update through normal processes. Orion is an IT monitoring platform with wide visibility of the network, which gave the backdoor a well-placed starting point.
- Privilege escalation on-premises. In selected victims, attackers obtained administrative permissions in the on-premises environment.
- Golden SAML. Microsoft describes intruders using those permissions "to gain access to an organization's trusted SAML token-signing certificate", then signing their own SAML tokens. Forged tokens let them log in as any user to federated services without a password or MFA prompt.
- Hijacking application identities. With highly privileged accounts, attackers added "illegitimate credentials to existing application service principals". Those app identities often already held permissions such as mail access through Microsoft Graph, so the attackers could read email as a trusted application rather than as a user.
Impact
- Reach: up to 18,000 organisations installed the backdoor; fewer than 100 saw command-and-control activity according to SolarWinds.
- Confirmed victims: 9 US federal agencies and about 100 private companies, according to the White House, including FireEye, Microsoft and Malwarebytes, which disclosed breaches.
- Response: widespread incident response and long recovery work in affected identity systems, including certificate rotation and application credential reviews, following guidance such as Microsoft's.
- Policy: US sanctions against Russia in April 2021, and a lasting push on software supply chain security and secure build practices.
What this means for NHI governance
SolarWinds is often told as a story about malicious code, but the lasting lessons are about identity, and mostly non-human identity. The build pipeline and its signing key were machine identities that customers trusted without question. Once the attackers controlled the build, the signature vouched for them.
Inside victim networks, the most powerful moves used machine trust too. A SAML token-signing certificate is a non-human credential that can mint an identity for any user. Application service principals are non-human identities that often hold standing, high-value API permissions and are rarely reviewed. Adding a new secret or certificate to an existing app gave the attackers persistent, quiet access that blended in with normal application traffic. Few organisations at the time monitored when credentials were added to service principals, or knew which apps could read all mail.
The same patterns appear in more recent breaches on our timeline, such as the Microsoft Midnight Blizzard breach, where a legacy test OAuth application was abused to reach corporate email. Treating signing keys, federation certificates and app credentials as privileged identities, with owners, inventories and alerts, is now a baseline.
Recommendations
- Harden build systems as identity systems. Isolate build infrastructure, use separate short-lived credentials for build steps, verify build outputs against source (reproducible builds), and protect code signing keys in hardware.
- Protect federation signing keys. Treat SAML token-signing certificates as tier-zero secrets, store them in HSMs, and follow Microsoft's guidance to rotate the token-signing certificate twice after a suspected compromise.
- Monitor application credentials. Alert on any new secret or certificate added to an existing application or service principal, and review which apps hold broad permissions such as mail read access. See our Cloud Workload Identity Guide.
- Minimise standing privilege. Use just-in-time elevation for admin roles, as covered in our Privileged Access Management Guide.
- Limit monitoring tool reach. IT management and monitoring platforms need broad visibility, but their service accounts should not hold domain or cloud admin rights.
- Inventory every non-human identity. Include service principals, certificates and signing keys in your NHI inventory, as described in the NHI Lifecycle Management Guide.
Frequently asked questions
How many organisations were affected by the SolarWinds attack?
Up to 18,000 SolarWinds customers installed Orion updates containing the SUNBURST backdoor. The White House said 9 federal agencies and about 100 private companies were actually compromised.
What is Golden SAML, and how was it used?
Golden SAML is forging SAML authentication tokens with a stolen token-signing certificate. Microsoft reported attackers using admin access to obtain the certificate and then sign tokens that let them log in as any user to federated services.
Why is SolarWinds a non-human identity breach?
The attack abused machine trust at every stage: the build and code signing process, SAML token-signing certificates and credentials added to application service principals. None of these are human accounts, yet each gave the attackers powerful, persistent access.
Related NHI Mgmt Group resources
Microsoft Midnight Blizzard breach · Codecov breach · Microsoft OAuth breach · NHI Authentication Guide
How NHI Mgmt Group can help
Securing Non-Human Identities (NHIs), including AI agents, is becoming increasingly crucial as attackers target signing keys, certificates, service principals, API keys, tokens and OAuth credentials. Our NHI Foundation Level Training Course gives teams the practical grounding to find, govern and protect these identities.
References
- SolarWinds: An Investigative Update of the Cyberattack (7 May 2021)
- SecurityWeek: SolarWinds Says 18,000 Customers May Have Used Compromised Orion Product (December 2020), on the 14 December 2020 SEC filing
- Microsoft: Advice for incident responders on recovery from systemic identity compromises (21 December 2020)
- CISA: Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments (AA21-008A)
- TechTarget: White House: 100 companies compromised in SolarWinds hack (February 2021)
- CyberScoop: White House slaps sanctions on Russian cyber activities while blaming SVR for SolarWinds campaign (April 2021)
