The SolarWinds attack did not begin with a phishing email or a misconfigured firewall. It began inside a build server — the trusted forge where software is assembled, signed, and shipped. By the time 18,000 organizations downloaded the trojaned Orion update in the spring of 2020, the attackers had already achieved something far more dangerous than a network intrusion: they had weaponized trust itself.

This post dissects the technical mechanics of the SUNBURST backdoor, the Orion build pipeline compromise, DGA-based command and control, and the detection and defense strategies that can limit your exposure to this class of attack.

The SolarWinds Orion Platform as an Attack Vector

SolarWinds Orion is a network monitoring platform used extensively in enterprise and government environments. It typically runs with elevated privileges — it needs broad network visibility to do its job. That privilege footprint makes it a high-value implant target.

The attackers (widely attributed to APT29, also known as Cozy Bear, operating on behalf of the Russian Foreign Intelligence Service) identified this leverage point and executed a multi-stage supply chain compromise.

Timeline of key events:

  • October 2019: Attackers are believed to have first accessed the SolarWinds environment, based on forensic analysis by Crowdstrike and others.
  • October 2019 – February 2020: Attackers conduct test injections, inserting benign placeholder code into Orion builds to test detection.
  • March 2020: SUNBURST-laced Orion updates (versions 2019.4 through 2020.2.1) are published and begin downloading to customer environments.
  • June 2020: Distribution of the malicious update ceases, but the backdoor remains active in already-deployed environments.
  • December 8, 2020: FireEye discloses it was breached and that its red team tools were stolen.
  • December 13, 2020: SolarWinds, Microsoft, and US government agencies jointly disclose the Orion compromise. CISA issues Emergency Directive 21-01.

Build Pipeline Injection: How the Code Got In

The SUNBURST backdoor was injected into SolarWinds.Orion.Core.BusinessLayer.dll, a core component of the Orion platform. The DLL was compiled and then signed with a legitimate SolarWinds code-signing certificate, making it indistinguishable from a normal update to most security tools.

The likely injection mechanism involved one or more of the following:

  1. Compromise of a developer workstation or build server via credential theft or an earlier intrusion.
  2. Modification of build scripts or a CI/CD pipeline step to include the malicious source file or binary patch.
  3. Abuse of a TFTP or source control mechanism to substitute a legitimate file with a trojanized version during the build.

The attacker’s restraint during the test phase — where they injected benign code first — demonstrates a high level of operational security and patience. They validated that their injection method worked and that the modified DLL passed signing checks before deploying weaponized code.

This technique aligns with MITRE ATT&CK T1195.002: Supply Chain Compromise — Compromise Software Supply Chain.

SUNBURST Backdoor Mechanics

Dormancy Period

After the Orion DLL loads, SUNBURST does not immediately beacon out. It performs a series of checks:

  1. Checks the hostname — if it contains strings like swdev, solarwinds, sandbox, vmware, or virtual, it exits. This prevents execution in test and analyst environments.
  2. Verifies that the Orion service has been running for at least 12–14 days since first execution. This delays C2 activity past most standard incident response timelines.
  3. Checks for the presence of certain security products and domain controller configurations before proceeding.

DGA-Based C2 Communication

SUNBURST uses a domain generation algorithm to construct DNS queries to avsvmcloud[.]com. The subdomain encodes the victim’s hostname and domain using a custom base32-like encoding scheme, allowing the C2 infrastructure to identify each victim uniquely via passive DNS — without a direct callback that might trigger IDS alerts.

Below is a Python approximation of the DGA encoding logic used by SUNBURST (reconstructed from public reverse engineering reports by FireEye and Volexity):

 1import hashlib
 2import struct
 3
 4# SUNBURST-style subdomain encoding (simplified approximation)
 5# Based on public analysis by FireEye (Mandiant) and Prevasio
 6
 7CHARSET = "ph2eifo3n5utg1j8d94qrvbmk0sal76c"
 8
 9def encode_hostname(hostname: str) -> str:
10    """
11    Encode a hostname into the SUNBURST DGA subdomain format.
12    This is a simplified reconstruction for educational/detection purposes.
13    """
14    hostname = hostname.lower()
15    uid_bytes = hashlib.md5(hostname.encode()).digest()[:8]
16    uid = struct.unpack("<Q", uid_bytes)[0]
17
18    # Encode uid into custom base32
19    encoded = []
20    for _ in range(13):
21        encoded.append(CHARSET[uid & 0x1F])
22        uid >>= 5
23
24    return "".join(encoded)
25
26def build_dga_domain(hostname: str, domain: str) -> str:
27    encoded_host = encode_hostname(hostname)
28    encoded_domain = encode_hostname(domain)
29    # Format: <encoded_host><encoded_domain>.avsvmcloud.com
30    return f"{encoded_host}{encoded_domain}.avsvmcloud.com"
31
32# Example
33victim_host = "corp-workstation01"
34victim_domain = "example.corp"
35print(build_dga_domain(victim_host, victim_domain))

The C2 server could then decode the subdomain to identify the victim, then respond with DNS records (A or CNAME) that encoded instructions — upgrade to a secondary payload (TEARDROP or RAINDROP), move laterally, or lay dormant.

Post-Compromise Lateral Movement

Once activated, SUNBURST could:

  • Execute arbitrary commands via the Windows task scheduler or WMI.
  • Move laterally using forged SAML tokens (Golden SAML attack) by compromising the ADFS signing certificate.
  • Access Microsoft 365 mailboxes and Azure AD environments without triggering standard MFA checks, because the forged tokens were valid from the IdP’s perspective.
  • Deploy secondary payloads (TEARDROP loader, RAINDROP Cobalt Strike loader) via memory-only execution to avoid file-based detection.

The Golden SAML technique in particular was devastating in cloud-connected environments, where an attacker with the ADFS signing key can impersonate any user, including global admins, to cloud services.

Detection

Splunk SPL Queries

Detect DNS queries to avsvmcloud[.]com:

index=dns_logs
| search query="*.avsvmcloud.com"
| stats count by src_ip, query, _time
| where count > 0

Identify SolarWinds Orion DLL load with hash check:

index=sysmon EventCode=7
| search ImageLoaded="*SolarWinds.Orion.Core.BusinessLayer.dll"
| eval known_bad_hashes=mvappend(
    "d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600",
    "32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77"
  )
| where md5 IN (known_bad_hashes)
| table _time, host, ImageLoaded, md5

Detect unusual SAML token issuance from ADFS (Golden SAML):

index=windows_security EventCode=1202
| search "The Federation Service validated a new credential"
| stats count by src_user, dest_service, src_ip
| where count > 5
| sort - count

Windows Event IDs to Monitor

Event IDSourceSignificance
4648SecurityLogon using explicit credentials — lateral movement
4769SecurityKerberos service ticket request — Golden Ticket/SAML
7045SystemNew service installed — persistence
4697SecurityService installed in system — SUNBURST uses scheduled tasks
1102SecurityAudit log cleared — anti-forensics

Snort/Suricata Rule for C2 DNS Traffic

alert dns any any -> any 53 (
  msg:"SUNBURST DNS C2 Query to avsvmcloud.com";
  dns.query;
  content:"avsvmcloud.com";
  nocase;
  threshold:type limit, track by_src, count 1, seconds 60;
  classtype:trojan-activity;
  sid:9000001;
  rev:2;
  reference:url,github.com/fireeye/sunburst_countermeasures;
)

PowerShell IOC Hunting

 1# Hunt for SUNBURST DLL by known bad hashes
 2$badHashes = @(
 3    "d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600",
 4    "32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77",
 5    "019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134"
 6)
 7
 8$targetPath = "C:\Program Files (x86)\SolarWinds\Orion\"
 9
10Get-ChildItem -Path $targetPath -Recurse -Filter "*.dll" | ForEach-Object {
11    $hash = (Get-FileHash -Path $_.FullName -Algorithm SHA256).Hash.ToLower()
12    if ($badHashes -contains $hash) {
13        Write-Warning "MALICIOUS FILE DETECTED: $($_.FullName) | Hash: $hash"
14    }
15}

Defense and Mitigation

1. Build Pipeline Integrity

  • Code-sign verification at multiple stages: Do not rely solely on the final binary signature. Use in-process integrity checks during the build.
  • Reproducible builds: Ensure that a given source commit always produces a byte-identical binary. Deviations indicate tampering.
  • Build environment isolation: Run CI/CD pipelines in ephemeral, immutable infrastructure. No persistent build agents with standing credentials.
  • Multi-party code review gates: Require cryptographic sign-off from two developers before a build is promoted to production.

2. Software Bill of Materials (SBOM)

An SBOM enumerates every component in your software supply chain. Use tools like Syft or CycloneDX to generate SBOMs automatically:

1# Generate an SBOM for a container image using Syft
2syft alpine:latest -o cyclonedx-json > sbom.json
3
4# Or for a directory
5syft dir:/opt/solarwinds -o spdx-json > solarwinds-sbom.spdx.json

When a compromise like SolarWinds occurs, organizations with SBOMs can run a single query to determine if the affected component is in their environment.

3. Network Segmentation for Monitoring Tools

Monitoring infrastructure (SIEM, network management) should be in a management VLAN with strict egress controls:

# Firewall rule example — block outbound DNS from monitoring servers
# to anything other than internal DNS resolvers
iptables -A OUTPUT -p udp --dport 53 ! -d 10.0.0.53 -j DROP
iptables -A OUTPUT -p tcp --dport 53 ! -d 10.0.0.53 -j DROP

Monitoring tools should never have unrestricted internet access. SUNBURST’s C2 relied on DNS beaconing — which most organizations allow outbound without logging.

4. Zero Trust for Internal Monitoring Services

  • Orion and similar tools should not have administrative credentials stored locally.
  • Use LAPS or CyberArk for credential management on monitored hosts.
  • Apply the principle of least privilege — monitoring agents should only read, never write or execute.

5. ADFS Hardening Against Golden SAML

1# Audit ADFS token-signing certificate
2Get-AdfsCertificate -CertificateType Token-Signing | Select-Object Thumbprint, NotAfter
3
4# Enable ADFS extranet lockout
5Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 5 -ExtranetObservationWindow 00:30:00
6
7# Monitor for SAML token issuance anomalies
8# Alert on issuance to cloud services from unusual source IPs

6. Vendor Risk Assessment

Before allowing a vendor’s software on privileged systems:

  • Review their SDLC and CI/CD security practices.
  • Require third-party penetration testing results for critical software.
  • Evaluate their incident response disclosure history.
  • Consider contractual obligations around timely notification of security events.

Lessons Learned

The SolarWinds breach demonstrated that an advanced threat actor with sufficient patience and access to a software vendor’s infrastructure can compromise thousands of organizations simultaneously — far more efficiently than targeting each individually.

The attacker’s OPSEC was exceptional: they used victim-specific C2 subdomains to avoid pattern matching, dormancy periods to defeat sandbox analysis, and memory-only payloads to evade file-based detection. They identified the chokepoint in the supply chain — the Orion build process — and exploited it with precision.

No perimeter control would have stopped this. The signed DLL arrived via an expected update channel. What could have helped:

  • DNS egress filtering and logging on the monitoring VLAN.
  • Behavioral anomaly detection on ADFS token issuance.
  • SBOM-based component inventory for rapid impact assessment.
  • Privileged access workstations (PAWs) for administrative activity to limit lateral movement impact.

References