89 lines
2.7 KiB
Markdown
89 lines
2.7 KiB
Markdown
---
|
|
name: analyzing-cryptominer-malware
|
|
description: 'Analyzes cryptojacking/coinminer malware by extracting mining pool endpoints
|
|
(stratum), wallet addresses, algorithm and miner identifiers (XMRig and forks), and persistence
|
|
or resource-control settings from static strings and config. Activates for requests to analyze a
|
|
cryptominer, extract mining pool and wallet IOCs, or identify coinminer configuration.'
|
|
domain: cybersecurity
|
|
subdomain: malware-analysis
|
|
tags:
|
|
- malware-analysis
|
|
- cryptominer
|
|
- cryptojacking
|
|
- xmrig
|
|
- resource-hijacking
|
|
version: 1.0.0
|
|
author: analyst-ai-pack
|
|
license: Apache-2.0
|
|
mitre_attack:
|
|
- T1496
|
|
- T1543
|
|
- T1027
|
|
d3fend:
|
|
- D3-PSA
|
|
- D3-DA
|
|
references:
|
|
- 'MITRE ATT&CK T1496 Resource Hijacking — https://attack.mitre.org/techniques/T1496/'
|
|
- 'XMRig configuration documentation — https://xmrig.com/docs/miner/config'
|
|
---
|
|
|
|
# Analyzing Cryptominer Malware
|
|
|
|
## When to Use
|
|
|
|
- You have a suspected coinminer (often an XMRig fork) and need to extract its pool, wallet,
|
|
algorithm, and resource-control configuration for IOCs and attribution.
|
|
- You are confirming a host's high CPU/GPU usage is malicious mining.
|
|
|
|
**Do not use** this to run the miner — extract its configuration statically.
|
|
|
|
## Prerequisites
|
|
|
|
- The miner sample or its extracted config/strings, read inertly.
|
|
|
|
## Safety & Handling
|
|
|
|
- Read bytes statically; defang pool endpoints; never start the miner.
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Extract mining configuration
|
|
|
|
```bash
|
|
python scripts/analyst.py profile sample.bin
|
|
```
|
|
|
|
Extracts `stratum+tcp://`/`stratum+ssl://` pool URLs, wallet addresses (Monero and common
|
|
formats), algorithm names (`rx/0`, `cn/r`, etc.), and the XMRig/miner identifier strings.
|
|
|
|
### Step 2: Identify resource and stealth controls
|
|
|
|
Surface `max-cpu-usage`, `--background`, idle-detection, and `donate-level` settings, plus
|
|
watchdog/persistence indicators.
|
|
|
|
### Step 3: Build IOCs
|
|
|
|
Record defanged pool endpoints, wallet addresses, and the miner family for detection and takedown
|
|
referral.
|
|
|
|
### Step 4: Document
|
|
|
|
Summarize the campaign's pool/wallet and the resource-control posture.
|
|
|
|
## Validation
|
|
|
|
- Pool URLs use a recognized `stratum` scheme and resolve to plausible hosts.
|
|
- Wallet addresses match a known coin's format/length.
|
|
- The miner family is identified from its config keys/strings.
|
|
|
|
## Pitfalls
|
|
|
|
- Legitimate mining software shares the same config keys — context (deployment, stealth) matters.
|
|
- Encrypted/packed config requiring decryption first.
|
|
- Proxy pools masking the true upstream pool.
|
|
|
|
## References
|
|
|
|
- See [`references/api-reference.md`](references/api-reference.md) for the profiler.
|
|
- ATT&CK T1496 and the XMRig config reference (linked in frontmatter).
|