Back to results

Kubernetes Secret Get or List with Suspicious User Agent

Detects read access to Kubernetes Secrets (get/list) with a user agent matching a curated set of non-standard or attacker-leaning clients, for example minimal HTTP tooling, common scripting stacks, default library…

Description

Detects read access to Kubernetes Secrets (get/list) with a user agent matching a curated set of non-standard or attacker-leaning clients, for example minimal HTTP tooling, common scripting stacks, default library fingerprints, or distribution-tagged strings associated with offensive-security Linux images. Legitimate in-cluster automation usually presents stable, purpose-specific user agents (for example controller or client-go variants used by known components).

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

  • Internal automation built with generic libraries can resemble suspicious user agents; baseline known jobs and tune by service account, namespace, or stable source IP allowlists.
  • Operators may use ad hoc HTTP clients, scripts, or penetration-test images during approved exercises or break-glass maintenance; validate tickets, source IP, and identity before treating as compromise.

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