How do security teams know whether mining activity is legitimate or malicious?

Why This Matters for Security Teams

Cryptomining alerts are easy to dismiss as noisy host telemetry, but they often signal a broader compromise: stolen credentials, exposed workloads, or a container that has escaped its intended purpose. The real challenge is not spotting high CPU alone. It is distinguishing approved compute-heavy activity from unauthorised resource abuse, especially when attackers deliberately blend mining with routine background processing. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful here because mining detection depends on logging, baselining, and change control as much as on malware signatures.

For NHI-focused teams, mining is also an identity problem. Compromised service accounts, API keys, CI/CD credentials, and cloud workload identities are frequently the entry point for malicious miners. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which makes it difficult to separate legitimate automation from abuse. In practice, many security teams encounter crypto-mining only after an over-privileged workload has already been repurposed, rather than through intentional monitoring of expected workload behaviour.

How It Works in Practice

Security teams should treat mining decisions as a correlation problem, not a single-indicator verdict. Sustained CPU or GPU usage is only meaningful when compared with the host’s approved purpose, the owning team, and the normal network destinations for that workload. A build runner, analytics job, or render node may be compute-intensive by design, while a domain controller, database server, or low-traffic pod should not suddenly behave like a miner.

The practical workflow is to build an allowlist of known compute profiles and then compare runtime evidence against it. Useful signals include:

• Process lineage and command line, especially mining binaries, shell launchers, or abuse of legitimate tools.
• Outbound connections to mining pools, unusual DNS lookups, or repetitive beacons to low-reputation endpoints.
• Persistence artefacts such as cron entries, systemd services, startup items, or container restarts.
• Ownership context, including whether the asset is mapped to a documented application, pipeline, or team.

That same logic applies to cloud and container environments, where attackers often hide mining inside short-lived pods or compromised build jobs. NHIMG’s CI/CD pipeline exploitation case study is a good reminder that a legitimate automation path can become a covert execution channel when secrets, runners, or release tokens are exposed. The control objective is to make every compute spike explainable: who or what started it, what identity was used, what network egress was expected, and when the activity should end. For control mapping, NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls supports that approach through event logging, account monitoring, and configuration management.

These controls tend to break down in ephemeral container fleets with weak asset ownership, because the workload disappears before investigators can tie it to a business purpose.

Common Variations and Edge Cases

Tighter mining detection often increases investigation overhead, requiring organisations to balance alert fidelity against the risk of false positives. The hardest cases are usually legitimate high-performance workloads, managed service providers, and research clusters where sustained CPU use is normal. In those environments, current guidance suggests using context, not just thresholds: if the workload is approved, the destination systems are expected, and the identity is scoped correctly, high utilisation may be benign.

The edge cases are usually about identity drift and hidden persistence. A workload that was legitimate yesterday can become malicious today if its secret is stolen, its pod is rescheduled into a different namespace, or its service account gains broader rights than intended. NHIMG’s Millions of Misconfigured Git Servers Leaking Secrets shows how quickly exposed secrets can expand an attacker’s options, which is why teams should pair mining detections with secret rotation, ownership validation, and rapid revocation. Where consensus is still evolving is around whether every spike should trigger an automated kill action; most mature teams prefer staged response for approved batch systems and immediate isolation for unknown hosts, unknown pods, or unowned identities.

In practice, the breach becomes obvious only when mining traffic persists after the original workload owner has already lost control of the identity.

Related resources from NHI Mgmt Group

• How do security teams spot malicious activity after a legitimate login?
• How do security teams know if a suspicious package touched a Lambda environment?
• How can security teams tell whether loader controls are actually working?
• Why are NHIs a critical concern for security teams?