From 963d01ba89dbebf8e2ed0f3d9f954c308c192908 Mon Sep 17 00:00:00 2001
From: Isai <59296946+imays11@users.noreply.github.com>
Date: Mon, 19 Sep 2022 13:35:37 -0400
Subject: [PATCH] [New Rule] Kubernetes Suspicious Assignment of Controller
 Service Account (#2298)

* [New Rule] Kubernetes Suspicious Assignment of Controller Service Account

Issues
--
#2034

Summary
--
This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control.

* Update privilege_escalation_suspicious_assignment_of_controller_service_account.toml

updated query after testing

* Update non-ecs-schema.json

added new field used in query update

Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
---
 detection_rules/etc/non-ecs-schema.json       |  3 +
 ...ignment_of_controller_service_account.toml | 67 +++++++++++++++++++
 2 files changed, 70 insertions(+)
 create mode 100644 rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml

diff --git a/detection_rules/etc/non-ecs-schema.json b/detection_rules/etc/non-ecs-schema.json
index 45334cc79..60f96791c 100644
--- a/detection_rules/etc/non-ecs-schema.json
+++ b/detection_rules/etc/non-ecs-schema.json
@@ -84,6 +84,9 @@
     "kubernetes.audit.requestObject.spec.type": "keyword",
     "kubernetes.audit.requestObject.rules.resources": "keyword",
     "kubernetes.audit.requestObject.rules.verb": "keyword",
+    "kubernetes.audit.objectRef.namespace": "keyword",
+    "kubernetes.audit.objectRef.serviceAccountName": "keyword",
+    "kubernetes.audit.requestObject.spec.serviceAccountName": "keyword",
     "kubernetes.audit.responseStatus.reason": "keyword"
   }
 }
diff --git a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
new file mode 100644
index 000000000..4a2cfde1d
--- /dev/null
+++ b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
@@ -0,0 +1,67 @@
+[metadata]
+creation_date = "2022/09/13"
+integration = "kubernetes"
+maturity = "production"
+min_stack_comments = "New fields added: required_fields, related_integrations, setup"
+min_stack_version = "8.3.0"
+updated_date = "2022/09/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system
+namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in
+the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate
+adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system
+namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate
+privileges and gain complete cluster control.
+"""
+false_positives = [
+    """
+    Controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few
+    legitimate use-cases and should result in very few false positives.
+    """,
+]
+index = ["logs-kubernetes.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Suspicious Assignment of Controller Service Account"
+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",
+]
+risk_score = 47
+rule_id = "63c05204-339a-11ed-a261-0242ac120002"
+severity = "medium"
+tags = ["Elastic", "Kubernetes", "Continuous Monitoring", "Execution", "Privilege Escalation"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset : "kubernetes.audit_logs" and kubernetes.audit.verb : "create" 
+  and kubernetes.audit.objectRef.resource : "pods"
+  and kubernetes.audit.objectRef.namespace : "kube-system"
+  and kubernetes.audit.requestObject.spec.serviceAccountName:*controller
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.001"
+name = "Default Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+