Back to results

GKE Unusual Service Account Secret Access via New User Agent

Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable…

Description

Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable client fingerprint; a new user agent or source for that service account could indicate a stolen token used outside the workload (for example curl, a custom script, or kubectl from an unexpected host).

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
ContainersIaaSIdentity ProviderLinuxmacOSNetwork DevicesOffice SuiteSaaSWindows

The rule states no platform. This is derived from the ATT&CK technique it maps to.

Log source category
event_index

Known benign triggers

  • Controller upgrades, sidecar replacements, or client library version bumps change user agents and can produce a first-seen alert for known service accounts. Confirm the new client is expected before treating as compromise.
  • Newly deployed operators or workloads that change egress IP will alert once while the history window learns their client fingerprint.

Detections can measure how the public catalogue is used — which detections people look for, and which pages bring them here. It sets a cookie that recognises this browser for 180 days. It is never linked to an account and never follows you to other sites. Privacy notice