Simulating Supply Chain Attacks in a Corporate Environment
The SolarWinds Orion breach of 2020 changed the cybersecurity landscape forever. Advanced threat actors realized that hacking a highly secured target directly was inefficient. Instead, it was far easier to hack a less secure third-party vendor, inject a backdoor into their software update process, and let the target voluntarily download and install the malware themselves.
This is the terrifying reality of a Supply Chain Attack.
For a Red Team, simulating a supply chain attack is complex. You cannot legally hack your client's third-party software vendor. So, how do you test a corporate environment's resilience against this vector? In this post, we will explore safe, highly effective methodologies for simulating supply chain compromise.
Vector 1: Dependency Confusion (Internal Supply Chain)
Modern applications are built using package managers (like npm for Node.js, pip for Python, or NuGet for .NET). Companies often use internal package registries for their proprietary code, alongside public registries for open-source libraries.
A "Dependency Confusion" attack occurs when a build pipeline is tricked into downloading a malicious package from the public internet instead of the legitimate package from the internal registry.
The Simulation:
The Red Team identifies the names of internal packages the company uses (often leaked in public GitHub repositories or client-side JavaScript). The Red Team then authors a benign, simulated package with the exact same name, but gives it an artificially high version number (e.g., v99.9.9).
They upload this simulated package to the public npm registry. When the victim's automated CI/CD pipeline runs npm install, the package manager sees the public package has a higher version number and pulls it down by default. The Red Team's benign code executes inside the automated build environment, proving the supply chain vulnerability without touching a third party.
Vector 2: CI/CD Pipeline Compromise
Developers are the new Domain Admins. If an attacker can compromise a developer's credentials or access the Continuous Integration/Continuous Deployment (CI/CD) server (like Jenkins, GitLab Actions, or Azure DevOps), they own the supply chain.
The Simulation:
The Red Team focuses their phishing and lateral movement efforts entirely on the engineering teams. Upon gaining access to a Jenkins server or a developer's GitHub token, the Red Team modifies a build script.
Instead of altering the raw source code (which requires peer review), they alter the automated deployment pipeline to inject a benign backdoor directly into the compiled binary just before it gets pushed to the production environment. This tests if the organization has integrity checks and code-signing validation in place after the build phase.
Vector 3: Simulated Vendor Compromise ("Assumed Breach")
If a client specifically wants to test their resilience against a SolarWinds-style attack, the Red Team executes an "Assumed Breach" scenario.
The Simulation:
The organization uses a third-party managed IT service, a cloud-based Endpoint Management tool, or a massive SaaS platform. The Red Team and the Blue Team's management agree to pretend this vendor has been compromised.
The Red Team is intentionally granted a foothold that mimics what a breached vendor would have. For example, they are given access to the internal network from the specific VPN subnet the vendor uses for support, or they are given a set of service account credentials used by the third-party application.
The objective is then to see if the Red Team can pivot from this "trusted" vendor appliance into the core network. This tests network segmentation and Zero Trust principles. If the third-party HVAC monitoring server is compromised, can it RDP into the Domain Controller? If the answer is yes, the supply chain defense has failed.
Conclusion
Supply chain attacks bypass traditional perimeter defenses because they leverage inherent trust. By simulating Dependency Confusion, exploiting CI/CD pipelines, and conducting "Assumed Breach" vendor scenarios, Red Teams can expose systemic trust flaws without violating the law or causing production outages.
Organizations must shift their mindset: trust no software update blindly, verify the integrity of all code pipelines, and aggressively segment third-party appliances from the core network.