Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
/.venv
/.env
/dist
/build
/out
/target
/node_modules
/.DS_Store
Thumbs.db
*.pyc
*.swp
/.idea
/.vscode
11 changes: 11 additions & 0 deletions COURSE_SUMMARY.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# Hands-on Docker Hacking
**For editorial board review.**

## Scope
- 11 modules with intro, attack scenario, compliant/noncompliant examples, remediation, lab
- 22 assessments: 3 questions per module quiz + 2 final questions per module
- Files stored in `course/modules/` and `course/quizzes/`
Comment on lines +5 to +7

## Notes
- Draft PR opened: see linked PR
- Target runtime: Docker Desktop / Linux host
35 changes: 13 additions & 22 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,25 +1,16 @@
# Docker Hacking Lab
### EC-Council | Hands-on Docker Hacking Course
**Author: Adonis Jimenez | BizDevStudio**

> Warning: This lab contains intentional vulnerabilities. Run in an isolated environment only.
Hands-on Docker Hacking course.
Comment thread
donny-devops marked this conversation as resolved.

## Quick Start
```
git clone https://github.com/donny-devops/docker-hacking-lab
cd docker-hacking-lab
docker compose up -d
```

## Course Modules
- Module 0: Lab Setup
- Module 1: Docker Internals and Attack Surface
- Module 2: Enumeration and Reconnaissance
- Module 3: Escape via Privileged Flag
- Module 4: Escape via Host Path Mount
- Module 5: Docker Socket Exploitation
- Module 6: TCP Daemon Exploitation
- Module 7: Image and Registry Attacks
- Module 8: Supply Chain Attacks
- Module 9: Network Attacks and Lateral Movement
- Module 10: Runtime Defense
## Course modules
Comment on lines +3 to +5
01 - Privileged Containers
02 - Exposed Container APIs
03 - Container Escape
04 - Container Image Tampering
05 - Insecure Configuration
06 - Denial-of-Service
07 - Kernel Vulnerabilities
08 - Shared Kernel Exploitation
09 - Insecure Container Orchestration
10 - Insecure Container Images
11 - Seccomp, AppArmor, SELinux
22 changes: 22 additions & 0 deletions course/modules/02-exposed-apis.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# Exposed Container APIs
Covers Docker daemon socket/API exposure, auth bypass, TLS, and network exposure risks.

## Attack scenario
Exposing `2375/2376` without auth allows remote host takeover.

## Noncompliant
docker run -d -p 2375:2375 docker:dind

## Compliant
docker run -d -p 127.0.0.1:2376:2376 `
--tlsverify --tlscacert ca.pem --tlscert cert.pem --tlskey key.pem docker:dind
Comment on lines +10 to +12

## Remediation
- Bind to localhost or VPN only.
- Enforce TLS client auth on 2376.
- Firewall-restrict daemon ports.

## Hands-on lab
1. Inspect Docker socket listeners.
2. Confirm remote API auth requirements.
3. Harden with TLS/localhost binding.
21 changes: 21 additions & 0 deletions course/modules/03-container-escape.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Container Escape
Covers breakouts via docker socket, --privileged, host namespaces, and dangerous mounts.

## Attack scenario
A container with /var/run/docker.sock can create privileged sibling containers.

## Noncompliant
docker run -v /var/run/docker.sock:/var/run/docker.sock alpine

## Compliant
docker run --user 1000:1000 --read-only --cap-drop ALL alpine

## Remediation
- Avoid host namespace sharing.
- Drop capabilities; avoid --privileged.
- Use rootless Docker where possible.

## Hands-on lab
1. Run noncompliant container.
2. Attempt docker ps inside.
3. Harden and verify escape path blocked.
21 changes: 21 additions & 0 deletions course/modules/04-image-tampering.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Container Image Tampering
Covers supply-chain attacks, tag mutation, untrusted registries, and image signing.

## Attack scenario
Attacker pushes backdoored tag to public registry; CI auto-deploys it.

## Noncompliant
docker build -t app:latest .

## Compliant
cosign sign --key cosign.key app@sha256:...

## Remediation
- Pin images by digest.
- Sign images with cosign/Sigstore.
- Scan in CI with Trivy/Grype.

## Hands-on lab
1. Inspect image history/layers.
2. Re-pin by digest.
3. Verify provenance/signature.
21 changes: 21 additions & 0 deletions course/modules/05-insecure-config.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Insecure Container Configuration
Covers excessive permissions, writable rootfs, dangerous sysctls, and insecure defaults.

## Attack scenario
Root-owned writable rootfs enables cron/kmodule persistence.

## Noncompliant
docker run --cap-add SYS_ADMIN --read-only=false ubuntu

## Compliant
docker run --user 65532:65532 --read-only --tmpfs /tmp ubuntu

## Remediation
- Run as nonroot.
- Use --read-only with tmpfs.
- Drop capabilities by default.

## Hands-on lab
1. Inspect docker inspect config.
2. Harden runtime flags.
3. Verify no root writable paths.
21 changes: 21 additions & 0 deletions course/modules/06-dos.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Denial-of-Service (DoS)
Covers CPU/memory/PIDs/I/O exhaustion and runtime limits.

## Attack scenario
Fork bomb or memory hog crashes neighboring containers/host.

## Noncompliant
docker run -d --name stress docker-stress

## Compliant
docker run -d --name stress --cpus 0.5 --memory 256m --pids-limit 64 docker-stress

## Remediation
- Set --cpus --memory --pids-limit.
- Use --restart on-failure:5.
- Monitor with cAdvisor/Prometheus.

## Hands-on lab
1. Run stress unconstrained.
2. Observe impact.
3. Apply limits and compare.
21 changes: 21 additions & 0 deletions course/modules/07-kernel-vulns.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Kernel Vulnerabilities
Covers host/runtime CVEs, patching cadence, and isolation limitations.

## Attack scenario
Unpatched kernel enables container-to-host privilege escalation.

## Noncompliant
uname -r # old unpatched kernel

## Compliant
sudo apt install linux-generic-hwe-22.04

## Remediation
- Patch host/runtime on SLA.
- Minimize host kernel modules.
- Evaluate gVisor/Kata for stronger isolation.

## Hands-on lab
1. Check kernel against CVE advisories.
2. Review runtime changelog.
3. Document upgrade plan.
21 changes: 21 additions & 0 deletions course/modules/08-shared-kernel.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Shared Kernel Exploitation
Covers namespace mistakes, /proc exposure, pid=host, and cross-container access.

## Attack scenario
Host PID namespace exposes other containers'/host process data.

## Noncompliant
docker run --pid=host --cap-add SYS_ADMIN alpine

## Compliant
docker run --user nonroot --pid container --cap-drop ALL alpine

## Remediation
- Avoid --pid=host.
- Use container-scoped PID namespaces.
- Enable dmesg_restrict.

## Hands-on lab
1. Run two containers.
2. Inspect /proc with/without host PID.
3. Harden namespace usage.
22 changes: 22 additions & 0 deletions course/modules/09-orchestration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# Insecure Container Orchestration
Covers K8s/Compose misconfigs, default SAs, broad RBAC, and exposed APIs.

## Attack scenario
Default SA has secret-read; app bug leaks cluster secrets.

## Noncompliant
serviceAccountName: default

## Compliant
serviceAccountName: app-sa
automountServiceAccountToken: false

## Remediation
- Dedicated SA per workload.
- Least-privilege RBAC.
- Scan configs with Polaris/Kubesec.

## Hands-on lab
1. Inspect current SA/roles.
2. Create restricted SA.
3. Update deployment and confirm denial.
21 changes: 21 additions & 0 deletions course/modules/10-insecure-images.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Insecure Container Images
Covers outdated bases, malware images, vulnerable packages, and registry hygiene.

## Attack scenario
Malicious image appears as trusted name; CI builds and deploys it.

## Noncompliant
docker build -t app:latest .

## Compliant
trivy image app@sha256:...

## Remediation
- Pin by digest/provenance.
- Scan in CI and deploy gate.
- Trust only approved registries.

## Hands-on lab
1. Build latest-tagged image.
2. Inspect layers/history.
3. Rebuild pinned and scan.
27 changes: 27 additions & 0 deletions course/modules/11-lsm.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# What Seccomp, AppArmor, and SELinux Actually Do
Covers Linux security modules in Docker/Kubernetes, default profiles, custom profiles, and real limitations.

## Seccomp
Restricts syscalls. Docker default blocks ~44 dangerous syscalls.

## AppArmor
Path-based confinement. Uses docker-default on Debian/Ubuntu.

## SELinux
Label-based MAC. Stronger; enabled on RHEL/Fedora.

## Noncompliant
docker run --security-opt seccomp=unconfined ubuntu

## Compliant
docker run --security-opt seccomp=default --security-opt apparmor=docker-default ubuntu

## Remediation
- Keep defaults unless app breaks.
- Trace syscalls before narrowing.
- Combine seccomp + AppArmor/SELinux + capabilities.

## Hands-on lab
1. Inspect container security opts.
2. strace app process.
3. Build minimal custom seccomp JSON and test.
8 changes: 8 additions & 0 deletions course/quizzes/container-escape-final.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Final assessment: Container Escape
## Questions
1. Which option most directly reduces runtime breakout surface?
A) --privileged B) drop caps + seccomp + read-only C) expose 2375 D) host network
2. Which is a reliable signal of insecure images?
A) pinned digest + signed provenance B) latest tag from unknown registry C) small image size D) alpine base
Comment on lines +3 to +6

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛑 Logic Error: Replace generic final assessment questions with module-specific content about container escape techniques. These questions are identical across all final assessments. Questions should assess understanding of Docker socket mounting risks, privileged container dangers, capability management, host namespace sharing, and rootless Docker.

## Answers
1. B 2. B
10 changes: 10 additions & 0 deletions course/quizzes/container-escape.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# Quiz: Container Escape
## Questions
1. Which control is most specific to syscall filtering?
A) AppArmor B) SELinux C) seccomp D) cgroups
2. Exposing Docker API without auth primarily risks:
A) slower builds B) disk usage C) full host compromise D) image pulls failing
3. The strongest container isolation boundary is:
A) shared kernel B) VM parity C) namespace + cgroup + LSM D) Docker socket
Comment thread
donny-devops marked this conversation as resolved.
## Answers
1. C 2. C 3. C
8 changes: 8 additions & 0 deletions course/quizzes/dos-final.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Final assessment: Denial-of-Service (DoS)
## Questions
1. Which option most directly reduces runtime breakout surface?
A) --privileged B) drop caps + seccomp + read-only C) expose 2375 D) host network
2. Which is a reliable signal of insecure images?
A) pinned digest + signed provenance B) latest tag from unknown registry C) small image size D) alpine base
## Answers
1. B 2. B
10 changes: 10 additions & 0 deletions course/quizzes/dos.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# Quiz: Denial-of-Service (DoS)
## Questions
1. Which control is most specific to syscall filtering?
A) AppArmor B) SELinux C) seccomp D) cgroups
2. Exposing Docker API without auth primarily risks:
A) slower builds B) disk usage C) full host compromise D) image pulls failing
3. The strongest container isolation boundary is:
A) shared kernel B) VM parity C) namespace + cgroup + LSM D) Docker socket
Comment thread
donny-devops marked this conversation as resolved.
## Answers
1. C 2. C 3. C
8 changes: 8 additions & 0 deletions course/quizzes/exposed-apis-final.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Final assessment: Exposed Container APIs
## Questions
1. Which option most directly reduces runtime breakout surface?
A) --privileged B) drop caps + seccomp + read-only C) expose 2375 D) host network
2. Which is a reliable signal of insecure images?
A) pinned digest + signed provenance B) latest tag from unknown registry C) small image size D) alpine base
Comment on lines +3 to +6

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛑 Logic Error: Replace generic final assessment questions with module-specific content about exposed container APIs. Both questions appear identical across all final assessments. Question 1 is about runtime breakout (not API exposure), and question 2 is about insecure images (not API exposure). Questions should assess understanding of Docker daemon socket security, TLS configuration, port binding risks, and API authentication mechanisms.

## Answers
1. B 2. B
10 changes: 10 additions & 0 deletions course/quizzes/exposed-apis.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# Quiz: Exposed Container APIs
## Questions
1. Which control is most specific to syscall filtering?
A) AppArmor B) SELinux C) seccomp D) cgroups
2. Exposing Docker API without auth primarily risks:
A) slower builds B) disk usage C) full host compromise D) image pulls failing
3. The strongest container isolation boundary is:
A) shared kernel B) VM parity C) namespace + cgroup + LSM D) Docker socket
Comment thread
donny-devops marked this conversation as resolved.
## Answers
1. C 2. C 3. C
8 changes: 8 additions & 0 deletions course/quizzes/image-tampering-final.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Final assessment: Container Image Tampering
## Questions
1. Which option most directly reduces runtime breakout surface?
A) --privileged B) drop caps + seccomp + read-only C) expose 2375 D) host network
2. Which is a reliable signal of insecure images?
A) pinned digest + signed provenance B) latest tag from unknown registry C) small image size D) alpine base
## Answers
1. B 2. B
10 changes: 10 additions & 0 deletions course/quizzes/image-tampering.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# Quiz: Container Image Tampering
## Questions
1. Which control is most specific to syscall filtering?
A) AppArmor B) SELinux C) seccomp D) cgroups
2. Exposing Docker API without auth primarily risks:
A) slower builds B) disk usage C) full host compromise D) image pulls failing
3. The strongest container isolation boundary is:
A) shared kernel B) VM parity C) namespace + cgroup + LSM D) Docker socket
Comment on lines +3 to +8

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛑 Logic Error: Replace generic questions with module-specific content about image tampering and supply chain security. Questions should address topics like image signing with cosign, digest pinning, registry trust, tag mutation attacks, and vulnerability scanning tools (Trivy/Grype) mentioned in the module.

## Answers
1. C 2. C 3. C
8 changes: 8 additions & 0 deletions course/quizzes/insecure-config-final.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Final assessment: Insecure Container Configuration
## Questions
1. Which option most directly reduces runtime breakout surface?
A) --privileged B) drop caps + seccomp + read-only C) expose 2375 D) host network
2. Which is a reliable signal of insecure images?
A) pinned digest + signed provenance B) latest tag from unknown registry C) small image size D) alpine base
## Answers
1. B 2. B
10 changes: 10 additions & 0 deletions course/quizzes/insecure-config.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# Quiz: Insecure Container Configuration
## Questions
1. Which control is most specific to syscall filtering?
A) AppArmor B) SELinux C) seccomp D) cgroups
2. Exposing Docker API without auth primarily risks:
A) slower builds B) disk usage C) full host compromise D) image pulls failing
3. The strongest container isolation boundary is:
A) shared kernel B) VM parity C) namespace + cgroup + LSM D) Docker socket
## Answers
1. C 2. C 3. C
Loading