trustedsec/reelFramework di simulazione phishing e sensibilizzazione per campagne basate su nodi, cattura di credenziali, consegna SMTP, CAPTCHA e replay facoltativo di credenziali del browser.
Framework di simulazione phishing e sensibilizzazione alla sicurezza con workflow configurabili, gestione delle campagne e proxy opzionale per le credenziali.
cd al suo interno../deploy.sh — questo configurerà i prerequisiti per voi, presupponendo che siate su Ubuntu../start.sh --preload-ml. Questo avvierà i server e precaricherà i modelli ML che utilizziamo.L'interfaccia di amministrazione è disponibile su http://localhost:8000 e il server di phishing su http://localhost:1234. Login predefinito: admin / admin123. Cambiare la password dopo il primo accesso.
Inoltrare la porta 8000 in locale via SSH per accedere al pannello di amministrazione. NON esporre il pannello di amministrazione o il server Flask (porta 1234) direttamente su internet.
deploy.sh installerà un server Caddy sullo stesso host; tutto è pensato presupponendo l'uso di Caddy come reverse proxy. Non siete obbligati, ma qui ci sono draghi.
Flag opzionali per start.sh:
--with-caddy — Avvia Caddy tramite Docker (solo test locali).--preload-ml — Predownload del modello di rilevamento phishing (~1,3 GB); evita il ritardo al primo utilizzo con il plugin Phishing Detector.--reset-db — Reimposta il database e lo reinizializza.--admin-only — Avvia solo il server di amministrazione (porta 8000).--phishing-only — Avvia solo il server di phishing (porta 1234).--skip-init — Salta l'inizializzazione del database.--skip-setup — Salta la configurazione di venv/dipendenze; carica solo .env e avvia i server.Senza start.sh, dopo aver installato le dipendenze e inizializzato il database, è possibile avviare entrambi i server con: uv run python -m cli start.
Python: Vedere requirements.txt. Lo stack principale include Flask, SQLAlchemy, Jinja2, Pydantic, Flask-Login, python-jose, passlib, cryptography e Flask-WTF. Il plugin Phishing Detector utilizza transformers e torch. Il proxy per le credenziali usa Playwright; le integrazioni opzionali usano OpenAI/Anthropic e boto3 (AWS Connect).
Sviluppo: requirements-dev.txt aggiunge pytest, pytest-cov e strumenti di test correlati. Installare con uv pip install -r requirements-dev.txt per eseguire test e coverage.
Sistema (produzione): Lo script di deploy è pensato per Ubuntu/Debian. Installa uv, Caddy (reverse proxy) e pacchetti di sistema come libmagic1. Per il proxy delle credenziali, start.sh esegue uv run playwright install chromium per installare Chromium.
Preparazione alla produzione su Ubuntu. Idempotente. Esegue:
requirements.txt..env da .env.example se mancante e genera SECRET_KEY e JWT_SECRET_KEY se non impostati.storage/caddy/data, storage/caddy/config, storage/uploads, storage/templates, storage/assets, instance).--init-db (esegue uv run python -m cli init --force).Non avvia l'applicazione. Per la produzione: avviare Caddy (reverse proxy), quindi avviare l'app con ./start.sh o un process manager, così tutto il traffico raggiunge l'app tramite il proxy.
Avvio locale e di sviluppo. Esegue:
.env e garantisce SECRET_KEY e JWT_SECRET_KEY (li genera se sono presenti valori predefiniti).requirements.txt.uv run playwright install chromium per il proxy delle credenziali.--preload-ml (~1,3 GB).--skip-init). Usare --reset-db per eliminare e reinizializzare.--with-caddy (solo test locali).uv run python -m cli start; usare --admin-only o --phishing-only per eseguirne uno solo.In produzione, l'applicazione deve essere eseguita dietro un reverse proxy. Non esporre i server di sviluppo Flask direttamente su internet.
Il reverse proxy è responsabile della terminazione TLS, degli header Host corretti, del routing di percorsi e domini e della separazione del traffico admin dal traffico delle campagne. L'app ascolta su localhost o su una porta interna; il proxy gestisce l'HTTPS pubblico e inoltra al server admin (es. porta 8000) e al server di phishing (es. porta 1234) secondo la vostra configurazione.
Consigliato: Usare Caddy come reverse proxy. deploy.sh installa Caddy tramite APT. Il progetto include esempi di Caddyfile (es. Caddyfile.minimal). Dopo aver eseguito deploy.sh, avviare Caddy (es. caddy run --config /path/to/Caddyfile.minimal) e quindi avviare l'applicazione con ./start.sh o un process manager. Qualsiasi reverse proxy equivalente (nginx, Traefik, ecc.) è accettabile, purché l'app non sia esposta direttamente.
Reel è un framework di simulazione phishing e sensibilizzazione alla sicurezza. Gli operatori usano l'interfaccia di amministrazione per gestire campagne, workflow, modelli e target. Il server di phishing serve le landing page delle campagne ed esegue i workflow — grafi a nodi di plugin — a ogni richiesta.
Ci sono due punti di ingresso dell'applicazione in app.py: create_app() per il server di phishing e create_admin_app() per l'interfaccia di amministrazione. Le campagne possono essere inbound (un visitatore segue un link; i workflow GET e POST gestiscono le visualizzazioni di pagina e gli invii di moduli) o outbound (il sistema invia email o chiamate tramite workflow di invio). Caddy può essere usato per il routing basato su dominio delle campagne. Il proxy delle credenziali usa Playwright per l'automazione del browser al fine di riprodurre le credenziali catturate sui siti target.
Un utente visita un URL di campagna (es. /<campaign_uid>). Il server di phishing instrada in base all'UID della campagna. Per le richieste GET esegue il workflow GET della campagna (es. render della landing page, CAPTCHA); per le richieste POST esegue il workflow POST (es. validazione input, cattura credenziali, redirect). I workflow sono di tipo campaign e dichiarano il supporto ai metodi HTTP (GET, POST o BOTH). Il contesto di esecuzione include campaign, request, session e variables. La risposta viene presa da chiavi di contesto come _response_html, _response_redirect o _response_json. I workflow inbound sono usati per landing page, CAPTCHA, cattura credenziali, redirect e logging.
Un operatore esegue un workflow di invio dall'interfaccia di amministrazione, collegato a una campagna (il "Workflow" / workflow di invio della campagna). L'esecutore di invio esegue un singolo workflow di tipo sending: seleziona i target (es. da CSV o utenti tracciati), opzionalmente valida o pre-rende il contenuto, quindi itera sui target — rendendo l'email, applicando i rate limit e inviando tramite un plugin (es. SMTP). Non ci sono GET/POST da visitatore; il workflow genera contenuto e lo invia a un elenco di target.
Riepilogo: