Delegación sin restricciones

La delegación sin restricciones representa un serio riesgo de ciberseguridad. Al tomar medidas para abusar de los controles de delegación de Active Directory aplicados a objetos de usuario y computadora en un entorno de AD, un atacante puede moverse lateralmente e incluso tomar control del dominio.

Esta entrada de blog explora esta área de ataque (delegación sin restricciones) y ofrece a los equipos de seguridad y administradores estrategias efectivas para mitigar este riesgo de seguridad.

¿Qué es la delegación sin restricciones?

La delegación permite que un usuario o una computadora se haga pasar por otra cuenta para acceder a recursos (como servidores de bases de datos back-end). La delegación tiene varias aplicaciones prácticas, las cuales Microsoft cubre en esta entrada de blog.

Usando la pestaña Delegación en una cuenta de usuario o de computadora, puede configurar la delegación sin restricciones o con restricciones:

• Al seleccionar “Confiar en este equipo para la delegación a cualquier servicio (delegación Kerberos solamente),” está habilitando sin restricciones
• Alternativamente, puede restringir a qué servicios el usuario o la computadora pueden suplantar especificando nombres de entidad de servicio (SPNs) particulares, lo cual es una delegación restringida.

Tenga en cuenta que otra opción es la resource-based constrained delegation (RBCD), en la que la delegación se configura en el recurso, en lugar de en las cuentas que acceden al recurso. RBCD se puede configurar usando Windows PowerShell.

¿Cuáles son los riesgos de la delegación sin restricciones?

Varios ataques pueden perpetrarse contra la delegación sin restricciones: algunos están cubiertos en esta entrada de blog por harmj0y y Sean Metcalf describe otros. Exploremos un par.

Ejemplo 1: Abusar de la delegación sin restricciones para comprometer un bosque AD completo

Los investigadores de seguridad han demostrado cómo un atacante que compromete una máquina con delegación sin restricciones en un bosque puede comprometer otro bosque y todos los dominios en él. Si tienes una confianza bidireccional establecida, un atacante puede usar el error de impresora MS-RPRN para hacer que un DC envíe información de autenticación de vuelta al atacante, permitiéndoles usar DCSync para comprometer el dominio de confianza. Por ejemplo, si tu empresa adquirió una pequeña empresa y unió su dominio al tuyo, un atacante que comprometa un sistema en el pequeño entorno podría tomar control de todo el bosque de tu empresa, lo cual definitivamente no es bueno.

Un artículo de KB fue publicado para proporcionar una solución a este error, y en Windows Server 2012 en adelante hay una configuración de seguridad para prevenir esto, pero puede que no esté activada por defecto.

Ejemplo 2: Explotando la delegación sin restricciones para habilitar el movimiento lateral

Aquí hay otro escenario. Si la delegación sin restricciones está activada para una computadora, entonces cada vez que una cuenta se conecta a esa computadora, su ticket de concesión de ticket (TGT) del Centro de Distribución de Claves (KDC) se almacena en memoria para su uso posterior por la computadora. Si la máquina está comprometida, el adversario puede obtener ese TGT y usarlo indebidamente para causar un gran daño, especialmente si el TGT es de un usuario con altos privilegios.

Por ejemplo, supongamos que un Administrador de Dominio accede a una computadora en particular a través del Sistema de Archivos de Internet Común (CIFS) accediendo a una carpeta compartida. Sin la delegación sin restricciones activada, solo el servidor de concesión de tickets (TGS) se almacenaría en memoria; este ticket solo da acceso al servicio CIFS en la máquina local, por lo que un adversario no puede usarlo para moverse lateralmente. Podemos ver esto utilizando el comando Mimikatz sekurlsa::tickets /export, que solo devuelve el ticket de servicio del usuario (TGS):

Sin embargo, si la delegación sin restricciones está habilitada, el comando devuelve el TGT para la cuenta de administrador, que un adversario puede utilizar en un ataque de Pass-the-Ticket para comprometer todo el dominio.

Para recolectar TGTs de cualquier usuario que se conecte al sistema, el adversario puede utilizar el siguiente comando de PowerSpoit:

Derechos necesarios para habilitar la delegación sin restricciones

Para poder gestionar los controles de delegación de un objeto, un usuario necesita los siguientes derechos:

• SeEnableDelegationPrivilege, un derecho de usuario es controlado por la política de security policy local de un controlador de dominio y gestionado a través de la configuración de Group Policy “Enable computer and user accounts to be trusted for delegation”, como se ilustra a continuación
• Capacidad para actualizar los atributos msDS-AllowedToDelegateTo y userAccountControl de un ordenador, que es donde se almacena esta configuración de Directiva de grupo is stored

Encontrar delegación sin restricciones

Para averiguar dónde se ha habilitado la delegación sin restricciones, puede utilizar el siguiente script de PowerShell. Comprobará el valor de Control de Cuenta de Usuario (UAC) de todos los ordenadores para ver dónde está activada la delegación sin restricciones.

También puede que quieras ver quién ha recibido el derecho SeEnableDelegationPrivilege. Para hacer esto, puedes usar PowerSploit y el comando Get-DomainPolicy.

Mejores prácticas para reducir el riesgo de la delegación sin restricciones

Para reducir el riesgo de delegación sin restricciones, se recomienda:

• Investigue si la delegación sin restricciones es realmente necesaria. En muchos casos, la delegación sin restricciones se habilitó por error y puede ser deshabilitada por completo o convertida a delegación con restricciones o delegación con restricciones basada en recursos. Tenga en cuenta que no se recomienda configurar la delegación con restricciones a un controlador de dominio (DC), porque un atacante que comprometa una cuenta con delegación con restricciones podrá suplantar a cualquier usuario para cualquier servicio en el DC.
• Utilice la opción “Esta cuenta es sensible y no se puede delegar” para evitar que las cuentas sensibles se utilicen en la delegación.
• Coloque a los usuarios privilegiados en el grupo de Protected Users. Esto ayuda a prevenir que sean utilizados en delegaciones y mantiene sus TGTs fuera del ordenador después de que se autentiquen.
• Monitoree de cerca la actividad de las cuentas delegadas. Todos los sistemas donde se haya configurado y utilizado algún tipo de delegación deben ser monitoreados en busca de actividad sospechosa.

¿Cómo puede ayudar Netwrix?

La delegación sin restricciones es uno de los numerosos vectores de ataque que los malhechores pueden explotar para obtener acceso y mantenerse en su entorno de Active Directory. Con la Netwrix Active Directory Security Solution, podrás:

• Descubra riesgos de seguridad, incluyendo delegaciones innecesarias, permisos excesivos, privilegios permanentes y configuraciones erróneas de GPO, y priorice sus esfuerzos de mitigación.
• Establezca configuraciones seguras en toda su infraestructura de TI y manténgalas identificando y remediando cualquier cambio indebido desde su línea base endurecida.
• Detecte y responda rápidamente a amenazas avanzadas, como Kerberoasting, DCSync, extracción de dit y ataques de Golden Ticket.
• Automatice la respuesta a ataques conocidos para minimizar el daño.
• Asegure una rápida recuperación de Active Directory en caso de una violación de seguridad u otro incidente.

FAQ

¿Qué tipos de delegación están disponibles en Active Directory?

Hay 3 tipos de delegación que su organización puede utilizar:

• Delegación sin restricciones
• Delegación restringida
• Delegación restringida basada en recursos (RBCD)

¿Qué es la delegación restringida basada en recursos (RBCD)?

Con RBCD, un administrador que posee un recurso puede delegar acceso a este.

¿Cómo puedo configurar RBCD?

Para configurar un servicio de recursos para permitir el acceso en nombre de los usuarios, puede utilizar cmdlets de Windows PowerShell (New-ADComputer, New-ADServiceAccount, New-ADUser, Set-ADComputer, Set-ADServiceAccount y Set-ADUser) con el parámetro PrincipalsAllowedToDelegateToAccount.