Elad Shamir

Algunas personas son un martillo en busca de un clavo, pero yo soy un martillo en busca de la delegación de Kerberos. Así que, cuando me enteré de que se había introducido un borde WriteSPN en BloodHound 4.1, empecé a explorar técnicas alternativas de abuso más allá de Kerberoasting dirigido, y encontré un caso de borde (juego de palabras) que se puede encadenar con Kerberos Constrained Delegation.

Tl;dr

Supongamos que un atacante compromete una cuenta configurada para Delegación Restringida pero no tiene el privilegio SeEnableDelegation. El atacante no podrá cambiar las restricciones (msDS-AllowedToDelegateTo). Sin embargo, si el atacante tiene derechos WriteSPN sobre la cuenta asociada con el SPN objetivo, así como sobre otra cuenta de equipo/servicio, el atacante puede secuestrar temporalmente el SPN (una técnica llamada SPN-jacking), asignarlo al otro equipo/servidor, y realizar un ataque S4U completo para comprometerlo.

Además, si el SPN de destino no está asociado actualmente a ninguna cuenta, el atacante puede apropiárselo de forma similar.

Seré el primero en admitir que no se trata de un descubrimiento innovador, pero puede revivir vías de ataque aparentemente sin salida en determinadas circunstancias. El SPN-jacking también puede ser una técnica de toma de control alternativa si RBCD o Shadow Credentials no son viables.

Introducción a la delegación Kerberos

La delegación Kerberos es un mecanismo que permite a los servicios suplantar usuarios ante otros servicios. Por ejemplo, un usuario puede acceder a una aplicación front-end, y esa aplicación puede, a su vez, acceder a una API back-end con la identidad y los permisos del usuario.

La delegación Kerberos puede ser de tres tipos: Delegación no restringida, delegación restringida y delegación restringida basada en recursos (RBCD).

Delegación ilimitada

La delegación sin restricciones requiere que los usuarios envíen su ticket-ticket (TGT) al servicio front-end (Servidor A). A continuación, el servicio front-end puede utilizar ese ticket para suplantar al usuario ante cualquier servicio, incluido el servicio back-end (Servidor B).

Delegación restringida

La delegación restringida permite al servicio front-end (Servidor A) obtener tiquets de servicio Kerberos para los usuarios a una lista predefinida de servicios especificados por su nombre principal de servicio (SPN), como el servicio back-end, Servidor B.

Ten en cuenta que Constrained Delegation permite al servicio suplantar usuarios de la nada, se hayan autenticado o no en el servicio. Muchos piensan que depende de la configuración del atributo TrustedToAuthForDelegation. Sin embargo, cuando se encadena con Resource-Based Constrained Delegation, esa limitación puede ser eludida, como explico en esta entrada de blog.

Delegación limitada en función de los recursos

La RBCD es muy similar a la Delegación Restringida, salvo que la dirección de la restricción se invierte. Especifica a quién se le permite delegar en un servicio en lugar de a quién se le permite delegar al servicio. En otras palabras, si al Servidor A se le permite delegar en el Servidor B en Delegación Restringida, la restricción se configuraría en un atributo del Servidor A. En RBCD, se configuraría en un atributo del Servidor B.

Otra diferencia importante entre la delegación restringida y la RBCD es que la delegación restringida especifica el SPN del servicio de destino. En cambio, RBCD especifica el SID del servicio de origen en un Descriptor de Seguridad.

Privilegios necesarios

La configuración de la delegación no restringida y la delegación restringida requiere el privilegio SeEnableDelegation, que, de forma predeterminada, sólo se concede a los administradores de dominio. Por lo tanto, aunque un usuario tuviera control total (GenericAll) sobre una cuenta AD, no podría configurar ninguno de estos tipos de delegación Kerberos sin tener también el privilegio SeEnableDelegation. A diferencia de Unconstrained Delegation y Constrained Delegation, RBCD requiere el derecho a cambiar el atributo msDS-AllowedToActOnBehalfOfOtherIdentity, pero no privilegios especiales.

Ten en cuenta que los usuarios necesitan privilegios especiales para cambiar la configuración de la Delegación Restringida, pero no se requieren privilegios especiales para cambiar los SPN. Por lo tanto, puede ser interesante abordar escenarios con el compromiso de la Delegación Restringida desde un ángulo diferente-manipulando el atributo SPN en lugar de la configuración de la delegación.

Preparar el escenario

Supongamos que hay tres servidores en el entorno: ServidorA, ServidorB y ServidorC. El ServidorA está configurado con Delegación Restringida a un determinado SPN. El atacante comprometió el ServidorA y la cuenta NotAdmin, la cual tiene derechos de WriteSPN en cuentas de computadoras/servicios en el ambiente. El objetivo del atacante es comprometer el ServidorC.

Fantasma SPN-jacking

El primer escenario es el más sencillo. El ServidorA está configurado para Delegación Restringida a un SPN previamente asociado a una cuenta de equipo o servicio que ya no existe. Podría tratarse de un SPN estándar, como cifs/hostname, asociado a una cuenta de equipo/servicio eliminada o a una cuenta calculada con un nuevo nombre si los SPN se actualizaran en consecuencia. O la cuenta podría ser un SPN personalizado con una clase de servicio no estándar que se eliminó de la cuenta de equipo/servicio, o la propia cuenta podría haber dejado de existir.

En este escenario, el atacante puede agregar el SPN afectado al ServidorC y luego ejecutar el ataque S4U completo utilizando la cuenta del ServidorA para obtener un ticket de servicio para un usuario privilegiado al ServidorC.

El nombre de servicio de ese ticket no sería válido para acceder a ServerC porque el nombre de host no coincidiría, y la clase de servicio podría ser inútil. Sin embargo, lo importante es que el ticket está cifrado para ServiceC, y el nombre de servicio no está en la parte cifrada del ticket, por lo que el atacante puede cambiarlo por uno válido.

Finalmente, el atacante puede pasar -el ticket y comprometer el ServidorC.

La cadena de ataque se ilustra en el siguiente diagrama:

El ataque se muestra en la siguiente captura de pantalla:

SPN-jacking en directo

El segundo escenario es un poco más artificioso. El ServidorA está configurado para Delegación Restringida a un SPN actualmente asociado con el ServidorB, y el atacante tiene derechos de WriteSPN en el ServidorB y el ServidorC.

En entornos totalmente parcheados, sólo los administradores de dominio pueden configurar SPN conflictivos, es decir, SPN asociados a dos o más cuentas diferentes. Por lo tanto, si el atacante en este escenario intentara agregar el SPN objetivo al ServidorC, el DC rechazaría ese cambio porque ya está asociado con el ServidorB.

El atacante puede sortear esa barrera eliminando temporalmente el SPN objetivo del ServidorB y sólo entonces añadirlo al ServidorC. El atacante puede entonces ejecutar el ataque S4U completo utilizando la cuenta del ServidorA para obtener un ticket de servicio para un usuario privilegiado al ServidorC.

Como en el escenario anterior, el nombre de servicio de ese ticket no sería válido para acceder al ServidorC. Sin embargo, lo importante es que el ticket está cifrado para ServerC, y el nombre de servicio no está en la parte cifrada del ticket, por lo que el atacante puede cambiarlo.

Finalmente, el atacante puede pasar -el ticket y comprometer el ServidorC.

Un atacante que se comporte bien también debería deshacer los cambios eliminando el SPN de destino del ServidorC y restaurándolo en el ServidorB.

La cadena de ataque se ilustra en el siguiente diagrama:

SPN-jacking con la clase de servicio HOST

La cosa se pone más interesante cuando el SPN objetivo no está definido explícitamente. Por defecto, las cuentas de equipo tienen SPN asociados a las clases de servicio TERMSRV, RestrictedKrbHost y HOST. Si se instalan otros servicios, como LDAP o SQL Server, también se añaden SPN adicionales para ellos.

La clase de servicio HOST se asigna por defecto a las siguientes clases de servicio:
alerter, appmgmt, cisvc, clipsrv, browser, dhcp, dnscache, replicator, eventlog, eventsystem, policyagent, oakley, dmserver, dns, mcsvc, fax, msiserver, ias, messenger, netlogon, netman, netdde, netddedsm, nmagent, plugplay, protectedstorage, rasman, rpclocator, rpc, rpcss, remoteaccess, rsvp, samss, scardsvr, scesrv, seclogon, scm, dcom, cifs, spooler, snmp, schedule, tapisrv, trksvr, trkwks, ups, time, wins, www, http, w3svc, iisadmin, msdtc.

Si el atacante intentara apuntar a una clase de servicio asignada a HOST, el controlador de dominio rechazaría añadir esa clase de servicio a ServerC, aunque no esté directamente asociada a ServerB. El atacante tendría que eliminar primero los SPN de HOST del ServidorB y después añadir explícitamente el SPN objetivo al ServidorC. Sin embargo, después de añadir el SPN de destino al ServidorC, el atacante puede volver a añadir los SPNs HOST al ServidorB sin encontrar ningún error de validación, a pesar de tener ya un SPN mapeado asociado al ServidorC, como se demuestra en la siguiente captura de pantalla:

Al solicitar tickets de servicio al SPN ambiguo, cifs/SERVERB en la captura de pantalla anterior, el Controlador de Dominio lo emite para ServerC en lugar de ServerB.

La cadena de ataque se ilustra en el siguiente diagrama:

¿Cómo pueden utilizar los atacantes el SPN-jacking?

Si un atacante comprometiera una cuenta con derechos GenericAll o GenericWrite en cuentas de equipo, el atacante podría usar RBCD o Shadow Credentials para comprometer el host o servicio asociado. Sospecho que comprometer una cuenta con sólo derechos WriteSPN en cuentas de equipo no es muy probable. Sin embargo, encadenado con el compromiso de un host con Constrained Delegation ya configurado, los atacantes podrían utilizar esta técnica en entornos donde RBCD y Shadow Credentials están monitorizados o bloqueados. Los defensores deben seguir las siguientes recomendaciones para mitigar los ataques de SPN-jacking.

Detección de SPN-jacking

Los cambios en el atributo ServicePrincipalName de una cuenta de equipo generan eventos de seguridad con el ID 4742 (Se ha modificado una cuenta de equipo) en el controlador de dominio. Los detalles del evento muestran los atributos cambiados y su nuevo valor. Defenders puede detectar NPS con un nombre de host diferente de los nombres DNS del equipo, como se muestra en la captura de pantalla siguiente:

Eliminar la clase de servicio HOST de una cuenta informática también puede ser sospechoso.

El ataque S4U genera dos eventos de seguridad con ID 4769 (Se solicitó un ticket de servicio Kerberos).

El primer evento es para S4U2Self. Los defensores pueden detectarlo cuando la información de la cuenta y la información del servicio apuntan a la misma cuenta, como se muestra en la siguiente captura de pantalla:

El segundo evento es para S4U2Proxy. Defenders puede detectarlo cuando el atributo Transited Services no está en blanco, como se muestra en la siguiente captura de pantalla:

Prevención del SPN-jacking

Los defensores pueden aplicar varias tácticas para evitar este tipo de abusos:

  • Audite periódicamente Active Directory en busca de delegaciones restringidas que apunten a SPN fantasmas.
  • Auditar periódicamente Active Directory en busca de derechos WriteSPN anómalos.
  • Añada todas las cuentas con privilegios al grupo Usuarios protegidos para bloquear cualquier intento de suplantación de identidad a través de la delegación Kerberos.

Los atacantes pueden manipular el SPN de las cuentas de equipos/servicios para redirigir la Delegación Restringida preconfigurada a objetivos no deseados, incluso sin obtener privilegios de SeEnableDelegation.

Aunque los escenarios descritos en este artículo no son comunes, pueden presentar rutas de ataque viables cuando una cuenta comprometida está configurada para una Delegación Restringida que de otra manera sería considerada benigna o como una alternativa a RBCD y Credenciales en la Sombra.

Los defensores deben tomar las medidas necesarias para detectar y prevenir este tipo de ataques.

Referencias

Este post también se publicó en shenaniganslabs.io y eladshamir.com.