How to correlate Kubernetes audit logs with container runtime data
Elastic Security Labs shows how to join Kubernetes audit logs with Defend for Containers runtime data to investigate service account abuse and container escapes.
Elastic Security Labs demonstrates correlating Kubernetes audit logs with Defend for Containers (D4C) runtime telemetry in Elastic. In an Amazon EKS lab, a compromised workload service account performed discovery, read secrets, minted a token, created a privileged pod, and execed into it to attempt a container escape via nsenter and chroot. The escape wrappers appeared only in the decoded Kubernetes audit requestURI, not in runtime process events. The post covers join fields, prebuilt EQL sequence rules, and continues the control-plane correlation thread from the TeamPCP container attack scenario and the Hugging Face intrusion write-up.
The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE
Unit 42 demonstrates that root access on a Kubernetes node lets attackers spoof SPIFFE/SPIRE attestation and harvest co-located workloads' SVIDs.
Palo Alto Networks Unit 42 describes post-exploitation techniques in which an attacker with root on a compromised Kubernetes node spoofs Linux cgroup metadata used by the SPIRE agent during workload attestation, tricking it into issuing a co-located workload's SPIFFE Verifiable Identity Document to an attacker-controlled process. The research shows the core trust assumption of machine-identity systems—that the node is trusted—collapses once root is obtained, exposing all cryptographic identities scoped to that node. Unit 42 released an open-source tool, Spooffe, for defenders to test identity exposure, and notes the technique has not been observed exploited in the wild.
Attack Paths Into VMs in the Cloud
Unit 42 maps attack paths into AWS, Azure, and GCP VMs through intended features like startup scripts and SSH key pushes.
Palo Alto Unit 42 reviewed attack vectors against virtual machine services on AWS, Azure, and GCP, finding that 11% of internet-exposed cloud hosts carry Critical or High severity vulnerabilities. The attack paths rely on legitimate features such as EC2 User Data, VM custom data, EC2 Instance Connect, SSM Run Command, and serial consoles rather than vulnerabilities, and exploiting them requires attackers to first obtain control plane permissions. A compromised VM exposes not only its data but the workload identity and cloud permissions assigned to it, making identity compromise potentially more damaging than data theft. The firm places mitigation responsibility on cloud users and administrators.
A battery storage cyberattack would look exactly like a badly tuned controller
Risk modeling suggests a few hundred compromised grid-scale batteries dispatched through cloud optimizers could trigger blackouts in Texas or Great Britain.
Centrii analysis estimates 1,500 compromised one-megawatt units (5.4% of ERCOT's ~28 GW fleet) or 400 units (about 29% of Great Britain's ~1,400-unit fleet) could destabilize the grids, with modeled damage of $12-65 billion in Texas and a national blackout costing £2-10 billion in Britain. The study puts the probability of a major attack affecting at least one million people by 2031 at 92.1%, dropping to 61.4% with IEC 62443 certification and quarterly drills, based on 10,000 Monte Carlo runs. Because hostile battery swings are phased like legitimate frequency response, control rooms would see nothing unusual; Centrii proposes hunting for a reverse-governor signature where inverter output feeds oscillations. Spain's April 2025 blackout took an expert panel until March 2026 to rule out cyberattack, partly because key plants had no recordings.
Has anybody seen my keys? A key-hierarchy strategy for rack-level security
Oxide's RFD 0301 proposes a rack-level key hierarchy using Shamir secret sharing and a trust quorum to protect data-at-rest keys.
Oxide's request for discussion (RFD 0301) lays out a key-hierarchy strategy for rack-level security, deriving keys from a rack secret protected by Shamir secret sharing across a trust quorum of sleds, with keys exchanged over authenticated sprockets sessions. The document maps which keys protect control-plane data, metrics, Crucible extents, and authentication tokens, and defines open questions on key lifecycle, locality, and compromise handling. Future work includes sealing shares with the root of trust so an attacker would need to steal K whole sleds to reconstruct the rack secret.