« Kubernetes Rapid Secret GET Activity Against Multiple Objects Kubernetes Secret get or list from Node or Pod Service Account »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Kubernetes Secret get or list with Suspicious User Agent

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

Kubernetes Secret get or list with Suspicious User Agent

edit

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).

Rule type: query

Rule indices:

  • logs-kubernetes.audit_logs-*

Severity: high

Risk score: 73

Runs every: 5m

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

Maximum alerts per execution: 100

References:

Tags:

  • Data Source: Kubernetes
  • Domain: Kubernetes
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Kubernetes Secret get or list with Suspicious User Agent

The rule matches Kubernetes audit events for secret get/list where user_agent.original matches a small allowlist of suspicious patterns (scripting runtimes, bare HTTP clients, and known offensive-distro markers) and source.ip is populated. It is meant to highlight credential access where the client fingerprint does not look like routine kubectl or well-known controller traffic relative to your environment.

Possible investigation steps

  • Tie user.name (and kubernetes.audit.impersonatedUser.* if present) to a human, service account, or cloud identity and validate whether that principal should use this user-agent profile against the targeted namespaces and secret names.
  • Review kubernetes.audit.objectRef.namespace and kubernetes.audit.objectRef.name for high-value objects (service account tokens, cloud IAM bindings, registry pulls, TLS bundles).
  • Pivot on source.ip in VPC flow, VPN, or proxy logs to determine origin (employee laptop, compromised host, cloud instance) and correlate with other API bursts or exec activity.
  • Check kubernetes.audit.annotations.authorization_k8s_io/decision for successful reads versus failed probing.

False positive analysis

  • CI, GitOps, or one-off scripts can emit generic user agents with broad RBAC; exclude stable pipelines and service accounts after review.
  • Local API server loopback may still populate source.ip in some topologies; compare with expected control-plane paths.

Response and remediation

  • If unauthorized, rotate affected secrets and credentials, revoke tokens or kubeconfigs for the identity, tighten RBAC, and block or isolate the source host at the network edge to the API server where appropriate.

Rule query

edit
data_stream.dataset:"kubernetes.audit_logs" and
event.action:(get or list) and
kubernetes.audit.objectRef.resource:"secrets" and
user_agent.original:(curl* or python* or Python* or wget* or Go-http* or perl* or java* or node* or php* or *distrib#kali* or *kali-amd64 or *kali-arm64*) and
source.ip:*

Framework: MITRE ATT&CKTM

« Kubernetes Rapid Secret GET Activity Against Multiple Objects Kubernetes Secret get or list from Node or Pod Service Account »