Direct Interactive Kubernetes API Request by Common Utilities

This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster. Note that this rule may not trigger if the authorization token of the request is expanded within the process argument list, as the length of the "process.args" field may lead to the field being ignored.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/01/21"
  3integration = ["cloud_defend", "kubernetes"]
  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/01/27"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct
 13interactive Kubernetes API requests. An adversary may need to execute direct interactive Kubernetes API requests to gain
 14access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate
 15the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within
 16the cluster. Note that this rule may not trigger if the authorization token of the request is expanded within the process
 17argument list, as the length of the "process.args" field may lead to the field being ignored.
 18"""
 19false_positives = [
 20    """
 21    There is a potential for false positives if the direct interactive Kubernetes API requests are used for legitimate purposes,
 22    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
 23    if they are indicative of malicious activity or part of legitimate container activity.
 24    """,
 25    """
 26    There is a risk of false positives if there are several containers named the same, as the rule may correlate the request
 27    to the wrong container.
 28    """,
 29]
 30from = "now-6m"
 31index = ["logs-cloud_defend.process*", "logs-kubernetes.audit_logs-*"]
 32interval = "5m"
 33language = "eql"
 34license = "Elastic License v2"
 35name = "Direct Interactive Kubernetes API Request by Common Utilities"
 36note = """ ## Triage and analysis
 37
 38> **Disclaimer**:
 39> 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.
 40
 41### Investigating Direct Interactive Kubernetes API Request by Common Utilities
 42
 43This detection links an interactive invocation of common networking utilities or kubectl inside a container to a near-simultaneous Kubernetes API response, indicating hands-on-keyboard access to the API server for discovery or lateral movement. A common attacker pattern is compromising a pod, reading its mounted service account token, then running curl or kubectl interactively to query /api or /apis endpoints to list pods and secrets and map cluster scope.
 44
 45### Possible investigation steps
 46
 47- From Kubernetes audit logs linked to the pod, capture the authenticated principal, namespace, verbs, and request URIs to determine whether the activity focused on discovery or sensitive resources like secrets or RBAC objects.
 48- Correlate the interactive container activity with kubelet exec/attach or terminal session telemetry to identify who initiated the session and through which source IP or control-plane endpoint.
 49- Inspect the pod’s service account by validating access to the mounted token path and enumerating its RoleBindings and ClusterRoleBindings to quantify effective privileges and decide on immediate revocation or rotation.
 50- Review the container image provenance and available shell history or command logs to confirm use of networking utilities or kubectl and identify any reads of secrets, kubeconfig files, or /api and /apis endpoints.
 51- Expand the time window to find prior or subsequent API calls from the same pod, namespace, or node, and quarantine or cordon the workload if you observe sustained enumeration or cross-namespace access.
 52
 53### False positive analysis
 54
 55- An operator uses kubectl exec -it to enter a pod and runs kubectl or curl to list resources or verify RBAC, producing interactive process starts and near-simultaneous Kubernetes audit responses that are expected during troubleshooting.
 56- During routine connectivity or certificate checks, an engineer attaches to a container that includes curl/openssl/socat/ncat and interactively tests the Kubernetes API server endpoint, generating correlated audit events without malicious intent.
 57
 58### Response and remediation
 59
 60- Immediately isolate the implicated pod by terminating the interactive shell and curl/kubectl processes, applying a deny-all NetworkPolicy in its namespace, and temporarily blocking pod egress to the kube-apiserver address.
 61- Revoke and rotate the service account credentials used by the pod, invalidate the token at /var/run/secrets/kubernetes.io/serviceaccount/token, and remove excess RoleBindings or ClusterRoleBindings tied to that identity.
 62- Delete and restore the workload from a trusted image that excludes curl/wget/openssl/socat/ncat, with automountServiceAccountToken disabled and least-privilege RBAC enforced.
 63- Escalate to incident response if the pod read Secrets or ConfigMaps, modified RBAC objects, attempted create/patch/delete on cluster-scoped resources, or originated from an unapproved operator workstation or bastion.
 64- Harden by restricting kubectl exec/attach to a small admin group with MFA, enabling admission controls (Pod Security Admission, Gatekeeper, or Kyverno) to block shells or kubectl/netcat in images, and applying egress NetworkPolicies so only approved namespaces can reach https://kubernetes.default.svc.
 65"""
 66risk_score = 47
 67rule_id = "9d312839-339a-4e10-af2e-a49b15b15d13"
 68severity = "medium"
 69tags = [
 70    "Data Source: Elastic Defend for Containers",
 71    "Data Source: Kubernetes",
 72    "Domain: Container",
 73    "Domain: Kubernetes",
 74    "OS: Linux",
 75    "Use Case: Threat Detection",
 76    "Tactic: Execution",
 77    "Tactic: Discovery",
 78    "Resources: Investigation Guide",
 79]
 80timestamp_override = "event.ingested"
 81type = "eql"
 82query = '''
 83sequence with maxspan=1s
 84  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
 85     process.name in ("wget", "curl", "openssl", "socat", "ncat", "kubectl") or
 86     (
 87       /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
 88       process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
 89       process.args in (
 90         "wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget",
 91         "ssl_client", "/bin/ssl_client", "/usr/bin/ssl_client", "/usr/local/bin/ssl_client",
 92         "curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl",
 93         "openssl", "/bin/openssl", "/usr/bin/openssl", "/usr/local/bin/openssl",
 94         "socat", "/bin/socat", "/usr/bin/socat", "/usr/local/bin/socat",
 95         "ncat", "/bin/ncat", "/usr/bin/ncat", "/usr/local/bin/ncat",
 96         "kubectl", "/bin/kubectl", "/usr/bin/kubectl", "/usr/local/bin/kubectl"
 97       ) and
 98       /* default exclusion list to not FP on default multi-process commands */
 99       not process.args in (
100         "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
101         "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
102         "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
103         "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
104       )
105     )
106   ) and process.interactive == true and container.id like "*"
107  ] by orchestrator.resource.name
108  [any where event.dataset == "kubernetes.audit_logs" and kubernetes.audit.stage in ("ResponseComplete", "ResponseStarted")] by `kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name` 
109'''
110
111[[rule.threat]]
112framework = "MITRE ATT&CK"
113
114[[rule.threat.technique]]
115id = "T1059"
116name = "Command and Scripting Interpreter"
117reference = "https://attack.mitre.org/techniques/T1059/"
118
119[[rule.threat.technique.subtechnique]]
120id = "T1059.004"
121name = "Unix Shell"
122reference = "https://attack.mitre.org/techniques/T1059/004/"
123
124[rule.threat.tactic]
125id = "TA0002"
126name = "Execution"
127reference = "https://attack.mitre.org/tactics/TA0002/"
128
129[[rule.threat]]
130framework = "MITRE ATT&CK"
131
132[[rule.threat.technique]]
133id = "T1613"
134name = "Container and Resource Discovery"
135reference = "https://attack.mitre.org/techniques/T1613/"
136
137[rule.threat.tactic]
138id = "TA0007"
139name = "Discovery"
140reference = "https://attack.mitre.org/tactics/TA0007/"

Triage and analysis

Disclaimer: 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.

Investigating Direct Interactive Kubernetes API Request by Common Utilities

This detection links an interactive invocation of common networking utilities or kubectl inside a container to a near-simultaneous Kubernetes API response, indicating hands-on-keyboard access to the API server for discovery or lateral movement. A common attacker pattern is compromising a pod, reading its mounted service account token, then running curl or kubectl interactively to query /api or /apis endpoints to list pods and secrets and map cluster scope.

Possible investigation steps

  • From Kubernetes audit logs linked to the pod, capture the authenticated principal, namespace, verbs, and request URIs to determine whether the activity focused on discovery or sensitive resources like secrets or RBAC objects.
  • Correlate the interactive container activity with kubelet exec/attach or terminal session telemetry to identify who initiated the session and through which source IP or control-plane endpoint.
  • Inspect the pod’s service account by validating access to the mounted token path and enumerating its RoleBindings and ClusterRoleBindings to quantify effective privileges and decide on immediate revocation or rotation.
  • Review the container image provenance and available shell history or command logs to confirm use of networking utilities or kubectl and identify any reads of secrets, kubeconfig files, or /api and /apis endpoints.
  • Expand the time window to find prior or subsequent API calls from the same pod, namespace, or node, and quarantine or cordon the workload if you observe sustained enumeration or cross-namespace access.

False positive analysis

  • An operator uses kubectl exec -it to enter a pod and runs kubectl or curl to list resources or verify RBAC, producing interactive process starts and near-simultaneous Kubernetes audit responses that are expected during troubleshooting.
  • During routine connectivity or certificate checks, an engineer attaches to a container that includes curl/openssl/socat/ncat and interactively tests the Kubernetes API server endpoint, generating correlated audit events without malicious intent.

Response and remediation

  • Immediately isolate the implicated pod by terminating the interactive shell and curl/kubectl processes, applying a deny-all NetworkPolicy in its namespace, and temporarily blocking pod egress to the kube-apiserver address.
  • Revoke and rotate the service account credentials used by the pod, invalidate the token at /var/run/secrets/kubernetes.io/serviceaccount/token, and remove excess RoleBindings or ClusterRoleBindings tied to that identity.
  • Delete and restore the workload from a trusted image that excludes curl/wget/openssl/socat/ncat, with automountServiceAccountToken disabled and least-privilege RBAC enforced.
  • Escalate to incident response if the pod read Secrets or ConfigMaps, modified RBAC objects, attempted create/patch/delete on cluster-scoped resources, or originated from an unapproved operator workstation or bastion.
  • Harden by restricting kubectl exec/attach to a small admin group with MFA, enabling admission controls (Pod Security Admission, Gatekeeper, or Kyverno) to block shells or kubectl/netcat in images, and applying egress NetworkPolicies so only approved namespaces can reach https://kubernetes.default.svc.

Related rules

to-top