# Intro to forensics in the cloud: A container was compromised. What’s next?

Weak WordPress admin creds led to web shell, privileged container escape, lateral move to data-fetcher pod, and theft of client records from S3.

- Payout: Research
- Severity: high
- Program: WordPress
- Write-up by: Wiz Research
- Disclosed: 2023-04-06
- Write-up quality: 6/10
- Original: https://www.wiz.io/blog/intro-to-forensics-in-the-cloud-a-container-was-compromised-whats-next
- Library page: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-intro-to-forensics-in-the-cloud-a-container-was-compromised-whats-next
- Tags: area:cloud domain:cloud impact:data-leak impact:internal-access kind:research platform:threat-intel sev:high tech:aws tech:docker tech:kubernetes tech:wordpress technique:chained vuln:misconfiguration vuln:privilege-escalation vuln:rce

**Target:** WordPress pod on EKS, privileged container, Docker socket, S3 bucket
**Root cause:** Weak WordPress admin credentials allowed plugin upload of a web shell; the WordPress pod ran privileged, enabling mount-based container escape to the host and Docker socket abuse.
**Steps:**
1. Log into WordPress admin with weak credentials from attacker IP
2. Upload plugin `wp-shell` containing `/wp-content/plugins/wp-shell/rshell.php` web shell
3. Execute reverse shell as www-data (UID 33)
4. Run privileged mount command to escape container to host node
5. Attempt pod creation `legit-stuff` via node identity (blocked by EKS RBAC)
6. Use exposed `docker.sock` to create privileged container with startup backdoor
7. Pivot to `data-fetcher` pod on same node
8. Use `s3-get-object-role` to `GetObject` on `clients-records` in sensitive S3 bucket via AWS CLI
**How found:** Forensics triggered by reverse shell runtime alert; traced attacker IP through Apache logs, runtime mount events, Kubernetes audit logs, Docker container listings, VPC flow logs, and CloudTrail GetObject events.
**Exploitation:** Attacker gained WordPress admin, uploaded web shell plugin, got reverse shell, escaped privileged pod via mount, used Docker socket to create persistent privileged container, moved laterally to data-fetcher pod, and exfiltrated cleartext client-records from S3 using the pod's IAM role.
**Escalation:** Chained web shell -> privileged container escape -> Docker socket persistence -> lateral pod movement -> IAM role abuse for S3 data theft.
**Insight:** Privileged pods with mounted host paths plus exposed docker.sock let a web compromise become node-level persistence; check for privileged containers and docker.sock mounts when a workload is popped.

## Proof of concept (copied exactly from the original report)

**Kubernetes audit log query for pod creation**

```
{$.verb = "create" && $.requestURI= pods && $.user.username ="system:node:ip-192-168-61-188.ec2.internal"}
```

**Docker socket container inspection commands**

```
executing `docker ps` or by looking at the `/var/lib/docker` path on the node (`ls –la /var/lib/docker/containers`)
```