Derechos Usuario Peligrosos GPO Active Directory SeDebug SeTcb: Escalada de Privilegios SeLoadDriver a SYSTEM

Qué es una asignación de derechos de usuario peligrosa en Active Directory

Group Policy no solo distribuye software o mapea unidades de red: su contenedor Security Settings también puede otorgar derechos de usuario locales (los "privilegios" del modelo de token de acceso de Windows, distintos de los permisos sobre objetos) a cualquier principal de seguridad, incluidos Authenticated Users, Domain Users o un grupo personalizado. Cuando la sección [Privilege Rights] de una GPO asigna un privilegio de alto impacto como SeDebugPrivilege, SeLoadDriverPrivilege o SeTcbPrivilege a cuentas que no son administradores locales, cada equipo al que se aplica esa GPO hereda una vía directa, sin necesidad de exploit, entre "cualquier cuenta del dominio" y SYSTEM. Los equipos de seguridad y los auditores señalan cada vez más este patrón — derechos de usuario peligrosos otorgados vía GPO — como un hallazgo de Active Directory distinto, diferente de la más conocida mala configuración "la GPO añade un usuario al grupo Administradores locales".

Esto no es una vulnerabilidad de Windows, sino un error al redactar la Group Policy, normalmente introducido para desbloquear un agente de monitorización, una herramienta de backup o una herramienta de helpdesk que legítimamente necesita derechos elevados, y que luego se deja así (o se copia en GPO sin relación) mucho después de que la justificación original desaparezca. Las malas configuraciones de GPO están entre las formas más comunes en que Group Policy se convierte en un vector de ataque, precisamente porque son silenciosas: nada se rompe, no salta ninguna alerta, y la GPO sigue aplicándose en cada ciclo de actualización de la política.

El radio de impacto depende del vínculo de la GPO, no de cómo se justificó la asignación. Una GPO creada para arreglar el agente de monitorización de un solo servidor, y luego vinculada por comodidad a una OU o a la raíz del dominio, otorga silenciosamente el mismo derecho a todos los equipos bajo ese vínculo — convirtiendo una excepción estrecha y defendible en una vía de escalada a nivel de dominio que nadie aprobó, otra variante de las rutas ocultas hacia Domain Admin del anidamiento peligroso de grupos.

Por qué Active Directory considera peligrosos estos derechos de usuario otorgados vía GPO

Windows aplica alrededor de tres decenas de derechos de usuario a través del token de acceso. La mayoría son inofensivos en malas manos — "Cambiar la zona horaria" no es una vía hacia SYSTEM. Tres de ellos son la excepción.

SeDebugPrivilege ("Depurar programas")

SeDebugPrivilege permite a su titular abrir un handle hacia cualquier proceso o hilo de la máquina, sorteando el control de acceso que normalmente impediría a un no propietario tocar el proceso de otro usuario — incluidos los procesos propiedad de NT AUTHORITY\SYSTEM. Como LSASS se ejecuta como SYSTEM y mantiene en memoria material de credenciales en caché, una cuenta con SeDebugPrivilege puede abrir un handle hacia LSASS y volcar credenciales utilizables — la misma primitiva que usa el módulo sekurlsa de Mimikatz, y la misma que hay detrás de técnicas living-off-the-land como volcar LSASS mediante la exportación MiniDump de comsvcs.dll. Por defecto, solo los administradores tienen este derecho.

SeLoadDriverPrivilege ("Cargar y descargar controladores de dispositivo")

SeLoadDriverPrivilege permite a su titular cargar un controlador en modo kernel a través de la API NtLoadDriver(). Los controladores de kernel se ejecutan sin ninguna barrera de seguridad frente al resto del sistema operativo, así que una cuenta con este derecho puede registrar y cargar un controlador firmado conocido por ser vulnerable (el controlador Capcom.sys es un ejemplo bien documentado) y usarlo como primitiva para leer/escribir memoria de kernel o ejecutar código arbitrario como SYSTEM — una técnica conocida habitualmente como BYOVD (Bring Your Own Vulnerable Driver). Esta vía sigue siendo relevante incluso frente a un EDR moderno, ya que un controlador vulnerable firmado es de confianza para los controles de integridad de código que bloquean el código sin firmar.

SeTcbPrivilege ("Actuar como parte del sistema operativo")

SeTcbPrivilege es el más directo de los tres: permite a su titular llamar a las API de autenticación normalmente reservadas para la Trusted Computing Base de Windows, lo que incluye suplantar a cualquier cuenta del sistema, incluida SYSTEM. Un atacante con este derecho no necesita volcar credenciales ni cargar un controlador — puede crear un servicio que llame directamente a las API de logon de confianza y suplantar a SYSTEM sin rodeos. En un sistema correctamente configurado, ninguna cuenta que no sea administrador debería tener nunca SeTcbPrivilege.

🚨 Peligro: los tres derechos se consideran críticos porque ninguno requiere un exploit de ejecución de código. Si la GPO otorga el derecho, la escalada es un uso documentado y compatible de una API de Windows — no un fallo.

La cadena de ataque: de la mala configuración de GPO a SYSTEM

Paso 1 — Descubrir la asignación

Un atacante que ya cuenta con un punto de apoyo en el dominio (un usuario phishing, una cuenta de servicio con pocos privilegios) enumera las GPO aplicadas a las OU de interés — controladores de dominio, servidores tier-0, hosts de salto — y lee la sección [Privilege Rights] del GptTmpl.inf de cada GPO en SYSVOL, que por defecto puede leer cualquier usuario autenticado:

# Enumerar la seccion User Rights Assignment de cada GPO para los tres derechos criticos
Get-GPO -All | ForEach-Object {
    $report = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
    $report.GPO.Computer.ExtensionData.Extension.UserRightsAssignment |
        Where-Object { $_.Name -match 'SeDebugPrivilege|SeLoadDriverPrivilege|SeTcbPrivilege' } |
        Select-Object @{n='GPO';e={$report.GPO.Name}}, Name, Member
}

Paso 2 — Confirmar que la cuenta está dentro del alcance

El atacante comprueba si su cuenta actual — o un grupo que controla, incluido un grupo amplio como Authenticated Users si la GPO tiene ese alcance tan laxo — figura como miembro de la asignación, y a qué equipos está vinculada la GPO. Una GPO vinculada a la raíz del dominio o a una OU que contenga controladores de dominio convierte esto de "interesante" en "termina con el dominio".

Paso 3 — Explotar el derecho

• Con SeDebugPrivilege: abrir un handle sobre lsass.exe y volcar material de credenciales para crackeo offline o replay.
• Con SeLoadDriverPrivilege: registrar y cargar un controlador firmado vulnerable, y luego explotarlo para obtener una shell SYSTEM.
• Con SeTcbPrivilege: llamar directamente a las API de logon de confianza para suplantar a SYSTEM, sin controlador ni volcado de credenciales.

Cualquiera de los tres convierte "usuario de dominio en esta OU" en "SYSTEM local en cada máquina que toca la GPO" — lo cual, si la OU incluye activos tier-0, equivale funcionalmente a una ruta de ataque directa hacia Domain Admin. Desde SYSTEM local en un controlador de dominio, el atacante está a un solo paso de los derechos DCSync y de todo el conjunto de credenciales del dominio.

Detección

La supervisión de Active Directory cubre el conjunto más amplio de ID de eventos que merece la pena vigilar si quiere ampliar la detección más allá de estos tres privilegios. El repositorio público de reglas de detección de Elastic también incluye una regla "Group Policy Abuse for Privilege Addition" que vigila el evento de cambio del servicio de directorio (Event ID 5136) que se dispara cuando se modifica el GUID de la extensión de cliente de Seguridad de una GPO — la señal de que el contenido de su GptTmpl.inf, incluido [Privilege Rights], ha cambiado — señalando precisamente esta clase de derecho de alto impacto (SeDebugPrivilege, SeTakeOwnershipPrivilege, SeEnableDelegationPrivilege, SeImpersonatePrivilege) — una referencia útil incluso fuera de Elastic Security. Sea cual sea la fuente desde la que alerte, trate cualquier coincidencia como de alta severidad: no existe ninguna razón legítima para que estos tres derechos lleguen a una cuenta no administradora por simple deriva de políticas.

Remediación

1. Inventaríe cada GPO que toque [Privilege Rights]. Exporte todas las GPO con Get-GPOReport -All -ReportType Xml y busque los nodos UserRightsAssignment; no asuma que solo las GPO de "línea base de seguridad" tocan esta sección.
2. Restrinja los tres derechos críticos a los administradores. Los CIS Benchmarks de Windows Server y Windows 11 fijan ambos "Depurar programas" (SeDebugPrivilege) solo para administradores como recomendación de referencia; aplique el mismo estándar a SeLoadDriverPrivilege y SeTcbPrivilege, salvo que exista una excepción específica, documentada y con fecha límite.
3. Rastree el origen de cada excepción. Si un agente de monitorización o una herramienta de backup realmente necesita uno de estos derechos, limite la GPO al grupo de seguridad más pequeño posible en lugar de una OU amplia o Authenticated Users, y documente la excepción con un responsable y una fecha de revisión.
4. Pruebe en una OU aislada antes de desplegar. Despliegue primero una línea base de derechos de usuario endurecida en una OU piloto — algunos agentes heredados fallan de forma ruidosa (y evidente) si se les retira un derecho del que dependen, un hallazgo mucho más barato que descubrirlo en producción.
5. Controle las versiones de los cambios de GPO. Trate los cambios de GptTmpl.inf como cambios de código — un proceso de diff/revisión de GPO convierte una concesión silenciosa de privilegios en un cambio revisable en lugar de una sorpresa.
6. Repita el barrido de forma periódica, no solo una vez. Las GPO se copian, se heredan y se re-vinculan con el tiempo, y una línea base limpia hoy no garantiza una línea base limpia el próximo trimestre. La deriva de accesos privilegiados sigue exactamente este patrón: los derechos vuelven a aparecer después de cerrar la auditoría original.

Cómo detecta esto EtcSec

La auditoría de Active Directory de EtcSec comprueba la sección [Privilege Rights] de cada GPO vinculada frente a las tres asignaciones críticas cubiertas aquí — PRIVILEGE_SEDEBUG_ABUSE, PRIVILEGE_SELOADDRIVER_ABUSE y PRIVILEGE_SETCB_ABUSE — y señala cualquier SID no predeterminado que tenga uno de ellos fuera del grupo integrado de Administradores, con el nombre de la GPO y la OU vinculada, para un hallazgo accionable sin necesidad de un barrido manual con Get-GPOReport.