Kubernetes Suspicious Self-Subject Review via Unusual User Agent

  1[metadata]
  2creation_date = "2022/06/30"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2026/01/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview
 11or selfsubjectrulesreview APIs via an unusual user agent. This is highly unusual behavior for non-human identities like
 12service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to
 13determine what privileges they have to facilitate further movement or execution within the cluster.
 14"""
 15false_positives = [
 16    """
 17    An administrator may submit this request as an "impersonatedUser" to determine what privileges a particular service
 18    account has been granted. However, an adversary may utilize the same technique as a means to determine the
 19    privileges of another token other than that of the compromised account.
 20    """,
 21]
 22index = ["logs-kubernetes.audit_logs-*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "Kubernetes Suspicious Self-Subject Review 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 Suspicious Self-Subject Review via Unusual User Agent
 32
 33Kubernetes uses APIs like selfsubjectaccessreview and selfsubjectrulesreview to allow entities to check their own permissions. While useful for debugging, adversaries can exploit these APIs to assess their access level after compromising service accounts or nodes. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized privilege enumeration attempts.
 34
 35### Possible investigation steps
 36
 37- Review the Kubernetes audit logs to identify the specific service account or node that triggered the alert by examining the kubernetes.audit.user.username or kubernetes.audit.impersonatedUser.username fields.
 38- Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews.
 39- Investigate the source of the API request by looking at the IP address and user agent in the audit logs to determine if the request originated from a known or expected source.
 40- Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior.
 41- Verify if there have been any recent changes to the permissions or roles associated with the service account or node to understand if the access level has been altered.
 42- Cross-reference the alert with any other security events or alerts in the environment to determine if this is part of a broader attack or compromise.
 43
 44### False positive analysis
 45
 46- Service accounts used for automated tasks may trigger this rule if they are programmed to check permissions as part of their routine operations. To handle this, identify these accounts and create exceptions for their specific API calls.
 47- Nodes performing legitimate self-assessment for compliance or security checks might be flagged. Review the node's purpose and, if necessary, whitelist these actions in the detection rule.
 48- Development or testing environments where permissions are frequently checked by service accounts can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific contexts.
 49- Regularly scheduled jobs or scripts that include permission checks as part of their execution may cause alerts. Document these jobs and adjust the rule to ignore these specific, non-threatening behaviors.
 50
 51### Response and remediation
 52
 53- Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster.
 54- Conduct a thorough review of the audit logs to identify any other suspicious activities or access patterns associated with the compromised identity, focusing on any lateral movement or privilege escalation attempts.
 55- Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely.
 56- Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster.
 57- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
 58- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts.
 59- Review and update Kubernetes role-based access control (RBAC) policies to ensure that service accounts and nodes have the minimum necessary permissions, reducing the risk of privilege abuse.
 60
 61## Setup
 62
 63The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 64references = [
 65    "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms",
 66    "https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access",
 67    "https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/detecting-identity-attacks-in-kubernetes/ba-p/3232340",
 68]
 69risk_score = 21
 70rule_id = "12a2f15d-597e-4334-88ff-38a02cb1330b"
 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.annotations.authorization_k8s_io/decision:"allow" and
 84kubernetes.audit.verb:"create" and
 85kubernetes.audit.objectRef.resource:("selfsubjectaccessreviews" or "selfsubjectrulesreviews") and (
 86  kubernetes.audit.user.username:(system\:serviceaccount\:* or system\:node\:*) or
 87  kubernetes.audit.impersonatedUser.username:(system\:serviceaccount\:* or system\:node\:*)
 88) and kubernetes.audit.userAgent:(* and not (*kubernetes/$Format))
 89'''
 90
 91[[rule.threat]]
 92framework = "MITRE ATT&CK"
 93
 94[[rule.threat.technique]]
 95id = "T1613"
 96name = "Container and Resource Discovery"
 97reference = "https://attack.mitre.org/techniques/T1613/"
 98
 99[rule.threat.tactic]
100id = "TA0007"
101name = "Discovery"
102reference = "https://attack.mitre.org/tactics/TA0007/"
103
104[rule.new_terms]
105field = "new_terms_fields"
106value = ["kubernetes.audit.userAgent"]
107
108[[rule.new_terms.history_window_start]]
109field = "history_window_start"
110value = "now-7d"