elastic / elastic/detection-rules

[New Rule] Untrusted Process Access to Cryptocurrency Wallet Data

Open
#6,616 0 comments 0 reactions 0 assignees View on GitHub
community
Dominant language
Python
Stars
2.7k
Forks
696
Avg merge
4d 17h
Merged PRs (30d)
87

Description

### Description

Identifies an untrusted/unsigned process, `osascript`, or a process with an untrusted/unsigned parent referencing a cryptocurrency wallet application's data directory or a browser cryptocurrency wallet extension's local storage on its command line. Wallet application data (Exodus, Electrum, Ledger Live, Coinomi, Atomic, Wasabi, Monero, `wallet.dat`) and browser extension local storage for popular wallets (MetaMask, Phantom) hold private keys, seed phrases, and session data attackers can use to drain funds directly. Real macOS infostealer families (AMOS/Atomic, Poseidon, Cthulhu, Banshee) explicitly target this data. No existing Elastic Defend rule for macOS covers wallet paths specifically. The closest rule (`credential_access_suspicious_web_browser_sensitive_file_access.toml`) only covers generic browser cookie/login-credential files, not wallet application data or wallet extension storage.

**Validation**: built and tested against a real macOS Elastic Defend deployment (Elastic Agent 9.4.0 / Elastic Defend 9.4.1, macOS 12.7.6 Intel). Real true-positive coverage for all 3 attacker vectors the rule is designed to catch: (1) a genuinely unsigned binary reading a wallet file directly, (2) a genuinely unsigned binary spawning a trusted `/bin/cat` as a child (`process.parent.code_signature.exists == false`), (3) `osascript do shell script "cat '' > /dev/null"`. Real false-positive control: 4 real instances of the same file read via a fully-trusted `bash`→`cat` chain, confirmed excluded. Re-confirmed live against the same EQL query today (2026-08-07) via `_eql/search` against real captured telemetry, still matches only the 3 real attacker vectors, no drift.

### Target Ruleset

macos

### Target Rule Type

Event Correlation (EQL)

### Tested ECS Version

8.10.0

### Query

```eql
process where event.action == "exec" and host.os.type == "macos" and process.command_line != null and
process.command_line like~ (
"*Library/Application Support/Exodus*",
"*Library/Application Support/Electrum*",
"*Library/Application Support/Ledger Live*",
"*Library/Application Support/Coinomi*",
"*Library/Application Support/atomic*",
"*Library/Application Support/Wasabi*",
"*Library/Application Support/monero-wallet-gui*",
"*wallet.dat*",
"*Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn*",
"*Local Extension Settings/bfnaelmomeimhlpmgjnjophhpkkoljpa*"
) and
(
process.code_signature.trusted == false or process.code_signature.exists == false or
process.name == "osascript" or
process.parent.code_signature.trusted == false or process.parent.code_signature.exists == false
) and
not process.executable == "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint"
```

### New fields required in ECS/data sources for this rule?

None. Uses standard `process.*` fields already populated by Elastic Defend on macOS.

### Related issues or PRs

None.

### References

- https://attack.mitre.org/techniques/T1555/
- https://attack.mitre.org/techniques/T1005/

### Redacted Example Data

Real event, re-confirmed live today (2026-08-07) against the same deployment, `osascript` vector:

```json
{
"@timestamp": "2026-08-07T18:xx:xx.xxxZ",
"host": { "os": { "type": "macos" } },
"process": {
"name": "osascript",
"command_line": "osascript -e do shell script \"cat \\\"/Users/victim/Library/Application Support/Ledger Live/app.json\\\" > /dev/null\"",
"parent": { "name": "bash" }
}
}
```

Real event, unsigned-binary-direct-read vector:

```json
{
"@timestamp": "2026-08-06T21:54:55.720Z",
"host": { "os": { "type": "macos" } },
"process": {
"name": "s33r_unsigned_reader",
"code_signature": { "exists": false },
"args": [
"/tmp/s33r_unsigned_reader",
"/Users/victim/Library/Application Support/Exodus/exodus.wallet.json"
],
"parent": { "name": "bash" }
}
}
```

False-positive control (does **not** match, both process and parent trusted, excluded by design): a fully-trusted `bash`→`cat` chain reading the same file paths, confirmed absent from the matched set in the same test session.

Contributor guide

Open the contributing guide

Research direction

Start by locating existing macOS Event Correlation EQL rules and their tests in the detection-rules repository, then compare their structure with the supplied query and ECS fields. Add the wallet-path detection under the macos ruleset and verify coverage for the three attacker vectors while excluding the trusted bash-to-cat control case.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos
Domain
operating-systems, security
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.