SelfSubjectAccessReviews

Elastic #

• Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity source low: Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC before privilege escalation.T1069, T1069.003, T1613
  Investigation guide

  Triage and analysis#

  Investigating Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity#

  AKS kube-audit events are carried under the flattened azure.platformlogs.properties.log.* subtree and share the ARM operation event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read. A selfsubjectaccessreviews or selfsubjectrulesreviews create lets the caller enumerate its own effective permissions. Service account and node identities issuing these reviews outside of known controllers can indicate a stolen token mapping out what it can reach.

  Possible investigation steps#

  • Confirm the acting identity in azure.platformlogs.properties.log.user.username and its groups in azure.platformlogs.properties.log.user.groups, and whether that service account or node routinely performs self-subject reviews. Check azure.platformlogs.properties.log.impersonatedUser.username: when populated, the review was issued via impersonation (e.g. kubectl auth can-i --as=<service account>) and the real actor is the impersonating user, not the service account in user.username.
  • Review azure.platformlogs.properties.log.objectRef.resource (selfsubjectaccessreviews or selfsubjectrulesreviews) and the azure.platformlogs.properties.log.requestObject to see what access was checked, plus the API path in azure.platformlogs.properties.log.requestURI. Inspect azure.platformlogs.properties.log.userAgent to distinguish interactive tooling (kubectl) from custom recon tooling or in-cluster SDKs.
  • Evaluate the source in azure.platformlogs.properties.log.sourceIPs. Control-plane and in-cluster agents use loopback (127.0.0.1/::1) or pod-network addresses (e.g. 10.244.0.0/16); an external caller wielding a service account token is more suspicious. Pivot on the source for related API activity, denied requests, exec sessions, or RBAC changes from the same identity.

  False positive analysis#

  • Known observability or workflow controllers may issue self-subject reviews; extend exclusions for validated identities. Azure Arc's agent service accounts (system:serviceaccount:azure-arc:*) legitimately submit these reviews and are already excluded; add other validated platform controllers as they are baselined.
  • Admin impersonation workflows can trigger this via an impersonated service account; validate the impersonating user in azure.platformlogs.properties.log.impersonatedUser.username.

  Response and remediation#

  • If unauthorized, revoke the service account token and review the RBAC bindings granted to it.
  • Correlate with any successful privileged actions the identity performed after the review.
  • Collect kube-audit and identity artifacts per incident response procedures.
• GKE Suspicious Self-Subject Review via Service Account source low: Detects GKE service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC.T1069, T1069.003, T1613
  Investigation guide

  Triage and analysis#

  Investigating GKE Suspicious Self-Subject Review via Service Account#

  Review the calling service account or node identity and subsequent API activity.

  Investigation steps#

  • Confirm user.email and event.action (selfsubjectaccessreviews or selfsubjectrulesreviews).
  • Correlate with denied requests, secret access, or RBAC changes from the same identity.

  False positives#

  • Known observability or workflow controllers; extend exclusions if needed.

  Setup#

  The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

• Kubernetes Suspicious Self-Subject Review via Unusual User Agent source low: This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs via an unusual user agent. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster.T1069, T1069.003, T1613
  Investigation guide

  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 Kubernetes Suspicious Self-Subject Review via Unusual User Agent#

  Kubernetes 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.

  Possible investigation steps#

  • 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.
  • Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews.
  • 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.
  • Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior.
  • 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.
  • 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.

  False positive analysis#

  • 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.
  • 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.
  • 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.
  • 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.

  Response and remediation#

  • Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster.
  • 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.
  • Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely.
  • Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster.
  • Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
  • Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts.
  • 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.

  Setup#

  The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.

Show 1 more (4 total) on the rules page