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 = "2024/05/21"
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 = """## Setup
27
28The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
29references = [
30 "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms",
31 "https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access",
32 "https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/detecting-identity-attacks-in-kubernetes/ba-p/3232340",
33]
34risk_score = 47
35rule_id = "12a2f15d-597e-4334-88ff-38a02cb1330b"
36severity = "medium"
37tags = ["Data Source: Kubernetes", "Tactic: Discovery"]
38timestamp_override = "event.ingested"
39type = "query"
40
41query = '''
42event.dataset : "kubernetes.audit_logs"
43 and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
44 and kubernetes.audit.verb:"create"
45 and kubernetes.audit.objectRef.resource:("selfsubjectaccessreviews" or "selfsubjectrulesreviews")
46 and (kubernetes.audit.user.username:(system\:serviceaccount\:* or system\:node\:*)
47 or kubernetes.audit.impersonatedUser.username:(system\:serviceaccount\:* or system\:node\:*))
48'''
49
50
51[[rule.threat]]
52framework = "MITRE ATT&CK"
53[[rule.threat.technique]]
54id = "T1613"
55name = "Container and Resource Discovery"
56reference = "https://attack.mitre.org/techniques/T1613/"
57
58
59[rule.threat.tactic]
60id = "TA0007"
61name = "Discovery"
62reference = "https://attack.mitre.org/tactics/TA0007/"
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
- Azure Blob Container Access Level Modification
- Enumeration of Users or Groups via Built-in Commands
- Hping Process Activity
- Kubernetes Anonymous Request Authorized