Escalada de Privilegios Active Directory: Backup Operators, Print Operators, Server Operators, los Grupos que Nadie Audita

Escalada de Privilegios Active Directory Explicada: Backup Operators, Print Operators, Server Operators

La escalada de privilegios Active Directory a través de los grupos integrados Backup Operators, Print Operators, Server Operators es una clase de riesgo que la mayoría de las revisiones centradas en Domain Admins nunca comprueban, porque ninguno de estos cuatro grupos —Backup Operators, Print Operators, Server Operators o Account Operators— está anidado por defecto dentro de Domain Admins o Enterprise Admins. Sin embargo, la propia documentación de Microsoft enumera los cuatro como grupos de seguridad de Active Directory, y Microsoft los clasifica además como cuentas y grupos protegidos — el mismo nivel de protección que Domain Admins y Schema Admins.

Esa clasificación es la señal reveladora. Pertenecer a cualquiera de estos cuatro grupos basta para obtener acceso completo de lectura/escritura a todos los archivos de un controlador de dominio, ejecución de código en modo kernel, ejecución de comandos a nivel de servicio, o manipulación de cuentas en todo el dominio. Ninguno de estos casos es una mala configuración ni un parche ausente: es el comportamiento diseñado de los derechos de usuario de Windows, aplicado por defecto a un grupo al que un atacante solo necesita conseguir que se añada una cuenta.

Cómo Cada Grupo Otorga Derechos Cercanos a Domain Admin

El mecanismo es la Default Domain Controllers Policy (GPO), que asigna derechos de usuario de Windows específicos a estos grupos en cada DC del dominio:

Estos valores por defecto están documentados directamente por Microsoft: la página de política "Realizar copias de seguridad de archivos y directorios" enumera a Administrators, Backup Operators y Server Operators como titulares por defecto en los controladores de dominio, y la página de política "Cargar y descargar controladores de dispositivo" enumera a Administrators y Print Operators. El alcance de Account Operators se describe en la misma referencia de grupos de seguridad: sus miembros pueden crear y modificar la mayoría de los tipos de cuenta, pero el grupo en sí no tiene miembros por defecto, y la recomendación de Microsoft es mantenerlo así.

La Cadena de Ataque: Cuatro Vías de Entrada Distintas

Paso 1 — De Backup Operators a ntds.dit

SeBackupPrivilege omite por completo las ACL de NTFS, lo que permite extraer la base de datos de AD directamente de un DC en producción sin tocar nunca el grupo Domain Admins. El patrón documentado en varias publicaciones públicas —Semperis, Hacking Articles y nhimg.org— usa diskshadow.exe para crear una copia shadow de volumen y así poder copiar el archivo bloqueado ntds.dit, y luego robocopy (que respeta SeBackupPrivilege) para extraer la copia y una exportación de la colmena de registro SYSTEM:

# script diskshadow (ejecutar desde una cuenta con SeBackupPrivilege)
set context persistent nowriters
add volume c: alias cvol
create
expose %cvol% z:
exec "cmd.exe" /c robocopy /b z:\windows\ntds . ntds.dit
exec "cmd.exe" /c reg save hklm\system c:\temp\system.hive

Sin conexión, ntds.dit junto con la colmena SYSTEM entregan todos los hashes de contraseñas del dominio — una vía directa a un inicio de sesión pass-the-hash como Domain Admin, sin exploit ni CVE necesarios. Llega a los mismos secretos que cubre nuestro artículo ACL abuse and DCSync para las vías basadas en ACL — solo que mediante una omisión del sistema de archivos en lugar de un derecho de replicación.

Paso 2 — De Print Operators a SYSTEM mediante un controlador cargado

SeLoadDriverPrivilege permite a un miembro de Print Operators cargar un controlador en modo kernel en un controlador de dominio. Como describen la investigación de Tarlogic sobre este privilegio y varias recopilaciones de notas de seguridad ofensiva (por ejemplo HackTricks), este privilegio se abusa comúnmente cargando un controlador legítimamente firmado pero explotable — la técnica Capcom.sys es el ejemplo público mejor documentado— para ejecutar código arbitrario en espacio de kernel como NT AUTHORITY\SYSTEM. A partir de ahí, añadir la cuenta actual a Domain Admins o extraer ntds.dit directamente es trivial.

Paso 3 — De Server Operators al secuestro de servicios

Server Operators hereda los mismos derechos de copia de seguridad/restauración que Backup Operators, pero además obtiene SERVICE_ALL_ACCESS sobre la mayoría de los servicios de un DC. El artículo de Hacking Articles sobre este grupo explica cómo redirigir la ruta binaria de un servicio legítimo hacia un ejecutable controlado por el atacante y reiniciar ese servicio — este ejecuta entonces la carga útil como SYSTEM. La investigación publicada sobre el abuso de SeRestorePrivilege (alcanzado habitualmente mediante la pertenencia a Server Operators) muestra además que permite sobrescribir binarios de sistema protegidos y secuestrar DLL de servicios, lo que ofrece al menos tres vías independientes desde una sola pertenencia a grupo hasta SYSTEM en un DC.

Paso 4 — De Account Operators a la persistencia silenciosa

Account Operators no tiene ningún privilegio de SO, pero sus derechos nativos de AD son amplios: crear nuevos usuarios, restablecer la mayoría de las contraseñas de usuario, y añadir o eliminar miembros de la mayoría de los grupos, en todo el dominio. El artículo de Cyber Advisors sobre Account Operators lo describe como frecuentemente "a un paso de Domain Administrator" — el grupo no puede tocar directamente Domain Admins, Enterprise Admins ni los demás grupos protegidos (están blindados por la ACL de AdminSDHolder), pero puede crear cuentas libremente, añadirse a cualquier grupo no protegido con derechos delegados, y restablecer la contraseña de cualquier cuenta que no esté en un grupo protegido. Eso basta para lograr persistencia duradera y de bajo perfil sin tocar nunca un grupo Tier 0.

🚨 Peligro: ninguna de estas cuatro técnicas requiere una divulgación de vulnerabilidad, un CVE ni un parche ausente. Son el comportamiento previsto, por diseño, de los derechos de usuario de Windows — el único "bug" es que una cuenta sea miembro del grupo.

Detección

Los cambios de pertenencia a grupos y el uso de privilegios se registran nativamente en ambos casos — la brecha casi siempre es que nadie los está vigilando.

Correlacione todo lo anterior con inicios de sesión interactivos o RDP (Event ID 4624, tipo de inicio de sesión 2 o 10) desde estos cuatro grupos en un DC — bajo cualquier modelo de tiering razonable, ninguno de ellos debería necesitarlo jamás. Nuestra guía de Monitorización de Active Directory sobre los Event ID que importan cubre los requisitos de política de auditoría para todos los eventos anteriores. Herramientas de enumeración continua como etc-collector, PingCastle y Purple Knight también pueden señalar directamente la pertenencia no vacía de estos grupos, sin esperar a que se dispare un evento de registro.

Remediación

1. Mantenga los cuatro grupos vacíos. Este es el estado por defecto documentado; trate cualquier adición como un cambio digno de un incidente, no como una delegación rutinaria.
2. Delegue de forma acotada en lugar de anidar en grupos integrados. Si un equipo realmente necesita crear cuentas de usuario, otorgue ese derecho mediante una delegación ACL a nivel de OU en lugar de la pertenencia a Account Operators, que por diseño abarca todo el dominio.
3. Saque los trabajos de backup del privilegio a nivel de dominio. Cuando el producto de backup lo permita, use una cuenta de servicio dedicada, limitada al objetivo de backup específico, en lugar de una cuenta humana o compartida que posea SeBackupPrivilege/SeRestorePrivilege a nivel de dominio a través de Server/Backup Operators.
4. Aplique un modelo de tiering. Ninguna cuenta de administración, soporte técnico o servicio de Tier 1 o Tier 2 debería estar nunca anidada en un grupo Tier 0 — estos cuatro incluidos. Nuestro artículo Deriva de Acceso Privilegiado explica cómo la pertenencia anidada reaparece incluso después de una auditoría limpia, y nuestra guía Endurecimiento de Active Directory cubre dónde encaja esto en una secuencia de blindaje más amplia.
5. Active la política de auditoría y genere alertas. Habilite "Auditar el uso de privilegios sensibles" y "Auditar la administración de grupos de seguridad", reenvíe los Event ID 4728/4732/4756/4673 a su SIEM, y genere alertas ante cualquier coincidencia que involucre los SID de estos cuatro grupos.
6. Vuelva a revisar con regularidad, no una sola vez. Estos cuatro grupos son exactamente el tipo de hallazgo que una revisión más amplia de las configuraciones incorrectas de seguridad de Active Directory más comunes suele sacar a la luz junto con otros, tal como describe nuestra checklist de auditoría de seguridad de Active Directory — incluya esta comprobación en cada ciclo de auditoría recurrente, no en una limpieza puntual.

Cómo lo Detecta EtcSec

Las comprobaciones ACCOUNT_OPERATORS_MEMBER, BACKUP_OPERATORS_MEMBER, PRINT_OPERATORS_MEMBER y SERVER_OPERATORS_MEMBER de EtcSec señalan cualquier pertenencia no vacía a estos cuatro grupos en cada auditoría de AD — la misma tolerancia casi nula que documenta Microsoft. PRIVILEGE_SEBACKUP_ABUSE y PRIVILEGE_SERESTORE_ABUSE detectan por separado los casos en que SeBackupPrivilege o SeRestorePrivilege se ha asignado más allá de los valores por defecto integrados mediante una GPO, la otra vía por la que estos derechos terminan en las manos equivocadas.