Breach Files #003: SolarWinds 2020

The Attackers Who Were Inside for 14 Months — And Nobody Noticed

A complete technical breakdown — attack chain, exact TTPs, and three framework mappings.

Before We Start

Breach Files #001 was about human manipulation. One tired contractor, one approved MFA push, one company owned.

Breach Files #002 was about destruction. A cyber weapon disguised as ransomware, $10 billion in damage, a world that never saw it coming.

Breach Files #003 is about something quieter. And because of that, far more dangerous.

Stealth. Patience. Precision.

The SolarWinds attackers were not in a hurry. They did not destroy anything. They did not announce themselves on Slack. They moved through some of the most secure networks on the planet — the US Treasury, the Department of Homeland Security, the Pentagon, FireEye — for 14 months without a single alarm going off.

When they were finally discovered, it was not because any security tool caught them.

It was an accident.

The Target

Attack name: SUNBURST / Solorigate Initial access date: September 2019 Discovery date: December 13, 2020 Time undetected: Approximately 14 months Attributed to: APT29 / Cozy Bear — Russian Foreign Intelligence Service (SVR) Initial vector: SolarWinds Orion software build pipeline Stage 1 victims: ~18,000 organisations received the backdoored update Stage 2 victims (actively exploited): ~40 confirmed by Microsoft

Confirmed Victim Category US Treasury Department Government US Department of Homeland Security Government US State Department Government US Department of Commerce Government Pentagon (limited access confirmed) Government / Military FireEye Cybersecurity Microsoft Technology Intel Technology Cisco Technology Belkin Technology Deloitte Consulting

Victims were identified across North America, Europe, Asia, and the Middle East. Over 80% of confirmed targets were US-based.

What Made SolarWinds the Perfect Target

SolarWinds Orion is enterprise IT monitoring software. It watches networks, manages configurations, tracks performance across servers and applications.

To do this job, Orion requires something extraordinary: elevated privileges across the entire infrastructure it monitors.

It needs to see everything. So it was given access to everything.

When APT29 compromised Orion, they did not break into individual targets one by one. They compromised the software that already had the keys — and then let 18,000 organisations install it themselves through a routine update.

The attacker never needed to knock on a single door. Every victim held the door open for them.

The Malware Family — Four Components

SolarWinds involved four distinct malware components, each with a specific role:

Malware Role Deployed SUNSPOT Build pipeline injector — watched for Orion build commands and replaced source files with SUNBURST September 2019 SUNBURST The backdoor — delivered via poisoned Orion update, established C2, filtered targets February–June 2020 TEARDROP Second-stage dropper — delivered Cobalt Strike Beacon to high-value targets Post-SUNBURST activation RAINDROP Lateral movement tool — similar to TEARDROP, used for spreading across victim networks May 2020 onward

Each component was designed to be isolated from the others. The attackers went out of their way to ensure that SUNBURST and TEARDROP were separated as much as possible to evade detection. Finding one would not lead investigators to another.

The Complete Attack Chain

Stage 1 — Initial Access to SolarWinds Build Environment

Date: September 2019 Method: Unknown initial access vector (likely password spraying or spear phishing)

In September 2019, APT29 gained access to SolarWinds’ internal development environment. The exact initial access method has not been publicly confirmed. What is confirmed is that by October 2019, the attackers were already testing code injection into the Orion build pipeline — inserting innocuous test code that did nothing, purely to verify the injection mechanism worked without triggering alerts.

They were rehearsing.

Stage 2 — SUNSPOT: The Build Pipeline Implant

Date: September–October 2019 Tool: SUNSPOT malware Target: SolarWinds Orion build server

SUNSPOT was installed on SolarWinds’ build server — the machine responsible for compiling Orion’s source code into a finished software product.

SUNSPOT’s function was precise: it watched the build server for the specific build command that assembled Orion. When it detected that command, it temporarily replaced legitimate Orion source code files with malicious versions containing the SUNBURST backdoor. After the build completed, it restored the original files.

The compiled Orion update contained SUNBURST. The source code repository did not. Code reviews would find nothing. Source control would show nothing. Only the compiled binary was infected — and only during the brief window of the build process.

This is one of the most sophisticated software supply chain techniques ever documented in a real-world attack.

Stage 3 — SUNBURST: The Backdoor Delivered at Scale

Date: March 26, 2020 — SolarWinds begins distributing infected updates Affected versions: Orion 2019.4 through 2020.2.1 HF1 Recipients: ~18,000 organisations

When organisations installed the Orion update between March and June 2020, they installed SUNBURST alongside it. The backdoor was digitally signed with SolarWinds’ legitimate code signing certificate — making it indistinguishable from authentic SolarWinds software to every security tool that checked.

SUNBURST then began its most remarkable behaviour: it did nothing for two weeks.

After installation, SUNBURST entered a dormancy period of at least 12–14 days before initiating any C2 communication. This gap was deliberate — it separated the installation event from the first malicious network activity in time, making correlation in security logs extremely difficult.

When SUNBURST did activate, it communicated via DNS queries to avsvmcloud[.]com — the attacker-controlled C2 domain. The DNS traffic was designed to mimic legitimate Orion network activity patterns, blending into the normal traffic baseline of every organisation it infected.

SUNBURST then performed target filtering. Not every infected organisation was worth the risk of further exploitation. The malware checked for:

• Security software processes (if certain AV/EDR tools were found, it went dormant)
• Whether the domain matched a target of interest
• Internal network characteristics that indicated high-value infrastructure

For the vast majority of the 18,000 infected organisations, SUNBURST simply went dormant. They were collateral — infected but not exploited. Only select high-value targets received Stage 2 attention.

Stage 4 — TEARDROP and RAINDROP: Second Stage Activation

Date: Post-activation (varies by victim, from May 2020 onward) Tools: TEARDROP, RAINDROP, Cobalt Strike Beacon

For targets designated as high-value, APT29 moved to Stage 2.

TEARDROP — a custom dropper — was delivered to selected victims. Its purpose was to load Cobalt Strike Beacon, a commercial penetration testing tool repurposed as an espionage platform. Cobalt Strike gave the attackers a fully-featured C2 channel — file access, command execution, lateral movement, credential theft — while blending into legitimate pentesting tool traffic patterns.

RAINDROP served a similar function to TEARDROP but was used specifically for lateral movement within victim networks — spreading Cobalt Strike to additional machines that had not been directly infected by SUNBURST.

Critically, RAINDROP was never delivered by SUNBURST directly. It appeared on machines after the initial compromise — introduced through a separate pathway, keeping the two components forensically isolated.

By using TEARDROP and RAINDROP, the attackers protected SUNBURST from discovery. Even if Stage 2 activity was detected, investigators would find Cobalt Strike — a tool used legitimately by pentesters everywhere — not a novel backdoor that would immediately point back to SolarWinds.

Stage 5 — Hands-on-Keyboard Operations

Duration: Months, varying by victim Method: Living off the land — SAML token forgery, Azure AD abuse, legitimate admin tools

Inside target networks, APT29 operated with extraordinary discipline.

They used SAML token forgery — creating forged authentication tokens that gave them persistent access to cloud services (Microsoft 365, Azure) without needing passwords. This technique left minimal forensic evidence because the tokens appeared legitimate.

They abused legitimate administrative tools — Windows Management Instrumentation (WMI), PowerShell, Windows Task Scheduler — to move laterally and maintain access without deploying additional custom malware. This is called living off the land: using the victim’s own tools against them.

They moved slowly. They exfiltrated data in small, consistent volumes that matched normal traffic patterns. They avoided actions that would generate security alerts.

At the US Treasury and Commerce departments, email systems were compromised. At FireEye, their Red Team toolkit — a collection of offensive security tools — was stolen.

Stage 6 — Discovery

Date: December 8–13, 2020 Discovered by: FireEye — accidentally, while investigating their own breach

FireEye noticed an unusual device had registered for MFA on their network. An employee appeared to have a second phone connected to their account. When FireEye’s security team called the employee to verify — the employee had not registered any second device.

FireEye began investigating and discovered they had been compromised via SolarWinds Orion.

On December 13, 2020, FireEye published their findings publicly, naming the backdoor SUNBURST and the campaign UNC2452. The same day, SolarWinds began notifying customers.

CISA issued Emergency Directive 21–01 ordering all US federal civilian agencies to immediately disconnect SolarWinds Orion instances from their networks.

The attacker had been inside for 14 months. They were discovered because of an MFA anomaly — not because any security tool caught SUNBURST itself.

The Exact Timeline

Date Event Sep 2019 APT29 gains access to SolarWinds build environment Oct 2019 Test code injection into Orion build pipeline — rehearsal run Feb 20, 2020 SUNBURST backdoor injected into Orion source build Mar 26, 2020 SolarWinds begins distributing infected Orion updates May 2020 RAINDROP first deployed in victim networks Mar–Jun 2020 ~18,000 organisations install backdoored updates Jun 2020 SolarWinds stops distributing infected version Sep–Oct 2020 Palo Alto Networks detects DNS callbacks — attack not yet understood Dec 8, 2020 FireEye detects breach of their own systems Dec 13, 2020 FireEye publishes SUNBURST findings. SolarWinds notifies customers Dec 13, 2020 CISA Emergency Directive 21–01 issued Dec 14, 2020 SolarWinds files SEC Form 8-K Dec 18, 2020 Microsoft confirms 40+ victims. Brad Smith calls it “a moment of reckoning” Jan 5, 2021 CrowdStrike publishes SUNSPOT analysis Jan 18, 2021 Symantec discloses RAINDROP Feb 2021 US government attributes attack to Russian SVR / APT29

Framework Mapping

1. MITRE ATT&CK

TTP Code Technique How It Was Used T1195.002 Supply Chain Compromise: Software Supply Chain SUNSPOT poisoned Orion build pipeline T1553.002 Subvert Trust Controls: Code Signing SUNBURST signed with legitimate SolarWinds certificate T1027 Obfuscated Files or Information SUNBURST disguised as legitimate Orion DLL T1071.004 Application Layer Protocol: DNS C2 communication via DNS queries to avsvmcloud[.]com T1568.002 Dynamic Resolution: Domain Generation C2 domain used subdomain encoding to identify victims T1550.001 Use Alternate Authentication Material: SAML Tokens Forged SAML tokens for persistent cloud access T1078 Valid Accounts Used legitimate admin credentials for lateral movement T1059.001 Command and Scripting: PowerShell Living off the land post-exploitation T1560 Archive Collected Data Data staged before exfiltration T1102 Web Service Cobalt Strike C2 over HTTPS mimicking legitimate traffic

Most critical TTP: T1195.002 — For the second consecutive article in this series, supply chain compromise is the root of everything. SolarWinds and NotPetya both prove the same thing: compromise the vendor, and every customer becomes a victim automatically.

Most sophisticated TTP: T1550.001 — SAML token forgery. This technique allowed persistent access to cloud infrastructure without passwords, leaving almost no forensic trail. It is one of the most advanced post-exploitation techniques documented in any public breach analysis.

2. Cyber Kill Chain

Phase What Happened Duration Reconnaissance Identified SolarWinds Orion as high-value supply chain target Unknown — months/years prior Weaponisation Built SUNSPOT, SUNBURST, TEARDROP, RAINDROP, Cobalt Strike loaders Months prior Delivery SUNSPOT injects SUNBURST into Orion build pipeline Sep 2019 — Feb 2020 Exploitation 18,000 organisations install backdoored update — no user error required Mar — Jun 2020 Installation SUNBURST dormancy period — 12–14 days of silence post-install Mar — Jun 2020 C2 DNS-based callbacks to avsvmcloud[.]com — target filtering, Stage 2 selection Jun 2020 onward Actions on Objectives TEARDROP/RAINDROP → Cobalt Strike → SAML forgery → data exfiltration Jun — Dec 2020

Key Kill Chain insight: The gap between Delivery and C2 is the defining feature of this attack. Most malware activates immediately on installation. SUNBURST waited 12–14 days, then mimicked legitimate traffic patterns. Standard security monitoring correlates events in time windows — hours, days at most. A 14-day gap between installation and first malicious activity sits completely outside normal detection windows.

Where defenders had the best chance:

• Delivery phase — build pipeline integrity monitoring and reproducible build verification would have detected SUNSPOT
• C2 phase — DNS monitoring for unusual subdomain patterns to avsvmcloud[.]com
• Actions phase — SAML token anomaly detection and impossible travel alerts in Azure AD

3. Diamond Model

Key Diamond Model insight: APT29’s infrastructure was almost entirely borrowed or disguised. The C2 domain mimicked legitimate traffic. Cobalt Strike is a commercial tool. SAML tokens were legitimate by design. The attacker built an operation where almost every component, examined in isolation, appeared authorized. This is the hallmark of a mature nation-state operation — not breaking in loudly, but becoming indistinguishable from the legitimate environment.

Root Cause Analysis

Three failures. Each one compounding the next.

Failure 1 — No build pipeline integrity monitoring SUNSPOT lived inside SolarWinds’ build environment for months. It modified source files during compilation and restored them afterward. No tool was monitoring the build process itself for unexpected file modifications during compilation. This is a gap that is still common across the software industry — source code is reviewed, but the build process is trusted implicitly.

Failure 2 — Implicit trust in signed software updates Every organisation that installed the backdoored Orion update did so because it was digitally signed by SolarWinds. Code signing is a critical security control — but it only verifies that the software came from the stated publisher. It does not verify that the publisher’s build pipeline was uncompromised. Signing verified the package was from SolarWinds. It said nothing about what SolarWinds had unknowingly included.

Failure 3 — Flat cloud trust models and over-privileged service accounts Once inside victim networks, APT29’s most powerful technique was SAML token forgery — gaining persistent cloud access without passwords. This was possible because victim organisations had not implemented anomaly detection on authentication token usage, had not enforced conditional access policies that might have flagged impossible travel or unusual access patterns, and had granted Orion service accounts more cloud access than necessary.

Orion needed network monitoring access. It did not need the level of cloud identity access that allowed SAML token forgery to be effective. Least privilege, applied to service accounts and monitoring tools, would have dramatically reduced the blast radius.

What Made This Different From Every Breach Before It

SolarWinds was the first publicly documented case of a nation-state attacking the software build pipeline itself at this scale and sophistication.

Previous supply chain attacks compromised update servers after the fact — like NotPetya’s M.E.Doc compromise. SolarWinds went deeper: APT29 was inside the build environment, modifying the compilation process, producing signed malicious binaries that no downstream security tool could distinguish from legitimate software.

The implications for the software industry were immediate. Microsoft President Brad Smith called it “a moment of reckoning.” The attack influenced the US Executive Order on Cybersecurity issued in May 2021, which mandated software bill of materials (SBOM) requirements and supply chain security standards for government software vendors for the first time.

The NullyBlissful Take

What this teaches someone learning offensive security

I’m Mayan Suthar. I’ve spent months grinding CTF machines and studying how real attackers operate. Three articles into Breach Files, and SolarWinds is the one that has changed how I think the most.

First — the build pipeline is an attack surface almost nobody thinks about.

In CTFs and lab environments, I think about services, credentials, misconfigurations. I think about what’s running and who has access to it. SolarWinds taught me to think one level up: what produces the software that runs on the target? What does the CI/CD pipeline look like? Who has access to the build server? SUNSPOT was not sophisticated because of its code — it was sophisticated because of where it lived. A build server is one of the most trusted machines in any organisation. Nobody watches it the way they watch production servers. That blind spot is enormous.

Second — patience is a weapon.

Every CTF has a time pressure — implicit or explicit. Real nation-state operations have no such constraint. APT29 spent months doing a test run before deploying SUNBURST. They waited 14 days after installation before activating. They moved slowly inside victim networks for months. The 12–14 day dormancy period alone tells you everything about the operational mindset: they understood detection windows better than the defenders did.

When I’m studying attack methodology, I now ask not just how an attack works, but how long would this take and what would this look like in a SIEM 6 months later. Those questions change how you think about stealth.

Third — SAML token forgery is the most underappreciated technique in this entire series.

I’ve studied credential attacks extensively — pass-the-hash, Kerberoasting, AS-REP roasting. SAML token forgery is different. It operates at the identity layer of cloud infrastructure, produces tokens that are cryptographically valid, and leaves almost no traditional forensic trace. As someone on the OSCP path and thinking about cloud environments, this technique sits at the intersection of AD exploitation and cloud security — exactly the space where modern enterprise attack surface is expanding fastest.

Understanding SAML, how Azure AD trust relationships work, and how token-based authentication can be abused is the next frontier for anyone serious about offensive security.

Read SolarWinds. Then go learn how SAML works. The gap between those two things is where the real knowledge is.

Null is peace. Bliss is the overflow.

Series Navigation

Breach Files #001 — Uber 2022 | Read here Breach Files #002 — NotPetya 2017 | Read here Breach Files #003 — SolarWinds 2020 ← You are here Breach Files #004 — Coming soon

— Mayan Suthar | NullyBlissful Penetration tester, builder, and overthinker. GitHub: github.com/MayanSuthar | LinkedIn: linkedin.com/in/mayan-suthar-5625b1229 | Medium: nullyblissful.medium.com “I am not a body. I am not even the mind.”