Kubernetes Suspicious Self-Subject Review
This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs. 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.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2022/06/30"
3integration = ["kubernetes"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule detects when a service account or node attempts to enumerate their own permissions via the
11selfsubjectaccessreview or selfsubjectrulesreview APIs. 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.*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "Kubernetes Suspicious Self-Subject Review"
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
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 = 47
70rule_id = "12a2f15d-597e-4334-88ff-38a02cb1330b"
71severity = "medium"
72tags = ["Data Source: Kubernetes", "Tactic: Discovery", "Resources: Investigation Guide"]
73timestamp_override = "event.ingested"
74type = "query"
75
76query = '''
77event.dataset : "kubernetes.audit_logs"
78 and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
79 and kubernetes.audit.verb:"create"
80 and kubernetes.audit.objectRef.resource:("selfsubjectaccessreviews" or "selfsubjectrulesreviews")
81 and (kubernetes.audit.user.username:(system\:serviceaccount\:* or system\:node\:*)
82 or kubernetes.audit.impersonatedUser.username:(system\:serviceaccount\:* or system\:node\:*))
83'''
84
85
86[[rule.threat]]
87framework = "MITRE ATT&CK"
88[[rule.threat.technique]]
89id = "T1613"
90name = "Container and Resource Discovery"
91reference = "https://attack.mitre.org/techniques/T1613/"
92
93
94[rule.threat.tactic]
95id = "TA0007"
96name = "Discovery"
97reference = "https://attack.mitre.org/tactics/TA0007/"
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
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.
References
Related rules
- Kubernetes Denied Service Account Request
- AWS Discovery API Calls via CLI from a Single Resource
- AWS EC2 Deprecated AMI Discovery
- AWS EC2 Multi-Region DescribeInstances API Calls
- AWS STS GetCallerIdentity API Called for the First Time