Kubernetes Denied Service Account Request via Unusual User Agent

  1[metadata]
  2creation_date = "2022/09/13"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2026/01/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects when a service account makes an unauthorized request for resources from the API server via an unusual
 11user agent. Service accounts follow a very predictable pattern of behavior. A service account should never send an
 12unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the
 13cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create
 14resources to facilitate further movement or execution within the cluster.
 15"""
 16false_positives = [
 17    """
 18    Unauthorized requests from service accounts are normal and expected behavior. Analyze the user agent, pod and
 19    other node information to determine if the request is legitimate.
 20    """,
 21]
 22index = ["logs-kubernetes.audit_logs-*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "Kubernetes Denied Service Account Request via Unusual User Agent"
 26note = """## Triage and analysis
 27
 28> **Disclaimer**:
 29> 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.
 30
 31### Investigating Kubernetes Denied Service Account Request via Unusual User Agent
 32
 33Kubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow strict access patterns. Adversaries may exploit compromised service account credentials to probe or manipulate cluster resources, potentially leading to unauthorized access or lateral movement. The detection rule identifies anomalies by flagging unauthorized API requests from service accounts, signaling possible security breaches or misconfigurations.
 34
 35### Possible investigation steps
 36
 37- Review the specific service account involved in the unauthorized request by examining the kubernetes.audit.user.username field to determine which service account was used.
 38- Analyze the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm the request was indeed forbidden and identify the nature of the denied request.
 39- Investigate the source of the request by checking the originating pod or node to understand where the unauthorized request was initiated.
 40- Examine recent activity logs for the service account to identify any unusual patterns or deviations from its typical behavior.
 41- Check for any recent changes or deployments in the cluster that might have affected service account permissions or configurations.
 42- Assess whether there have been any recent security incidents or alerts related to the cluster that could be connected to this unauthorized request.
 43
 44### False positive analysis
 45
 46- Service accounts used for testing or development may generate unauthorized requests if they are not properly configured. Regularly review and update permissions for these accounts to ensure they align with their intended use.
 47- Automated scripts or tools that interact with the Kubernetes API might trigger false positives if they use service accounts with insufficient permissions. Ensure these tools have the necessary permissions or adjust the detection rule to exclude known benign activities.
 48- Misconfigured role-based access control (RBAC) settings can lead to legitimate service accounts being denied access. Conduct periodic audits of RBAC policies to verify that service accounts have appropriate permissions.
 49- Temporary service accounts created for specific tasks might not have the correct permissions, leading to denied requests. Consider excluding these accounts from the rule if they are known to perform non-threatening activities.
 50- Service accounts from third-party integrations or plugins may not have the required permissions, resulting in false positives. Validate the permissions needed for these integrations and adjust the rule to exclude their expected behavior.
 51
 52### Response and remediation
 53
 54- Immediately isolate the affected service account by revoking its access tokens and credentials to prevent further unauthorized API requests.
 55- Conduct a thorough review of the audit logs to identify any other suspicious activities or unauthorized access attempts associated with the compromised service account.
 56- Rotate credentials for the affected service account and any other potentially impacted accounts to mitigate the risk of further exploitation.
 57- Assess and remediate any misconfigurations in role-based access control (RBAC) policies that may have allowed the unauthorized request, ensuring that service accounts have the minimum necessary permissions.
 58- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are required.
 59- Implement enhanced monitoring and alerting for similar unauthorized access attempts to improve detection and response times for future incidents.
 60- Review and update incident response plans to incorporate lessons learned from this event, ensuring readiness for similar threats in the future.
 61
 62## Setup
 63
 64The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 65references = [
 66    "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
 67    "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens",
 68]
 69risk_score = 21
 70rule_id = "63c056a0-339a-11ed-a261-0242ac120002"
 71severity = "low"
 72tags = [
 73  "Data Source: Kubernetes",
 74  "Domain: Kubernetes",
 75  "Use Case: Threat Detection",
 76  "Tactic: Discovery",
 77  "Resources: Investigation Guide",
 78]
 79timestamp_override = "event.ingested"
 80type = "new_terms"
 81query = '''
 82event.dataset:"kubernetes.audit_logs" and
 83kubernetes.audit.user.username:system\:serviceaccount\:* and
 84kubernetes.audit.annotations.authorization_k8s_io/decision:"forbid" and
 85kubernetes.audit.userAgent:(* and not (*kubernetes/$Format or karpenter or csi-secrets-store* or OpenAPI-Generator* or Prometheus* or dashboard* or cilium-agent*))
 86'''
 87
 88[[rule.threat]]
 89framework = "MITRE ATT&CK"
 90
 91[[rule.threat.technique]]
 92id = "T1613"
 93name = "Container and Resource Discovery"
 94reference = "https://attack.mitre.org/techniques/T1613/"
 95
 96[rule.threat.tactic]
 97id = "TA0007"
 98name = "Discovery"
 99reference = "https://attack.mitre.org/tactics/TA0007/"
100
101[rule.new_terms]
102field = "new_terms_fields"
103value = ["kubernetes.audit.userAgent"]
104
105[[rule.new_terms.history_window_start]]
106field = "history_window_start"
107value = "now-7d"