# AWS EKS Forensics: Data Sources and Investigation Tooling (Synacktiv)

> 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.

- **Published:** 2026-10-15T20:31:33Z
- **Last reviewed:** 2026-10-15T20:31:33Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-3664
- **ID:** TL-2026-3664
- **Severity:** INFO
- **Category:** CLOUD
- **Status:** TRACKING
- **Detections:** 9 · **IOCs:** 4 (full data via the Threadlinqs MCP server — Purple tier)

## Description

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

- T1078.004 Cloud Accounts
- T1613 Container and Resource Discovery
- T1087.004 Cloud Account
- T1580 Cloud Infrastructure Discovery
- T1098.006 Additional Container Cluster Roles
- T1098.006 Additional Container Cluster Roles
- T1610 Deploy Container
- T1611 Escape to Host
- T1552.005 Cloud Instance Metadata API
- T1552.007 Container API

## Sources

- [AWS EKS forensics: data sources and investigation tooling (Synacktiv)](https://www.synacktiv.com/en/publications/aws-eks-forensics-data-sources-and-investigation-tooling.html)
- [Synacktiv Publications](https://www.synacktiv.com/en/publications)
- [Amazon EKS control plane logging](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
- [Amazon GuardDuty Kubernetes findings types](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-kubernetes.html)
- [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)
- [Threat Matrix for Kubernetes (Microsoft)](https://www.microsoft.com/en-us/security/blog/2020/04/02/attack-matrix-kubernetes/)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-3664