search

page4S4U2self

BUIUHNYUGBGNDSDMHMUAMJDJDIJOA;OKDOPKJIDAMJ)DMUJOIQAIJODUNHIAIUMHDNUIHADNUIHIODJPIMJO;DAI;JDOJ;IDMOIJAHUIDG/) NTNY/)DNY")(NE//"EU)(=

En el mundo real, no podemos esperar a que un administrador inicie sesión. Afortunadamente, no tenemos que hacerlo. Podemos forzar a un equipo a autenticarse con nosotros.

En las bases es la misma mierda que un Unconstrained Delegation pero con mas pasos y mas por culero

hashtag
Paso 1: Forzar la Autenticación y Capturar el TGT

Existen múltiples "desencadenantes de autenticación remota" que pueden obligar a un equipo a autenticarse en otro. Dos técnicas muy conocidas son:

  • SpoolSample (de Lee Christensen): Abusa del Protocolo Remoto del Sistema de Impresión ([MS-RPRN]).

  • PetitPotam (de Topotam): Abusa del Protocolo Remoto del Sistema de Archivos Cifrados ([MS-EFSRPC]).

El plan de ataque es el siguiente:

  1. En nuestro servidor comprometido ([SERVIDOR_COMPROMETIDO]), que tiene delegación sin restricciones, iniciamos Rubeus para monitorear los TGTs entrantes.

  2. Desde cualquier máquina en el dominio, usamos un desencadenante como SharpSpoolTrigger para ordenar al Controlador de Dominio ([CONTROLADOR_DOMINIO]) que se autentique en nuestro servidor ([SERVIDOR_COMPROMETIDO]).

En [SERVIDOR_COMPROMETIDO] (nuestra máquina comprometida):

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe monitor /interval:5 /nowrap

Desde otra máquina (lanzando el ataque):

beacon> execute-assembly C:\Tools\SharpSystemTriggers\SharpSpoolTrigger\bin\Release\SharpSpoolTrigger.exe [CONTROLADOR_DOMINIO] [SERVIDOR_COMPROMETIDO]
NdrClientCall2x64[-]RpcRemoteFindFirstPrinterChangeNotificationEx status: 6

Inmediatamente, Rubeus en [SERVIDOR_COMPROMETIDO] capturará el TGT del Controlador de Dominio. 

[*] 21/02/2025 11:54:39 UTC - Found new TGT:
  User                  :  [CONTROLADOR_DOMINIO]$@[DOMINIO.COM]
  StartTime             :  21/02/2025 10:39:21
  EndTime               :  21/02/2025 20:38:58
  RenewTill             :  28/02/2025 10:38:58
  Flags                 :  name_canonicalize, pre_authent, renewable, forwarded, forwardable
  Base64EncodedTicket   :    doIFt[...snip...]5DT00=

hashtag
Paso 2: El Problema (Por qué el TGT de la Máquina no es Suficiente)

Podrías pensar que el juego ha terminado. Tenemos el TGT del DC. Sin embargo, si inyectamos este ticket e intentamos acceder a un recurso administrativo como la unidad C$, fallaremos.

El acceso es denegado. Esto se debe a una característica de seguridad de Windows: las cuentas de equipo no tienen acceso de administrador local a sí mismas de forma remota. El TGT [CONTROLADOR_DOMINIO]$ no nos da derechos administrativos sobre [CONTROLADOR_DOMINIO].

hashtag
Paso 3: La Solución (El Abuso de S4U2self "Wagging the Dog")

Aquí es donde entra en juego una técnica brillante, popularizada por Elad Shamir e implementada en Rubeus por Charlie Clark.

Podemos usar el TGT de la máquina ([CONTROLADOR_DOMINIO]$) para realizar una solicitud S4U2self.

Normalmente, S4U2self se usa en la delegación restringida para obtener un ticket para un usuario hacia el propio servicio. Pero aquí, vamos a abusar de él.

Usaremos el comando s4u de Rubeus con dos parámetros especiales: /self y /altservice.

Analicemos esto:

  • /impersonateuser:[USUARIO_ADMIN]: Le decimos al KDC que queremos un ticket en nombre del usuario [USUARIO_ADMIN].

  • /ticket:...: Proporcionamos el TGT de la máquina ([CONTROLADOR_DOMINIO]$) que capturamos.

  • /self: Esta es la clave. Le dice a Rubeus que solo realice la parte S4U2self (solicitando un ticket para [USUARIO_ADMIN]@[CONTROLADOR_DOMINIO]$) y que no intente un S4U2proxy.

  • /altservice:cifs/[CONTROLADOR_DOMINIO]: Esta es la magia. Rubeus recibe el ticket de S4U2self (que sería para [USUARIO_ADMIN]@[CONTROLADOR_DOMINIO]$) y simplemente reemplaza el nombre del servicio dentro del ticket por cifs/[CONTROLADOR_DOMINIO].

El resultado es un ticket de servicio perfectamente válido para el usuario [USUARIO_ADMIN] dirigido al servicio cifs/[CONTROLADOR_DOMINIO].

¿Por qué funciona esto? El ticket de servicio está cifrado con la clave del servicio de destino. En este caso, el servicio es cifs/[CONTROLADOR_DOMINIO], que se ejecuta en el contexto de SYSTEM en [CONTROLADOR_DOMINIO]... es decir, ¡la cuenta [CONTROLADOR_DOMINIO]$!

Dado que el KDC emitió el ticket original basándose en el TGT de [CONTROLADOR_DOMINIO]$, y el servicio CIFS se ejecuta como [CONTROLADOR_DOMINIO]$, el DC puede descifrar y aceptar este ticket sin problemas.

Ahora, inyectamos este nuevo ticket de servicio. Al listar nuestros tickets, vemos que ya no somos [CONTROLADOR_DOMINIO]$, sino [USUARIO_ADMIN] con un ticket para cifs.

Hemos convertido un TGT de cuenta de máquina, obtenido al forzar una autenticación en un servidor con delegación sin restricciones, en un acceso administrativo completo al Controlador de Dominio.

AnteriorService Name SubstitutionSiguienteSPN-less RBCD

Última actualización