Supply chain cyber attacks on the rise
Over the past several weeks, Asymmetric has responded to multiple supply chain cyber incidents. These attacks can be especially damaging because they compromise what is already trusted, such as known packages, everyday build tools, and routine plugins.
Developers have become prime targets because of how deeply embedded they are in a complex supply chain — pulling packages, running scripts, and executing code from dozens of sources every day. The payoff for an attacker can be large: compromise one developer's machine and inherit access to production credentials, proprietary repositories, secret managers (i.e., tools that store passwords in one place), along with the trust relationships that connect them all.
Drawing on these recent cases, below is a closer look at the techniques being used by attackers and what organizations should do if they suspect a compromise.
How these attacks work
Most modern software is assembled from packages, i.e., reusable code that developers install from public repositories instead of writing it themselves. That reuse saves enormous time. It also creates the attack surface, and that surface is wider than most organizations realize. Threat actors use a range of techniques. Three stand out:
- Typosquatting. Publishing a typosquatted package (e.g., reqeusts instead of requests) to catch hasty installs.
- Package takeover. Taking over a legitimate, widely-used package through stolen credentials or by acquiring an abandoned, unmaintained project.
- Poisoning a transitive dependency. Injecting malicious code into a dependency's dependency (targeting a package the project never directly installed, but that was pulled in automatically through the supply chain).
This is so effective because the payload looks legitimate and originates from a trusted source. And while each attack is designed differently, threat actors generally want one of a few things, such as credentials, persistent access, and SSH keys.
If a compromise is suspected
If there is a concern that a device has been compromised:
- Don't power off the machine.
Keeping the machine running preserves evidence that may be critical to understanding the scope of the attack. A live system gives investigators far more to work with in answering the questions that matter to a client and their legal team. The exception is when continued operation is actively causing harm — ongoing data exfiltration, for example.
- Disconnect the machine from the network.
Isolating a machine from the internet should be done as soon as possible, cutting off any active channels of communication between the threat actor and the compromised device. This prevents the attacker from issuing new instructions, moving laterally or exfiltrating further data.
- Capture a snapshot of the running state.
Once isolated, capture volatile system state before anything changes. This includes running processes, active connections, open files, and recent file modifications. Write the output to an external drive.
- Begin containment.
Immediately revoke every credential the compromised machine could access: API keys, cloud IAM credentials, database passwords, SSH keys. Anything accessible from the machine should be treated as potentially known to the attacker. Pull all logs covering the window of potential compromise, and rapidly engage an incident response provider.
The larger lesson
Supply chain attacks succeed partly because of misplaced trust in familiar channels, and partly because response is slow.
A layered defense makes the biggest difference, as no single control catches everything. Pin dependencies and verify their hashes; apply least privilege to everything, including the development environment; keep a clear picture of what the toolchain does and why.
When something goes wrong, responding fast is critical. If you suspect an incident, reach out to our team.