Inside the SolarWinds SUNBURST Backdoor: A Technical Breakdown of the Most Creative Malware Ever Built

Three Malware Families, One Operation

In December 2020, FireEye discovered that their own network had been compromised — not through a phishing email or a zero-day exploit, but through a routine software update from SolarWinds Orion, one of the most widely deployed IT monitoring platforms in the world. The investigation that followed uncovered the most sophisticated supply chain attack ever documented, attributed with high confidence to Russia’s SVR foreign intelligence service (tracked as APT29, Cozy Bear, Nobelium, and now Midnight Blizzard).

The operation used three distinct malware families working in sequence. SUNSPOT was the build server implant that injected malicious code during compilation. SUNBURST was the backdoor distributed to approximately 18,000 organisations via the trojanised update. TEARDROP and RAINDROP were memory-only second-stage payloads deployed only to the roughly 100 high-value targets the attackers chose to exploit further — including the US Treasury, the Department of Homeland Security, the Pentagon, and Microsoft itself.

SUNSPOT: Hijacking the Compiler

The first piece of the puzzle was SUNSPOT — deployed to SolarWinds’ build server as taskhostsvc.exe, disguised as a legitimate Windows service. Its job was to monitor running MsBuild.exe processes and detect when the Orion solution was being compiled. At the exact moment the compiler reached a specific source file — InventoryManager.cs — SUNSPOT replaced it with a backdoored version decrypted from an AES128-CBC encrypted blob:

SUNSPOT build interception (pseudocode from CrowdStrike analysis):

while (true):
    sleep(1000ms)
    for each process in GetRunningProcesses():
        if process.name == "MsBuild.exe":
            if ORION_SOLUTION_FILE in process.CommandLine:
                if MD5(InventoryManager.cs) == expected_hash:
                    malicious_code = AES_Decrypt(payload, key, iv)
                    WriteFile("InventoryManager.cs", malicious_code)
                    WaitForBuildComplete()
                    RestoreOriginalFile()

After compilation completed, SUNSPOT restored the original file. The source code repository remained clean. The backdoor existed only in the compiled binary — which was then signed with SolarWinds’ legitimate code-signing certificate and distributed to customers through the normal update channel. Any developer who checked InventoryManager.cs in source control would see clean code. Traditional code review was useless because the code being reviewed was never malicious. The malicious code appeared only during compilation and was cleaned up immediately afterward.

SUNBURST: The Backdoor That Looked Like Legitimate Code

The backdoor landed in SolarWinds.Orion.Core.BusinessLayer.dll, inside a class called OrionImprovementBusinessLayer — a name deliberately chosen to blend into the Orion namespace. Because it was a .NET assembly, reverse engineers could decompile it with tools like dnSpy and ILSpy almost entirely back to readable C#:

SolarWinds.Orion.Core.BusinessLayer
  └── OrionImprovementBusinessLayer
        ├── Initialize()          // Entry point
        ├── Update()              // Main execution loop
        ├── GetHash()             // FNV-1a anti-analysis checks
        ├── DelayMs()             // 12-14 day dormancy timer
        ├── GetOrCreateUserID()   // Victim fingerprinting
        └── HttpHelper            // C2 communication

ReversingLabs found that this class first appeared as an empty placeholder in an earlier Orion version — suggesting the attackers tested their build injection capability before deploying the actual payload.

12-14 Day Dormancy

After installation, SUNBURST did nothing for 12 to 14 days. It checked the DLL’s file write timestamp and refused to activate until enough time had passed — directly targeting sandbox environments that typically run samples for minutes or hours:

// Simplified dormancy check (reconstructed)
DateTime fileWriteTime = File.GetLastWriteTime(
    Assembly.GetExecutingAssembly().Location);
TimeSpan elapsed = DateTime.UtcNow - fileWriteTime;
double minDays = 12.0 + (new Random().NextDouble() * 2.0);
if (elapsed.TotalDays < minDays) return; // Stay dormant

Hashed Process Blocklist: Why Security Tools Never Saw It

One of the most studied aspects of SUNBURST is how it evaded security tooling. Rather than storing security tool names as plaintext strings, SUNBURST hashed each process name using FNV-1a and compared against a list of over 130 precomputed hashes. If any analysis or security tool was running, the backdoor silently exited:

// SUNBURST FNV-1a hash function (from Mandiant's analysis)
private static ulong GetHash(string input)
{
    ulong hash = 14695981039346656037UL;  // FNV offset basis
    foreach (char c in input.ToLower())
    {
        hash ^= (byte)c;
        hash *= 1099511628211UL;          // FNV prime
    }
    return hash;
}

The community cracked these hashes to reveal the tools SUNBURST refused to run alongside:

// Reversed hashes — partial list of 130+ blocked tools:
apimonitor-x64, apimonitor-x86     // API monitoring
autoruns, autorunsc                 // Persistence analysis
dnspy, ilspy, de4dot                // .NET decompilers/deobfuscators
fiddler, wireshark, dumpcap         // Network analysis
idaq, idaq64                        // IDA Pro disassembler
ollydbg, x32dbg, x64dbg            // Debuggers
pestudio, cff explorer              // PE analysis
procmon, debugview                  // Sysinternals
radare2, binaryninja, gdb          // Reverse engineering

This is why many sandbox detonations returned clean results — the malware detected the analysis environment and refused to execute.

Disabling Antivirus and EDR

SUNBURST went further than simply avoiding security tools. It actively disabled them. The backdoor enumerated installed security services and, once the attackers had elevated access, used legitimate administrative mechanisms to disable endpoint protection. SolarWinds’ own documentation instructed customers to exclude Orion directories from antivirus scanning and to whitelist Orion processes in their EDR — advice that most organisations followed because it came from the vendor. The attackers used this existing trust to operate in blind spots that the victims had created for themselves.

Once TEARDROP deployed Cobalt Strike beacons in target environments, the attackers used Group Policy and administrative tools to disable Windows Defender, tamper with EDR agent configurations, and suppress security event logging on compromised hosts. Because they were operating with domain administrator credentials obtained through credential harvesting, these changes appeared to be legitimate administrative actions — not malware behaviour. This is a critical point: when your security tools trust the software that’s been compromised, and the attacker gains the same administrative privileges your IT team uses, the distinction between legitimate administration and attacker activity disappears.

DGA and Selective Targeting via DNS

SUNBURST’s command and control used a custom domain generation algorithm to create subdomains under avsvmcloud[.]com. The DGA encoded victim-specific information — including the Active Directory domain name — into the subdomain, allowing the attackers to identify high-value targets from DNS queries alone:

# Example DGA subdomains (encoded victim environment data):
7sbvaemscs0mc925tb99.appsync-api.eu-west-1.avsvmcloud[.]com
ihvpgv9psvq02ffo77et.appsync-api.us-east-2.avsvmcloud[.]com

The subdomains mimicked legitimate AWS AppSync API traffic. The attackers controlled the authoritative DNS server and responded selectively — CNAME records pointing to second-stage C2 for interesting targets, localhost addresses for everyone else. HTTP C2 traffic was disguised as SolarWinds Orion Improvement Program telemetry, using legitimate Orion URL patterns and headers that organisations had already whitelisted in their firewalls.

The backdoor also checked the victim’s AD domain against a blocklist that included solarwinds.com and swi-rc.com — ensuring it never activated inside SolarWinds’ own network where it would be most likely to be noticed.

From SUNBURST to Golden SAML

For the ~100 organisations selected for active exploitation, SUNBURST was just the entry point. TEARDROP loaded entirely in memory from a fake JPEG file called gracious_truth.jpg, decoded a customised Cobalt Strike beacon, and executed it without ever writing to disk. The beacon used a completely separate C2 infrastructure from SUNBURST — meaning that discovering avsvmcloud[.]com would not reveal the post-exploitation activity.

The attackers’ signature technique was the Golden SAML attack. After compromising Active Directory Federation Services, they extracted the SAML token-signing certificate and used it to forge authentication tokens for any user, in any federated application, without triggering MFA:

<!-- Forged SAML assertion — cryptographically valid with stolen cert -->
<saml:Assertion>
  <saml:Subject>
    <saml:NameID>admin@target.gov</saml:NameID>
  </saml:Subject>
  <saml:AudienceRestriction>
    <saml:Audience>https://mail.target.gov</saml:Audience>
  </saml:AudienceRestriction>
  <!-- Signed with stolen AD FS private key — accepted everywhere -->
</saml:Assertion>

No password required. No MFA prompt. No login anomaly in the logs. The forged token was cryptographically valid and accepted by every relying party — Microsoft 365, Azure, AWS, anything that trusted the organisation’s identity provider.

The Same Attackers Later Breached Microsoft Itself

In late 2023, the same SVR group breached Microsoft using a far simpler method: a password spray attack against a legacy test tenant account with no MFA. From that single account they pivoted to an OAuth application with elevated access and exfiltrated email from senior Microsoft executives — including members of the security and legal teams investigating the original SolarWinds campaign. Microsoft later confirmed the attackers also accessed internal source code repositories. The most sophisticated supply chain attackers in history demonstrated that when a simple technique works, sophistication is unnecessary.

What Defenders Should Take From This

SUNBURST’s dwell time was approximately 14 months. The attackers compromised the build pipeline, signed their malware with the vendor’s certificate, disabled security tooling through legitimate administrative channels, disguised their C2 as whitelisted application traffic, and forged authentication tokens that bypassed every identity control. Traditional perimeter defences, signature-based antivirus, and even EDR solutions operating in standard configurations were insufficient — because the attack was designed specifically to exploit the trust relationships these tools depend on.

The detection signals that ultimately exposed SUNBURST were anomalous DNS patterns, unexpected process behaviours from the Orion service account, and network connections to infrastructure that didn’t match legitimate SolarWinds endpoints. These are exactly the kinds of signals that require continuous monitoring, behavioural analysis, and skilled human analysts to detect — not just tooling, but people who understand what normal looks like and can recognise when something deviates.

This is where solutions like Spectra matter. A cloud-native SIEM with AI-powered detection can correlate DNS anomalies, process behaviour, and network telemetry at scale — surfacing the subtle indicators that rule-based tools miss. SUNBURST was designed to evade point solutions. Detecting it required the kind of cross-signal correlation and behavioural baselining that SIEM platforms are built for, combined with threat hunters who know what to look for. The SolarWinds attack proved that no vendor, no certificate, and no update mechanism should be implicitly trusted. The organisations that survive the next supply chain attack will be the ones that had the visibility and the expertise to notice something was wrong before the attacker completed their mission.