In December 2020, something nasty was discovered. SolarWinds, the enterprise IT monitoring vendor that thousands of organisations trusted, had been distributing malware to approximately 18,000 customers through what should have been routine software updates. The attack was carried out by Russian intelligence-linked group APT29 (also known as NOBELIUM or Cozy Bear), and it represented a new class of threat that changed how we think about supply chain risk: nation-state actors weaponising the software supply chain itself by compromising build systems.
Who got hit? U.S. federal agencies like the Department of Homeland Security, State Department, Commerce Department, and Treasury Department. Fortune 500 companies across multiple sectors. Even FireEye, a leading cybersecurity vendor, was compromised—and it was their detection of their own breach that blew the lid off the whole campaign.
The SUNBURST backdoor sat there, undetected, for over 14 months. This attack demonstrated something important: traditional perimeter and endpoint defences don’t work when the trusted software update mechanism itself becomes the attack vector. This incident became the defining moment in the broader software supply chain security landscape, reshaping how organisations approach build integrity and vendor trust.
So in this article we’re going to examine how the attack worked, why it was so difficult to detect, and what defensive frameworks emerged in response. Understanding SolarWinds as the watershed moment that reshaped software supply chain security matters for decisions you’ll be making about your own infrastructure.
What Is a Software Supply Chain Attack?
A software supply chain attack targets the development, distribution, or update mechanisms of trusted third-party software rather than attacking victim organisations directly. Instead of breaching each target individually, attackers compromise a single upstream vendor and gain access to thousands of downstream customers simultaneously—a 1-to-N distribution model.
This is dangerous because victims receive malicious code through channels they already trust: digitally signed software updates from verified vendors. Your security tools are monitoring for external threats, but they typically grant automatic trust to software arriving with valid digital signatures from established vendors.
The SolarWinds incident made it clear that even organisations with mature security programmes can be compromised when the threat arrives inside a legitimate, authenticated update package. Firewalls, endpoint detection, and application whitelisting all fail when malicious code arrives through authorised channels.
Supply chain attacks aren’t new. NotPetya used the M.E.Doc accounting software to spread ransomware across Ukraine and globally in 2017. CCleaner distributed malware through compromised installers that same year. But SolarWinds was a major escalation. Third-party breaches now account for 30% of all data breaches, up from negligible percentages just a few years ago.
The methodology works because it exploits fundamental trust relationships in modern software development. You can’t operate without third-party software. The question becomes: how do you verify what you’re receiving?
How Did APT29 Compromise the SolarWinds Build System?
APT29 gained access to the SolarWinds development environment and injected malicious code into the Orion Platform build pipeline. The attackers inserted approximately 4,000 lines of code into the SolarWinds.Orion.Core.BusinessLayer.dll file, using the class name OrionImprovementBusinessLayer to blend with legitimate code and avoid detection during code review.
Here’s the key detail: the malicious code was injected before compilation. The backdoor wasn’t added to compiled binaries; it was added to the source code and then compiled and digitally signed with SolarWinds’ legitimate certificate. From a verification perspective, the compromised update was indistinguishable from authentic software.
The timeline shows careful preparation. Threat actors gained unauthorised access to the SolarWinds network in September 2019. They tested initial code injection in October 2019. The actual SUNBURST backdoor was injected in February 2020, and compromised updates were distributed from March through June 2020, affecting Orion versions 2019.4 through 2020.2.1 HF1.
Multiple trojanised updates were digitally signed from March to May 2020 and posted to the SolarWinds updates website. Approximately 18,000 organisations downloaded and installed these updates. But APT29 selectively activated the backdoor in a much smaller subset of high-value targets—probably fewer than 100 organisations.
This selective targeting is worth understanding. Broadcasting the backdoor to 18,000 organisations while only activating it in specific targets reduced the risk of discovery. If only a handful of organisations are being actively exploited, the chance that one of them detects the intrusion and traces it back to the SolarWinds update is much lower than if all 18,000 installations were generating malicious traffic.
The attribution to APT29 comes from forensic analysis by Mandiant/FireEye and subsequent U.S. government statements attributing the operation to Russia’s Foreign Intelligence Service (SVR). Understanding that this is a state-sponsored actor matters because it tells you the level of resources, patience, and sophistication behind the attack. This wasn’t a ransomware gang looking for a quick payout.
What Made SUNBURST So Effective and Hard to Detect?
SUNBURST incorporated multiple anti-forensic techniques that delayed detection for over 14 months. Dwell time is the period between initial compromise and detection. The average dwell time in 2019 was 95 days according to CrowdStrike. SUNBURST’s 14+ months exceeded that average considerably.
The backdoor waited 12-14 days after installation before activating, avoiding detection during initial monitoring periods following software updates. Most organisations watch new deployments closely for the first few days. By waiting two weeks, SUNBURST ensured it would activate after that scrutiny period ended.
Before executing, SUNBURST performed several environmental checks. It verified that the machine was domain-joined and retrieved the domain name. It checked for analysis environments, validated domain names, and monitored for security tools. If any indicators of analysis were found, the malware terminated silently and updated its configuration to prevent further execution.
The backdoor used multiple obfuscated blocklists to identify forensic and anti-virus tools running as processes, services, and drivers. If it detected security tools, it would disable them. The malware actively suppressed defences by modifying registry entries.
Command and control communication used DNS queries to avsvmcloud[.]com, generating unique subdomains per victim. The subdomains were constructed by concatenating a victim user ID with a reversible encoding of the victim’s local machine domain name. This allowed the attackers to identify and route traffic from specific victims while making the DNS queries appear to be routine network activity.
The malware masqueraded its network traffic as the Orion Improvement Program (OIP) protocol and stored reconnaissance results within legitimate plugin configuration files, allowing it to blend in with legitimate SolarWinds activity. Even if you were logging all Orion traffic, the malicious activity looked exactly like normal Orion behaviour.
The digital signature trust exploitation deserves emphasis. Because the malware was legitimately signed with SolarWinds’ certificate, it bypassed application whitelisting and code integrity checks. Your systems were configured to trust code signed by SolarWinds. That trust was the attack vector.
Which Organisations Were Affected and What Was the Impact?
Approximately 18,000 organisations installed compromised Orion updates, though APT29 selectively targeted a smaller subset for active exploitation, focusing on high-value intelligence targets.
Confirmed affected U.S. federal agencies included the Department of Homeland Security, State Department, Commerce Department, and Treasury Department. That’s a penetration of U.S. government networks.
Fortune 500 companies across multiple sectors were affected. Private companies including FireEye, Microsoft, Intel, Cisco and Deloitte all suffered from the attack.
Post-compromise techniques included SAML token abuse. By compromising the certificates used to sign authentication tokens, attackers could forge tokens that granted access to cloud environments like Azure and Microsoft 365 without valid credentials. This effectively bypassed multi-factor authentication and allowed access to email, documents, and other cloud resources.
In targeted environments, attackers deployed additional tools for persistent access and lateral movement, including memory-only droppers and legitimate administrative tools. The attack deployed secondary payloads including TEARDROP malware and Cobalt Strike for persistent access and data exfiltration in high-value targets.
The impact extended beyond data theft. The breach fundamentally undermined trust in software update mechanisms and vendor security assurances across the industry. When a trusted vendor distributes malware through legitimate update channels, what do you do? Stop accepting updates? That’s not viable. The attack forced a rethinking of how software trust is established and verified.
What Warning Signs Indicate a Build System Compromise?
Unexpected changes to build artifacts should raise flags. If compiled output differs from source code, or checksums of build outputs change without corresponding source code commits, investigate. This requires having baseline measurements of what your build outputs should look like and the discipline to check them regularly.
Anomalous build system behaviour warrants scrutiny. Unexplained build process modifications, new build steps or scripts appearing without change records, or build infrastructure accessing unusual network resources are all indicators that something might be wrong. Build servers communicating with external hosts not associated with known package registries, version control systems, or legitimate build services is suspicious.
Suspicious code in build dependencies needs attention. Third-party libraries or packages introducing code that doesn’t align with their stated functionality—code that establishes network connections or accesses credentials—should be reviewed. The challenge is that most teams don’t have the resources to audit every dependency. This is where Software Bills of Materials become useful.
CI/CD pipeline configuration drift is a warning sign. Changes to pipeline definitions, runner configurations, or deployment scripts that weren’t made through standard change management processes indicate potential compromise. This assumes you have standard change management processes for your build infrastructure, which many organisations don’t. For practical steps on hardening CI/CD pipelines, including commit SHA pinning and runtime monitoring, organisations can implement controls that raise the cost of pipeline compromise.
Discrepancies between development and production artifacts matter. If software in production environments contains code or capabilities not present in the reviewed and approved source code, you have a problem. The SolarWinds attack demonstrated this: the production DLL contained code that wasn’t in the reviewed source because it was injected during the build process.
Build system monitoring requires resources. A practical approach focuses on: maintaining checksums of build outputs, implementing code provenance validation for production deployments, and monitoring build infrastructure network activity for unexpected connections. It’s not perfect, but it raises the bar. For a structured approach to establishing build integrity, see our guide on implementing the SLSA framework for build integrity.
How Did the Industry Respond to SolarWinds?
FireEye publicly disclosed the attack on 13 December 2020 after detecting the SUNBURST backdoor in their own environment. That disclosure triggered a coordinated industry-wide investigation involving Microsoft, CISA, and multiple security vendors. The fact that a leading cybersecurity vendor was compromised underscored the effectiveness of the supply chain attack methodology.
CISA issued Emergency Directive 21-01 requiring federal agencies to disconnect or power down affected SolarWinds Orion products. They developed the Sparrow.ps1 detection tool for assessing cloud compromise, which organisations could run to check for indicators of SAML token abuse and other post-compromise activity.
Microsoft and industry partners sinkholed the primary C2 domain (avsvmcloud[.]com) to IP address 20.140.0.1, functioning as a kill switch to disrupt attacker communication with compromised systems. DNS responses within specific IP ranges would cause the malware to terminate and update its configuration to prevent further execution.
In May 2021, President Biden signed Executive Order 14028, which mandated Software Bills of Materials (SBOM) for federal software procurement, established new cybersecurity standards for government suppliers, and required agencies to adopt Zero Trust architecture principles. This regulatory response changed requirements for any organisation selling software to the federal government.
Google proposed the SLSA framework in 2021—Supply-chain Levels for Software Artifacts—providing a structured approach to build integrity and provenance tracking. SLSA directly addresses the SolarWinds attack vector by requiring provenance attestation that proves a build artifact was produced from specific source code by a specific build process.
The attack accelerated adoption of software supply chain security practices including build provenance, dependency management, and vendor security assessment across both public and private sectors. Supply chain compromise accounted for 17% of intrusions in 2021 compared to less than 1% in 2020, though 86% of those 2021 intrusions were related to the SolarWinds breach itself.
Those frameworks and regulatory changes remain the foundation of supply chain security today. The SolarWinds attack raised fundamental questions about software supply chain security that organisations continue to grapple with.
FAQ Section
What is the difference between a supply chain attack and a regular hack?
A supply chain attack compromises a trusted third-party vendor to reach downstream targets through legitimate software distribution channels. A regular hack targets a specific organisation’s infrastructure directly. Supply chain attacks are more dangerous because victims receive malicious code through channels they already trust, bypassing perimeter defences. The SolarWinds attack compromised 18,000 organisations through a single vendor compromise.
How long did the SolarWinds attack go undetected?
The SUNBURST backdoor remained undetected for approximately 14 months. APT29 began testing injections in October 2019, deployed SUNBURST in February 2020, and the compromise wasn’t discovered until December 2020 when FireEye detected the backdoor. This extended dwell time was enabled by sophisticated anti-forensic techniques including delayed execution, sandbox detection, and C2 traffic that mimicked legitimate SolarWinds network activity.
What is APT29 and why does attribution matter?
APT29 (also tracked as NOBELIUM and Cozy Bear) is an advanced persistent threat group attributed to Russia’s Foreign Intelligence Service (SVR). Attribution to a nation-state actor matters because it tells you the level of resources, patience, and sophistication behind the attack. Understanding that state-sponsored actors target software supply chains helps organisations calibrate their risk assessment and justify investment in defensive frameworks.
Should my organisation be worried about supply chain attacks if we don’t use SolarWinds?
Yes. The SolarWinds attack demonstrated a methodology that can be applied to any software vendor’s development pipeline. Any organisation that relies on third-party software—which is effectively every organisation—faces supply chain risk. The relevant question isn’t whether you used SolarWinds Orion specifically, but whether your software vendors have adequate build security controls and whether you can verify the integrity of the software you deploy.
What is an SBOM and why did it become mandatory after SolarWinds?
A Software Bill of Materials (SBOM) is a comprehensive inventory of all software components and dependencies in a product, analogous to a nutritional label for software. Executive Order 14028, signed in May 2021 in direct response to the SolarWinds attack, mandates SBOM for software sold to the U.S. federal government. SBOMs enable organisations to rapidly identify whether they’re running affected components when a vulnerability or compromise is disclosed.
What is the SLSA framework and how does it prevent build system attacks?
SLSA (Supply-chain Levels for Software Artifacts) is a security framework proposed by Google in 2021, designed to ensure the integrity of software artifacts from source to deployment. It defines four maturity levels progressing from basic build documentation to fully reproducible builds with independent verification. SLSA directly addresses the SolarWinds attack vector by requiring provenance attestation that proves a build artifact was produced from specific source code by a specific build process.
How did FireEye discover the SolarWinds breach?
FireEye detected the compromise in December 2020 when they identified unauthorised access to their Red Team tools. During their investigation, they traced the intrusion to a backdoor in SolarWinds Orion software and named it SUNBURST. FireEye’s public disclosure triggered the broader investigation that revealed the scale of the campaign. The fact that a leading cybersecurity vendor was itself compromised underscored the effectiveness of the supply chain attack methodology.
What is SAML token abuse and how was it used in the SolarWinds attack?
SAML token abuse involves compromising the certificates used to sign authentication tokens, allowing attackers to forge tokens that grant access to cloud services without valid credentials. In the SolarWinds attack, APT29 used SAML token forgery to access victims’ cloud environments like Azure and Microsoft 365, read email, and exfiltrate data, effectively bypassing multi-factor authentication.
Can small and mid-size companies defend against nation-state supply chain attacks?
While no organisation can achieve absolute security against state-sponsored attackers, proportionate defences reduce risk. Practical steps include adopting SLSA Level 1-2 practices for build integrity, generating SBOMs to maintain component visibility, hardening CI/CD pipeline access controls, and implementing vendor security assessment processes. The goal isn’t to match nation-state offensive capability but to raise the cost of compromise beyond what attackers consider worthwhile for your organisation.
What is dwell time and why was it significant in the SolarWinds attack?
Dwell time is the period between initial compromise and detection. In the SolarWinds attack, dwell time exceeded 14 months, one of the longest recorded for a campaign of this scale. Extended dwell time allowed APT29 to conduct reconnaissance, move laterally across compromised networks, and exfiltrate data without triggering alerts. The SUNBURST backdoor’s built-in 12-14 day activation delay was designed to extend dwell time by avoiding detection during post-update monitoring windows.
What did Executive Order 14028 change about cybersecurity requirements?
Executive Order 14028, signed in May 2021, mandated changes including SBOM requirements for software sold to the federal government, adoption of Zero Trust architecture principles across federal agencies, enhanced security standards for software development lifecycle, improved information sharing between government and private sector regarding cyber threats, and establishment of a Cyber Safety Review Board. These requirements have cascading effects on private sector vendors serving government customers.
Conclusion
The SolarWinds SUNBURST attack demonstrated that nation-state actors can weaponise the software supply chain to achieve unprecedented scale and dwell time. By compromising the build system rather than individual targets, APT29 gained access to 18,000 organisations through a single vendor breach. The 14-month dwell time, sophisticated anti-forensic techniques, and exploitation of digital signature trust fundamentally challenged assumptions about software security.
The regulatory and technical responses—Executive Order 14028, SLSA, and SBOM adoption—represent the industry’s recognition that supply chain security requires systemic solutions. No single defence prevents these attacks, but layered controls raise the cost of compromise.
For organisations evaluating their supply chain risk, the SolarWinds case study clarifies that build integrity, vendor security assessment, and component visibility aren’t optional security enhancements. They’re foundational requirements for operating in an environment where trusted software update mechanisms can be compromised. To explore defensive frameworks, operational practices, and systemic challenges across the supply chain security landscape, see our comprehensive supply chain security guide.
