Lessons Learned from 2024's Supply Chain Attacks

Earlier this month, Kaspersky’s Alanna Titterington published a blog titled Supply-chain attacks in 2024. The post briefly summarizes 12 incidents that occurred in each month of 2024. Towards the end, there are suggestions on protecting against supply-chain attacks, but they are pretty useless—essentially, they suggest reviewing the code of software dependencies and maintaining SBOMs.

Kaspersky has a separate blog, Trusted relationships: how to prevent supply-chain attacks, but oddly enough, it offers no ways to prevent them. Similar to the other blog, there is a section with vague reactive suggestions for minimizing the risk of an attack.

These articles are written for software consumers, and most preventative supply chain security strategies are tailored for software maintainers and the open-source software ecosystem. So, I don’t blame the authors, but let’s discuss what tools and methods are being developed to prevent these risks!

Table of Contents

• Lifecycle Scripts

• init.py

• Abusing Stolen Credentials

• Reputation Boosts

• Meme: OSI-approved open-source license 🤔

Lifecycle Scripts

In January, malicious npm packages stole SSH keys from hundreds of developers on GitHub. The malware was triggered by a postinstall script that searched for and exfiltrated SSH private keys.

Snyk’s Liran Tal has a blog on this topic, NPM Ignore Scripts Best Practices as Security Mitigation for Malicious Packages, where he suggests disabling scripts by default by setting the ignore-scripts flag to true in your .npmrc file. Additionally, while not npm, in January 2025, pnpm announced v10, where lifecycle scripts are disabled by default for all users!

👋 Lifecycle scripts may have a purpose, but I think, in most cases, they can be avoided. I hope npm eventually disables them by default as well. Full disclosure: I am not an npm ecosystem expert 😅.

init.py

In February, an abandoned PyPI package was being used to distribute NovaSentinel infostealer malware. The original package was legitimate but was dormant, and a malicious PyPI release popped up out of the blue with no changes made to the GitHub repository. The threat actor stripped the package and uploaded a __init__.py file that retrieves a malicious executable from a hardcoded IP address and runs it via os.startfile(). A developer must import the package somewhere in their codebase for this to trigger.

The most significant development is PyPI's improvement in detecting malicious behaviors and responding via takedowns. Check out a recent blog post about their new quarantine feature for more information. In addition, it’s important to note that the malicious changes are not reflected in the GitHub repository for this package, suggesting that the maintainer's PyPI account was compromised. PyPI has released Trusted Publishers to mitigate this risk, which leverages short-lived identity tokens instead of the more susceptible long-lived API token.

👋 People are often surprised by how vendors find so many malicious packages. The reality is that the malware commonly discovered is pretty dumb. Researchers find malware with more sophisticated triggers much less often. So, writing some SAST rules and scanning build scripts can likely spot a lot of malware. Using a sandbox to install or import a package into an empty project can also be effective.

Abusing Stolen Credentials

As was described in the February incident, it’s common for supply chain incidents to occur due to compromised package repository tokens. This often ends with malware being published as a release, but the source code retains its integrity.

👋 I still find it crazy that we don’t verify package metadata for all published releases, but I’m glad we’re now making progress via provenance attestations!

For instance, PyPI now supports digital attestations, publicly verifiable proof that a package comes from a particular source. If the maintainer opts to publish a provenance attestation, consumers can verify the package’s metadata, such as the repository, GitHub workflow, commit hash, etc., that was used to generate the release artifact.

Separately, a backdoor was discovered in the JAVS courtroom video recording software in May. Somehow, a malicious actor replaced the software available via the JAVS official website with a trojanized version containing a malicious fffmpeg.exe binary. JAVS reported that it "did not originate from JAVS or any third party associated with JAVS." The trojanized version was also signed by a different certificate than all legitimate versions 🤷‍♂️, which is another thing we should verify better. 

The LottieFiles compromise involved a compromised long-lived npm token and a malicious release in which at least one person reportedly lost more than $750,000 in Bitcoin.

👋 Seth Larson released a blog post titled "Supply-chain attack analysis: Ultralytics." It discusses the December 2024 incident and how PyPI used provenance to investigate it (and what PyPI is doing about malware in general). I can continue, but you probably understand the value of provenance attestations by now 😅.

Reputation Boosts

In April, malicious Visual Studio projects spread on GitHub. The malicious actor primarily focused on ease of discovery to lure unsuspecting victims into executing malware hidden in Visual Studio projects, using build events (e.g., PreBuildEvent) to execute commands during the project build. The threat actor created repositories with familiar names, abused automation to make commits and issue new releases, and used fake GitHub accounts to get more stars—all methods to make the repositories seem credible. 

Whether it’s a sketchy website or GitHub, you shouldn’t download random stuff from the internet. However, ecosystems have improved on at least one of the risks abused in this scenario, StarJacking. In November 2024, Checkmarx’s Eugene Rojavski shared a blog post on the current status of StarJacking in popular package registries, citing that some ecosystems have opted to hide a package’s stars altogether.

Meme: OSI-approved open-source license 🤔

In August, a malicious actor uploaded a malicious plug-in to the official Pidgin plugin repository. Don’t be surprised that there’s no attempt to detect malware from being uploaded; uploading malware to open-source package repositories is still trivial.

Unrelated to Pidgin, malware can be anywhere. In my opinion, malicious browser extensions are mind-numbingly concerning, yet there’s little to no market for them. Dakota Riley and Drake Sumner recently published a local CLI tool for evaluating an extension’s risk. I’ve previously used tools like crxcavator, but it’s no longer being maintained. Malicious vscode extensions also seem to make an appearance every few months.

I don't know what this is supposed to mean, but following this, they’ve announced that they will only accept third-party plugins with an OSI-approved open-source license. Am I crazy, or is this entirely useless concerning malicious plugins?

Until Next Time! 👋

Hey, you made it to the bottom – thanks for sticking around!

Questions, ideas, or want to chat? Slide into my inbox! 💌

Don’t hesitate to forward if someone could benefit from this.

See you next Monday!
-Kyle

P.S. CramHacks has a Supporter tier! You can upgrade here to support CramHacks and its free weekly content 😃.