SolarWinds exposed the risk in trusted software updates
SolarWinds showed how a legitimate software update could carry an intrusion into network administration systems. Recovery required customers to investigate the access an attacker might retain beyond the compromised component.
A software signature helps a customer establish whether an update came from the expected publisher. In the SolarWinds incident, a signed update contained malicious code. On 13 December 2020, FireEye described a backdoor in a digitally signed component of SolarWinds Orion, software used for IT monitoring and management. Attackers had reached victims through updates to a product those organisations already trusted.
Investigators needed to establish whether affected software was present, whether an attacker had used it and what access might remain elsewhere. Removing a component could close one route into the network while leaving compromised accounts or other persistence behind. Enterprise software suppliers faced questions about the security of their releases and their customers' ability to recover.
The update carried the first compromise
FireEye called the trojanised component SUNBURST. Its initial report said malicious updates had been digitally signed between March and May 2020 and distributed through the SolarWinds update website. The backdoor could remain dormant for up to two weeks before communicating with external infrastructure. Its commands included transferring and executing files, profiling the system and disabling services. It also tried to make its traffic resemble legitimate Orion activity.
- March–May 2020
Signed updates distributed
FireEye's initial report identified trojanised updates digitally signed during this period.
- 13 December 2020
SUNBURST disclosed
FireEye described the backdoor and observed activity after the initial compromise.
- 13 December 2020
Federal isolation ordered
CISA issued Emergency Directive 21-01 for affected federal civilian executive branch systems.
The signing window is reported in FireEye's initial analysis; it is not a claim that every customer was intruded upon throughout that period.
The malicious component arrived through the expected product channel and ran within a legitimate application. Delayed activity and imitation of normal traffic made it harder to observe. Code signing and patching remained important, but neither could fully protect a customer when the release process itself had been compromised.
Isolation came before a routine reinstall
CISA issued Emergency Directive 21-01 on the same day. Its original instructions required affected federal civilian executive branch agencies to disconnect or power down specified Orion versions. Agencies with the necessary expertise were first to capture forensic images and examine relevant evidence. CISA also instructed agencies to wait for further direction before reinstalling forthcoming software patches and reconnecting the host operating system to the enterprise domain.
The directive addressed an urgent federal risk under specific statutory authority. It did not legally bind every private business, and its guidance evolved as the investigation developed. Agencies had to preserve evidence and reduce attacker access while their administrative tool was unavailable. Disabling it could remove useful monitoring just when they most needed visibility.
The investigation had more than one boundary
FireEye reported lateral movement and data theft after the initial compromise, including the use of legitimate credentials and remote access to limit the malware footprint. Investigators therefore had to distinguish exposure from attacker activity. An affected version required investigation but did not, by itself, establish that a particular record had been stolen. Replacing that version could not establish that all attacker access had disappeared.
Scroll to view all columns
| Comparison | Finding | Evidence still needed |
|---|---|---|
| Exposure | An affected update was installed | Whether the attacker communicated with or acted inside this environment |
| Intrusion | Evidence shows attacker activity | Which accounts, systems and information were reached |
| Remediation | The original entry point was removed | Whether other access and persistence were eradicated |
An investigative distinction based on the backdoor, lateral movement and recovery issues described in the initial FireEye report and CISA directive.
Recovery extended to identities, privileges and other systems reached after initial access. An inventory of affected software helped establish exposure but could not resolve the customer's whole problem. Detection vendors also needed to explain their evidence, gaps in telemetry and the assumptions behind a clean result. Confidence depended on the coverage of the investigation, not the number of alerts closed.
Release security became part of the customer relationship
For an infrastructure startup, the supply chain includes the path from source code to the binary delivered to a customer. Access to build systems, release approvals and signing credentials all affect what customers execute under the supplier's name. SolarWinds gave vendors reason to scrutinise those controls, though the incident did not establish that any single development practice would have prevented the campaign.
Diligence also needed to examine how a vendor identified affected versions and informed customers when confidence in a release changed. It had to distinguish deployments accurately, preserve relevant build records and issue instructions an administrator could follow under pressure. These capabilities required investment before an incident. During recovery, they helped the supplier explain which releases could be trusted and limit customer disruption.
Recovery was a product requirement
Administrative tools often accumulate broad privileges because that makes them useful. Restricting those privileges can complicate deployment, but unrestricted access can enlarge the consequences of compromise. Founders therefore need to treat least privilege, separable service accounts and an emergency isolation path as design questions. A customer should be able to understand what stops working when the tool is disconnected and how to recover essential functions.
A highly publicised attack can attract attention to security vendors without demonstrating that their products help an exhausted response team. Customers need evidence they can act on and support for a safe return to operation. SolarWinds made those demands apply to trusted software suppliers as well as to the defences installed around them.
Investment implications
- A valid signature establishes an important origin check; it cannot establish that the signed program is benign.
- Exposure to a compromised update, attacker activity and the scope of recovery are separate findings.
- Administrative software needs a credible isolation and recovery plan because its privileges can extend the incident beyond its own host.
Sources
- Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor (opens in a new tab)
FireEye, now hosted by Google Cloud Threat Intelligence
- Emergency Directive 21-01: Mitigate SolarWinds Orion Code Compromise (opens in a new tab)
Cybersecurity and Infrastructure Security Agency
Published
