Supply chain attacks are the category of attack where the defender’s traditional security perimeter doesn’t help. Instead of breaking in through the front door, the attacker compromises something the defender already trusts: a software update, an open-source library, an MSP’s remote-monitoring tool, a CI/CD pipeline component. The malicious payload arrives with the right signatures, comes through the expected channels, and runs with the privileges the defender granted to the legitimate version. By the time anyone notices, the attacker has had weeks or months to operate inside hundreds of environments.
This is post three in the Red Team Operations series (the five-phase methodology is covered in post two, Red team exercises: the eight engagement shapes and the five-phase playbook ). What follows is how operators simulate supply chain attacks during engagements, the canonical case studies that have happened in the wild, and the defender-side controls (SBOMs, signing, SLSA build provenance, dependency review) that have moved from “nice to have” to “regulatory requirement” since SolarWinds.
Why supply chain attacks work#
The traditional security perimeter assumes the defender can validate what’s coming in. The supply chain bypasses that assumption. The attacker compromises something already trusted, and the trust relationship is the attack surface.
Every modern software stack runs hundreds to thousands of third-party dependencies. A typical enterprise application: 200-500 direct dependencies, expanding to thousands of transitive dependencies, each maintained by someone the application’s developer has never met. Linux distributions ship with tens of thousands of upstream packages, each with its own maintenance status and security posture. SaaS platforms integrate with dozens of other SaaS platforms via API. The aggregate attack surface is “every package, every vendor, every cloud service in the entire transitive chain.”
The attacker’s edge is asymmetric. A successful compromise of a single popular package (event-stream, ua-parser-js, colors.js) can affect millions of downstream installations. A successful compromise of a single MSP can affect every customer the MSP manages. A successful compromise of a single CI/CD vendor (Codecov, CircleCI) can extract secrets from every customer’s build environment. The economic value of compromising one upstream dependency dramatically exceeds the cost of compromising it; this is the dynamic that’s produced an industrial-scale supply chain attack category since roughly 2017.
The case studies operators reference#
The major supply chain attacks of the last decade, with corrected details:
NotPetya (June 2017)#
The Russian GRU’s Unit 74455 (Sandworm / Voodoo Bear) trojanized the M.E.Doc Ukrainian tax accounting software. The malware was distributed through M.E.Doc’s automatic update mechanism on June 27, 2017, hit Ukrainian government and business systems first, then propagated globally via EternalBlue and EternalRomance SMB exploits combined with credential theft (Mimikatz-style LSASS scraping).
NotPetya was technically destructive malware disguised as ransomware: the encryption was irreversible by design. Damages exceeded $10 billion, the largest single cyberattack in dollar terms ever recorded. Maersk, Merck, FedEx (TNT), Mondelez, and Reckitt Benckiser each lost hundreds of millions. The Maersk recovery story (reinstalling Active Directory from a single offline domain controller in Ghana that had survived because of a power outage) is the canonical incident-response case study.
The supply chain lesson: an automatic-update mechanism with software running as SYSTEM is an enormous attack surface. The defenders weren’t compromised by their own security failures; they were compromised by their tax software vendor’s.
CCleaner (August 2017)#
Avast’s CCleaner v5.33.6162 (released August 15, 2017) shipped with a backdoored installer. The first-stage payload, Floxif, was attributed to the Axiom / Winnti / APT17 group (Chinese state-sponsored). Approximately 2.3 million users downloaded the trojaned version. The first stage was followed by ShadowPad, a more sophisticated second-stage RAT, but only for a targeted set of roughly 40 technology companies (Cisco, Intel, Microsoft, Samsung, Sony, VMware, and others) that the attackers wanted deeper access to. Cisco Talos (working with Avast and Morphisec) discovered and disclosed the campaign in September 2017.
The supply chain lesson: a popular consumer utility with hundreds of millions of installations is high-value upstream territory. The attacker can afford to be patient and selective about who they activate against.
SolarWinds / SUNBURST (December 2020)#
The Russian SVR’s APT29 (Cozy Bear / Nobelium / Midnight Blizzard) compromised SolarWinds’ build infrastructure and inserted SUNBURST into the SolarWinds Orion network management product’s SolarWinds.Orion.Core.BusinessLayer.dll. The injector (SUNSPOT) modified the source code during build, after code review but before signing, so the trojanized binary passed SolarWinds’ integrity checks and shipped with valid SolarWinds signing.
Trojanized Orion updates shipped between March and June 2020. Approximately 18,000 organizations installed the malicious update. The attackers then handpicked roughly 100 targets for deeper exploitation, including Microsoft, FireEye/Mandiant (which discovered the attack on December 13, 2020 during investigation of their own breach), and at least 9 U.S. federal agencies (Treasury, Commerce, State, Energy, Justice, Homeland Security, DOD, NIH, NRC).
The disclosure was the inflection point for the supply chain security industry. The U.S. government’s Executive Order 14028 (May 2021) mandated SBOMs, the SLSA framework was started in response, every major enterprise vendor added supply chain attack to their compliance check list. SolarWinds is the canonical post-2020 case study.
Codecov (April 2021)#
A Codecov Bash Uploader script (used in customer CI/CD pipelines to upload code coverage data) was modified on January 31, 2021 to also exfiltrate environment variables to an attacker-controlled IP. Codecov discovered and disclosed the breach on April 15, 2021, meaning the malicious script had been running for over two months.
The exfiltrated environment variables typically contained CI/CD secrets: cloud credentials, API keys, signing keys. Thousands of Codecov customers were affected; HashiCorp publicly disclosed that their Go-binary GPG signing key was among the credentials exposed.
The supply chain lesson: any tool that runs inside a CI/CD pipeline has access to every secret in the build environment. CI/CD compromise is a force multiplier for downstream compromise.
Kaseya VSA (July 2021)#
The REvil ransomware affiliate exploited a chain of vulnerabilities in Kaseya VSA (a remote monitoring and management tool used heavily by MSPs serving small and mid-size businesses) on July 2, 2021. The primary vulnerability was CVE-2021-30116, an authentication bypass. Once REvil had compromised the VSA server, they pushed a malicious “update” to every connected Kaseya agent, which executed ransomware on the endpoints.
Approximately 60 MSPs were directly compromised; estimates of downstream organizations affected range from 1,500 to several thousand. The Coop supermarket chain in Sweden had to close 800 stores. The initial ransom demand was $70 million for a universal decryption tool. The FBI eventually obtained the decryption keys (through means that have never been fully disclosed) and provided them to victims; whether the key obtained was through Bitcoin tracing, infiltration of REvil, or another mechanism is still publicly unclear.
3CX (March 2023)#
The first publicly confirmed cascading supply chain attack: 3CX (a VoIP / unified communications vendor) was compromised because one of its developers had installed a trojanized copy of Trading Technologies’ X_TRADER software on their work machine in 2022. That earlier compromise (also a supply chain attack, also attributed to North Korea’s Labyrinth Chollima / UNC4736 Lazarus subgroup) gave the attackers access to 3CX’s development environment, from which they trojanized the 3CX desktop app installer.
The 3CX trojanized installers were active in late March 2023; the discovery was made by CrowdStrike, SentinelOne, and Sophos almost simultaneously. The 3CX desktop app had over 600,000 organizations using it; the actual second-stage targeting was again selective.
The cascading-attack pattern is what made 3CX significant: even if you’ve vetted your direct vendors, they’re using vendors of their own, and the chain has the same trust problems at every link.
MOVEit Transfer (May 2023)#
CL0P ransomware exploited a zero-day SQL injection (CVE-2023-34362) in Progress Software’s MOVEit Transfer managed file transfer product. Mass exploitation began around May 27-28, 2023; Progress disclosed and patched on May 31. By the time the patch was available, CL0P had compromised over 2,700 organizations, including the BBC, British Airways, the U.S. Department of Energy, the Oregon DMV, the Louisiana DMV, Shell, and many others.
MOVEit’s role in customer environments was as the secure-file-transfer middleman between organizations and their partners, which meant the data CL0P stole was often customer data the MOVEit-running organization had been entrusted with. The attack pattern was “compromise the MFT vendor’s product, exfiltrate every customer’s data through the compromised installations, ransom each customer separately.” Hundreds of millions of records were involved.
CL0P didn’t deploy ransomware in most cases; they used the stolen data as leverage for extortion. This double-extortion pattern (without encryption) had become the dominant ransomware model by 2024.
XZ Utils backdoor (March 2024)#
The closest-call open-source supply chain attack to date. A maintainer using the name “Jia Tan” (with the GitHub username JiaT75) spent approximately two years building trust with the xz-utils maintenance community, gradually taking over more of the project, and eventually inserting a sophisticated backdoor in xz-utils 5.6.0 (February 24, 2024) and 5.6.1 (March 9, 2024). The backdoor used a multi-stage activation that abused the way liblzma was linked into systemd’s OpenSSH integration, allowing remote authentication bypass against SSH on affected systems.
The attack would have hit millions of Linux servers once 5.6.0/5.6.1 reached stable distributions. Andres Freund (a Microsoft engineer working on PostgreSQL) noticed slower SSH login times during routine performance testing on Debian unstable, investigated the cause, and discovered the backdoor on March 29, 2024. The affected versions had only reached bleeding-edge distributions (Fedora Rawhide, Debian unstable, Kali, Tumbleweed); no stable Debian, RHEL, or Ubuntu had shipped the malicious version. Within hours, every distribution had reverted to 5.4.x.
Jia Tan’s identity remains officially unattributed; the sophistication, patience, and operational security suggest nation-state involvement. The attack is the most-studied case in supply chain security since its disclosure and is the canonical reason every major open-source project has tightened its maintainer-onboarding processes since.
Target (2013)#
The Target breach gets cited frequently as a supply chain attack and is genuinely one, though the technical details have been mangled in many retellings. The actual attack chain: attackers phished credentials from Fazio Mechanical Services, a Pennsylvania-based HVAC contractor with vendor portal access to Target’s network for billing and project management. Fazio’s credentials gave the attackers access to Target’s vendor portal, from which they moved laterally to Target’s internal network, then to the POS infrastructure, where they installed memory-scraping malware on the point-of-sale terminals. Approximately 40 million payment card records were stolen between November 27 and December 18, 2013.
The HVAC system itself wasn’t the vulnerability (the “smart thermostat hacked” framing in older posts is wrong); the vendor’s network access plus weak segmentation between vendor-portal-accessible systems and POS infrastructure was the actual issue. This is the same correction made in the spear phishing post and the IPS post ; Target stays a supply chain case study, the technical specifics matter.
Simulating supply chain attacks on engagement#
The five-phase methodology from post two of this series applies; the supply-chain specifics are where each phase has to be scoped differently.
Reconnaissance: mapping the chain#
The first operator-side task is figuring out what the supply chain actually looks like. For a typical enterprise target:
- Vendor inventory. Who are the client’s actual vendors? IT (Microsoft, Google, Adobe, Salesforce), security (CrowdStrike, Splunk), HR (Workday), finance (Oracle, SAP), MSPs (Kaseya, ConnectWise, Datto), CI/CD (GitHub Actions, CircleCI, Jenkins, Codecov), monitoring (Datadog, New Relic, PagerDuty). Most of this is OSINT-recoverable from job postings, vendor case studies, and the client’s own integration disclosures.
- Open-source dependency mapping. SBOMs (Software Bills of Materials) are the canonical artifact. If the client’s SBOMs exist (regulatory requirements have made this increasingly common since 2021), they tell the operator exactly what’s in the build. If they don’t, the operator builds one with
syft,cyclonedx-cli, or by analyzing artifacts directly. - CI/CD attack surface enumeration. What runs in the client’s GitHub Actions / GitLab CI / Jenkins pipelines? Which third-party actions are imported? Where do secrets live?
secret-scanner,gitleaks, andactions-cache-tinjectorare the operator’s standard tools. - Partner and supplier mapping. Beyond software vendors: which organizations have network access to the client’s systems? Auditors, consultants, marketing agencies, payment processors, the cleaning company. Each represents a potential supply chain path.
Weaponization: building the payload#
Supply chain testing usually doesn’t involve weaponizing a real upstream package; the engagement letter would never authorize that. The operator’s actual weaponization work tends to be one of:
- Simulating a typosquatted package. Register a similarly-named npm or PyPI package that the client’s developers might typo-install, with telemetry that calls home if installed. Measure how long until the client’s CI/CD catches it.
- Simulating a compromised dependency. With explicit authorization, push a “malicious” update to a package the client’s CI/CD actually imports; the package phones home to the operator’s infrastructure instead of doing anything destructive.
- Simulating a CI/CD compromise. With the client’s permission, plant a benign-looking GitHub Action in a client-owned repository that demonstrates secrets exfiltration if the client’s pipeline runs it.
- Vendor impersonation. With the engagement letter explicitly authorizing it, spear-phish the client’s developers or DevOps team posing as one of their actual vendors (a renewal notice, a security advisory, a new API key requirement) and measure click-through.
The thing to avoid is any work that touches real third parties without their authorization. If the client’s vendor isn’t in scope on the engagement letter, the vendor’s infrastructure is off-limits regardless of how convenient the attack chain would be.
Delivery: getting into the pipeline#
Supply chain delivery looks different from regular phishing-and-payload-drop:
- Updates as the delivery vehicle. The defender expects updates from the vendor and has automated systems that install them. A simulated compromised-update test (via a client-owned package or container image) verifies whether the client’s pipeline catches the modification.
- CI/CD secret exfiltration. A planted GitHub Action with a step that prints environment variables to a base64-encoded log demonstrates what an actual Codecov-style compromise would have extracted.
- Vendor portal credential theft. Phishing the client’s developers with a fake vendor login page (Atlassian, GitHub, Snyk, Snowflake) demonstrates whether their MFA actually protects vendor accounts. AiTM toolkits like Evilginx work the same way against vendor portals as against M365.
- Container image and dependency confusion. Publishing a package with the same internal name as one of the client’s private packages, hoping their build system pulls from the public registry first. This is the technique Alex Birsan demonstrated against Apple, Microsoft, Tesla, and others in 2021.
Exploitation and post-exploitation#
Once the simulated supply chain compromise lands, the operator’s downstream behavior is largely the same as in any other engagement: lateral movement, privilege escalation, credential theft, data exfiltration. The difference is what the operator can demonstrate about scope:
- What did the simulated compromise have access to? The pipeline secrets, the production database credentials, the cloud account, the signing keys. Document the blast radius.
- How quickly did the defender notice? Did the SIEM catch the unusual outbound connection from the build runner? Did the CSPM catch the unauthorized cloud resource creation? Did the EDR catch the post-compromise tooling?
- What’s the recovery path? If this were real, would the client be able to invalidate the compromised secrets, replace the compromised dependency, restore from a known-good state?
The post-exploitation phase for supply chain testing is more about measuring the defender’s response capability than about achieving maximum compromise.
What the defenders are doing (and what to test)#
The defender controls that have emerged since SolarWinds and that the operator should test for:
- SBOMs (Software Bills of Materials). SPDX and CycloneDX are the dominant formats. U.S. Executive Order 14028 (May 2021) and the EU Cyber Resilience Act both effectively require them. The operator’s question: does the client actually generate and consume them, or do they have a file labeled “SBOM” that’s three months out of date?
- SLSA (Supply-chain Levels for Software Artifacts). Google-originated framework that defines progressive levels of build provenance and source integrity (SLSA 1 through 4). SLSA 3+ requires hermetic, reproducible builds with signed provenance. Few organizations are actually at SLSA 3; the regulatory pressure is moving everyone in that direction.
- Sigstore. Public-good signing infrastructure (cosign, rekor, fulcio) for container images and arbitrary artifacts. Backed by Google, Red Hat, GitHub, the Linux Foundation. The operator’s test is whether the client actually verifies signatures on what they install or just generates them on what they publish.
- Dependency review at PR time. GitHub’s Dependency Review, Renovate, Dependabot, and similar. Catch new dependencies before they merge; flag known-vulnerable versions.
- Vendor risk assessment. TPRM (Third Party Risk Management) platforms (SecurityScorecard, BitSight, UpGuard) for continuous monitoring of vendor security posture.
- Air-gapped build environments. For the highest-criticality builds (signed firmware, OS images, financial software), running the build in an isolated environment that has no internet access except to vetted dependency mirrors.
- Reproducible builds. Same source plus same toolchain produces same binary, byte-for-byte. The defense against SUNSPOT-style build-injection attacks: if the build isn’t reproducible, the build itself is an attack surface.
The honest assessment of the current state in 2026: the defensive frameworks exist, the regulatory pressure is real (CRA in the EU, EO 14028 in the US, various sector-specific requirements), and large enterprises have meaningfully improved their supply chain defenses. The mid-market and small-business segments are still mostly running 2018-era controls. Open-source maintainership remains a single-point-of-failure problem that the XZ incident demonstrated without resolving.
What this comes down to#
Supply chain attacks are the category that has shifted the most in red team work over the past five years. Pre-SolarWinds, supply chain testing was rare on engagement; clients weren’t asking for it and most operators didn’t have the procedures. Post-SolarWinds, post-Kaseya, post-XZ, supply chain testing is increasingly the headline finding in mature engagements, and the defender side has built out a real industry of frameworks, tools, and regulatory requirements.
The operator side of this work requires more legal care than almost any other red team category. The targets are usually third parties; the techniques touch software that other people depend on; the consequences of unauthorized action can cascade well beyond the engagement. Scope this work in writing, name every in-scope vendor explicitly, and refuse to go further than the engagement letter authorizes regardless of how convenient the attack chain would be.
Done well, supply chain testing on engagement demonstrates exactly the risk that the past decade of attacks has made real: the defender’s perimeter doesn’t help when the attacker came in through the trust relationship. Demonstrating that, finding the specific control gaps that would let an attack land, and walking the client through the remediation path is what justifies the work.
