AWS EKS Unusual Decision by User Agent

This rule detects unusual request responses in Kubernetes audit logs through the use of the "new_terms" rule type. In production environments, default API requests are typically made by system components or trusted users, who are expected to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes environment.

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/21"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects unusual request responses in Kubernetes audit logs through the use of the "new_terms" rule type. In
 13production environments, default API requests are typically made by system components or trusted users, who are expected
 14to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and
 15response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes
 16environment.
 17"""
 18from = "now-6m"
 19index = ["logs-aws.eks_audit-*"]
 20language = "kuery"
 21license = "Elastic License v2"
 22name = "AWS EKS Unusual Decision by User Agent"
 23note = """## Triage and analysis
 24
 25> **Disclaimer**:
 26> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 27
 28### Investigating AWS EKS Unusual Decision by User Agent
 29Kubernetes orchestrates containerized applications, relying on API requests for operations. Typically, these requests originate from system components or trusted users with consistent user agents. Adversaries might exploit this by using atypical user agents to mask unauthorized access or misconfigurations. The detection rule identifies anomalies in user agents and response annotations, signaling potential threats in the Kubernetes environment.
 30
 31### Possible investigation steps
 32
 33- Review the Kubernetes audit logs for entries where the user_agent.original field is present to identify any unusual or unexpected user agents.
 34- Cross-reference the identified user agents with known system components and trusted users to determine if the user agent is legitimate or potentially malicious.
 35- Examine the aws.eks.audit.stage field for "ResponseComplete" entries to understand the context and outcome of the requests associated with the unusual user agent.
 36- Investigate the source IP addresses and associated usernames in the audit logs to identify any patterns or anomalies that could indicate unauthorized access.
 37- Check for any recent changes or deployments in the Kubernetes environment that might explain the presence of unusual user agents or unexpected behavior.
 38- Assess the risk and impact of the detected anomaly by considering the sensitivity of the accessed resources and the permissions associated with the user account involved.
 39
 40### False positive analysis
 41
 42- System components or trusted users with legitimate but infrequent user agents may trigger the rule. To manage this, identify these user agents and add them to an exception list to prevent unnecessary alerts.
 43- Automated scripts or tools used for maintenance or monitoring might use unique user agents. Regularly review these tools and update the exception list to include their user agents if they are verified as non-threatening.
 44- New deployments or updates to Kubernetes components can introduce new user agents temporarily. Monitor these changes and adjust the rule exceptions accordingly to accommodate expected behavior during these periods.
 45- Third-party integrations or plugins may use distinct user agents. Validate these integrations and, if deemed safe, include their user agents in the exception list to reduce false positives.
 46- On Amazon EKS, `user.name` is the username mapped by the cluster access entry (or `aws-auth` entry) of the calling IAM principal. When the access entry sets no `username`, the audit log records the raw principal ARN instead: `arn:aws:iam::<account>:user/<name>` for IAM users and `arn:aws:sts::<account>:assumed-role/<role>/<session>` for assumed roles, so every new role session is a new value for the identity fields this rule learns terms from. Set a stable `username` on access entries used by automation, or expect a first-seen alert per session.
 47
 48### Response and remediation
 49
 50- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary.
 51- Review and terminate any suspicious or unauthorized sessions identified in the audit logs to cut off any active malicious activity.
 52- Revoke and rotate credentials associated with the compromised user agent to prevent further unauthorized access using the same credentials.
 53- Conduct a thorough review of the affected system's configurations and permissions to identify and rectify any misconfigurations or overly permissive access controls.
 54- Implement additional monitoring and logging for the affected systems to detect any further anomalies or unauthorized activities promptly.
 55- Escalate the incident to the security operations team for a comprehensive investigation and to determine if any data exfiltration or further compromise has occurred.
 56- Update and enhance detection rules and alerts to better identify similar anomalies in user agents and response annotations in the future, ensuring quicker response times."""
 57risk_score = 21
 58rule_id = "437531d2-48a8-5934-8122-8b676582f311"
 59setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 60into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 61pipelines normalize each audit record under `aws.eks.audit.*`.
 62
 63Enable the `audit` control-plane log type on the EKS cluster, send its
 64CloudWatch log group through the AWS integration, and confirm events carry
 65`data_stream.dataset: aws.eks_audit` and
 66`cloud.provider: aws` before enabling this rule.
 67"""
 68severity = "low"
 69tags = [
 70    "Domain: Cloud",
 71    "Domain: Containers",
 72    "Platform: AWS",
 73    "Platform: Kubernetes",
 74    "Data Source: AWS",
 75    "Data Source: Amazon Web Services",
 76    "Data Source: Kubernetes API Server Audit Logs",
 77    "Service: AWS EKS",
 78    "Use Case: Threat Detection",
 79    "Tactic: Execution",
 80    "Tactic: Defense Evasion",
 81    "Tactic: Initial Access",
 82    "Rule Type: New Terms",
 83    "Resources: Investigation Guide",
 84    "Profile: Beta",
 85]
 86timestamp_override = "event.ingested"
 87type = "new_terms"
 88
 89query = '''
 90data_stream.dataset:"aws.eks_audit" and aws.eks.audit.stage:"ResponseComplete" and
 91user_agent.original:(* and not (*kubernetes/$Format)) and
 92not (
 93  user_agent.original:kubelet* and
 94  not aws.eks.audit.objectRef.resource:(pods or nodes or csinodes or csidrivers or configmaps or secrets or events or leases or runtimeclasses) and
 95  aws.eks.audit.verb:(get or list or watch or patch)
 96)
 97'''
 98
 99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102
103[rule.threat.tactic]
104id = "TA0002"
105name = "Execution"
106reference = "https://attack.mitre.org/tactics/TA0002/"
107[[rule.threat]]
108framework = "MITRE ATT&CK"
109[[rule.threat.technique]]
110id = "T1078"
111name = "Valid Accounts"
112reference = "https://attack.mitre.org/techniques/T1078/"
113
114
115[rule.threat.tactic]
116id = "TA0005"
117name = "Defense Evasion"
118reference = "https://attack.mitre.org/tactics/TA0005/"
119[[rule.threat]]
120framework = "MITRE ATT&CK"
121[[rule.threat.technique]]
122id = "T1078"
123name = "Valid Accounts"
124reference = "https://attack.mitre.org/techniques/T1078/"
125
126
127[rule.threat.tactic]
128id = "TA0001"
129name = "Initial Access"
130reference = "https://attack.mitre.org/tactics/TA0001/"
131
132[rule.new_terms]
133field = "new_terms_fields"
134value = [
135    "aws.eks.audit.annotations.authorization_k8s_io/decision",
136    "aws.eks.audit.user.username",
137    "user_agent.original",
138]
139[[rule.new_terms.history_window_start]]
140field = "history_window_start"
141value = "now-10d"

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating AWS EKS Unusual Decision by User Agent

Kubernetes orchestrates containerized applications, relying on API requests for operations. Typically, these requests originate from system components or trusted users with consistent user agents. Adversaries might exploit this by using atypical user agents to mask unauthorized access or misconfigurations. The detection rule identifies anomalies in user agents and response annotations, signaling potential threats in the Kubernetes environment.

Possible investigation steps

  • Review the Kubernetes audit logs for entries where the user_agent.original field is present to identify any unusual or unexpected user agents.
  • Cross-reference the identified user agents with known system components and trusted users to determine if the user agent is legitimate or potentially malicious.
  • Examine the aws.eks.audit.stage field for "ResponseComplete" entries to understand the context and outcome of the requests associated with the unusual user agent.
  • Investigate the source IP addresses and associated usernames in the audit logs to identify any patterns or anomalies that could indicate unauthorized access.
  • Check for any recent changes or deployments in the Kubernetes environment that might explain the presence of unusual user agents or unexpected behavior.
  • Assess the risk and impact of the detected anomaly by considering the sensitivity of the accessed resources and the permissions associated with the user account involved.

False positive analysis

  • System components or trusted users with legitimate but infrequent user agents may trigger the rule. To manage this, identify these user agents and add them to an exception list to prevent unnecessary alerts.
  • Automated scripts or tools used for maintenance or monitoring might use unique user agents. Regularly review these tools and update the exception list to include their user agents if they are verified as non-threatening.
  • New deployments or updates to Kubernetes components can introduce new user agents temporarily. Monitor these changes and adjust the rule exceptions accordingly to accommodate expected behavior during these periods.
  • Third-party integrations or plugins may use distinct user agents. Validate these integrations and, if deemed safe, include their user agents in the exception list to reduce false positives.
  • On Amazon EKS, user.name is the username mapped by the cluster access entry (or aws-auth entry) of the calling IAM principal. When the access entry sets no username, the audit log records the raw principal ARN instead: arn:aws:iam::<account>:user/<name> for IAM users and arn:aws:sts::<account>:assumed-role/<role>/<session> for assumed roles, so every new role session is a new value for the identity fields this rule learns terms from. Set a stable username on access entries used by automation, or expect a first-seen alert per session.

Response and remediation

  • Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary.
  • Review and terminate any suspicious or unauthorized sessions identified in the audit logs to cut off any active malicious activity.
  • Revoke and rotate credentials associated with the compromised user agent to prevent further unauthorized access using the same credentials.
  • Conduct a thorough review of the affected system's configurations and permissions to identify and rectify any misconfigurations or overly permissive access controls.
  • Implement additional monitoring and logging for the affected systems to detect any further anomalies or unauthorized activities promptly.
  • Escalate the incident to the security operations team for a comprehensive investigation and to determine if any data exfiltration or further compromise has occurred.
  • Update and enhance detection rules and alerts to better identify similar anomalies in user agents and response annotations in the future, ensuring quicker response times.

Related rules

to-top