The SolarWinds attack, disclosed yesterday, is one of the most significant cyber incidents in history. Attackers compromised SolarWinds’ build system to inject malware into software updates, affecting thousands of organizations including government agencies.
Here’s what happened and what it means for software security.
What Happened
The Attack Timeline
March 2020: Malicious code injected into SolarWinds Orion build
March-June 2020: Trojanized updates distributed to ~18,000 customers
December 8, 2020: FireEye discloses breach, discovers attack vector
December 13, 2020: SolarWinds confirms supply chain compromise
How It Worked
┌─────────────────────────────────────────────────────────────────┐
│ SolarWinds Build System │
│ │
│ Source Code ──► Build Process ──► Signed Update ──► Customers │
│ ▲ │
│ │ │
│ ┌────────┴────────┐ │
│ │ Attacker Access │ │
│ │ (Injected code │ │
│ │ into build) │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────┐
│ Trojanized Update │
│ (Legitimate signature) │
└───────────┬─────────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Victim │ │ Victim │ │ Victim │
│ A │ │ B │ │ C │
└─────────┘ └─────────┘ └─────────┘
The Malware (SUNBURST)
Characteristics:
- Dormant for ~2 weeks after installation
- Checked for security tools before activating
- Communicated via DNS to evade detection
- Masqueraded as legitimate Orion traffic
- Selected high-value targets for further exploitation
Victim Environment
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ SUNBURST Behavior │
│ │
│ 1. Sleep for 12-14 days │
│ 2. Check for security tools (avoid sandboxes) │
│ 3. DNS beacon to C2 (disguised as SolarWinds traffic) │
│ 4. Receive targeting instructions │
│ 5. If targeted: Download TEARDROP for further access │
│ │
└─────────────────────────────────────────────────────────────────┘
Why Traditional Security Failed
Trust in Signed Software
Traditional assumption:
Signed by vendor → Trusted → Run without scrutiny
Reality:
Build system compromised → Malware signed → Still trusted
Code signing prevents tampering after signing, not before.
Network-Level Detection
Why detection was hard:
- Traffic looked like legitimate SolarWinds communication
- DNS queries to domains similar to legit infrastructure
- Low and slow (not noisy)
- 2-week dormancy evaded sandbox analysis
Perimeter Security
The malware was inside the perimeter from day one:
- Delivered via trusted update channel
- Running as trusted software
- Had legitimate-looking behavior
Lessons Learned
Build System Security
The build system is as critical as production:
build_security_requirements:
access_control:
- Principle of least privilege
- Multi-person approval for changes
- Separate credentials from development
- Audit all access
integrity:
- Reproducible builds
- Build artifact verification
- Source-to-binary traceability
- Hermetic builds (isolated, deterministic)
monitoring:
- All build activities logged
- Alerts on unusual patterns
- Regular integrity checks
- Comparison of build outputs over time
isolation:
- Separate from corporate network
- Dedicated infrastructure
- No internet access (air-gapped or proxied)
- Ephemeral build environments
Software Bill of Materials (SBOM)
Know what’s in your software:
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"version": 1,
"components": [
{
"type": "library",
"name": "lodash",
"version": "4.17.21",
"purl": "pkg:npm/lodash@4.17.21",
"hashes": [
{
"alg": "SHA-256",
"content": "abc123..."
}
]
}
]
}
SBOM enables:
- Vulnerability tracking
- License compliance
- Supply chain visibility
- Incident response
Dependency Verification
Don’t blindly trust dependencies:
# Verify checksums
npm ci --ignore-scripts # Don't run arbitrary scripts
npm audit # Check for known vulnerabilities
# Pin exact versions
# package-lock.json, go.sum, requirements.txt
# Verify signatures where available
cosign verify --key cosign.pub myimage:tag
Zero Trust for Software
Apply zero trust principles to software:
assumptions:
- Any component could be compromised
- Verify explicitly, don't trust implicitly
- Least privilege for all components
- Monitor behavior, not just access
implementation:
- Runtime security monitoring
- Network segmentation between components
- Behavioral baselining
- Anomaly detection
Detection Strategies
Hunt for Compromise
If you ran affected SolarWinds versions:
# Check for indicators of compromise
# SolarWinds Orion versions 2019.4 HF5 through 2020.2.1
# DNS queries to:
# avsvmcloud[.]com (C2 domain)
# Files:
# SolarWinds.Orion.Core.BusinessLayer.dll (trojanized)
# Network connections:
# Unusual DNS queries with encoded hostnames
# Connections from SolarWinds processes to unusual destinations
Behavioral Indicators
suspicious_behaviors:
- SolarWinds process spawning cmd.exe/powershell.exe
- Unusual outbound connections from Orion server
- DNS queries with unusually long subdomain names
- Memory-only payloads (TEARDROP)
- Lateral movement from Orion server
Long-Term Hunting
Attacker dwell time: ~9 months
Traditional IoC hunting: Insufficient
Need:
- Historical log analysis
- Behavioral anomaly detection
- Authentication audit
- Privilege escalation review
Future Defenses
Reproducible Builds
Verify that source produces expected binary:
# Build twice, compare outputs
# Different machines, same result = reproducible
build-1: docker build . -t myapp:v1
build-2: docker build . -t myapp:v1-verify
diff <(docker inspect myapp:v1) <(docker inspect myapp:v1-verify)
Sigstore and Transparency
Public transparency logs for software artifacts:
# Sign with Sigstore
cosign sign --key cosign.key myimage:tag
# Verify signature
cosign verify --key cosign.pub myimage:tag
# Artifacts logged to Rekor transparency log
# Anyone can audit the signing history
Runtime Protection
Detect malicious behavior regardless of source:
runtime_defenses:
- EDR on critical systems
- Network traffic analysis
- Behavioral monitoring
- Anomaly detection
- Zero trust networking
Organizational Response
Immediate Actions
If potentially affected:
1. Isolate SolarWinds Orion servers
2. Preserve evidence (don't rebuild yet)
3. Check for IoCs in logs
4. Review outbound traffic from Orion
5. Reset credentials accessible from Orion
6. Engage incident response
Strategic Changes
1. Review supply chain security posture
2. Implement SBOM for critical software
3. Enhance build system security
4. Deploy runtime protection
5. Improve detection capabilities
6. Practice supply chain attack scenarios
Key Takeaways
- Supply chain attacks compromise trust at the source; signed ≠ safe
- Build systems need production-level security; they’re high-value targets
- Software bills of materials enable visibility into what you’re running
- Traditional perimeter security fails when malware arrives via trusted channel
- Behavioral monitoring catches malicious activity regardless of source
- Reproducible builds and signing help verify software integrity
- Zero trust applies to software: verify explicitly, assume breach
- Long dwell times require historical analysis, not just real-time detection
- This attack changes how we think about software supply chain security
The SolarWinds attack is a watershed moment. Software supply chain security can no longer be an afterthought. Every organization needs to evaluate their exposure and improve their defenses.