A common mistake is watching only for visible miners while missing the access paths and hiding techniques that enable them. TeamTNT used shell scripts, memory-only execution, process hiding, and legitimate tooling to stay resident and reduce detection. Teams need to correlate unusual container activity, unexpected privilege use, suspicious outbound connections, and hidden processes rather than relying on malware signatures alone.
What teams miss when they look only for visible miners
Cryptojacking on Kubernetes and container hosts is rarely just a “miner found on disk” problem. The real failure is usually earlier in the chain: exposed credentials, overly broad cluster access, weak runtime boundaries, or hidden execution paths that let the workload keep running after the obvious artifact is removed. The right question is not only whether a miner exists, but how it was launched, sustained, and concealed.
That is why detection has to look beyond static signatures. In container environments, attackers often blend into normal operations by using legitimate tooling, short-lived scripts, and container-native behavior that does not look unusual in isolation. On hosts and in clusters, the compromise often shows up first as abnormal process behavior, privilege misuse, unexpected outbound traffic, or workload patterns that do not fit the application baseline.
Teams also underestimate how much persistence can live outside the miner itself. If access paths remain open, an attacker can replace one payload with another, re-spawn the workload, or pivot from one container to a node-level foothold. For that reason, the hunting problem is as much about access and execution context as it is about malware identification.
For container-specific hardening and runtime exposure patterns, NIST SP 800-190 Container Security is the right baseline to anchor image, orchestrator, and runtime controls.
How cryptojackers stay resident in Kubernetes and on hosts
Current campaigns tend to use ordinary operational pathways, not exotic exploits. In Kubernetes, that can mean a compromised pod, a leaked secret, a misconfigured workload identity, or over-permissive RBAC that allows the attacker to create new pods, mount sensitive data, or execute commands in existing containers. On the host side, the payload may run as a process tree that is easy to lose once it is renamed, moved into memory, or wrapped by a legitimate binary.
TeamTNT-style tradecraft is a useful example because it shows the pattern teams miss: shell scripts to stage the payload, in-memory execution to reduce artifacts, process hiding to frustrate local inspection, and legitimate tools to make malicious activity look like administration. None of those techniques are impressive on their own, but together they let the operator survive shallow cleanup and simple signature-based detection.
The practical implication is that a cluster can be “cleaned” while still being re-compromised minutes later if the underlying access path is not removed. Teams should treat a cryptojacking incident as both a malware event and an access-control event, especially where the same credentials, service tokens, or node permissions can be reused to redeploy the workload.
For workload-identity and secret-sprawl context, Ultimate Guide to NHIs, key challenges and risks is especially relevant because the same overexposed access material often enables persistence and re-entry.
What good detection and response need to correlate
Better detection comes from correlating weak signals across the container, node, and network layers. A miner that is trying to stay hidden often still leaves operational friction: unusual CPU saturation, unexplained outbound connections, processes that do not match the image or declared entrypoint, container restarts that do not align with application behavior, or privilege escalation that does not fit the workload’s normal role.
Teams should also investigate whether the “miner” is just the visible end state of a broader compromise. The more durable indicator is often anomalous authorization or execution: unexpected kubectl activity, shell access inside a running container, node-level commands launched from a container context, or signs that the attacker used legitimate administrative tooling to blend in. If the environment has no clean baseline for normal process trees, network destinations, and privilege use, cryptojacking will be detected late or not at all.
Operationally, the best response sequence is to contain the access path first, then rebuild from trusted images and known-good credentials, and only then look for the dropped payloads. That ordering matters because deleting the miner without removing the foothold leaves the attacker free to redeploy.
For broader posture and governance across identity, visibility, and least privilege, Top 10 NHI Issues and NIST Cybersecurity Framework 2.0 both help frame the control gaps behind repeated compromise.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Cryptojacking detection depends on correlating runtime, process, and network anomalies. |
| PR.AA — Identity Management, Authentication, and Access Control | Hidden miners persist through compromised access paths, over-privilege, and reused credentials. | |
| PR.PS — Platform Security | Container and host hardening limit the runtime and privilege conditions cryptojackers exploit. | |
| Recommendation — Correlate workload, host, and network telemetry to detect abnormal execution and outbound activity. Enforce least-privilege access and remove stale credentials that can redeploy workloads. Harden container hosts and orchestrators to restrict execution, privilege, and persistence. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Cryptojackers often use shell scripts and interpreters to stage and execute payloads. |
| T1562 — Impair Defenses | Process hiding and similar evasion techniques reduce visibility of running miners. | |
| T1071 — Application Layer Protocol | Abnormal outbound connections often reveal cryptojacking beaconing or pool traffic. | |
| Recommendation — Hunt for suspicious script-driven execution inside containers and on hosts. Monitor for defense-evasion behavior that suppresses local visibility into malicious processes. Inspect application-layer outbound traffic for mining pool connections and unusual destinations. | ||
| CIS Controls v8 | 8 — Audit Log Management | Correlated logs are needed to spot hidden execution and privilege misuse across the cluster. |
| 5 — Account Management | Cryptojacking often starts with weakly governed accounts, tokens, or access paths. | |
| Recommendation — Centralize and review logs that show execution, privilege use, and suspicious network activity. Review and remove unnecessary accounts and access paths that can be reused for redeployment. | ||
Practitioner Guidance
What to prioritise: Treat any confirmed miner as evidence of a wider access problem until proven otherwise. If you only hunt for the process binary, you will miss the conditions that let it return.
What to verify: Check whether the pod, node, or host had a valid path for command execution, credential reuse, or privilege escalation. The key question is whether the attacker could have redeployed the workload without needing a new exploit.
Practitioner takeaway: The highest-value detection signal is usually not the miner itself, but the combination of abnormal execution, privilege, and outbound behavior that explains how it survived.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
