GKE User Exec into Pod

Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2026/06/30"
 3integration = ["gcp"]
 4maturity = "production"
 5updated_date = "2026/06/30"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables
11interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand
12access.
13"""
14false_positives = [
15    """
16    Administrators routinely exec into pods for troubleshooting. Baseline expected users and target pods, then exclude
17    known break-glass identities.
18    """,
19]
20from = "now-6m"
21index = ["logs-gcp.audit-*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "GKE User Exec into Pod"
25note = """## Triage and analysis
26
27### Investigating GKE User Exec into Pod
28
29This new-terms rule alerts on the first exec into a given pod by a user identity in the lookback window.
30
31### Investigation steps
32
33- Review `user.email`, `orchestrator.resource.name`, `source.ip`, and `user_agent.original`.
34- Determine whether the target pod holds sensitive data or cluster credentials.
35- Correlate with secret access or RBAC changes from the same identity.
36
37### False positives
38
39- Approved admin debugging; exclude stable operator identities after review.
40
41## Setup
42
43The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
44references = [
45    "https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/",
46]
47risk_score = 47
48rule_id = "c040c962-1c60-4259-8ea3-601a40d4ab9f"
49severity = "medium"
50tags = [
51    "Domain: Cloud",
52    "Domain: Kubernetes",
53    "Data Source: GCP",
54    "Data Source: Google Cloud Platform",
55    "Use Case: Threat Detection",
56    "Tactic: Execution",
57    "Resources: Investigation Guide",
58]
59timestamp_override = "event.ingested"
60type = "new_terms"
61
62query = '''
63data_stream.dataset:gcp.audit and event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and
64not user.email:system\:*
65'''
66
67[rule.new_terms]
68field = "new_terms_fields"
69value = ["user.email", "orchestrator.resource.name"]
70
71[[rule.new_terms.history_window_start]]
72field = "history_window_start"
73value = "now-7d"
74
75[[rule.threat]]
76framework = "MITRE ATT&CK"
77
78[[rule.threat.technique]]
79id = "T1609"
80name = "Container Administration Command"
81reference = "https://attack.mitre.org/techniques/T1609/"
82
83[rule.threat.tactic]
84id = "TA0002"
85name = "Execution"
86reference = "https://attack.mitre.org/tactics/TA0002/"

Triage and analysis

Investigating GKE User Exec into Pod

This new-terms rule alerts on the first exec into a given pod by a user identity in the lookback window.

Investigation steps

  • Review user.email, orchestrator.resource.name, source.ip, and user_agent.original.
  • Determine whether the target pod holds sensitive data or cluster credentials.
  • Correlate with secret access or RBAC changes from the same identity.

False positives

  • Approved admin debugging; exclude stable operator identities after review.

Setup

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

References

Related rules

to-top