SolarWinds SUNBURST: A Build System Compromise, Re-Read in 2024

Threat Intelligence

Three years on, the SUNBURST campaign still defines how we think about software supply chain risk. A practitioner walkthrough of the timeline, the build pipeline failure, and the controls that would have caught it.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 1, 2024 · 9 min read

On December 13, 2020, FireEye (now Mandiant) disclosed that a trojanized SolarWinds Orion update had been used to breach its red team tooling. Within 72 hours the scope was clear: roughly 18,000 organizations had pulled the poisoned 2019.4 HF5 through 2020.2.1 builds, and a smaller curated subset was actively exploited. Reading the post-mortem in 2024, the technical lessons remain the most cited reference in any boardroom supply chain discussion.

Timeline of the intrusion

1. September 2019: UNC2452 (later attributed to SVR / APT29) gains initial access to SolarWinds' development environment.
2. October 2019: Test injection into the Orion build pipeline confirms the attackers can modify compiled DLLs without breaking signing.
3. February 2020: Production payload (SolarWinds.Orion.Core.BusinessLayer.dll) is injected during MSBuild; SUNBURST is live.
4. March to June 2020: Trojanized updates ship to ~18,000 Orion customers. SUNBURST waits 12 to 14 days before contacting avsvmcloud.com.
5. December 8, 2020: FireEye detects anomalous DUO MFA enrollment for an employee, triggers full IR.
6. December 13, 2020: Public disclosure. CISA issues Emergency Directive 21-01 the same week.

Root cause: the build server, not the source code

The clean source tree never carried the backdoor. SUNBURST was inserted by SUNSPOT, a separate implant running on the SolarWinds build server, which monitored MSBuild.exe processes and swapped a benign source file for a trojanized one during compilation. The signed binary that shipped was, from the perspective of every downstream verifier, legitimate. Code review and source-side SAST would not have caught this. Reproducible builds and signed provenance attestations (the conceptual ancestor of SLSA Level 3) would have.

What the operators actually did post-implant

SUNBURST's DNS beacon to avsvmcloud.com encoded a victim ID. The operators selectively activated TEARDROP and RAINDROP second-stage loaders only against high-value targets. Movement inside victim networks abused on-prem ADFS to mint forged SAML tokens (the Golden SAML technique), giving access to Microsoft 365 mail and SharePoint without ever touching a password. Mandiant later confirmed the operators read email of specific named individuals at multiple federal agencies.

Detection signals defenders should bake in

• Outbound DNS to avsvmcloud.com and its subdomains, plus any newly observed domains under deftsecurity.com, freescanonline.com, thedoccloud.com.
• Orion process making outbound HTTPS beyond known SolarWinds update infrastructure.
• New SAML token signing certificates added to ADFS without a change ticket.
• MFA enrollment from a previously unseen device, especially on privileged accounts.

Lessons that aged well

Four practices that were niche in 2020 are now table stakes for any vendor we assess. First, signed SBOMs with build provenance (in-toto, SLSA) so that the binary's lineage is verifiable, not just its publisher signature. Second, ephemeral build runners that are destroyed after each job, eliminating the persistent attacker foothold SUNSPOT relied on. Third, conditional access policies that treat 'new device + privileged account' as a hard block, not a notification. Fourth, network egress allow-lists for management tooling like Orion, because the SUNBURST DNS beacon would have failed in any environment that did not let an on-prem monitoring server resolve arbitrary external domains.

SUNBURST was not a code-signing failure. It was a build-server trust failure. The signature was correct; the supply chain that produced the binary was not.

The hard question SolarWinds forced every CISO to answer is still the right one to ask in 2024: when our vendor's CI/CD pipeline runs, who can write to it, who can read from it, and how would we know if either of those changed? Most procurement questionnaires still do not ask.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.