In the last few months, ReversingLabs (RL) researchers have encountered multiple malicious packages that target cryptocurrency users and developers. In May, RL researcher Karlo Zanki wrote a blog about malicious PyPI packages that targets developers in the Solana ecosystem. Another RL researcher, Lucija Valentić, wrote about malicious npm packages that steal crypto funds from wallets by injecting code into local, legitimate packages. Those are notable incidents.
Every day the RL research team detects packages like simple infostealers, backdoors or downloaders that have been published to open source repositories. Most of the time these packages mimic legitimate open source packages with similar names (attacks known as “typosquatting”). Or they publish new modules that reproduce code and functionality from existing, legitimate packages, but add subtle, malicious features that are easily overlooked by rushed developers. In each case, attackers are counting on unsuspecting developers downloading their malicious packages in order to run their payload.
But mimicking legitimate packages isn’t the only form of software supply chain attack. The hacks of SolarWinds Orion, 3CX’s DesktopApp, and the malicious compromise of the widely used open source compression tool XZ Utils, are examples of more sophisticated supply chain compromises that involve development pipelines of trusted commercial and open-source projects and result in unsanctioned code tampering or the insertion of malicious code into trusted code bases.
This type of supply chain attack is less common, but it is more effective than simple typosquatting attacks. If successful, these attacks can impact hundreds or thousands of end user organizations with serious consequences.
It is this kind of attack that RL researchers identified when we detected the compromise of ETHcode, a legitimate VS Code extension, via a GitHub pull request (PR).
[ Learn more in this RL research Webinar: Unmasking a VS Code Supply Chain Attack ]
A background in blockchain
ETHcode is a VS Code extension developed and maintained by 7finney, a small GitHub organization that develops tools related to the Ethereum blockchain platform. First published in 2022, ETHcode has nearly 6,000 user installs to date.
Image 1: Extension as shown on the marketplace
Understanding VS Code extensions
VS Code extensions follow a similar structure to npm packages. Under the hood, they are zip archives that anyone can access and view the code they contain directly. But more often than not, users install extensions straight from the VS Code marketplace, without ever reviewing the code they contain. And while Visual Studio Marketplace employs several mechanisms to protect its users from malicious extensions, they are not perfect.
Since it was first released in 2022, the ETHcode extension has enabled Ethereum developers to streamline their smart-contract development by providing a set of dev-tools which can be used to test, debug and deploy smart contracts and decentralized applications across all EVM based blockchains. It has been actively maintained, receiving updates semi-frequently (each month on average) through September 6, 2024, when it received its last (non-malicious) update.
ETHcode pull request: Too good to be true
That is until June 17, when a user named Airez299 opened up a GitHub PR with the message “Modernize codebase with viem integration and testing framework.”
Image 2: GitHub pull request comments
The Airez299 account claimed to have added new features and capabilities, removed old configurations and dependencies and updated other elements of ETHcode. At face value, that looked like a really helpful PR, especially for a project that was dormant for more than six months.
Following the PR, one of the members from the 7finney organization reviewed the code. It was also scanned by GitHub’s copilot AI reviewer. Together, those reviewers requested some minor changes, but otherwise found nothing suspicious in the code. That is not surprising. At first look, Airez299’s pull request didn’t actually add malicious code to the ETHcode module’s codebase. The changes are mostly fixes and updates for the existing code. However, amongst the 43 commits and about 4,000 lines changed, there were two lines of code that, together, would compromise the entire project and the corresponding VS Code extension.
Obfuscated code updates reveal malicious dependencies
Looking more closely at those two lines of code revealed a sophisticated supply chain compromise. The first of the two, suspicious lines of code introduced in the pull request that compromised the ETHcode project contained a call to a new file dependency named “keythereum-utils.”
Image 3: The newly introduced dependency
This dependency was carefully named to raise as little suspicion as possible. Since the package keythereum was used as a dependency before; the threat actors named their package similarly, adding only the -utils suffix.
At first glance, keythereum-utils just looks like a helper library — one that is needed for the original keythereum to work properly. Without downloading and closely examining the code in the new package dependency, no one would be able to know what it actually does.
Introducing a new dependency isn’t the same as executing malicious code. If that dependency isn’t invoked in any post- or pre-install scripts, it just sits there: dormant and waiting for someone or something to invoke it. That’s where the second line of code comes into play.
Image 4: Invoking the dependency
This line is simple. It invokes the Node.js' “require” function that loads a module and executes initialization code. In this case, the “require” function opens up the application equivalent of Pandora's Box, letting the malicious script run.
When we turned our attention to the keythereum-utils code, we found it to be heavily obfuscated and unreadable. There are glimpses of interesting strings, but without clearing up the code, we can’t really know what it’s doing. Fortunately, there are free tools that can deobfuscate the code.
Image 5: Deobfuscated JavaScript code
After deobfuscating the keythereum-utils code, it became easy to see what the script does: spawn a hidden Powershell that downloads and runs a batch script from a public file-hosting service.
The RL research team is still investigating exactly what this second stage payload does, but given the steady cadence of supply chain attacks on the crypto community, and the nature of the extension under attack, it’s not far fetched to assume that the second stage malware is intended to steal crypto assets stored on the victim's machine or, alternatively, compromise the Ethereum contracts under development by users of the extension. New information regarding the second-stage payload will be added to this blog post when it’s available.
RL researchers contacted Microsoft's Visual Studio Marketplace admins about this discovery, and as of June 26, the entire extension had been removed from the marketplace. In the meantime, the extension author at 7finney issued a fix to the extension that removes the malicious code from the code base. ETHcode version, 0.5.1, published on July 1st, does not include the malicious dependency and is available on the VS Code Marketplace.
Analysis is ongoing
RL’s analysis of this malicious campaign is ongoing, and updates will continue to be shared with the community via the RL Blog. However, there are already a number of clear lessons to be drawn from what we already know about the ETHcode compromise, and questions that still need to be answered:
Mind the package.json
A key to understanding VS Code extensions is package.json, a manifest file that holds all the important information about the extension. The VS Code package.json is based on npm’s file of the same name. It contains information like the extension’s display name, version and publisher name.
The package.json file also holds information about what dependencies are used in the extension, so that when the user installs an extension, it will install them locally to the node_modules folder (similar to running “npm install”). It was via the package.json file that we observed that the new ETHcode “keythereum-utils” dependency was subtly introduced in the pull request. Our research team then confirmed that the new dependency correlated with the first line of code that compromised this project.
Who is Airez299?
Who is behind this malicious campaign? The GitHub account Airez299 that initiated the ETHcode pull request was created on the same day as the PR request was opened. Accordingly, the Airez299 account does not have any previous history or activity associated with it. This strongly indicates that this is a throw-away account that was created solely for the purpose of infecting this repo — a goal in which they were successful.
Comparing extension versions is key
By scanning the latest version of the extension with its previous, uncompromised version using RL’s Spectra Assure platform, the analysis gave the research team a detailed view of what components are present in the software, and if anything is out of the ordinary.
The platform also allows for easy comparison between the two versions, which can be seen in the version diff section. This makes it clear that, post PR, the package has started using code obfuscated by JavaScript Obfuscator — a frequently seen “red flag.”
It’s also worth noting that this package was tagged by Spectra Assure's predictive threat hunting models even before a detailed look by analysts, due to having files with similar behaviors to malicious packages published on npm. This code appears as a part of the extension package and not as a part of the GitHub repo, as the malicious dependency was shipped with the .vsix file inside the node_modules folder.
Image 6: Spectra Assure diff showing new behaviours
Implications for Developers using VS Code
Unlike some of the other malicious packages that rely on impersonation and typosquatting, this extension was legitimate, commonly used and trusted by developers. The compromise of the ETHcode extension was also aided by the fact that the VS Code platform automatically updates extensions, as RL researcher Karlo Zanki already mentioned in one of his blog posts, unless developers explicitly turn off auto updates in the settings. That means — with nearly 6000 installs — ETHcode has potentially spread this malware to thousands of developer systems that make up its userbase. Not knowing yet what the second stage payload does, this campaign has the potential to infect even more systems depending on the lateral movement capabilities of the further payload stages.
It only took two lines of code...
No one is immune to being targeted by threat actors. As this incident proves, even legitimate software modules can be compromised by shadowy developer accounts and just a few subtle changes to a trusted code base — two lines of code in this case.
Without a careful review of all software dependencies, modern software development workflows are easy targets for supply chain attacks, as this incident shows.
How could this compromise have been avoided? Here are a few, simple steps that developers and development teams can take to reduce the likelihood of successful compromise of their software supply chain:
- Manually verify the identity and history of contributors: Always check the GitHub profile of users submitting pull requests. Brand new accounts are easy to spot — and should raise red flags.
- Review files like package.json to identify and assess newly introduced dependencies. Any new dependency, no matter how trustworthy it seems, should be reviewed manually and checked through services like secure.software to identify any potential risks lurking in the package.
- Use tools like Spectra Assure to help developers track changes and vulnerabilities across software versions, flag malicious behavior and give excellent insight over software.
To help developers and users stay ahead of threats like the compromise of ETHcode, RL recently launched a VS Code community on secure.software. There, you can quickly query suspicious extensions flagged by RL and the community to gain a clearer understanding of what the extension does, and threats or risks that the extension may pose.
IOCs
Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident-response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.
The following IOCs were collected as part of RL's investigation of this malicious software supply chain campaign.
npm
| package_name | version | sha1 |
| keythereum-utils | 1.2.1 | 17802c834861bb983a248234b0a5d17a62fe4474 |
| keythereum-utils | 1.2.2 | 0a9b47d707e167af384403af7c466eb43d46f343 |
| keythereum-utils | 1.2.3 | 442cac64cd5e7783503970c446a1d0d0a0dab69d |
| keythereum-utils | 1.2.4 | 933967db50602a058bd1764c44fc98305866e89e |
| keythereum-utils | 1.2.5 | 351a25bd647587aaf76bd8a303a687bb6ad79f8f |
| keythereum-utils | 1.2.7 | e37adafde5e03001172663256cf3d480e3765b91 |
VS Code
| package_name | version | sha1 |
| 7finney.ethcode | 0.5.0 | 8f93077e8193996fc096de359401a8e9aa6ffc7f |
Learn how to vet your VS Code Plugins with Spectra Assure Community.
