Response playbooks, investigation guides, and Atomic Red Team tests are Pro-only. Upgrade to unlock the full detection package for THREAT-K8s-CryptojackingResourceHijack.
Upgrade to ProKubernetes Cryptojacking — Cloud Compute Hijacking via Malicious Pod Deployment
Cryptojacking crews (TeamTNT, Kinsing, WatchDog, Kiss-a-dog, and opportunistic campaigns like RBAC Buster/SCARLETEEL follow-on activity) systematically scan the internet for exposed Kubernetes control planes: anonymous-auth API servers, unauthenticated kubelet read-only ports (10255/10250), exposed dashboards (Weave Scope, Kubeflow), or leaked/over-privileged service account tokens harvested from a prior web-app compromise. Once inside, the attacker uses `kubectl create`/`apply` or a direct API call to deploy a DaemonSet or high-replica Deployment across every node in the cluster, pulling a miner image (XMRig, kdevtmpfsi, kinsing) from a public or attacker-controlled registry, frequently disguised behind a legitimate-looking image name or tag. Pods routinely request the maximum CPU the node scheduler will allow (or omit resource limits entirely), starving legitimate workloads and driving the victim's cloud compute bill up dramatically — a single hijacked node-pool can run into thousands of dollars per day on AWS EKS, Azure AKS, or GCP GKE. Many variants also set `hostPID`/`hostNetwork: true` or mount `/var/run/docker.sock`/hostPath `/` to escape the container and persist directly on the underlying node, then disable or kill competing miners and security agents (Falco, cloud-native EDR) before establishing outbound connections to a mining pool over Stratum protocol. Detection requires correlating Kubernetes audit logs (anomalous pod/DaemonSet creation, especially from a ServiceAccount or anonymous identity with no prior deployment history), container runtime/stdout logs (miner banner strings), and node-level network telemetry (outbound to known Stratum ports and mining-pool domains).
What is THREAT-K8s-CryptojackingResourceHijack Kubernetes Cryptojacking — Cloud Compute Hijacking via Malicious Pod Deployment?
Kubernetes Cryptojacking — Cloud Compute Hijacking via Malicious Pod Deployment (THREAT-K8s-CryptojackingResourceHijack) maps to the Impact tactic — the adversary is trying to manipulate, interrupt, or destroy your systems and data in MITRE ATT&CK.
This page provides production-ready detection logic for Kubernetes Cryptojacking — Cloud Compute Hijacking via Malicious Pod Deployment, covering the data sources and telemetry it touches: AKS/EKS/GKE Kubernetes audit logs (kube-audit) forwarded via diagnostic settings, Container stdout/stderr via Container Insights (ContainerLogV2), Microsoft Defender for Containers / Defender for Endpoint on Linux node sensors (DeviceNetworkEvents). The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Impact
// THREAT-K8s-CryptojackingResourceHijack (T1496.001 Resource Hijacking: Compute Hijacking)
// Requires AKS diagnostic settings sending kube-audit to AKSAudit, and Defender for Containers/MDE node sensors for DeviceNetworkEvents
let MinerImagePatterns = dynamic(["xmrig", "kdevtmpfsi", "kinsing", "monero", "minerd", "cryptonight", "nicehash", "c3pool", "supportxmr"]);
let MiningPorts = dynamic([3333, 4444, 5555, 7777, 8080, 14444, 45700, 14433]);
let Lookback = 1h;
// Signal 1: Kubernetes audit log shows a Pod/DaemonSet/Deployment created with a miner-matching image, no resource limits, or hostPID/hostNetwork set
let SuspiciousWorkloadCreate = AKSAudit
| where TimeGenerated > ago(Lookback)
| where Verb in ("create", "update", "patch") and ObjectRef.resource in ("pods", "daemonsets", "deployments", "replicasets")
| extend RequestBody = tostring(RequestObject)
| where RequestBody has_any (MinerImagePatterns)
or (RequestBody has "hostNetwork" and RequestBody has "true")
or (RequestBody has "hostPID" and RequestBody has "true")
| project TimeGenerated, User = tostring(User.username), Namespace = tostring(ObjectRef.namespace), ObjectName = tostring(ObjectRef.name), Resource = tostring(ObjectRef.resource), RequestBody, Indicator = "SuspiciousWorkloadCreate";
// Signal 2: container stdout/stderr contains miner banner strings (XMRig prints its version/pool banner on startup)
let MinerBannerInLogs = ContainerLogV2
| where TimeGenerated > ago(Lookback)
| where LogMessage has_any ("XMRig", "stratum+tcp", "cryptonight", "randomx", "donate-level", "hashrate")
| project TimeGenerated, Namespace = PodNamespace, ObjectName = PodName, Resource = "pod", RequestBody = LogMessage, Indicator = "MinerBannerInLogs";
// Signal 3: node-level outbound network connection to a known Stratum mining port
let MiningPoolConnections = DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where ActionType == "ConnectionSuccess"
| where RemotePort in (MiningPorts)
| summarize ConnectionCount = count(), RemoteIPs = make_set(RemoteIP, 10) by DeviceName, InitiatingProcessFileName, bin(TimeGenerated, 10m)
| where ConnectionCount >= 3
| project TimeGenerated, Namespace = "(node-level)", ObjectName = DeviceName, Resource = InitiatingProcessFileName, RequestBody = strcat("RemoteIPs=", tostring(RemoteIPs)), Indicator = "MiningPoolConnection";
union SuspiciousWorkloadCreate, MinerBannerInLogs, MiningPoolConnections
| sort by TimeGenerated desc Three-signal detection combining Kubernetes control-plane audit logs, container runtime stdout, and node network telemetry. Signal 1 flags Pod/DaemonSet/Deployment/ReplicaSet create-or-patch events whose request body references a known miner image name or sets hostNetwork/hostPID to true (used for container-escape and to avoid a service ClusterIP giving away the workload's purpose). Signal 2 flags XMRig/cryptonight/stratum banner text emitted to container stdout at process startup — miners are extremely 'noisy' about their identity in logs since the software itself is not designed to hide, only the deployment vector is. Signal 3 flags a node making 3+ outbound connections within a 10-minute window to a well-known Stratum mining port (3333/4444/5555/7777/8080/14444/45700/14433). Any single signal can be a false positive (a legitimate crypto-adjacent workload, a misconfigured DaemonSet, or a security research pod); two or more signals correlated on the same namespace/pod/node within the lookback window is high-confidence cryptojacking.
Data Sources
Required Tables
False Positives
- Legitimate blockchain/crypto research or internal PoC workloads that intentionally run mining or hashing software in a sandboxed namespace
- Security research or honeypot pods deliberately deployed to study cryptojacking malware behavior
- Batch/ML workloads that omit CPU resource limits by design (e.g. burstable QoS for training jobs) and coincidentally trip the hostNetwork/no-limits heuristic
- CI/CD runner DaemonSets (self-hosted GitHub Actions/GitLab runners) that legitimately request hostNetwork or hostPID for build isolation
- Network monitoring or service-mesh sidecar DaemonSets (Cilium, Calico, Istio CNI) that require hostNetwork:true and can trigger the container-escape heuristic
Sigma rule & cross-platform mapping
The detection logic for Kubernetes Cryptojacking — Cloud Compute Hijacking via Malicious Pod Deployment (THREAT-K8s-CryptojackingResourceHijack) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: network_connection
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for THREAT-K8s-CryptojackingResourceHijack
References (7)
- https://attack.mitre.org/techniques/T1496/001/
- https://attack.mitre.org/techniques/T1610/
- https://attack.mitre.org/techniques/T1611/
- https://attack.mitre.org/tactics/TA0040/
- https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
- https://sysdig.com/blog/tor-teamtnt-mining-orchestration/
- https://www.crowdstrike.com/en-us/blog/kinsing-malware-attacks-targeting-container-environments/
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulated Miner DaemonSet Deployment via kubectl (Lab Only)
Expected signal: Kubernetes audit log (kube-audit) records a 'create' event for objectRef.resource=daemonsets with objectRef.name=xmrig-test-457, requestObject containing hostNetwork:true, hostPID:true, and the image name 'xmrig-test-457' in metadata/labels.
- Test 2Simulated Miner Banner in Container Logs (Lab Only)
Expected signal: ContainerLogV2/kube:container:log records the literal banner string containing 'XMRig', 'stratum+tcp', 'cryptonight', and 'donate-level' for the pod miner-banner-test-457.
- Test 3Simulated Outbound Connection to Stratum Mining Port (Lab Only)
Expected signal: Node-level network telemetry (DeviceNetworkEvents / netflow) records 4 ConnectionSuccess events to RemotePort=3333 from the test host within a single 10-minute window.
Unlock playbooks & atomic tests with Pro
Get the full detection package for THREAT-K8s-CryptojackingResourceHijack — response playbook and atomic red team tests, plus investigation guidance and hunting queries.
df00tech Pro — £29/user/month
Related Detections
Tactic Hub
Detection Variants (1)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.