← back

Software Supply Chain Vulnerabilities: Analysis of the SolarWinds Attack

By Justina | May 20, 2026 | 13 min read


The 2020 SolarWinds attack dubbed “StellarParticle” by CrowdStrike is one of the most sophisticated campaigns conducted against the United States, attributed to the Russian group APT-29. We will analyze some technicalities of the malware associated with it, and how its impact on both public and private sectors is key to understanding how destructive supply chain attacks are, especially in the age of mass, AI-driven campaigns that target third-party assets which nearly every organization relies on, whether large or small.

What is a Supply Chain Attack?

Supply chains are delicate webs of trust that exist in nearly every aspect of an organization. When you think about where your device came from, you usually associate it with a brand like Apple or Samsung–but where did the small, unassuming part of the phone’s processor come from? How about the materials used for it?

This is a supply chain, and tracking these small dependencies can get messy, which is applicable in software as well. Packages and libraries that don’t get inventoried properly can carry great risks, as just one compromised dependency can poison others downstream. This is how supply chain attacks have such a large burst radius, where compromising just one trusted developer can enable a threat actor access to hundreds of victims.

What is SolarWinds and their Orion Software?

SolarWinds is a US based company that provides IT monitoring and management tools to several government agencies and hundreds of Fortune 500 companies. Their products help organizations manage IT infrastructure, cloud-based services, and networks. Prior to it’s merge with the SolarWinds platform, Orion was the flagship software that provided alerting and reporting engines, management tools for networks, systems, virtualization, storage, and more. With the adoption of its tools within criticial organizations grew, so did the risk of its compromise.

Executive Summary

The SolarWinds attack is one of the most significant US cyber compromises, and utilized existing malware as well as campaign specific trojans. When SolarWinds released a list of customers they served in 2018, a group of threat actors likely saw it as an opportunity to poison one point of the supply chain that these customers relied on. Since Orion has a privileged position in the host it lives in, compromising its source code would mean having extreme administrative control over victim networks. Threat actor attribution points to APT29 (Cozy Bear,) who is Russia’s Foreign Intelligence Service backed APT (Advanced Persistant Threat) group whose main goal is to gather foreign intelligence through highly stealthy, long, and sophisticated campaigns. The SolarWinds attacks breached thousands of organizations, but only actually targeted a select handful to deal heavy damage to. These victims were high profile, being top Fortune 500 companies, federal defense agenices, and military branches–but they also affected those in the education, healthcare, telecommunications, and accounting industries.

What they stole exactly is still not known, but we can assume that it was highly confidential information that could be used for espionage and counter-intelligence used to do things such as exposing covert agents. In order to do this, APT29 likely used social engineering for initial access (though this is not verifiable), malicious code injections in the build process, privilege escalation, backdoors for persistent access in key victims, and command-and-control (C2) servers for data exfiltration.

Timeline

DateEvent
September 9 2019APT29 gained access to internal SolarWinds development environment
September 19 2019APT29 injects test code and begins trial run
November 4 2019Test injection ends
February 20 2020SUNBURST (malicious Orion version) is compiled and preparing for deployment
March 26 2020SUNBURST is officially pushed out to unknowing SolarWinds customers
June 4 2020APT29 removes SUNBURST malware from SolarWinds build VMs to maintain stealth
December 12 2020FireEye notifies SolarWinds of compromised Orion version
December 13 2020Public disclosure released
December 14-15 2020SolarWinds notifies shareholders/customers and releases software fix

SUNSPOT - The Internal SolarWinds Implant

SUNSPOT is the specialized malware utilized by APT29 tracked under the StellarParticle activity cluster that compromised the Orion software build process. Its purpose was to discreetly insert the SUNBURST backdoor into the software builds of the Orion IT management product, where the SUNSPOT malware operated on an automated, routine process that monitored system processes, manipulated source-code files on the go, all while evading developer detection through graceful termination and other sophisticated methods.

It was first identified on a disk as an executable file named taskhostsvc.exe. The file was likely compiled on February 20 2020 based on forensic analysis. To guarantee persistence, the APT29 operators configured a scheduled task set to execute the malicious file automatically at boot time according to CrowdStrike. Upon boot, the malware creates a mutex to manage its running instances and creates an encrypted log file at C:\Windows\Temp mware-vmdmp.log to masquerade as a legitimate VMware log file. It modifies its own security token to grant itself SeDebugPrivilege, allowing it to read the virtual memory of running processes. This privilege allows the malware to enter a continuous monitoring loop that executes every second, scanning for instances of the MsBuild.exe process, which is a normal Visual Studio development component. This attempts to intercept and modify the target source code files before they’re read by the compiler. When the instance is spotted, SUNSPOT spawns a new thread to check if Orion is undergoing a build operation. It extracts each MsBuild.exe process’s command-line arguments from virtual memory by calling NtQueryInformationProcess, which returns a pointer to the remote process’s Process Environment Block which contains a pointer to the _RTL_USER_PROCESS_PARAMETERS structure. These parameters allow SUNSPOT to locate the directory path of the Orion software Visual Studio solution, a configuration value hardcoded in the binary via AES128-CBC encryption using non-unique keys and initialization vectors which mirror popular video games to make static detection impractical for anybody trying to detect SUNSPOT. After locating the path, it replaces a target source code file with a malicious one, (the only identified copy has been InventoryManager.cs), effectively inserting SUNBURST while Orion is being built. After this, an entry is appended to the vmware-vmdmp.log file with a timestamp of the backdoor attempt and waits for MsBuild.exe to exit before restoring the source code and deleting the temporary backup InventoryManager.bk file. To avoid causing build failures that could have developers accidentally detect the presence of the malware, SUNSPOT made sure to cross check MD5 hashes of the original source code and the malicious version of the code. Finally, the malware continuously checks for a second, non-existing mutex, providing a guardrail that allows it to finish active injection threads and exit gracefully rather than killing the process abruptly and triggering a developer investigation.

SUNBURST

SUNBURST represents the actual malicious backdoor code injected into the Orion software by the SUNSPOT implant. It is the trojanized version of the SolarWinds Orion plug-in framework.

Threat actors established initial development environment access in September 2019, introduced early non-malicious test modifications in October 2019 to validate their injection capabilities, and deployed the fully weaponized SUNBURST backdoor into official Orion releases on February 20, 2020. Compromised updates were distributed to customers on March 26, 2020, affecting versions 2019.4 HF 5, 2020.2, and 2020.2 HF 1. To preserve long-term presence, operators purged the malware from build systems on June 4, 2020 after establishing footholds into victim networks, leaving the SolarWinds compromise unnoticed until December 12, 2020.

Since the injection of SUNBURST occurred dynamically during the automated build process, the malicious library file was digitally signed with a legitimate SolarWinds code-signing certificate on March 24, 2020. This allowed it to bypass early detection and bypass standard code-integrity verification checks. After laying low for an initial period of 2 weeks, the backdoor would retrieve and execute commands. This delay allowed the malware to appear disconnected from the initial installation timestamp, confusing any automated analysis tools. Furthermore, StellarParticle operators randomized their behaviors post-dormancy. This helped them evade traditional signature-based identification methods like scanning for static indicators of compromise.

The malicious backdoor communicated via HTTP to C2 servers, and was embedded inside a core library file component known as SolarWinds.Orion.Core.BusinessLayer.dll. After installation, the Orion software framework executes the .NET program SolarWinds.BusinessLayerHost.exe to load both normal plugins as well as the malicious dll file. The dll plugin contains legitimate and standard namespaces and classes–but this is where the SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer class resides, which has an HTTP backdoor. By using the Domain Generation Algorithm (DGA), the backdoor would randomly generate subdomains pointing to avsvmcloud[.]com. When communication was established, the backdoor utilized standard HTTP web protocols and application-layer DNS queries to interact with its external C2 servers, blending malicious traffic smoothly into legitimate enterprise network patterns.

Cobalt Strike Droppers

Though StellarParticle established a foothold across thousands of organizations in the United States alone, its operators were highly selective in the secondary stages of their exploitation sense that they focused their attention on highly valuable targets, such as government agencies, Fortune 500, and other IT companies. When operators identified that they had compromised these targets, they would use two Cobalt Strike droppers named TEARDROP and RAINDROP.

TEARDROP

  • Primary Function: A memory-only dropper used to establish the initial foothold immediately after SUNBURST execution.
  • Delivery Method: Deployed directly by the initial SUNBURST backdoor on systems that the threat actors selected for active exploitation.
  • Evasion & Execution: TEARDROP ran strictly in-memory to avoid signature-based disk scanning. It modified the Windows Registry to create a service for itself and used a custom rolling XOR algorithm to decode its payload.
  • Steganography: To obscure the payload, it read from an embedded file constructed with a fake JPG header under the name gracious_truth.jpg.

RAINDROP

  • Primary Function: A closely related sibling to TEARDROP that was a customized Cobalt Strike loader, but was specifically optimized for internal network expansion.
  • Delivery Method: Unlike TEARDROP, RAINDROP was not delivered directly by the SUNBURST backdoor. Instead, it appeared on computers elsewhere in the target network, indicating it was deployed manually during the threat actor’s lateral movement phase.
  • Disguise & Packaging: It was compiled as a Dynamic Link Library (DLL) file built on a modified version of the open-source 7-Zip source code. The legitimate 7-Zip code was purely camouflage designed to deceive static analysis tools.
  • Evasion & Execution: It used a completely different custom packer than TEARDROP. Extracting its payload required a complex chain: executing computational delays to stall automated sandboxes, pulling data from immediate values of machine instructions, decrypting via AES-CBC, and decompressing using the LZMA algorithm.
  • C2 Configuration: While most versions used HTTPS for external communication, some samples discovered on isolated, non-internet-facing machines were specifically configured to route C2 traffic over SMB Named Pipes (\.\pipe\protected_storage) through another compromised machine on the local network.

Other Malware Used

In addition to Cobalt Strike loaders, APT29 placed secondary, sophisticated malware families on victim networks. These implants were introduced as early as mid-2019 to provide independent backup access and deep persistence.

Linux GoldMax

  • Primary Function: A second stage, fully featured C2 backdoor program written in Go with comprehensive C2 capabilities, used after lateral access was secured.
  • Platform Diversity: While Windows versions exist, a specialized Linux variant was actively leveraged within target environments to compromise non-Windows infrastructure. The Linux version was almost identical in functionality and implementation to the previously identified May 2020 Windows variant.
  • Evasion Tactics: GoldMax attempted to blend into enterprise environments by dynamically changing its binary filename to match the specific hostname of the victim system it resided on.
  • Persistence: On Linux machines, it configured itself to automatically restart upon system reboots by planting a specialized @reboot line within the system’s crontab configuration.

TrailBlazer

  • Primary Function: A modular, heavily obfuscated malware family used by APT29 since at least 2019 to maintain a silent secondary presence.
  • Persistence: TrailBlazer is unique in its adaptability. While it targeted multiple OS environments, its Windows-facing components utilized Windows Management Instrumentation (WMI) event subscriptions. This is an uncommon, highly evasive technique especially in 2019 that achieves persistent execution without touching traditional registry run keys.
  • C2 Obfuscation: The malware obfuscated its operations and result codes by generating random identifier strings to confuse security analysts.
  • Traffic Masquerading: To bypass network security gateways, it masqueraded its external C2 traffic as legitimate, everyday HTTP requests pointing to Google Notifications API endpoints.

Post Exploitation: Office 365 & Azure Infrastructure

Once initial access was secured via SUNBURST, the StellarParticle campaign shifted toward enterprise cloud exploitation, with a heavy focus on Microsoft Office 365 (O365) and Azure environments. Rather than relying on sustained malware implants, APT29 pivoted to abusing trusted relationships within victim infrastructure to ensure long-term access. They did this by bypassing MFA through browser cookie theft, Azure AD configuration, credential hopping, and lateral movement.

Conclusion

The SolarWinds attack redefined modern security posture in organizations by demonstrating how traditional security models fail when trusted, administrative software is weaponized against its own users.

Recent campaigns by actors such as TeamPCP and ShinyHunters emphasize this ongoing risk. As of writing, threat intelligence indicates that TeamPCP has compromised internal GitHub source code repositories. Github has just confirmed this, and initial access points to a malicious Visual Studio Code Extension installed on an employee device as being the point of compromise. The fact that TeamPCP has open sourced the infamous Shai-Hulud worm and launched a supply chain compromise competition means that these attacks will only continue to grow, since it gives an incentive for copycat attempts against package libraries.

Mitigating these cascading supply chain risks requires a shift away from implicit trust models to rigorous dependency tracking and inventory, continuous build-pipeline integrity validation, and isolated zero-trust network boundaries for infrastructure management software.

Sources

  • Raindrop: New Malware Discovered in SolarWinds Investigation | SECURITY.COM
  • StellarParticle Campaign: Novel Tactics and Techniques | CrowdStrike
  • SUNSPOT Malware: A Technical Analysis | CrowdStrike
  • SolarWinds Compromise, Campaign C0024 | MITRE ATT&CK®
  • GoldMax, Software S0588 | MITRE ATT&CK®
  • TrailBlazer, Software S0682 | MITRE ATT&CK®
  • SolarWinds Supply Chain Attack Uses SUNBURST Backdoor | Google Cloud Blog
  • New Findings From Our Investigation of SUNBURST - SolarWinds Blog
  • The SolarWinds Attack: A Complete Analysis and the Path Forward
  • SolarWinds Attack: Stages, Implications, and Mitigation Strategies in the Cyber Age Gia Anisa1*, Fitria Widianingsih1 DOI : 10.62123/enigma.v2i1.31