Forbidden Direct Interactive Kubernetes API Request

  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 forbidden
 13interactive Kubernetes API requests. An adversary may need to execute interactive Kubernetes API requests to gain access
 14to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the
 15Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the
 16cluster. Attackers may attempt to access resources that are forbidden by the authorization policy. Note that this rule may
 17not trigger if the authorization token of the request is expanded within the process argument list, as the length of the
 18"process.args" field may lead to the field being ignored.
 19"""
 20false_positives = [
 21    """
 22    There is a potential for false positives if the direct interactive Kubernetes API requests are used for legitimate purposes,
 23    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
 24    if they are indicative of malicious activity or part of legitimate container activity.
 25    """,
 26    """
 27    There is a risk of false positives if there are several containers named the same, as the rule may correlate the request
 28    to the wrong container.
 29    """,
 30]
 31from = "now-6m"
 32index = ["logs-cloud_defend.process*", "logs-kubernetes.audit_logs-*"]
 33interval = "5m"
 34language = "eql"
 35license = "Elastic License v2"
 36name = "Forbidden Direct Interactive Kubernetes API Request"
 37note = """ ## Triage and analysis
 38
 39> **Disclaimer**:
 40> 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.
 41
 42### Investigating Forbidden Direct Interactive Kubernetes API Request
 43
 44This rule correlates an interactive command execution inside a container with a Kubernetes API request that is explicitly forbidden, signaling hands-on-keyboard probing and unauthorized access attempts. It matters because attackers use live shells to enumerate cluster resources and test privileges for lateral movement or escalation. Example: after compromising a pod, an operator opens a shell and runs kubectl get secrets or curls the API server with the pod’s token, repeatedly receiving 403 Forbidden.
 45
 46### Possible investigation steps
 47
 48- Correlate the pod, container, namespace, node, and service account from the alert, then quickly pull the matching audit entries to see the verb, resource, requestURI, and userAgent for the forbidden calls.
 49- Determine whether the container image normally includes utilities like kubectl/curl/openssl or if they were dropped into the pod, and review recent file writes and package installs to differentiate admin debugging from hands-on-keyboard activity.
 50- Inspect the pod’s service account bindings and effective RBAC in the target namespace to confirm least privilege and understand why the request was denied, then check for other successful API requests from the same identity around the same timeframe.
 51- Review network connections from the pod to the API server (and any proxies) during the session to validate direct access paths, source IPs, and whether a mounted service account token from /var/run/secrets was used.
 52- Validate whether this was an authorized SRE/debug session by contacting the workload owner and checking for recent kubectl exec or ephemeral debug activity; if not expected, expand the search for similar forbidden attempts from other pods.
 53
 54### False positive analysis
 55
 56- An authorized kubectl exec or ephemeral debug session inside a pod where an engineer runs kubectl or curl to probe API resources and, because the pod’s service account is intentionally least‑privileged, the requests are forbidden as expected.
 57- Benign interactive troubleshooting that mistakenly uses the wrong namespace or queries cluster‑scoped endpoints from within the container (e.g., curl/openssl to the API server), causing the audit logs to show forbid decisions even though no malicious access was attempted.
 58
 59### Response and remediation
 60
 61- Immediately terminate the interactive shell (e.g., sh/bash) in the offending container and isolate the pod by applying a deny-egress NetworkPolicy in its namespace that blocks outbound connections to https://kubernetes.default.svc and the API server IPs.
 62- Revoke and rotate credentials by deleting the pod and its ServiceAccount token Secret, temporarily setting automountServiceAccountToken: false on the workload, and redeploying with a new ServiceAccount after validating RBAC least privilege.
 63- Remove attacker tooling and persistence by rebuilding the container image to exclude kubectl/curl/openssl/socat/ncat, clearing writable volume mounts that contain dropped binaries or scripts, and redeploying from a trusted registry.
 64- Sweep for spread by identifying pods running the same image or on the same node and terminating any interactive processes issuing Kubernetes API requests from within containers, then restart those workloads cleanly.
 65- Escalate to incident response if you observe successful API operations (200/201) on secrets, configmaps, or RBAC objects, exec into other pods, or privileged container settings (privileged=true, hostNetwork, or hostPID), indicating lateral movement or credential compromise.
 66- Harden going forward by tightening RBAC on the new ServiceAccount, enforcing Gatekeeper/OPA policies to deny images that include kubectl/curl and block interactive shells, setting readOnlyRootFilesystem and dropping NET_ADMIN, and restricting API server access via egress controls.
 67"""
 68risk_score = 47
 69rule_id = "5d1c962d-5d2a-48d4-bdcf-e980e3914947"
 70severity = "medium"
 71tags = [
 72    "Data Source: Elastic Defend for Containers",
 73    "Data Source: Kubernetes",
 74    "Domain: Container",
 75    "Domain: Kubernetes",
 76    "OS: Linux",
 77    "Use Case: Threat Detection",
 78    "Tactic: Execution",
 79    "Tactic: Discovery",
 80    "Resources: Investigation Guide",
 81]
 82timestamp_override = "event.ingested"
 83type = "eql"
 84query = '''
 85sequence with maxspan=1s
 86  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
 87     process.name in ("wget", "curl", "openssl", "socat", "ncat", "kubectl") or
 88     (
 89       /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
 90       process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
 91       process.args in (
 92         "wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget",
 93         "ssl_client", "/bin/ssl_client", "/usr/bin/ssl_client", "/usr/local/bin/ssl_client",
 94         "curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl",
 95         "openssl", "/bin/openssl", "/usr/bin/openssl", "/usr/local/bin/openssl",
 96         "socat", "/bin/socat", "/usr/bin/socat", "/usr/local/bin/socat",
 97         "ncat", "/bin/ncat", "/usr/bin/ncat", "/usr/local/bin/ncat",
 98         "kubectl", "/bin/kubectl", "/usr/bin/kubectl", "/usr/local/bin/kubectl"
 99       ) and
100       /* default exclusion list to not FP on default multi-process commands */
101       not process.args in (
102         "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
103         "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
104         "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
105         "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
106       )
107     )
108   ) and process.interactive == true and container.id like "*"
109  ] by orchestrator.resource.name
110  [any where event.dataset == "kubernetes.audit_logs" and kubernetes.audit.stage in ("ResponseComplete", "ResponseStarted") and
111  `kubernetes.audit.annotations.authorization_k8s_io/decision` == "forbid"
112  ] by `kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name` 
113'''
114
115[[rule.threat]]
116framework = "MITRE ATT&CK"
117
118[[rule.threat.technique]]
119id = "T1059"
120name = "Command and Scripting Interpreter"
121reference = "https://attack.mitre.org/techniques/T1059/"
122
123[[rule.threat.technique.subtechnique]]
124id = "T1059.004"
125name = "Unix Shell"
126reference = "https://attack.mitre.org/techniques/T1059/004/"
127
128[rule.threat.tactic]
129id = "TA0002"
130name = "Execution"
131reference = "https://attack.mitre.org/tactics/TA0002/"
132
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135
136[[rule.threat.technique]]
137id = "T1613"
138name = "Container and Resource Discovery"
139reference = "https://attack.mitre.org/techniques/T1613/"
140
141[rule.threat.tactic]
142id = "TA0007"
143name = "Discovery"
144reference = "https://attack.mitre.org/tactics/TA0007/"