Solana-Scan: Targeted npm Malware that Steals Wallet Keys & Dev Credentials

Security researchers have uncovered a targeted supply‑chain campaign — dubbed “Solana‑Scan” — in which malicious npm packages masquerading as Solana SDK utilities are being used to harvest developer credentials, wallet keyfiles and other high‑value artifacts from developer machines. (theregister.com)

Background / Overview​

The JavaScript/npm ecosystem has long been a favored vector for supply‑chain attacks because package installs run arbitrary install‑time code with developer privileges. Recent months have seen multiple waves of Solana‑themed typosquats and backdoored libraries that specifically target blockchain developers and their local signing material; the Solana‑Scan cluster is the latest, and it is notable for both its operational focus on Solana developers and its two‑stage, file‑scavenging payload. (socket.dev) (reversinglabs.com)
What makes this campaign striking is the narrowed target profile: the packages were crafted to look like small, legitimate Solana SDK helpers and scanners — tools developers commonly install while prototyping or debugging — then executed a reconnaissance launcher followed by a broad extractor that looks for wallet files, .env files, JSON keypairs and other credential holders. The pattern fits an attack philosophy optimized to hit developer workstations and CI agents where secrets are frequently present. (socket.dev)

---

The lure: malicious npm packages and social engineering​

Packages observed​

• solana-pump-test
• solana-spl-sdk
• solana-pump-sdk (later removed)

These package names intentionally mirror Solana terminology (SPL, pump/trading helpers) to gain quick trust among crypto developers. Multiple vendor and community reports reproduced these package names and flagged them as malicious. (theregister.com)

Publisher alias and registry signals​

Researchers observed the packages published under a threat handle that appears as “cryptohan” and tied to an email address used to publish the tarballs. Observers note that adversaries often use plausible‑looking handles or recycled community aliases to create a veneer of legitimacy. Repository readmes and associated GitHub accounts were used to give the packages a semblance of real projects before they were imported into developer environments.

Two‑stage execution model​

The malicious packages implement a two‑stage payload:

• A heavily obfuscated launcher (e.g., universal‑launcher.js) that enumerates the build/runtime environment — usernames, working directories, npm install mode and other metadata. This allows the operator to profile targets and decide whether to push the full payload.
• A second‑stage scavenger that recursively searches common user folders (Documents, Desktop, Downloads, project directories) for files with sensitive extensions (.env, .json, .one, .txt, keypair formats) and patterns resembling mnemonic phrases, base58‑encoded private keys or exchange credentials. Matching files are collected and prepared for exfiltration. (socket.dev)

---

What was stolen and how it was exfiltrated​

Analysts who examined available data report two main objectives of the payload:

• Harvest local wallet key files and serialized wallet exports that can be used to reconstruct signers and drain funds.
• Scrape environment variables, project configuration files and plaintext notes where developers sometimes paste API keys or mnemonics.

Exfiltration was reported to occur to a remote command‑and‑control (C2) endpoint. Some reporting described the C2 serving an HTTP UI that exposed victim files — an unusual operational mistake that allowed researchers to inspect stolen artifacts and estimate victim scope. However, the specific network artifacts (certain C2 IP addresses and exact host fingerprints) are reported in some outlets and not independently confirmed across all public telemetry feeds; those details should be treated as reported but requiring verification before automated blocking or attribution. (theregister.com)
Important context: earlier Solana‑themed npm campaigns (December 2024–January 2025) used a variety of exfiltration channels, including abusing Gmail SMTP and public webhooks to bypass firewall rules. The Solana‑Scan campaign follows this operational lineage but emphasizes targeted file harvesting rather than on‑chain siphoning logic embedded in an SDK. Cross‑referencing these incidents highlights how attackers iterate on tactics against an attractive developer target set. (socket.dev) (sonatype.com)

---

Command‑and‑control and investigators’ visibility — what’s verified and what’s not​

One report noted harvested data visible via a web interface on a server that researchers accessed, and that exposed artifacts clustered around Moscow IP geolocation, prompting speculation about a focused targeting of Russian developers. Another report named an IP address and a Windows Server 2022 host fingerprint, but that mapping has not (yet) been corroborated by multiple independent telemetry sources available publicly. In short:

• The presence of a C2 UI exposing victim data is corroborated by multiple analyses and made the campaign unusually transparent to researchers. (theregister.com)
• The specifics of the hosting (single IP, exact OS fingerprint) currently rest on limited reporting and should be treated with caution until passive DNS, Shodan or vendor telemetry confirm the mapping.

Flagging unverifiable claims like host ownership and exact IP mappings is important because attribution and legal response depend on firm, reproducible network evidence; rushed attribution based solely on one exposed server risks mischaracterizing the operator and the intent.

---

Technical dissection: obfuscation, heuristics and persistence​

Obfuscation and AI artifacts​

Researchers reported heavy JavaScript obfuscation and unusual console diagnostics (including emoji strings) in the launcher code. Some analysts suggested these artifacts might indicate the use of AI‑assisted code generation during development, or simply operator shortcuts; either way, the obfuscation and multi‑file loader design makes static inspection and signature detection far less effective.

File targeting heuristics​

The second‑stage payload uses broad file search and regex heuristics to extract:

• Common environment files (.env, *.json)
• Wallet and keypair file formats (JSON wallet dumps, base58 keys)
• Plaintext notes and code files where mnemonic phrases are sometimes pasted
• Credential formats and exchange login dumps

The heuristics are purpose‑built to find the artifacts developers commonly carry on test machines and CI agents, making developer workstations a high‑value target.

Persistence and evasive behaviors​

Reports indicate the payload attempted to avoid immediate discovery by:

• Running only in certain locales or skipping hostnames that resemble honeypots
• Altering project files to survive naive cleanup (i.e., not fully removed by deleting node_modules)
• Using a staged loader so static SCA tools scanning tarballs might not see the active payload

These tactics fit an adversary aiming for longer dwell time to harvest as many credentials as possible before detection.

---

Indicators of Compromise (IOCs) and verification caveats​

Observed package names and example file artifacts (reported by researchers and reproduced in incident summaries) include:

• NPM package names: solana-pump-test, solana-spl-sdk, solana-pump-sdk.
• Example payload filenames and SHA‑256 checksums reported in some analyses:
• bd93bea65242bc8205728f129c9bbadc694d849a028fc2d771f9ea60a293665c ./index.cjs
• e6f75dbf6d42e4c34b1a267426accd6dfd3ea7773a28e580c10687768fcc3883 ./index.js
• ed5b9c8bfede0668a240e976e65a46e2dd393ef597c7068c1bb842173ae51ebb ./install.cjs
• 233a408bbcd072236d9331792356ed0b59da5a4c51e3ca74f860a4bf1a621c15 ./install.js
• 21a6135067c3f150a4629e4746c8b81c5b41567117eeaf69224a1919077521d9 ./universal-launcher.cjs
  These artifact hashes were reported in some vendor write‑ups and should be cross‑checked with vendor telemetry before automated blocking.

Caution: several public writeups reproduce IOCs and package names, but exact hashes and C2 artifacts vary across reports. Security teams should cross‑reference vendor feeds (Snyk, Socket, ReversingLabs and other authoritative telemetry) before taking blocking or remediation actions based solely on a single blog post. (reversinglabs.com)

---

Why SCA and EDR alone can miss these attacks​

• Postinstall execution: npm packages can run arbitrary JavaScript during install (postinstall hooks). Static SCA that only inspects tarball contents without emulating run‑time behavior can miss payloads that assemble or fetch code dynamically.
• Obfuscation and staged loaders: multi‑stage loaders and heavy obfuscation defeat simple hash‑ or signature‑based checks. Payloads reconstructed at runtime evade static scanning. (reversinglabs.com)
• Trusted exfiltration channels: attackers reuse trusted services (Gmail SMTP, public webhooks, widely allowed HTTPS destinations) to blend with legitimate traffic and avoid perimeter flags. Earlier Solana‑targeting packages abused Gmail SMTP specifically, illustrating this technique. (socket.dev) (sonatype.com)
• Developer privileges: installs frequently run as the active developer user (not a hardened service account), giving the payload direct access to files and local credentials that would be inaccessible under stricter least‑privilege models.

Taken together, these factors explain how a deceptively small package can yield catastrophic results on a developer laptop or CI agent.

---

Practical detection and remediation playbook​

Immediate triage (for any host that installed these or suspicious Solana‑themed packages)

• Treat the host as compromised until proven otherwise. Rotate all secrets that were used or stored on that machine (wallet keys, API keys, SSH keys), and perform rotations from a known‑clean environment.
• Isolate affected machines from the network and preserve forensic artifacts: node_modules, npm cache, package‑lock.json, system logs and a memory snapshot if feasible. Capture the installed tarballs and package.json entries for analysis.
• Search for the listed filenames and any of the reported SHA‑256 checksums before deleting artifacts; preserve copies for vendor triage and law enforcement if necessary.

Short‑to‑medium term mitigations

• Deploy runtime package scanners or sandbox installs that emulate postinstall behavior and flag network calls and file system access patterns. Static tarball scanning is necessary but insufficient.
• Pin dependencies and lock down developer endpoints: use immutable lockfiles, restrict who can add new dev dependencies in shared repos, and run third‑party scripts in ephemeral containers not permitted to access long‑term credentials.
• Integrate SBOMs and continuous SCA with policy gates in CI so changes to dependency trees require explicit review. Consider provenance verification solutions (reproducible rebuild checks) where practical. (reversinglabs.com)

Operational and governance changes

• Limit publish and automation tokens for package registries; enable hardware‑backed 2FA where possible and rotate tokens routinely. Avoid shared long‑lived tokens.
• Maintain a curated allowlist of trusted package maintainers for internal tooling and require multi‑person approvals for adding new dev dependencies to shared images or CI agents.

---

Attribution, geopolitics and the danger of premature conclusions​

Some reporting observed that exposed victim IPs clustered around Moscow, while the C2 hosting appeared (in one account) to be in the United States; this pattern led researchers to hypothesize that the campaign had a targeted focus on Russian developers and even floated the possibility of a state‑linked operation. However, public evidence remains circumstantial: IP geolocation is noisy, exposed IPs can be leased or spoofed, and adversaries routinely use third‑party infrastructure across jurisdictions. Attribution requires multiple independent lines of verifiable telemetry and, ideally, a chain‑of‑custody that links operational artifacts to a specific actor. Until such corroboration is available, treat attribution hypotheses as provisional and prioritize containment and remediation. (theregister.com)

---

How this fits into the wider trend against Solana and developer tooling​

The Solana ecosystem has been repeatedly targeted by supply‑chain abuse over the last 12 months: compromises of @solana/web3.js in December 2024, typosquats that siphoned keys, and packages that abused widely trusted services for exfiltration. The Solana‑Scan cluster continues that trend, but pivots toward highly targeted developer artifact theft rather than always embedding on‑chain theft logic. Together, these incidents reveal an adversary learning: exploit developer convenience and habitual trust in small helper libraries to seed broad compromise. (reversinglabs.com) (socket.dev)

---

Recommendations for Solana developers and Windows‑based developer environments​

• Assume developer machines are high‑value assets: avoid storing long‑term keys, mnemonics or persistent API tokens on the developer desktop. Use hardware wallets, dedicated signers, or isolated ephemeral VMs for signing and key management.
• Harden npm usage: pin transitive dependencies with strict lockfiles, restrict installs on privileged hosts, and inspect package postinstall hooks as part of CI gates. Consider running package installs in ephemeral containerized build agents that never hold long‑term credentials.
• Rotate keys and secrets from known‑good devices if compromise is suspected; automate secret rotation where possible so incidents require minimal manual intervention.
• Use runtime monitoring that looks for unusual file reads of wallet/key files, unexpected outbound HTTP/SMTP to nonstandard destinations, and additions of launcher or postinstall scripts in project roots. Pair endpoint telemetry with network detection rules that flag unusual port 3000/HTTP destinations originating from developer workstations, but validate such rules against vendor threat intelligence before blocking.

---

Critical analysis: strengths of the campaign and defensive gaps​

Notable strengths of the attackers

• Targeted social engineering combined with realistic lures: masquerading as Solana SDK helpers reduces friction for installation.
• Staged runtime behavior: the two‑stage launcher model increases evasion against static SCA and crowdsourced code review.
• Use of trusted exfiltration paths in related campaigns: earlier campaigns’ use of Gmail SMTP and public webhooks shows an operational understanding of enterprise allow‑lists. (socket.dev)

Defensive gaps exposed

• Overreliance on static SCA and hash‑based signatures leaves developer installs vulnerable.
• Weak separation between developer tooling and secret material — developers frequently run untrusted code on hosts that also store keys.
• Sparse publish‑token hygiene and success of social‑engineering against maintainers and small project owners. (reversinglabs.com)

---

Conclusion​

Solana‑Scan is a timely reminder that modern software trust models are fragile: convenience and the habit of trusting small helper packages create a large attack surface for actors seeking high‑value developer secrets. The campaign is technically unspectacular — it scans, collects and exfiltrates — but operationally savvy: staged loaders, plausible package names and developer‑centric heuristics make it exceptionally dangerous.
The best defense combines improved developer hygiene, runtime analysis for install‑time behavior, strict separation of keys from developer machines, and a policy posture that treats third‑party dev dependencies as potentially hostile until validated. Security teams should cross‑reference IOCs reported in blog posts with multiple vendor feeds before enacting wide blocks, preserve forensic artifacts when incidents occur, and assume compromise for any machine that installed suspicious packages until proven clean. (theregister.com)
Indicators, behavioral rules and recommended remediation steps provided in this article are derived from public researcher writeups and vendor analyses; teams should consult their preferred threat intel providers for the latest, verified IOCs and automated blocking signatures before applying any network‑level blocks or legal escalations. (reversinglabs.com)

---

Source: cyberpress.org Crypto Developers Targeted by Malicious npm Packages in Login Credential Heist