[New Rule] Kubernetes Suspicious Self-Subject Review (#2067)

* Create discovery_suspicious_self_subject_review.toml Adding new rule * non-ecs-schema fields added and query change to specify fields added non ecs-schema fields for all coming k8s rules and added specific fields to the query instead of using regex * Update discovery_suspicious_self_subject_review.toml * Update rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com> Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com> Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
2022-07-28 15:30:47 -04:00
parent 3d88dc2cf5
commit 026a822840
1 changed files with 62 additions and 0 deletions
@@ -0,0 +1,62 @@
+[metadata]
+creation_date = "2022/06/30"
+integration = "kubernetes"
+maturity = "production"
+min_stack_comments = "Necessary audit log fields not available prior to 8.2"
+min_stack_version = "8.2"
+updated_date = "2022/06/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+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.
+"""
+false_positives = [
+    """
+    An administrator may submit this request as an "impersonatedUser" to determine what privileges a particular service
+    account has been granted. However, an adversary may utilize the same technique as a means to determine the
+    privileges of another token other than that of the compromised account.
+    """,
+]
+index = ["logs-kubernetes.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Suspicious Self-Subject Review"
+note = """## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms",
+    "https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access",
+    "https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/detecting-identity-attacks-in-kubernetes/ba-p/3232340",
+]
+risk_score = 47
+rule_id = "12a2f15d-597e-4334-88ff-38a02cb1330b"
+severity = "medium"
+tags = ["Elastic", "Kubernetes", "Continuous Monitoring", "Discovery"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+kubernetes.audit.verb:"create" 
+and kubernetes.audit.objectRef.resource:("selfsubjectaccessreviews" or "selfsubjectrulesreviews") 
+and kubernetes.audit.user.username:(system\:serviceaccount\:* or system\:node\:*) or kubernetes.audit.impersonatedUser.username:(system\:serviceaccount\:* or system\:node\:*)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1613"
+name = "Container and Resource Discovery"
+reference = "https://attack.mitre.org/techniques/T1613/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+