Andrea Pierini Consultor principal de seguridad

He dedicado muchos años a estudiar cómo los ciberdelincuentes abusan de los privilegios de Windows para escalar su acceso desde cuentas con privilegios reducidos hasta llegar a NT AUTHORITY\SYSTEM. Lo que comenzó como una simple curiosidad por unas pocas técnicas básicas de suplantación de identidad se fue convirtiendo poco a poco en un catálogo sistemático de técnicas de ataque centradas en el abuso de privilegios de Windows . Muchas de estas técnicas siguen siendo relevantes incluso en entornos modernos y actualizados.

En esta entrada, te explicaré cuáles son los privilegios de Windows más interesantes desde el punto de vista de un atacante: aquellos que permiten una escalada directa de privilegios. Sigue leyendo para descubrir:

  • ¿Qué privilegios suponen un mayor riesgo para tu entorno?
  • ¿Por qué los atacantes se centran en estos privilegios?
  • Cómo los atacantes pueden aprovecharse de estos privilegios para obtener privilegios locales de SYSTEM, a menudo con un esfuerzo sorprendentemente reducido

Cómo los privilegios de Windows pueden aumentar tu riesgo de ciberseguridad

Llevo desde 2018 hablando con profesionales de las tecnologías de la información y la ciberseguridad sobre los peligros del abuso de privilegios en Windows. Desde la clásica manipulación de tokens hasta la familia de exploits «Potato», este tema ha marcado gran parte de la investigación sobre la escalada de privilegios locales en Windows durante los últimos 10 años.

Sin embargo, el mensaje sigue siendo tan relevante como siempre. Muchos siguen subestimando estos privilegios, cómo funcionan y el nivel de control que pueden proporcionar a los atacantes. Este riesgo persiste por dos razones:

  • Los privilegios no son lo mismo que los permisos. Las organizaciones que auditan minuciosamente sus listas de control de acceso (ACL) y sus delegaciones suelen pasar por alto los privilegios asignados a las cuentas de usuario sin privilegios.
  • Microsoft no corrige el abuso de privilegios. Abusar de un privilegio del que se dispone legítimamente no constituye una violación de los límites de seguridad. Las técnicas que describo en esta entrada, incluidos los exploits «Potato», han perdurado durante muchos años y en innumerables versiones de Windows porque se basan en características del sistema, no en errores. Por lo tanto, las defensas deben ser de carácter arquitectónico.

El abuso de privilegios suele asociarse con la escalada de privilegios locales (LPE). Pero todos sabemos que el compromiso total de un dominio suele comenzar precisamente ahí: una escalada de privilegios locales que permite a un atacante obtener el máximo nivel de acceso en una sola máquina. A partir de ese momento, los atacantes suelen abusar de los derechos elevados, las credenciales, los tokens u otros recursos expuestos para desplazarse lateralmente y continuar su trayectoria de escalada dentro de tu entorno.

El riesgo se vuelve aún más grave en entornos compartidos. Piensa en un servidor RDP, un host de enlace o cualquier sistema en el que interactúen varios usuarios. Obtener control administrativo local en una máquina de este tipo puede tener consecuencias que van mucho más allá del propio host.

Si ejecutas whoami /priv y quieres ver más de unas pocas entradas, este blog es para ti.


¿Qué son los privilegios de Windows?

Microsoft define un privilegio como«el derecho de una cuenta, como la de un usuario o un grupo, a realizar diversas operaciones relacionadas con el sistema en el ordenador local, como apagar el sistema, cargar controladores de dispositivos o modificar la hora del sistema».

En la práctica, los privilegios son un mecanismo que complementa —y, en ocasiones, sustituye— al modelo tradicional de permisos basado en las ACL. Hay algunos aspectos que es fundamental comprender desde el punto de vista de la seguridad:

  • Los privilegios se asignan a través de Asignación de derechos de usuario en el editor de políticas locales o de grupo (Figura 1). Pero también se pueden gestionar mediante programación a través de la API de Windows, utilizando funciones como LsaOpenPolicy() y LsaAddAccountRights().
Asignación de derechos de usuario (privilegios) mediante el editor de GPO
Figura 1. Asignación de derechos de usuario (privilegios) mediante el editor de GPO
  • Los privilegios se pueden activar o desactivar. Un privilegio predeterminado es aquel que se activa automáticamente cada vez que el sistema determina que es necesario.
  • Algunos privilegios anulan explícitamente los permisos de los objetos (ACL). Esta es la causa principal de la mayoría de los abusos que se analizan aquí.
  • La mayoría de los privilegios solo son accesibles desde un proceso con un alto nivel de integridad (IL), lo que significa que para utilizarlos se necesita un shell con privilegios elevados. Sin embargo, una vez que se dispone de ese shell con privilegios elevados, los privilegios están a tu disposición para hacer un uso indebido de ellos.
  • La conclusión más importante de esta investigación es whoami /priv, que muestra todos los privilegios asignados al token actual, junto con su estado (activado o desactivado). Un privilegio activado está listo para su uso. Uno desactivado solo requiere una llamada a la API para AdjustTokenPrivileges() para activarlo, a menos que se considere un privilegio predeterminado.

¿Qué son los tokens de acceso de Windows?

Para comprender el abuso de privilegios, primero hay que entender qué son los tokens de acceso. Se trata de objetos que Windows utiliza para representar el contexto de seguridad de un proceso o un hilo (Figura 2).

Estructura del token de acceso de Windows
Figura 2. Estructura del token de acceso de Windows

Un sistema crea un token durante el proceso de inicio de sesión mediante NtCreateToken(). Este token se utiliza cada vez que un proceso o un hilo intenta interactuar con un objeto protegible. Cuando se crea un nuevo proceso o hilo, se le asigna una copia del token del proceso o hilo padre.

Un token contiene, entre otras cosas:

  • El SID del usuario y del propietario
  • SID de todos los grupos a los que pertenece el usuario
  • El SID de inicio de sesión
  • El DACL que se aplica cuando el usuario crea objetos protegibles sin especificar un descriptor de seguridad
  • El tipo de token (primario o de suplantación)
  • El nivel de suplantación actual: SecurityAnonymous, SecurityIdentification, SecurityImpersonation o SecurityDelegation
  • La lista completa de privilegios de los que dispone el usuario o sus grupos (Figura 3)
Privilegios en la estructura de tokens
Figura 3. Privilegios en la estructura de los tokens

Existe una limitación importante: una vez que el PrimaryTokenFrozen Si se activa un bit en un token, no se le pueden añadir nuevos privilegios. Solo se pueden activar o desactivar los privilegios que ya están presentes, mediante AdjustTokenPrivileges. No obstante, puedes cambiar el tipo de token utilizando DuplicateToken, lo que abre la puerta a posibles casos de suplantación de identidad.
Este diseño implica que los privilegios de los que dispones se determinan en gran medida en el momento del inicio de sesión. La pregunta que surge entonces es: ¿Quién ha iniciado sesión y con qué?


¿A qué cuentas de Windows se dirigen los atacantes?

Antes de entrar en detalle sobre los privilegios específicos, conviene saber qué cuentas cuentan con privilegios peligrosos de forma predeterminada. He aquí una breve lista:

  • Los administradores y el sistema local disponen, en esencia, de todos los privilegios.
  • Los grupos integrados, como «Operadores de copias de seguridad», «Operadores de servidores» y «Operadores de impresión», cuentan con un subconjunto de privilegios muy potentes que a menudo se pasan por alto.
  • Las cuentas de servicio locales y de red suelen disponer de los privilegios «SeImpersonatePrivilege» y «SeAssignPrimaryTokenPrivilege», que son suficientes para alcanzar el nivel SYSTEM.
  • Las cuentas de servicio gestionadas y las cuentas virtuales tienen los mismos privilegios que las cuentas de servicio.
  • Los usuarios de aplicaciones de terceros, como los grupos de aplicaciones de IIS, las cuentas de servicio de SQL Server y los agentes de copia de seguridad, suelen configurarse con más privilegios de los que necesitan.

Una vez más, Microsoft considera que el abuso de privilegios legítimos constituye una violación de los límites de seguridad, no una violación de los límites de protección. Las técnicas de abuso de privilegios no se consideran errores y, por lo tanto, no se corrigen con parches.


Cómo los atacantes descubren y aprovechan los privilegios de Windows

Entonces, ¿cómo consiguen los atacantes acceder a cuentas con privilegios que pueden explotarse? El proceso suele implicar uno o varios de los siguientes métodos:

  • Cuentas de servicio comprometidas, como por ejemplo a través de configuraciones de servicio deficientes, la ejecución remota de código en aplicaciones web o la inyección SQL, lo que da lugar a xp_cmdshell ejecución
  • Interceptar la autenticación NTLM o Kerberos mediante técnicas como la coacción, los ataques de retransmisión o la captura de credenciales
  • Robar credenciales o llevar a cabo «kerberoasting» mediante la obtención de datos de cuentas de servicio y el descifrado de hash sin conexión
  • Manipulación de tokens mediante la suplantación de tokens de procesos con privilegios o su robo directo
  • Escrituras parciales o arbitrarias mediante la manipulación directa de objetos del núcleo (DKOM), que permite a los atacantes disponer de primitivas de escritura a nivel del núcleo —a menudo obtenidas a través de controladores vulnerables— para eludir por completo las API del modo usuario. Al localizar el _TOKEN estructura a través de _EPROCESS y, al modificar los campos de privilegios, los atacantes pueden añadir y activar privilegios adicionales (Figura 4).
Funcionamiento interno del token de acceso de Windows mostrado a través de WinDbg
Figura 4. Detalles internos del token de acceso de Windows mostrados mediante WinDbg

¿A qué privilegios de Windows se dirigen los atacantes?

Ahora que ya conoces el contexto del riesgo que supone el abuso de privilegios en Windows, veamos cuáles son los privilegios que los atacantes suelen tener como objetivo, por qué resultan atractivos para los actores maliciosos y cómo se explotan.


SeCreateTokenPrivilege: ¿Alguien quiere tokens de acceso?

SeCreateTokenPrivilege es un potente privilegio relacionado con los tokens que permite a un proceso llamar a las API de creación de tokens, concretamente ZwCreateToken, para crear un token de acceso totalmente personalizado con los privilegios y las pertenencias a grupos que se deseen:

      NTSTATUS ZwCreateToken(
PHANDLE                            TokenHandle,
ACCESS_MASK                     DesiredAccess,
POBJECT_ATTRIBUTES         ObjectAttributes,
TOKEN_TYPE                        Type,
PLUID                                   AuthenticationId,
PLARGE_INTEGER                 ExpirationTime,
PTOKEN_USER                      User,
PTOKEN_GROUPS                Grupos,
PTOKEN_PRIVILEGES            Privilegios,
PTOKEN_OWNER                 Propietario,
PTOKEN_PRIMARY_GROUP GrupoPrincipal,
PTOKEN_DEFAULT_DACL     DACL predeterminada,
PTOKEN_SOURCE                Origen
);

En Windows Server 2016 / Windows 10 versión 1809 y anteriores, el token resultante puede utilizarse para suplantar hilos sin necesidad de privilegios de suplantación adicionales. Microsoft solucionó ese vector específico en versiones posteriores de Windows, pero el token resultante sigue pudiendo utilizarse para escribir y sobrescribir archivos protegidos, lo que constituye una herramienta útil para los atacantes, incluso en escenarios con restricciones.


SeDebugPrivilege: el acceso SYSTEM en pocas palabras

SeDebugPrivilege es uno de los privilegios más potentes del modelo de privilegios de Windows. Permite a quien lo posee conectar un depurador a cualquier proceso, independientemente de quién sea el propietario de dicho proceso o de qué listas de control de acceso (ACL) lo protejan, así como leer o modificar la memoria del proceso.

Es importante destacar que SeDebugPrivilege elude los controles normales de DACL. No elude los mecanismos de procesos protegidos (por ejemplo, PPL o procesos firmados con ELAM), pero estos representan solo una pequeña parte de los procesos que se ejecutan en un sistema típico.

Entre los casos de abuso se incluyen:

  • Inyección de código. Los atacantes pueden inyectar código malicioso en procesos con privilegios utilizando la secuencia clásica VirtualAlloc() → WriteProcessMemory() → CreateRemoteThread(). Objetivo lsass.exe, winlogon.exe, o cualquier proceso de NT AUTHORITY\SYSTEM, y se produce la ejecución de código arbitrario con el nivel más alto de privilegios.
  • Suplantación del proceso padre. Los atacantes pueden crear un nuevo proceso y designar a un proceso con privilegios como su proceso padre, de modo que el proceso hijo herede el token de privilegios (Figura 5).
Suplantación del proceso padre con SeDebugPrivilege
Figura 5. Suplantación del proceso padre con SeDebugPrivilege

En la práctica, cualquier servicio o aplicación que conceda a una cuenta el privilegio SeDebugPrivilege le otorga, en la práctica, acceso de tipo SYSTEM. Existen pocas razones legítimas para que este privilegio se conceda de forma generalizada.


SeBackupPrivilege y SeRestorePrivilege: de la escalada de privilegios locales a la extracción de NTDS.DIT

Los atacantes pueden aprovechar los privilegios «SeBackupPrivilege» y «SeRestorePrivilege» para acceder a archivos confidenciales y, en algunos casos, extraer la base de datos NTDS.DIT de los controladores de dominio (DC), lo que podría dar lugar a un compromiso total de Active Directory… un escenario preocupante.


SeBackupPrivilege: Vía rápida para la extracción de credenciales

En la documentación de Microsoft se indica que SeBackupPrivilege «permite al usuario eludir los permisos de archivos y directorios para realizar una copia de seguridad del sistema.» En otras palabras, este privilegio otorga acceso de lectura a cualquier archivo del sistema, independientemente de las listas de control de acceso (ACL), siempre y cuando se abra el archivo con FILE_FLAG_BACKUP_SEMANTICS.

El abuso más inmediato consiste en volcar los «hives» del Registro de Windows necesarios para la extracción de credenciales sin conexión:

reg save HKLM\SYSTEM c:\temp\system.hive
reg save HKLM\SAM c:\temp\sam.hive

Una vez que un atacante dispone de estos dos archivos, puede utilizar cualquier herramienta sin conexión para extraer los hash NTLM locales. En un servidor, donde la reutilización de contraseñas de administrador local sigue siendo una práctica demasiado frecuente, esta capacidad puede proporcionar a los actores maliciosos un punto de apoyo para desplazarse lateralmente por todo un segmento (Figura 6).

Recuperación de hash de NT a partir de una copia de seguridad del archivo SAM mediante SeBackupPrivilege
Figura 6. Recuperación de hash de NT a partir de una copia de seguridad de la base de datos SAM mediante SeBackupPrivilege

Además del registro, SeBackupPrivilege puede utilizarse para leer cualquier archivo al que el sistema de archivos normalmente denegaría el acceso:

      source = CreateFile(
L"c:\users\administrator\supersecretfile4admins.doc",
GENERIC_READ,
0,
NULL,
OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS,
NULL
);

La clave es el FILE_FLAG_BACKUP_SEMANTICS indicador, que hace que Windows reconozca una operación de copia de seguridad y omita la evaluación habitual de la DACL.


SeRestorePrivilege: Acceso de escritura sin restricciones

Mientras que SeBackupPrivilege proporciona acceso de lectura a cualquier elemento, SeRestorePrivilege proporciona acceso de escritura a cualquier elemento, incluidos los archivos protegidos por TrustedInstaller y claves del registro del sistema. Dos llamadas a la API activan este comportamiento:

  • CreateFile() con FILE_FLAG_BACKUP_SEMANTICS
  • RegCreateKeyEx() con REG_OPTION_BACKUP_RESTORE

Con acceso de escritura sin restricciones, la superficie de ataque se vuelve enorme. Una técnica sencilla y de la que se abusa con frecuencia consiste en modificar un servicio de Windows para ejecutar una carga útil controlada por el atacante. Los atacantes simplemente:

  1. Crea un archivo DLL o un ejecutable de servicio malicioso.
  2. Uso RegCreateKeyEx() con REG_OPTION_BACKUP_RESTORE para sobrescribir el ServiceDLL valor del Registro:
    std::string buffer = "c:\windows\system32\hackerservice.dll";
    LSTATUS stat = RegCreateKeyExA(
    HKEY_LOCAL_MACHINE,
    "SYSTEM\CurrentControlSet\Services\dmwappushservice\Parameters",
    0, NULL, REG_OPTION_BACKUP_RESTORE, KEY_SET_VALUE, NULL, &hk, NULL
    );
    stat = RegSetValueExA(
    hk, "ServiceDLL", 0, REG_EXPAND_SZ,
    (const BYTE*)buffer.c_str(), buffer.length() + 1
    );
  3. Uso CreateFile() con FILE_FLAG_BACKUP_SEMANTICS para copiar el archivo DLL en C:\Windows\System32. (La ubicación puede ser cualquiera; este ejemplo solo sirve para demostrar que el privilegio permite escribir, o incluso sobrescribir, archivos del sistema protegidos.)
  4. Reinicia el servicio de destino. El servicio, que se ejecuta como SYSTEM, ahora carga la DLL del atacante.

Gráfico 7 muestra un ejemplo de esta técnica utilizando dmwappushservice, que está presente de forma predeterminada, se ejecuta como SYSTEM y puede iniciarse desde cualquier usuario. Sin embargo, esta misma técnica puede utilizarse para explotar cualquier servicio.

Manipulación de la ruta de una imagen de servicio mediante SeRestorePrivilege
Figura 7. Manipulación de la ruta de una imagen de servicio mediante SeRestorePrivilege

Operadores de copias de seguridad: el doble de privilegios, el doble de riesgo

Los miembros del grupo integrado «Backup Operators» disponen tanto del privilegio «SeBackupPrivilege» como del «SeRestorePrivilege». Y lo que es más importante, tienen permiso para iniciar sesión de forma local en los servidores de dominio (DC), una capacidad que conlleva un riesgo muy subestimado en la mayoría de los entornos de Active Directory.

Esta combinación implica que cualquier atacante que consiga acceder al grupo «Backup Operators» puede realizar una copia de seguridad del archivo NTDS.DIT directamente desde un servidor de dominio (DC) utilizando herramientas como wbadmin.exe:

      wbadmin start backup -backuptarget:e: -include:c:\windows\ntds
wbadmin get versions
wbadmin start recovery -version:07/12/2025-11:09 -itemtype:file
-items:c:\windows\ntds\ntds.dit -recoverytarget:c:\temp\srvdc1 -notrestoreacl
reg save HKLM\SYSTEM c:\temp\system

El método integrado de «diskshadow.exe» funciona igual de bien y, a menudo, los defensores lo pasan por alto:

      set metadata C:\temp\metadata.cab
set context clientaccessible
set context persistent
begin backup
add volume c: alias mydrive
create
expose %mydrive% z:

Ten en cuenta que esta técnica no funciona con ntdsutil.exe, ya que este programa requiere privilegios de administrador.

Una vez que un atacante tiene NTDS.DIT y el hive SYSTEM, puede utilizar herramientas como DSInternals o impacket-secretsdump para extraer todas las credenciales del dominio sin conexión, incluido el hash de krbtgt necesario para lanzar un ataque de «Golden Ticket».

Además, con ambos privilegios, un atacante que se infiltre en el grupo «Backup Operators» puede establecer la propiedad y los permisos de cualquier archivo o carpeta del sistema, lo que le permite obtener acceso a SYSTEM únicamente mediante la manipulación del sistema de archivos.


SeImpersonatePrivilege y SeAssignPrimaryTokenPrivilege: ¿Por qué los exploits de Potato no desaparecen?

Estos dos privilegios son los que más se utilizan indebidamente en situaciones reales, y son la razón por la que existe la familia de exploits «Potato».

  • SeImpersonatePrivilege («Suplantar la identidad de un cliente tras la autenticación») permite que un hilo se haga pasar por cualquier token de acceso a través de SetThreadToken(), ImpersonateLoggedOnUser()o CreateProcessWithToken().
  • SeAssignPrimaryTokenPrivilege («Asignar el token principal de un proceso») permite que un proceso genere un proceso hijo con un token primario diferente mediante CreateProcessAsUser(). Este privilegio también está disponible en un shell IL estándar de tamaño medio.

Ambos privilegios suelen asignarse a cuentas de servicio, identidades de grupos de aplicaciones de IIS, cuentas de servicio de SQL Server y entidades similares. En resumen: si dispones de RCE como cuenta de servicio, es casi seguro que tienes al menos uno de estos privilegios.

Pero, ¿cómo consiguen los atacantes los tokens privilegiados para suplantar la identidad? Existen varias técnicas, por ejemplo:

  • Creación de una tubería con nombre, obligando a un proceso con privilegios a conectarse a él y, a continuación, llamando a ImpersonateNamedPipeClient() para obtener el token de la persona que llama
  • Uso de las llamadas de retorno de DCOM/RPC vía CoImpersonateClient(), RpcImpersonateClient()
  • Utilizando los exploits «Potato», una familia de técnicas muy conocidas para la escalada de privilegios locales (por ejemplo, RottenPotato, JuicyPotato, SweetPotato, GodPotato) que abusan de dichos privilegios al forzar que la autenticación COM/RPC de nivel SYSTEM se redirija a un listener controlado por el atacante

Esta técnica se remonta a una observación realizada por James Forshaw en 2016:

«Las conexiones DCOM DCE/RPC locales pueden reflejarse en un socket TCP a la escucha, lo que permite acceder al desafío de autenticación NTLM del usuario LocalSystem, que puede reproducirse en el servicio de activación DCOM local para elevar los privilegios».

A lo largo de los últimos 10 años, este exploit básico se ha reimplementado, adaptado y vuelto a utilizar como arma en una notable variedad de técnicas que, en conjunto, conforman la familia Potato. El mecanismo general, común a todas las variantes, sigue esta estructura:

  1. Inicia un listener local en un puerto TCP para que actúe como un punto final COM o RPC falso.
  2. Activa un CLSID creando una instancia de una clase COM que se ejecute con los privilegios de NT AUTHORITY\SYSTEM.
  3. Desmarcado forzado vía CoGetInstanceFromIStorage, pasando un IStorage OBJREF señalando hacia 127.0.0.1: <listener>. El servidor SYSTEM COM intenta conectarse al listener y autentica el tráfico saliente mediante NTLM.
  4. Interceptar el protocolo de intercambio de datos NTLM a nivel local a través de SSPI (AcceptSecurityContext → QuerySecurityContextToken) para obtener un token de suplantación de identidad de SYSTEM.
  5. Suplantar el token y escalar privilegios vía CreateProcessWithTokenW o CreateProcessAsUser para iniciar un shell como SYSTEM.

La idea clave es ingeniosa: el CLSID hace que SYSTEM inicie la autenticación de salida, CoGetInstanceFromIStorage dirige esa autenticación hacia el listener del atacante, y el relé NTLM local captura el token. No se trata de una vulnerabilidad en el sentido tradicional… simplemente son privilegios que hacen exactamente lo que se diseñaron para hacer.

La figura 8 muestra cómo se puede utilizar la herramienta JuicyPotatoNG para crear un shell de SYSTEM aprovechando el fallo de seguridad de SeAssignPrimaryTokenPrivilege desde un shell que se ejecuta en un IL de nivel medio.

Escalada de privilegios mediante técnicas «Potato» que aprovechan las vulnerabilidades de «SeImpersonatePrivilege» y «SeAssignPrimaryTokenPrivilege»
Figura 8. Escalada de privilegios mediante técnicas de Potato que hacen uso indebido de SeImpersonatePrivilege y SeAssignPrimaryTokenPrivilege

SeLoadDriverPrivilege: Del controlador de dispositivo al control total del sistema

SeLoadDriverPrivilege determina qué usuarios pueden cargar y descargar dinámicamente controladores de dispositivos u otro código en modo kernel. Este privilegio es especialmente relevante porque los miembros del grupo de dominio «Operadores de impresoras» lo tienen de forma predeterminada en los servidores de dominio (DC).

El patrón de ataque está bien definido: se carga un controlador del núcleo firmado pero vulnerable y, a continuación, se aprovecha desde el espacio de usuario para leer o escribir en la memoria del núcleo, lo que permite el robo de tokens, la activación de privilegios, la elusión de PPL, la interrupción de programas antivirus y EDR, o la ejecución arbitraria en modo núcleo.

La técnica canónica se basa en el hecho de que los usuarios pueden crear entradas de registro en su colmena actual (HKCU), y NtLoadDriver() admite rutas de registro creadas a partir del SID del usuario, lo que permite a un usuario sin privilegios registrar un servicio de controlador del núcleo sin modificar HKLM:

      std::string data = "\??\C:\TEMP\evildriver.sys";
RegCreateKeyExA(HKEY_CURRENT_USER,
"SYSTEM\CurrentControlSet\Services\Evil",
0, NULL, NULL, KEY_SET_VALUE, NULL, &hk, NULL);
RegSetValueExA(hk, "ImagePath", 0, REG_EXPAND_SZ,
(const BYTE)data.c_str(), data.length() + 1); RegSetValueExA(hk, "Type", 0, REG_DWORD, (const BYTE)&val, sizeof(val));

WCHAR winregPath[256];
wcscpy(winregPath, L"\Registry\User\");
wcscat(winregPath, sidstring);
wcscat(winregPath, L"\System\CurrentControlSet\Services\Evil");
RtlInitUnicodeString(&DriverServiceName, winregPath);
status = NtLoadDriver(&DriverServiceName);

Microsoft ha bloqueado ahora las ubicaciones alternativas del Registro, pero siguen existiendo rutas en las que se puede escribir bajo HKLM\System.

No es raro que los GPO concedan el privilegio «SeLoadDriverPrivilege» a grupos amplios, lo que probablemente se deba a la idea errónea de que dicho privilegio es necesario para que los usuarios puedan instalar impresoras. El resultado es un privilegio expuesto innecesariamente que ofrece a los atacantes una vía directa para ejecutar código a nivel del núcleo.


SeManageVolumePrivilege: Acceso a la modificación de las ACL

SeManageVolumePrivilege permite a un usuario realizar operaciones relacionadas con los volúmenes, como desfragmentarlos, montarlos o desmontarlos. Este privilegio está disponible en un shell de nivel medio de IL. Desde el punto de vista de un atacante, aprovechar este privilegio abre la puerta a varias posibilidades útiles:

  • Montar volúmenes que contengan datos sensibles, lo que podría eludir los mecanismos de control de acceso que regulan cómo se exponen los datos a través del sistema de archivos
  • Manipular sistemas de archivos a nivel de volumen, incluido el cambio de permisos en volúmenes completos (Figura 9); un privilegio que puede permitir a un atacante, por ejemplo, modificar la lista de control de acceso (ACL) de toda la unidad C:\ y, a continuación, utilizar otras técnicas para crear rutas de escritura en áreas del sistema que, de otro modo, estarían protegidas
Modificación de los permisos de volumen mediante SeManageVolumePrivilege
Figura 9. Modificación de los permisos de volumen mediante SeManageVolumePrivilege

Aunque este privilegio se da con menos frecuencia en la práctica que el SeImpersonatePrivilege o el SeBackupPrivilege, su presencia en una cuenta que no sea de administrador debe considerarse un riesgo grave.


SeRelabelPrivilege: menor integridad, mayor riesgo

SeRelabelPrivilege es un privilegio poco conocido, pero interesante. Según la documentación de Microsoft, este privilegio«determina qué cuentas de usuario pueden modificar la etiqueta de integridad de objetos, como archivos, claves del Registro o procesos que pertenecen a otros usuarios».

Sin este privilegio, un proceso solo puede reducir la etiqueta de integridad de los objetos de los que es propietario. Con el privilegio SeRelabelPrivilege, un proceso puede modificar las etiquetas de integridad de los objetos que pertenecen a otros usuarios, lo que incluye elevar las etiquetas por encima del propio nivel de integridad del proceso actual. En otras palabras:

  • SeRelabelPrivilege te permite asumir la propiedad de un recurso aunque su nivel de integridad (IL) sea superior al tuyo.
  • Una vez que te hayas hecho cargo, podrás concederte acceso completo al proceso y a los tokens.
  • El resultado, desde el punto de vista de un posible abuso, es similar al de SeDebugPrivilege.
  • La manipulación de la etiqueta obligatoria no es más que una consecuencia.

La razón original que motivó este privilegio sigue sin estar clara, pero su impacto sí lo está. Te permite tomar la propiedad de objetos que se encuentran por encima de tu nivel de integridad (Figura 10), lo que lo convierte en uno de los privilegios más peligrosos y subestimados del modelo de seguridad de Windows.

Aprovechar SeRelabelPrivilege para obtener la propiedad de un proceso con privilegios
Figura 10. Aprovechamiento de SeRelabelPrivilege para hacerse con el control de un proceso con privilegios

Cualquier asignación que no se realice a través de cuentas administrativas sometidas a un estricto control debe revisarse minuciosamente y considerarse una señal de alerta.


SeTakeOwnershipPrivilege: Ahora somos tus dueños

Este privilegio hace exactamente lo que su nombre indica: permite a quien lo posee hacerse con la propiedad de cualquier objeto protegible del sistema. Las dos llamadas a la API pertinentes utilizan la OWNER_SECURITY_INFORMATION bandera:

  • SetSecurityInfo()
  • SetNamedSecurityInfo()

Los tipos de objetos que pueden ser objeto de estos ataques son muy variados: archivos, impresoras, recursos compartidos, servicios, claves del Registro y objetos del núcleo.

Una vez establecida la propiedad, se aplican las mismas técnicas de manipulación de archivos y del registro que se utilizan en la explotación de SeRestorePrivilege. Un ejemplo práctico es centrarse en el msiserver Servicio (Windows Installer):

Paso 1. Asumir la propiedad de la clave del registro del servicio:

      wchar_t infile[] = L"SYSTEM\CurrentControlSet\Services\msiserver";
PSID UserSid = GetCurrentUserSID();
dwRes = SetNamedSecurityInfoW(
infile,
SE_REGISTRY_KEY,
OWNER_SECURITY_INFORMATION,
UserSid, NULL, NULL, NULL
);

Paso 2. Modifica los permisos de la clave del Registro para conceder acceso total:

      ea[0].grfAccessPermissions = KEY_ALL_ACCESS;
ea[0].grfAccessMode = SET_ACCESS;
ea[0].grfInheritance = NO_INHERITANCE;
ea[0].Trustee.TrusteeForm = TRUSTEE_IS_SID;
ea[0].Trustee.TrusteeType = TRUSTEE_IS_WELL_KNOWN_GROUP;
ea[0].Trustee.ptstrName = (LPTSTR)pSIDEveryone;
SetEntriesInAcl(NUM_ACES, ea, NULL, &pACL);

Paso 3. Modificar el servicio ImagePath para ejecutar un comando arbitrario:

      std::string buffer = "cmd.exe /c net localgroup administrators hacker /add";
stat = RegSetValueExA(
hk, "ImagePath", 0, REG_EXPAND_SZ,
(const BYTE*)buffer.c_str(), buffer.length() + 1
);

Cuando el usuario inicia el servicio, este ejecuta el comando controlado por el atacante bajo la cuenta SYSTEM.


SeTCBPrivilege: Suplantación de identidad

SeTCBPrivilege es uno de los privilegios más peculiares de esta lista. La documentación lo describe como «funcionar como parte del sistema operativo,», pero la consecuencia práctica es la posibilidad de utilizar LsaLogonUser() asumir la identidad de cualquier usuario, sin necesidad de disponer de las credenciales de dicho usuario.

El mecanismo es «Service For User Logon» (S4ULogon), una función que permite a un proceso con el privilegio SeTCBPrivilege obtener un token de seguridad para un usuario cualquiera. Es importante destacar que el proceso que realiza la llamada puede solicitar que se añadan al token resultante pertenencias a grupos o privilegios adicionales, incluidos grupos a los que el usuario no pertenece realmente:

      pS4uLogon->MessageType = MsV1_0S4ULogon;
// SzUsername = USUARIO DE DESTINO DEL QUE SE VA A ASUMIR LA IDENTIDAD
InitUnicodeString(&pS4uLogon->UserPrincipalName, szusername, pbPosition);
InitUnicodeString(&pS4uLogon->DomainName, szDomain, pbPosition);

// Añadir S-1-5-32-544 (Administradores locales) al token
ConvertStringSidToSid("S-1-5-32-544", &pExtraSid);
pGroups->Groups[pGroups->GroupCount].Attributes =
SE_GROUP_ENABLED | SE_GROUP_ENABLED_BY_DEFAULT | SE_GROUP_MANDATORY;
pGroups->Groups[pGroups->GroupCount].Sid = pExtraSid;
Status = LsaLogonUser(…)

El token de suplantación resultante, válido en el contexto de la máquina local, puede utilizarse para suplantar hilos sin necesidad de privilegios adicionales, como SeImpersonatePrivilege. Esto convierte a SeTcbPrivilege en una primitiva autónoma de escalada de privilegios.

Desde PowerShell, la ruta de Kerberos S4ULogon tiene el siguiente aspecto:

      $ident = [System.Security.Principal.WindowsIdentity]::new("administrator@domain.local")
$ctx = $ident.Impersonate()
try {
[System.IO.File]::WriteAllText("C:\Windows\System32\text.txt", "hello from Domain Admin")
}
finally {
$ctx.Undo()
}

Por defecto, este privilegio solo lo tiene la cuenta SYSTEM. No hay ninguna razón legítima para concederlo a otras cuentas. Cualquier asignación a una cuenta que no sea SYSTEM debe considerarse una configuración incorrecta o un indicio de compromiso de seguridad.


Reducción del riesgo de abuso de privilegios en Windows: medidas prácticas para entornos de Active Directory

Esto es lo que puedes hacer hoy mismo para reducir los riesgos de abuso de privilegios:

  • La orden whoami /priv Es una de las primeras cosas que hace un atacante tras conseguir acceso inicial. Por lo tanto, también debería ser una de las primeras cosas que compruebes al analizar el estado de seguridad de una cuenta sensible.
  • Revisa todos los objetos de política de grupo (GPO) que asignan privilegios a través de «Configuración del equipo» → «Configuración de Windows» → «Configuración de seguridad» → «Políticas locales» → «Asignación de derechos de usuario» en todo el dominio. Audita las asignaciones vigentes en todos los sistemas, prestando especial atención a los activos de nivel 0. Este es el principal vector de distribución involuntaria de privilegios. Audita no solo lo que está configurado explícitamente, sino también la política resultante, ya que la herencia y la precedencia de los GPO suelen generar asignaciones que ningún administrador pretendía. Elimina todo aquello que no esté justificado desde el punto de vista operativo.
  • Revisa la pertenencia a los grupos integrados con potentes conjuntos de privilegios: Operadores de copias de seguridad, Operadores de impresión, Operadores de servidor y Operadores de cuentas.
  • Las cuentas de servicio deben ejecutarse con los privilegios mínimos necesarios. De forma predeterminada, las cuentas de servicio cuentan con el privilegio SeImpersonatePrivilege. Es posible restringir los privilegios asignados a través de la Required Privileges clave de registro en la configuración del servicio; se trata de una buena práctica de refuerzo de la seguridad. Sin embargo, hay que tener en cuenta que un atacante puede recuperar estos privilegios en determinadas condiciones, por lo que este paso debe considerarse una capa más dentro de una estrategia más amplia de defensa en profundidad, y no una medida de mitigación completa.
  • Supervisar whoami /priv ejecución y para las llamadas a la API relacionadas con la gestión de tokens (DuplicateToken, ImpersonateLoggedOnUser, CreateProcessWithToken, LsaLogonUser) en la telemetría del EDR.
  • Considera como activo de nivel 0 cualquier cuenta que pueda iniciar sesión localmente en un servidor de dominio (DC), independientemente de si figura o no en el grupo «Administradores del dominio».

No permitas que el uso indebido de privilegios en Windows ponga en riesgo a tu organización

Vale la pena repetirlo: dado que los privilegios que se analizan en esta entrada funcionan tal y como están diseñados, la posibilidad de que se produzca un abuso de privilegios en Windows —y las técnicas de ataque que dicho abuso permite— existe incluso en entornos con todas las actualizaciones instaladas. Los actores maliciosos pueden utilizar estas técnicas para comprometer Active Directory y escalar sus privilegios en toda tu organización. No subestimes el riesgo; toma medidas hoy mismo para proteger tu resiliencia cibernética.


Más investigaciones especializadas


Fuentes