Supply Chain Attack Examples and Tactics, With a Case Study

A supply chain attack compromises a trusted vendor, software component or update channel, so one breach reaches many customers. The best-known example is the SolarWinds Orion backdoor (a build-system compromise). Others include NotPetya (a poisoned update of accounting software), the 2021 Kaseya VSA attack that pushed ransomware to MSP customers and the 2025 Shai-Hulud npm worm. This post lists them in one table, explains the tactics and stages, and ends with a case study and the newest 2026 incidents.

Why Supply Chain Attacks Matter

Supply chain attacks turn trust into the entry point. The attacker does not break into each target. It compromises a vendor, a library or an update channel that many targets already trust. Legitimate updates and signed code then carry the attack for it. This post compares well-known examples, walks through the stages of an attack and analyzes the September 2025 npm campaign. The risk is systemic: one supplier can carry a breach to thousands of customers.

Supply Chain Attack Examples at a Glance

Each row below is one supply chain attack with a public primary source. The layer tells you where the attacker got in: a build system, an update channel, a package registry, a pipeline or a vendor cloud app.

Most of these attacks hit the same weak point: a supplier that customers trust without checking. Third-party risk monitoring watches that trust from the outside, and the free Atlas domain scan shows what your own domain exposes today.

What Is a Supply Chain Attack?

Conceptual Framework

For a short definition, see our supply chain attack definition. A supply chain attack is when an adversary compromises an organization by leveraging that organization’s dependencies on trusted third parties. Rather than breaking directly into the target’s network, adversaries focus their attack on a trusted vendor, service provider, or component of software that the organization implicitly trusts.

Attackers manipulate these external points of entry into trusted systems, such as a development pipeline, a software update mechanism, or a software distribution channel. This lets them insert themselves, inconspicuously, into critical processes. Supply chain attacks represent a shift in thinking about security in general. Security can no longer be limited to the perimeter of one enterprise.

It must extend to the entire ecosystem of partners and suppliers that the enterprise relies on.

Differences from Classic Attacks

Unlike traditional cyberattacks which rely on exploiting vulnerabilities within the target’s own systems, supply chain intrusions utilize trusted relationships as the vehicle for exploiting their target. Traditional attacks often start with phishing emails, brute force attempts, or exploiting unpatched software. Supply chain attacks achieve far greater reach by infecting software updates, open-source libraries, or vendor tools that organizations install without question.

This makes them both more stealthy and more dangerous. All it takes is one compromise at the source for a wide impact across potentially thousands of downstream victims. Many traditional attacks are opportunistic. Supply chain operations, however, are far more strategic and organized. They are typically conducted by well-resourced actors seeking a long-term presence and high-value information.

How Do Attackers Exploit the Digital Supply Chain?

To defend against supply chain attacks, our first need to think like an attacker. Where are the weak points? What trusted processes can be turned into weapons?

Attackers have developed a sophisticated playbook to infiltrate products and services at every stage of their lifecycle. Let’s break down their most common tactics.

Compromising the Software Development Lifecycle (SDLC)

The SDLC the process of creating software is a prime target. By embedding malicious code at the source, attackers ensure their malware is distributed far and wide, often with the legitimate digital signature of the company they hacked.

Figure 1: The Dependency Confusion Attack

Source & Dependency Attacks

Modern software isn’t written from scratch; it’s assembled from hundreds of open-source components. This creates a massive attack surface.

• Malicious Code Injection: An attacker contributes code with a hidden backdoor to a popular open-source project. If it gets past the maintainers, it’s unknowingly adopted by every developer who uses that library.
  • Dependency Confusion: A clever trick where an attacker uploads a malicious public package with the same name as a company’s internal private package. If the build tools are misconfigured, they might pull the malicious public version instead of the trusted internal one.
  • Typosquatting: Simple but effective. Attackers publish malicious packages with names that are common misspellings of popular ones (e.g., python-dateutil vs. python-dateutl). One typo from a developer is all it takes to compromise their system.

Build & Pipeline Infiltration

The build process, where code is compiled and packaged, is a high-value target. A compromise here is invisible in the source code.

• Compromising the Build Server: Attackers gain control of the build environment (like a CI/CD server) and insert malware as the software is being compiled. This is exactly how the devastating SolarWinds attack was carried out.
  • Compiler Attacks: A deeply stealthy, advanced attack where the compiler itself is compromised. The malicious compiler adds a backdoor to programs as it compiles them, making it nearly impossible to detect by reviewing the code.

Distribution & Update Hijacking

Even with secure code and a secure build, the attack can happen at the point of delivery.

• Hijacking Updates: This is one of the most effective vectors. Attackers break into a vendor’s network and inject malware into a legitimate patch. Customers automatically download and install the “update,” giving the attackers privileged access. This was the method used in the destructive NotPetya attack.

Figure 2: Software development lifecycle and associated attacks.

Exploiting the Vendor & Partner Ecosystem

The attack surface extends beyond our code to every third-party partner with access to our systems.

• Targeting Managed Service Providers (MSPs): MSPs often have administrative-level access to hundreds of their customers’ networks. By compromising one MSP, attackers gain the keys to the kingdom for all their clients. In July 2021 a vulnerability in Kaseya VSA, a remote management product, was used to push ransomware to MSPs and their downstream customers, as CISA reported. Watching your vendors this way is the job of vendor risk monitoring, described in our supply chain and vendor risk use case.
  • Hardware and Firmware Tampering: This physical attack involves altering devices somewhere between the factory and the customer. This could mean adding a rogue microchip to a server motherboard or pre-installing spyware on a laptop before it’s delivered.

Figure 3: Supply chain attack compromising updates/services to multiple customers.

Undermining Foundational Trust

The most sophisticated attacks target the very systems designed to ensure digital trust.

• Undermining Code Signing: A digital signature is supposed to prove who published a piece of software and that it hasn’t been tampered with. Attackers can steal a company’s private signing keys. This lets them sign their malware so it appears to be legitimate software from a trusted company like Microsoft or Google.
  • Insider Threats: A disgruntled employee or a compromised contractor with privileged access can intentionally plant vulnerabilities or leak credentials. From a position of trust, they bypass nearly all external security controls.

The battlefield has shifted “left.” Security is no longer just about protecting the final product. The very tools and processes we use to build software have become the primary targets. Attackers are turning our own efficiency into their most effective weapon.

Figure 4: Supply chain attack with malware injected into a legitimate update.

Three Landmark Supply Chain Attack Examples

Three attacks from 2017 to 2021 show three different goals: destruction, espionage and ransomware for profit.

NotPetya (2017): A Wiper Disguised as Ransomware

• The vector: NotPetya was delivered through the update process of M.E.Doc, a Ukrainian tax accounting program. CISA says the attackers had a backdoor in the vendor’s development environment as early as 14 April 2017. The alert covers the events of 27 June 2017.
• The mechanism: The malware encrypted the master boot record and the master file table. Inside a network it moved with PsExec, WMI, EternalBlue and EternalRomance. CISA found no link between the encryption key and the victim ID, so files may be impossible to decrypt even after payment.
• The attribution: In February 2018 the US government publicly attributed NotPetya to the Russian military, as CISA records.
• The lesson: A routine update can carry a destructive payload. Segment networks to contain an outbreak, patch the lateral movement flaws and keep offline backups. Our NotPetya incident page has the full record.

SolarWinds (2020): Espionage Through the Build System

• The vector: SolarWinds told the SEC that the flaw came from a compromise of the Orion build system, not from its source code repository. Affected updates were released between March and June 2020.
• The mechanism: CISA says the malicious DLL was signed by the legitimate SolarWinds code signing certificate. The backdoor is known as SUNBURST. That is why the update looked authentic.
• The impact: SolarWinds believed fewer than 18,000 customers may have installed the affected products. In January 2021 the FBI, CISA, ODNI and NSA said a much smaller number were compromised through follow-on activity, fewer than ten US government agencies at that point. They called it an intelligence gathering effort by an actor likely Russian in origin.
• The lesson: A valid signature does not prove a clean build. Protect the build pipeline and limit what vendor software can reach. See the SolarWinds Orion incident page.

Kaseya VSA (2021): Ransomware at Scale

• The vector: On 2 July 2021 CISA reported a supply chain ransomware attack against Kaseya VSA, an on-premises remote management product used by MSPs.
• The mechanism: Attackers did not need to hack each customer. The trusted management tool delivered the ransomware downstream to the MSPs’ customers.
• The lesson: CISA warned that an MSP compromise can have globally cascading effects. CISA told customers to enforce MFA, keep backups air-gapped from the network and keep MSP accounts out of administrator groups.

What Are the Stages of a Supply Chain Attack?

In a supply chain attack, the attacker’s first target is usually the trusted software provider or its update channel. The following image shows the lifecycle of a typical supply chain attack.

Figure 5: General Flow of a Supply Chain Attack

In a typical supply chain attack, the attacker first injects malicious code into the software provider. This harmful update is then delivered to Managed Service Providers (MSPs) or directly to customer companies through trusted channels. Organizations install this update without suspicion because they receive it from a “trusted” source. The attacker thus gains access to thousands of targets from a single point (the software provider).

To better understand how such operations unfold, the lifecycle can be broken down into several stages. Each stage highlights the attacker’s objectives, techniques, and the defender’s potential blind spots. The following subsections (4.1–4.5) detail these stages.

Initial Access

Initial access is the stage where the attacker infiltrates the target network or system via the supply chain. In supply chain attacks, this usually occurs by compromising a trusted third party or software component. Attackers target a supplier with weak security practices, an open-source library, or an update mechanism to plant malicious code. For example, in the 2020 SolarWinds attack, a trojanized Orion update gave attackers initial access to the customers that installed it. SolarWinds believed fewer than 18,000 customers may have been affected.

Common techniques used at this stage include injecting malicious code into legitimate software updates, adding backdoors to source code, compromising compilation processes, or stealing vendor credentials. Once initial access is successful, the attacker gains a foothold in the target network. From this point, the attacker connects the compromised system to the command and control (C2) infrastructure, preparing to move on to the next stages.

Lateral Movement

Lateral movement refers to the attacker spreading from the system initially compromised to other parts of the network. After gaining initial access, the attacker begins exploring the network and tries to gain additional privileges. The goal is to move horizontally to reach critical systems and valuable data.

For example, the attacker can use the credentials they have obtained to access different servers or cloud services, targeting privileged accounts to elevate their privileges. Common techniques at this stage include compromising authorized accounts, scanning the internal network for vulnerabilities or misconfigurations, and infiltrating other systems using remote management tools.

Furthermore, in supply chain attacks, attackers frequently use a compromised supplier’s VPN or API keys to log into the customer’s network. They then jump to other systems. Evasion tactics also come into play at this stage; attackers hide their tracks, hide behind legitimate software, or encrypt their traffic to avoid detection.

The ultimate goal of the lateral movement phase is to move away from the initial point of entry. This gives the attacker broader access and reach to the most critical assets within the organization. Therefore, successful lateral movement indicates that the attacker has advanced dangerously in the attack lifecycle.

Persistence

The persistence phase involves the attacker’s steps to establish a long-term presence on the target system. The attacker uses various techniques to maintain access gained on the network and create re-entry points. In supply chain attacks, attackers often create backdoors, malware implants, or compromised accounts. These let them stay in the network even if the initial access vector is closed.

For example, in the SolarWinds case, CISA reported activity from at least March 2020, sustained over a long period, with several persistence mechanisms. To ensure persistence, malicious software can add itself to system startup routines, infect the registry or task scheduler, or be designed to resist system security updates.

Advanced threat actors take care to leave alternative access paths even if they are detected. For example, when an attacker realizes they have been exposed, they can re-enter the system through a previously planted web shell or a hidden administrator account. This makes it difficult for security teams to eliminate the threat, allowing the attack to remain active for a long time. Successfully establishing persistence means the attacker has a base of operations within the network. There they can operate at will, which increases the attack’s effectiveness and potential damage.

Data Exfiltration & Impact

In this final stage, the attacker takes steps to achieve their ultimate goals. These goals are typically the theft of confidential or critical data (data exfiltration) and the execution of actions that will be harmful to the organization. The attacker transfers the sensitive data collected in previous stages out of the target network (exfiltration).

For example, information such as confidential customer projects, personal data, intellectual property, or state secrets are sent to servers controlled by the attacker at this stage. This espionage-driven data theft is one of the most common types of impact seen in supply chain attacks. In the SolarWinds attack, US agencies described the campaign as an intelligence gathering effort.

In addition, some attacks aim to directly damage systems during the impact phase. For example, the 2017 NotPetya attack spread through the update channel of M.E.Doc accounting software. It encrypted the boot record and file table, and CISA found that decryption may be impossible even after payment. This is one example of the destructive impact of a supply chain attack. During the impact phase, attackers can place ransomware to encrypt files and demand money, disable infrastructure with denial-of-service attacks, or manipulate systems to carry out sabotage.

In summary, this final stage varies depending on the attacker’s objective. If the goal is cyber espionage, the stolen data is secretly leaked. If the goal is to cause damage or gain financial profit, attacks target the integrity and accessibility of the systems. The events that occur at this stage are often the most visible and destructive for the organization. After achieving their goal, attackers may withdraw, attempting to cover their tracks or preserving persistence mechanisms to attack again in the future.

Case Study: How the Shai-Hulud npm Worm Spread

Background of the Attack

On September 15, 2025, researchers uncovered a new type of supply chain attack targeting the npm ecosystem. Malicious versions of several widely used packages were uploaded. Each contained malicious JavaScript code designed to steal sensitive data and send it to attacker-controlled GitHub repositories named Shai-Hulud. By the time it was identified, more than 100 packages were infected, including the popular @ctrl/tinycolor, as reported by Wiz. CISA later said the worm had compromised more than 500 packages.

Techniques and Tactics Used

In the unpackPackage function, the code downloads the package tarball into a temporary directory. It decompresses and extracts the package tree, including “package.json”. It then prepares the extracted files for modification, such as bumping the version, injecting a postinstall script and adding a malicious “bundle.js”, before repackaging and publishing.

Figure 6: Preparing packages for backdoor injection

Figure 7: Credential harvesting & scanning

Shai-Hulud targets GitHub, AWS, GCP, and npm, using TruffleHog to harvest credentials such as tokens, usernames, and other secrets. Our page on TruffleHog explains that the tool is legitimate software that attackers reuse.

Figure 8: Targeted services

After that, the malware created public GitHub repositories named Shai-Hulud to exfiltrate collected tokens. The collected data are uploaded in Base64 encoded “data.json” file.

Figure 9: Data exfiltration

In some cases it also deployed GitHub Actions workflows or other artifacts that triggered on push events. These sent data to the hxxps://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7 endpoint. The malware also transfers private repositories into public repositories under an attacker-controlled account with a “–migration” suffix and labeling them “Shai-Hulud Migration”

Figure 10: Repository migration to public “Shai-Hulud” repositories

IoCs

46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09

hxxps://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7

Impact

Shai-Hulud is a high impact supply chain incident. Trojanized packages steal environment variables, IMDS credentials, npm/GitHub tokens and other secrets. They exfiltrate these to public “Shai-Hulud” repositories. They then abuse harvested publish rights to automatically republish backdoored releases that propagate across the ecosystem. Operationally, CI runners, developer machines, and service accounts that used the same credentials must be treated as compromised. This requires token revocation, forensic snapshots, and removal or deprecation of malicious releases. Downstream consumers face a high risk that automated updates will pull trojanized code into production.

Latest Supply Chain Attacks in 2026

Three 2026 incidents show how fast the pattern repeats. In March 2026 two malicious Axios versions were published to npm, as CISA reported. On 21 October 2026 LiteLLM said its release pipeline was compromised and version 1.107.0 carried a credential stealer; read our LiteLLM response checklist.

On 21 October 2026 Microsoft linked the ConnectWise cloud app compromise to the actor Storm-0940. See what Microsoft 365 admins should check in our ConnectWise supply chain attack post.

How to Reduce Supply Chain Attack Risk

Start with what you can see. List the vendors and open-source components that touch your build and your data. Pin dependency versions, require phishing-resistant MFA on developer and publishing accounts, and rotate secrets when a package you use is hit. Then watch the vendor side from outside: exposed assets and leaked credentials of your suppliers are early warning signs. Brandefense third-party risk management does this, and our guide on outside-in vendor risk assessment shows the method.

Conclusion and Recommendations

Supply chain attacks have evolved from individual occurrences into a global security threat that undermines the very trust foundations in digital. These attacks undermine the measures organizations have put in place to build, update and maintain their systems. They show an ability to bypass even the most advanced defenses.

The case studies in this report show the range of motivations behind such operations. NotPetya was a destructive campaign. SolarWinds was espionage. The Kaseya attack delivered ransomware. Most recently, the Shai-Hulud campaign has illustrated how quickly malicious code can proliferate, threatening not just individual enterprises but entire sectors of an economy across open-source ecosystems.

Tackling this problem requires more than a set of technical controls; it requires a foundational rebuilding of trust in the digital ecosystem. Organizations must accept that security obligations are linked to every partner, supplier, and dependency in their value chain not just their own. Building resiliency, then, means greater oversight of vendors, careful documentation along the supply chain, and a cultural transition from assumed trust to always checking and verifying.

In tandem with this, effective protection requires cooperation between government, private sector players, and the security research community; no organization can defend successfully alone. Until institutions create supply chain awareness at every level of cybersecurity strategy, we cannot prepare for the next generation of adversaries. Those adversaries are bent on turning efficiency and trust against us.