- Targeted supply-chain attack on Atomic and Exodus wallets, according to ReversingLabs
- The malicious npm package pdf-to-office masqueraded as a PDF conversion utility
- When installed, it injected Trojanized JS files into locally installed Atomic Wallet and Exodus
- The malicious code spoofed the destination address when sending funds
- The campaign affected specific versions of the wallets (Atomic 2.90.6 and 2.91.5; Exodus 25.13.3 and 25.9.2)
- Even after removing the pdf-to-office package, the wallets remained compromised
The targeted attack on Atomic and Exodus wallets, according to ReversingLabs, showed yet another example of how secure-focused technologies like blockchain aren’t too easy to hack – attackers look for workarounds.
The attackers used the malicious pdf-to-office npm package, which posed as a PDF conversion. It checked for the Atomic and Exodus wallets on the device and injected malicious code, and in the case of a transaction, spoofed the destination address to the attacker’s wallet.
Critically, removing the npm package itself did not eliminate the threat — the altered files remained active until the wallets were manually reinstalled.
Infection Mechanism Targeting Atomic and Exodus on Local Machines
This was a multi-stage scheme that required a detailed breakdown. The malicious package first appeared on npm in March, but the active malicious functionality was introduced in an update published on April 1 — which turned out to be no joke for affected users.
All versions of the package (1.0.0, 1.0.1, 1.0.2, and 1.1.2) were minimalist JavaScript modules. While the package masqueraded as a PDF-to-Office document conversion utility, it, in fact, performed a completely different function.
Inside the package was an obfuscated file named pdftodoc.js, which deployed a malicious payload targeting already installed instances of Atomic Wallet (and later, Exodus). Technically, the infection relied on local file replacement rather than modifying source code or application installers.
Specifically, the script checked for the presence of the app.asar archive located in %AppData%/Local/Programs/atomic/resources, verified the installed wallet version, and based on the result, injected a corresponding trojanized version of a key JavaScript file.
- For version 2.91.5, it replaced dist/electron/vendors.64b69c3b00e2a7914733.js.
- For version 2.90.6, it replaced dist/electron/vendors.610db4cad49ffb2ccbfb.js.
In both cases, the script substituted these files with nearly identical versions — a_2_90_6.js and a_2_91_5.js, respectively — preserving all original functionality except for a critical change: the destination wallet address was replaced with one controlled by the attacker. As a result, any crypto sent by the user would be redirected to the attacker’s wallet without detection.
A similar injection was performed against Exodus Wallet, this time targeting the file src/app/ui/index.js. The affected versions in that case were 25.13.3 and 25.9.2.
Exfiltration Layer
The infection did not stop there. After successfully injecting the trojanized files, the script issued a POST request to hxxp[:]//178[.]156[.]149[.]109/set-install-status, containing data about the user’s home directory.
Simultaneously, a ZIP archive was created from the %AppData%/Roaming/AnyDesk folder — including chat logs and trace files — and sent to hxxp[:]//178[.]156[.]149[.]109/save-anydesk. This suggests either extended data collection or efforts to wipe forensic evidence of the attack.
Critically, removing the pdf-to-office npm package alone did not neutralize the infection. The trojanized components in Atomic and Exodus remained active until the wallets were manually and cleanly reinstalled.
This persistence is particularly dangerous, given that self-custodial wallets store private keys locally — meaning wallet removal or mismanagement during cleanup can result in irreversible loss of funds.
There is a case when hardware wallets show their best because they are single-purpose devices that aren’t used for anything except crypto, without third-party risky options – see our guide to crypto wallets and the top hardware wallet options.
Conclusion
This wasn’t the first ‘patch-in-place’ campaign of its kind. ReversingLabs previously documented similar cases involving the ethers-provider2 and ethers-providerz packages, which targeted the popular ethers npm package using comparable techniques.
As noted earlier, supply chain attacks that target infrastructure are increasingly common, especially when the architectural complexity of blockchain systems makes direct compromise prohibitively difficult. That’s why it’s essential not only to rely on trusted sources of information thoroughly as your trading strategy but also to validate the software you use and to audit your systems. Stay tuned for updates, be adaptive in the rapidly evolving technology, blockchain, and crypto landscape.
