Potential Kubeletctl Execution Detected via Defend for Containers

  1[metadata]
  2creation_date = "2026/02/02"
  3integration = ["cloud_defend"]
  4maturity = "production"
  5min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
  6min_stack_version = "9.3.0"
  7updated_date = "2026/02/09"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the execution of kubeletctl inside a container. Kubeletctl is a command-line tool that can be used to
 13interact with the Kubelet API directly. It allows easy access to this API, making the often undocumented Kubelet API
 14more accessible. It is often used to enumerate the Kubelet API or other resources inside the container, and may indicate
 15an attempt to move laterally within the pod.
 16"""
 17false_positives = [
 18    """
 19    There is a potential for false positives when the command line arguments looked for in this rule are used for legitimate purposes,
 20    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
 21    if they are indicative of malicious activity or part of legitimate container activity.
 22    """,
 23]
 24from = "now-6m"
 25index = ["logs-cloud_defend.process*"]
 26interval = "5m"
 27language = "eql"
 28license = "Elastic License v2"
 29name = "Potential Kubeletctl Execution Detected via Defend for Containers"
 30note = """ ## Triage and analysis
 31
 32> **Disclaimer**:
 33> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 34
 35### Investigating Potential Kubeletctl Execution Detected via Defend for Containers
 36
 37This detects an interactive execution of kubeletctl within a Linux container, a tool that simplifies direct access to the node’s Kubelet API. It matters because kubeletctl can expose pod and node details and enable actions that support discovery and lateral movement from a compromised container. A common attacker pattern is running `kubeletctl scan` against the Kubelet endpoint, then using `pods` or `exec/attach` to reach other workloads.
 38
 39### Possible investigation steps
 40
 41- Determine how an interactive shell was obtained in the container (e.g., kubectl exec, docker exec, or an app RCE) by correlating the timestamp with Kubernetes audit logs and upstream access logs for the initiating user or workload.  
 42- Review the full kubeletctl invocation to identify the intended operation and target Kubelet endpoint (node IP/hostname and port), then validate whether that endpoint should be reachable from this pod in the cluster design.  
 43- Correlate container network activity around the alert for connections to node addresses on Kubelet ports (commonly 10250/10255) and look for scanning patterns across multiple nodes indicating discovery or lateral movement attempts.  
 44- Check for access to Kubernetes credentials within the container (service account token, mounted certificates, kubeconfig, cloud metadata credentials) and verify whether any were used to authenticate to the Kubelet API.  
 45- Hunt for follow-on actions consistent with lateral movement or impact, such as kubeletctl exec/attach/portForward usage, access to other pod namespaces, or subsequent Kubernetes API activity that creates/patches workloads.
 46
 47### False positive analysis
 48
 49- An administrator or developer may have executed kubeletctl interactively inside the container during an incident response or troubleshooting session to enumerate pods/runningpods or validate Kubelet API connectivity, which can resemble discovery activity.  
 50- A container image or entrypoint script that includes kubeletctl may be invoked manually for routine diagnostics (e.g., running scan/pods/cri or using --server/-s to target a node), producing an interactive exec event without malicious intent.
 51
 52### Response and remediation
 53
 54- Isolate the affected pod by scaling it to zero or applying a deny-all egress policy while preserving the container filesystem and process history needed to reconstruct the kubeletctl command, its target node address, and any output artifacts.  
 55- Block and alert on pod-to-node access to the Kubelet API (typically 10250/10255) at the network layer, and rotate/revoke any Kubernetes service account tokens or kubeconfigs present in the container if kubeletctl attempted authenticated actions like exec/attach/portForward.  
 56- Remove kubeletctl and related tooling from the image and redeploy from a known-good build, then perform node/pod hygiene by evicting/restarting the workload and checking for persistence indicators such as added binaries, modified entrypoints, or unexpected cron/init scripts.  
 57- Recover by re-creating the workload in a clean namespace with least-privilege RBAC, validating no unauthorized pods/replicasets were created and that the service account permissions and mounts match the expected deployment spec.  
 58- Escalate to the incident response team immediately if kubeletctl targeted multiple nodes, invoked exec/attach/portForward/run/scan, or if there is evidence of access to other namespaces or credential material (service account tokens, cloud metadata credentials) from the container.  
 59- Harden by enforcing Pod Security Standards (no privileged pods, hostNetwork/hostPID/hostPath restrictions), restricting interactive exec into production pods, and limiting node API exposure by disabling unauthenticated Kubelet endpoints and requiring authenticated/authorized access.
 60"""
 61references = [
 62    "https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster",
 63    "https://github.com/cyberark/kubeletctl",
 64]
 65risk_score = 21
 66rule_id = "2572f7e0-7647-4c68-a42b-d3b1973deaae"
 67severity = "low"
 68tags = [
 69    "Data Source: Elastic Defend for Containers",
 70    "Domain: Container",
 71    "OS: Linux",
 72    "Use Case: Threat Detection",
 73    "Tactic: Execution",
 74    "Tactic: Discovery",
 75    "Resources: Investigation Guide",
 76]
 77timestamp_override = "event.ingested"
 78type = "eql"
 79query = '''
 80process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
 81  (process.name == "kubeletctl" or process.args like "*kubeletctl*") or
 82  (process.args in ("-s", "--server") and process.args in ("run", "portForward", "scan", "attach", "exec", "pods", "runningpods", "cri", "pid2pod"))
 83) and
 84process.interactive == true and container.id like "?*" 
 85'''
 86
 87[[rule.threat]]
 88framework = "MITRE ATT&CK"
 89
 90[[rule.threat.technique]]
 91id = "T1059"
 92name = "Command and Scripting Interpreter"
 93reference = "https://attack.mitre.org/techniques/T1059/"
 94
 95[[rule.threat.technique.subtechnique]]
 96id = "T1059.004"
 97name = "Unix Shell"
 98reference = "https://attack.mitre.org/techniques/T1059/004/"
 99
100[rule.threat.tactic]
101id = "TA0002"
102name = "Execution"
103reference = "https://attack.mitre.org/tactics/TA0002/"
104
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107
108[[rule.threat.technique]]
109id = "T1613"
110name = "Container and Resource Discovery"
111reference = "https://attack.mitre.org/techniques/T1613/"
112
113[rule.threat.tactic]
114id = "TA0007"
115name = "Discovery"
116reference = "https://attack.mitre.org/tactics/TA0007/"