Services are connected on a dedicated Docker bridge network (172.20.0.0/16 by default). An attacker container is included to run controlled exploit attempts against the isolated MindsDB service.

Ports (host → container)

• 80 → nginx proxy
• 443 → nginx proxy (if SSL enabled)
• 8080 → reverse-proxy dashboard
• 47334 → MindsDB (API/web)
• 47335 → MindsDB (API/aux)
• 5432 → Postgres (internal, not recommended to expose)
• 9200 → Elasticsearch
• 5601 → Kibana
• 1025/8025 → Mailhog (SMTP/web)

By default Postgres is not intended to be exposed to the public internet. The compose file maps internal services for local lab use.

Quick start (local)

Prerequisites:

• Docker (v20+) and Docker Compose v2+ (docker compose)
• At least 8 GB RAM recommended for a full deployment (Elasticsearch + Kibana require memory)

1. Clone the repo:

2. Copy the example environment file and review secrets:

Important: Ensure DB_PASSWORD in .env matches the password the compose file expects. There is a default in docker-compose.yml (${DB_PASSWORD:-P@ssw0rd123!}). Either set DB_PASSWORD=P@ssw0rd123! in .env or edit docker-compose.yml to use the password you prefer. If they mismatch, MindsDB will fail to connect to Postgres and services will not start correctly.

3. (Optional) Edit .env to tune behaviour (enable/disable features, set attacker listener IP, etc.).

4. Start the lab (full mode):

5. Verify these endpoints once services are healthy:

• MindsDB: curl http://localhost:47334/api/status
• Kibana: http://localhost:5601
• Reverse proxy dashboard: http://localhost:8080

6. To stop and remove containers:

To remove volumes (destructive):

Profiles and resource options

The README references minimal and monitoring profiles. To support these you can either:

• Use profiles: keys in docker-compose.yml to separate services into minimal and monitoring profiles, or
• Create an override compose file such as docker-compose.minimal.yml that disables heavy components (Elasticsearch/Kibana/Wazuh) for low-resource tests.

A suggested minimal test approach is to comment out or skip Elasticsearch/Kibana/Wazuh and run only: mindsdb, postgres, nginx-proxy, and attacker.

How the lab works (detailed)

• Reverse proxy (nginx-proxy): acts as the external-facing endpoint and routes attacker traffic to the vulnerable MindsDB service. The proxy also provides a simple dashboard port (8080) for quick checks.

• MindsDB (vulnerable image): packaged from the vulnerable release referenced in the README. It stores data in Postgres and provides API endpoints which are intentionally vulnerable in older versions.

• Postgres: stores MindsDB configuration and artifacts. Initialization SQL and seed data are provided in configs/postgres/*.sql.

• ELK Stack (Elasticsearch, Logstash, Kibana): collects logs from the proxy and application so you can build detection rules and dashboards.

• Wazuh (optional): security monitoring agent and manager. Included as a placeholder to demonstrate integration; TLS certs and credentials in the config are placeholders and must be provisioned for full functionality.

• Attacker container: an environment with utilities (curl, netcat, python) and mounted exploits/ folder to run challenge scripts from inside the same Docker network (isolated from your host network if desired).

• Backup service: sample container to demonstrate realistic enterprise workflows (backups pulling DB dumps from Postgres).

How to use the lab (practice flow)

1. Start the lab (see Quick start).
2. From your host, or by entering the attacker container (docker compose exec -it attacker /bin/bash), run reconnaissance against the proxy (port 80/8080) and MindsDB API (47334).
3. Progress through learning levels (recon → path traversal → RCE → persistence → defense). This repo intentionally does not include weaponized exploit code. If you want challenge scripts or sanitized PoC steps, we can add them under exploits/ and docs/challenges/ with guidance and safe checks.
4. Observe logs in ELK and use the included Sigma rule (rules/sigma/cve-2026-27483.yml) as a starting point for detections. Create Kibana visualizations to highlight suspicious upload paths, anomalous requests, and unexpected file system activity.

Example: run a basic reconnaissance from the attacker container

Smoke tests

A smoke test script is provided at scripts/smoke_test.sh (if present). It performs the following checks:

• Builds and starts the compose stack
• Waits for MindsDB /api/status to respond
• Verifies nginx reverse-proxy responds on port 8080
• Checks Kibana status endpoint
• Waits for Elasticsearch cluster health (yellow|green)
• Verifies Postgres readiness with pg_isready

Run it locally:

If the smoke test fails, collect logs to smoke_compose_logs.txt and share them for debugging:

Detection & Logging

• Logstash pipeline is provided in configs/logstash/logstash.conf to forward logs to Elasticsearch. The included Sigma rule rules/sigma/cve-2026-27483.yml is a simple example that flags suspicious path traversal patterns (requests containing ..). Use it as a starting point and refine to reduce false positives.

• Create Kibana dashboards to visualize:

  • Upload/request URIs containing traversal patterns
  • Anomalous user agents and source IPs
  • Changes in file system related logs

Troubleshooting (common issues)

• Postgres authentication failures: this is typically due to DB password mismatch between .env and docker-compose.yml. Ensure both agree on the same secret.
• MindsDB errors/500s: check docker compose logs -f mindsdb for stack traces and DB connectivity errors.
• Elasticsearch OOM or not starting: increase host RAM or reduce ES_JAVA_OPTS in docker-compose.yml (example: -Xms256m -Xmx256m) for small hosts.
• Nginx healthcheck failing: ensure proxy config points to the correct internal host (mindsdb:47334) and that the mindsdb container is healthy.

If you need help debugging, run the smoke test and share smoke_compose_logs.txt.

Safety & legal

• The lab includes intentionally vulnerable components. Use only in isolated, non-production environments.
• Do not deploy this lab on publicly routable infrastructure.
• Keep exploit code out of public commits; if you include PoC steps, sanitize them and follow responsible disclosure practices.

Contributing

Contributions are welcome. Suggested ways to help:

• Improve docs under docs/ (deployment, challenges, detection, incident-response)
• Add sanitized challenge scripts in exploits/ with step-by-step learning guides
• Add smoke tests and CI workflows to validate the lab on push/PR

Please open PRs against main and follow the CONTRIBUTING guidelines when you add educational exploit material.

Credits

• Vulnerability discovery: XlabAITeam
• Original PoC: Lohitya Pushkar (thewhiteh4t)
• Lab development: Security Research Community

Made with ❤️ for the security community.