Desde que PowerShell Empire se ha convertido en una herramienta popular de post-explotacion entre los Threat Actors, las organizaciones se preocupan más por prevenir y detectar esta herramienta o cualquier otra que se apoye en PowerShellpara ejecutar código malicioso. Las capacidades de PowerShell Empire no han parado de crecer: en el ultimo commit del proyecto, versión v2.1, se han agregado funciones de ScriptBlock logging bypass, ofuscación de payloads, modulo para EternalBlue y un largo etcetera.
 |
| Figura 1: Cómo detectar a pentesters usando PowerShell Empire en máquinas comprometidas con una Query de Splunk |
Prevenir o detectar cada uno de los módulos que incorpora PowerShell Empire o cada uno de los mecanismos de infección es bastante complicado en grandes corporaciones. Los sistemas de End-Point Protection ya hacen un buen trabajo para detectar, al menos, lo básico. Sin embargo, por muy avanzado que sea el método de intrusion en la red de la víctima, siempre hay un punto débil, el punto en común de cualquier rat moderno: la comunicación con el servidor de commando y control (C2).
Detectar PowerShell Empire con la configuración por defecto
PowerShell Empire se comunica con el servidor C2 por medio de conexiones http/https, a través de peticiones GET/POST a ciertas URLs. En la siguiente imagenb puedes ver cual es la configuración por defecto de los diferentes listeners http:.
 |
| Figura 2: Listeners por defecto configurados en PowerShell Empire |
En el valor de la variable ‘DefaultProfile’ se especifica las diferentes URLs que PowerShell Empire visitará en forma de GET para recibir commandos, y el valor de ‘DefaultDelay’ especifica cada cuánto tiempo lo hará, es decir, cada 5 segundos. Lo que los equipos blue-team pueden aprovechar es que la configuración por defecto no está aleatorizada por PowerShell Empire, ni es algo habitual encontrar que estas variables sean cambiadas por los threat actors.
Partiremos de la base que estamos bajo un ambiente corporativo que posee un servidor proxy por el cual pasan todas las conexiones de la empresa, que hay un logde todas esas peticiones y que estas son ‘queryables’, es decir, que tenemos una aplicación con la cual podemos hacer búsquedas en esos logs. Tener habilitado en el ambiente corporativo las inspecciones SSL (donde se pueda), al menos a nivel de Tier 1 (servidores), ayuda a poder registrar las URLs visitadas por los agentes de PowerShell Empire que hayan habilitado HTTPS.
Query de Splunk para detectar PowerShell Empire
Para hacer la búsqueda dentro de los masivos datos que podemos encontrar en los logs de un servidor proxy de una empresa grande, utilizaremos una instancia de Splunk Enterprise, utilizando las ventajas del Common Information Model y los Accelerated data models. Si no tienes este producto, siempre puedes crear gratis una instancia Docker de Splunk Enterprise e importar el log de tu proxy de un mes y probar qué tal.
 |
| Figura 3: Query de Splunk para localizar agentes de PowerShell Empire |
Con este query lo que buscamos descubrir es la dirección IP del servidor C&C (dest)y el host de origen (src) que está generando «peticiones masivas» (attempts) a las distintas URLs por defecto de Empire 1 y Empire 2 (url y dc_url). Para eliminar falsos positivos, siempre hay que fijarse en la cantidad de peticiones (attempts). Será un número realmente alto en un timeframe de 24h. Esto muestra que siempre es útil crear reglas o Use Cases para aprovechar las configuraciones por defecto de los frameworks de explotación, que al final son como firmas de comportamiento.
Happy hunting!
Autor: Daniel Ferreira (@daniel0x00), Threat hunter en Royal Dutch Shell.
