Threat reportCloud SecurityTL-2026-3664
AWS EKS Forensics: Data Sources and Investigation Tooling (Synacktiv)
AWS EKS Forensics (TL-2026-3664) is a info-severity cloud security threat, first published 2026-10-15. It has no confirmed attribution, affects Amazon Web Services Amazon Elastic Kubernetes Service (EKS), maps to 9 MITRE ATT&CK techniques (T1078.004, T1087.004, T1098.006), and is covered by 9 detection rules and 4 indicators of compromise.
- Severity
- INFOAssessed severity
- CVEs
- 0None referenced
- Techniques
- 9MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 4Indicators of compromise
Key facts for TL-2026-3664
- Threat ID
- TL-2026-3664
- Severity
- INFO
- Status
- TRACKING
- Category
- CLOUD
- First published
- Last reviewed
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Target sectors
- technology, cloud services, finance
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 4
How AWS EKS Forensics works
Synacktiv CSIRT research (Théo Letailleur, 2026-08-24) on investigating compromises of Amazon EKS clusters by correlating Kubernetes control plane logs, worker node/data plane telemetry and AWS-level services (CloudTrail, GuardDuty, VPC Flow Logs). It documents detectable EKS attack behaviours: RBAC reconnaissance, role-modification privilege escalation, static pod persistence, Pod Security Admission violations and node role credential exfiltration.
This is defensive DFIR and detection-engineering research, not an active campaign. The source names no CVE, threat actor, malware family or network IOC, and states no confirmed in-the-wild exploitation. Severity and status are analyst-assigned.
The article describes three investigation layers. The control plane layer comprises five EKS control plane log types (api, audit, authenticator, controllerManager, scheduler), all disabled by default and delivered to the CloudWatch log group /aws/eks/<cluster>/cluster. The audit stream (kube-apiserver-audit-*) carries user.username, verb, objectRef.resource/namespace/name, responseStatus.code, sourceIPs, userAgent and requestObject; the authenticator stream records the IAM-to-RBAC mapping. The data plane layer comes from the amazon-cloudwatch-observability add-on (CloudWatch agent plus Fluent Bit DaemonSet), which populates the /aws/containerinsights/<cluster>/application, host, dataplane and performance log groups. The AWS plane layer comprises CloudTrail (eks.amazonaws.com for administrative API calls and eks-auth.amazonaws.com for pod role assumption), VPC Flow Logs (which have no native Kubernetes context) and GuardDuty (EKS Protection audit-log analysis plus optional eBPF Runtime Monitoring).
Attack behaviours and their artifacts: (1) RBAC reconnaissance appears as bursts of selfsubjectreviews/selfsubjectrulesreviews/selfsubjectaccessreviews requests (for example from kubectl auth can-i --list), detectable with a per-minute count by user. (2) Privilege escalation through role modification appears as update/patch on roles or clusterroles, enabled by the RBAC escalate verb, with the applied rule set recorded in requestObject. (3) Static pod persistence requires setting staticPodPath in /etc/kubernetes/kubelet/config.json and reloading the kubelet. It produces mirror pods on the API server, attributable to system:node:* users with the annotation kubernetes.io/config.source = file, and may raise the GuardDuty finding Execution:Kubernetes/AnomalousBehavior.WorkloadDeployed. (4) Pod Security Admission violations appear as HTTP 403 on pod create. (5) Node identity theft appears as GuardDuty UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS or InsideAWS, and as bursts of Describe*/List*/Get* CloudTrail calls from non-cluster egress, often with an aws-cli user agent. (6) Pod identity compromise through IRSA or EKS Pod Identity is traceable via eks-auth.amazonaws.com events, with no dedicated GuardDuty finding. Anomalous system:node:* identities issuing selfsubjectrulesreviews/accessreviews are also flagged.
Other GuardDuty finding types discussed include PrivilegeEscalation:Kubernetes/PrivilegedContainer, Persistence:Kubernetes/ContainerWithSensitiveMount and Execution:Runtime/ReverseShell. The article also covers deployment modes (standard EKS, EKS Auto Mode with Bottlerocket and a 21-day node lifetime, and Fargate), which affect forensic access. It lists acquisition priorities (live pod state and node-local ServiceAccount tokens under /var/lib/kubelet/pods/*/kubernetes.io~projected/*/token first), notes that EKS-optimized AMIs do not currently ship CRIU support for the kubelet checkpoint API, and gives containment guidance (avoid kubectl delete, use NetworkPolicies/Security Groups, rotate node role credentials and ServiceAccount tokens).
MITRE ATT&CK techniques used in TL-2026-3664
Initial Access
Discovery
T1087.004 Cloud Account; T1580 Cloud Infrastructure Discovery; T1613 Container and Resource Discovery
Persistence
T1098.006 Additional Container Cluster Roles
Privilege Escalation
T1098.006 Additional Container Cluster Roles; T1611 Escape to Host
Credential Access
T1552.005 Cloud Instance Metadata API; T1552.007 Container API
Execution
Affected products and versions in AWS EKS Forensics
- Amazon Web Services — Amazon Elastic Kubernetes Service (EKS)
Vulnerable versions: Clusters without audit logging, Container Insights or GuardDuty EKS Protection
Remediation for AWS EKS Forensics
Immediate actions
- Enable all five EKS control plane log types (api, audit, authenticator, controllerManager, scheduler) and ship them to CloudWatch Logs
- Revoke and rotate node IAM role credentials and ServiceAccount tokens when compromise is suspected
- Contain suspect pods with NetworkPolicies or Security Groups while keeping liveness probes; avoid kubectl delete, which destroys pod state and tokens
Workarounds
- For Fargate, where node access and DaemonSet agents are unavailable, rely on control plane audit logs and CloudTrail
- Alert on selfsubjectrulesreviews bursts, role/clusterrole update/patch, pod-create 403s and system:node:* identities creating workloads
Longer-term hardening
- Deploy the amazon-cloudwatch-observability add-on (Container Insights) for application, host and dataplane logs
- Enable GuardDuty EKS Protection and Runtime Monitoring
- Apply permission boundaries to node and pod IAM roles and enforce Pod Security Admission policies
- Use least-privilege ServiceAccounts and restrict the RBAC escalate verb
Timeline of AWS EKS Forensics
- Retained by the Threadlinqs hunt as a detection-content seed; no CVE or in-the-wild campaign stated
- Article sets out containment guidance, acquisition priority (live pod state and tokens first) and analysis pivots (identity, source IP, cross-layer timeline)
- Article describes static pod persistence via staticPodPath, node role credential exfiltration and IRSA/Pod Identity compromise, with their audit and CloudTrail signatures
- Article provides CloudWatch Logs Insights queries for mutating actions, RBAC reconnaissance bursts, role escalation, PSA 403 denials and anomalous node self-permission checks
- Article documents three evidence layers: EKS control plane logs, Container Insights data plane logs, and AWS-level CloudTrail, VPC Flow Logs and GuardDuty
- Synacktiv publishes 'AWS EKS forensics: data sources and investigation tooling' (author Théo Letailleur, CSIRT category)
Sources cited for AWS EKS Forensics
Detection coverage for TL-2026-3664
As of 2026-10-15, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-3664 across Splunk SPL, Microsoft KQL and Sigma, covering 4 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.