The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE
Root-level compromise of a Kubernetes node allows attackers to spoof cgroup metadata and harvest all SPIFFE/SPIRE workload identities on that node, collapsing identity isolation between co-located workloads. An attacker with root on a Kubernetes node can spoof Linux cgroup metadata used by the SPIRE agent during workload attestation. This causes the agent to issue co-located workloads' SVIDs to attacker-controlled processes, enabling workload impersonation. The Spooffe tool automates this technique to enumerate and extract all identities on a compromised node.
Detection / Hunteropenrouter
Immediate Actions
- Restrict root access to Kubernetes nodes to essential personnel only
- Prohibit privileged containers and direct host access in pod specs
- Audit SPIRE registration entries for weak or easily spoofable selectors
- Monitor for cgroup.procs modifications by non-runtime processes
Key Takeaways
- Root access on a node grants access to all SVIDs scoped to that node
- Spooffe tool automates cgroup spoofing to extract all workload identities
- Attack manipulates /proc/<pid>/cgroup paths to mislead SPIRE agent attestation
- k8s plugin queries kubelet using service account token for pod metadata
- Not observed in the wild; defensive research with open-source PoC tool
Attack Chain
- Initial Access: Attacker obtains root access on a Kubernetes node running SPIRE agent
- Discovery: Attacker scans running workloads and extracts their cgroup paths via /proc
- Spoofing: Attacker creates mock cgroup path and writes own PID into cgroup.procs
- Credential Access: SPIRE agent issues victim workload's SVID to attacker's process
- Lateral Movement: Attacker uses harvested SVIDs to impersonate workloads and access trusted services
Affected Systems
- Kubernetes nodes running SPIRE agent
- Cloud-native environments using SPIFFE/SPIRE
- Linux systems with cgroup v2
- Containers co-located on shared nodes
Detection Availability
No detection rules or queries are published in the source article.
Detection Engineering Assessment
Hypotheses are starting points derived from the article, not findings about your environment; validate against your own telemetry.
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | Cgroup file writes and crictl invocations from interactive shells are visible but root activity is noisy. |
| Network Visibility | Low | SVID requests occur over Unix domain socket; kubelet queries use legitimate service account tokens. |
| Detection Difficulty | Hard | Cgroup manipulation by root blends with legitimate container runtime activity; no network signatures. |
Hunting Hypotheses
| Hypothesis | Telemetry | Stage | FP Risk |
|---|---|---|---|
| Processes writing to /sys/fs/cgroup paths that are not container runtimes indicate cgroup spoofing for identity theft (T1552) | File write events on /sys/fs/cgroup | Credential Access | Medium — container runtimes legitimately modify cgroups |
| SPIRE agent issuing SVIDs to processes whose cgroup paths contain non-standard segments like .FAK (T1078) | SPIRE agent workload API request logs | Credential Access | Low — non-standard cgroup segments are anomalous |
| Interactive shell processes running crictl inspect to enumerate container PIDs (T1613) | Process execution with command line arguments | Discovery | Medium — admins may run crictl for troubleshooting |
Required Log Sources
- Process execution logs
- File system audit logs
- cgroup modification events
- Kubernetes audit logs
- SPIRE agent logs
Key Behavioral Indicators
- Non-container-runtime processes writing to /sys/fs/cgroup
- crictl inspect commands from interactive shell sessions
- SVID fetch requests from processes outside expected cgroup paths
- Multiple SVID fetches from a single process in short timeframe
- Cgroup paths containing .FAKE or non-standard segment names
Control Gaps
- SPIRE agent does not verify cgroup path integrity
- No alerting on cgroup.procs modification by non-runtime processes
- Unix socket SVID requests lack caller verification beyond PID
- Weak selectors like k8s:ns and k8s:sa alone are easily spoofable
False Positive Assessment
Medium — cgroup modifications by container runtimes are normal; distinguishing malicious cgroup writes requires understanding expected runtime behavior.
Recommendations
Suggestions to evaluate against your own environment, tooling, and incident-response procedures — not directives.
Infrastructure Hardening
- Harden Kubernetes nodes per CIS benchmarks
- Use stronger selectors combining k8s and Unix plugin attributes
- Segment workloads across nodes to limit identity blast radius
- Deploy SPIRE agent with host-level protections on cgroup paths
User Protection
- Enforce least-privilege RBAC for Kubernetes service accounts
- Use Pod Security Standards to block privileged containers
- Monitor SPIRE agent logs for unexpected SVID issuance patterns
Security Awareness
- Train platform teams that node compromise equals identity compromise
- Include workload identity spoofing in threat models for SPIFFE/SPIRE
MITRE ATT&CK Mapping
Initial Access
Credential Access
Discovery
Lateral Movement
Plain-Language Summary
Researchers found that if an attacker gains administrator-level access to a server running Kubernetes, they can manipulate internal system data (called cgroups) to trick identity software called SPIRE into giving them the digital identities of other applications on that server. This lets the attacker impersonate those applications and access their permissions. Organizations using SPIRE should restrict administrator access, avoid privileged containers, and assume a compromised server means all its application identities are compromised.
Additional IOCs
- Command Lines:
- Purpose: Request SVID from local SPIRE agent via Unix socket | Tools:
spire-agent| Stage: Credential Access |spire-agent api fetch jwt -audience <audience> -socketPath - Purpose: Retrieve PID of target workload container | Tools:
crictl,jq| Stage: Discovery |crictl inspect <container_id> | jq '.info.pid' - Purpose: Create mock cgroup and write attacker PID into cgroup.procs | Tools:
mkdir,echo,tee| Stage: Defense Evasion |mkdir -p /sys/fs/cgroup/<mock_path> && echo $$ | tee .../cgroup.procs
- Purpose: Request SVID from local SPIRE agent via Unix socket | Tools:
