Software Supply Chain Attacks: How Credentials Get Stolen

Software supply chain attacks lead to credential theft by injecting malicious code into a trusted software update or dependency, which then runs with the privileges of the user or service that installs it, allowing attackers to harvest passwords, API keys, and session tokens directly from memory, configuration files, or keystrokes. This happens before any traditional security tool flags the behavior, because the malicious code is signed and distributed through channels the victim already trusts. The attack succeeds by exploiting the chain of trust between developers, build systems, and end users.

What Is a Software Supply Chain Attack?

A software supply chain attack targets the processes and tools used to build, distribute, and update software, rather than attacking the software itself after installation. The goal is to compromise a single upstream component—a library, a build script, an update server, or even a developer’s credentials—and then let that compromise spread to every downstream user who trusts the component. This is different from a direct attack on an organization’s own systems, because the malicious code arrives through a legitimate, expected channel.

Common targets include open-source package repositories (like npm, PyPI, or Maven), proprietary update mechanisms, CI/CD pipelines, and code-signing certificates. Attackers often use typosquatting (registering package names similar to popular ones), dependency confusion (uploading a malicious package with the same name as an internal private package), or compromising a maintainer’s account to publish a poisoned version.

How Credential Theft Happens in These Attacks

Once the malicious code is running inside a trusted application, credential theft can occur through several mechanisms:

• Environment variable harvesting: Many applications store API keys, database passwords, and service account credentials in environment variables. Malicious code can read these directly from the process environment.
• Configuration file scraping: Credentials are often stored in plaintext or lightly obfuscated files like .env, settings.py, web.config, or cloud provider credential files. The malware reads these files and exfiltrates them.
• Memory scraping: Passwords and tokens pass through memory during authentication. Code injected into a process can scan memory for patterns resembling secrets.
• Keystroke logging: If the malicious code runs in a user session, it can log keystrokes to capture passwords as they are typed.
• Token interception: OAuth tokens, session cookies, and cloud provider temporary credentials can be stolen from memory or from token cache files.
• Credential stuffing: Once a password is stolen, attackers often try it against other services, exploiting password reuse.

The critical advantage for the attacker is that this all happens under the guise of legitimate software. The user or system administrator sees a normal update, and the malicious code runs with the same permissions as the legitimate software would have.

Real-World Examples and Their Impact

Several high-profile incidents illustrate how supply chain attacks lead to credential theft:

• SolarWinds Orion (2020): Attackers compromised the build system of SolarWinds and injected malicious code into Orion updates. The backdoor, known as SUNBURST, allowed attackers to impersonate users and steal credentials from compromised networks. The attack affected thousands of organizations, including US government agencies.
• Codecov (2021): Attackers gained access to a script used by Codecov’s bash uploader, modifying it to harvest environment variables (which often contain credentials) from CI/CD pipelines of thousands of customers.
• npm and PyPI package poisoning: Numerous malicious packages have been published with names similar to popular libraries. When developers install them, the packages steal environment variables, SSH keys, and cloud credentials. For example, in 2022, a malicious npm package named node-ipc was found to exfiltrate files from Russian and Belarusian users.
• 3CX supply chain attack (2023): The 3CX desktop app was compromised via a malicious library in its build environment. The malware stole Chrome and Edge browser profiles, which often contain saved passwords and session cookies.

These examples show that the attack vector is not limited to a single type of software or industry. Any organization that uses third-party components or updates is potentially exposed.

Why Traditional Security Tools Often Miss These Attacks

Most security tools focus on detecting malicious behavior at the endpoint or network level. However, supply chain attacks are designed to blend in with legitimate activity. The malicious code is often signed with a valid certificate, communicates over normal HTTPS channels, and runs during a routine update. This makes it difficult for antivirus or EDR (Endpoint Detection and Response) tools to flag it.

Another challenge is that the attack often happens in multiple stages. The initial compromise might be a single credential theft, which then allows lateral movement and further credential harvesting. By the time an anomaly is noticed, the attacker may have already exfiltrated large amounts of data. This is why incident response teams often recommend treating any supply chain compromise as a complete credential reset.

How to Protect Against Credential Theft from Supply Chain Attacks

While no defense is perfect, several practices significantly reduce the risk:

• Use a software bill of materials (SBOM): Maintain a list of all third-party components and versions. This helps you quickly identify if a known compromised component is in use.
• Verify package integrity: Use checksums, signature verification, and lock files to ensure that the package you receive is the one the author published.
• Limit credential scope: Use short-lived credentials, scoped permissions, and separate service accounts for different applications. This minimizes the damage if one credential is stolen.
• Enable multi-factor authentication (MFA): MFA can stop attackers from using stolen passwords, though it is not foolproof against session token theft.
• Monitor for unusual behavior: Look for unexpected outbound connections, new processes, or changes to configuration files. Behavioral analysis can catch some supply chain attacks that static signatures miss.
• Keep dependencies updated: While updates can be a vector, they also contain security patches. The key is to update from official sources and verify the integrity of the update.
• Segment your network: If an attacker compromises one system, segmentation limits their ability to move laterally and steal more credentials.

What to Do If You Suspect a Compromise

If you believe a software supply chain attack has occurred, immediate action is critical:

1. Disconnect affected systems from the network to prevent further exfiltration.
2. Rotate all credentials that may have been exposed, including passwords, API keys, and certificates. Assume the worst-case scenario.
3. Review logs for unusual authentication attempts or data transfers, but be aware that attackers often delete logs.
4. Check for indicators of compromise provided by security researchers or the software vendor.
5. Rebuild affected systems from known-good images, and reinstall software from verified sources.

Frequently Asked Questions

Can a supply chain attack steal credentials without any user interaction?

Yes. If the malicious code runs automatically during an update or as a service, it can harvest credentials without any user clicking a link or entering a password. The code runs with the same privileges as the legitimate software, so it can read environment variables, configuration files, and memory without prompting the user.

Are open-source libraries more dangerous than proprietary software?

Not necessarily. Open-source libraries are more transparent, which can make them easier to audit, but they also have a wider attack surface because anyone can contribute. Proprietary software is harder to inspect, but it is also a smaller target. The risk depends more on how the software is distributed and maintained than on whether it is open source.

How do attackers get credentials from CI/CD pipelines?

CI/CD pipelines often have access to production credentials to deploy applications. Attackers can compromise a dependency used in the build process, and that dependency can read environment variables or secret files that are available to the pipeline. This was the case in the Codecov attack, where a modified script harvested credentials from CI environments.

Does using a password manager protect against supply chain attacks?

Partially. A password manager can prevent keystroke logging from capturing passwords, because the password is auto-filled rather than typed. However, if the malicious code runs in the same session, it could still read the password from memory or from the password manager’s own database if it has been unlocked. It also does not protect against session token theft or environment variable harvesting.

What is the difference between a supply chain attack and a direct phishing attack?

A direct phishing attack targets individuals directly, usually through email or fake websites, to trick them into giving up credentials. A supply chain attack targets the software itself, so the credential theft happens without any user deception. The user trusts the software because it comes from a reputable source, but that source has been compromised.

Can regular users do anything to protect themselves?

Yes. Regular users can reduce their exposure by enabling automatic updates only from official sources, being cautious about installing browser extensions or plugins, using unique passwords for each service, and enabling MFA wherever possible. However, the most effective protections are implemented by the organizations that build and distribute the software.

Related

• SQL vs T-SQL: Key Differences Explained
• How to Flip or Invert a Picture on iPhone
• Can’t Install Microsoft PC Manager? Fixes That Work