What Was SUNBURST? The Backdoor Nobody Committed
The alert was routine. Someone had registered a second phone against an employee's multi-factor authentication account, and the system did what it was built to do, which was notice and send a message.
A member of security staff rang the employee to confirm it. The employee had not registered a second phone.
That phone call, at FireEye in early December 2020, is the reason anyone knows about any of this.
Everyone remembers SolarWinds as a supply chain attack. That is true and almost useless. The specific thing that happened is narrower and considerably worse: nobody put a backdoor into SolarWinds' source code. The source stayed clean the entire time. The backdoor was inserted during compilation, and removed again once the compiler finished.
What was SUNBURST?
SUNBURST was a backdoor that shipped inside SolarWinds.Orion.Core.BusinessLayer.dll, a legitimate component of the SolarWinds Orion Platform, a network monitoring product installed in the middle of very large networks precisely because it needs to see everything.
Trojanized builds went out in Orion versions 2019.4 HF5 through 2020.2.1 HF1, released between March and June 2020. They were distributed through SolarWinds' own update infrastructure and carried a valid SolarWinds code-signing signature.
Microsoft called it Solorigate. FireEye called it SUNBURST, and that name stuck.
The backdoor itself is competent but not exotic. It lives in a class named OrionImprovementBusinessLayer, which is exactly the kind of name that survives a code review because reading it costs more attention than skipping it. It collects information about the host, talks to a command server, and can run further payloads.
None of that is the interesting part.
SUNSPOT: the implant that watched for a compiler
In January 2021, CrowdStrike published an analysis of a second piece of malware found on SolarWinds' build systems. They called it SUNSPOT, and it explains the whole incident.
SUNSPOT sat on a build server and monitored running processes, looking for MsBuild.exe. When it found one, it read that process's command line to work out whether the Orion solution was the thing being built. If it was, SUNSPOT located the source file InventoryManager.cs, replaced it with a version containing SUNBURST, waited for the compiler to consume it, and then wrote the original file back.
The substitution existed on disk only for the duration of a build. A developer pulling the repository afterwards would find nothing. A code review would find nothing. A diff of the repository against itself would find nothing, because nothing in the repository had changed.
The detail that gives away how carefully this was done: SUNSPOT checked that its substituted source actually compiled. If the build threw errors or warnings, it aborted and raised an internal alert, because a failed build is the one thing that would make a developer go and look at the file.
Then the finished DLL went through SolarWinds' normal release process, including signing. The signature was valid. It was supposed to be. Everything about that binary was authentic except its contents.
Why the delay was the clever part
On a freshly infected machine, SUNBURST did nothing at all for twelve to fourteen days.
That single design choice defeats most of how software gets vetted. A sandbox does not wait two weeks. An analyst detonating a suspicious build does not wait two weeks. A network baseline drawn around a deployment window has closed long before the traffic starts.
When it did wake up, it did not connect to a hardcoded address. It generated a subdomain of avsvmcloud.com using a domain generation algorithm seeded partly from the victim's own internal domain name, and resolved it. The DNS response came back as a CNAME pointing at the next stage — which meant the attackers could decide, per victim, from the DNS query alone, whether that organisation was worth escalating.
It also checked its surroundings before doing anything: looking for analysis tooling, security drivers and specific processes, and staying dormant if it found them. And it maintained a blocklist of environments to leave alone entirely.
Put together, the operation had a filter on the front of it. Eighteen thousand organisations installed the thing. The attackers looked at the DNS beacons and picked.
What the 18,000 number actually counts
The figure quoted everywhere is 18,000, and it is worth being precise about what it is.
It comes from SolarWinds' own 8-K filing in December 2020, and it is the company's estimate of how many customers downloaded or installed a trojanized Orion build. It is a distribution number.
It is not a count of compromised organisations. Both FireEye and Microsoft put the number of victims who saw meaningful follow-on activity at fewer than a hundred. Microsoft separately notified roughly forty of its own customers who had been targeted more precisely.
So the honest shape of it is: around eighteen thousand doors quietly unlocked, and something under a hundred actually walked through. The rest were noise the operation could hide inside, which was almost certainly the point — a hundred targeted intrusions attract a hundred investigations, and one poisoned update attracts a patch cycle.
The victims that were named include the US Departments of the Treasury, Commerce, State, Energy and Homeland Security, the National Institutes of Health, and Microsoft itself.
It was not solarwinds123
In February 2021 a congressional hearing produced the detail that everyone remembers: a SolarWinds update server had at some point been protected with the password solarwinds123, set by an intern and found publicly exposed by a researcher in 2019.
It is a genuinely bad password and it was a genuinely real finding. It is also, as far as any public investigation has ever established, not how the attackers got in.
The initial access vector for the SolarWinds intrusion has never been publicly confirmed. SolarWinds' own investigation put forward several possibilities and settled on none. The password story survived because it is short, it is embarrassing, and it lets the reader file the whole thing under carelessness.
It is worth resisting, because the actual finding is much harder to live with. The attackers were inside the build environment for months, and every control downstream of that environment continued to work perfectly. The repository was clean. The review passed. The signature verified. The vendor was real. The update was genuine.
There is no password hygiene policy that catches that.
How it was actually found
No scanner found SUNBURST. No threat intelligence feed found it. No customer found it in nine months of running it.
FireEye found it because of the MFA enrollment alert, which led to the discovery that its own red team tooling had been stolen, which it disclosed on 8 December 2020. Working backwards from that intrusion, its investigators arrived at the Orion DLL, and on 13 December 2020 they published the analysis. SolarWinds filed its 8-K the same day.
Volexity later determined that it had encountered the same actor at a think tank client in 2019 and 2020 without being able to connect the activity to a source.
The thing that broke the case was a security team noticing an anomaly in its own staff directory and picking up a telephone.
Who did it
In April 2021 the US government formally attributed the operation to the SVR, Russia's foreign intelligence service — the group tracked as APT29, Cozy Bear, and in Microsoft's naming Nobelium, later Midnight Blizzard.
The same actor turns up again in January 2024, inside Microsoft's own corporate tenant, having got there through a legacy test account with no multi-factor authentication. That one is EXHIBIT 0007.
The through-line between the two is worth sitting with. Neither operation used a zero-day. One used a build server. The other used a forgotten account. Both worked for months.
What changed afterwards
The policy response was fast and largely about paperwork. Executive Order 14028, in May 2021, pushed software bills of materials into US federal procurement. SLSA, Sigstore and reproducible builds all got significantly more attention and funding than they had the year before.
Reproducible builds are the one that actually addresses this incident. If two independent parties can compile the same source and get byte-identical output, then a build server that quietly edits a file during compilation produces a mismatch that anyone can detect. An SBOM would not have caught SUNBURST, because the component list was correct.
The other consequence was personal. In October 2023 the SEC charged SolarWinds and its Chief Information Security Officer, Tim Brown, with fraud and internal control failures — the first time the agency had brought such charges against an individual security executive over a breach. Most of the case was dismissed in 2024. The effect on how CISOs write things down had already happened.
Further reading
- FireEye / Mandiant — Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims with SUNBURST Backdoor, 13 December 2020. The original disclosure.
- CrowdStrike — SUNSPOT: An Implant in the Build Process, 11 January 2021. The build-server implant, in detail.
- Microsoft Security — Deep dive into the Solorigate second-stage activation, January 2021.
- SolarWinds Form 8-K, filed 14 December 2020, for the 18,000 figure in its original wording.
- CISA Emergency Directive 21-01, 13 December 2020.
EXHIBIT 0016 — SUNBURST
We put it on a shirt. Not a network diagram — a printing press, drawn as an engraving. A clean sheet marked InventoryManager.cs feeds in at the top. A mechanical arm reaches into the frame holding an identical substitute. What comes out of the delivery tray is a stack of finished sheets under an embossed seal.
The callouts are the incident: SOURCE WAS CLEAN, SWAPPED DURING THE BUILD, SIGNED BY SOLARWINDS, DORMANT 12-14 DAYS. Most people will read a nice old press. Anyone who has ever signed a release will read what the arm is doing.
That's the whole idea.