The SolarWinds Attack: How a Software Update Spread Hidden Malware

In December 2020, the cybersecurity firm FireEye revealed that it had been breached, and that the attackers had got in through a trusted software update. The software was Orion, a network monitoring product made by SolarWinds and used by thousands of organisations, including government agencies. What followed was one of the most significant espionage campaigns ever made public, and the word "supply chain" became part of everyday security vocabulary.

How it was discovered

On 8 December 2020, FireEye announced that a sophisticated attacker had stolen its red team tools, the software it used to test clients' defences. While investigating, the company traced the intrusion to a trojanised update of SolarWinds Orion. On 13 December, SolarWinds and FireEye published details. The malicious code was named SUNBURST by FireEye.

How the attack worked

1. Break into the supplier. The attackers gained access to SolarWinds' build environment, the systems used to compile and package software.
2. Insert a backdoor. They added malicious code to the Orion software before it was packaged. Because it was added at that stage, the update was digitally signed by SolarWinds as usual.
3. Distribute through normal updates. Updates released between March and June 2020 contained the backdoor. SolarWinds said that fewer than 18,000 customers had downloaded the affected versions.
4. Stay quiet. The backdoor waited for around two weeks before contacting the attackers, and it was designed to blend in with normal Orion traffic.
5. Choose targets. Only a smaller number of networks were selected for further intrusion, where the attackers moved to other systems and stole credentials and email.

Who was affected

US government bodies that disclosed compromises included the Treasury and Commerce departments and the Department of Homeland Security. Microsoft said that the attackers had viewed some of its source code. In February 2021, a White House official said that nine federal agencies and about 100 private companies had been compromised. The US government attributed the campaign to Russia's foreign intelligence service, the SVR, in April 2021 and imposed sanctions. Russia denied involvement.

A very patient attack

Reports from investigators indicated that the attackers had accessed SolarWinds' systems well before the malicious updates went out, and had run a test in October 2019 by inserting harmless changes. The scale of preparation, the care taken to avoid detection and the focus on selected high-value targets were hallmarks of a well-resourced intelligence operation.

What it changed

The incident led to an executive order on improving cybersecurity in the United States in May 2021, which included requirements for software suppliers to government. It also accelerated interest in software bills of materials, which list the components inside a product, and in build systems that can show where and how software was assembled. For defenders, it showed that the update you trust can also be the threat, and that the right answer is monitoring behaviour, not just signatures.

Supply chains on the web

Websites have their own supply chains. A WordPress site may use dozens of plugins and themes, written by different developers, which update through their own channels. There have been several cases of plugins being sold to new owners who then added malicious code, or of attackers compromising a developer's account to push a bad update. The risk is smaller than in the SolarWinds case, but the mechanism is the same.

Why signatures did not help

Code signing is meant to show that software comes from the vendor and has not been altered after signing. In this case, the attackers got in before signing, so the malicious update carried a valid signature. That is a useful reminder of what signatures can and cannot prove: they show who released a file, not that the file is safe. If the releasing process itself is compromised, the signature is simply a stamp on a bad package.

Defenders did eventually find the campaign because of behaviour that looked wrong, for example FireEye noticing a new device registered to a user's account for two-factor authentication. Small, unusual events led back to the larger story. For your site, this argues for keeping logs and reading alerts, such as notices of new admin users, changed files and logins from unfamiliar locations.

It also argues for limiting what any single tool can do. A monitoring product, a backup plugin or an analytics script should not have the power to do everything on your server. The less each tool is allowed to touch, the less an attacker gains by compromising it.

The practical lesson for site owners

Keep the number of plugins and tools small, choose those with active maintenance and a good record, and remove the ones you no longer use. Install updates promptly, since most are fixes, but keep a backup so you can roll back if an update causes trouble. Watch for unexpected changes to files, new admin users or outgoing connections you cannot explain.

Our WordPress hosting is built around keeping sites manageable and updated, and our security page describes the monitoring and protection layers available. The knowledge base has steps for reviewing admin users and backups.