Breaking News
Menu

Malicious npm Packages Steal Crypto Wallet Keys via Telegram Bot

Malicious npm Packages Steal Crypto Wallet Keys via Telegram Bot
Advertisement

Table of Contents

Malicious npm packages targeting crypto developers are actively stealing Solana and Ethereum wallet keys by exfiltrating them directly to a Telegram bot. Security researchers at Socket identified five typosquatted libraries that intercept private keys during standard decoding processes, draining developer wallets before any application errors are triggered. The campaign, published by the npm account galedonovan, specifically targets the supply chain of blockchain developers.

The malicious logic is injected directly into the areas where developers handle private keys, ensuring that the broader application behavior appears completely normal. For Solana-focused packages, the code intercepts Base58 decode functions typically used to load keypairs from secret strings. On the Ethereum side, the trojanized package triggers inside the Wallet constructor the moment a private key is passed.

To execute the data theft, the malware relies on the global fetch API without explicitly importing it. This means the exfiltration only works successfully on Node.js 18 and newer runtimes. On older versions, the code throws a ReferenceError that is silently caught, causing the theft to fail without alerting the developer.

The Telegram Command and Control Network

All stolen plaintext keys are funneled to a single Telegram Bot API endpoint using a hardcoded bot token and chat ID. The bot, operating under the handle @Test20131_Bot, posts the compromised credentials into a small private Telegram group named My_Bot_Test. The creator of this group uses the handle @crypto_sol3, providing a direct attribution link to the threat actor.

Because there is no secondary staging server, the entire exfiltration channel remains operational only as long as the Telegram bot is active. Socket has submitted takedown requests for the associated npm account, but at the time of the initial analysis, four of the packages remained available in the public registry.

Breakdown of the Compromised Packages

The campaign consists of five distinct packages, each employing different tactics to hide its payload and execute the theft:

  • raydium-bs58: Re-exports the legitimate bs58 library with a wrapper that sends the input key to Telegram first. The developer accidentally left a comment in the published code containing the full bot token and group invite URL.
  • base-x-64: Embeds an obfuscated payload using an array-rotation cipher and a checksum loop to hide the Telegram URL and bot token before executing the POST request.
  • bs58-basic: Contains no direct malicious code but depends entirely on the base-x-64 package, triggering the exfiltration transitively.
  • ethersproject-wallet: Clones the real @ethersproject/wallet release verbatim but injects a single malicious line into the compiled CJS output. Its error handler leaves a visible console log reading "Error sending message to Telegram:".
  • base_xd: Published and unpublished within five minutes, this package used the exact same obfuscation pattern as base-x-64 and served as the original template for the campaign.

Security analysts linked all five packages to a single developer workflow due to shared typos across the configuration files. These included the misspelling "crytography" and the inclusion of a flawed terminal command:

git diff --exidt-code

My Take

The reliance on Telegram as a Command and Control (C2) infrastructure highlights a growing trend among low-to-mid-tier threat actors who prioritize immediate deployment over operational security. While Telegram offers a free, encrypted, and highly reliable exfiltration channel, hardcoding bot tokens directly into npm packages is a massive forensic vulnerability. The fact that the raydium-bs58 developer accidentally left the group invite URL in the code comments shows a rushed execution, yet the attack still successfully bypassed initial registry filters.

What makes this campaign particularly dangerous is its nuanced understanding of modern JavaScript environments. By injecting the malicious payload exclusively into the compiled CJS output of the ethersproject-wallet package while leaving the ESM build clean, the attacker created a forensic artifact that is easily missed during casual code reviews. Furthermore, relying on the native fetch API to target Node.js 18+ environments demonstrates a deliberate choice to minimize imported dependencies, which often trigger automated security alerts.

For crypto developers, this incident reinforces the critical need to audit transitive dependencies and avoid blindly trusting thin wrapper packages that re-export cryptographic primitives. Any developer who installed these specific packages must assume their keys are compromised, immediately rotate their credentials, and migrate back to the official scoped packages. Security teams should treat any obfuscation in key-handling utilities as an immediate, high-risk red flag.

Sources: gbhackers.com ↗
Did you like this article?
Advertisement

Popular Searches