Direct Interactive Kubernetes API Request by Unusual Utilities
This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. 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.
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 via unusual utilities. An adversary may need to execute direct interactive Kubernetes
14API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often
15used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move
16laterally within the cluster.
17"""
18false_positives = [
19 """
20 There is a potential for false positives if the direct interactive Kubernetes API requests are used for legitimate purposes,
21 such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
22 if they are indicative of malicious activity or part of legitimate container activity.
23 """,
24 """
25 There is a risk of false positives if there are several containers named the same, as the rule may correlate the request
26 to the wrong container.
27 """,
28]
29from = "now-6m"
30index = ["logs-cloud_defend.process*", "logs-kubernetes.audit_logs-*"]
31interval = "5m"
32language = "eql"
33license = "Elastic License v2"
34name = "Direct Interactive Kubernetes API Request by Unusual Utilities"
35note = """ ## Triage and analysis
36
37> **Disclaimer**:
38> 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.
39
40### Investigating Direct Interactive Kubernetes API Request by Unusual Utilities
41
42This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.
43
44### Possible investigation steps
45
46- Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
47- Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
48- Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
49- Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
50- If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.
51
52### False positive analysis
53
54- An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
55- A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.
56
57### Response and remediation
58
59- Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
60- Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
61- Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
62- Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
63- Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
64- Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
65"""
66risk_score = 21
67rule_id = "02275e05-57a1-46ab-a443-7fb444da6b28"
68severity = "low"
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 process.interactive == true and
85 container.id like "*" and
86 /* Covered by the rule "Direct Interactive Kubernetes API Request by Common Utilities" */
87 not (
88 process.name in ("wget", "curl", "openssl", "socat", "ncat", "kubectl") or
89 (
90 /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
91 process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
92 process.args in (
93 "wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget",
94 "ssl_client", "/bin/ssl_client", "/usr/bin/ssl_client", "/usr/local/bin/ssl_client",
95 "curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl",
96 "openssl", "/bin/openssl", "/usr/bin/openssl", "/usr/local/bin/openssl",
97 "socat", "/bin/socat", "/usr/bin/socat", "/usr/local/bin/socat",
98 "ncat", "/bin/ncat", "/usr/bin/ncat", "/usr/local/bin/ncat",
99 "kubectl", "/bin/kubectl", "/usr/bin/kubectl", "/usr/local/bin/kubectl"
100 ) and
101 /* default exclusion list to not FP on default multi-process commands */
102 not process.args in (
103 "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
104 "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
105 "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
106 "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
107 )
108 ) or
109 /* General exclusions for utilities that are not typically used for Kubernetes API requests */
110 process.name in ("sleep", "head", "tail")
111 )] by orchestrator.resource.name
112 [any where
113 event.dataset == "kubernetes.audit_logs" and
114 kubernetes.audit.stage in ("ResponseStarted","ResponseComplete") and
115 kubernetes.audit.verb in ("get", "list", "watch", "create", "patch", "update") and
116 (
117 kubernetes.audit.objectRef.resource in (
118 "pods", "secrets", "serviceaccounts", "configmaps",
119 "roles", "rolebindings", "clusterroles", "clusterrolebindings",
120 "deployments", "daemonsets", "statefulsets", "jobs", "cronjobs",
121 "nodes", "namespaces",
122 "selfsubjectaccessreviews", "selfsubjectrulesreviews", "subjectaccessreviews"
123 )
124 or (
125 kubernetes.audit.objectRef.resource == "pods" and
126 kubernetes.audit.objectRef.subresource in ("exec", "attach", "portforward", "log")
127 )
128 )
129 ] by `kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name`
130'''
131
132[[rule.threat]]
133framework = "MITRE ATT&CK"
134
135[[rule.threat.technique]]
136id = "T1059"
137name = "Command and Scripting Interpreter"
138reference = "https://attack.mitre.org/techniques/T1059/"
139
140[[rule.threat.technique.subtechnique]]
141id = "T1059.004"
142name = "Unix Shell"
143reference = "https://attack.mitre.org/techniques/T1059/004/"
144
145[rule.threat.tactic]
146id = "TA0002"
147name = "Execution"
148reference = "https://attack.mitre.org/tactics/TA0002/"
149
150[[rule.threat]]
151framework = "MITRE ATT&CK"
152
153[[rule.threat.technique]]
154id = "T1613"
155name = "Container and Resource Discovery"
156reference = "https://attack.mitre.org/techniques/T1613/"
157
158[rule.threat.tactic]
159id = "TA0007"
160name = "Discovery"
161reference = "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 Unusual Utilities
This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.
Possible investigation steps
- Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
- Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
- Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
- Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
- If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.
False positive analysis
- An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
- A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.
Response and remediation
- Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
- Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
- Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
- Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
- Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
- Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
Related rules
- Direct Interactive Kubernetes API Request by Common 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