afsh4ck/hacklabs

Purpose and Entry Points

HackLabs is an intentionally vulnerable ethical-hacking training platform. The primary Flask application is app.py; local initialization runs through init_db.py. Container startup is defined by Dockerfile, entrypoint.sh, and docker-compose.yml; deploy.sh orchestrates LAN-facing deployment and optional Active Directory infrastructure.

Web Application and Lab Engine

app.py is the central control plane: it serves the lab routes, applies session-selected difficulty behavior, exposes intentionally insecure endpoints, validates flags, and manages account state. HTML rendering is organized around shared layout and individual lab views:

• templates/base.html

• templates/index.html

• templates/labs/

The application is deliberately not a secure service; vulnerable request handling is the product behavior and must remain isolated from public networks.

Accounts, Persistence, and Gamified Progress

SQLite persists both lab-facing seed data and registered-user progress. Schema/bootstrap boundaries are:

• database/schema.sql

• init_db.py

• hacklabs.db

Account pages under templates/account/ support registration, login, profile, and reset flows. Progress, XP, achievements, completion toggling, and certificate eligibility are user-account features, distinct from intentionally vulnerable lab users.

Lab Content and Evidence Delivery

Most web labs pair route logic in app.py with a dedicated instructional UI in templates/labs/, covering OWASP, API, authentication, AI, and exploitation scenarios. Static content provides client behavior and intentionally exposed/downloadable artifacts:

• static/js/main.js

• static/files/

• secret/

Digital-forensics labs are data-driven: templates present questions and evidence links, while artifact files are shipped in evidence/forensic/. Evidence generation utilities live in ad_hoc/forensics/.

Active Directory Lab Environment

AD labs are a separate, real Samba AD Domain Controller environment rather than Flask-only simulations. Its compose topology and container build are:

• docker-compose.active-directory.yml

• ad_hoc/active_directory/Dockerfile

• ad_hoc/active_directory/provision.sh

The AD container provisions domain identities, services, ACLs, flags, and attack paths; the web app’s AD templates provide target details and guided instructions. deploy.sh assigns separate network identity/IPs and updates local name resolution needed for Kerberos.

Host/Container Exploitation Scenarios

The primary container intentionally exposes services and host-like artifacts for labs such as SSH, FTP, SMB, LFI, upload, and privilege escalation. Build/runtime definitions are:

• Dockerfile

• docker-compose.yml

• etc/passwd

Container-escape training is deliberately separated into its own dangerous compose scenario:

• docker-compose.docker-escape.yml

• ad_hoc/docker_escape/victim/Dockerfile

• ad_hoc/docker_escape/dind/Dockerfile

Deployment Boundaries and External Tooling

Python/Flask is the main runtime, with SQLite embedded locally. Docker Compose provides isolated lab infrastructure; macvlan-style LAN deployment is handled by deploy.sh. No external cloud service is required. Learners interact using browser and Kali-compatible offensive/forensic tools; the AD environment additionally exposes DNS, Kerberos, LDAP/LDAPS, and SMB.