« GKE Pod Exec Potential Reverse Shell GKE Pod Exec with Curl or Wget to HTTPS »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

GKE Pod Exec Sensitive File or Credential Path Access

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

GKE Pod Exec Sensitive File or Credential Path Access

edit

Detects successful GKE pod exec sessions where the executed command references high-value host or in-cluster paths: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root or home credential directories, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. Attackers with pods/exec often use these one-liners to steal credentials before lateral movement or privilege escalation. A narrow exclusion ignores benign resolv.conf reads. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec.

Rule type: query

Rule indices:

  • logs-gcp.audit-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Kubernetes
  • Data Source: GCP
  • Data Source: GCP Audit Logs
  • Data Source: Google Cloud Platform
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Tactic: Execution
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating GKE Pod Exec Sensitive File or Credential Path Access

This alert fires when a successful pods/exec API call includes a command matching sensitive path or filename patterns. Review gcp.audit.labels.command.gke.io/command for the reconstructed command string.

Possible investigation steps

  • Identify the actor (client.user.email), source IP, and user agent for the exec caller.
  • Map gcp.audit.resource_name (namespace/pod) to a workload owner, image, and change history.
  • Correlate adjacent activity from the same identity: secret reads, TokenRequest, RBAC writes, or additional execs.
  • If host-level paths appear, determine whether the workload is privileged, uses hostPath, or runs on break-glass nodes.

False positive analysis

  • Diagnostic images and vendor agents sometimes read kubeconfig-like or credential paths; baseline stable automation.
  • Training containers that deliberately demonstrate passwd reads can trigger; scope exceptions to those namespaces.

Response and remediation

  • If malicious, end the exec session, isolate the pod or node, rotate credentials that could have been read, and tighten pods/exec RBAC and admission controls.

Setup

edit

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

Rule query

edit
data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.type:start and
event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and
gcp.audit.labels.command.gke.io/command:(
  (
    *.jks* or *.key* or *.keystore* or *.p12* or *.pem* or
    */etc/kubernetes/* or */etc/passwd* or */etc/shadow* or */etc/sudoers* or
    */home/*/.aws* or */home/*/.azure* or */home/*/.config/gcloud* or */home/*/.kube* or */home/*/.ssh* or
    */proc/*/environ* or
    */root/.aws* or */root/.azure* or */root/.config/gcloud* or */root/.kube* or */root/.ssh* or
    */var/lib/kubelet/* or */var/run/secrets/* or
    */etc/*.conf* and (*credential* or *key* or *password* or *secret* or *token*)
  ) and not */etc/resolv.conf*
)

Framework: MITRE ATT&CKTM

« GKE Pod Exec Potential Reverse Shell GKE Pod Exec with Curl or Wget to HTTPS »