Djinn Stealer: The New Malware Hunting Crypto Wallet Files
A critical remote-support tool flaw let attackers deploy malware built to scan machines for Bitcoin, Ethereum, and six other wallet formats.
A vulnerability in SimpleHelp, a remote support tool used by IT teams and managed service providers, just gave attackers a fully authenticated technician session with a single forged token — no password, no phishing click required. What they installed next matters more than the entry point: Djinn Stealer, malware built with a dedicated module that scans infected machines for wallet files from Bitcoin, Ethereum, Litecoin, Dogecoin, Dash, Monero, Zcash, Exodus, Atomic Wallet, and Electrum.
CISA added the flaw, tracked as CVE-2026-48558, to its Known Exploited Vulnerabilities catalog and gave federal agencies until July 2 to patch. The CVSS score is a maximum 10 — the bug sits in how SimpleHelp validates identity tokens from its OIDC login flow, and it doesn't check the cryptographic signature at all. Anyone who can construct a plausible-looking token gets in as a technician. The malware that follows is the part worth understanding, because its wallet-hunting logic isn't unique to this incident — it's becoming standard equipment in infostealer families that have nothing to do with crypto on the surface.
What Actually Happened
SimpleHelp is remote monitoring and management (RMM) software — the kind of tool an IT department or outsourced support desk installs to access machines, push updates, and fix issues without physically being there. The vulnerability let an attacker skip authentication entirely and open a technician session on any internet-facing SimpleHelp server.
From that foothold, the attacker deployed TaskWeaver, a modular loader disguised as a file named jquery.js and run through Node.js rather than a browser. TaskWeaver doesn't carry a fixed set of commands. It opens an encrypted channel back to the attacker and pulls down whatever payload the operator decides to run next — in this case, Djinn Stealer.
That two-stage design is deliberate. A loader with no hardcoded malicious behavior is harder for antivirus and endpoint tools to flag, because the file itself doesn't do anything suspicious until it's told to. The actual theft only happens after the second payload lands, which gives the attacker room to profile the machine first and decide whether it's worth the second step.
Why Djinn Targets Wallet Files, Not Just Cloud Logins
Djinn Stealer's primary haul is what you'd expect from a machine reachable through IT support software: cloud platform credentials, source control tokens, package registry logins, SSH keys, and credentials for AI coding assistants. Businesses running SimpleHelp are exactly the kind of target where those exist in volume.
The wallet-hunting module is the detail that makes this relevant beyond IT departments. Djinn scans local storage for the file formats and directory structures specific to Bitcoin, Litecoin, Dogecoin, Dash, Ethereum, Monero, and Zcash keystores, plus the data directories used by Exodus, Atomic Wallet, and Electrum. These aren't guesses — each of those wallets stores private key material or seed data in predictable, named locations on disk, and Djinn's authors clearly built a list rather than a generic file-grabber.
This is a different attack shape than the wallet threats already covered on this blog. Clipboard hijackers intercept an address between copy and paste. AI-driven phishing tricks a user into signing something or handing over a seed phrase directly. Djinn does neither — it doesn't need the user to do anything wrong in the moment. It just walks the filesystem looking for keystore files that were left sitting on an already-compromised machine, sometimes years after the wallet was set up and forgotten.
| Attack type | What it needs from the user | What it steals |
|---|---|---|
| Clipboard hijacker | Paste without checking the full address | Redirects an outgoing transfer |
| AI phishing / deepfake | Click, connect, or approve something | Seed phrase or a malicious approval |
| File-hunting infostealer | Nothing — only needs the machine compromised | Existing keystore or wallet data files |
The Trend This Incident Confirms
Wallet-file scanning modules like Djinn's aren't new to this campaign specifically — they've been showing up across unrelated malware families for a couple of years, bundled in alongside browser-password grabbers as a low-cost addition. What CVE-2026-48558 confirms is how the delivery method keeps expanding. This time it's a remote-support tool flaw. Previous waves have ridden in through cracked software, malicious npm packages, and fake wallet update files.
The initial infection vector is almost irrelevant to whether your wallet data is at risk. If a machine gets compromised by any modern infostealer — regardless of whether the entry point was an RMM exploit, a poisoned dependency, or a pirated application — there is a reasonable chance the malware includes a module that checks for Exodus, Electrum, or raw keystore files the same way Djinn does. The SimpleHelp incident is notable for the specific CVE and the CISA deadline, not because the wallet-hunting behavior itself is unusual.
This matters most for two overlapping groups: businesses or DAOs that hold treasury funds in software wallets on machines an IT provider can remotely access, and individual users who keep a software wallet's keystore file on the same general-purpose computer they use for everything else — including the SimpleHelp-managed work laptop, if their employer uses it.
What to Actually Check and Change
Start with whether this applies to you at all. If your employer, DAO, or an IT contractor uses SimpleHelp or any similar RMM tool, confirm with them that CVE-2026-48558 has been patched — the fix has been available since the vulnerability was disclosed, and the CISA deadline only bound federal agencies, not private patching timelines.
Beyond that specific patch, the keystore-hunting behavior is the part worth defending against directly:
- Move meaningful balances to a hardware wallet. A hardware device keeps private keys in a separate secure element that a filesystem-scanning infostealer cannot read, regardless of what compromises the host computer.
- Don't leave keystore or seed backups as plaintext files on any internet-connected machine. Encrypted archives are better than nothing, but an offline backup — written down or stored on a device that never touches the internet — is what actually removes the file from an attacker's reach.
- Separate the machine you trade from the machine that gets remote support. If a work laptop is managed by an external IT provider, it's a reasonable place for spreadsheets and email. It's a poor place to also run a software wallet holding meaningful funds.
- Audit what remote access tools are installed and why. RMM software is legitimate and useful, but every instance is also a potential entry point. If you don't recognize a remote support tool running on a machine you use for crypto, find out who installed it and why before doing anything else on that device.
None of this requires abandoning software wallets entirely — it requires treating keystore files with the same caution as a seed phrase written on paper, because to an infostealer built like Djinn, that's exactly what they are.