Enumeración en Windows para Post-Explotación – Parte 3.

Continuando con los detalles básicos de enumeración que se han visto en las partes 1 y 2, se listan a continuación más elementos del "checklist" para enumerar sistemas Windows.

Usuarios y grupos.

Posiblemente es una de las primeras cosas que se intenta enumerar en cualquier sistema durante la post-explotación. Consiste en encontrar detalles básicos sobre las cuentas de usuario que se encuentran registradas en el sistema. En el caso de Windows esto se puede conseguir de una forma muy simple utilizando el comando "net users" o instrucciones en Powershell.

El comando " whoami /all" también es muy útil para enumerar información relevante sobre el usuario que se encuentra autenticado actualmente.
En este punto es especialmente interesante verificar el token de acceso que tiene el usuario que se está utilizando para enumerar el sistema, el cual se encarga de definir los grupos y privilegios del usuario, así como su identificación. Resulta conveniente ver el listado de privilegios que enseña el comando whoami y ver cuáles de ellos se pueden utilizar para post-explotación, especialmente si es posible la impersonalización de los mismos. Una guía concreta e interesante sobre el significado de los privilegios se encuentra en https://github.com/gtworek/Priv2Admin
Por otro lado, también es importante detectar los usuarios que son administradores locales en el sistema, ya que cuando se autentican, normalmente se crean dos tokens, uno de ellos con privilegios regulares y el otro con permisos de administrador. El que se utiliza por defecto para la ejecución de programas es el primero, pero cuando se intenta ejecutar alguna operación que requiere permisos de administrador se ejecuta el segundo y en este caso entra el juego el nivel de integridad y el UAC para "pedir confirmación" sobre la acción que se va a ejecutar.

Aplicaciones instaladas

En las aplicaciones instaladas en el sistema se puede encontrar una forma de elevar privilegios, especialmente en aquellos programas que se utilizan localmente por parte de los usuarios de forma regular y que incluyen vulnerabilidades conocidas o cuentan con configuraciones inseguras. Listar los directorios C:\\Program Files y C:\\Program Files (x86) es una buena forma de hacerse una idea de lo que se encuentra instalado en el sistema, también resulta conveniente consultar la clave del registro HKLM\SOFTWARE por si acaso hay algún otro programa instalado en un directorio distinto a los anteriores. Además de esto, resulta conveniente utilizar una herramienta como AccessChk de Sysinternals para comprobar permisos débiles en esos directorios. Por supuesto, Powershell también puede utilizarse para obtener esta información

Contraseñas e información sensible.

Dependiendo del mecanismo de autenticación empleado y de la versión de Windows, es posible que las credenciales utilizadas por los usuarios se puedan recuperar directamente de la memoria de procesos como el LSASS o en otras ubicaciones. De hecho, los ataques clásicos de pass the hash se basan en obtener los hashes de las contraseñas utilizadas para iniciar sesión en el sistema local y en el caso de que la autenticación se lleve a cabo contra un AD, dichos hashes estarán guardados en los controladores de dominio. Los ataques de pass the hash continúan siendo una amenaza real y representan una técnica perfectamente valida para intentar elevar privilegios o realizar movimientos laterales. Aunque cuando se habla de PtH comúnmente se refiere a hashes NT, la misma dinámica aplica a Kerberos solo que en este caso se puede intentar obtener el TGT (Ticket-Granted Ticket).
Por otro lado, algunas ubicaciones que son de "obligada" verificación en un proceso de pentesting o incluso de Hardening en un sistema Windows se listan a continuación:

Security Accounts Manager (SAM):

Aquí se almacenan las credenciales hasheadas de los usuarios locales (NTLM). Dependiendo de la versión del sistema operativo se puede obtener de múltiples formas, entre las que se incluyen:

• Extracción desde el registro del sistema operativo:
  En algunas versiones de Windows se puede obtener los hashes NTLM locales desde el registro y almacenarlos en un fichero, por ejemplo.
  reg save HKLM\sam C:\sam
  reg save HKLM\system C:\system
  Posteriormente se puede utilizar una herramienta comoJTR (John The Ripper) o samdump2 para volcar dichos hashes.
• Herramientas especificas:
  Es común utilizar herramientas como Mimikatz o el comando hashdump de meterpreter que se encuentra ubicado en la extensión priv pero además de esto, también se puede utilizar el script secretsdump.py de Impacket, el proyecto Lazagne o FGDump
• Copia de la SAM :
  Las versiones más recientes de Windows conservan un bloqueo exclusivo del fichero SAM utilizado actualmente. Una alternativa valida podría ser obtener el backup de dicho fichero que el propio sistema operativo almacena. Las ubicaciones típicas suelen ser C:\Windows\Repair\ y C:\Windows\System32\config\RegBack. Nuevamente dependerá de la versión de Windows.
• Volume Shadow Copy:
  Como se ha mencionado anteriormente, las versiones recientes de Windows no permiten el acceso directo al fichero SAM para lectura o escritura, pero en versiones recientes de dicho sistema operativo también se ha implementado una característica llamada VSC (Volume Shadow Copy) la cual se encarga de la creación de snapshots del volumen completo con el objetivo de realizar labores de recuperación del sistema y backup. Por lo tanto, es posible crear un snapshot del volumen principal (C: por ejemplo), montarlo y a partir de este punto copiar los ficheros SAM y SYSTEM para poder utilizar las herramientas que se han explicado previamente. Para ello se puede utilizar una herramienta como vssadmin o diskshadow, nuevamente dependiendo de la versión de Windows las herramientas disponibles son distintas.

LSA Secrets:

Ya se ha mencionado anteriormente que el proceso LSASS almacena en memoria información sensible como las credenciales de los usuarios, sin embargo existen otros elementos que también son interesantes y relevantes para un proceso de post-explotación, por ejemplo:

• Contraseñas almacenadas en el ordenador localmente.
• Contraseñas de cuentas destinadas a servicios que se ejecutan en el sistema.
• Contraseñas de aplicaciones especificas, como por ejemplo aplicaciones web desplegadas en un IIS.
• Contraseñas utilizadas en las tareas programadas creadas en el sistema operativo.

Gestores de contraseñas:

Los navegadores web que utilizan los usuarios de un sistema son una valiosa fuente de información y no solamente por el contenido correspondiente al historial de navegación o cookies, sino también las credenciales que se almacenan en los gestores de contraseñas. Además de esto, también es una práctica muy extendida utilizar programas de gestión de contraseñas en la nube o localmente, como es el caso de programas como LastPass, Bitwarden, PasswordSafe, KeePass2, KeePassX, etc. que también merece la pena investigar en el caso de el sistema comprometido tenga alguno de estos programas instalado.

Crear Named Pipes para saltar de "High Integrity" a "System".

Es una técnica muy extendida y de hecho, es una de las que se implementa en el comando "getsystem" de meterpreter. En primer lugar es necesario comprender que las pipes son un elemento habitual en sistemas operativos para ejecutar operaciones IPC (Inter Process Communication) y se trata simplemente de bloques de memoria cuyo único próposito es el de almacenar información que será compartida entre múltiples procesos. Las Named Pipes son un concepto introducido en sistemas Windows y que tienen una arquitectura cliente/servidor, en donde un servidor crear la Named Pipe y un cliente se puede conectar para leer/escribir datos en ella. En IPC evidentemente tanto cliente como servidor se encuentran ejecutandose en la máquina local, pero las Named Pipes pueden compartir recursos en máquinas remotas y en todo caso, se utiliza el protocolo SMB para la conexión e intercambio de información. El procedimiento para llevar a cabo esta técnica es simple y se resume en los siguientes pasos:

1. Crea servicio el cual creará y se conectará a una Named Pipe.
2. Desde el servicio, escribir cualquier cosa en la pipe. Es importante que la cuenta de usuario con la que se ha creado dicho servicio tenga el privilegio SeImpersonate.
3. A continuación, un proceso cliente se debe conectar a la Named Pipe y leer el contenido que se ha puesto en dicho buffer
4. En este punto el servicio puede invocar la función ImpersonateNamedPipeClient disponible en la API. Esta función, como su nombre indica, permite impersonalizar el contexto de seguridad del cliente y "establecerlo" en el hilo de ejecución principal del servidor, lo que se traducirá en una elevación de privilegios si el cliente que se conecta a la Named Pipe cuenta con privilegios de System.
5. Finalmente, con el token del cliente impersonalizado se puede ejecutar las instrucciones que se quiera, como por ejemplo una shell.

Un buen recurso al que merece la pena dedicar unos minutos de lectura sobre este tópico, es el siguiente artículo: https://www.ired.team/offensive-security/privilege-escalation/windows-namedpipes-privilege-escalation

Se trata de un listado corto de algunas técnicas que se utilizan en elevación de privilegios en sistemas Windows, poco a poco se profundizará más y se emplearán otras herramientas y técnicas interesantes.

Un saludo y Happy Hack!
Adastra.