threatintel
actor tracker
Named attack · kill-chain walkthrough

SolarWinds / SUNBURST

Supply-chain compromise of SolarWinds Orion

APT29 (UNC2452 / NOBELIUM)Sep 2019 – Dec 2020High confidence

Attributed by the U.S. government to the Russian Foreign Intelligence Service (SVR).

A trojanized Orion update reached ~18,000 SolarWinds customers. A small subset — including U.S. federal agencies and Microsoft — were selected for hands-on follow-on, pivoting from on-prem networks into Microsoft 365 and Azure via forged SAML tokens.

scene 00 / 07
devworkstationcommitsSolarWinds build serverMsBuild.execompiling OrionSUNSPOTwatches MsBuildMITRE S0562swap InventoryManager.csSolarWinds.Orion….dllsigned · SolarWinds certOrion update CDN2019.4 HF5 – 2020.2.1~18,000 customers~100 selected for hands-onBUILD PIPELINE / INITIAL ACCESSPOST-EXPLOIT / CLOUD PIVOTon-premcloudon-prem ADFSSAML signing keyT1558.001steal keyGolden SAMLforged trusted tokenT1606.002SUNBURSTbackdoor C2 beaconavsvmcloud.com · T1071.001AD lateralmovementT1078.002discovery / enumnet / ldap reconT1018 · T1482sign in as anyone →Microsoft 365 / Azuremailboxes · documents · TeamsattributionAPT29 / Cozy BearSVR · RussiaFireEye · MicrosoftCISA AA20-352A
  1. Phase 01 · Initial AccessTA0001

    The backdoor was injected at compile time — inside SolarWinds' own build server

    • By September 2019 the operators had access to the SolarWinds Orion build environment; the original on-prem foothold has never been publicly confirmed.
    • They deployed SUNSPOT (MITRE S0562) on the build server. SUNSPOT monitored running processes via WMI and waited for an Orion build to start.
    • When MsBuild.exe began compiling Orion, SUNSPOT replaced the legitimate source file `InventoryManager.cs` with a trojanized copy carrying the SUNBURST backdoor, then restored the original after the compile.
    • Because the swap happened inside the compile, the resulting DLL was signed with SolarWinds' real code-signing certificate and shipped through the legitimate update channel as Orion 2019.4 HF5 through 2020.2.1.
    • Roughly 18,000 customers downloaded the trojanized build between March and June 2020.
  2. Phase 02 · ExecutionTA0002

    SUNBURST runs inside the trusted SolarWinds.BusinessLayerHost.exe process

    • The trojanized DLL was loaded automatically by the Orion service host on install.
    • After a 12–14 day dormancy, SUNBURST began beaconing and executed operator commands in-process, blending into legitimate SolarWinds telemetry.
  3. Phase 03 · PersistenceTA0003

    The legitimate Orion service was the persistence — no extra footholds needed

    • Customers themselves kept the trojanized service running and patched.
    • On a subset of victims the actor also deployed the SUPERNOVA .NET web shell as a separate fallback foothold.
  4. Phase 04 · Defense EvasionTA0005

    Valid signature, long dormancy, and DGA subdomains kept SUNBURST invisible

    • DLL signed with SolarWinds' real digital certificate (T1553.002).
    • Built-in environment checks before activation to dodge sandboxes and security tooling.
    • Subdomains under avsvmcloud[.]com generated via a domain-generation algorithm so simple block lists missed it.
  5. Phase 05 · Credential AccessTA0006

    Golden SAML — stealing the ADFS signing key to mint trusted tokens

    • After on-prem foothold, the actor extracted the SAML token-signing certificate from Active Directory Federation Services.
    • With that key, they could forge SAML tokens for any identity in the federated tenant — including service principals.
    • Forged tokens walk past MFA: the cloud identity provider sees a fully-signed, trusted assertion.
  6. Phase 06 · Lateral MovementTA0008

    On-prem → cloud: forged tokens pivot into Microsoft 365 and Azure

    • Forged SAML tokens used to sign into M365 and Azure as both users and service principals.
    • In some tenants the actor added a new trusted federated domain (or modified an existing one) so they could keep issuing their own tokens.
    • Result: the cloud identity plane itself became a persistence mechanism.
  7. Phase 07 · Collection & ExfiltrationTA0009

    Mailbox harvesting via legitimate Microsoft Graph APIs

    • With cloud identity captured, the actor read mail and documents through normal M365 APIs as trusted principals.
    • API traffic looked routine; on-prem SUNBURST stayed the only obvious anomaly — and most defenders did not find it until December 2020.
Diamond Model

Caltagirone / Pendergast / Betz 2013 — four-vertex attribution framework.

Adversary
  • APT29 (UNC2452 / NOBELIUM)
Capability
  • T1195.002
  • T1554
  • T1106
  • T1059.003
  • T1505.003
  • +1 more
Infrastructure
  • avsvmcloud.com
Victim
  • See narrative above
Primary sources