IntermediosimulaciónGoPhishpurple teamawarenessmétricas

Simulación de Phishing: GoPhish, King Phisher y Métricas de Efectividad

Cómo diseñar y ejecutar simulaciones de phishing con GoPhish y King Phisher. Métricas clave (click rate, report rate, credential submit), diseño de campañas progresivas, y cómo medir la mejora del factor humano.

MalwareIntel Research··16 min lectura
Serie: Phishing y Social Engineering — Parte 10

El phishing se combate practicando, no con PowerPoints

El 91% de los ciberataques comienzan con un email de phishing. Las organizaciones gastan millones en gateways de correo, filtros anti-spam y soluciones de sandboxing. Todo eso es necesario, pero insuficiente. El eslabón que ningún appliance puede parchear es el humano que decide hacer clic.

Las simulaciones de phishing son la herramienta que conecta la defensa técnica con el factor humano. No se trata de pillar a empleados desprevenidos ni de generar rankings vergonzantes. Se trata de crear un músculo organizacional: que ante un email sospechoso, la respuesta automática sea reportar, no hacer clic.

Este artículo cubre las herramientas, las métricas, el diseño de campañas progresivas y los errores que convierten un programa de simulación en un ejercicio inútil (o peor, contraproducente).

Training vs testing: dos objetivos distintos

Antes de lanzar la primera campaña, hay que definir el objetivo. Las simulaciones de phishing sirven para dos cosas que se confunden constantemente:

ObjetivoPropósitoCuándo usarlo
TestingMedir el nivel actual de exposiciónBaseline inicial, auditorías, reportes a dirección
TrainingCambiar comportamiento a lo largo del tiempoPrograma continuo, campañas mensuales o trimestrales

Un test sin training posterior es un diagnóstico sin tratamiento. Un training sin métricas es fe ciega. El programa completo combina ambos: medir, entrenar, medir de nuevo, ajustar.

La simulación también cumple una función regulatoria. Normativas como NIS2 (art. 21), DORA (art. 13.6) e ISO 27001 (A.6.3) exigen programas de concienciación con evidencia medible. Una simulación bien documentada genera exactamente esa evidencia.

Herramientas: GoPhish, King Phisher y alternativas

GoPhish (open source, recomendado)

GoPhish es el estándar de facto para simulaciones de phishing open source. Escrito en Go, se despliega como un binario único sin dependencias. Su interfaz web permite gestionar todo el ciclo de una campaña.

Componentes principales:

  • Sending Profiles. Configuración SMTP para enviar los emails. Soporta autenticación, TLS y cabeceras personalizadas.
  • Email Templates. Plantillas HTML con variables (nombre, empresa, cargo). Soporta tracking pixel para medir opens y reescritura automática de URLs para tracking de clicks.
  • Landing Pages. Páginas de destino que simulan formularios de login. Capturan credenciales introducidas (sin almacenarlas en texto claro en producción).
  • Users & Groups. Importación de targets por CSV. Campos: nombre, apellido, email, cargo.
  • Campaigns. Combinación de template + landing + sending profile + grupo de usuarios. Programación por fecha y hora.
  • Dashboard. Resultados en tiempo real: emails enviados, abiertos, clicks, credenciales introducidas, emails reportados.

Instalación básica:

# Descargar última release
wget https://github.com/gophish/gophish/releases/latest/download/gophish-v0.12.1-linux-64bit.zip
unzip gophish-v0.12.1-linux-64bit.zip
cd gophish

# Editar config.json: cambiar listen_url y admin_server
# Lanzar
./gophish

El panel de administración estará en https://localhost:3333 con credenciales por defecto que se muestran en el primer arranque.

Limitaciones de GoPhish: no soporta nativamente campañas de SMS (smishing), no tiene módulo de training integrado (solo simulación), y el reporting es funcional pero básico para presentaciones ejecutivas. Para reporting avanzado, exportar a CSV y procesar con herramientas externas.

King Phisher

King Phisher es una alternativa open source más orientada a red teams. Desarrollada originalmente por SecureState, ofrece funcionalidades que GoPhish no tiene de serie.

Diferencias clave con GoPhish:

CaracterísticaGoPhishKing Phisher
LenguajeGoPython
ArquitecturaBinario únicoCliente-servidor
TemplatesHTML con variablesJinja2 templates avanzados
GeolocalizaciónNo nativoSí, con GeoIP
Clonado de sitiosManualHerramienta integrada
Two-factor harvestingNoPlugin disponible
Calendario de envíoBásicoAvanzado con intervalos aleatorios
PluginsLimitadosSistema de plugins extensible
Facilidad de usoAlta (interfaz web)Media (requiere cliente GTK)

King Phisher destaca en escenarios de red team donde se necesita más control sobre el timing, la evasión de filtros y el tracking granular. Para programas de awareness corporativo, GoPhish suele ser suficiente y más fácil de mantener.

Opciones comerciales

Para organizaciones que necesitan soporte, compliance y reporting ejecutivo, existen plataformas comerciales:

PlataformaTipoFortalezaPrecio aprox.
KnowBe4SaaSMayor biblioteca de templates + módulos de trainingDesde 18 USD/usuario/año
Proofpoint SATSaaSIntegración con gateway Proofpoint, threat intelligenceDesde 25 USD/usuario/año
Cofense PhishMeSaaSBotón de reporte integrado en Outlook, SOC integrationDesde 20 USD/usuario/año
HoxhuntSaaSGamificación, IA adaptativa por usuarioDesde 30 USD/usuario/año
Lucy SecurityOn-premise/SaaSOpen source base, versión EnterpriseDesde 5.000 EUR/año

La decisión entre open source y comercial depende del tamaño de la organización y de si se necesita módulo de training integrado. GoPhish para simulación pura es excelente. Si se necesita e-learning post-simulación (vídeos, quizzes, certificados), las plataformas comerciales lo resuelven mejor.

Diseño de campañas: niveles de dificultad

Un error frecuente es lanzar la misma dificultad siempre. Las campañas deben escalar progresivamente para que el programa tenga impacto real.

Nivel 1: Fácil (baseline)

Objetivo: establecer la línea base. Detectar qué porcentaje de la organización cae ante un phishing genérico.

  • Remitente externo obvio (dominio no corporativo).
  • Asunto genérico: "Su paquete está en camino", "Actualice su contraseña".
  • Errores gramaticales intencionados (2 o 3 faltas visibles).
  • URL visible en el cuerpo del email (sin ocultar con texto).
  • Landing page genérica, sin branding corporativo.

Click rate esperado en primera simulación: 15-30%.

Nivel 2: Medio

Objetivo: simular phishing masivo de calidad media, similar a campañas reales de commodity malware.

  • Remitente con dominio lookalike (ej. empresa-soporte.com en vez de empresa.com).
  • Asunto contextual: "Revisión de nómina Q2", "Incidencia en tu cuenta corporativa".
  • Sin errores gramaticales.
  • URL oculta tras texto ("Acceder a mi cuenta").
  • Landing page con logo corporativo y formulario de login.

Click rate esperado: 8-18%.

Nivel 3: Difícil

Objetivo: simular spear phishing dirigido, usando información pública de la organización.

  • Remitente que suplanta a un compañero real o proveedor conocido.
  • Referencia a proyectos internos, eventos reales o cambios organizativos.
  • Adjunto o link a documento compartido (OneDrive, SharePoint, Google Drive).
  • Urgencia contextual: "El CEO necesita esto antes de las 17:00".
  • Landing page idéntica al portal corporativo con certificado TLS válido.

Click rate esperado: 5-12%.

Nivel 4: APT (solo para equipos de alto riesgo)

Objetivo: evaluar la resiliencia del equipo directivo, finanzas y IT ante ataques dirigidos.

  • OSINT previo del target (LinkedIn, conferencias, publicaciones).
  • Email hiper-personalizado (menciona reuniones recientes, proyectos específicos).
  • Suplantación de identidad de un contacto real con dominio typosquatted.
  • Payload simulado (documento con macro deshabilitada que solo trackea apertura).
  • Timing calculado (lunes 9:00 o viernes 16:00).

Click rate esperado: 3-8%.

Este nivel requiere coordinación previa con legal y RRHH. No se lanza sin aprobación explícita de dirección.

Ejecución: de la teoría al envío

Configuración del sending profile

El sending profile es el punto donde más simulaciones fallan. Si el email llega a spam, la simulación no mide nada útil.

Recomendaciones:

  • Usar un dominio dedicado para simulaciones (no el corporativo). Registrarlo al menos 30 días antes y configurar SPF, DKIM y DMARC.
  • Configurar el servidor SMTP con autenticación TLS. Evitar relays abiertos.
  • Enviar emails de prueba a cuentas internas antes de lanzar la campaña para verificar que no caen en spam.
  • Whitelist del dominio de simulación en el gateway de correo. Esto es polémico: algunos argumentan que falsea resultados. La posición pragmática es que la simulación mide el factor humano, no la eficacia del gateway.

Scheduling y OPSEC

  • Espaciar envíos: no enviar 500 emails en 10 segundos. GoPhish permite configurar un intervalo entre envíos (recomendado: 30-120 segundos por email).
  • Aleatorizar horarios dentro de una ventana (ej. entre 9:00 y 12:00 del martes). Evitar que todos reciban el email al mismo tiempo, lo que facilita que alguien avise al resto.
  • Rotación de templates entre departamentos. Si finanzas recibe el template A, marketing recibe el B. Evita que la difusión interna invalide la simulación.
  • Registrar la campaña con el SOC. El equipo de seguridad debe saber que hay una simulación activa para no investigar los eventos como un incidente real.

Landing pages

La landing page es donde se mide la acción más grave: la introducción de credenciales. Reglas de diseño:

  • Replicar el portal de login objetivo (Microsoft 365, Google Workspace, portal corporativo).
  • Capturar las credenciales pero no almacenarlas. GoPhish registra que el usuario introdujo datos, pero se puede configurar para no guardar el contenido.
  • Redirigir al usuario a una página de training inmediato tras el submit. Este es el momento de máximo impacto educativo: el usuario acaba de caer y está receptivo.
  • Incluir un mensaje claro: "Esto ha sido una simulación de phishing. No te preocupes, tus credenciales no han sido almacenadas. Aquí tienes 3 señales que debiste detectar."

Las 4 métricas que importan

No todas las métricas tienen el mismo valor. El error más común es obsesionarse con el click rate e ignorar la métrica que realmente indica madurez.

1. Open rate (email abierto)

Qué mide: quién abrió el email (vía tracking pixel).

Benchmark: 50-70% en primera campaña. Esta métrica es la menos accionable porque abrir un email no es necesariamente un fallo. El usuario puede abrirlo, detectar que es sospechoso y reportarlo.

Limitación técnica: clientes de email que bloquean imágenes externas no registran la apertura. Outlook con configuración corporativa frecuentemente bloquea el tracking pixel, lo que subestima el open rate real.

2. Click rate (clic en el enlace)

Qué mide: quién hizo clic en el enlace del email de phishing.

Benchmark por industria:

SectorClick rate medio (primera simulación)
Educación25-35%
Sanidad20-28%
Gobierno18-25%
Finanzas12-18%
Tecnología8-15%

Objetivo después de 12 meses de programa: reducir al 3-5% independientemente del sector.

3. Credential submit rate (credenciales introducidas)

Qué mide: quién introdujo credenciales en la landing page falsa.

Benchmark: típicamente entre el 30% y el 60% de los que hicieron clic. Es decir, si el click rate es 20%, el credential submit rate absoluto está entre el 6% y el 12%.

Por qué importa: este es el indicador de daño real. Un clic puede ser curiosidad. Introducir credenciales es comprometer la cuenta.

4. Report rate (reporte como sospechoso)

Qué mide: quién reportó el email al equipo de seguridad (botón de reporte en Outlook, reenvío a [email protected], ticket al SOC).

Benchmark: 5-15% en primera simulación. Objetivo a 12 meses: superior al 40%.

Por qué es la métrica más importante: el report rate mide la respuesta correcta ante phishing. No basta con no caer. Lo que la organización necesita es que los empleados actúen como sensores: que detecten y reporten, para que el SOC pueda bloquear la campaña antes de que otros caigan.

Una organización con 5% de click rate y 5% de report rate está en peor forma que una con 8% de click rate y 45% de report rate. La segunda tiene un sistema de detección humano funcional.

Análisis de resultados: más allá del número

Dashboard de campaña

GoPhish proporciona un dashboard por campaña con timeline de eventos. Para análisis más profundo, exportar los datos y construir vistas adicionales:

  • Comparativa por departamento. Identificar qué áreas necesitan refuerzo. Finanzas y RRHH suelen tener click rates más altos porque reciben más emails legítimos con adjuntos y links.
  • Tendencia temporal. Graficar click rate y report rate a lo largo de 6 o 12 meses. La tendencia importa más que el valor absoluto de cada campaña.
  • Tiempo de clic. Medir cuántos minutos pasan entre la recepción y el clic. Los clics en los primeros 5 minutos indican respuesta impulsiva. Los que ocurren después de 30 minutos indican que el usuario lo pensó y aun así cayó (problema distinto, requiere training diferente).
  • Reincidentes. Usuarios que caen en más de una campaña consecutiva. Estos necesitan intervención individual (no punitiva: formación personalizada o cambio de permisos).

Reporting ejecutivo

Para dirección, las métricas técnicas no comunican. Traducir a lenguaje de riesgo:

  • "El 12% de la organización introduciría credenciales corporativas en una página falsa. Eso equivale a 48 cuentas comprometidas en un ataque real."
  • "El report rate ha subido del 8% al 35% en 6 meses. Cada reporte al SOC permite bloquear la campaña 47 minutos antes de media."
  • "El departamento de finanzas tiene un click rate 3x superior a la media. Recomendamos sesión de training presencial y revisión de permisos en sistemas financieros."

Programa progresivo de 12 meses

Un programa de simulación efectivo escala en dificultad y varía en vector. Plan tipo:

MesDificultadVectorTemplateObjetivo
1FácilEmailPaquete pendiente de entregaBaseline
2FácilEmailActualización de contraseña obligatoriaConfirmar baseline
3MedioEmailNómina Q1 disponible para revisiónMedir mejora post-training M2
4MedioEmailDocumento compartido por compañeroContexto interno
5MedioQR (quishing)Cartel en oficina con QR falsoNuevo vector
6DifícilEmailSuplantación de proveedor ITSpear phishing básico
7MedioSMS (smishing)Verificación de cuenta corporativaNuevo vector
8DifícilEmailInvitación a evento del sectorOSINT básico
9MedioEmailFactura de proveedor conocidoTargeting de finanzas
10DifícilEmailMensaje del CEO con urgenciaAuthority + urgencia
11APTEmailEmail personalizado a directivosOSINT completo
12MixtoMulti-vectorCombinación email + llamada VoIPEvaluación final

Cada simulación va seguida de:

  1. Feedback inmediato a quien cayó (página de training tras el clic).
  2. Comunicación general a la organización con estadísticas anónimas (nunca nombres).
  3. Micro-training de 5 minutos sobre las señales específicas de esa campaña.
  4. Ajuste de dificultad para el mes siguiente según resultados.

Errores comunes que arruinan el programa

1. Shaming de empleados

Publicar rankings de "quién cayó más", enviar emails de reproche, o incluir resultados individuales en evaluaciones de desempeño. Esto destruye la confianza y produce el efecto contrario: los empleados dejan de reportar emails sospechosos por miedo a equivocarse.

Lo correcto: comunicar resultados agregados, ofrecer training adicional voluntario, y celebrar públicamente la mejora del report rate.

2. Escenarios irrealistas

Enviar un email de phishing que ningún atacante real usaría (ej. "Has ganado un iPhone 15" a una empresa de ciberseguridad). Esto invalida la simulación y genera cinismo: "Si esto es lo que nos mandan, el phishing real no puede ser tan difícil."

Lo correcto: basar los templates en campañas reales documentadas. Threat intelligence feeds (como los de MalwareIntel) proporcionan ejemplos de phishing activos que se pueden adaptar.

3. No hacer follow-up de training

Lanzar la simulación, recoger los datos y no hacer nada con ellos. Sin formación posterior, la simulación es puro testing sin valor educativo.

Lo correcto: cada simulación tiene un ciclo de feedback asociado. El momento de máximo impacto educativo es los 60 segundos posteriores a caer en la simulación. La landing page de GoPhish es el lugar ideal para ese micro-training.

4. Frecuencia inadecuada

Hacer una simulación anual "para cumplir con la auditoría" no cambia comportamiento. Tampoco hacer simulaciones semanales, que genera fatiga y desensibilización.

Lo correcto: mensual para grupos de alto riesgo, trimestral para el resto. Variar siempre el template y el vector.

5. Ignorar los falsos positivos

Empleados que reportan emails legítimos como phishing. Si el report rate sube pero el SOC se inunda de falsos positivos, el sistema no escala.

Lo correcto: implementar un proceso de triage eficiente para reportes. Herramientas como Cofense Triage o un workflow en el SIEM permiten clasificar reportes rápidamente. Agradecer cada reporte, incluso los falsos positivos: es mejor un sensor con alta sensibilidad que uno que no detecta nada.

Aspectos legales y éticos

Las simulaciones de phishing operan en un espacio legal delicado. Lo que está permitido varía por jurisdicción, y hacerlo mal puede generar problemas laborales y regulatorios.

Consentimiento y privacidad

  • RGPD (UE/EEE). Los datos de la simulación (quién abrió, quién clicó, quién introdujo credenciales) son datos personales. Se necesita base jurídica: interés legítimo del responsable (art. 6.1.f RGPD) para proteger los sistemas de la organización. Documentar la evaluación de interés legítimo.
  • Consentimiento informado. No se requiere consentimiento previo específico para cada simulación (eso la invalidaría), pero el contrato laboral o la política de seguridad deben incluir una cláusula general sobre ejercicios de seguridad.
  • Minimización de datos. No almacenar las credenciales introducidas. Registrar solo el evento (el usuario introdujo datos en la landing page). GoPhish permite configurar esto.

Comité de empresa (UE)

En la Unión Europea, y especialmente en España, el comité de empresa tiene derechos de información y consulta sobre medidas de control y vigilancia.

  • Informar al comité de empresa antes de lanzar el programa (no cada campaña individual).
  • Explicar que el objetivo es formativo, no disciplinario.
  • Compartir resultados agregados con el comité.
  • Documentar que no se tomarán medidas disciplinarias basadas exclusivamente en resultados de simulaciones.

Coordinación interna

  • Legal. Validar que la política de uso aceptable y el contrato laboral cubren las simulaciones.
  • RRHH. Acordar que los resultados no se usan en evaluaciones de desempeño.
  • SOC. Registrar la campaña para evitar falsos incidentes.
  • Dirección. Aprobación formal por escrito antes de la primera campaña.

Recursos y referencias

Herramientas open source:

  • GoPhish (MIT License, Go, framework de referencia)
  • King Phisher (BSD License, Python)
  • Evilginx2 (para entender el ataque, no para simulaciones de awareness)

Frameworks y estándares:

  • NIST SP 800-50: Building an Information Technology Security Awareness and Training Program
  • ENISA: Phishing Awareness Programme Guidelines (2024)
  • ISO 27001:2022, Anexo A, control A.6.3: Information Security Awareness, Education and Training

Benchmarks de referencia:

  • Verizon DBIR 2025: datos de click rate por industria
  • KnowBe4 Phishing Benchmarking Report (publicación anual, datos de millones de simulaciones)
  • SANS Security Awareness Report: estado de programas de concienciación globales

Artículos relacionados en MalwareIntel:

Preguntas frecuentes

Artículos relacionados

Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.