Threat actors have been targeting the cryptocurrency community hard lately. The ReversingLabs (RL) research team is continuously tracking an ongoing battle in which cybercriminals and other threat actors use a variety of techniques to hijack popular, legitimate crypto packages and steal things from Web3 wallets to crypto funds.
But hijacking open source packages is a challenge. The size of the open-source software (OSS) developer community guarantees that OSS packages that have been tampered with get noticed. That means even campaigns against packages that are successful are likely to be short lived. For example, in December RL wrote about the compromise of the Ultralytics, a widely used AI library on the Python Package Index (PyPI). But that campaign lasted only a few hours, with patched versions of Ultralytics released within a day of the release of the malicious version.
In response, threat actors are developing less-noticeable techniques in the hopes of staying hidden longer. One of the new strategies is to upload packages to popular OSS repositories that are designed to apply malicious “patches” to local versions of legitimate libraries, with the hopes of installing malicious code in an otherwise trusted local library that will escape notice.
RL has seen a number of campaigns that attempt to use this technique in recent weeks. Most recently, a campaign launched on April 1 published a package, pdf-to-office, to the npm package manager that posed as a library for converting PDF format files to Microsoft Office documents. When executed, the package injected malicious code into legitimate, locally-installed crypto wallet software Atomic Wallet and Exodus, overwriting existing, non-malicious files in the process. Effectively, a victim who tried to send crypto funds to another wallet would have the intended destination address swapped out for one belonging to the malicious actor.
This latest campaign looks a lot like the campaign the RL team described in a research post in late March. In that case, researchers identified two malicious npm packages, ethers-provider2 and ethers-providerz — simple downloaders with a malicious payload including a second stage that “patches” the legitimate npm package ethers. The packages installed locally, with a new file containing the malicious payload. That patched file was ultimately used to serve up a reverse shell.
Here’s what the RL research team knows about the pdf-to-office package — and the larger trend of malicious packages patching local software.
Déjà vu all over again
RL first detected the malicious pdf-to-office package shortly after an update to the package was published to npm on April 1. At the time of discovery, the package was still available on npm. It was removed shortly after RL detected it, probably by the author since there was no security-holding package available following its removal. However, a couple of days later, the threat actor published a new version of the package, 1.1.2, designed to look like the first-published version.
The package itself was very simple: a lightweight npm package that posed as “a library for converting PDF files to Office.” First published in March, it had the same functionality in all three versions released in the space of a few weeks in March and April.
The package was initially flagged in RL’s Spectra Assure platform with the help of automated, machine learning (ML) detection algorithms that spotted behaviors associated with previously discovered npm-based malware campaigns and software supply chain attacks. These behaviors are formalized in Threat Hunting (TH) policy TH15502.
Figure 1: List of TH policies in package pdf-to-office@1.0.2
The pdf-to-office package was also flagged as suspicious because one of the files inside was altered using a Javascript Obfuscator. Having files obfuscated doesn’t mean the package is outright malicious, but it does raise some red flags, especially given that the package was very simple and new. While it was promoted as a tool that could convert PDF files to Office format, the code contained in the package didn’t look like it supported that functionality.
Instead, the code inside the main file would run an obfuscated file, pdftodoc.js. It wasn’t hard to deobfuscate it, and it was apparent that the file was malicious.
Figure 2: Malicious payload from pdf-to-office@1.0.2
Specifically, the malicious payload would try to detect the presence of the atomic/resources/app.asar archive inside AppData/Local/Programs directory. If detected, that would indicate that Atomic Wallet is installed on the computer. If the archive was present, the malicious code would overwrite one of its files with a new trojanized version that had the same functionality as the legitimate file. But it switched the outgoing crypto address where funds would be sent with the address of a base64-encoded Web3 wallet belonging to the threat actor. That was the only difference between the legitimate and trojanized file, except that the malicious version of the file was not minified.
Figure 3: The difference between a legitimate and trojanized file
Interestingly, the threat actors focused on specific versions of Atomic Wallet that were installed on the computer, and modified their attack code to adjust which files were overwritten based on the version of Atomic Wallet they encountered. RL researchers know this because the names of the trojanized files installed by the package were a_2_90_6.js and a_2_91_5.js.
That makes sense, because the names of the targeted file are not stable between the two targeted versions of Atomic Wallet: 2.91.5 and 2.90.6. Specifically, the targeted file in version 2.91.5 that needed to be overwritten by a malicious version to successfully redirect funds was dist/electron/vendors.64b69c3b00e2a7914733.js. The targeted file in 2.90.6, on the other hand, was dist/electron/vendors.610db4cad49ffb2ccbfb.js.
To be sure the correct file was overwritten (no matter which version was installed) the threat actor tried to overwrite both files with appropriate trojanized versions of files. After the trojanized files were injected into the legitimate, locally-installed Atomic Wallet, a request was sent to the threat actors’ endpoint hxxp[:]//178[.]156[.]149[.]109/set-install-status containing the location of the home directory.
Figure 4a: Files inside the AtomicWallet@2.91.5 installer
Figure 4b: Files inside the AtomicWallet@2.90.6 installer
Atomic Wallets weren’t the only target of this malicious package, either. RL also detected a malicious payload that tried to inject a trojanized file inside a legitimate, locally-installed Exodus wallet. As with the Atomic Wallet, a key file was targeted for trojanizing: src/app/ui/index.js. And the two latest versions of Exodus were targeted, 25.13.3 and 25.9.2.
As with the attacks on Atomic Wallet, successful trojanization of Exodus Wallet allowed the threat actors to redirect all the funds a victim was trying to send to their wallet.
RL also observed an effort by the malicious actors to cover their tracks and thwart incident-response efforts, or perhaps to simply exfiltrate even more information. For example, the AppData/Roaming/AnyDesk directory in which chat logs for the AnyDesk remote access software are saved and trace files are located, was zipped and sent to hxxp[:]//178[.]156[.]149[.]109/save-anydesk. That suggests attackers are either collecting more data, or taking steps to remove evidence of their activities on compromised hosts, then planning long-term campaigns tailored to avoid detection.
Crypto persistence
The malicious patch attack also showed evidence of persistence. If, by chance, the package pdf-to-office was removed from the computer, the Web3 wallets’ software would remain compromised and continue to channel crypto funds to the attackers’ wallet. The only way to completely remove the malicious trojanized files from the Web3 wallets’ software would be to remove them completely from the computer and re-install them.
As noted in the RL research team's coverage of the attack on the ethers package, the malicious code is injected into locally installed Atomic Wallet and Exodus Wallet instances. As with ethers, the official Atomic Wallet and Exodus Wallet installers available on their respective sites are not affected by this campaign in any way.
Software supply chain risk's scope is growing
As RL noted in its 2025 Software Supply Chain Security Report, the scope of software supply chain risks is growing for both software producers and end-user organizations. Nowhere is that more true than in the cryptocurrency industry, with attacks on cryptocurrency code, applications and infrastructure a major theme in 2024 — and continuing in 2025.
Recent campaigns in which threat actors have been observed trying to patch a legitimate, locally-installed npm package with trojanized code are proof that the threats facing both commercial and open-source software continue to evolve. This demands closer monitoring of changes and modifications to both source code repositories and locally deployed applications.
The frequency and sophistication of software supply chain attacks that target the cryptocurrency industry are also a warning sign of what’s to come in other industries. And they’re more evidence of the need for organizations to improve their ability to monitor for software supply chain threats and attacks.
Since organizations don’t usually pay attention to the software they already use and believe is not malicious, this kind of attack would go unnoticed — possibly for a long time. The most ominous part: The removal of a malicious npm package wouldn’t remove the malicious payload and activity at all.
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's investigation of this malicious software supply chain campaign.
| package_name | version | SHA1 |
| pdf-to-office | 1.0.0 | 92ae8c8317da6dd1660c3decb55be74b1a41f3df |
| pdf-to-office | 1.0.1 | 7172583d31d7b79737b21b0d6f76cf179c60f728 |
| pdf-to-office | 1.0.2 | e8ad87a866b6677ef96de30bd93a455ce7247ffc |
| pdf-to-office | 1.1.2 | 59384e801dcf0299e0e704434c00b0da65550c01 |
Additional IOCs
| IP_address |
| hxxp[:]//178[.]156[.]149[.]109/set-install-status |
| hxxp[:]//178[.]156[.]149[.]109/save-anydesk |
| trojanized_files_SHA1 |
| 6708a1bdf6c7251223152a5008fcb29ef6734a7a |
| 3fdc6451234d74cdfc3d64bf6f1001ba4432b151 |
| d9c14ded8bacbf40f3255d79f831d8344f2e691a |
| bcb0594f7c0b134714060455a3f97b0a8d53954e |
| 15bdc1e9d9cbab7eb3fb3425a71e56601cfaffef |
| 77f38e6aa1eaf95afabed90e13c565418fac9073 |
| dfb3a02b9876c72243cf0249825c7126402f328c |
| 40e47b781100c2295fd945bcb133cc79994e6bea |
| e90738ec6cdf9369e7d6f8b5738220bea11656b6 |
| 2210f9b81dcf251af537fbc93222dd3c453b9806 |
| web3_wallets |
| 18u6Tpa6oN4wyL9i1Ry6Cx3wsLkRd7waom |
| 0x47ee0E81F59Db27F034f4eb10F991230f66f53fA |
| TPfaMQVSpqjjAWMvtEW8kDKtc4nSybkWgF |
| rDX43gCUxcVWHT9jMx27tMTFq7D1E92aY7 |
| 4wGTosRFR86B9XWGpHySUW14TLpK1JP4tVMEtHG2CABP |
| 12xe39N4h4T5qPHSuPQVjg5HM6SVs9hf42 |
| r9xGPPHnfy9nt3RrDaBme2AEZVhE9Jme7r |
| 4x2udMpreSTNjpvLBHF2fVfqqFPX1BAF5a8ycSsF1K8r |
| TCUkBnGfXrNHC156Se45BydLMb2Y1NgLuY |
