SolarWinds Supply Chain Attack

The SolarWinds supply chain attack was a 2020 compromise of the Orion software build process that placed the SUNBURST backdoor inside legitimate vendor updates. Those releases reached enterprise customers through normal distribution channels, and the incident became public in December 2020. The U.S. Government Accountability Office later examined the breach as part of its review of federal cybersecurity.

An affected download did not, by itself, establish that attackers had penetrated a customer's network. Installation, malicious execution, and subsequent unauthorized access were separate findings, not interchangeable measures of impact. Orion's position within enterprise infrastructure explains why altering vendor-produced software created a potential entry point into customer environments.

What Was the SolarWinds Supply Chain Attack?

The SolarWinds supply chain attack exploited the trusted position of Orion, SolarWinds' network monitoring and management platform, within enterprise IT environments. Organizations used Orion to monitor servers, network devices, and other infrastructure across on-premises and hosted systems.

Some Orion deployments had extensive network visibility and elevated management privileges, making them attractive targets for attackers seeking access to sensitive infrastructure. The permissions available to the platform depended on each organization's configuration, so the potential reach of a compromised installation varied. CISA's December 2020 alert called for urgent action by organizations running affected versions of the software.

Customers relied on SolarWinds to develop and maintain Orion, but they had limited visibility into the vendor's internal software production processes. SolarWinds controlled how updates were built and released, whereas customers determined which versions to install and where to deploy them. This division of responsibility made the integrity of the vendor's development environment critical to the security of customer installations.

How Did the SolarWinds Supply Chain Attack Work?

Intruders moved from SolarWinds' development environment into its software production workflow, ultimately distributing altered Orion releases to customers. SUNSPOT enabled the build manipulation, SUNBURST provided the customer-side backdoor, and later intrusions required separate attacker actions.

solarwinds supply chain attack explained

Development Environment Access

The company's February 2021 investigation identified unauthorized activity on systems associated with development. Compromised employee credentials were linked to access in that environment, but investigators examined several possible original entry paths. They did not conclusively determine how the attackers first entered SolarWinds' infrastructure.

SUNSPOT Build Manipulation

Within that environment, SUNSPOT helped attackers interfere with the Orion build process. The malicious code facilitated the insertion of SUNBURST functionality into software being produced and used concealment techniques intended to avoid immediate detection. Its role was confined to the producer's environment; the customer-side backdoor was a different component.

Compromised Orion Updates

The altered build yielded releases containing SUNBURST, including modifications to SolarWinds.Orion.Core.BusinessLayer.dll. That DLL became part of official Orion packages, allowing customers to obtain the compromised component through established update channels.

As documented in SolarWinds' historical security advisory FAQ, the affected releases passed through the legitimate signing process. A valid signature helps authenticate the signer and verify that an artifact has not changed since signing; it does not prove the code was benign before signing occurred. The malicious modification preceded that step. SUPERNOVA, also addressed in the advisory materials, was a separate security issue and did not belong to the SUNBURST injection chain.

SUNBURST Backdoor Execution

When an affected Orion installation loaded the modified DLL, SUNBURST code could run within the application. CISA's technical advisory described its staged behavior, which did not necessarily lead to interactive attacker access:

Component execution: An affected installation loaded the trojanized library.
Delayed activation: The backdoor waited and checked conditions in its environment.
Initial contact: It attempted communications associated with the attacker-controlled avsvmcloud.com domain, using traffic designed to resemble legitimate Orion activity.
Selective commands: DNS responses could redirect particular installations to interactive command-and-control infrastructure for attacker instructions.

Execution of SUNBURST or an observed backdoor-associated connection provided grounds for investigation; neither alone proved that other systems had been breached.

Follow-On Intrusions

In selected environments, attackers obtained or misused privileges to reach additional systems. The extent of intrusion depended on the opportunities present at the target, not solely on which update it received.

Documented cases in the broader campaign involved privileged account misuse, compromised credentials, authentication trust abuse, and unauthorized cloud access. CISA's analysis of activity in Microsoft cloud environments also described initial-access methods unrelated to compromised Orion updates. Investigators consequently had to identify the actual entry path and subsequent behavior for a given organization.

SolarWinds Attack Chain

The decisive transitions took place between the vendor's internal systems, its release channel, and infrastructure managed by customers. Responsibility for protecting those environments, along with the evidence available to investigators, changed at each boundary.

Stage	Control Boundary	Transition	Result
1. Supplier access	SolarWinds internal infrastructure	Unauthorized access reached development-related systems	The original entry method remained unresolved
2. Build manipulation	Software production	SUNSPOT helped place SUNBURST in Orion artifacts	Malicious functionality entered the release
3. Update distribution	Vendor to customer	Official signed packages carried the altered DLL	Customers could download affected software
4. Backdoor activity	Customer Orion installation	The DLL executed and attempted attacker-controlled communication	An opportunity for further commands arose
5. Conditional intrusion	Customer identities, systems, and cloud services	Selected targets experienced subsequent attacker actions	Deeper unauthorized access required separate confirmation

The vendor's investigation could reconstruct changes to its own production systems, but determining what occurred after installation required evidence from the customer environment.

When Did the SolarWinds Attack Occur, and How Was It Discovered?

The company's investigative timeline traced suspicious internal activity to 2019, before malicious releases circulated and the compromise became public.

Date / Period	Key Event	Qualification
September 2019	Earliest suspicious internal activity identified in the January 2021 investigation	Not a conclusively established first intrusion date
October 2019	Apparent testing of Orion build modifications	Described by the company as apparent testing
February 20, 2020	Updated malicious injection source associated with SUNBURST insertion	Build activity, not customer installation
March–June 2020	Distribution of affected Orion releases	Distribution did not establish follow-on intrusion
June 2020	Reported removal of SUNBURST injection code from the producer's environment	Customer-side attacker access might have persisted
December 8, 2020	FireEye disclosed its own security intrusion	Distinct from Orion-specific discovery
December 12, 2020	FireEye notified SolarWinds about malicious Orion code	Vendor notification date
December 13, 2020	The Orion compromise became public and CISA issued emergency directions	Public response milestone

FireEye discovered evidence of the altered Orion component during its investigation into a breach of its own systems. Its December 12 notification connected that incident to software originating from an outside vendor. The December 17 SolarWinds update described the company's ensuing investigation and response, which helped trigger reviews of potentially affected installations across government and industry.

Who Was Responsible for the SolarWinds Attack?

In April 2021, the United States and United Kingdom publicly attributed the campaign to Russia's Foreign Intelligence Service (SVR). MITRE ATT&CK records the SolarWinds Compromise as campaign C0024 and associates it with APT29. Researchers have also used UNC2452, NOBELIUM, Dark Halo, and SolarStorm for related activity, though different organizations' tracking categories do not necessarily have identical boundaries. SUNSPOT and SUNBURST name malware components, not separate threat actors.

Tracking how groups like APT29 operate, including their tooling, targets, and techniques, is the work of threat intelligence. CloudSEK Threat Intelligence profiles threat actors and campaigns so defenders can recognize familiar tradecraft early.

How Many Organizations Were Affected by the SolarWinds Attack?

According to SolarWinds’ December 14, 2020 SEC filing, up to 18,000 customers had potentially downloaded implicated Orion releases. This was an estimate of potentially affected downloads, not a count of confirmed intrusions.

Evidence State	What It Establishes	What It Does Not Automatically Prove
Affected update downloaded	An implicated Orion release was obtained	Installation or successful compromise
Affected software installed	A compromised release was deployed	Access to other systems
SUNBURST communication observed	Backdoor-associated contact with potential attacker infrastructure	Organization-wide intrusion
Follow-on intrusion	Investigation identified subsequent unauthorized activity	Every step or consequence is fully known
Documented impact	Particular security consequences were identified	Equivalent consequences at all affected organizations

Using available DNS-related evidence, SolarWinds later estimated that fewer than 100 customers had been hacked through SUNBURST. Some customers had downloaded the affected software without installing it; others deployed it on machines unable to contact the attacker's server. The figure remains a historical company estimate, not an independently verified final worldwide count. Documented consequences reached both government agencies and private-sector organizations, but their individual circumstances differed.

Why Was the SolarWinds Attack Difficult to Detect?

Identifying the differences in customer outcomes required investigators to recognize malicious behavior within an authentic application and distinguish ordinary administration from unauthorized use of trusted accounts.

Trusted Software Execution

Because SUNBURST ran inside an official Orion component, publisher-authenticity checks offered little help in identifying the altered code. Analysts needed component-integrity findings or suspicious behavior to recognize that a familiar application was performing an unintended function.

Delayed Network Activity

Dormancy reduced the likelihood of an immediate alert after installation. The backdoor's traffic also resembled expected Orion communications, making historical DNS queries and connection records important once investigators knew what to look for. Relevant events might have occurred months before public disclosure.

Selective Attacker Activity

Valid accounts and familiar administrative mechanisms could conceal unauthorized actions after an initial foothold. CISA's guidance on the broader campaign addressed persistence and authentication abuse that complicated investigations. Analysts therefore had to examine the timing and context of account actions rather than treating a recognizable administrative tool as proof of benign activity. Gaps in historical records limited the certainty of those judgments.

Forensic Evidence

Host artifacts and cloud identity records answered different parts of the investigation. CISA's CHIRP tool, whose original repository is archived, aided on-premises searches across Windows events, registry artifacts, network indicators, and YARA-based findings. For cloud analysis, Sparrow and Aviary helped examine suspicious Azure and Microsoft 365 identities and applications and interpret the resulting data. None of these tools, by itself, confirmed a completed intrusion.

Evidence Source	Investigation Focus	Supported Interpretation	Limitation
Orion version and DLL integrity	Affected release or component	Potential software compromise	Does not prove downstream intrusion
Historical DNS and network telemetry	Backdoor-associated communications	Possible or observed malicious contact	Cannot define the whole incident alone
Windows event and process logs	Unexpected execution or administrative action	Suspicious host behavior	Legitimate administration may look similar
Registry and file artifacts	Persistence or further malware indications	Possible malicious host artifacts	Matches need validation
Microsoft cloud audit records	Accounts, applications, and identity events	Possible unauthorized cloud access	Needs corroboration and account context
Correlated forensic evidence	Relationships across software, network, host, and identity findings	Better-grounded assessment of intrusion scope	Missing records leave uncertainty

How Can Organizations Prevent SolarWinds-Style Supply Chain Attacks?

The investigative challenges highlight why customer response cannot replace safeguards in software production. Producers need controls that protect builds and releases, and customers need procedures for assessing and containing compromise after deployment.

Development Access

Producers should restrict privileged access to source repositories, development infrastructure, and build systems. Dividing administrative responsibilities and limiting credentials to authorized personnel reduces opportunities to tamper with critical resources. NIST's Secure Software Development Framework (SSDF), SP 800-218, describes practices for protecting these parts of the development lifecycle.

Build Integrity

Controls around compilation and artifact generation need to detect changes to source inputs, production tools, or build procedures that have not been approved. Traceability between authorized code changes and generated files gives engineering teams a way to investigate discrepancies before publication.

Release Assurance

Before publication, a release approval step should verify that the intended artifacts correspond to authorized changes. Signing credentials and distribution systems also require restricted access, since compromising either creates another opportunity to interfere with the release process. These checks address the transition from a completed build to software offered for installation.

Exposure Assessment

Customers should inventory implicated versions and identify the systems on which they were installed. Application permissions, connected services, and reachable infrastructure determine which deployments deserve closer scrutiny. An installation with broad administrative reach presents a different investigation scope from a more isolated instance.

Intrusion Investigation

Preserved host, network, and identity records should inform whether response can remain limited to the affected application or must extend into connected systems. CISA's SolarWinds remediation guidance differentiated incident conditions, including cases involving compromised identity infrastructure. Findings involving privileged accounts or persistence require examination of the resources and trust relationships available through that access.

Containment and Recovery

Evidence of active compromise calls for containment proportionate to the threat, even before every investigative question has been resolved. Responders might isolate machines, revoke compromised credentials, remove persistence, or rebuild affected identity systems where warranted. Recovery is not complete until the team validates remediation and checks for residual attacker access.

How Can Third-Party Risk Intelligence Address Supplier Visibility Gaps?

Even with producer and customer controls in place, enterprises have limited visibility into the externally accessible assets and indirect dependencies of their software providers. Periodic assessments can miss newly exposed services, vulnerabilities, or changing vendor relationships. NIST's Cybersecurity Supply Chain Risk Management guidance, SP 800-161 Rev. 1, recommends managing such relationships over time. Intelligence collected from observable external sources adds useful context, although it cannot certify the integrity of a vendor's private build environment.

Those external findings become more useful when correlated with threats that might exploit them. CloudSEK SVigil replaces point-in-time vendor assessments with continuous monitoring of each supplier’s external attack surface, dark-web exposure, and leaked credentials, and maps third- and fourth-party dependencies that questionnaires rarely reach. Nexus AI connects these findings with external threat signals and exposed assets to prioritize potential attack paths. This allows security teams to evaluate supplier-related weaknesses without treating external intelligence as a substitute for secure development controls, endpoint monitoring, or incident investigation.

The pattern has not gone away. In March 2026, attackers compromised Trivy, a widely used open-source security scanner. LiteLLM’s build pipeline installed it without pinning a verified version, which let the attackers publish poisoned releases of the LiteLLM AI gateway to PyPI. CloudSEK’s investigation identified more than 2,500 organizations and roughly 434,000 CI/CD pipelines as potentially exposed. Like SolarWinds, the attack rode a trusted build process, and ‘potentially exposed’ did not mean ‘confirmed compromised.’ For AI dependencies specifically, CloudSEK AIVigil inspects AI packages and model files for malicious code before they reach production.

No single safeguard can show whether an update was built securely, whether malicious code led to deeper access, and which vendor weaknesses remain externally visible. Answering those questions requires integrity checks at the software producer, investigative evidence from customer systems, and informed oversight of third-party relationships.