SolarWinds Attack: Anatomy of a Compromised Software Update

The compromised updates distributed a backdoor known as SUNBURST to affected customers. After installation, the attackers selectively targeted organisations for further exploitation, using stealthy techniques to maintain access, gather intelligence, and move deeper into victim environments.

The incident demonstrated that trusted software distribution channels can become attack vectors. Even organisations with established security controls may be exposed when a trusted vendor's software update mechanism is compromised.

1. Introduction: When a Trusted Update Becomes a Threat

Software updates are a fundamental part of cybersecurity. Organisations install updates to patch vulnerabilities, improve functionality, and maintain their systems. Because updates are digitally distributed through trusted vendor channels, security teams often treat them as legitimate.

The SolarWinds incident challenged that assumption.

Attackers compromised the software build and distribution process associated with SolarWinds Orion. Malicious code was inserted into legitimate software updates, which were subsequently distributed to customers. As a result, affected organisations received software that appeared authentic but contained a hidden backdoor.

The initial compromise was particularly dangerous because the malicious code arrived through a trusted software supplier rather than an obviously suspicious download or email attachment.

This was not simply an attack against one organisation. It was a supply chain compromise that created opportunities to access multiple downstream organisations.

2. What Is a Software Supply Chain Attack?

A software supply chain attack occurs when adversaries compromise a component, development process, distribution channel, or service that other organisations trust.

Instead of attacking every intended victim independently, attackers target a shared dependency.

Common attack paths include:

• Compromising a software developer's build environment.

• Injecting malicious code into source code or compiled binaries.

• Abusing software signing or update-distribution mechanisms.

• Compromising third-party libraries or development tools.

• Exploiting trusted access provided by a vendor or service provider.

In the SolarWinds incident, attackers compromised the software development and update process so that malicious code was included in legitimate Orion updates.

The key security failure was not that customers downloaded an obviously malicious program. The updates came through a trusted channel, making conventional perimeter-based detection more difficult.

3. Anatomy of the SolarWinds Attack

The attack involved several stages, from compromising the software supply chain to conducting selective follow-on operations.

Stage 1 — Compromising the software build process

The attackers gained access to SolarWinds' development environment and manipulated the process used to build Orion software.

Malicious code was incorporated into legitimate software builds. The resulting software packages were distributed through SolarWinds' normal update infrastructure.

This allowed the attackers to exploit the trust customers placed in the vendor and its update process.

Stage 2 — Distributing the compromised update

Affected customers downloaded and installed Orion updates containing the malicious component.

The malicious code associated with this campaign became known as SUNBURST. It was embedded in a legitimate Orion software component, enabling the initial compromise to blend into expected software activity.

Because the software originated from a recognised vendor, basic reputation checks alone were insufficient to identify the threat.

Stage 3 — Establishing a covert backdoor

Following installation, SUNBURST used delayed and selective execution behaviours to reduce the likelihood of immediate detection.

The malware included checks and delays before conducting further activity. It also used communications designed to blend with legitimate network traffic.

These behaviours complicated detection because the affected software was already expected to communicate with other systems as part of its normal monitoring role.

Stage 4 — Selecting victims for further exploitation

The attackers did not necessarily pursue every system that received a compromised update in the same way.

After the initial backdoor became active, selected victims experienced additional activity. This could include the deployment of further tools, credential-related operations, reconnaissance, and attempts to access sensitive systems.

This distinction is essential: receiving the compromised update, executing SUNBURST, and experiencing deeper intrusion are different stages of the incident.

Security teams should not assume that all three occurred at every affected organisation.

Stage 5 — Expanding access and gathering intelligence

In selected environments, the attackers sought to expand their access and reach valuable information.

Depending on the victim and the observed intrusion, follow-on activity included identity and credential abuse, movement between systems, and access to cloud or enterprise resources.

The attackers used techniques intended to avoid detection, including the abuse of legitimate administrative tools and trusted relationships.

Stage 6 — Maintaining stealth and evading detection

The campaign demonstrated how attackers can use legitimate software, valid accounts, and ordinary administrative operations to conceal malicious activity.

Traditional detections that focus exclusively on known malware files or suspicious executable names may miss this kind of intrusion.

Effective investigation requires understanding the context in which a process runs, which account initiated it, what it communicates with, and whether the activity matches expected behaviour.

4. SUNBURST: The Malware Behind the Compromised Updates

SUNBURST was the backdoor associated with the compromised SolarWinds Orion software updates.

Its behaviour made the incident particularly challenging for defenders.

Delayed execution

The malware did not necessarily begin its malicious activity immediately after installation. Delays and environmental checks reduced the likelihood that routine testing would expose it quickly.

Selective behaviour

The malware incorporated checks intended to avoid certain environments and reduce the risk of analysis or detection. This helped it remain inactive or behave differently under some conditions.

Covert command-and-control communications

SUNBURST communicated with attacker-controlled infrastructure using techniques intended to resemble legitimate network activity.

Investigators therefore needed to assess more than whether a connection occurred. They also needed to determine whether the destination, timing, process, DNS behaviour, and surrounding events were consistent with the organisation's normal operations.

Follow-on payloads

The initial backdoor provided an entry point for further operations against selected victims. Additional tooling and activity varied across affected environments.

Defensive takeaway: Detecting the initial backdoor is important, but it is not enough. Incident responders must also investigate potential persistence, credential abuse, lateral movement, and access to sensitive resources.

5. Why Traditional Security Controls Struggled

Several characteristics of the incident made detection difficult.

ChallengeWhy it matteredTrusted software distributionThe malicious code arrived through a legitimate update channel.Legitimate vendor softwareThe affected application was expected to run on customer systems.Delayed executionImmediate post-installation checks might not reveal the malicious behaviour.Selective targetingNot every affected installation followed the same intrusion path.Trusted administrative activityFollow-on actions could resemble normal enterprise operations.Covert network communicationsMalicious traffic could blend into expected application activity.Multiple downstream victimsOne upstream compromise created exposure across many organisations.

The lesson is not that software updates should be avoided. Updates remain essential for security. Instead, organisations need controls that assess software provenance, monitor behaviour after deployment, and identify unusual activity originating from trusted applications.

6. SOC Investigation: How to Investigate a Suspected Supply Chain Compromise

A SOC analyst investigating a suspected SolarWinds-related intrusion should establish the affected software scope, correlate endpoint and network telemetry, and determine whether there is evidence of follow-on compromise.

Step 1 — Identify affected Orion installations

Inventory SolarWinds Orion deployments, installed versions, update history, and the systems on which the software ran.

Determine whether the environment contains a version associated with the affected update campaign. Use vendor advisories, internal software inventory, endpoint telemetry, and historical deployment records.

Do not assume that every Orion installation or every software version was affected.

Step 2 — Review process execution

Examine process creation and execution telemetry associated with Orion services and related components.

Investigate:

• Unexpected child processes spawned by Orion services.

• Unusual execution of PowerShell or other scripting tools.

• Administrative tools launched from unexpected parent processes.

• Processes accessing sensitive files or credential-related resources.

• Changes in execution patterns around the time of a suspicious update.

Windows Security Event ID 4688 can record process creation when the appropriate auditing is enabled. EDR telemetry may provide richer process lineage, command-line information, and network connections.

An unusual child process is a lead for investigation, not proof of SUNBURST activity.

Step 3 — Analyse network and DNS activity

Review DNS, proxy, firewall, and endpoint network telemetry for unusual communications originating from Orion servers.

Assess:

• Newly observed or suspicious external destinations.

• DNS queries inconsistent with normal application behaviour.

• Unexpected outbound traffic from monitoring infrastructure.

• Connections occurring after software updates or unusual process execution.

• Communications between Orion servers and sensitive internal systems that lack a clear operational purpose.

Compare findings against historical baselines and approved vendor destinations. Use campaign-specific indicators from trusted threat-intelligence sources when investigating the historical SolarWinds campaign.

Step 4 — Investigate identity and credential activity

Determine whether the affected server had access to privileged accounts, service credentials, or administrative management interfaces.

Review successful and failed logons, account use from unusual hosts, unexpected authentication relationships, and suspicious access to cloud resources.

Relevant Windows Security events may include:

• 4624: Successful logon.

• 4625: Failed logon.

• 4648: Logon attempted using explicit credentials.

• 4672: Special privileges assigned to a new logon.

These events must be correlated with the account, logon type, source system, target system, and other available telemetry. They do not independently confirm credential theft or lateral movement.

Step 5 — Examine persistence and lateral movement

Look for unauthorised scheduled tasks, services, startup mechanisms, account changes, and remote execution activity.

Establish whether the Orion server communicated with domain controllers, identity systems, administrative workstations, or other sensitive assets in ways that differed from its normal role.

Correlate endpoint activity with authentication logs and network flows to reconstruct the sequence of events.

Step 6 — Assess cloud and enterprise access

If the affected organisation uses cloud identity or SaaS platforms, investigate relevant sign-in records, audit logs, privileged application activity, and access to sensitive resources.

The scope should reflect the actual environment and available evidence. Do not assume that a compromised Orion server automatically resulted in cloud compromise.

Step 7 — Determine scope and respond

Classify systems according to the evidence collected:

1. Systems that received an affected update.

2. Systems where suspicious backdoor execution is supported by evidence.

3. Systems with evidence of follow-on malicious activity.

4. Systems where the investigation found no evidence of compromise, while acknowledging any visibility gaps.

Preserve relevant logs and forensic evidence before making changes that could destroy investigative artefacts. Follow the organisation's incident-response procedures for containment, eradication, credential rotation, and recovery.

Where compromise is confirmed, removing the affected software alone may not eliminate attacker access established through subsequent activity.

7. Evidence and Indicators to Collect

The SolarWinds incident is a historical campaign, so investigations should use campaign-specific indicators from authoritative threat-intelligence and vendor sources rather than relying on generic indicators.

Evidence sourceWhat to collectInvestigative purposeSoftware inventoryOrion versions, installation records, update historyEstablishes exposure to affected softwareEDR telemetryProcess trees, file activity, persistence changesIdentifies suspicious execution and follow-on activityDNS logsQuery history, resolved domains, timestampsHelps identify suspicious command-and-control behaviourFirewall and proxy logsDestination IPs, domains, connection timing, byte countsReconstructs outbound communicationsWindows Security logsLogon and process-creation eventsSupports authentication and execution timelinesIdentity audit logsAccount activity, role changes, privileged accessIdentifies possible identity compromiseCloud audit logsSign-ins and sensitive administrative operationsAssesses potential cloud impactForensic artefactsRelevant binaries, hashes, timestamps, system artefactsSupports validation and evidence preservation

A useful investigation timeline should correlate update installation, process execution, DNS activity, authentication events, and any suspicious administrative actions.

8. MITRE ATT&CK Mapping

The following techniques may be relevant when supported by evidence from a SolarWinds-style supply chain intrusion. The mapping should reflect observed behaviour rather than assuming every technique occurred in every victim environment.

• T1195.002 — Compromise Software Supply Chain: Relevant to the compromise of a software build or distribution process.

• T1071.001 — Web Protocols: Potentially relevant where command-and-control communications use web protocols.

• T1059 — Command and Scripting Interpreter: Relevant if malicious activity uses command or scripting interpreters.

• T1078 — Valid Accounts: Relevant when attackers abuse legitimate accounts to access systems or resources.

• T1021 — Remote Services: Relevant when evidence shows movement through remote services.

• T1562.001 — Disable or Modify Tools: Relevant only where evidence demonstrates that security tools or controls were disabled or modified.

These mappings describe potential behaviours, not a claim that every technique was used in every affected environment.

9. Defending Against Software Supply Chain Attacks

Verify software provenance

Maintain an inventory of software suppliers, components, versions, and update channels. Validate signatures and hashes where appropriate, while recognising that a valid signature alone does not guarantee that software is benign.

Secure build and release environments

Software vendors should protect build systems, signing keys, source repositories, and release pipelines with strong access controls, separation of duties, monitoring, and auditable release procedures.

Customers should evaluate supplier security practices and the availability of trustworthy security advisories.

Monitor trusted applications

Do not automatically trust a process simply because it belongs to a known vendor. Monitor unexpected child processes, unusual network destinations, abnormal privilege use, and deviations from normal behaviour.

Apply least privilege

Monitoring servers should not have unnecessary administrative access to domain controllers, identity systems, or unrelated enterprise assets. Separate service accounts and restrict their permissions to the minimum required.

Segment critical infrastructure

Restrict communication between monitoring platforms, management networks, identity infrastructure, and sensitive workloads. Segmentation can limit the impact of a compromised management server.

Centralise and preserve logs

Forward relevant endpoint, network, identity, and cloud audit logs to independently managed systems. Retain enough historical telemetry to support investigations that begin long after the initial compromise.

Prepare for vendor compromise

Develop response procedures for compromised software updates, including asset identification, version validation, isolation, forensic collection, credential review, and recovery from a trusted state.

Organisations should also test whether they can identify every system that depends on a critical third-party application.

10. Key Lessons from the SolarWinds Incident

The incident highlighted several enduring security principles:

• Trust must be continuously evaluated. A trusted supplier can become a route into multiple customer environments.

• Software integrity is not the same as software safety. A valid signature establishes aspects of provenance and integrity, not the absence of malicious behaviour.

• Detection must extend beyond the perimeter. Endpoint, identity, network, and cloud telemetry are needed to identify follow-on activity.

• Exposure and compromise are different. Installing an affected update does not, by itself, prove that an attacker established access or reached sensitive data.

• Incident response must address persistence and identity. Removing the original entry point may not remove access established later.

Conclusion

The SolarWinds attack demonstrated how compromising a trusted software supply chain can create a path into many organisations at once. By inserting SUNBURST into legitimate Orion updates, the attackers exploited customer trust and made the initial compromise difficult to distinguish from normal software activity.

For defenders, the response requires more than checking software versions or scanning for known malware. Effective protection combines software provenance, secure development practices, least privilege, network segmentation, behavioural monitoring, and detailed investigation across endpoint, identity, network, and cloud systems.

The central lesson is clear: trusted software must still be monitored, and a suspected supply chain compromise must be investigated for what happened after installation—not just for how the software arrived.

Further Reading

• CISA — Emergency Directive 21-01: Mitigate SolarWinds Orion Code Compromise

• CISA — AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations

• MITRE ATT&CK — Compromise Software Supply Chain (T1195.002)

• Microsoft Security — Solorigate: Analyzing the attacks