Cuenta de servidor (des)confianza

Persistencia en Active Directory mediante la manipulación de userAccountControl

He estado investigando recientemente sobre las cuentas de servicio administrado de grupo (gMSAs) y leyendo la especificación del protocolo MS-SAMR para obtener información. Me topé con información interesante en la sección de userAccountControl que nos hizo dejar lo que estábamos haciendo para probarlo:

Efectivamente, cuando el bit UF_SERVER_TRUST_ACCOUNT está establecido en el atributo userAccountControl de un objeto de computadora, entonces Active Directory debe asignar el mismo objeto al primaryGroupId con el RID del grupo Domain Controllers. Por lo tanto, simplemente cambiando userAccountControl puede otorgar a un objeto de computadora los privilegios de un controlador de dominio.

Investigando el comportamiento

Comenzamos a probar usando una cuenta de Administrador de Dominio en nuestro laboratorio, y primero intentamos usar el valor predeterminado de userAccountControl para un controlador de dominio de 0x82000 (decimal 532480), que es la suma de las banderas de bit para SERVER_TRUST_ACCOUNT (0x2000, decimal 8192) y TRUSTED_FOR_DELEGATION (0x80000, decimal 524288).

Después de cambiar el valor de userAccountControl, observamos que el primaryGroupId se actualiza a 516 (el RID para el grupo de Controladores de Dominio) y hemos comenzado con buen pie! A continuación, queríamos saber si solo se requiere el bit SERVER_TRUST_ACCOUNT, así que intentamos nuevamente establecer el atributo userAccountControl a 8192.

Hemos confirmado así la precisión de la especificación del protocolo, y que es solo el bit SERVER_TRUST_ACCOUNT el que provoca el cambio del primaryGroupId.

Investigando los privilegios requeridos

Comenzamos a considerar posibles vectores de abuso. Si solo se requiere la capacidad de modificar el atributo userAccountControl, entonces podríamos estar ante una interesante técnica de privilege escalation. Empezamos a probar con una cuenta sin privilegios con permisos solo para modificar el atributo userAccountControl, y rápidamente nos encontramos con errores de acceso denegado.

Resulta que deberíamos haber leído solo unas pocas líneas más abajo en la documentación de MS-SAMR. La sección 5 del atributo userAccountControl detalla permisos adicionales requeridos para configurar ciertos bits de userAccountControl. Para establecer el bit UF_SERVER_TRUST_ACCOUNT de userAccountControl, el actor debe tener el permiso DS-Install-Replica (“Agregar/quitar réplica en dominio”) otorgado en el objeto del dominio.

Otorgamos a nuestro usuario no privilegiado este permiso e intentamos nuestra prueba de nuevo.

Después de otorgar el privilegio de escritura userAccountControl en el equipo y el privilegio DS-Install-Replica en el objeto de dominio a nuestro usuario no privilegiado, nuestra prueba fue exitosa.

De forma predeterminada, el permiso DS-Install-Replica se concede a los grupos “Domain Admins” y “Enterprise Admins”. Por lo tanto, en todos los entornos excepto los mal configurados, este enfoque no representa un vector de escalada de privilegios. Sin embargo, dada la limitada cantidad de permisos requeridos, comenzamos a pensar en aplicaciones para la persistencia de dominio.

Aplicaciones para la persistencia de dominio

Al evaluar si esto presenta un método interesante para la persistencia, consideramos varios factores: que se requiere un conjunto limitado de privilegios, que estos privilegios no se revisan comúnmente, que las cuentas (objectClass=computer) son fáciles de crear, que las computadoras se revisan con poca frecuencia (muchas organizaciones luchan con objetos de computadora obsoletos) y que la explotación del mecanismo es fácil y los signos son de corta duración.

Configurar este mecanismo solo requiere unos pocos pasos sencillos:

1. Cree una cuenta falsa de computadora, MSA o gMSA. También se puede utilizar una cuenta existente, pero la efectividad del mecanismo de persistencia estará limitada por la frecuencia de cambios de contraseña. Sin embargo, una cuenta de computadora existente pero obsoleta (que ya no se utiliza) podría ser un objetivo atractivo.
2. Otorgue el privilegio “Agregar/quitar réplica en el dominio” a un usuario regular comprometido, grupo o entidad conocida. Utilizamos “Usuarios Autenticados” para que un adversario pueda comprometer cualquier cuenta de usuario regular y recuperar el dominio del dominio.
3. Otorgue el privilegio “Write userAccountControl” en el objeto del equipo a la misma entidad que en el paso anterior.

Creando una cuenta de computadora con una contraseña conocida

Puede parecer obvio, pero no todos pueden estar familiarizados con la capacidad de crear una cuenta de computadora con una contraseña conocida utilizando los cmdlets New-ADComputer o New-ADServiceAccount, por ejemplo:

New-ADComputer “ComputerName” -AccountPassword (ConvertTo-SecureString -AsPlainText -Force “Password”)

Conocer la contraseña en texto plano es beneficioso por varias razones. Lo más importante es que podemos calcular los hashes NTLM, AES-128 y AES-256 utilizando los cmdlets ConvertTo-NTHash y ConvertTo-KerberosKey del módulo de PowerShell DSInternals de Michael Grafnetter. Cuando el adversario elige explotar la puerta trasera, necesitará autenticarse como la cuenta de la computadora para usar sus privilegios y lo hará con la técnica de overpass-the-hash. Especificar los hashes NTLM y AES evita la mayoría de las detecciones de overpass-the-hash.

Recuperando el dominio del dominio

Después de preparar la cuenta y los permisos, si el adversario pierde acceso a sus credenciales administrativas o es expulsado de la red, solo necesita comprometer a cualquier usuario regular para recuperar el dominio del dominio.

Con cualquier cuenta de usuario, el adversario solo necesita modificar el atributo userAccountControl de su computadora preparada a 0x2000 (8192). Esta modificación también provoca una replicación inmediata, lo que significa que el adversario no necesita apuntar a controladores de dominio específicos. Una vez que el userAccountControl esté completo, el adversario puede usar sus privilegios de controlador de dominio para comprometer el dominio.

Por ejemplo, el adversario podría usar la cuenta de computadora para realizar DCSync y comprometer el hash de la contraseña de krbtgt. Debido a que la replicación parece provenir de un controlador de dominio, la mayoría de las detecciones de amenazas de DCSync no detectan la actividad. Una vez que han replicado el secreto de krbtgt, simplemente pueden cambiar userAccountControl de nuevo a 0x1000 (4096) y la cuenta de computadora parecerá una cuenta de computadora normal.

Automatizando la técnica

Para ayudar a demostrar la potencial eficacia de este método, creé dos nuevas funciones de PowerShell que están available on GitHub.

La primera función, Add-ServerUntrustAccount, automatiza los tres pasos de configuración: crear una cuenta de computadora falsa con una contraseña conocida y otorgar a los “Usuarios Autenticados” los privilegios de “Agregar/quitar réplica en el dominio” y “Escribir userAccountControl”.

La segunda función, Invoke-ServerUntrustAccount, automatiza la explotación de la puerta trasera y está diseñada para ser ejecutada como un usuario sin privilegios. La función establece el atributo userAccountControl a 0x2000 (8192), luego utiliza pass-the-hash para autenticarse como la cuenta falsa de computadora, realiza un DCSync de los hashes de krbtgt, y finalmente devuelve userAccountControl a 0x1000 (4096).

Descubrimiento de mecanismos y detección de explotación

Para encontrar este y otros mecanismos similares, las organizaciones deberían auditar periódicamente los permisos sensibles de Active Directory. También es beneficioso monitorear (o incluso bloquear) los cambios de permisos sensibles (como el “Agregar/quitar réplica en dominio”) en tiempo real. Probamos varias herramientas populares de código abierto para la auditoría de permisos de Active Directory, y solo AD ACL Scanner resalta correctamente los permisos de nuestro adversario como problemáticos.

Los registros de eventos de Active Directory, específicamente los ID de evento 5136 y 4662 – permiten una monitorización básica en tiempo real de los cambios en las ACL y pueden utilizarse para detectar el privilegio a nivel de dominio “Agregar/quitar réplica en dominio”. Sin embargo, el proceso para analizar estos eventos no es sencillo.

Además, es importante encontrar y eliminar cuentas de computadora (y MSA y gMSA) que están inactivas o que no coinciden con una máquina real en la red. Por ejemplo, puedes encontrar rápidamente cuentas de computadora inactivas o sin usar con PowerShell (reemplazando “-90” por la edad máxima de cuenta de computadora de tu dominio):

$Date = [DateTime]::Today.AddDays(-90); Get-ADComputer -Filter ‘(Enabled -eq $true) -and (PasswordLastSet -le $Date)’ | Select Name

Detección de la explotación

Detectar el uso de esta técnica por parte de un adversario se centra en el monitoreo de cambios en el atributo userAccountControl. El Id. de evento 4742 – Computer Account Management puede utilizarse para monitorear cambios en los valores de userAccountControl. Cualquier modificación de userAccountControl con el bit 0x2000 establecido fuera de una promoción de controlador de dominio esperada es preocupante.

Concluyendo

Aunque obviamente no es tan grave como una vulnerabilidad crítica, este tipo de técnicas a menudo pasan desapercibidas en las empresas y pueden complicar aún más el trabajo de un encargado de respuesta a incidentes. Dada la baja tasa de detección en las herramientas de auditoría de Active Directory que probamos, creemos que esta es una técnica interesante que abusa de un comportamiento menos conocido que fácilmente podría pasarse por alto. Agradecemos sus comentarios y preguntas, y sería un descuido de nuestra parte si no les indicáramos nuestro Attack Catalog, donde pueden aprender más sobre cómo funcionan ciertos ataques.