SolarWinds SUNBURST: How Russia Hid a Backdoor in 18,000 Software Updates and Read US Government Email for Nine Months

In October 2019, Russian intelligence operatives embedded malware into the build system of SolarWinds, an Austin-based company that made network management software used by 33,000 organizations including the US Treasury, Department of Homeland Security, Department of Justice, Department of State, parts of the Pentagon, and eighteen thousand other customers worldwide.

For the next fourteen months, the malware - later named SUNBURST - sat dormant inside legitimate, signed software updates that SolarWinds shipped to its entire customer base. No one knew. The attackers selected approximately one hundred high-value targets from the eighteen thousand who installed the backdoor, and spent months moving laterally through government and corporate networks. They read emails. They accessed classified systems. They stole security tools. When FireEye finally detected the intrusion and disclosed it publicly on December 13, 2020, it triggered one of the largest cybersecurity investigations in US government history.

//The Supply Chain as Attack Surface

The defining characteristic of the SolarWinds attack - and the reason it became a landmark case - is that no vulnerability was exploited in any victim's network. The attacker did not need to breach Treasury or DHS directly. They breached SolarWinds, and then waited for Treasury and DHS to voluntarily install the compromised software through the normal update mechanism, authenticated with SolarWinds' legitimate code-signing certificate.

This is the logic of supply chain attacks: rather than attacking a hardened target directly, attack a trusted vendor whose software is already present in the target environment. The security team at the target organization never evaluates the actual content of the SolarWinds DLL - they trust that SolarWinds evaluated it, that their integrity check passed, and that their antivirus didn't flag it. All of those checks passed. The DLL was legitimate. The backdoor was in it.

SUNSPOT - The Build System Implant

The implant that enabled the supply chain injection was a separate piece of malware called SUNSPOT, deployed on SolarWinds' build server before SUNBURST was created. SUNSPOT's sole function was to monitor the build system for compilation of a specific SolarWinds DLL - SolarWinds.Orion.Core.BusinessLayer.dll - and replace the source file on disk with a backdoored version at compile time.

This is a sophisticated choice. Rather than modifying the DLL directly (which would bypass code signing), SUNSPOT injected malicious source code into the build pipeline so the compiler would compile the backdoor as a legitimate part of the final binary, which was then signed by SolarWinds' automated build system with their valid code signing certificate.

The signed, backdoored DLL was then distributed via SolarWinds' official update infrastructure to every customer who had automatic updates enabled for Orion. Approximately 18,000 organizations installed it.

//SUNBURST - The Backdoor

The SUNBURST backdoor was written in C# and designed to blend into the legitimate Orion codebase. It used the same internal class and method naming conventions as the surrounding code and stored its configuration in the Windows Registry under a key that resembled Orion's legitimate keys.

After the dormancy period, SUNBURST began beaconing to a command-and-control domain: avsvmcloud.com. The beacon was designed to look like legitimate Orion network traffic - SUNBURST used HTTP with headers that matched what Orion itself generated. The communication used a custom protocol encoded in DNS subdomains and HTTP responses.

Each victim's hostname, domain, and environment details were encoded in the DNS subdomain of the beacon request. The operators at the other end of avsvmcloud.com used this to identify which installations were worth pursuing further. The vast majority of the 18,000 installations were evaluated and ignored. Approximately 100 were selected for active exploitation.

The Selection Process

The degree of care the operators applied to target selection was notable. After the dormancy period, SUNBURST first checked the victim environment for security tools - if specific AV products, security research tools, or endpoint detection software was running, the backdoor would inactivate itself. If the victim domain contained strings suggesting it was a security company, researcher, or test environment, the backdoor would self-terminate.

This behavior was not accidental. The operators were trying to avoid discovery, and the most likely source of discovery was a security researcher examining the malware in a controlled environment. By checking for the presence of security tooling and refusing to activate in those environments, SUNBURST significantly reduced its exposure.

//TEARDROP, RAINDROP, and Active Exploitation

For the organizations selected for active exploitation, the operators deployed a second-stage loader - initially called TEARDROP, later a variant named RAINDROP - which loaded a Cobalt Strike Beacon into memory. Cobalt Strike is a legitimate commercial penetration testing platform that has become the de facto post-exploitation framework of choice for sophisticated threat actors because it generates relatively normal-looking HTTPS traffic and has extensive in-memory execution capabilities.

From the Cobalt Strike foothold, the operators began Active Directory reconnaissance - mapping user accounts, group memberships, service accounts, and federation trust relationships.

Golden SAML - The Cloud Pivot

The most significant technique employed during the active exploitation phase was "Golden SAML" - a cloud authentication attack analogous to the well-known "Golden Ticket" attack against on-premises Kerberos.

Active Directory Federation Services (ADFS) allows organizations to extend on-premises identities into cloud services like Microsoft 365, Azure, and other SAML-based applications. ADFS signs authentication assertions using a certificate stored on the on-premises ADFS server. An attacker with access to that certificate can forge SAML assertions for any user, with any role, bypassing MFA entirely, because the cloud service trusts any assertion signed by the known certificate.

The operators extracted ADFS signing certificates from compromised on-premises AD infrastructure and used them to forge SAML tokens that granted persistent, privileged access to Microsoft 365 tenants. This gave them access to email, SharePoint, Teams, and other cloud-hosted data without touching the on-premises infrastructure again - and without triggering the conditional access policies that would have flagged unusual sign-in patterns.

//What Was Taken

The full scope of what was accessed remains classified in some areas, but what has been confirmed publicly includes: internal communications and emails at the Treasury Department, including from officials at the Office of Domestic Finance and the Office of International Affairs; internal DHS emails; DOJ Microsoft 365 tenant access affecting approximately 3% of its mailboxes; source code from Microsoft internal repositories; and FireEye's red team tools, which were stolen and subsequently released publicly by the attackers.

Nine federal agencies and approximately one hundred private sector organizations were confirmed as actively exploited. The full list has not been disclosed.

//Discovery and Response

FireEye discovered the intrusion not by detecting SUNBURST but by noticing suspicious activity in their own environment - specifically, an unusual device registered in their multi-factor authentication system from what appeared to be a new device used by an existing employee. The employee confirmed they had not registered a new device. This triggered an investigation that eventually traced back to the compromised Orion DLL.

FireEye notified the FBI, Microsoft, and CISA before going public. On December 13, 2020, FireEye published a detailed technical blog post on SUNBURST along with detection rules - simultaneously disclosing the campaign to the public and providing the indicators needed to identify compromised systems.

CISA issued Emergency Directive 21-01 requiring all federal civilian agencies to immediately power off or disconnect any system running Orion software. SolarWinds released a patched version. The DNS domain avsvmcloud.com was seized and sinkholed by Microsoft, cutting the C2 channel.

//Attribution and Context

The US government formally attributed the attack to the Foreign Intelligence Directorate of Russia (SVR), specifically the threat group tracked as APT29 or Cozy Bear. The same group was previously attributed to the 2016 Democratic National Committee breach and the 2014-2015 hack of unclassified State Department and White House email systems.

The sophistication of the operation - the patience, the operational security, the selection process, the use of legitimate infrastructure to blend with normal traffic, the focus on intelligence collection rather than disruption - is consistent with a nation-state intelligence collection operation rather than cybercriminal activity. The operators were inside some systems for nine months without triggering detection. They left specific systems alone to avoid drawing attention. They prioritized access breadth over immediate exploitation.

The total dwell time from initial compromise of SolarWinds' build system to public disclosure was approximately fourteen months.

//Legacy

The SolarWinds case fundamentally changed how the security community and US government think about software supply chain risk. Prior to December 2020, the build pipeline was not typically included in the threat model for enterprise software procurement. After December 2020, it was.

The Biden administration's Executive Order 14028 on Improving the Nation's Cybersecurity, signed in May 2021, directly addressed supply chain security, including requirements for software bill of materials (SBOM), enhanced software development security practices, and endpoint detection requirements for federal contractors. The SUNBURST attack is the direct provocation for that order.

The fundamental problem it exposed - that you cannot verify the integrity of software you receive from a vendor just because it is signed - has not been solved. Signed software still means only that the binary was signed by whoever holds the signing key. It says nothing about whether the build system that produced the binary was compromised. Build-time attestation, reproducible builds, and supply chain security frameworks address parts of this, but widespread implementation remains a work in progress.