SeDebugPrivilege
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
Para ejecutar una aplicación o un servicio en particular o ayudar con la resolución de problemas, se le puede asignar a un usuario el privilegio SeDebug en lugar de agregar la cuenta al grupo de administradores. Este privilegio se puede asignar a través de una política de grupo local o de dominio, en Computer Settings > Windows Settings > Security Settings
. De manera predeterminada, solo se les otorga este privilegio a los administradores, ya que se puede utilizar para capturar información confidencial de la memoria del sistema o acceder/modificar estructuras del kernel y de la aplicación. Este derecho se puede asignar a los desarrolladores que necesitan depurar nuevos componentes del sistema como parte de su trabajo diario. Este derecho de usuario se debe otorgar con moderación porque cualquier cuenta a la que se le asigne tendrá acceso a componentes críticos del sistema operativo.
Durante una prueba de penetración interna, suele ser útil utilizar sitios web como LinkedIn para recopilar información sobre los usuarios potenciales a los que dirigirse. Supongamos, por ejemplo, que estamos recuperando muchos hashes de contraseñas NTLMv2 utilizando Responder
o Inveigh
. En ese caso, es posible que queramos centrar nuestros esfuerzos de descifrado de hashes de contraseñas en posibles cuentas de alto valor, como desarrolladores que tienen más probabilidades de tener este tipo de privilegios asignados a sus cuentas. Un usuario puede no ser un administrador local en un host, pero tener derechos que no podemos enumerar de forma remota utilizando una herramienta como BloodHound. Esto valdría la pena comprobarlo en un entorno en el que obtenemos credenciales para varios usuarios y tenemos acceso RDP a uno o más hosts, pero sin privilegios adicionales.
Después de iniciar sesión como usuario asignado al derecho Debug programs
y abrir un shell elevado, vemos que SeDebugPrivilege
aparece en la lista.
Podemos utilizar ProcDump de la suite SysInternals para aprovechar este privilegio y volcar la memoria del proceso. Un buen candidato es el proceso del Servicio de subsistema de autoridad de seguridad local ( LSASS ), que almacena las credenciales del usuario después de que este inicia sesión
Vemos que se ha realizado correctamente y podemos cargarlo en Mimikatz
mediante el comando sekurlsa::minidump
. Después de emitir el comando sekurlsa::logonPasswords
, obtenemos el hash NTLM de la cuenta de administrador local que inició sesión localmente. Podemos utilizar esto para realizar un ataque de paso del hash para movernos lateralmente si se utiliza la misma contraseña de administrador local en uno o varios sistemas adicionales (algo común en organizaciones grandes).
Supongamos que no podemos cargar herramientas en el objetivo por cualquier motivo, pero tenemos acceso RDP. En ese caso, podemos hacer un volcado de memoria manual del proceso LSASS
a través del Administrador de tareas navegando hasta la pestaña Details
, eligiendo el proceso LSASS
y seleccionando Create dump file
. Después de descargar este archivo de vuelta a nuestro sistema de ataque, podemos procesarlo usando Mimikatz de la misma manera que en el ejemplo anterior.
También podemos aprovechar un RCE SeDebugPrivilege
. Con esta técnica, podemos elevar nuestros privilegios a SYSTEM iniciando un proceso secundario y utilizando los derechos elevados otorgados a nuestra cuenta a través de SeDebugPrivilege
para alterar el comportamiento normal del sistema para heredar el token de un proceso primario y suplantarlo. Si apuntamos a un proceso primario que se ejecuta como SYSTEM (especificando el ID de proceso (o PID) del proceso de destino o programa en ejecución), entonces podemos elevar nuestros derechos rápidamente. Veamos esto en acción.
Primero, transfiera este script de PoC al sistema de destino. A continuación, simplemente cargue el script y ejecútelo con la siguiente sintaxis:
Ten en cuenta que debemos agregar un tercer argumento en blanco ""
al final para que el PoC funcione correctamente.
El script PoC ha recibido una actualización. Visite su repositorio de GitHub y revise su uso.
En primer lugar, abra una PowerShell con privilegios elevados (haga clic con el botón derecho, ejecútela como administrador e ingrese las credenciales del usuario jordan
). A continuación, escriba tasklist
para obtener una lista de los procesos en ejecución y los PID correspondientes.
Aquí podemos apuntar a la ejecución de winlogon.exe
bajo el PID 612
, que sabemos que se ejecuta como SYSTEM en Windows.
También podríamos usar el cmdlet Get-Process para obtener el PID de un proceso conocido que se ejecuta como SYSTEM (como LSASS) y pasar el PID directamente al script, reduciendo la cantidad de pasos necesarios.
Existen otras herramientas como esta para abrir un shell SYSTEM cuando tenemos SeDebugPrivilege
. A menudo no tendremos acceso RDP a un host, por lo que tendremos que modificar nuestros PoC para devolver un reverse shell a nuestro host de ataque como SYSTEM u otro comando, como agregar un usuario administrador. Experimente con estos PoC y vea de qué otras formas puede lograr acceso SYSTEM, especialmente si no tiene una sesión completamente interactiva, como cuando logra la inyección de comandos o tiene una conexión web shell o shell inversa como el usuario con SeDebugPrivilege
. Ten estos ejemplos en mente en caso de que alguna vez se encuentre en una situación en la que volcar LSASS no resulte en ninguna credencial útil (aunque podemos obtener acceso SYSTEM con solo el hash NTLM de la máquina, pero eso está fuera del alcance de este módulo) y un shell o RCE como SYSTEM sería beneficioso.
Aproveche los derechos de
SeDebugPrivilege
y obtén el hash de contraseña NTLM para la cuentasccm_svc
.
El usuario Jordan tiene habilitado el privilegio SeDebugPrivilege
.
Vamos a ver los procesos en ejecución:
Identificamos la ejecución de winlogon.exe
bajo el PID 608
, que sabemos que se ejecuta como SYSTEM en Windows.
Vamos a copiar el raw de esta binario y creamos un nuevo archivo.ps1 en la máquina objetivo:
PowerShell no ejecuta scripts automáticamente por razones de seguridad. Debes "dot-source
" el script para importar sus funciones en la sesión:
Vamos a usar Mimikatz desde la CDM de SYSTEM:
Esto nos crea un archivo de log, ya que en la CMD de SYSTEM que nos abre no nos permite hacer scroll y ver todo el contenido.
Obtenemos el hash de la cuenta privilegiada sccm_svc