Stealers collect cryptocurrency wallets in two places: desktop wallet applications, which keep key material in files such as wallet.dat or in per-wallet folders, and browser-extension wallets, which keep encrypted vaults in the extension’s local storage inside the browser profile. Both are fixed locations, so file-access detection is reliable. Finance, treasury and developer staff are the priority population.
Signals at a Glance
| Signal | Where | ATT&CK |
|---|---|---|
| Non-wallet process reads wallet.dat or desktop wallet folders (Electrum, Exodus, Atomic and similar) | EDR file access, 4663 | T1005 |
| Non-browser process reads Local Extension Settings folders of wallet extensions | EDR file access | T1555 |
| One process sweeps many wallet and browser locations within minutes | EDR correlation | T1005 |
| Wallet folder copied or archived to a staging path | File events | T1560.001 |
| Wallet application launched shortly after a stealer alert on the same host | Process creation | T1555 |
Wallet Locations
Desktop wallets live under the roaming application data folder or the user profile, and Bitcoin Core keeps wallet.dat in its data directory. Extension wallets store their vault under the browser profile in a folder named for the extension ID, so copy IDs from the vendor’s official listing and verify them in the browser store, since attackers register lookalikes. Express the rule against EDR file-read telemetry:
title: Non-Owner Read of Cryptocurrency Wallet Data
logsource:
category: file_access # map to your EDR file-read telemetry
product: windows
detection:
desktop_wallets:
TargetFilename|contains:
- '\Electrum\wallets\'
- '\Exodus\exodus.wallet\'
- '\Bitcoin\wallet.dat'
- '\Ethereum\keystore\'
extension_wallets:
TargetFilename|contains: '\Local Extension Settings\'
# add the verified extension IDs for wallets your users run
filter_owner:
Image|endswith:
- '\Electrum.exe'
- '\Exodus.exe'
- '\bitcoin-qt.exe'
- '\chrome.exe'
- '\msedge.exe'
condition: (desktop_wallets or extension_wallets) and not filter_owner
level: high
# tune/validate: backup agents and profile sync tools will match; allowlist by path and signer
Sweep Correlation
A single wallet read can be a backup. A sweep cannot. Count distinct wallet and credential locations touched by one process in a short window:
// KQL against an EDR file-access table (table and column names vary by product)
EdrFileAccess
| where TimeGenerated > ago(1d)
| where FilePath has_any ("\\Electrum\\wallets", "exodus.wallet", "wallet.dat",
"\\Local Extension Settings\\", "\\Login Data", "\\Network\\Cookies")
| summarize locations=dcount(FilePath), kinds=make_set(tostring(split(FilePath, "\\")[-2]), 12)
by DeviceName, ProcessPath, bin(TimeGenerated, 10m)
| where locations >= 4
// tune/validate: set the threshold from your own backup and sync baseline
- Move meaningful holdings to hardware wallets or institutional custody. A file-based hot wallet on an endpoint is a standing exposure.
- After a hit, assume the passphrase was captured as well (keylogging or clipboard) and move funds from a clean device first, then investigate.
- Pair with the clipper detection: stealers often include both collection and address swapping.
Use SigmaHQ and Elastic detections for credential and data theft from local files, the MITRE ATT&CK T1555 and T1005 pages, and wallet vendors’ own documentation for data paths. Verify extension IDs from the official store listing and baseline legitimate backup behaviour before alerting.
Build Detections That Fire
Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.
- Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
- Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
- 24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.
Stay ahead of emerging threats. Get notified when we publish new intelligence reports and advisories.
Subscribe to Alerts