Auditar los permisos de GPO y los derechos gPLink

Una GPO es ejecución de código en todos los equipos a los que se aplica. Una tarea programada, un script de inicio o una entrada de grupos restringidos distribuidos mediante una GPO vinculada a la OU Domain Controllers se ejecutan como SYSTEM en todos los controladores de dominio en el siguiente ciclo de actualización. Eso convierte en Tier 0 tres permisos siempre que afectan a sistemas de Tier 0: el derecho a editar una GPO, el derecho a vincular una GPO a una OU, un sitio o un dominio, y el derecho a crear GPO. Las herramientas de rutas de ataque como BloodHound sacan a la luz de forma habitual derechos GpoEdit o de escritura en gPLink en manos de grupos de soporte, y están entre las rutas más comunes hacia el compromiso del dominio que se encuentran en las evaluaciones.

El pilar de directiva de grupo y SYSVOL presenta la distinción entre edición y vinculación con una comprobación rápida de la raíz del dominio y de la OU de los controladores de dominio. Esta guía va más allá: todas las GPO, todas las OU y sitios, la propiedad de las GPO, el grupo de creadores, los filtros WMI y el cruce entre todo ello que le dice qué hallazgos son realmente de Tier 0.

Cómo se almacenan los permisos de las GPO

Una GPO tiene dos mitades. El Group Policy Container (GPC) es un objeto de AD en CN={GUID},CN=Policies,CN=System,<domain DN>; el Group Policy Template (GPT) es la carpeta \\<domain>\SYSVOL\<domain>\Policies\{GUID}. La consola de administración de directivas de grupo (GPMC) y el módulo GroupPolicy de PowerShell escriben permisos coincidentes en ambas, expresados en cinco niveles: GpoRead, GpoApply, GpoEdit, GpoEditDeleteModifySecurity y GpoCustom. Cualquiera con acceso de escritura a cualquiera de las dos mitades puede cambiar lo que hace la directiva.

Los derechos de vinculación son independientes y residen en el destino: el acceso de escritura al atributo gPLink (GUID de esquema f30e3bbe-9ff0-11d1-b603-0000f80367c1) en un objeto de OU, dominio o sitio decide qué GPO se aplican ahí. gPOptions (f30e3bbf-9ff0-11d1-b603-0000f80367c1) controla el bloqueo de herencia. GenericAll, GenericWrite, WriteDacl y WriteOwner sobre la OU implican ambos.

Medir: asignar las GPO a lo que alcanzan

Empiece por el cruce que determina la gravedad: qué GPO se aplican a sistemas de Tier 0. Como mínimo, incluya la OU Domain Controllers, la raíz del dominio y cualquier OU que contenga servidores de Tier 0 (AD CS, Entra Connect, copia de seguridad, PAM) de su inventario de Tier 0.

Import-Module GroupPolicy, ActiveDirectory
$domain = Get-ADDomain
$tier0Targets = @(
    $domain.DomainControllersContainer
    $domain.DistinguishedName
    'OU=Tier0 Servers,OU=Admin,DC=corp,DC=example'   # adaptar a su estructura
)

$tier0Gpos = foreach ($t in $tier0Targets) {
    (Get-GPInheritance -Target $t).InheritedGpoLinks |
        Select-Object @{n='Target';e={$t}}, DisplayName, GpoId, Enforced
}
$tier0Gpos | Sort-Object DisplayName -Unique | Format-Table -AutoSize

InheritedGpoLinks incluye las GPO vinculadas en niveles superiores y los vínculos exigidos, así que refleja lo que realmente se aplica. Las GPO vinculadas a sitios también se aplican a los controladores de dominio de ese sitio; enumérelas con el atributo gPLink de los objetos de CN=Sites,CN=Configuration,... (véase más abajo).

Auditar: derechos de edición y propiedad de las GPO

Enumere todos los titulares no predeterminados con acceso de nivel de edición o propiedad, y marque las GPO que alcanzan Tier 0:

$defaultTrustees = 'Domain Admins','Enterprise Admins','SYSTEM','ENTERPRISE DOMAIN CONTROLLERS','Authenticated Users'
$tier0Ids = $tier0Gpos.GpoId | ForEach-Object { $_.ToString() }

Get-GPO -All | ForEach-Object {
    $gpo = $_
    $perms = Get-GPPermission -Guid $gpo.Id -All |
        Where-Object { $_.Permission -in 'GpoEdit','GpoEditDeleteModifySecurity','GpoCustom' -and
                       $_.Trustee.Name -notin $defaultTrustees }
    foreach ($p in $perms) {
        [pscustomobject]@{
            GPO        = $gpo.DisplayName
            Tier0      = $tier0Ids -contains $gpo.Id.ToString()
            Trustee    = "$($p.Trustee.Domain)\$($p.Trustee.Name)"
            Permission = $p.Permission
            Owner      = $gpo.Owner
        }
    }
} | Sort-Object Tier0, GPO -Descending | Format-Table -AutoSize

GpoCustom requiere revisar manualmente la ACE subyacente, porque puede ocultar un único WriteProperty o WriteDacl. Revise también la columna Owner por separado: el propietario del GPC tiene derechos implícitos para cambiar sus permisos. Las GPO creadas por miembros de Group Policy Creator Owners pertenecen a ese miembro, no a Domain Admins.

La GPMC también informa cuando los permisos de AD y de SYSVOL no coinciden («The permissions for this GPO in the SYSVOL folder are inconsistent»). Una incoherencia suele significar que alguien editó directamente la ACL NTFS o la ACL de AD; compruebe la carpeta GPT cuando el GPC parezca limpio:

$gpoPath = "\\$($domain.DNSRoot)\SYSVOL\$($domain.DNSRoot)\Policies"
foreach ($id in $tier0Ids) {
    (Get-Acl "$gpoPath\{$id}").Access |
        Where-Object { $_.FileSystemRights -match 'Write|Modify|FullControl|ChangePermissions|TakeOwnership' } |
        Select-Object @{n='GPO';e={$id}}, IdentityReference, FileSystemRights, IsInherited
}

Auditar: derechos de vinculación en OU, dominio y sitios

A continuación, localice todas las entidades de seguridad no administradoras que puedan escribir gPLink en cualquier lugar. Filtre los SID de administración conocidos por su sufijo y no por su nombre, para que no se cuelen los nombres de grupo localizados.

$gpLink  = [guid]'f30e3bbe-9ff0-11d1-b603-0000f80367c1'
$adminRx = '-(512|518|519)$|^S-1-5-18$|^S-1-5-32-544$|^S-1-5-9$'   # DA, Schema Admins, EA, SYSTEM, Administrators, EDCs
$configNC = (Get-ADRootDSE).configurationNamingContext

$targets = @($domain.DistinguishedName) +
           (Get-ADOrganizationalUnit -Filter * | Select-Object -ExpandProperty DistinguishedName) +
           (Get-ADObject -SearchBase "CN=Sites,$configNC" -LDAPFilter '(objectClass=site)' |
                Select-Object -ExpandProperty DistinguishedName)

foreach ($t in $targets) {
    (Get-Acl "AD:\$t").Access | Where-Object {
        $_.AccessControlType -eq 'Allow' -and (
            ($_.ActiveDirectoryRights -match 'WriteProperty' -and $_.ObjectType -in $gpLink, [guid]::Empty) -or
            $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner')
    } | ForEach-Object {
        $sid = try { $_.IdentityReference.Translate([Security.Principal.SecurityIdentifier]).Value } catch { $_.IdentityReference.Value }
        if ($sid -notmatch $adminRx) {
            [pscustomobject]@{
                Target    = $t
                Trustee   = $_.IdentityReference.Value
                Rights    = $_.ActiveDirectoryRights
                Inherited = $_.IsInherited
            }
        }
    }
} | Sort-Object Target | Format-Table -AutoSize

Es normal encontrar algunas delegaciones legítimas en OU departamentales. Cualquier cosa sobre la raíz del dominio, la OU Domain Controllers, un sitio que contenga controladores de dominio o una OU con servidores de Tier 0 es un hallazgo. Recuerde que las GPO vinculadas a sitios se aplican a todos los equipos del sitio, controladores de dominio incluidos, así que el acceso de escritura a un objeto de sitio es tan sensible como la raíz del dominio. Para la cuestión más amplia de qué otras ACE de esas OU importan, consulte auditar las ACL de AD.

Auditar: creación de GPO y filtros WMI

Get-ADGroupMember 'Group Policy Creator Owners' -Recursive | Select-Object Name, objectClass

# Quién puede crear GPO directamente en el contenedor Policies
$policies = "CN=Policies,CN=System,$($domain.DistinguishedName)"
(Get-Acl "AD:\$policies").Access |
    Where-Object { $_.ActiveDirectoryRights -match 'CreateChild|GenericAll' } |
    Select-Object IdentityReference, ActiveDirectoryRights

# Filtros WMI: el acceso de escritura cambia el destino de todas las GPO que los usan
$som = "CN=SOM,CN=WMIPolicy,CN=System,$($domain.DistinguishedName)"
Get-ADObject -SearchBase $som -LDAPFilter '(objectClass=msWMI-Som)' -Properties msWMI-Name |
    ForEach-Object {
        $f = $_
        (Get-Acl "AD:\$($f.DistinguishedName)").Access |
            Where-Object { $_.ActiveDirectoryRights -match 'Write|GenericAll' } |
            Select-Object @{n='Filter';e={$f.'msWMI-Name'}}, IdentityReference, ActiveDirectoryRights
    }

Group Policy Creator Owners debería estar vacío. Un filtro WMI con permiso de escritura permite a quien lo edita ampliar el ámbito de una GPO, por ejemplo para que una GPO de estaciones de trabajo gestionada por el soporte se aplique también a los servidores.

Interpretar los resultados: hallazgos habituales

Unos pocos patrones explican la mayoría de los hallazgos en dominios reales. Conocerlos acelera la clasificación.

• Soporte o equipo de servidores con GpoEdit sobre Default Domain Policy o Default Domain Controllers Policy. Normalmente concedido hace años para que un equipo pudiera cambiar una sola configuración. Ambas GPO alcanzan Tier 0, así que equivale a ser Domain Admin. Traslade la configuración que necesitan a una GPO limitada a su propia OU y retire el derecho.
• Un antiguo administrador como propietario de la GPO. La propiedad sobrevive a los cambios de pertenencia a grupos e incluso al cambio de nombre de la cuenta. Si esa cuenta está deshabilitada, el riesgo es bajo, pero la propiedad sigue impidiendo auditorías limpias; si sigue habilitada, conserva derechos implícitos sobre los permisos de la GPO.
• Authenticated Users o Domain Users con GpoEdit. Casi siempre un error cometido al configurar el filtrado de seguridad, cuando alguien eligió el nivel de permiso equivocado. Es un hallazgo crítico si la GPO está vinculada en algún sitio.
• Cuentas de servicio con derechos de vinculación. A las herramientas de implementación y aprovisionamiento a veces se les concede acceso de escritura amplio sobre las OU para que puedan mover equipos, lo que incluye sin avisar gPLink. Limite su delegación a los tipos de objeto y atributos concretos que necesitan.
• GenericAll heredado en un árbol de OU. Una delegación hecha en una OU principal se propaga a todas las secundarias, incluida cualquier OU de Tier 0 que alguien haya creado después debajo. Las OU de Tier 0 deben bloquear la herencia de ACE delegadas o quedar completamente fuera de los árboles delegados.

Trate cualquier hallazgo sobre una GPO que aparezca en el cruce de Tier 0 del paso Medir como un hallazgo de Tier 0, diga lo que diga el nombre de la GPO.

Aplicar: retirar y volver a delegar

Retire los derechos de edición no administrativos sobre las GPO de Tier 0 con el módulo GroupPolicy, que actualiza tanto el GPC como el GPT:

Set-GPPermission -Name 'Default Domain Controllers Policy' -TargetName 'CORP\Helpdesk' `
    -TargetType Group -PermissionLevel None -Replace

Retire una delegación de gPLink de una OU eliminando la ACE concreta y no todas las ACE del titular:

$ou  = 'OU=Tier0 Servers,OU=Admin,DC=corp,DC=example'
$acl = Get-Acl "AD:\$ou"
$acl.Access | Where-Object { $_.IdentityReference -eq 'CORP\Helpdesk' -and $_.ObjectType -eq $gpLink -and -not $_.IsInherited } |
    ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:\$ou" -AclObject $acl

Si la ACE es heredada, corríjala en la OU principal donde está definida. Después vuelva a delegar correctamente: los administradores departamentales reciben GpoEdit sobre sus propias GPO y derechos de vinculación solo sobre su propia OU (GPMC > la OU > pestaña Delegation > Link GPOs), y las GPO de Tier 0 solo las editan administradores de Tier 0 desde una estación de trabajo de acceso privilegiado. Tome posesión de las GPO que pertenecen a antiguos creadores y asigne la propiedad a Domain Admins.

Verificar

Vuelva a ejecutar los tres bloques de auditoría; las filas de Tier 0 solo deberían mostrar ahora titulares administradores predeterminados. Confírmelo con Get-GPPermission -Name '<GPO>' -All en cada GPO de Tier 0 y compruebe que la GPMC no muestra advertencias de incoherencia en SYSVOL. Después haga visible la deriva: habilite "Audit Directory Service Changes" en los controladores de dominio y añada SACL de escritura sobre los objetos groupPolicyContainer y sobre gPLink en las OU. Los eventos 5136 (atributo modificado, incluidos gPLink y versionNumber), 5137 (GPO creada) y 5141 (GPO eliminada) registrarán entonces cada cambio; la referencia de ID de eventos de AD explica cómo interpretarlos.

Qué se rompe

• Retirar los derechos de edición del soporte o de los administradores de sede sobre GPO compartidas les impide hacer cambios que antes gestionaban por su cuenta. Deles sus propias GPO, limitadas a sus OU.
• Retirar los derechos de gPLink significa que los administradores delegados ya no pueden vincular GPO a OU fuera de su ámbito, y todo lo que hubieran vinculado más arriba sigue funcionando hasta que alguien lo desvincule; revise también los vínculos existentes.
• Vaciar Group Policy Creator Owners bloquea la creación de GPO para esos miembros; la creación debe pasar por el grupo designado.
• Tomar posesión de las GPO elimina el WriteDacl implícito que tenía el antiguo propietario, lo que puede romper automatizaciones que se ejecutaban con esa cuenta y modificaban permisos.
• Cambiar el filtrado de seguridad durante la limpieza: desde MS16-072 (junio de 2016), los equipos leen las GPO en su propio contexto de seguridad, así que si quita Authenticated Users de la ACL de una GPO debe dejar Read para Domain Computers (o para los equipos de destino), o la GPO dejará de aplicarse sin avisar.
• Restringir las ACL de los filtros WMI impide que quienes no son administradores ajusten el destino, algo que algunos equipos usan para despliegues por versión del sistema operativo.

Lecturas relacionadas: el tema Directiva de grupo y SYSVOL, gestión de rutas de ataque para priorizar las aristas de GPO en el grafo general, y eliminar las contraseñas de GPP para el otro hallazgo histórico de las GPO.