RemoteMonologue: Weaponizing DCOM for NTLM authentication coercions

Los días de adquirir credenciales sin esfuerzo con Mimikatz están, para bien o para mal, llegando a su fin. A medida que Microsoft fortalece las defensas contra el robo de credenciales y las soluciones de detección y respuesta de endpoints (EDR) continúan avanzando, las técnicas tradicionales de equipo rojo como el movimiento lateral, la ejecución de carga útil y el acceso directo al Servicio de Subsistema de Autoridad de Seguridad Local (LSASS) enfrentan un escrutinio cada vez mayor. Como resultado, la comunidad Red Team se ha visto obligada a explorar métodos alternativos para recopilar credenciales en sistemas Windows.

Imagínese obtener resultados similares sin necesidad de una carga útil "avanzada" ni acceso a LSASS, simplemente aprovechando recursos nativos y sacando partido a los objetos del modelo de objetos componentes (COM) infrautilizados. Si eso le entusiasma, concéntrese, porque este blog está repleto de trucos divertidos que puede utilizar en su próxima interacción.

Cubriremos brevemente los fundamentos de COM y su contraparte distribuida, el modelo de objetos componentes distribuidos (DCOM), profundizaremos en la configuración de RunAs y por qué las coerciones de autenticación son impactantes e introduciremos una nueva herramienta de recolección de credenciales: RemoteMonologue.

El modelo de objetos componentes (COM) es una de las tecnologías más antiguas y generalizadas de Windows, que opera silenciosamente detrás de escena de las aplicaciones y servicios cotidianos. A pesar de su antigüedad, COM sigue siendo un recurso valioso para los atacantes, ya que ofrece formas alternativas de lograr el movimiento lateral, la escalada de privilegios y la persistencia. Sin embargo, su complejidad inherente ha dejado gran parte de su superficie de ataque sin explorar.

Para este blog, los conceptos clave que se deben comprender son:

• COM: una tecnología central de Windows que permite que los componentes de software interactúen entre sí más allá de los límites del proceso. COM permite que los programas reutilicen la funcionalidad de otros programas sin duplicar la funcionalidad. Por ejemplo, un programa podría usar un objeto COM para leer registros del sistema o agregar nuevas entradas a un archivo de Excel sin implementar estas características por sí mismo.
• Modelo de objetos componentes distribuidos (DCOM) Una extensión de COM que permite la comunicación basada en red. Con DCOM, un proceso que se ejecuta en una máquina puede invocar funciones en un objeto COM ubicado en otra máquina. Esta capacidad basada en la red ha convertido a DCOM en una herramienta valiosa para el movimiento lateral. El acceso a objetos DCOM suele requerir privilegios de administrador local en el sistema remoto.

En un nivel alto, piense en los objetos COM como unidades autónomas con dos componentes principales:

• Propiedades: representan el estado o la configuración del objeto.
• Métodos: representan acciones que el objeto puede realizar. Por ejemplo, un objeto COM puede tener un método para iniciar un proceso, crear un archivo o iniciar una solicitud de autenticación.

Los atacantes pueden abusar de estos métodos para facilitar el movimiento lateral y, como ilustraremos en breve, coaccionar autenticaciones NTLM remotas para descifrar contraseñas y ataques de retransmisión.

Antes de sumergirse en las cosas divertidas, es necesario analizar con mayor detalle un componente importante de COM. Un Identificador de aplicaciones (AppID) en COM sirve como mecanismo clave para gestionar la seguridad, identidad y comportamiento en tiempo de ejecución de las aplicaciones COM, especialmente en escenarios que involucran DCOM o aplicaciones que requieren contextos de seguridad específicos. Cuando una clase COM se registra con un AppID, hereda la configuración de seguridad definida para ese AppID.

La configuración de seguridad de especial interés es la clave RunAs, que especifica qué cuenta de usuario se utilizará para ejecutar un objeto DCOM tras su instanciación. La clave RunAs se puede encontrar en el registro en:

• HKEY_CLASSES_ROOT\AppID\{AppID_GUID}

Al revisar la documentación de Microsoft sobre DCOM y la clave RunAs, se destacó un valor específico: usuario interactivo. Este valor configura el objeto DCOM para que se ejecute en el contexto de seguridad del usuario que ha iniciado sesión actualmente en la sesión de consola del sistema. Desde una perspectiva ofensiva, esto es interesante porque podría permitirnos aprovechar los objetos DCOM para operar como otro usuario sin conocer las credenciales del usuario afectado.

No todos los objetos DCOM con un AppID tienen un valor RunAs establecido en Usuario interactivo. De hecho, aproximadamente la mitad de los AppID no tienen ningún valor RunAs establecido. Sin embargo, ¿qué pasaría si el valor de RunAs pudiera agregarse o modificarse para adaptarlo a nuestros propósitos?

De forma predeterminada, un AppID en el registro está protegido con una lista de control de acceso discrecional (DACL), lo que otorga privilegios de propiedad a TrustedInstaller y restringe a los administradores locales el acceso de solo lectura, como se muestra en la Figura 1.

Sin embargo, a los administradores locales se les concede el privilegio SeTakeOwnershipPrivilege, que les permite tomar posesión de objetos del sistema, incluidas las claves del registro. Este privilegio es relevante para este ataque porque nos permite cambiar la propiedad de un AppID. Una vez que se cambia la propiedad, podemos otorgarnos permisos de control total sobre el AppID y, posteriormente, modificar su configuración para agregar o alterar el valor de RunAs.

Una vez que el valor RunAs se modifica a Usuario interactivo, el ataque se vuelve sencillo. Esto nos permite forzar la ejecución de un objeto DCOM en el contexto de otra sesión activa. Sin embargo, el éxito de este ataque depende en última instancia de las propiedades y métodos expuestos por el objeto DCOM específico al que se dirige.

Ahora que sabemos que es posible convertir un objeto DCOM en una herramienta de secuestro de sesión, el siguiente paso es identificar qué métodos y propiedades se pueden aprovechar para completar el secuestro. Para esta investigación, exploré si el compromiso del usuario podría lograrse sin ejecutar una carga útil, tomando un enfoque diferente al de la mayoría de las técnicas públicas de movimiento lateral DCOM.

Me enfoqué en lograr resultados comparables en un formato “sin archivos”, lo que significa que no hay necesidad de transferir o ejecutar una carga útil en el sistema de destino. Esta distinción es importante porque transferir y ejecutar cargas útiles en un sistema de destino a menudo se considera una acción "costosa" en las operaciones del Red Team. Al evitar este paso, el riesgo de activar controles de seguridad comunes se reduce significativamente. Por lo tanto, mi objetivo era comprometer las cuentas de usuario remotas al coaccionar una autenticación NTLM a través de DCOM.

Hay varios beneficios clave para coaccionar las autenticaciones NTLM en lugar de realizar técnicas tradicionales de movimiento lateral:

• Capturar hashes NTLMv1/NTLMv2 e intentar descifrarlos
• Retransmitir hashes NTLMv1 o WebDAV NTLMv2 a otros servicios de red, como LDAP o SMB, para realizar acciones como el usuario afectado
• Evitar transferir y ejecutar una carga útil en el sistema de destino, lo que normalmente atrae un mayor escrutinio por parte de las herramientas de seguridad
• Evitar tocar el proceso LSASS, reduciendo así los riesgos de detección

A la fecha de este texto, la firma LDAP ni la vinculación de canales no son necesarias ni se aplican por defecto en la mayoría de controladores de dominio. Estas características de seguridad solo son obligatorias en Windows Server 2025. Esto significa que si podemos forzar una autenticación NTLMv1 o WebDAV desde el sistema de destino, podemos retransmitirla a LDAP y realizar acciones como el usuario afectado. Del mismo modo, la firma SMB no es necesaria de forma predeterminada en los servidores Windows, excepto en los controladores de dominio.

Otra consideración importante es que los hash NTLMv1 pueden descifrarse fácilmente utilizando tablas rainbow, que Nic Losby ha compartido públicamente en desde diciembre de 2024. Estas tablas reducen drásticamente el tiempo y el esfuerzo necesarios para recuperar las credenciales NTLM de los hashes NTLMv1. Para obtener un hash NTLMv1 en lugar de un hash NTLMv2, modificamos la siguiente clave de registro en el sistema de destino:

• HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Establecer LmCompatibilityLevel en un valor de 2 o menos obliga al sistema a recurrir a NTLMv1 para la autenticación. Esta modificación es posible con privilegios de administrador local y se conoce comúnmente como "ataque de degradación de NetNTLMv1".

Alternativamente, podemos capturar una autenticación WebDAV y retransmitirla a LDAP, ya que las autenticaciones basadas en HTTP se pueden reenviar a este servicio. Si el servicio WebClient aún no se está ejecutando con acceso privilegiado, podemos habilitarlo de forma remota en el sistema de destino. Una vez habilitado, podemos forzar una autenticación NTLM de WebDAV a nuestro agente de escucha especificando el nombre NetBIOS de la máquina en la ruta UNC. Por ejemplo:

• \\MYHACKERBOX@80\giveme\creds.txt

Para obtener más información sobre los ataques de retransmisión NTLM y los protocolos que se pueden retransmitir a diferentes puntos finales, consulte el siguiente recurso aquí.

Durante mi investigación, analicé el objeto ServerDataCollectorSet DCOM, que tiene la {03837546-098B-11D8-9414-505054503030}CLSID , para identificar métodos y propiedades que pudieran aprovechar para la coacción de autenticación. Una propiedad que se destacó fue DataManager y, afortunadamente, este objeto COM incluía una biblioteca de tipos, que define sus métodos y propiedades con mayor detalle.

Usando OleView.NET, revisé la Biblioteca de tipos de ServerDataCollectorSet y descubrí que la propiedad DataManager tenía un método Extract que espera dos parámetros:

1. CabFilename: el nombre de un archivo CAB para extraer.
2. DestinationPath: la ruta para extraer el contenido del archivo CAB.

La presencia del parámetro CabFilename fue particularmente interesante porque sugirió la posibilidad de proporcionar una ruta UNC, lo que podría resultar en una acción de autenticación de red.

Para probar esta teoría, proporcioné una ruta UNC para el parámetro CabFilename que apuntaba a mi sistema (172.22.164.58). ejecutando Responder, como se muestra en la Figura 4. ¿El resultado? ¡Lo logró! Pudimos capturar un hash NTLMv2, como se muestra en la Figura 5.

A continuación, probé si era posible capturar las credenciales de otro usuario en un sistema remoto (172.22.166.170) modificando la clave RunAs de ServerDataCollectorSet. Para lograrlo, utilicé el servicio de Registro remoto para agregar el valor Usuario interactivo para el AppID {03837503-098B-11D8-9414-505054503030}.

Una vez que otro usuario inició sesión en el sistema de destino (en este caso, GALAXY\yoda), accedí al objeto DCOM ServerDataCollectorSet como GALAXY\Administrator y ejecuté el mismo método Extract que se muestra en la Figura 6. Una vez más, capturé con éxito una autenticación; sin embargo, esta vez de GALAXY\yoda, como se muestra en la Figura 7. Esto demuestra que modificar la clave RunAs para Usuario interactivo nos permite aprovechar los objetos DCOM para secuestrar sesiones de otros usuarios.

Este flujo de ataque se muestra en el siguiente diagrama.

Otro objeto interesante de DCOM susceptible a la coerción de autenticación es FileSystemImage, que tiene el CLSID{2C941FC5-975B-59BE-A960-9A2A262853A5}. Este objeto es particularmente único porque la coerción se activa simplemente modificando una propiedad en lugar de invocar un método, una técnica menos común en los ataques basados en DCOM.

La propiedad en cuestión es WorkingDirectory, que, por defecto, apunta a la carpeta %TEMP% del usuario interactivo. Sin embargo, al cambiar el valor de WorkingDirectory a una ruta UNC que apunte a nuestro agente de escucha, es posible capturar una autenticación NTLMv2, como se muestra en las figuras 9 y 10.

Para validar sus capacidades de secuestro de sesión, lo probé de forma remota configurando la clave RunAs para el AppID {2C941FD1-975B-59BE-A960-9A2A262853A5} en Usuario interactivo. Esta configuración activó el objeto DCOM FileSystemImage para ejecutarse bajo el contexto de seguridad del usuario activo en el sistema de destino. Y, como era de esperar, pude capturar el hash NTLMv2 para ese usuario.

Esta técnica demuestra que las coerciones de autenticación podrían lograrse modificando las propiedades y los métodos, ampliando así la superficie de ataque potencial de los objetos DCOM.

Un último objeto DCOM que vale la pena compartir es UpdateSession, que tiene el CLSID {4CB43D7F-7EEE-4906-8698-60DA1C38F2FE}. Al revisar su Biblioteca de tipos, el método AddScanPackageService destacó porque requería un argumento serviceName y, lo que es más interesante, un argumento scanFileLocation. La presencia de scanFileLocation sugería que podría aceptar una ruta UNC.

Al probar esta teoría, logramos capturar una autenticación NTLMv2, pero en lugar de recibir las credenciales de la cuenta de usuario, recibimos las credenciales de la cuenta de la máquina, como se ilustra a continuación.

Este hallazgo es especialmente interesante porque, incluso después de añadir una clave RunAs y configurarla como Usuario interactivo, el objeto DCOM UpdateSession seguía realizando operaciones de red como cuenta de máquina. Entonces, ¿por qué sucede esto? La respuesta simple es que, mientras que el objeto DCOM en sí se ejecuta bajo el contexto de seguridad del usuario que crea instancias o interactivo, las operaciones de red las realiza un proceso separado: svchost.exe. La ruta de acceso UNC se entrega a svchost.exe, que siempre se pone de forma predeterminada en la cuenta SYSTEM para estas operaciones. Por lo tanto, la configuración de la clave RunAs no afecta este comportamiento.

Aunque la clave RunAs no influye en la cuenta utilizada para las operaciones de red, capturar las credenciales de la cuenta de la máquina sigue siendo valiosa para varios escenarios de ataque:

1. Acceso a permisos DACL interesantes en Active Directory:
   Las cuentas de máquina (por ejemplo, DOMAIN\MACHINE$) podrían tener permisos para objetos específicos en Active Directory que pueden ser útiles para el movimiento lateral o la escalada de privilegios.
2. Falsificación de tickets plateados para evasión adicional:
   podemos usar el hash NTLM de una cuenta de máquina para falsificar un ticket plateado, lo que nos permite suplantar a cualquier usuario en el sistema y realizar acciones con un riesgo reducido de detección.

Este ataque fue denominado RemoteMonologue, ya que funciona de forma similar a InternalMonologue, con la principal diferencia de que realiza el ataque de forma remota. La herramienta fue desarrollada en Python empleando la biblioteca Impacket y automatiza el proceso de ataque.

RemoteMonologue ofrece la posibilidad de seleccionar cualquiera de los tres objetos DCOM mencionados anteriormente (-dcom) para realizar una coacción de autenticación contra un oyente específico (-auth-to). Además, cuenta con un módulo de rociado (-spray) para validar credenciales en múltiples sistemas, con el beneficio adicional de capturar credenciales. La herramienta también soporta un ataque de downgrade NetNTLMv1 (-downgrade) y tiene una opción para habilitar el servicio WebClient para facilitar las autenticaciones HTTP (-webclient). Por último, la herramienta incluye un módulo de consulta (-query) para enumerar los usuarios con una sesión activa en el sistema de destino.

A continuación, se muestra un ejemplo de ejecución de RemoteMonologue con el ataque de degradación NetNTLMv1 mientras se usa Responder como agente de escucha. De forma predeterminada, si no se especifica ninguna opción DCOM, la herramienta utiliza el objeto DCOM ServerDataCollectorSet.

A continuación se muestra otro ejemplo. En esta ocasión, el ataque se ejecuta utilizando el objeto DCOM FileSystemImage y habilitando el servicio WebClient para obtener una autenticación HTTP, que luego se transmite a LDAP utilizando ntlmrelayx.

Para proteger y detectar las técnicas descritas en este blog, se pueden implementar varias medidas preventivas y de detección.

Medidas preventivas:

1. Habilite la firma LDAP y el enlace de canales: configure la aplicación de la firma LDAP y el enlace de canales en los controladores de dominio para proteger el endpoint LDAP de los ataques de retransmisión. Nota: Esta configuración se aplicará de forma predeterminada a partir de Windows Server 2025.
2. Actualice a las últimas versiones de Windows: actualice los servidores a Windows Server 2025 y las estaciones de trabajo a Windows 11 versión 24H2 para mitigar los ataques de degradación de NetNTLM, ya que NTLMv1 se eliminó en estas versiones.
3. Aplicar la firma SMB: habilite y aplique la firma SMB en servidores Windows para evitar ataques de retransmisión SMB.
4. Implemente políticas de contraseñas seguras: aplique requisitos de contraseñas seguras para que los ataques de descifrado de contraseñas sean más desafiantes.

Oportunidades de detección:

1. Monitoree el acceso remoto a los objetos DCOM: realice un seguimiento del acceso a los objetos DCOM afectados y sus propiedades y métodos específicos para identificar actividades inusuales.
2. Monitoree las modificaciones del registro: monitoree los cambios en las claves del registro RunAs y LmCompatibilityLevel.
3. Haga un seguimiento de la actividad del servicio WebClient: monitoree las instancias en las que el servicio WebClient está habilitado de forma remota, ya que se utiliza para facilitar las autenticaciones NTLM basadas en HTTP.

El ataque RemoteMonologue muestra cómo los objetos DCOM infrautilizados pueden convertirse en armas para realizar ataques de coerción de autenticación sigilosos y sin archivos. Al modificar propiedades específicas y aprovechar técnicas como la degradación de NetNTLMv1, los atacantes pueden comprometer las cuentas de usuario y escalar los privilegios sin desplegar cargas útiles o acceder directamente a procesos confidenciales como LSASS.

Al centrarse en fortalecer los sistemas clave, como hacer cumplir la firma LDAP, la firma SMB y deshabilitar protocolos heredados como NTLMv1, los defensores pueden reducir significativamente la superficie de ataque. Además, un monitoreo riguroso de las modificaciones del registro, la actividad DCOM y los cambios en los servicios remotos puede ayudar a detectar estas técnicas en sus primeras etapas y mitigar su impacto.