Chaos, shock, private keys from a not-so-private GitLab 💻

Over the past couple of months, the attacker has been distributing trojans from several npm accounts: alex05255, mdrafiqulislamrabby, b.w1001, abdev8773, and mollspotwood54400.

List of packages:

🌟 svg-fetcher

🌟 tradepilot

🌟 polytrade

🌟 polymarket-kit

🌟 react-svg-chunk

🌟 gamified-trading-system

🌟 font-huge

🌟 font-hub

🌟 mdb-vite

🌟 router-processor

🌟 route-processor

The code, as is typical of the genre, is vibe-coded. This is indicated by the excessive explanatory comments:

Package logic

🔗 Concatenation of the C2 URL from several constants.

🔗 Request for the next stage. Of note:

🌟The payload is versioned and referred to in the code as token. We know of stages 106, 107, 108, and 116.

Final URL: http://svganchordev.net/icons/<token>

🌟 The code passes the header key bearrtoken (spelling preserved, the author probably meant bearertoken) with the value logo.

The second stage is represented by heavily obfuscated one-liner JS code:

The stage collects system information — username, computer name, operating system — and continues communicating via a web socket, receiving commands for execution.

The implementation is solid, with multi-stages, no argument there. But it’s still malicious activity, so we’re reporting the packages to the NPM admins 🫥

The releases with tokens 106 and 116 have a twist, namely embedded GitLab public and private keys:

We can’t use these keys: they belong to a private GitLab instance deployed in the attacker’s infrastructure.

However, it’s interesting that the campaign is conducted at such a serious level that the attacker needed code versioning, even though Git could have been used locally. One can assume that a CI/CD pipeline is set up in GitLab for obfuscating code and publishing stages.

Want to automatically check whether these and other malicious packages have made it into your environment? Go here: secure development feeds from PT Fusion.

#npm #scs

@ptescalator