AWS EKS Forbidden Creation Request

  1[metadata]
  2creation_date = "2026/08/03"
  3integration = ["aws"]
  4maturity = "production"
  5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
  6min_stack_version = "9.6.0"
  7updated_date = "2026/10/21"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It
 13specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service
 14account does not have the necessary permissions to perform the action. This activity is commonly associated with
 15adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to
 16unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation.
 17"""
 18from = "now-6m"
 19index = ["logs-aws.eks_audit-*"]
 20language = "eql"
 21license = "Elastic License v2"
 22name = "AWS EKS Forbidden Creation Request"
 23note = """## Triage and analysis
 24
 25> **Disclaimer**:
 26> 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.
 27
 28### Investigating AWS EKS Forbidden Creation Request
 29Kubernetes, 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.
 30
 31### Possible investigation steps
 32
 33- Review the audit logs to identify the user or service account associated with the forbidden creation request by examining the `aws.eks.audit.user.username` field.
 34- Check the `aws.eks.audit.objectRef.resource` field to determine which specific resource type the unauthorized creation attempt was targeting.
 35- Investigate the `aws.eks.audit.sourceIPs` field to trace the source IP address of the request, which may help identify the origin of the unauthorized attempt.
 36- Analyze the `aws.eks.audit.annotations.authorization_k8s_io/reason` field, if available, to understand why the request was forbidden, providing insights into potential misconfigurations or policy violations.
 37- 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.
 38- Review recent changes in the cluster's authorization policies or role assignments that might have inadvertently affected permissions, leading to the denied request.
 39- Consider correlating this event with other security alerts or logs to identify patterns or repeated unauthorized attempts, which could indicate a broader attack strategy.
 40
 41### False positive analysis
 42
 43- 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.
 44- 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.
 45- 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.
 46- 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.
 47- 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.
 48
 49### Response and remediation
 50
 51- 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.
 52- 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.
 53- 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.
 54- 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.
 55- 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.
 56- 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.
 57- 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."""
 58risk_score = 47
 59rule_id = "85fe3b35-cc25-5a12-9bad-2a9ba0e73d98"
 60setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 61into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 62pipelines normalize each audit record under `aws.eks.audit.*`.
 63
 64Enable the `audit` control-plane log type on the EKS cluster, send its
 65CloudWatch log group through the AWS integration, and confirm events carry
 66`data_stream.dataset: aws.eks_audit` and
 67`cloud.provider: aws` before enabling this rule.
 68"""
 69severity = "medium"
 70tags = [
 71    "Domain: Cloud",
 72    "Domain: Containers",
 73    "Platform: AWS",
 74    "Platform: Kubernetes",
 75    "Data Source: AWS",
 76    "Data Source: Amazon Web Services",
 77    "Data Source: Kubernetes API Server Audit Logs",
 78    "Service: AWS EKS",
 79    "Use Case: Threat Detection",
 80    "Tactic: Execution",
 81    "Rule Type: Event Correlation (EQL)",
 82    "Resources: Investigation Guide",
 83    "Profile: Beta",
 84]
 85timestamp_override = "event.ingested"
 86type = "eql"
 87
 88query = '''
 89any where data_stream.dataset == "aws.eks_audit" and aws.eks.audit.verb == "create" and
 90aws.eks.audit.stage == "ResponseComplete" and `aws.eks.audit.annotations.authorization_k8s_io/decision` == "forbid" and
 91user.name != null and not user.name in ("system:kube-scheduler", "system:kube-controller-manager")
 92'''
 93
 94
 95[[rule.threat]]
 96framework = "MITRE ATT&CK"
 97
 98[rule.threat.tactic]
 99id = "TA0002"
100name = "Execution"
101reference = "https://attack.mitre.org/tactics/TA0002/"