The SolarWinds Attack: How It Happened, What Was Stolen, and How to Prevent It

by

The SolarWinds hack, discovered in December 2020, was one of the most sophisticated cyberattacks in history. Russian intelligence operatives (APT29/Cozy Bear) compromised the software supply chain used by 18,000 organizations, including the US Treasury, Pentagon, and multiple Fortune 500 companies. It remained undetected for at least 9 months.

Understanding exactly how it happened is essential for every security professional. This is the real story.

Timeline of the Attack

October 2019 — Initial Access

APT29 first compromised SolarWinds’ build environment in October 2019. They gained access to the internal Orion software build pipeline — the system that compiles and packages the Orion IT monitoring software used by 33,000 customers.

How they got in: Multiple theories exist — a compromised SolarWinds intern’s password was “solarwinds123” and was publicly exposed on GitHub. Others point to a targeted spear-phishing campaign against SolarWinds developers. The exact initial vector was never publicly confirmed.

February–March 2020 — Injecting SUNSPOT

The attackers deployed a novel piece of malware called SUNSPOT into the build server. SUNSPOT’s only job was to monitor the build process and, when it detected Orion being compiled, silently inject malicious code — the SUNBURST backdoor — into the final software package.

This is the supply chain attack’s genius: they never had to attack any of the 18,000 victims directly. They attacked the vendor and let the vendor’s legitimate update process deliver the malware for them.

# SUNSPOT's detection logic (reconstructed from analysis)
# It watched for specific source files being compiled:
# SolarWinds.Orion.Core.BusinessLayer.dll

# When detected, it replaced a legitimate source file with
# the malicious version containing SUNBURST, compiled the
# package, then restored the original file.
# The infected DLL had a valid SolarWinds digital signature.

# SUNBURST was embedded in: SolarWinds.Orion.Core.BusinessLayer.dll
# SHA256: b91ce2fa41029f6955bff20079468448

March–June 2020 — Trojanized Orion Updates Released

SolarWinds released Orion updates versions 2019.4 through 2020.2.1 containing SUNBURST. The software was digitally signed by SolarWinds, passed all security checks, and was automatically deployed by customers — 18,000 of them.

June–October 2020 — TEARDROP and Hands-on-Keyboard Activity

SUNBURST remained dormant for 12-14 days after installation (to evade sandbox analysis). It then began contacting the command-and-control server at avsvmcloud.com — disguised as normal Orion telemetry traffic. Against selected high-value targets, APT29 deployed a second-stage malware called TEARDROP, which loaded Cobalt Strike Beacon into memory. From there, they conducted hands-on-keyboard operations.

# SUNBURST C2 communication disguise
# The malware mimicked legitimate SolarWinds API traffic
# C2 domain: avsvmcloud.com (looked like a SolarWinds domain)
# All traffic was HTTPS, blending with normal encrypted traffic

# SUNBURST victim identification algorithm:
# - Generated unique victim ID from environment
# - Encoded as a subdomain: {victimID}.avsvmcloud.com
# - Used DNS A record responses to receive commands
# - Commands encoded in IP address values returned

# Example C2 subdomain pattern:
# 7sbvaemscs0mc925tb6dr10a-f275.appsync-api.avsvmcloud.com

December 8, 2020 — FireEye Discovers the Breach

Cybersecurity firm FireEye noticed that a new employee’s MFA registration came from an unusual device — one that wasn’t issued by IT. Investigating, they discovered that an attacker had stolen a FireEye employee’s credentials and registered their own device for MFA. This led to the discovery of Cobalt Strike Beacon running in memory, which led to TEARDROP, which led to SUNBURST.

FireEye immediately notified US CISA, Microsoft, and GoDaddy (which operated avsvmcloud.com). GoDaddy sinkholed the C2 domain on December 14, 2020, cutting the attackers’ communication with all victims simultaneously.

What APT29 Stole

  • US Treasury Department: Emails from senior officials including the deputy secretary and domestic finance chief
  • US Department of Homeland Security: Internal communications including from the cybersecurity division
  • US Department of State: Sensitive diplomatic communications
  • FireEye: Their own red team tools (essentially a stolen hacking toolkit)
  • Microsoft: Source code for Azure, Exchange, and Intune (Microsoft confirmed limited access)
  • Approximately 100 companies: Intellectual property, sensitive communications, and internal systems

How to Detect SUNBURST — Even Now

While the specific campaign is over, the detection techniques are permanently valuable:

# 1. YARA rule for SUNBURST DLL detection
rule SUNBURST_Trojanized_SolarWinds {
    meta:
        description = "Detects SUNBURST backdoor in SolarWinds Orion DLL"
        reference = "https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain.html"
    strings:
        $a = "SolarWinds.Orion.Core.BusinessLayer.dll" wide
        $b = "avsvmcloud.com" ascii
        $c = "OrionImprovementBusinessLayer" ascii
    condition:
        all of them
}

# Run YARA scan against all DLLs
yara -r sunburst.yar /path/to/solarwinds/

# 2. Check for SUNBURST hash (Defender command)
Get-MpThreatDetection | Where-Object ThreatID -eq 2147771213

# 3. PowerShell - check for IOCs in DNS logs
Get-WinEvent -LogName "DNS Server" |
  Where-Object Message -match "avsvmcloud|appsync-api"

# 4. Check if SolarWinds Orion processes are making unusual outbound connections
netstat -ano | findstr :443
# Correlate PIDs with SolarWinds processes

# 5. Sigma rule for detecting supply chain IOCs
title: SolarWinds SUNBURST C2 Communication
status: stable
logsource:
  category: dns
detection:
  keywords:
    - 'avsvmcloud.com'
    - '.appsync-api.'
  condition: keywords

7 Things That Could Have Prevented This

1. Software Supply Chain Security

Implement a Software Bill of Materials (SBOM) for all third-party software. Verify checksums before installation. Use tools like Sigstore or in-toto to verify build integrity.

# Verify software SHA256 before installing
sha256sum SolarWinds-Orion-2020.2.zip
# Compare against vendor-published checksum

# Generate SBOM with Syft
syft packages dir:/opt/solarwinds -o cyclonedx-json > sbom.json

# Scan SBOM for known vulnerabilities
grype sbom:sbom.json

2. Build Server Isolation

Build servers should have zero internet access, no developer workstation access, and all code changes should require code review. SolarWinds’ build server had developer workstation connectivity — that’s what SUNSPOT exploited.

3. Privileged Identity Management

APT29 escalated privileges rapidly after initial access. Implement just-in-time privileged access, where admin accounts are only enabled for specific approved time windows.

4. MFA Everywhere — But Verify the Device

FireEye detected the breach partly because they verified the MFA device registration location. Implement Conditional Access policies that verify device compliance before allowing MFA registration.

5. Lateral Movement Detection

# Splunk query to detect lateral movement
index=windows EventCode=4648
| stats count by src_user, dest_host
| where count > 10

# Detect Pass-the-Hash attacks
index=windows EventCode=4624 Logon_Type=3
| where NOT user LIKE "%$"
| stats count by src_ip, user, dest
| where count > 20

6. Network Segmentation

The Orion platform had network access to nearly every system it monitored. That access should have been one-way (receive syslog) not bidirectional. Microsegmentation would have limited SUNBURST’s lateral movement.

7. DNS Monitoring for Anomalous Subdomains

# Zeek DNS log analysis for unusual query patterns
cat dns.log | zeek-cut query | sort | uniq -c | sort -rn |
  awk '$1 < 3 && length($2) > 40' | head -50
# Long unique subdomains = potential DNS exfiltration or C2

# Splunk DNS anomaly detection
index=dns
| eval query_length=len(query)
| where query_length > 50
| stats count by src_ip, query | sort -count

Key Lessons

The SolarWinds attack proved that even organizations with strong perimeter security can be compromised through trusted vendors. The security community’s response established new standards: vendor access verification, software supply chain attestation, and “assume breach” architecture where you design systems assuming the attacker is already inside. Zero trust isn’t a product — SolarWinds proved it’s a necessity.