A targeted supply-chain attack infiltrating the npm registry has been quietly siphoning cryptocurrency wallet keys, API tokens, and sensitive configuration files from developer machines. Dubbed SolanaScan, the campaign uses three malicious packages—solana-pump-test, solana-spl-sdk, and solana-pump-sdk—crafted to mimic legitimate Solana blockchain development tools. Security researchers confirmed the packages were published under the handle “cryptohan” and designed to prey on the trust developers place in small helper libraries.
Once installed, the packages trigger a stealthy two-stage payload that first profiles the victim’s environment, then recursively scavenges common folders for wallet keypairs, .env files, and plaintext notes containing mnemonic phrases. The exfiltrated data is sent to a remote command-and-control (C2) server, which in an operational blunder exposed victim files via a web interface—giving researchers unprecedented visibility into the attack.
The campaign is the latest in a string of supply-chain assaults against the Solana ecosystem, following the December 2024 compromise of @solana/web3.js and a wave of typosquatted packages abusing Gmail SMTP for data theft. But SolanaScan stands out for its surgical focus on developer workstations and continuous integration (CI) agents, where high-value secrets are frequently stored in plain sight.
The Lure: Fake Solana Packages on npm
The attackers banked on the very habits that make modern development efficient: installing small, single-purpose utilities from npm. The packages solana-pump-test, solana-spl-sdk, and solana-pump-sdk (the latter later removed) were uploaded with plausible-sounding names reflective of real Solana terminology—SPL for the Solana Program Library, “pump” for popular trading tools.
Each package came with a repository README and a GitHub presence, lending a veneer of legitimacy. The publisher handle “cryptohan” and an associated email address were used to push the tarballs, likely recycled or spoofed to deceive casual inspection. For a developer prototyping a Solana dApp or debugging a trading bot, running npm install solana-pump-test would feel routine—and that’s exactly where the trap snapped shut.
Two-Stage Payload: Recon then Loot
After installation, the malicious code springs to life through npm’s postinstall hooks, a feature that automatically executes scripts when a package is added. The first stage—a heavily obfuscated launcher like universal-launcher.js—collects metadata about the host: username, working directory, npm install mode, and other environmental clues. This reconnaissance allows the operators to determine whether the target is worth hitting with the full payload, potentially avoiding honeypots or sandboxes.
Once greenlit, the second stage deploys a broad file scavenger. It recursively searches directories commonly found on developer machines—Documents, Desktop, Downloads, as well as project folders—hunting for files with extensions like .env, .json, .txt, and custom wallet keypair formats. The payload also applies regex patterns to extract base58-encoded private keys, mnemonic phrases, and exchange login dumps. Files matching these heuristics are packaged and queued for exfiltration.
Exfiltration and the C2 Web Interface
Stolen data was sent to a remote C2 endpoint. In an unusual tactical mistake, the C2 server hosted an HTTP web interface that made victim files browsable. Researchers who accessed the interface found artifacts from multiple victims, allowing them to gauge the scope and nature of the theft. This unintentional transparency let investigators confirm that wallet keyfiles, API keys, and project configuration files were being harvested at scale.
One report suggested the C2 was hosted on a Windows Server 2022 machine, possibly in the United States, with victim IP addresses clustering around Moscow. However, those specifics remain unverified by multiple independent telemetry sources. The IP geolocation data and OS fingerprint should be treated with caution until passive DNS or Shodan corroboration emerges. What is solidly confirmed: the attacker’s operational security lapse gave defenders a rare window into the campaign’s inner workings.
Obfuscation and Evasion: Hallmarks of a Mature Attack
The launcher code was densely obfuscated, complicating static analysis and signature detection. Analysts reported unusual console diagnostics—emoji strings and odd output—that some theorize could be artifacts of AI-assisted code generation. Regardless of their origin, these features helped the payload slip past traditional security tools.
SolanaScan also employed several evasive maneuvers. It checked locale settings or hostnames to avoid execution on machines that might be honeypots. The payload modified project files in ways that survived a naive rm -rf node_modules, ensuring cleanup didn’t fully eradicate the threat. And by using a staged loader, the campaign ensured that static software composition analysis (SCA) tools scanning the tarball might only see the innocuous first stage, not the fully assembled second stage that activates at runtime.
Why Windows Developer Machines Are at Heightened Risk
The attack explicitly targets directories common to Windows desktop environments—Documents, Downloads, Desktop—where developers often stash wallet keyfiles, .env backups, or text notes containing secrets. On Windows, npm installations typically run with the same user privileges as the active developer, not a hardened service account. This grants the payload unrestricted access to the filesystem and local credential stores.
Many Solana development tutorials encourage storing wallet key JSON files in project directories or user folders. Combined with the fact that Windows’ default behavior often hides file extensions and permits script execution in developer tools, the platform becomes a rich hunting ground for credential-scraping malware.
Defensive Gaps: Why SCA and EDR Fail
Traditional security controls often miss attacks like SolanaScan. Static SCA tools inspect package contents but don’t emulate runtime behavior, so they can’t spot payloads that are assembled or fetched dynamically during installation. Signature-based defenses are easily defeated by the heavy obfuscation and multi-stage delivery.
Moreover, the exfiltration channels mimic legitimate traffic. Earlier Solana-focused campaigns abused Gmail SMTP and public webhooks—services widely allowed in corporate networks. SolanaScan likewise uses common HTTPS paths that blend into normal developer traffic, evading network detection rules. The combination of postinstall execution, obfuscation, and trusted exfiltration makes the attack exceptionally difficult to spot without runtime analysis that monitors file system access and unusual outbound connections.
IOCs and Verification Caveats
Researchers have published several indicators of compromise, but security teams should verify them against multiple threat intelligence feeds before taking action. The confirmed malicious package names are:
- solana-pump-test
- solana-spl-sdk
- solana-pump-sdk
Example payload filenames and SHA-256 hashes include:
bd93bea65242bc8205728f129c9bbadc694d849a028fc2d771f9ea60a293665c./index.cjse6f75dbf6d42e4c34b1a267426accd6dfd3ea7773a28e580c10687768fcc3883./index.jsed5b9c8bfede0668a240e976e65a46e2dd393ef597c7068c1bb842173ae51ebb./install.cjs233a408bbcd072236d9331792356ed0b59da5a4c51e3ca74f860a4bf1a621c15./install.js21a6135067c3f150a4629e4746c8b81c5b41567117eeaf69224a1919077521d9./universal-launcher.cjs
These hashes originate from vendor reports and may not be exhaustive. Cross-reference with Snyk, Socket, ReversingLabs, or your preferred threat intel provider before integrating them into automated blocking rules.
Immediate Triage and Long-Term Hardening
If any machine has installed the named packages, treat it as fully compromised. Rotate all secrets—wallet private keys, API tokens, SSH keys—from a known-clean environment. Isolate the affected system, preserve forensic artifacts (node_modules, npm cache, package-lock.json, logs), and search for the IOCs before deleting anything.
For short-to-medium term defense, deploy runtime package scanners that emulate installs and flag suspicious file reads or network calls. Pin dependencies with strict lockfiles, and enforce policies that require third-party code to run in ephemeral containers without access to long-term credentials. Integrate software bill of materials (SBOM) checks and provenance verification into CI pipelines.
Operationally, mandate hardware-backed 2FA for npm publishing and rotate automation tokens frequently. Maintain a curated allowlist of trusted maintainers for internal tooling, and require multi-person review for any new developer dependencies in shared images or CI agents.
A Broader Pattern of Solana Supply-Chain Attacks
SolanaScan is not an isolated incident. Over the past year, the ecosystem has absorbed multiple blows: the December 2024 hijack of @solana/web3.js injected wallet-draining code, numerous typosquatted packages scooped up private keys, and attackers creatively misused legitimate services to exfiltrate data. These incidents reveal an iterative learning curve. Adversaries are moving from embedding on-chain theft logic inside SDKs to a more flexible, file-harvesting approach that can net a wider variety of secrets.
The common thread is exploitation of developer trust. Solana’s fast-paced tooling culture encourages rapid installation of helper libraries, often without rigorous vetting. Each new wave of attacks proves that this trust is a critical weakness.
Recommendations for Windows-Based Solana Developers
Assume your developer machine is a high-value target. Do not store long-term wallet keys, mnemonics, or persistent API tokens on your desktop. Use hardware wallets, dedicated signers, or isolated ephemeral VMs for any operation involving secrets.
Harden your npm workflow. Pin transitive dependencies with lockfiles, avoid global installs of untrusted packages, and inspect postinstall hooks in any new dependency. Consider running npm installs inside containerized development environments that have no access to your local file system or keys.
Automate secret rotation wherever possible, and monitor your endpoints for unusual file reads—particularly any process accessing wallet keyfiles or .env folders—and unexpected outbound HTTP connections. Pair endpoint monitoring with network detection rules, but validate those rules against threat intelligence before blocking legitimate development tools.
Conclusion
SolanaScan is a technically modest but operationally adept campaign. It doesn’t rely on zero-days or sophisticated exploits; instead, it weaponizes the everyday workflows of blockchain developers. The use of staged payloads, file-scavenging heuristics, and legitimate-looking package names makes it a potent threat, especially for Windows workstations where secrets often linger in plain sight.
The takeaway is clear: the supply chain is a prime attack surface, and developer machines are the new front line. Defenders must move beyond static analysis to runtime behavior monitoring, enforce strong separation between code and credentials, and treat every third-party dependency as potentially hostile until proven otherwise. As the Solana ecosystem continues to grow, so too will the ingenuity of those who seek to exploit it—and the next campaign may not make the same opsec mistake that exposed SolanaScan.