AWS EKS 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/08/03"
  3integration = ["aws"]
  4maturity = "production"
  5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
  6min_stack_version = "9.6.0"
  7updated_date = "2026/10/20"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Detects read access to Kubernetes Secrets (get/list) with a user agent matching a curated set of non-standard or
 13attacker-leaning clients, for example minimal HTTP tooling, common scripting stacks, default library fingerprints, or
 14distribution-tagged strings associated with offensive-security Linux images. Legitimate in-cluster automation usually
 15presents stable, purpose-specific user agents (for example controller or client-go variants used by known components).
 16"""
 17false_positives = [
 18    """
 19    Operators may use ad hoc HTTP clients, scripts, or penetration-test images during approved exercises or break-glass
 20    maintenance; validate tickets, source IP, and identity before treating as compromise.
 21    """,
 22    """
 23    Internal automation built with generic libraries can resemble suspicious user agents; baseline known jobs and tune
 24    by service account, namespace, or stable source IP allowlists.
 25    """,
 26]
 27from = "now-6m"
 28index = ["logs-aws.eks_audit-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "AWS EKS Secret get or list with Suspicious User Agent"
 32note = """## Triage and analysis
 33
 34### Investigating AWS EKS Secret get or list with Suspicious User Agent
 35The rule matches Kubernetes audit events for **secret** `get`/`list` where **`user_agent.original`** matches a **small
 36allowlist of suspicious patterns** (scripting runtimes, bare HTTP clients, and known offensive-distro markers) and
 37**`source.ip` is populated**. It is meant to highlight **credential access** where the client fingerprint does not look
 38like routine kubectl or well-known controller traffic relative to your environment.
 39
 40### Possible investigation steps
 41
 42- Tie `user.name` (and `aws.eks.audit.impersonatedUser.*` if present) to a human, service account, or cloud identity
 43  and validate whether that principal should use this user-agent profile against the targeted namespaces and secret names.
 44- Review `aws.eks.audit.objectRef.namespace` and `aws.eks.audit.objectRef.name` for high-value objects (service
 45  account tokens, cloud IAM bindings, registry pulls, TLS bundles).
 46- Pivot on `source.ip` in VPC flow, VPN, or proxy logs to determine origin (employee laptop, compromised host, cloud
 47  instance) and correlate with other API bursts or exec activity.
 48- Check `aws.eks.audit.annotations.authorization_k8s_io/decision` for successful reads versus failed probing.
 49
 50### False positive analysis
 51
 52- CI, GitOps, or one-off scripts can emit generic user agents with broad RBAC; exclude stable pipelines and service
 53  accounts after review.
 54- Local API server loopback may still populate `source.ip` in some topologies; compare with expected control-plane paths.
 55
 56### Response and remediation
 57
 58- If unauthorized, rotate affected secrets and credentials, revoke tokens or kubeconfigs for the identity, tighten RBAC,
 59  and block or isolate the source host at the network edge to the API server where appropriate."""
 60references = ["https://kubernetes.io/docs/concepts/configuration/secret/"]
 61risk_score = 73
 62rule_id = "c4014f2d-3d1c-5c74-8d00-e5a942da0ec7"
 63setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 64into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 65pipelines normalize each audit record under `aws.eks.audit.*`.
 66
 67Enable the `audit` control-plane log type on the EKS cluster, send its
 68CloudWatch log group through the AWS integration, and confirm events carry
 69`data_stream.dataset: aws.eks_audit` and
 70`cloud.provider: aws` before enabling this rule.
 71"""
 72severity = "high"
 73tags = [
 74    "Domain: Cloud",
 75    "Domain: Containers",
 76    "Platform: AWS",
 77    "Platform: Kubernetes",
 78    "Data Source: AWS",
 79    "Data Source: Amazon Web Services",
 80    "Data Source: Kubernetes API Server Audit Logs",
 81    "Service: AWS EKS",
 82    "Use Case: Threat Detection",
 83    "Tactic: Credential Access",
 84    "Rule Type: Custom Query (KQL)",
 85    "Resources: Investigation Guide",
 86    "Profile: Beta",
 87]
 88timestamp_override = "event.ingested"
 89type = "query"
 90
 91query = '''
 92data_stream.dataset:"aws.eks_audit" and
 93event.action:(get or list) and event.outcome:success and
 94aws.eks.audit.objectRef.resource:"secrets" and
 95user_agent.original:(
 96  curl* or python* or Python* or wget* or Go-http* or perl* or java* or node* or php* or
 97  *distrib#kali* or *kali-amd64* or *kali-arm64* or Bun* or axios* or undici*
 98) and
 99source.ip:*
100'''
101
102
103[[rule.threat]]
104framework = "MITRE ATT&CK"
105[[rule.threat.technique]]
106id = "T1552"
107name = "Unsecured Credentials"
108reference = "https://attack.mitre.org/techniques/T1552/"
109[[rule.threat.technique.subtechnique]]
110id = "T1552.007"
111name = "Container API"
112reference = "https://attack.mitre.org/techniques/T1552/007/"
113
114
115
116[rule.threat.tactic]
117id = "TA0006"
118name = "Credential Access"
119reference = "https://attack.mitre.org/tactics/TA0006/"

Triage and analysis

Investigating AWS EKS 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 aws.eks.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 aws.eks.audit.objectRef.namespace and aws.eks.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 aws.eks.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.

References

Related rules

to-top