Start by monitoring the earliest compromise signals, then layer persistence and exfiltration checks. Failed SSH logins, vulnerability exploitation attempts, changes to SSH authorized_keys, suspicious cron jobs, dropped files in tmp locations, and outbound connections to known mining pools all matter. High CPU usage adds another signal, but network inspection is still needed because mining protocols can resemble other traffic.
Why This Matters for Security Teams
Linux endpoints that silently join crypto miner botnets are rarely just a performance problem. They often indicate that an attacker already has a foothold, with SSH brute force, exploit chaining, or exposed management services used to establish execution. Once persistence is in place, the same host can become a relay point for lateral movement, credential theft, or additional malware staging. Detection therefore needs to focus on early compromise indicators rather than waiting for obvious resource spikes.
The practical challenge is that miner activity can look like legitimate load, especially on build servers, containers, and shared infrastructure where high CPU is normal. Teams also miss weak signals when logging is fragmented across endpoint, authentication, and network tools. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces continuous monitoring, response coordination, and asset visibility as connected activities rather than separate tasks.
In practice, many security teams encounter the miner only after the host has already been used to scan internal systems or make outbound pool connections for some time.
How It Works in Practice
Detection works best when endpoint telemetry, authentication logs, and network data are correlated around a short compromise timeline. On Linux, the earliest signs often appear in auth logs and process lineage: repeated failed SSH attempts, unusual successful logins from new source IPs, or a process tree that does not match the expected administration path. From there, analysts should look for persistence changes such as new cron entries, modified startup scripts, altered systemd service files, and appended SSH authorized_keys content.
Once a suspicious process is identified, inspect where it was launched from and what it touched next. Miner botnets often drop binaries into writable locations such as /tmp, /var/tmp, or user home directories, then run under short-lived names that resemble maintenance utilities. Network inspection should confirm whether the host is reaching public mining pools, proxy nodes, or command-and-control infrastructure. A single indicator is rarely decisive, so the goal is to build a chain of evidence.
- Correlate SSH failures, successful logins, and new sessions for the same account.
- Flag new or changed cron jobs, systemd units, and shell profile modifications.
- Alert on executable files created in writable temporary paths followed by network activity.
- Compare outbound traffic against known mining pool patterns and unusual long-lived connections.
- Treat unexplained CPU spikes as a confirmation signal, not the primary trigger.
For broader hunt design, MITRE ATT&CK helps map the likely techniques, while NIST CSF keeps the response anchored to asset inventory, monitoring, and containment discipline. These controls tend to break down on heavily containerised hosts or ephemeral cloud instances because short-lived workloads and shared process namespaces reduce the fidelity of endpoint-only detection.
Common Variations and Edge Cases
Tighter detection often increases analyst workload, requiring organisations to balance earlier warning against the risk of noisy alerts on shared Linux infrastructure. That tradeoff is especially visible on developer workstations, CI runners, and virtualised estates where legitimate automation can resemble attacker tradecraft.
Current guidance suggests treating these environments differently rather than applying one rule set everywhere. On build agents, for example, outbound connections to known mining pools may matter more than CPU spikes, because compile jobs already consume resources. On bastion hosts, new SSH keys and unusual account usage deserve higher priority. On internet-facing servers, exploit traces may be more valuable than persistence artefacts because miners are often deployed immediately after initial access.
There is no universal standard for thresholding miner detection yet. Best practice is evolving toward behaviour-based correlations, enriched with allowlists for sanctioned admin tooling and approved monitoring agents. Where automation is mature, teams should feed detections into SOAR playbooks so that containment can isolate the host before the botnet expands laterally.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 | Continuous monitoring is central to spotting miner activity before lateral spread. |
| MITRE ATT&CK | T1078 | Valid account abuse commonly precedes miner deployment on Linux endpoints. |
Correlate endpoint, auth, and network telemetry to surface early compromise signals quickly.
Related resources from NHI Mgmt Group
- How can security teams detect release storms before they spread?
- How should security teams detect browser-based copy-paste attacks before they execute locally?
- How do security teams detect shadow agents before they cause damage?
- How should security teams detect fabricated employee identities before they reach system access?
