En los dos post anteriores sobre Impacket se han mencionado algunas herramientas disponibles en el proyecto para la ejecución remota utilizando SMB, DCOM, WMI, etc. Las puedes ver en los siguientes enlaces.
Network Hacking con Impacket – Parte 1
Network Hacking con Impacket – Parte 2
En esta ocasión se explicarán otras herramientas adicionales interesantes incluidas en Impacket.
Este script se encarga de realizar un volcado completo de los SAM/LSA Secrets, credenciales cacheadas, información sensible almacenada en el registro y los hashes NTLM del sistema. Todo esto lo hace sin necesidad de desplegar ningún tipo de utilidad en el sistema objetivo. Su funcionamiento consiste en habilitar el servicio de Remote Registry en el caso de que no se encuentre habilitado y utilizarlo para el acceso al registro de la máquina objetivo. La información que consigue obtener se almacena en el directorio %SYSTEM_ROOT%/Temp para posteriormente, consultarla y enseñarla en la terminal del atacante. Una vez termina el proceso, la herramienta es capaz de revertir los cambios que se han aplicado y devolver la sistema a su estado inicial.
Como se puede apreciar, la información que permite obtener puede ser útil para realizar ataques de cracking con herramientas como John The Ripper o Hashcat.
Se trata de una utilidad que permite conectarse a un servicio RPC levantado desde Mimikatz en la máquina comprometida. Para ello, en el sistema objetivo se debe ejecutar Mimikatz y posteriormente lanzar el comando “rpc::server”. A continuación, desde la máquina del atacante se podrá ejecutar el script “mimikatz.py” para establecer la conexión.
A partir de este punto, se podrán ejecutar los comandos habituales disponibles en Mimikatz desde la máquina del atacante gracias al servidor RPC que se encuentra en ejecución en la víctima.
WMI es un componente muy potente para administración de un sistema windows y se encuentran disponible en prácticamente todas las versiones del sistema operativo, por lo tanto es un buen recurso a la hora de llevar a cabo un proceso de Enumeración en Windows para post-explotación. Es bastante común utilizar herramientas como WMIC para realizar consultas y obtener información general del sistema, sin embargo cuenta con otras interfaces que permiten la interacción con WMI como es el caso de WQL. Se trata de una implementación del estándar ANSI SQL adaptada a WMI, lo que significa que conociendo la sintaxis de las consultas SQL y sabiendo qué elementos se pueden consultar, será suficiente para sacarle el máximo provecho a WQL, lo cual resulta mucho más beneficioso y potente que solamente usar WMIC. La herramienta “wmiquery.py” que se encuentra disponible en Impacket permite abrir una shell para ejecutar instrucciones WQL contra el sistema comprometido.
La sintaxis de las consultas es similar a cualquier consulta SQL ejecutada contra una base de datos relacional, simplemente es necesario saber cuáles son los elementos que se pueden consultar y cuales son sus campos para poder filtrar si es necesario. La documentación oficial de Microsoft ofrece información abundante en los siguientes enlaces:
En un próximo artículo se hablará sobre las consultas WQL que se pueden ejecutar para procesos de enumeración sobre sistemas windows.
Por otro lado, la utilidad “wmipersist.py” implementa un mecanismo de persistencia interesante que se basa en la creación de una suscripción WMI que responderá a un evento concreto, siguiendo el patrón de diseño Observer. La utilidad recibe un parámetro llamado “-vbs” al que se le debe indicar la ubicación de un fichero con instrucciones Visual Basic Script, las cuales se ejecutarán cuando se active el filtro correspondiente al evento, que puede ser por ejemplo, cuando el usuario ejecuta un programa concreto o con una periodicidad fija, similar a cualquier tarea programada que se ejecuta en el sistema.
Como se puede apreciar en la imagen anterior, se establece como filtro una consulta WQL la cual indica que cuando el usuario ejecute el proceso “calc.exe” se debe ejecutar el código incluido en el fichero “test.vbs”. Como se ha mencionado anteriormente, también es posible indicar una periodicidad concreta, en ese caso se debe sustituir la opción “-filter” por “-timer” e indicar cada cuánto se ejecutará el script VBS en milisegundos.
El funcionamiento en ambos casos es similar y tal como se puede apreciar en las trazas de ambas imágenes lo único que cambia es que en el segundo caso se añade un “IntervalTimerInstruction” al “ScriptEventConsumer”.
En ambos ejemplos se ha partido de un script VBS que se encuentra en los comentarios de la utilidad wmipersist.py pero evidentemente, puede ser cualquier otro tipo de instrucción maliciosa, como por ejemplo un payload de Cobalt Strike, Metasploit, Core Impact, etc.
Por último, si quieres aprender más sobre la potencia de WMI para operaciones de Red Team te sugiero que leas el siguiente post de duouyinsu o si lo prefieres puedes esperar a una serie de posts que estoy preparando sobre este tema. 🙂
Un saludo y Happy Hack!
Adastra.