What if your most trusted vendor quietly handed attackers the keys to your network?
That’s what happened in the SolarWinds hack.
Attackers broke into SolarWinds’ build environment, injected the SUNBURST backdoor into Orion, and shipped it in officially signed updates.
About 18,000 customers downloaded those poisoned updates.
The root cause was a supply-chain compromise that abused trust in build systems and code signing, letting stealthy malware masquerade as legitimate software.
This attack shows vendor trust can be the weakest link—and why supply-chain security now matters for every organization.

How the SolarWinds Hack Happened: A Clear Summary

Attackers got into the build environment where SolarWinds makes Orion, a network management tool used by thousands of companies and government offices to monitor their IT systems. Between February and June 2020, they injected a backdoor called SUNBURST directly into the legitimate software build. The compromised code got compiled into official Orion updates and signed with SolarWinds’ real certificate. That signature made the poisoned updates look completely legit.

From March through June 2020, about 18,000 SolarWinds customers downloaded and installed the trojanized updates through the normal update process. Once installed, SUNBURST went quiet for up to two weeks while it checked its surroundings to avoid getting caught. After that, it woke up and started talking back to the attackers using channels that looked like normal Orion monitoring traffic. From there, attackers could:

• Grab credentials stored in the Orion platform
• Map out victim networks and spot the valuable systems
• Move sideways to other internal systems using stolen logins
• Drop additional custom malware (TEARDROP and customized Cobalt Strike BEACON, among others)
• Pull out sensitive data through encrypted channels
• Stick around without tripping security tools

The supply chain angle made this incredibly hard to detect. The malicious code came through a trusted vendor’s official update, signed with valid certificates. Security tools that trust signed software didn’t flag it. The malware was designed to blend into legitimate Orion behavior. Most affected organizations had zero visibility into whether their vendor’s build process was clean, and the attackers kept things tight by using victim-specific infrastructure, temporary files, and legit admin tools instead of noisy persistent malware.

Timeline of the SolarWinds Supply Chain Attack

The SolarWinds intrusion played out over more than a year. Attackers stayed inside and expanded their reach while nobody noticed.

1. September 2019: Initial recon started. Attackers poked around SolarWinds’ infrastructure, looking at the build environment and update systems.

2. February 2020: SUNBURST got inserted into the Orion build system. First compromised builds were created.

3. March 24, 2020: The trojanized Orion plugin (SolarWinds.Orion.Core.BusinessLayer.dll) got signed with SolarWinds’ legitimate certificate. Compromised updates started going out.

4. March–June 2020: Roughly 18,000 customers downloaded and installed the malicious updates. SUNBURST backdoors activated across victim networks after lying low for a bit.

5. Spring–Fall 2020: Attackers ran selective follow-on ops, dropping additional malware on high-value targets, pulling data, and digging in for the long haul across dozens of organizations.

6. December 2020: FireEye spotted weird activity on its own network and traced it back to a SolarWinds Orion update. Public disclosure came shortly after, triggering emergency response across affected sectors.

The attackers operated undetected for more than nine months after those first compromised updates went out. Most victims had no clue anything was wrong until FireEye’s December disclosure. Forensics later showed that many networks had been infiltrated for the entire March–December window. That extended dwell time gave attackers plenty of opportunity to map networks, escalate privileges, and access sensitive systems before anyone could respond.

The Threat Actor Behind the SolarWinds Hack

U.S. intelligence and private security researchers widely attributed the SolarWinds operation to APT29 (also called Cozy Bear), a Russian state-sponsored group tied to Russia’s Foreign Intelligence Service (SVR). The attribution came from technical analysis of the malware, operational patterns matching previous APT29 campaigns, and intelligence assessments. APT29 has run espionage ops since at least 2008, targeting government agencies, think tanks, defense contractors, and tech companies across North America, Europe, and Asia.

The SolarWinds attack carried multiple fingerprints of APT29’s operational discipline. Key tactics observed included:

• Sophisticated supply chain targeting: going after high-leverage vendor compromise instead of direct network intrusion, maximizing reach while keeping initial detection risk low.
• Stealthy, patient operations: using extended dormancy periods, environment checks, and victim-specific infrastructure to dodge automated detection and blend with legitimate activity.
• Living off the land: preferring legitimate admin tools, valid credentials, and native OS features over custom malware, cutting down forensic footprints.
• Operational security rigor: employing temporary file manipulation, scheduled task reversion, dedicated per-victim infrastructure, and careful log hygiene to frustrate incident response and attribution.

Technical Breakdown of the SUNBURST Malware

SUNBURST was a carefully engineered backdoor built to hide inside a legitimate software product while giving deep access to victim networks. The malware ran within the standard Orion plugin loader process (SolarWinds.BusinessLayerHost.exe), making it tough to pick out from normal Orion operations. It enforced a randomized dormancy period of 12 to 14 days after installation, waiting for the filesystem write timestamp of the malicious DLL to age before doing anything. During that time, the backdoor checked its environment, verifying that the victim system was domain-joined and not running blocklisted forensic or security tools.

After activation, SUNBURST used a domain generation algorithm to create victim-specific subdomains for command and control. These DNS queries were designed to look like legitimate Orion telemetry traffic (masquerading as the Orion Improvement Program), and the malware decoded instructions from DNS CNAME responses and HTTP replies. Commands were obfuscated through multi-step encoding: attacker payloads were embedded in GUID and hex strings across JSON responses, extracted via regex, XOR-decoded, and decompressed using DEFLATE. The backdoor stored recon data in legitimate Orion config keys (like ReportWatcherRetry and ReportWatcherPostpone) to avoid creating suspicious new files or registry entries.

SUNBURST supported multiple “Job” commands that let attackers transfer files, execute arbitrary binaries, profile systems, disable services, and reboot machines. Once they had initial access, attackers deployed secondary payloads, including a memory-only dropper (TEARDROP) that loaded a customized Cobalt Strike BEACON directly into memory without writing to disk. TEARDROP read an embedded payload disguised as an image file, decoded it using a rolling XOR operation, and manually mapped the code into a running process, further dodging file-based detection.

Global Impact and Affected Organizations

The SolarWinds breach hit thousands of organizations across multiple sectors and geographies. Around 18,000 customers downloaded the compromised Orion update, though not all installations were actively exploited. Attackers ran selective follow-on operations, focusing on high-value victims in government, technology, consulting, telecommunications, and critical infrastructure. In the U.S., confirmed victims included the Department of Homeland Security, Department of Energy, Department of Commerce, Department of the Treasury, and the State Department. The breach of federal email systems and internal networks created serious intelligence and operational security concerns, as attackers potentially accessed classified or sensitive communications, policy documents, and internal agency operations.

Beyond government, the attack impacted major tech companies, cybersecurity vendors (including FireEye, whose Red Team tools got stolen), defense contractors, and telecom providers. The geographic scope stretched across North America, Europe, Asia, and the Middle East. The scale and sophistication represented an unprecedented supply chain compromise, showing that even organizations with mature security programs could get breached through trusted vendor relationships. The full damage remains tough to quantify because attackers stuck around for months, and many victims may never fully understand what data got accessed or pulled out during that window.

Long-Term Cybersecurity Implications

The SolarWinds breach fundamentally shifted how organizations and governments think about supply chain security and vendor risk. In the years following the incident, enterprises sped up adoption of zero trust architecture, rejecting the idea that internal systems or trusted vendor updates are inherently safe. Software supply chain transparency became a regulatory and contractual requirement, with increased demand for software bills of materials (SBOMs) that list every component in a software product and make rapid vulnerability assessment possible when new threats pop up.

Organizations also invested heavily in build system security, recognizing that compromise of the software development and release pipeline is a high-leverage attack vector. Better logging, continuous monitoring, and behavioral detection became priorities, as traditional signature-based defenses failed to catch the sophisticated, signed, stealthy malware used in the SolarWinds campaign. Key reforms included:

• Software Bill of Materials (SBOM) requirements: mandating transparency in software composition to make rapid vulnerability identification and supply chain risk assessment possible across all vendor relationships.
• Build system hardening: implementing multi-factor authentication, role-based access control, secrets management, code signing integrity checks, and continuous monitoring of CI/CD pipelines to prevent tampering.
• Vendor risk assessments: expanding security evaluations to include vendor development practices, audit rights, incident response obligations, and breach notification timelines in procurement contracts.
• Zero trust network architecture: eliminating implicit trust for internal systems and vendor software; enforcing continuous verification, least-privilege access, and micro-segmentation to limit lateral movement.
• Breach password defenses and credential hygiene: deploying tools that block known compromised passwords at scale, scanning Active Directory for weak or exposed credentials, and enforcing MFA across all privileged accounts to cut down credential-based attacks.

Final Words

They breached SolarWinds’ build environment, planted the SUNBURST backdoor in signed Orion updates, and quietly pushed those updates to thousands of customers in 2020.

That supply-chain method let attackers move laterally, steal credentials, and monitor high-value targets while staying hidden for months.

If you’re asking what caused the solarwinds hack: a compromised build system and trusted update process. The bright side is practical fixes—hardened build pipelines, SBOMs, and zero-trust—are now widely adopted and reduce the risk of a repeat.

FAQ

Q: Did Synnovis pay the ransom?

A: The Synnovis ransom payment status is not publicly confirmed; Synnovis hasn’t reported paying a ransom. Customers should follow official updates, reset affected credentials, enable MFA, and monitor for breach notices.

Q: What is the cause of SolarWinds hack?

A: The cause of the SolarWinds hack was a supply-chain compromise: attackers breached the Orion build system, inserted the SUNBURST backdoor into signed updates, and pushed those malicious updates to thousands of customers.

Q: Did United Healthcare pay the ransom?

A: The United Healthcare ransom payment status is not publicly confirmed; UnitedHealthcare has not disclosed paying a ransom. Members should follow company notices, monitor accounts, and enable two-factor authentication where available.

Q: What caused the airport cyber attack?

A: The airport cyber attack was typically caused by factors like compromised vendor systems, phishing, exposed remote access, or ransomware; the exact root cause depends on the specific incident and official forensic findings.