SolarWinds Supply Chain Attack - CloudSEK

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.

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. The company's February 2021 investigation identified unauthorized activity on systems associated with development, but they did not conclusively determine how the attackers first entered SolarWinds' infrastructure.

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.

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.

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. The backdoor waited and checked conditions in its environment, then attempted communications associated with the attacker-controlled avsvmcloud.com domain, using traffic designed to resemble legitimate Orion activity.

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. In selected environments, attackers obtained or misused privileges to reach additional systems, the extent of intrusion depending on the opportunities present at the target.

Detection and attribution

The company's investigative timeline traced suspicious internal activity to 2019, before malicious releases circulated and the compromise became public. 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.

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.

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. 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 the attack was hard to detect

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. 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. 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.

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. The vendor's investigation could reconstruct changes to its own production systems, but determining what occurred after installation required evidence from the customer environment.