[New Rule] AWS EKS Access Entry Created Then Deleted by Same Identity

[bryans3c]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/1066

Summary - What I changed

Added an eql sequence rule that detects an EKS access entry created and deleted by the same identity within 10 minutes — a pattern indicative of a temporary privilege grant used to install persistent Kubernetes-level backdoors before removing the CloudTrail evidence of the initial grant.

Why it matters

EKS access entries map IAM principals to Kubernetes access policies. An adversary with eks:CreateAccessEntry and eks:DeleteAccessEntry can temporarily grant themselves cluster-admin level access, use that access to create persistent RBAC resources (ClusterRoleBindings, privileged ServiceAccounts, rogue DaemonSets), then delete the access entry to remove the CloudTrail evidence of the initial grant — while retaining Kubernetes-level access through the backdoor RBAC objects. The deletion within a short window of creation is the key behavioral indicator separating this from legitimate lifecycle operations.

• https://www.wiz.io/blog/new-attack-vectors-emerge-via-recent-eks-access-entries-and-pod-identity-features
• https://securitylabs.datadoghq.com/articles/eks-cluster-access-management-deep-dive/

How To Test

Query to verify in our TRaDE stack:

sequence by user.name with maxspan=10m
  [any where event.provider == "eks.amazonaws.com"
   and event.action == "CreateAccessEntry"
   and event.outcome == "success"]
  [any where event.provider == "eks.amazonaws.com"
   and event.action == "DeleteAccessEntry"
   and event.outcome == "success"]

Checklist

• Added a label for the type of pr: Rule: New
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[Copilot]

Pull request overview

Adds a new AWS CloudTrail EQL sequence detection rule to identify suspicious Amazon EKS access entries that are created and then deleted by the same identity within a short window—behavior consistent with temporary privilege grants used to establish Kubernetes persistence before removing evidence.

Changes:

• Introduces a new EQL sequence rule for CreateAccessEntry followed by DeleteAccessEntry within maxspan=10m.
• Adds an investigation guide, references, and investigation fields tailored to EKS access entry abuse.
• Defines initial tagging and ATT&CK mappings for the new detection.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[terrancedejesus]

LGTM. Agreed on medium, and the guide needs a false positives section. Also +1 on tagging Domain/Platform Kubernetes.