GPO abuse (SharpGPOAbuse, Restricted Groups)
Las Group Policy Objects (GPO) son objetos AD con su propia DACL: si un usuario tiene WriteDacl, WriteOwner, GenericWrite o GenericAll sobre una GPO, puede inyectar directivas en ella y hacer que los equipos que la aplican ejecuten cambios elegidos por el atacante. Es una rama del abuso de ACLs que escala de un permiso sobre un objeto a ejecución de código en muchos hosts.
Enumeración
Primero se localizan las GPO y quién tiene derechos de escritura sobre ellas. Con PowerView, desde una máquina del dominio:
Get-DomainGPO | select displayname # inventario de GPO
$sid = Convert-NameToSid "Domain Users"
Get-DomainGPO | Get-ObjectAcl | ? { $_.SecurityIdentifier -eq $sid } # que puede escribir "Domain Users"
Get-GPO -Guid <GUID> # nombre a partir de un GUIDDesde Linux, BloodHound marca la arista GPO con derechos de escritura, y netexec con el módulo gpp_autologin/gpp_password cubre el caso de credenciales guardadas en SYSVOL (ver gpp-cpassword).
Explotación
El vector más limpio es Restricted Groups (--AddLocalAdmin): la GPO impone a los clientes que un usuario esté en el grupo local Administrators. Cuando la GPO aplica al DC (por ejemplo, la Default Domain Policy), el propio DC obedece y el atacante se vuelve Local Admin del DC, luego SYSTEM con psexec.
.\SharpGPOAbuse.exe --AddLocalAdmin --GPOName "Default Domain Policy" --UserAccount <me>
gpupdate /forceOtras primitivas de SharpGPOAbuse:
--AddUserRights SeTakeOwnershipPrivilege(más quirúrgico, menos ruido)--AddComputerScript/--AddUserScript(script de logon/arranque)--AddComputerTask(tarea programada como SYSTEM en el cliente)
Desde Linux sin tocar Windows, pyGPOAbuse hace lo mismo (crea una tarea inmediata que ejecuta un comando en el siguiente gpupdate, cada 90 min por defecto):
pygpoabuse.py <domain>/<me>:<pw> -gpo-id <GUID> -command 'net localgroup administrators <me> /add'Matices. BloodHound modela las relaciones GPO→OU→objetos: GPO GPLink OU, OU Contains User/Computer. La escalada real es la composición completa, no solo tener escritura en la GPO: hay que comprobar a qué OU está enlazada y qué objetos cuelgan de ella. El cambio no es inmediato: el cliente lo aplica en el siguiente ciclo de gpupdate. Modificar una GPO deja rastro en SYSVOL y en el gPCFileSysPath, y los EDR modernos alertan sobre cambios en Default Domain Policy.
Cómo detectarlo. Editar la GPO deja dos rastros paralelos: en el directorio, un Event ID 5136 (se modificó un objeto del servicio de directorio) sobre el objeto de la GPO (típicamente el atributo versionNumber o gPCMachineExtensionNames); en disco, cambios en los ficheros del SYSVOL bajo \Policies\{GUID}\ que un FIM detecta al vuelo. La aplicación en el cliente materializa el pago: --AddLocalAdmin genera un 4732 (miembro añadido al grupo local Administrators) en cada equipo afectado, y --AddComputerTask un 4698 (se creó una tarea programada) como SYSTEM. Que la GPO tocada sea la Default Domain Policy o la Default Domain Controllers Policy eleva cualquiera de esos eventos a incidente.
Defensa. Auditar quién tiene WriteDacl/WriteOwner/GenericWrite sobre GPO Tier-0 (Default Domain Policy, Default Domain Controllers Policy). Monitorizar cambios de gPCFileSysPath y de contenido en SYSVOL con FIM. Usar Restricted Groups solo en OUs concretas, nunca en Default Domain Policy. Es hermano del cPassword en GPP y desemboca en ejecución como SYSTEM.
Máquinas donde se aplica
- VaultProving Grounds Practice