In March 2020, attackers gained access to the build environment for SolarWinds Orion, a widely deployed network monitoring platform. They injected malicious code into the software’s build process, so that the next routine update, version 2019.4 HF 5, released in March 2020, contained a backdoor. SolarWinds digitally signed the trojanized update. Their customers downloaded and installed it through the normal update mechanism. Approximately 18,000 organizations deployed the compromised build, including the US Treasury, the Department of Homeland Security, the Department of Commerce, FireEye, and Microsoft.
The backdoor went undetected for nine months. It was discovered in December 2020, and only because FireEye, itself a victim, noticed that its proprietary red team tools had been stolen and launched an investigation that eventually traced the intrusion back to the SolarWinds update.
This is the closed-source supply chain attack that the xz backdoor is most often compared to. The comparison is instructive, not because one ecosystem is inherently more vulnerable, but because the detection timelines and response capabilities diverge dramatically when the code is visible versus when it is not.
What SolarWinds Orion does
SolarWinds Orion is an IT monitoring platform used by enterprises and government agencies to monitor network infrastructure, servers, switches, firewalls, and applications. It is the kind of software that has broad network visibility and elevated privileges by design: it needs credentials to poll devices, access to management interfaces, and a central position in the network to aggregate telemetry.
This made Orion an ideal target. Compromising the monitoring platform gives an attacker the same visibility and access that the platform itself has: a map of the network, credentials for managed devices, and a trusted position from which lateral movement looks like normal monitoring traffic.
Orion is closed source, proprietary, and commercially licensed. Customers receive compiled binaries through SolarWinds’ update mechanism. The source code is not available for inspection.
The build pipeline compromise
The attackers did not simply check a malicious DLL into the public Orion codebase and call it a day. Public reporting indicates they compromised the build system and used build-host malware (SUNSPOT) to watch for the Orion build, temporarily replace one source file during compilation, and restore the original afterward. This distinction matters: source review of the main repository alone would not have caught the backdoor, because the build host itself had become part of the attack path.
The build pipeline modification inserted a malicious class into a legitimate Orion DLL: SolarWinds.Orion.Core.BusinessLayer.dll. The class, later named SUNBURST by researchers, was compiled into the DLL alongside thousands of lines of legitimate business logic. It was not a separate standalone payload, not an obviously named component, and not something customers could detect through signature checking alone.
Normal build pipeline:
Source repo → Build server → Compile → Sign → Distribute
(source and binary match)
Compromised build pipeline:
Source repo → Build host malware swaps source during build
→ Compile → Sign → Distribute
(signed binary is backdoored)The trojanized DLL was signed with SolarWinds’ legitimate code-signing certificate. Every verification mechanism, Windows Authenticode, SolarWinds’ own update integrity checks, and customers’ endpoint protection, validated the signature and accepted the binary as genuine.
Insight
The signature verified correctly
This is the same lesson as the xz backdoor: digital signatures prove authorship, not intent. The binary was genuinely built by SolarWinds’ build infrastructure, using SolarWinds’ signing key. It was also backdoored. Both facts are true simultaneously. Signature verification tells you who built the software. It does not tell you whether the build environment was compromised.
SUNBURST: the backdoor
The SUNBURST backdoor was engineered for stealth. Every design decision prioritized avoiding detection over maximizing capability.
Dormancy
After installation, SUNBURST waited approximately two weeks before activating. During this dormancy period, the compromised DLL behaved identically to the legitimate version. This delay ensured that any automated analysis triggered by the update, sandbox detonation, behavioral monitoring during the first days after deployment, would see nothing unusual.
The dormancy was not a fixed timer. SUNBURST checked the system clock and only proceeded if the DLL had been loaded for at least 12-14 days. It also checked for the presence of security tools and analysis environments: if it detected processes associated with security software, forensic tools, or sandboxes, it disabled itself permanently.
// Simplified representation of SUNBURST's anti-analysis checks
private static bool IsAnalysisEnvironment()
{
// Check running processes against a blocklist
// (security tools, forensic utilities, sandbox indicators)
string[] blocklist = GetBlockedProcessNames();
foreach (var proc in Process.GetProcesses())
{
if (blocklist.Contains(proc.ProcessName.ToLower()))
return true;
}
// Check if the machine is domain-joined
// (standalone machines are likely analysis environments)
if (!IsDomainJoined())
return true;
return false;
}DNS-based command and control
SUNBURST’s C2 communication used DNS, specifically, DNS A record queries to the domain avsvmcloud[.]com. The subdomain of each query was an encoded identifier containing information about the victim environment: the Active Directory domain name, a unique machine identifier, and status information.
Query: [encoded-victim-data].appsync-api.eu-west-1.avsvmcloud.com
Response: IP address encoding the attacker's instructionsThe subdomain encoding used a custom scheme that produced strings resembling legitimate CDN or cloud API subdomains. To a network analyst reviewing DNS logs, the queries looked like routine cloud service communication, not like C2 traffic.
The DNS response directed the backdoor to one of several secondary C2 channels (HTTP-based) for receiving commands and exfiltrating data. The DNS stage was a low-bandwidth signaling channel only; the actual command execution happened over HTTPS to attacker-controlled infrastructure that rotated frequently.
sequenceDiagram
participant V as Victim (Orion server)
participant D as DNS (avsvmcloud.com)
participant C2 as HTTP C2 server
V->>D: DNS query: [encoded-id].avsvmcloud.com
D-->>V: IP response (instructions encoded)
Note over V: Decode instructions from IP
alt Instructions: activate
V->>C2: HTTPS beacon to secondary C2
C2-->>V: Commands (recon, lateral movement)
V->>C2: Exfiltrated data
else Instructions: stay dormant
Note over V: Wait and re-query later
endWarning
DNS as a covert channel
DNS-based C2 is effective because DNS traffic is ubiquitous, rarely inspected at the payload level, and often allowed through firewalls that block other outbound protocols. Organizations that do not log and analyze DNS queries, including the full subdomain, have no visibility into this type of communication. If your environment does not retain DNS query logs with full subdomain data, you cannot detect DNS-based C2 retroactively.
Victim selection
Not all 18,000 organizations that installed the trojanized update were actively exploited. SUNBURST’s DNS C2 reported the victim’s environment details to the attackers, who then selectively activated the full backdoor only on high-value targets. The majority of installations received a “stay dormant” response and were never further compromised.
This is a disciplined operational security practice. Activating the full backdoor on every victim would increase the chance of detection. By limiting active exploitation to a small subset, the attackers reduced their footprint and extended the operation’s lifespan.
Public reporting on follow-on exploitation consistently includes targets such as:
- US Department of Treasury
- US Department of Homeland Security
- US Department of Commerce (NTIA)
- US Department of State
- FireEye
- Intel
- Deloitte
- Multiple Fortune 500 companies
Microsoft later said it found evidence of attacker access to some internal systems and source repositories, but no evidence that customer-facing production services were compromised. It is more accurate to treat Microsoft as an organization affected by the broader campaign than as a clean example of the same confirmed post-SUNBURST exploitation set as FireEye or the US agencies.
Post-exploitation
On selected targets, SUNBURST downloaded a second-stage payload called TEARDROP, a memory-only dropper that loaded a customized Cobalt Strike beacon. From there, the attackers used standard post-exploitation techniques: credential theft, lateral movement via RDP and SMB, and data exfiltration. They specifically targeted email systems and internal documents related to security products and government policy.
The attackers’ operational security extended to the post-exploitation phase:
- Mimicked legitimate behavior. Lateral movement used the same protocols and patterns as Orion’s normal monitoring activity.
- Used victim infrastructure for C2. Where possible, the attackers used the victim’s own cloud infrastructure (Azure, AWS) for data staging, making exfiltration traffic blend with legitimate cloud usage.
- Avoided endpoints with EDR. The attackers mapped security tooling before moving laterally and avoided machines with active endpoint detection and response agents.
How it was caught
FireEye’s security team detected unauthorized access to their red team tool repository. During the subsequent investigation, they identified a novel backdoor in their SolarWinds Orion installation. On December 8, 2020, FireEye publicly disclosed that it had been breached by a sophisticated threat actor and released detection signatures for their stolen tools.
On December 13, 2020, FireEye, Microsoft, and SolarWinds jointly disclosed the supply chain compromise. The US government confirmed multiple federal agencies were affected.
The discovery chain:
- Attackers stole FireEye’s red team tools
- FireEye detected the theft through internal monitoring
- The incident response traced the initial access to the Orion update
- Analysis of the trojanized DLL revealed SUNBURST
- Coordinated disclosure to SolarWinds, Microsoft, and CISA
If the attackers had not targeted FireEye, a security company with above-average detection capabilities and a strong motivation to investigate, the compromise could have continued for significantly longer.
Insight
Detection was accidental and organizational
Like the xz backdoor (found because of a 500ms anomaly during unrelated benchmarking), the SolarWinds compromise was found through a chain of events that was not designed to catch it. No automated tool, no compliance audit, and no security framework detected the backdoor during its nine months of operation. The discovery required the attackers to make a mistake (targeting a security company that noticed the theft) and the victim to have the capability and motivation to investigate thoroughly. This is not a repeatable detection strategy.
Detection
Indicators of compromise
# Check for the compromised DLL version
# SolarWinds.Orion.Core.BusinessLayer.dll
# Affected versions: 2019.4 HF 5, 2020.2 RC1, 2020.2 RC2, 2020.2, and 2020.2 HF1
Get-FileHash "C:\Program Files (x86)\SolarWinds\Orion\SolarWinds.Orion.Core.BusinessLayer.dll"
# Known malicious hashes (SHA256):
# 32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77
# dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b
# eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0edDNS indicators
# Search DNS logs for C2 domain
grep -i "avsvmcloud.com" /var/log/dns/*.log
# Look for the encoded subdomain pattern
# Subdomains are base32-like encoded strings, 20-30 charactersWazuh rules
<rule id="100240" level="14">
<decoded_as>dns</decoded_as>
<regex>avsvmcloud\.com</regex>
<description>SUNBURST — SolarWinds backdoor C2 domain detected in DNS</description>
<mitre>
<id>T1071.004</id>
<tactic>Command and Control</tactic>
</mitre>
</rule>
<rule id="100241" level="14">
<decoded_as>syscheck</decoded_as>
<regex>SolarWinds.Orion.Core.BusinessLayer.dll</regex>
<description>SUNBURST — SolarWinds Orion business layer DLL modified</description>
<mitre>
<id>T1195.002</id>
<tactic>Initial Access</tactic>
</mitre>
</rule>
<rule id="100242" level="12">
<decoded_as>windows_eventlog</decoded_as>
<field name="win.system.eventID">^(7045|4697)$</field>
<regex>SolarWinds|Orion</regex>
<description>SUNBURST — Suspicious SolarWinds service installation</description>
</rule>Tip
Retroactive DNS analysis
If your organization used SolarWinds Orion during the affected period (March–December 2020), retroactive analysis of DNS logs for
avsvmcloud.comqueries can determine whether the backdoor was active in your environment. If you do not have DNS logs from that period, you cannot make this determination, which is itself a finding about your logging coverage.
Remediation
Immediate actions
Isolate affected Orion servers. Disconnect SolarWinds Orion instances from the network before performing analysis. The backdoor may still be active and capable of receiving commands.
Upgrade or rebuild. SolarWinds released Orion Platform 2020.2.1 HF 2 to address the compromise. However, given that the build pipeline itself was compromised, many organizations chose to rebuild Orion from scratch on clean infrastructure rather than trust an in-place upgrade.
Reset all credentials accessible to Orion. The Orion platform typically holds credentials for SNMP, WMI, SSH, and API access to every monitored device. Assume all credentials stored in or accessible to Orion are compromised. Rotate them.
Audit for lateral movement. The backdoor was a beachhead, not the final objective. Check for signs of post-exploitation: new service accounts, unexpected RDP sessions, anomalous Azure AD activity, and Cobalt Strike beacon indicators.
Longer-term actions
-
Monitor your supply chain, not just your perimeter. The SolarWinds attack entered through a trusted update channel. Traditional perimeter defenses, firewalls, IDS, email filtering, were irrelevant. Supply chain monitoring requires verifying the integrity of software updates, tracking vendor security posture, and maintaining visibility into what software runs in your environment and where it came from.
-
Implement DNS logging and analysis. SUNBURST’s C2 used DNS. Organizations without DNS query logging had no ability to detect the communication or perform retroactive analysis. Log all DNS queries, retain them, and monitor for anomalous patterns, high-entropy subdomains, queries to newly registered domains, and unusual query volumes.
-
Segment monitoring infrastructure. Network monitoring platforms have broad access by design. Segment them: restrict their network access to what they need, monitor their outbound communications, and treat them as high-value targets for compromise. A monitoring system that can reach every device on the network is the most dangerous thing to compromise.
-
Evaluate vendor build pipeline security. For critical software, ask vendors about their build pipeline security: Is the build environment isolated? Is the build reproducible? Are builds signed by a process that requires multiple parties? Are build artifacts compared against source to detect injection? Most vendors cannot answer these questions today. The ones that can are the ones investing in the problem.
Lessons
Build pipelines are the new target
The attacker did not need to compromise the source code, the developer workstations, or the code review process. They compromised the build system: the infrastructure that turns source into binaries. This is a supply chain attack at the most fundamental level: the source is clean, the binary is poisoned, and the signature says it is legitimate.
Reproducible builds, where anyone can rebuild the software from source and get a byte-identical binary, would have detected this immediately. The compiled DLL would not match a clean build from the source repository. But SolarWinds is closed source, so no customer could perform this verification. They were trusting the binary without the ability to verify it against the source. The open source ecosystem’s push toward reproducible builds is a direct response to this class of attack.
Trusted update channels are attack vectors
Every organization that installed the trojanized update did exactly what security best practices recommend: they kept their software up to date through the vendor’s official channel. The update was signed, it came from the correct server, and it passed every integrity check. The trust model worked exactly as designed, and it delivered a backdoor.
This does not mean you should stop patching. It means you should not treat “vendor-signed update” as a terminal trust decision. Defense in depth still applies: monitor the behavior of updated software, segment systems that receive updates from the network, and maintain the ability to detect anomalous behavior even from trusted software.
Nine months is a long time
The SolarWinds compromise was active from March to December 2020. During those nine months, the attackers had access to some of the most sensitive networks in the US government. The data exfiltrated during that window, emails, documents, security tool source code, policy discussions, represents an intelligence windfall whose full impact may never be publicly known.
Compare this to the xz backdoor, which was active for five weeks before a developer noticed a half-second performance anomaly and traced it to its source. The xz code was open, so anyone could investigate. The SolarWinds code was closed, so only FireEye’s internal investigation (triggered by an unrelated theft) surfaced the compromise.
The argument that closed source software is more secure because its code is hidden from attackers does not survive contact with the evidence. The code being hidden also hid the backdoor, from the 18,000 organizations that needed to know about it.
Vendor security posture is your security posture
If your monitoring platform is compromised, your network is compromised. If your CI/CD provider is compromised, your software is compromised. If your identity provider is compromised, your access controls are compromised.
Every vendor in your supply chain extends your attack surface. Evaluating vendor security is not a checkbox exercise for procurement; it is a continuous assessment of a risk you cannot eliminate, only manage. The SolarWinds attack proved that even large, well-funded vendors with security teams and compliance certifications can have their build infrastructure compromised without detecting it for months.
Trust, but verify. And when the software is closed source, recognize that “verify” has hard limits.