Resource-based Constrained Delegation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Isso é semelhante à Delegação Constrangida básica, mas em vez de dar permissões a um objeto para impersonar qualquer usuário contra um serviço. A Delegação Constrangida Baseada em Recurso define no objeto quem pode impersonar qualquer usuário contra ele.
Neste caso, o objeto constrangido terá um atributo chamado msDS-AllowedToActOnBehalfOfOtherIdentity com o nome do usuário que pode impersonar qualquer outro usuário contra ele.
Outra diferença importante desta Delegação Constrangida em relação às outras delegações é que qualquer usuário com permissões de escrita sobre uma conta de máquina (GenericAll/GenericWrite/WriteDacl/WriteProperty/etc) pode definir o msDS-AllowedToActOnBehalfOfOtherIdentity (Nas outras formas de Delegação, você precisava de privilégios de administrador de domínio).
Na Delegação Constrangida, foi dito que a TrustedToAuthForDelegation flag 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 serviço (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, tentar abusar de uma delegação constrangida básica não funcionará. Mas se você estiver tentando explorar uma delegação constrangida baseada em recurso, funcionará (isso não é uma vulnerabilidade, é um recurso, aparentemente).
Se você tiver privilégios de escrita equivalentes sobre uma conta de Computador, pode obter acesso privilegiado nessa máquina.
Suponha que o atacante já tenha privilégios de escrita equivalentes sobre o computador da vítima.
O atacante compromete uma conta que tem um SPN ou cria um (“Serviço A”). Observe que qualquer Usuário Admin sem nenhum outro privilégio especial pode criar até 10 objetos de Computador (MachineAccountQuota) e definir um SPN para eles. Portanto, o atacante pode simplesmente criar um objeto de Computador e definir um SPN.
O atacante abusa de seu privilégio de ESCRITA sobre o computador da vítima (ServiçoB) para configurar delegação constrangida baseada em recurso para permitir que o ServiçoA impersonifique qualquer usuário contra aquele computador da vítima (ServiçoB).
O atacante usa Rubeus para realizar um ataque S4U completo (S4U2Self e S4U2Proxy) do Serviço A para o Serviço B para um usuário com acesso privilegiado ao Serviço B.
S4U2Self (da conta SPN comprometida/criada): Solicitar um TGS de Administrador para mim (Não Forwardable).
S4U2Proxy: Usar o TGS não Forwardable do passo anterior para solicitar um TGS de Administrador para o host da vítima.
Mesmo que você esteja usando um TGS não Forwardable, como você está explorando a delegação constrangida baseada em recurso, funcionará.
O atacante pode passar o ticket e impersonar o usuário para obter acesso ao ServiçoB da vítima.
Para verificar o MachineAccountQuota do domínio, você pode usar:
Você pode criar um objeto de computador dentro do domínio usando powermad:
Usando o módulo PowerShell do Active Directory
Usando powerview
Primeiro de tudo, criamos o novo objeto Computador com a senha 123456, então precisamos do hash dessa senha:
Isso imprimirá os hashes RC4 e AES para essa conta. Agora, o ataque pode ser realizado:
Você pode gerar mais tickets apenas pedindo uma vez usando o parâmetro /altservice do Rubeus:
Observe que os usuários têm um atributo chamado "Não pode ser delegado". Se um usuário tiver esse atributo como Verdadeiro, você não poderá se passar por ele. Essa propriedade pode ser vista dentro do bloodhound.
A última linha de comando realizará o ataque S4U completo e injetará o TGS do Administrador para o host da vítima na memória. Neste exemplo, foi solicitado um TGS para o serviço CIFS do Administrador, então você poderá acessar C$:
Aprenda sobre os tickets de serviço disponíveis aqui.
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 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 impersoná-lo 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 está em execução)
O fakecomputer criado perdeu seus privilégios sobre o servidor vulnerável e você precisa recuperá-los.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
