The SolarWinds SUNBURST Attack (2020)
SolarWinds produced Orion, an IT infrastructure monitoring platform used by thousands of organizations including US government agencies. In 2020, attackers compromised SolarWinds' build system and inserted a backdoor — SUNBURST — into a legitimate Orion software update. The update was signed with SolarWinds' valid certificate and distributed through official channels.
How the Attack Unfolded
Attackers gained access to SolarWinds' software build environment. They inserted SUNBURST backdoor code into the Orion source in a way that would be compiled into the next update.
The update was compiled normally, including the SUNBURST code. It was signed with SolarWinds' valid code-signing certificate. Nothing in the signing process indicated a problem.
The update was distributed through SolarWinds' normal infrastructure to approximately 18,000 organizations, who installed it following security best practice.
After installation, SUNBURST lay dormant for up to two weeks, performing no suspicious activity — evading sandbox analysis tools that run samples for only a few minutes.
After dormancy, SUNBURST established a covert C2 channel, disguising traffic as legitimate Orion API calls. Attackers used this for lateral movement, data exfiltration, and persistent access.
The compromise was discovered months later through behavioral anomalies in network traffic — not through signature-based or integrity-based detection. Attackers had maintained access for months.
Dependency Confusion — Step-by-Step
A developer's workstation or build server installs a malicious package automatically — with no warning, no phishing, and no credential theft required.
The attacker searches job postings, GitHub repositories, and leaked configuration files for internal package names. They find a reference to an internal package named "corp-auth-utils" in a job listing.
The attacker creates a malicious "corp-auth-utils" package and uploads it to the public npm registry (or PyPI, NuGet) at version 9.9.9 — far higher than any realistic internal version.
A developer runs npm install. The package manager searches both the private internal registry (finds corp-auth-utils v1.4) and the public npm registry (finds corp-auth-utils v9.9.9).
The package manager selects v9.9.9 from the public registry — the highest available version. It downloads and installs the attacker's package automatically, with no warning or prompt.
The malicious package's install script runs automatically during installation, exfiltrating environment variables, SSH keys, or cloud credentials — all within the developer's environment.
Exam Scenarios
Scenario 1
Question: A security team discovers that an attacker gained persistent access to multiple organizations by compromising a software vendor's build system and inserting a backdoor into a legitimate update. The update was signed with the vendor's valid certificate and distributed through official channels. What type of attack is this, and why was it difficult to detect?
Answer: Supply chain attack / malicious update. Difficult to detect because: (1) the package had a valid code signature — verification passed; (2) it was delivered through official channels — no network anomalies during download; (3) the payload was dormant — sandbox analysis showed no suspicious behaviour. Only behavioral monitoring of post-installation activity could detect it.
Scenario 2
Question: A developer's build system begins exfiltrating credentials shortly after a dependency update. Investigation reveals the build system downloaded a package from a public registry that shares its name with an internal private package but has a higher version number. What attack is this, and what should the organization configure to prevent it?
Answer: Dependency confusion. Prevention: configure the package manager to prefer the private registry exclusively for internal package names (registry scoping). Alternatively, use namespaced package names that cannot be claimed on public registries, or pre-register internal package names on public registries with benign placeholder packages.
Scenario 3
Question: An organization uses hash verification for all software updates before installation. A malicious update is nonetheless installed successfully. The update's hash matches the vendor's published value. How is this possible?
Answer: The malicious code was inserted before the vendor computed and published the hash — specifically in the build pipeline, upstream of both signing and hashing. Hash verification detects modifications after publication; it cannot detect malicious code present when the hash was calculated. The vendor's reference hash matches the malicious package because the package was malicious when hashed.