Evilginx2 es una herramienta de ingeniería social y simulación de ataques de hombre en el medio (Man-in-the-Middle o MitM) diseñada para evaluar la efectividad del aprendizaje de usuarios y probar la seguridad de la autenticación de múltiples factores (MFA/2FA) mediante el uso de proxies inversos.
¿Cómo funciona?
A diferencia del phishing tradicional que clona páginas estáticas, Evilginx2 actúa como un intermediario entre el usuario víctima y el servicio legítimo (por ejemplo, Microsoft, Google, GitHub):
Interceptación de solicitudes: Redirige el tráfico del usuario hacia el sitio real a través del servidor del atacante.
Captura de credenciales y cookies: Captura las credenciales introducidas y, crucialmente, la cookie de sesión generada tras completar con éxito la verificación MFA.
Bypass de MFA: Al obtener la cookie de sesión autenticada, el atacante puede importarla en su navegador para acceder a la cuenta sin necesitar el código MFA de nuevo.
Requisitos previos para pruebas de concepto
Para utilizar Evilginx2 correctamente en un entorno controlado o de pruebas de penetración autorizadas, necesitas:
Un servidor VPS público: O una máquina Kali Linux accesible desde Internet (si no está en red local).
Un dominio propio: Configurado para apuntar a la IP de tu servidor.
Registros DNS (A y CNAME): Para gestionar los subdominios que simularán el servicio.
Instalación de Evilginx2 en Kali Linux
1.Instalar Go:Prerrequisito.Evilginx2 está desarrollado en Go. Asegúrate de tener Go instalado y actualizado:
2.Clonar el repositorio y compilar:Instalación.Descarga el código fuente de Evilginx2 y compílalo con Go:
3.Ejecutar la herramienta:Inicio.Inicia la consola interactiva de Evilginx2 con permisos de superusuario:
Comandos y configuración básica
Una vez dentro de la consola de Evilginx2 (:v), la configuración estándar se realiza mediante los siguientes comandos:
Configurar el IP y Dominio:
Gestión de Phishlets (plantillas de ataque):
Los phishlets son las plantillas de configuración que definen cómo se comporta el proxy para cada servicio (por ejemplo, o365, linkedin, github).
Crear un enlace de Phishing (Lure):
Inspeccionar sesiones capturadas:
Aviso de uso ético y legal
Evilginx2 debe utilizarse exclusivamente en evaluaciones de seguridad autorizadas, ejercicios de Red Team o entornos de laboratorio propio. El uso de esta herramienta contra objetivos sin autorización por escrito constituye un delito informático.
Las técnicas tradicionales de autenticación de doble factor (OTP por SMS, aplicaciones de autenticación con códigos TOTP de 6 dígitos o notificaciones Push estándar) son vulnerables a herramientas de proxy inverso como Evilginx2 porque no están vinculadas criptográficamente al dominio origen. El proxy intercepta el código de verificación enviado por el usuario, se lo retransmite al servicio legítimo y captura la cookie de sesión resultante.
Para mitigar eficazmente estos ataques AitM (Adversary-in-the-Middle), es necesario implementar defensas estructuradas en múltiples capas:
1. Autenticación resistente al Phishing (La defensa primaria)
FIDO2 / WebAuthn y llaves de seguridad físicas (YubiKey, SoloKeys):
Es la mitigación más efectiva. El protocolo WebAuthn vincula criptográficamente el proceso de autenticación con el origen del dominio (origin) presente en la barra de direcciones del navegador. Si la víctima está en login.servidor-falso.com, el navegador se negará a firmar la petición para el dominio real login.microsoftonline.com, neutralizando la interceptación del proxy.
Passkeys: Basadas en el estándar WebAuthn, ofrecen la misma protección resistente al phishing sin depender obligatoriamente de un token USB/NFC físico, utilizando los enclave de seguridad del sistema operativo o móvil.
Certificate-Based Authentication (CBA): Autenticación mediante certificados mTLS emitidos a dispositivos gestionados por la organización.
2. Políticas de Acceso Condicional y Control de Dispositivos
| Estrategia | Funcionamiento | Efecto frente al Proxy Inverso |
| Microsoft Entra ID / Okta Conditional Access | Restringe el acceso solo a dispositivos Unidos a dominio (Hybrid/Entra ID Joined) o Cumplimentados (Compliant) mediante MDM (Intune). | Aunque el atacante robe la cookie de sesión, no podrá reutilizarla desde su propio equipo al no cumplir la condición de dispositivo corporativo autorizado. |
| Vinculación por IP de red (Trusted IPs) | Exige que las autenticaciones procedan exclusivamente de rangos de IP corporativos o VPNs de la empresa. | Invalida el uso de cookies robadas desde redes no autorizadas. |
| Token Binding / Binding de sesión | Asocia la cookie de sesión al certificado mTLS del cliente o a la clave de cifrado de la máquina del usuario. | Evita que la cookie exportada sea válida en el navegador del atacante. |
3. Detección y Gestión de Sesiones
Frecuencia de reautenticación y sesiones de corta duración: Reducir el tiempo de vida de las cookies de sesión minimiza la ventana de oportunidad para que el atacante mantenga acceso no autorizado.
Análisis de comportamiento e IP (Impossible Travel): Herramientas UEBA/SIEM deben alertar o invalidar automáticamente sesiones si la cookie pasa de ser usada en la ubicación/dispositivo habitual de la víctima a una IP de un proveedor cloud (VPS) o un país distinto en cuestión de minutos.
Cierre de sesión dinámico al detectar anomalías: Configurar reglas para revocar automáticamente los tokens de actualización (Refresh Tokens) activos mediante APIs del IdP en caso de alertas de riesgo de usuario elevado.
4. Filtrado de Red y Monitoreo de Dominios
Monitoreo proactivo de typosquatting: Utilizar herramientas como DNSTwist para registrar preventivamente o monitorizar dominios similares al corporativo antes de que sean usados en campañas adversarias.
Categorización DNS e Inspección Web: Bloquear el acceso desde redes corporativas a dominios recién registrados (NRDs - Newly Registered Domains) o que carezcan de reputación en filtros web (web proxies/CASB), ya que las infraestructuras de phishing suelen usar dominios muy recientes.
