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 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).
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/04/22"
3integration = ["kubernetes"]
4maturity = "production"
5updated_date = "2026/04/22"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects read access to Kubernetes Secrets (`get`/`list`) with a user agent matching a curated set of non-standard or
11attacker-leaning clients, for example minimal HTTP tooling, common scripting stacks, default library fingerprints, or
12distribution-tagged strings associated with offensive-security Linux images. Legitimate in-cluster automation usually
13presents stable, purpose-specific user agents (for example controller or client-go variants used by known components).
14"""
15false_positives = [
16 """
17 Operators may use ad hoc HTTP clients, scripts, or penetration-test images during approved exercises or break-glass
18 maintenance; validate tickets, source IP, and identity before treating as compromise.
19 """,
20 """
21 Internal automation built with generic libraries can resemble suspicious user agents; baseline known jobs and tune
22 by service account, namespace, or stable source IP allowlists.
23 """,
24]
25index = ["logs-kubernetes.audit_logs-*"]
26language = "kuery"
27license = "Elastic License v2"
28name = "Kubernetes Secret get or list with Suspicious User Agent"
29note = """## Triage and analysis
30
31### Investigating Kubernetes Secret get or list with Suspicious User Agent
32
33The rule matches Kubernetes audit events for **secret** `get`/`list` where **`user_agent.original`** matches a **small
34allowlist of suspicious patterns** (scripting runtimes, bare HTTP clients, and known offensive-distro markers) and
35**`source.ip` is populated**. It is meant to highlight **credential access** where the client fingerprint does not look
36like routine kubectl or well-known controller traffic relative to your environment.
37
38### Possible investigation steps
39
40- Tie `user.name` (and `kubernetes.audit.impersonatedUser.*` if present) to a human, service account, or cloud identity
41 and validate whether that principal should use this user-agent profile against the targeted namespaces and secret names.
42- Review `kubernetes.audit.objectRef.namespace` and `kubernetes.audit.objectRef.name` for high-value objects (service
43 account tokens, cloud IAM bindings, registry pulls, TLS bundles).
44- Pivot on `source.ip` in VPC flow, VPN, or proxy logs to determine origin (employee laptop, compromised host, cloud
45 instance) and correlate with other API bursts or exec activity.
46- Check `kubernetes.audit.annotations.authorization_k8s_io/decision` for successful reads versus failed probing.
47
48### False positive analysis
49
50- CI, GitOps, or one-off scripts can emit generic user agents with broad RBAC; exclude stable pipelines and service
51 accounts after review.
52- Local API server loopback may still populate `source.ip` in some topologies; compare with expected control-plane paths.
53
54### Response and remediation
55
56- If unauthorized, rotate affected secrets and credentials, revoke tokens or kubeconfigs for the identity, tighten RBAC,
57 and block or isolate the source host at the network edge to the API server where appropriate.
58"""
59references = [
60 "https://attack.mitre.org/techniques/T1552/007/",
61 "https://kubernetes.io/docs/concepts/configuration/secret/",
62]
63risk_score = 73
64rule_id = "a4c8e901-2b7f-4d6e-9a3c-8e1f0d5b6c2a"
65severity = "high"
66tags = [
67 "Data Source: Kubernetes",
68 "Domain: Kubernetes",
69 "Use Case: Threat Detection",
70 "Tactic: Credential Access",
71 "Resources: Investigation Guide",
72]
73timestamp_override = "event.ingested"
74type = "query"
75query = '''
76data_stream.dataset:"kubernetes.audit_logs" and
77event.action:(get or list) and
78kubernetes.audit.objectRef.resource:"secrets" and
79user_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
80source.ip:*
81'''
82
83[[rule.threat]]
84framework = "MITRE ATT&CK"
85
86[[rule.threat.technique]]
87id = "T1552"
88name = "Unsecured Credentials"
89reference = "https://attack.mitre.org/techniques/T1552/"
90
91[[rule.threat.technique.subtechnique]]
92id = "T1552.007"
93name = "Container API"
94reference = "https://attack.mitre.org/techniques/T1552/007/"
95
96[rule.threat.tactic]
97id = "TA0006"
98name = "Credential Access"
99reference = "https://attack.mitre.org/tactics/TA0006/"
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(andkubernetes.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.namespaceandkubernetes.audit.objectRef.namefor high-value objects (service account tokens, cloud IAM bindings, registry pulls, TLS bundles). - Pivot on
source.ipin 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/decisionfor 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.ipin 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.
References
Related rules
- Kubernetes Secret get or list from Node or Pod Service Account
- Kubernetes Secrets List Across Cluster or Sensitive Namespaces
- Kubernetes Rapid Secret GET Activity Against Multiple Objects
- Kubernetes Secret Access via Unusual User Agent
- Service Account Token or Certificate Access Followed by Kubernetes API Request