SourceCodeRED identified a malicious package deployed on NPM this week.
This package was deployed by an NPM user named Zyrudev and named “arcus-cmd-utils”. The package only contained two files: index.js and package.json.
When this package was scanned by GitHax it identified it as malicious:
What does the package do?
When GitHax identified the package as malicious, I took a closer look.
The first place I looked was the index.js file. In larger packages finding the payload can be difficult to find and you have to inspect a lot of Javascript, etc. But with this package there are only a few files to look at and if any of them are obfuscated, or doing something dodgy, it stands out.
In this case, there was a base64 string encoded in the middle of the relatively tiny index.js file. This base64 value stuck out like a sore thumb.
When base64 decoded, this string gave me another javascript snippet. In that second javascript file, you could clearly see the payload. This new javascript is downloading a .exe file from a public IP address. It then stores that file in /tmp. The first javascript file evals the second which downloads the file:
Okay, but is this malware?
Good question! To find out, I ran the exe file through VirustTotal, which hadn’t seen the file before, which makes sense if it’s new. One vendor marked the .exe as “Suspicious”, but that was it. This is pretty common for new samples, and unfortunately, this is where many researchers stop. They run a sample through VirusTotal, and if it doesn’t say its malicious, they give up, assuming it’s a benign sample. That’s why it’s important to have a deeper context around how the file is working and what’s going on in the Javascript. Clearly, the author was trying to hide the .exe download file in the base64 string, so we can assume that the author is up to no good, right?
Having that important context, I ran the .exe file through one of our sandboxes, which basically executes the malware payload in a safe and controlled sandbox environment to see what it does and what services it talks to on the internet.
Behaviorally, this sample is malicious, with the typical recon, credential stealing and exfiltration components you would expect to see. However, the sandbox we used didn’t have a signature for the file yet. This probably meant that this sample was new.
What does the malware do?
Now that we know the file is malicious let’s look at its behaviour in the sandbox.
This malware appears to be a Windows x86 infostealer that targets the Chrome browser to harvest credentials and session tokens. This sample first tries to figure out what kind of machine it’s running on and where it’s located geographically. This geographic component has become more common over the last ten years as Russian-based malware will usually try not to target systems in Russia. The malware then identifies the CPU and storage of the system. It reads several registry keys but does not appear to modify any keys. Then, it gets to work on looking for credentials and session tokens in Chrome.
When it’s done collecting your data, it exfils all the stolen data to a Discord server and exits.
If you want to check out the full sandbox report you can find it here: https://tria.ge/250124-1k3bxs1paj
Do we know anything about the threat actor?
Well, this NPM package is called “arcus-cmd-utils”. What is “arcus”? This seemed like a good place to start. Let’s look at the package metadata to see if there are any clues:
We can see first that the package was initially created on January 12, 2025. The author was “zyrudev” and their email was “zyrathnetwork@gmail.com”. The package has a description “A utility for CMD operations.”
While researching, I found an offensive security firm in Europe that specializes in pen testing and red-teaming. This seemed like a good lead, as many of the dependency confusion or typo-squatting attacks I see come from security researchers. However, when I contacted the CEO, he assured me that no one on his team had created the package. Further research on my part underscores that this company didn’t create the packages. There are several other products named Arcus including a S3 compatible storage protocol.
I didn’t find any good leads on the other names in the metadata, which is surprising. Typically, we can trace these packages back to a company or individual, but not with this package so far.
Additional packages authored by this threat actor
It turns out that this same threat actor also published two other packages around the same time as arcus-cmd-utils. These two other packages are named arcus-gradient and arcus-gradient-colors. The threat actor removed both packages from NPM around the same time as arcus-cmd-utils, which was flagged as malicious by NPM. We assume this was the threat actor working proactively to remove these additional packages before NPM or researchers like myself found them.
Indicators of Compromise (IOCs)
Based on my research the “arcus-cmd-utils” NPM packages has several IOCs you can look for:
NPM Packages:
arcus-cmd-utils, arcus-gradient, and arcus-gradient-colors
Files:
Iy0xqmfv6DsNdAB.exe – sha256 hash: 2cc2c009340d8c77f3e645ccbffa9194961637e1a11ec75af0557d4a3eb7aaa5
IP addresses:
195.250.29.94
Email addresses:
zyrathnetwork@gmail.com
What can you do?
You can use our indicators of compromise above to hunt for this threat in your environment if you think you might have been affected. In the meantime, NPM has removed this package from the public repository, and some SCA tools have now marked this package as malicious.
Using SCA tools is essential but doesn’t provide coverage for malicious packages, which is ironic, right? SCA protects you from accidental code issues that *might* be a threat, but they don’t protect you from packages that were purposefully designed to be malicious.
