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…
Description
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.
Detection logic
Its licence does not clear it for publishing here
Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.
Detection requirements
- Platform
- Containers
The rule states no platform. This is derived from the ATT&CK technique it maps to.
- Log source category
- event_index
Known benign triggers
- Administrators routinely exec into pods for troubleshooting. Baseline expected users and target pods, then exclude known break-glass identities.
MITRE ATT&CK mappings
0 exclusive techniques.This is coverage no other published rule has; it is not this rule's total technique count.
References
| Reference | Cited by |
|---|---|
| kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/ | 4 |
From the source
- At source
- Open at source
- Upstream identifier
- c040c962-1c60-4259-8ea3-601a40d4ab9f
- Tagged by the source as
- Data Source: GCPData Source: Google Cloud PlatformDomain: CloudDomain: ContainersDomain: KubernetesNoise: LowPerformance: FastPlatform: GCPPlatform: KubernetesResources: Investigation GuideRule Type: New TermsTactic: ExecutionUse Case: Threat Detection
Licence
- Published under
- Elastic License 2.0Read the licence
- Attribution
- Required
Authorship
- Written by
- Published
- Sep 20, 2026
- Version
- 3