RemoteMonologue: armar el DCOM para coacciones de autenticación de NTLM

Los días de obtener credenciales sin esfuerzo con Mimikatz están llegando a su fin, para bien o para mal. A medida que Microsoft refuerza las defensas contra el robo de credenciales y las soluciones de detección y respuesta de endpoints (EDR) siguen avanzando, las técnicas tradicionales del equipo rojo, como el movimiento lateral, la ejecución de la carga útil y el acceso directo al servicio del subsistema de la autoridad de seguridad local (LSASS), se enfrentan a un escrutinio cada vez mayor. Como resultado, la comunidad del equipo rojo 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, anímese, porque este blog está repleto de trucos divertidos que puede utilizar en su próxima participación.

Cubriremos brevemente los fundamentos de COM y su homólogo distribuido, 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 omnipresentes en Windows, que opera silenciosamente detrás de escenas 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 poco explorada.

Para este blog, los conceptos clave que hay que entender son:

• COM: una tecnología básica de Windows que permite que los componentes de software interactúen entre sí a través de los límites del proceso. COM permite a los programas reutilizar la funcionalidad de otros programas sin duplicar funciones. 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 de 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.

A alto nivel, 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 lanzar 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 lo divertido, hay que analizar con más detalle un componente importante de la COM. Un identificador de aplicación (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 al instanciarlo. 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, un valor concreto destacó: Usuario interactivo. Este valor configura el objeto DCOM para que se ejecute bajo 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, ¿y si el valor de RunAs pudiera añadirse o modificarse para adaptarse a nuestros propósitos?

De forma predeterminada, un AppID en el registro está protegido con una lista de control de acceso discrecional (DACL), que otorga privilegios de propiedad de TrustedInstaller y restringe a los administradores locales al 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 los objetos del sistema, incluidas las claves de registro. Este privilegio es relevante para este ataque porque nos permite cambiar la propiedad de un AppID. Una vez cambiada la propiedad, podemos concedernos permisos de control total sobre el AppID y, posteriormente, modificar su configuración para añadir o modificar 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 se podía lograr el compromiso de los usuarios sin ejecutar una carga útil, adoptando un enfoque diferente al de la mayoría de las técnicas públicas de movimiento lateral de DCOM.

Me concentré en lograr resultados comparables en un formato “sin archivos”, lo que significa que no es necesario 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 equipo rojo. Al evitar este paso, el riesgo de activar controles de seguridad comunes se reduce significativamente. Por lo tanto, mi objetivo era comprometer cuentas de usuario remotas forzando una autenticación NTLM mediante 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 sin conexión
• 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 objetivo, que normalmente es objeto de un mayor escrutinio por parte de las herramientas de seguridad
• Evitar tocar el proceso LSASS, reduciendo así los riesgos de detección

En el momento de redactar este blog, la firma LDAP y el enlace de canal no son obligatorios ni se aplican de forma predeterminada en la mayoría de los 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 por defecto en los servidores Windows, excepto en los controladores de dominio.

Otra consideración importante es que los hashes de NTLMv1 se pueden descifrar de forma trivial con tablas arcoíris, que Nic Losby ha compartido públicamente en 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 a 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".

Como alternativa, 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 oyente 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 pueden retransmitirse a diferentes endpoints, consulte el siguiente recurso aquí.

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

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

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

La presencia del parámetro CabFilename era particularmente interesante porque sugería la posibilidad de proporcionar una ruta UNC, lo que podría dar lugar a una acción de autenticación de red.

Para probar esta teoría, suministré una ruta UNC para el parámetro CabFilename apuntando a mi sistema (172.22.164.58) ejecutando Responder, como se muestra en la Figura 4. ¿El resultado? ¡Todo un éxito! Pudimos capturar un hash de NTLMv2, como se muestra en la figura 5.

A continuación, probé si era posible capturar credenciales de un usuario diferente en un sistema remoto (172.22.166.170) modificando la clave RunAs del ServerDataCollectorSet. Para conseguirlo, utilicé el servicio Remote Registry para añadir el valor Interactive User para el AppID {03837503-098B-11D8-9414-505054503030}.

Una vez que un usuario diferente 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 su capacidad de secuestro de sesiones, lo probé de forma remota configurando la clave RunAs del AppID {2C941FD1-975B-59BE-A960-9A2A262853A5} en Interactive User. Esta configuración hace que el objeto DCOM FileSystemImage se ejecute 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 merece 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 daba a entender que podría aceptar una ruta UNC.

Al probar esta teoría, capturamos con éxito 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 establecerla como Usuario interactivo, el objeto DCOM UpdateSession seguía realizando operaciones de red como la cuenta de la máquina. Entonces, ¿por qué sucede esto? La respuesta sencilla es que, mientras que el propio objeto DCOM se ejecuta bajo el contexto de seguridad del usuario instanciador o interactivo, las operaciones de red las realiza un proceso independiente: svchost.exe. La ruta UNC se entrega a svchost.exe, que siempre utiliza por defecto la cuenta SYSTEM para estas operaciones. Por lo tanto, la configuración de la clave RunAs no afecta a este comportamiento.

Aunque la clave RunAs no influye en la cuenta utilizada para las operaciones de red, la captura de 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 podrían ser útiles para movimiento lateral o escalada de privilegios.
2. Falsificación de tickets plateados para una evasión adicional:
   podemos utilizar 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 ha sido 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 utilizando la biblioteca Impacket y automatiza el proceso de ataque.

RemoteMonologue ofrece la posibilidad de apuntar a cualquiera de los tres objetos DCOM mencionados (-dcom) para realizar la coerción de autenticación contra un oyente especificado (-auth-to). Además, cuenta con un módulo de pulverización (-spray) para validar las credenciales en varios sistemas, con el beneficio añadido de capturar las 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 cómo ejecutar RemoteMonologue con el ataque de downgrade de NetNTLMv1 usando Responder como oyente. 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. Esta vez, el ataque se ejecuta usando el objeto DCOM FileSystemImage y permite que el servicio WebClient obtenga una autenticación HTTP, que luego se retransmite a LDAP usando 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. Habilitar la firma LDAP y la vinculación de canales: configurar la aplicación de firma LDAP y la vinculación de canales en los controladores de dominio para proteger el endpoint LDAP de ataques por relé. Nota: Esta configuración se aplicará de forma predeterminada a partir de Windows Server 2025.
2. Actualizar a las últimas versiones de Windows: actualizar servidores a Windows Server 2025 y estaciones de trabajo a Windows 11 versión 24H2 para mitigar ataques de degradación NetNTLM, ya que NTLMv1 ha sido eliminado en estas versiones.
3. Hacer cumplir la firma SMB: habilitar y hacer cumplir la firma SMB en servidores Windows para prevenir ataques por relé SMB.
4. Implementar políticas de contraseñas seguras: aplicar requisitos de contraseñas seguras para que los ataques de descifrado de contraseñas sean más desafiantes.

Oportunidades de detección:

1. Supervise el acceso remoto a los objetos DCOM: realice un seguimiento del acceso a los objetos DCOM afectados y a sus propiedades y métodos específicos para identificar actividades inusuales.
2. Supervise las modificaciones del registro: supervise los cambios en las claves de registro RunAs y LmCompatibilityLevel.
3. Rastree la actividad del servicio WebClient: supervise 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 demuestra cómo los objetos DCOM infrautilizados pueden convertirse en armas para realizar ataques coercitivos de autenticación sigilosos y sin archivos. Modificando propiedades específicas y aprovechando técnicas como el downgrade de NetNTLMv1, los atacantes pueden comprometer cuentas de usuario y escalar privilegios sin implementar cargas útiles ni acceder directamente a procesos sensibles como LSASS.

Al centrarse en reforzar sistemas clave, como la aplicación de la firma LDAP, la firma SMB y la desactivación de protocolos heredados como NTLMv1, los defensores pueden reducir significativamente la superficie de ataque. Además, una sólida supervisión de las modificaciones del registro, la actividad de DCOM y los cambios en los servicios remotos puede ayudar a detectar estas técnicas en sus primeras fases y mitigar su impacto.