Elad Shamir

Hay quien es 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 de abuso alternativas más allá del «Kerberoasting» dirigido, y encontré un caso límite (nunca mejor dicho) que se puede encadenar con la delegación restringida de Kerberos.

Tl;dr

Supongamos que un atacante compromete una cuenta configurada para la delegación restringida, pero no dispone del privilegio SeEnableDelegation. El atacante no podrá modificar las restricciones (msDS-AllowedToDelegateTo). Sin embargo, si el atacante dispone de derechos WriteSPN sobre la cuenta asociada al SPN de destino, así como sobre otra cuenta de ordenador o de servicio, podrá secuestrar temporalmente el SPN (una técnica denominada «SPN-jacking»), asignarlo al otro ordenador o servidor y llevar a cabo 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.

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

Introducción a la delegación Kerberos

La delegación de Kerberos es un mecanismo que permite a los servicios suplantar la identidad de los usuarios ante otros servicios. Por ejemplo, un usuario puede acceder a una aplicación front-end y, a su vez, dicha aplicación puede acceder a una API back-end utilizando 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» para un SPN concreto. El atacante ha comprometido el ServidorA y la cuenta NotAdmin, que tiene derechos de «WriteSPN» sobre las cuentas de equipo y de servicio del entorno. 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 añadir el SPN afectado a ServerC y, a continuación, llevar a cabo un ataque S4U completo utilizando la cuenta de ServerA para obtener un ticket de servicio de un usuario con privilegios para ServerC.

El nombre del servicio de ese ticket no sería válido para acceder al Servidor C, ya que el nombre de host no coincidiría y la clase de servicio podría resultar inútil. Sin embargo, lo importante es que el ticket está cifrado para el Servicio C y que el nombre del servicio no figura 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 eludir esa barrera eliminando temporalmente el SPN de destino del Servidor B y añadiéndolo solo entonces al Servidor C. A continuación, el atacante puede llevar a cabo el ataque S4U completo utilizando la cuenta del Servidor A para obtener un ticket de servicio de un usuario con privilegios para el Servidor C.

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 modificados y su nuevo valor. Los defensores pueden detectar SPN con un nombre de host diferente a los nombres DNS del equipo, tal y como se muestra en la siguiente captura de pantalla:

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.