How APTs Steal Your Secrets

Key Takeaways

Imagine installing a popular JavaScript library only to find out later that it was stealing your secrets, mining crypto and opening a back door to your machine. This is the reality of software supply chain attacks in the NodeJS ecosystem. And in recent years, malicious or backdoored npm packages have repeatedly been discovered lurking in the registry. Attackers have smuggled malware into widely used open- source packages. Sometimes with obfiscated code or stealthy techniques that make the back doors hard to notice. Other times just by adding tabs so that the code itself is offscreen when you try to read it. So today we'll explore one of these incidents that took place in April 2025, just a few weeks ago at the time I'm recording this. We'll take a look at the infected package, how the malware was discovered, and what it actually does. If you enjoyed the video, then don't forget to like and subscribe, and let's dive in. It's April 2025, and the official XRP Ledger SDK, a core library that powers countless cryptocurrency applications, receives five updates in one go. This library averages 140,000 downloads per week and is a major package in the fintech blockchain developer community. So, what happened here? Iikido Security noticed that five new versions of the package published by the user Mjangid, I'm not sure how to say it, had appeared on npm that did not correspond to any of the releases on the project's GitHub repository. The latest version was 4.2.0, yet npm had versions 4.2.1 through 4.2.4 four published. And this is of course suspicious, a sign of a compromised package. Digging into the code, the Iikido security team found a arguably subtle but definitely dangerous addition in the index.ts file, which lives in the source directory at version 4.2.4. A new function at the end called check validity of seed had appeared. Now, this function wasn't part of the official code, and it kind of sounds like it was supposed to be there, but of course, this function was malicious. So, what did it do exactly? Well, it took a secret as input. And it's worth noting that it was called from a number of places, such as when a wallet was instantiated or simply created, and then sends an HTTP request to a remote server, and in this case, 0x9c.xyz XY Z with the secrets included in the request headers. So essentially whoever published this malicious package had implemented a data exfiltration function. Whenever an application that's using the poisoned library called check validity of seed, the app would then send the user's crypto wallet private key to the attacker's server and this would then enable them to later on empty those users wallets at will. Now, this might actually sound somewhat sophisticated, but let's take a closer look at the function since it's only five or six lines long. So, here we have our dangerous function. And just before we enter the function, we have a single line that says const valid seeds equals new set. And this basically creates a new set which is a unique value store. And here we can see that it's restricted to strings only. And when it starts off, it's going to be empty. So after that, we jump straight into the first line of our function. So we've got export function check validity of seed and then we've got seed colon string. So this declares a function and the name of the function is check validity of seed and it makes it exportable from the module. And then the seed colon string says that the loan argument must be a string. And in XRP wallets, the seed is a secret that essentially lets you spend funds. So this is obviously a little dangerous when we start reading this. After that on line three we've got if valid sees has the seed already then we return. So this is basically a quick check to say hey if we've already seen the seed in the current runtime then bail out of the function. Don't continue. Don't run any of the rest of the following lines. And if the seed is unique, obviously we then hit line four and we've got valid seeds add. So we add the seed into the set. And this means that once again, if we have the same seed and the function runs again, it's going to bail out on line three. In today's digital landscape, practical skills are key. TCM Security Academy offers training that's rooted in realworld application. Learn real world skills from industry experts that will teach you hands-on skills that will prepare you for any cyber challenge. Transform theory into practice atademy.tcm-sack.com. And then next is kind of where it gets interesting. And that is the use of fetch. And basically it's going to send an HTTP request to 0x9c.xyz. Now, I'm not 100% sure why the dot in the domain has square brackets around it. I suspect so that it can slip past kind of simple domain filters, but if it's not that and you know what it is, then let me know down in the comments below. I'd be interested to find out. But we can also see that the HTTP request is going to be a post. So, we can see method is post. And then we've got the headers. So, we've got add-er and then that's where it's passing in the seed. So, it's not exporting the seed via a parameter or via the body. It's actually exporting it or exfiltrating it via this add referral header. And that's kind of interesting because I suspect not all systems will log headers for HTTP requests. And so, this is probably a little bit more stealthy and a little bit more robust than just saying question mark seed equals and then the seed itself. This might be caught by somebody who's working on the blue team quite easily. whereas putting it as a header is a little bit trickier to find. And then of course after that we've just got the closing brace for the function. And that is it. That's our whole dangerous function. And there are plenty more examples of attacks like this happening. Probably the most famous one is the user agent passerjs package that had millions of downloads per week. Back in 2020 or 2021, I forget the exact dates. it was hijacked and started installing malware that stole passwords and mined cryptocurrency. And if you read around, you'll find that these kinds of attacks are not going away and potentially they're also on the rise. So now let's consider why npm packages are being targeted and why malicious packages are becoming more and more common. So first up, the barrier to entry for publishing to npm is actually quite low and of course packages are used by many victims at once. So the potential impact is pretty high. Now in a lot of cases we're seeing hijacked libraries. So that means the security of many packages basically depends on how good the developers or maintainers are at spotting fishing emails or how yolo they are when it comes to downloading malware from the internet. Now to be fair, MFA did start rolling out a number of years back. So this is at least one step to preventing hijacked accounts. But with so many packages and so many maintainers and so many old unmaintained packages that still live that are still available, we're not even going into older ones that simply have glaring vulnerabilities today. It's definitely a tricky situation. So what this all boils down to is that clearly package security as it is today is not going to protect us and our applications from malware. So we as developers, engineers, tech leads, whatever your role might be, need to step it up and take some responsibility, too. Personally, I think we should be leaning more on specialist tools that help us ensure that the packages and dependencies that we're using are safe. And we also need to be a little bit more responsible when it comes to things like package selection. So instead of just installing any old package that looks like it will do the trick. But that's just the basics. Some changes to our processes like pinning specific versions within our lock file. Bumping the versions intentionally and then just before upgrading running something like npm diff to review what's actually being changed is going to have a big impact. This matures our random driveby changes to audited and reviewable events and really only costs a small amount of time per release. And in practice, simple processes like this could stop things like the XRP supply chain attack from ever reaching our pipelines. And that's it for this video. I recommend that you check out the Iikido Security YouTube channel if you want to see some of their other videos on things that they've found. The malware breakdown Lazarus is a particularly good one to start with. And if you want me to cover more recent attacks like this one, then let me know down in the comments below. We have a Discord that you can check out. And of course, we live stream every Wednesday at 12 ET. Catch you next time.