Kubernetes Denied Service Account Request
This rule detects when a service account makes an unauthorized request for resources from the API server. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate further movement or execution within the cluster.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2022/09/13"
3integration = ["kubernetes"]
4maturity = "production"
5min_stack_comments = "New fields added to Kubernetes Integration"
6min_stack_version = "8.4.0"
7updated_date = "2023/06/22"
8
9[rule]
10author = ["Elastic"]
11description = """
12This rule detects when a service account makes an unauthorized request for resources from the API server. Service
13accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to
14the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may
15have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate
16further movement or execution within the cluster.
17"""
18false_positives = [
19 """
20 Unauthorized requests from service accounts are highly abnormal and more indicative of human behavior or a serious
21 problem within the cluster. This behavior should be investigated further.
22 """,
23]
24index = ["logs-kubernetes.*"]
25language = "kuery"
26license = "Elastic License v2"
27name = "Kubernetes Denied Service Account Request"
28note = """## Setup
29
30The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
31references = [
32 "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
33 "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens",
34]
35risk_score = 47
36rule_id = "63c056a0-339a-11ed-a261-0242ac120002"
37severity = "medium"
38tags = ["Data Source: Kubernetes", "Tactic: Discovery"]
39timestamp_override = "event.ingested"
40type = "query"
41
42query = '''
43event.dataset: "kubernetes.audit_logs"
44 and kubernetes.audit.user.username: system\:serviceaccount\:*
45 and kubernetes.audit.annotations.authorization_k8s_io/decision: "forbid"
46'''
47
48
49[[rule.threat]]
50framework = "MITRE ATT&CK"
51[[rule.threat.technique]]
52id = "T1613"
53name = "Container and Resource Discovery"
54reference = "https://attack.mitre.org/techniques/T1613/"
55
56
57[rule.threat.tactic]
58id = "TA0007"
59name = "Discovery"
60reference = "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 Suspicious Self-Subject Review
- Azure Blob Container Access Level Modification
- Kubernetes Container Created with Excessive Linux Capabilities
- Kubernetes Exposed Service Created With Type NodePort
- Kubernetes Pod Created With HostIPC