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
- Direct Interactive Kubernetes API Request by Unusual Utilities
- Forbidden Direct Interactive Kubernetes API Request
- Service Account Token or Certificate Access Followed by Kubernetes API Request
- Direct Interactive Kubernetes API Request Detected via Defend for Containers
- DNS Enumeration Detected via Defend for Containers