trustedsec/reelFramework de simulación de phishing y concienciación para campañas basadas en nodos, captura de credenciales, entrega SMTP, CAPTCHA y reproducción opcional de credenciales del navegador.
Marco de simulación de phishing y concienciación en seguridad con flujos de trabajo configurables, gestión de campañas y proxy de credenciales opcional.
cd../deploy.sh; esto configurará los requisitos previos por ti, asumiendo que estás en Ubuntu../start.sh --preload-ml. Esto iniciará los servidores y precargará los modelos de ML que usamos.Obtienes la interfaz de administración (Admin UI) en http://localhost:8000 y el servidor de phishing en http://localhost:1234. Inicio de sesión por defecto: admin / admin123. Cambia la contraseña después del primer inicio de sesión.
Reenvía el puerto 8000 a tu equipo local mediante SSH para acceder al panel de administración. NO expongas el panel de administración ni el servidor Flask (puerto 1234) directamente a Internet.
deploy.sh instalará un servidor Caddy en el mismo host; todo está construido asumiendo que usarás Caddy como proxy inverso. No es obligatorio, pero aquí hay dragones.
Banderas opcionales para start.sh:
--with-caddy — Inicia Caddy mediante Docker (solo para pruebas locales).--preload-ml — Descarga previamente el modelo de detección de phishing (~1.3GB); evita la demora del primer uso al utilizar el plugin Phishing Detector.--reset-db — Restablece la base de datos y la reinicializa.--admin-only — Inicia solo el servidor de administración (puerto 8000).--phishing-only — Inicia solo el servidor de phishing (puerto 1234).--skip-init — Omite la inicialización de la base de datos.--skip-setup — Omite la configuración del venv/dependencias; solo carga .env e inicia los servidores.Sin start.sh, después de instalar las dependencias e inicializar la base de datos, puedes ejecutar ambos servidores con: uv run python -m cli start.
Python: Consulta requirements.txt. El stack principal incluye Flask, SQLAlchemy, Jinja2, Pydantic, Flask-Login, python-jose, passlib, cryptography y Flask-WTF. El plugin Phishing Detector usa transformers y torch. El proxy de credenciales usa Playwright; las integraciones opcionales usan OpenAI/Anthropic y boto3 (AWS Connect).
Desarrollo: requirements-dev.txt añade pytest, pytest-cov y herramientas de prueba relacionadas. Instala con uv pip install -r requirements-dev.txt para ejecutar pruebas y cobertura.
Sistema (producción): El script de despliegue está dirigido a Ubuntu/Debian. Instala uv, Caddy (proxy inverso) y paquetes del sistema como libmagic1. Para el proxy de credenciales, start.sh ejecuta uv run playwright install chromium para instalar Chromium.
Preparación para producción en Ubuntu. Idempotente. Hace lo siguiente:
requirements.txt..env a partir de .env.example si no existe y genera SECRET_KEY y JWT_SECRET_KEY si no están definidas.storage/caddy/data, storage/caddy/config, storage/uploads, storage/templates, storage/assets, instance).--init-db (ejecuta uv run python -m cli init --force).No inicia la aplicación. Para producción: inicia Caddy (proxy inverso) y luego arranca la aplicación con ./start.sh o un administrador de procesos para que todo el tráfico llegue a la aplicación a través del proxy.
Arranque de desarrollo y local. Hace lo siguiente:
.env y garantiza SECRET_KEY y JWT_SECRET_KEY (las genera si hay valores por defecto presentes).requirements.txt.uv run playwright install chromium para el proxy de credenciales.--preload-ml (~1.3GB).--skip-init). Usa --reset-db para borrarla y reinicializarla.--with-caddy (solo para pruebas locales).uv run python -m cli start; usa --admin-only o --phishing-only para ejecutar solo uno.En producción, la aplicación debe ejecutarse detrás de un proxy inverso. No expongas los servidores de desarrollo de Flask directamente a Internet.
El proxy inverso es responsable de la terminación TLS, las cabeceras Host correctas, el enrutamiento por ruta y dominio, y de separar el tráfico de administración del tráfico de campañas. La aplicación escucha en localhost o en un puerto interno; el proxy gestiona el HTTPS público y reenvía al servidor de administración (p. ej. puerto 8000) y al servidor de phishing (p. ej. puerto 1234) según tu configuración.
Recomendado: Usa Caddy como proxy inverso. deploy.sh instala Caddy mediante APT. El proyecto incluye ejemplos de Caddyfile (p. ej. Caddyfile.minimal). Después de ejecutar deploy.sh, inicia Caddy (p. ej. caddy run --config /path/to/Caddyfile.minimal) y luego arranca la aplicación con ./start.sh o un administrador de procesos. Cualquier proxy inverso equivalente (nginx, Traefik, etc.) es aceptable siempre que la aplicación no esté expuesta directamente.
Reel es un marco de simulación de phishing y concienciación en seguridad. Los operadores usan la interfaz de administración (admin UI) para gestionar campañas, flujos de trabajo, plantillas y objetivos. El servidor de phishing sirve las páginas de aterrizaje de las campañas y ejecuta flujos de trabajo—grafos basados en nodos de plugins—en cada petición.
Hay dos puntos de entrada de la aplicación en app.py: create_app() para el servidor de phishing y create_admin_app() para la interfaz de administración. Las campañas pueden ser entrantes (inbound) (un visitante sigue un enlace; los flujos de trabajo GET y POST gestionan las vistas de página y los envíos de formularios) o salientes (outbound) (el sistema envía correos o llamadas mediante flujos de trabajo de envío). Caddy puede usarse para el enrutamiento de campañas basado en dominios. El proxy de credenciales usa Playwright para la automatización del navegador y reproducir las credenciales capturadas en los sitios objetivo.
Un usuario visita una URL de campaña (p. ej. /<campaign_uid>). El servidor de phishing enruta por UID de campaña. Para peticiones GET ejecuta el flujo de trabajo GET de la campaña (p. ej. renderizar página de aterrizaje, CAPTCHA); para peticiones POST ejecuta el flujo de trabajo POST (p. ej. validar la entrada, capturar credenciales, redirigir). Los flujos de trabajo son de tipo campaign y declaran soporte de métodos HTTP (GET, POST o AMBOS). El contexto de ejecución incluye campaign, request, session y variables. La respuesta se toma de claves del contexto como _response_html, _response_redirect o _response_json. Los flujos de trabajo entrantes se usan para páginas de aterrizaje, CAPTCHA, captura de credenciales, redirecciones y registro de eventos.