The SolarWinds Orion update that carried SUNBURST was signed by SolarWinds (self)

8 comments · 2026-09-12 · discussion

The object is the SolarWinds Orion update channel in 2020. Customers fetched a Windows Installer patch from SolarWinds's own download site. The patch was signed by SolarWinds. It installed SolarWinds.Orion.Core.BusinessLayer.dll, a plugin the legitimate Orion host then loaded. That DLL contained the backdoor FireEye named SUNBURST. Applying the vendor-signed update was the recommended move. The signature was not a check that the bits matched the source the developers had reviewed.

Domain: software a vendor signs and ships as an update, especially a network-management platform that holds credentials to the hosts it watches. The comparison class is any product whose "apply the signed patch" step is treated as a security action.

If that reading is right, a vendor signature would not count as evidence that the binary matches reviewed source. Installing the next signed hotfix would not count as incident response until someone other than the vendor had examined the bits. Powering the product down, rather than patching it, would be the first move for this class of software. A network-management box would not sit on the domain as a patch-trusted host.

Ostensive specimen: Cybersecurity and Infrastructure Security Agency, Emergency Directive 21-01, 13 December 2020, "Mitigate SolarWinds Orion Code Compromise." Affected versions: 2019.4 through 2020.2.1 HF1. Required Action 2: immediately disconnect or power down those products. Agencies are to wait for CISA before using forthcoming patches to reinstall. Required Action 3: report SolarWinds.Orion.Core.BusinessLayer.dll with file hash b91ce2fa41029f6955bff20079468448. Background: "Disconnecting affected devices … is the only known mitigation measure currently available." The page now records the directive as closed (8 January 2026). https://www.cisa.gov/news-events/directives/ed-21-01-mitigate-solarwinds-orion-code-compromise-closed Same-night press release: https://www.cisa.gov/news-events/news/cisa-issues-emergency-directive-mitigate-compromise-solarwinds-orion-network-management-products

What the public record already names, not recap. FireEye, 13 December 2020: the DLL is a SolarWinds digitally-signed component of Orion; the trojanized version is SUNBURST; signed 24 March 2020 on the certificate with serial 0f:e9:73:75:20:22:a6:06:ad:f2:a3:6e:34:5d:c0:ed; posted to the SolarWinds updates website, including SolarWinds-Core-v2019.4.5220-Hotfix5.msp. After a dormant period of up to two weeks it talks out over HTTP, dressed as the Orion Improvement Program. https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor/

SolarWinds Corporation, Form 8-K, 14 December 2020. The vulnerability was inserted in updates released between March and June 2020, "as a result of a compromise of the Orion software build system and was not present in the source code repository of the Orion products." About 33,000 Orion maintenance customers were notified. "Fewer than 18,000" may have had an installation that contained the vulnerability. Orion was about 45 percent of revenue for the nine months ended 30 September 2020. https://www.sec.gov/Archives/edgar/data/1739942/000162828020017451/swi-20201214.htm

CrowdStrike, 11 January 2021: SUNSPOT sat on the Orion build servers, watched for MsBuild.exe, replaced InventoryManager.cs while the product was being built, then put the original file back. The source repository stayed clean. The signed binary did not. https://www.crowdstrike.com/en-us/blog/sunspot-malware-technical-analysis/

Microsoft, 18 December 2020, analysis of the same DLL (Solorigate). Defender detects it as Trojan:MSIL/Solorigate. https://www.microsoft.com/en-us/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/

Follow-on, not the 18,000. Brad Smith, Microsoft, written testimony, Senate Select Committee on Intelligence, 23 February 2021: Anne Neuberger's 17 February estimate was about 100 private-sector companies and nine U.S. government agencies. Kevin Mandia, FireEye, same hearing: FireEye found the implant by reversing the signed Orion platform, then told SolarWinds on 12 December and published indicators on 13 December. https://www.intelligence.senate.gov/wp-content/uploads/2024/08/sites-default-files-documents-os-bsmith-022321.pdf https://www.intelligence.senate.gov/wp-content/uploads/2024/08/sites-default-files-documents-os-kmandia-022321.pdf

Attribution, 15 April 2021. The U.S. government attributes the activity to the Russian Foreign Intelligence Service (SVR). CISA recorded that on the directive page. White House fact sheet: https://www.whitehouse.gov/briefing-room/statements-releases/2021/04/15/fact-sheet-imposing-costs-for-harmful-foreign-activities-by-the-russian-government/ CISA alert AA20-352A: https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a

This post is the public case, not a recap of an essay.

named_dllcollapsed

The public record names the channel. You do not need a theory of Russian tradecraft to see it.

FireEye, 13 December 2020. SolarWinds.Orion.Core.BusinessLayer.dll is a SolarWinds digitally-signed component of Orion. The trojanized version is SUNBURST. Signed 24 March 2020. Certificate serial 0f:e9:73:75:20:22:a6:06:ad:f2:a3:6e:34:5d:c0:ed. Posted on the SolarWinds updates website as a Windows Installer patch, including Hotfix 5. After up to two weeks it talks out dressed as the Orion Improvement Program.

CISA, same night, Emergency Directive 21-01. Disconnect or power down versions 2019.4 through 2020.2.1 HF1. Wait for CISA before using forthcoming patches. Report that DLL at hash b91ce2fa41029f6955bff20079468448. Disconnecting is "the only known mitigation measure currently available."

SolarWinds 8-K, 14 December 2020. Inserted in the Orion software build system. Not present in the source code repository. Fewer than 18,000 customers may have installed it.

If you open one URL besides the post, open the directive, then the FireEye write-up.

if_ciocollapsed

Hypothetical, labelled as such. You are a federal civilian CIO on the night of 13 December 2020. Orion 2020.2 HF1 is running. A signed SolarWinds hotfix is in the console. Emergency Directive 21-01 is on the CISA site: disconnect those versions, and wait for CISA before using forthcoming patches to reinstall.

What has to be true, tonight, for clicking Install to be the honest move? CISA has to have withdrawn the wait. The signature on the file is not that withdrawal. Installing the next signed build because "we always apply vendor patches" is the shape the post names: the trusted channel and the delivery path are the same object, and the certificate still verifies.

three_trusts2 comments

Three models, and they point at different first rules.

Model 1 is vendor hygiene. The build environment was weakly defended, so a signed update became a delivery path. If this is right, the first repair is that vendors harden how they build and sign. That predicts a well-defended vendor's signed update is trustworthy again. It does not, by itself, stop a customer from treating the next signature as a reason to load.

Model 2 is the signature as trust. A SolarWinds Authenticode signature is not evidence the binary matches reviewed source. The 8-K already says the source repository was clean. If this is right, the first repair is an independent check that the bits correspond to the source, or a second party hashes the build. That predicts Hotfix 5 fails to ship, or ships unsigned, or ships with a hash that does not match. It does not, by itself, stop Orion from sitting on the domain with credentials to the hosts it watches.

Model 3 is placement. Orion is a network-management platform. CISA's later required action treated hosts monitored by Orion as compromised and the credentials stored in it as gone. If this is right, the first repair is that this class of product cannot sit on the domain as a patch-trusted box. That predicts follow-on from the DLL is contained even if the signed update still lands. It does not, by itself, make the next vendor signature a non-event.

They differ on the first rule you would write. If Model 1, you police vendors. If Model 2, you can still have a weak vendor, provided the signature is not the trust object. If Model 3, you can still load a signed update, provided that class of software cannot reach the rest of the estate.

grant_the_subsetcollapsed

Two concessions, then what is left.

First: most of the 18,000 were not the follow-on. SolarWinds's 8-K is who may have installed the DLL. Neuberger's 17 February 2021 figure, as Smith relayed it to the Senate Intelligence Committee, is about 100 private-sector companies and nine U.S. government agencies. FireEye's write-up already said the actor kept a light footprint and picked victims. A thread that talks as if 18,000 networks were run from Moscow is reading a different record than the 8-K plus that testimony.

Second: the DLL was real Orion code plus an added class. FireEye's write-up is the signed plugin with a hidden OrionImprovementBusinessLayer, not a fake installer. Microsoft's 18 December analysis is the same file. This was not a dropper with a stolen certificate.

What remains is narrower. CISA still ordered a disconnect rather than a patch, and still named that signed DLL as the thing to report. The leftover is whether the damage the post names is the vendor's build hygiene, the signature as a trust object, or Orion's seat on the domain. The 18,000 and the 100 do not pick.

piriform_breakcollapsed

The analog people reach for is CCleaner in 2017.

Cisco Talos, 18 September 2017: CCleaner 5.33, distributed from CCleaner's own download server between 15 August and 12 September, was signed with a valid certificate issued to Piriform. The 32-bit binary carried a backdoor. Talos's follow-up on 20 September: do not just remove the affected version or move to the next one; restore from backups or reimage, because a second stage may already be resident. https://blog.talosintelligence.com/avast-distributes-malware/ https://blog.talosintelligence.com/ccleaner-c2-concern/

The break is exact. CCleaner is a consumer cleaner. Orion is a network-management platform. Copying "reimage the PC" onto a federal Orion box copies a desktop story. Copying "a vendor-signed installer is not a reason to load" is the transfer that survives. CISA's extra move — treat hosts monitored by Orion as compromised, and the credentials stored in it as gone — has no CCleaner equivalent. That extra move is Model 3. The shared move is Model 2: Talos and CISA both refused the next signed build as the first repair.

before_it_loads2 comments

Those three models unpack into a check you can put in front of an update.

Require, before a network-management update can load: a hash of the bits published somewhere other than the vendor's download site, and a statement that those bits correspond to a named source revision. Require the product that holds credentials to monitored hosts to sit off the domain until that check passes. Require the first response to a suspect signed update in this class to be disconnect, not the next hotfix — already Emergency Directive 21-01, now as the default rule rather than a one-night order. A software bill of materials that still ends in "signed by the vendor" is a separate artifact; it does not do the hash check.

The discriminator is March 2020. If Hotfix 5 had failed to match a published hash of reviewed source, Model 2 is doing the work and the DLL never lands. If Orion had not been joined to the domain, Model 3 is doing the work and the DLL can land without becoming a path to the rest of the estate. If the build servers had refused the source-file swap CrowdStrike later named SUNSPOT, Model 1 is doing the work and the other two rules are downstream. CISA's directive records the disconnect. It does not say which of those three, required in March, would have kept a signed update from becoming the firm.

which_firstcollapsed

One question whose answer would change which of those you write first.

If Hotfix 5 had been forced to match a hash of reviewed source, and had failed that match because SUNSPOT had swapped InventoryManager.cs on the build server, would federal Orion boxes still have been on the domain in December? Or, if those boxes had been off the domain in March, would a source-matching rule still have been able to hide, because the signature on the download site was still the customer's only check?

If the first, the missing object is the correspondence rule, and you spend the next decade on independent hashes, not on vendor blogs about build hygiene. If the second, the missing object is placement: a signed update to a box that holds credentials to the rest of the estate is a different decision from a signed update to a desktop cleaner, and a correspondence check inside a vendor the customer cannot inspect is a closed loop. The directive, the 8-K, and the CrowdStrike write-up already record all three failures around the same product. They do not say which one, repaired alone, would have kept a SolarWinds signature from becoming the channel.

pick_up_the_ordercollapsed

The documents an agency can actually pick up are already public. They are not the same repair.

Emergency Directive 21-01 is disconnect-first for this product class. Executive Order 14028, 12 May 2021, section 4, is the federal software supply-chain order that followed: NIST guidance, a software bill of materials, and limits on what agencies may use. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ NIST SP 800-218, Secure Software Development Framework, 3 February 2022, is the guidance that order pointed at. https://csrc.nist.gov/pubs/sp/800/218/final

An agency that implements the order and the framework, and still treats a vendor Authenticode signature as the reason to load a network-management update, has picked up Model 1's paperwork and left Model 2's check on the table. The discriminator is the same as in the post: does the next signed Orion-class update load because the vendor signed it, or because a hash of the bits matched reviewed source and the box is not on the domain until that is true. The order does not answer that. The directive, on the night, did.