I’m thrilled to sit down with Rupert Marais, our in-house security specialist with deep expertise in endpoint and device security, cybersecurity strategies, and network management. Today, we’re diving into a critical issue in the realm of software supply chain security—a recently discovered flaw in the Visual Studio Code Marketplace that exposes users to significant risks. We’ll explore how attackers exploit deleted extension names, the mechanics of malicious payloads, and the broader implications for trust in open-source repositories. Rupert will also shed light on sophisticated threats in other platforms like npm and PyPI, and share insights on protecting against these evolving dangers.
Can you walk us through the loophole researchers uncovered in the Visual Studio Code Marketplace and how it lets attackers reuse names of deleted extensions?
Certainly. The flaw lies in how the Visual Studio Code Marketplace handles extension names after they’ve been removed. Once an extension is deleted from the repository, its name becomes available for anyone to claim and republish under. This is a big issue because attackers can swoop in and reuse the name of a previously trusted or popular extension, tricking users into downloading what they think is a legitimate tool. Unlike when an author simply unpublishes an extension—where the name remains tied to them—this deletion process completely frees up the name for malicious actors to exploit.
What did researchers find out about malicious extensions like “ahban.shiba” and how they target users?
Researchers identified a series of malicious extensions, including “ahban.shiba” and variants with nearly identical names, that act as downloaders. Once installed, these extensions fetch a PowerShell payload from a remote server. This payload then encrypts files in a specific folder on the victim’s Windows desktop and demands payment in cryptocurrency, specifically Shiba Inu tokens, to a designated wallet. It’s a clear ransomware tactic, and the naming similarities suggest the threat actors are actively refining their approach to evade detection.
Why do you think the ability to reuse extension names poses such a serious security risk?
Reusing extension names is a huge problem because it directly undermines trust. Imagine a widely used, legitimate extension that gets removed for whatever reason—maybe the developer stops maintaining it. An attacker can then publish a malicious version under the exact same name. Users who remember the extension or search for it might install the new version without realizing it’s a fake, especially if they trust the name based on past reputation. This erodes confidence in the Marketplace as a safe ecosystem for developers, making every download a potential gamble.
How does the Visual Studio Code Marketplace’s handling of extension names stack up against other repositories like PyPI?
There’s a notable difference in policy. PyPI, the Python Package Index, has a safeguard where names of packages identified as malicious can be flagged and made unavailable for reuse. This prevents attackers from hijacking known names tied to past threats. The Visual Studio Code Marketplace, however, lacks a similar restriction. I suspect this might be due to differences in how the platforms prioritize user experience versus security, or perhaps a gap in recognizing the full scale of this threat. Without such a policy, it’s open season for attackers to recycle names of deleted extensions.
What insights do the leaked chat logs from threat actors reveal about their strategies with open-source registries?
The leaked chat logs from groups like Black Basta paint a chilling picture. These actors are deliberately targeting open-source registries, including the Visual Studio Code Marketplace, as a vector for distributing ransomware. They’re poisoning these platforms with malicious libraries, banking on the fact that developers and users often trust these ecosystems by default. Their goal is to infect unsuspecting users who install these tainted extensions or packages, then extort them with ransomware demands. It’s a calculated move to exploit the open nature of these repositories.
Can you tell us more about the eight malicious npm packages recently discovered and what they’re designed to do?
These eight npm packages are particularly nasty. They’re crafted to steal sensitive information from Windows users, targeting data like passwords, credit card details, cryptocurrency wallet info, and browser cookies. Once they gather this data, they transmit it to a specific web URL or, as a backup, through a Discord webhook. It’s a sophisticated data theft operation, and the fact that they have fallback mechanisms shows how determined these attackers are to ensure the stolen info reaches them, even if one channel gets blocked.
What makes these npm packages so difficult to spot, and how do they hide their true intentions?
The stealth of these npm packages comes down to their use of multiple layers—up to 70, in fact—of obfuscated code. This means the malicious payload is buried deep under complex, hard-to-read code that unpacks a Python script only at runtime. This level of sophistication helps evade traditional security scans that might not dig through all those layers. For developers and security teams, it’s a growing headache because it raises the bar for detection tools and requires constant vigilance to catch these threats before they cause harm.
What broader takeaways should developers and organizations draw from these kinds of supply chain attacks?
The key lesson here is that open-source repositories, while invaluable, are now prime targets for attackers. Developers and organizations need to adopt a mindset of skepticism—don’t assume anything is safe just because it’s in a trusted marketplace. Implementing rigorous scanning of all software components, maintaining visibility across the supply chain, and using automated tools to detect anomalies are critical steps. Beyond that, fostering a culture of security awareness and educating teams about risks like typosquatting or name reuse can prevent a lot of damage.
Looking ahead, what’s your forecast for the future of software supply chain security in open-source ecosystems?
I think we’re heading toward a more challenging but also more proactive landscape. As attackers continue to exploit open-source platforms with increasingly sophisticated methods, I expect we’ll see stronger policies and tools emerge—think stricter name reservation rules or AI-driven anomaly detection baked into repositories. But the cat-and-mouse game will persist, with threat actors finding new ways to blend in. My hope is that collaboration between platform providers, security researchers, and developers will tighten these ecosystems, though it’ll take sustained effort to stay ahead of the curve.
