Back to All Scenarios
PASSEDsecurity / cryptojacking_production_servers
Cryptojacking on Production Servers — CPU Exhaustion
An attacker deploys cryptocurrency mining malware on 5 production servers after exploiting an unpatched vulnerability in a web management interface. The miners consume 90%+ CPU across all affected servers, causing severe performance degradation for production workloads. The mining pool connections are obfuscated through DNS-over-HTTPS to avoid detection.
Pattern
HIGH_CPU
Severity
CRITICAL
Confidence
95%
Remediation
Auto-Heal
Test Results
| Metric | Expected | Actual | Result |
|---|---|---|---|
| Pattern Recognition | HIGH_CPU | HIGH_CPU | |
| Severity Assessment | CRITICAL | CRITICAL | |
| Incident Correlation | Yes | 57 linked | |
| Cascade Escalation | Yes | Yes | |
| Remediation | — | Auto-Heal — Corax resolves autonomously |
Scenario Conditions
5 Linux production servers compromised. XMRig miner deployed as 'kworker' process. CPU usage: 90-98% on all 5 servers. Mining pool: MoneroOcean via DNS-over-HTTPS proxy. Initial access: unpatched Apache Tomcat manager interface. Persistence: systemd service 'system-update.service'.
Injected Error Messages (4)
CPU exhaustion on prod-srv-01 — cpu usage at 98% sustained for 6 hours, load average high: 47.2 31.8 28.4 (8-core system), top process: 'kworker_update' PID 31847 consuming 94% cpu across all cores, process masquerading as kernel worker thread, cpu 100% on 7 of 8 cores with only 2% from legitimate workloads, performance critically degraded
CPU exhaustion on prod-srv-03 — cpu high at 96% for 6+ hours, suspicious process '/usr/lib/system-update' running as root consuming 91% cpu, process spawned from systemd service 'system-update.service' (not a legitimate service), binary hash not matching any known system package, stratum mining protocol strings found in process memory, cpu critical across all production workloads
Customer portal severely degraded — response times increased from 200ms to 14 seconds, application CPU starved by competing process consuming 94% of available cpu, Tomcat thread pool exhausted: 200/200 threads busy, health check latency: 8 seconds (threshold: 2s), load average high and climbing, application effectively non-functional under cpu exhaustion conditions
SentinelOne threat detection — 5 endpoints running unauthorized cryptocurrency mining software, process name: 'kworker_update' and '/usr/lib/system-update', behavioral analysis: CPU-intensive process with network connections to known mining pool infrastructure via DoH (DNS-over-HTTPS), persistence mechanism: systemd service and crontab entry, initial compromise: Apache Tomcat manager with default credentials, MITRE ATT&CK: T1496 Resource Hijacking, cpu exhaustion across 5 production servers
Neural Engine Root Cause Analysis
A malicious or corrupted process named 'kworker_update' (PID 31847) is masquerading as a legitimate kernel worker thread and consuming 94% CPU across all cores. This is not a normal kernel worker thread behavior, as legitimate kworker processes typically don't sustain such high CPU usage for 6 hours. The process appears to be either malware, a runaway application process disguised as a system component, or a corrupted system process that needs immediate termination to restore system functionality.
Remediation Plan
1. Immediately kill the suspicious 'kworker_update' process (PID 31847) using kill -9 command. 2. Investigate the process origin by checking /proc/31847/ details before termination if still accessible. 3. Scan system for malware and verify integrity of system binaries. 4. Monitor system for 30 minutes post-termination to ensure CPU usage returns to normal. 5. Review system logs for process spawn origin and implement preventive measures. 6. If process respawns, identify parent process and terminate the entire process tree.
Tested: 2026-03-30Monitors: 4 | Incidents: 4Test ID: cmncjx4b405j1obqef6qw3bhi