Demostración en vídeo de este post
Empire Framework ha sido diseñado en sus inicios como una herramienta de post-explotación que ayuda en las labores típicas en esta etapa de un pentest o campaña de Red Team, no obstante ha tenido sus altos y bajos, pasando de PowerShell Empire a luego llamarse Empire Framework, es un proyecto inicialmente desarrollado por personas tan conocidas en el mundo de la seguridad informática como Will Schroeder y con características que realmente sobresalían, no obstante su desarrollo fue abandonado y el repositorio archivado, por lo que daba la impresión de que el proyecto había llegado a su fin y era el momento de ver otras alternativas o sacar lo que se pudiese del código para crear otra herramienta. Sin embargo, tiempo después de que el proyecto original fuese declarado como “finalizado”, la empresa BC-Security y concretamente, Cx01N, Hubbl3 y Vince decidieron reactivarlo haciendo un fork del proyecto original. Desde ese momento la herramienta no ha parado de crecer y ahora mismo cuenta con más listeners y stagers orientados a entornos maduros en los que evidentemente, pueden haber mecanismos de seguridad implementados.
Inicialmente uno de los cambios más relevantes de Empire Framework 4 con respecto a su versión anterior, es que ahora hay un componente “server” completamente independiente que se encarga de la gestión de absolutamente todas las características del entorno. Esto significa que, evidentemente, también existe un componente “client” que es desde donde se envían las peticiones y es precisamente la interfaz principal con la que se interactua. Esto de hecho, también estaba montado así en versiones anteriores, pero gracias a una refactorización profunda en el código y al diseño modular que se ha implementado, es posible ejecutar el componente server y client en máquinas separadas. Esto también tiene otra ventaja y es que se pueden crear clientes personalizados, es decir, se puede crear un script en cualquier lenguaje de programación que consulte la API Rest del componente server y ejecutar rutinas de forma automática. De hecho, además del componente cliente disponible en la herramienta, hay otra utilidad que es capaz de consultar los endpoints de dicha API Rest llamada StarKiller de la que se hablará en otra ocasión.
Como se ha comentado anteriormente, ahora hay dos componentes cliente y servidor independientes, lo que significa que es necesario ejecutar ambos programas de forma separada. Hay que tener en cuenta que ambos son configurables, es decir, en ambos componentes existe un fichero de configuración que indica la interfaz de red y puerto que se abrirá (componente server) así como la IP y puerto contra el cual se debe realizar la conexión (componente client). Si no se modifican estos valores, tanto el servidor como el cliente utilizarán la interfaz de red local y el puerto 1337. Otro detalle que hay que tener en cuenta es que requiere poetry y una versión superior a Python 3.8, al margen de esto, se conserva el script de instalación que es tan frecuente en las versiones anteriores de la herramienta ubicado en setup/install.sh
Funciona perfectamente en Debian 10 y Kali, aunque el proceso de instalación puede tardar algunos minutos. Una vez se encuentra instalado, es necesario abrir una terminal y ejecutar el componente servidor y desde otra, ejecutar el componente cliente que se conectará a la API Rest que levanta el servidor.
En la imagen anterior se puede ver cómo se ha ejecutado el componente “server” en la consola superior utilizando el comando “poetry run python empire.py server” y en la terminal inferior, aunque no se puede ver el comando ejecutado dada la forma en la que se enseña el interprete de Empire, pero ha sido “poetry run python empire.py client“. Se aprecia que efectivamente, el cliente establece la conexión contra el componente servidor en el puerto 1337 y el servidor acepta dicha conexión. Se trata de una conexión utilizando HTTPS con un certificado autofirmado generado por Empire, pero se podría generar otro certificado con OpenSSL o uno valido emitido por una CA de confianza e incluirlo en los ficheros de configuración tanto del cliente como del servidor para esta establecer una conexión.
A partir de este punto, usar la herramienta no tiene ninguna dificultad y se siguen los mismos pasos de las versiones anteriores y que por cierto, he documentado en este blog hace algunos años. Puedes leer ese post aquí.
Tal como mencionaba anteriormente, el uso de la herramienta no ha cambiado mucho con respecto a versiones anteriores, se encuentran más elementos, por supuesto, pero la dinámica sigue siendo la misma. Una cosa que resulta llamativa de esta nueva versión de Empire es que la interfaz es más limpia y cuenta con componentes de ayuda que permiten trabajar rápidamente.
Existen varios listeners y stagers nuevos que son interesantes, además funcionan bastante bien. Por ejemplo windows/wmic y windows/launcher_vbs pueden ser útiles en determinados entornos. Además, tal como se indica en el post publicado por BC-Security sobre las características nuevas en Empire Framework 4 que puedes leer aquí, describe un stager basado en C# que embebe su código en un ejecutable. La “gracia” que tiene es que el agente que se genera de la ejecución de dicho stager en la máquina comprometida es que cuenta con un conjunto de módulos muy interesantes, entre los que se incluye la integración con las herramientas de GhostPack, lo que permite llevar a cabo procesos de post-explotación en Windows muy potentes y elaborados. De esto, hablaré con mucho más detalle en otro post.
Puedes ver el vídeo que está disponible en este post para que puedas ver más claramente cómo utilizar Empire Framework 4 y los beneficios que aporta en un Pentest o en una campaña de Red Team
No será el último post que escriba sobre Empire Framework, se están haciendo grandes esfuerzos en mejorar la herramienta y merece la pena prestarle atención y apoyar.
Un saludo y Happy Hack!
Adastra.