Kubernetes Forbidden Creation Request

 1[metadata]
 2creation_date = "2025/06/24"
 3integration = ["kubernetes"]
 4maturity = "production"
 5updated_date = "2025/07/07"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It
11specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service
12account does not have the necessary permissions to perform the action. This activity is commonly associated with
13adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to
14unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation.
15"""
16index = ["logs-kubernetes.audit_logs-*"]
17language = "eql"
18license = "Elastic License v2"
19name = "Kubernetes Forbidden Creation Request"
20note = """ ## Triage and analysis
21
22> **Disclaimer**:
23> 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.
24
25### Investigating Kubernetes Forbidden Creation Request
26
27Kubernetes, a container orchestration platform, manages applications across clusters. It uses authorization policies to control resource creation. Adversaries may exploit misconfigurations or attempt unauthorized resource creation to gain access or escalate privileges. The detection rule identifies denied creation requests, signaling potential unauthorized attempts, by analyzing audit logs for forbidden decisions, aiding in threat detection and response.
28
29### Possible investigation steps
30
31- Review the audit logs to identify the user or service account associated with the forbidden creation request by examining the `kubernetes.audit.user.username` field.
32- Check the `kubernetes.audit.objectRef.resource` field to determine which specific resource type the unauthorized creation attempt was targeting.
33- Investigate the `kubernetes.audit.sourceIPs` field to trace the source IP address of the request, which may help identify the origin of the unauthorized attempt.
34- Analyze the `kubernetes.audit.annotations.authorization_k8s_io/reason` field, if available, to understand why the request was forbidden, providing insights into potential misconfigurations or policy violations.
35- Cross-reference the user or service account with existing role bindings and cluster role bindings to verify if there are any misconfigurations or missing permissions that could have led to the forbidden request.
36- Review recent changes in the cluster's authorization policies or role assignments that might have inadvertently affected permissions, leading to the denied request.
37- Consider correlating this event with other security alerts or logs to identify patterns or repeated unauthorized attempts, which could indicate a broader attack strategy.
38
39### False positive analysis
40
41- Service accounts with limited permissions may trigger false positives when attempting to create resources they are not authorized for. Review service account roles and permissions to ensure they align with intended access levels.
42- Automated processes or scripts that attempt resource creation without proper permissions can result in false positives. Identify and adjust these processes to ensure they operate within their designated permissions.
43- Developers testing new configurations or deployments might inadvertently cause forbidden creation requests. Implement a separate testing environment with appropriate permissions to minimize false positives in production.
44- Changes in authorization policies can lead to temporary false positives as users adjust to new permissions. Communicate policy changes effectively and provide guidance on necessary adjustments to avoid unnecessary alerts.
45- Regularly scheduled tasks or cron jobs that attempt resource creation without updated permissions can trigger false positives. Review and update these tasks to ensure they have the necessary access rights.
46
47### Response and remediation
48
49- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or resource manipulation. This can be done by restricting network access or applying stricter firewall rules temporarily.
50- Identify and revoke any unauthorized or suspicious service accounts or user credentials that attempted the forbidden creation request. Ensure that these accounts are disabled or have their permissions reduced to prevent further misuse.
51- Review and update the Kubernetes Role-Based Access Control (RBAC) policies to ensure that only authorized users and service accounts have the necessary permissions to create resources. This includes verifying that least privilege principles are applied.
52- Conduct a thorough audit of recent Kubernetes audit logs to identify any other unauthorized access attempts or suspicious activities that may have occurred around the same time as the detected alert.
53- Escalate the incident to the security operations team for further investigation and to determine if there is a broader security incident or breach. Provide them with all relevant logs and findings.
54- Implement additional monitoring and alerting for similar unauthorized creation attempts in the future. This can include setting up alerts for any "forbid" decisions in the audit logs to ensure rapid detection and response.
55- Consider deploying additional security tools or services, such as intrusion detection systems or anomaly detection solutions, to enhance the security posture of the Kubernetes environment and prevent similar threats.
56"""
57risk_score = 47
58rule_id = "ec81962e-4bc8-48e6-bfb0-545fc97d8f6a"
59severity = "medium"
60tags = [
61    "Data Source: Kubernetes",
62    "Domain: Kubernetes",
63    "Use Case: Threat Detection",
64    "Tactic: Execution",
65    "Resources: Investigation Guide"
66    ]
67timestamp_override = "event.ingested"
68type = "eql"
69query = '''
70any where host.os.type == "linux" and event.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "create" and
71kubernetes.audit.stage == "ResponseComplete" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "forbid"
72'''
73
74[[rule.threat]]
75framework = "MITRE ATT&CK"
76
77[rule.threat.tactic]
78id = "TA0002"
79name = "Execution"
80reference = "https://attack.mitre.org/tactics/TA0002/"