Kubernetes Rapid Secret GET Activity Against Multiple Objects

edit

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

Kubernetes Rapid Secret GET Activity Against Multiple Objects

edit

This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity.

Rule type: esql

Rule indices: None

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:

https://attack.mitre.org/techniques/T1552/007/

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 Rapid Secret GET Activity Against Multiple Objects

This rule surfaces clusters of get operations on the secrets API where the same identity and client path (user.name, source.ip, user_agent.original) touch several different secret names within the rule lookback window. Allowed and denied outcomes are included: successful reads may indicate harvesting; repeated forbidden or unauthorized responses can still signal reconnaissance, RBAC probing, or scripted spray against secret names that exist in the cluster.

Investigation steps

Inspect Esql.outcome for a mix of allow vs deny and whether failures cluster on sensitive namespaces.
Map the identity to RBAC and namespace scope; review Esql.secrets_names and Esql.namespaces for high-value targets (tokens, registry credentials, TLS bundles, application secrets).
Pivot on the same source.ip and user for follow-on API activity (exec, pod create, role changes, broad list on secrets).
Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious.

False positives

Startup, Helm, or controllers may legitimately touch many secrets in one window; tune by user, namespace, or IP allowlists when baselined.

Rule query

edit

from logs-kubernetes.audit_logs-* metadata _id, _index, _version
| where event.dataset == "kubernetes.audit_logs"
    and event.action == "get"
    and kubernetes.audit.objectRef.resource == "secrets"
    and source.ip is not null and user.name is not null
    and not to_string(source.ip) in ("127.0.0.1", "::1") and
    not user.name in ("system:kube-controller-manager", "system:kube-scheduler") and
    not kubernetes.audit.objectRef.name like "sh.helm.release.*"
| stats
    Esql.unique_credentials = count_distinct(kubernetes.audit.objectRef.name),
    Esql.secrets_names = values(kubernetes.audit.objectRef.name),
    Esql.namespaces = values(kubernetes.audit.objectRef.namespace),
    Esql.outcome = values(`kubernetes.audit.annotations.authorization_k8s_io/decision`)
  by user.name, source.ip, user_agent.original
| where Esql.unique_credentials >= 3
| KEEP user.name, source.ip, user_agent.original, Esql.*

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
Technique:
- Name: Unsecured Credentials
- ID: T1552
- Reference URL: https://attack.mitre.org/techniques/T1552/
Sub-technique:
- Name: Container API
- ID: T1552.007
- Reference URL: https://attack.mitre.org/techniques/T1552/007/

« AWS STS GetFederationToken with AdministratorAccess in Request Kubernetes Secret get or list with Suspicious User Agent »