Los proyectos y scripts que van surgiendo enfocados a la post-explotación son cada vez más variados y potentes. Cada cierto tiempo suelen aparecer proyectos que dadas sus características encajan perfectamente con los objetivos de una campaña de Red Team o como mínimo, dan ideas o aproximaciones para enfrentarse a los problemas cada vez complejos que hacen parte de las actividades un de equipo de Red Team. Dicho esto, hace cerca de un año ha aparecido un proyecto para la creación de entornos C2 pero a diferencia de los ya conocidos como Pupy , ToRat,  Metasploit/Meterpreter, Koadic, o Empire, este en concreto utiliza técnicas de ofuscación y bypassing de mecanismos de seguridad habituales como AVs, de hecho tal como se indica en su sitio web en GitHub y tal como lo describe su autor, está enfocado a entornos “maduros”. Dado que evidentemente, no hay que comprar todo lo que se nos ofrece y aceptarlo sin antes verificarlo, en este post se explicarán las dificultades encontradas durante su instalación, configuración, uso y al final, dadas las pruebas realizadas se determinará si realmente puede ser conveniente en una campaña de Red Team para entornos debidamente securizados o si por el contrario requiere más trabajo y un enfoque más “artesanal/manual” como suele ocurrir en la mayoría de las campañas.

En primer lugar el proyecto se encuentra ubicado en el siguiente repositorio: https://github.com/bats3c/shad0w y el autor de la herramienta comparte sus ideas sobre la misma en su blog, concretamente en el siguiente post: https://blog.dylan.codes/shad0w/
El proceso de instalación, tal como se indica en el sitio web se basa en Docker, por lo tanto es necesario tener el servicio de Docker levantado en el sistema, algo que a día de hoy es cada vez más frecuente en proyectos de todo tipo y por lo tanto es recomendable aprenderlo.
Aunque en la documentación se indica que se debe clonar el proyecto y posteriormente ejecutar el comando “./shad0w install” como root, en la práctica dicho comando produce un error ya que espera que una imagen llamada “shad0w” se encuentre creada en el servicio de Docker, algo que evidentemente no será así inicialmente. No obstante, se cuenta con el fichero Dockerfile en el repositorio de GitHub por lo tanto no habrá ningún problema si se construye la imagen con el comando “docker build“.

Ahora se puede comenzar a utilizar la herramienta. Hay que tener en cuenta que lo que hace el binario “shad0w” es lanzar un contenedor Docker con la imagen creada previamente, esto a efectos prácticos significa que la herramienta está preparada y configurada para ser ejecutada dentro de ese contenedor. En las pruebas realizadas se ha lanzado directamente el fichero “shad0w.py” y en múltiples secciones del código se puede apreciar que aparece hardcodeada la ruta “/root/shad0w” y a menos que se ejecute dicho script como root (no recomendable) y se descargue la herramienta en esa ruta, no funcionará correctamente.

Los elementos que se incluyen en la herramienta son simples y recuerdan a otras utilidades para generar agentes o payloads como es el caso de Msfvenom o Pupygen, tal como se puede ver con la opción “–help” las opciones son muy intuitivas, sin embargo es conveniente leer el post del autor para entender la arquitectura del programa y cómo usarlo adecuadamente. En primer lugar, los payloads generados son llamados “beacons” y hay dos tipos: secure e insecure. En el caso de utilizar un beacon del tipo secure, las conexiones se realizarán utilizando HTTPS entre la víctima y el objetivo, en el segundo con HTTP. Por otro lado, los beacons pueden ser staged o static, en el primer caso el beacon contendrá unicamente las instrucciones necesarias para establecer la conexión con el atacante y posteriormente se transferirán otros componentes del payload de forma dinámica, haciendo que sea menos pesado y más fácil de manejar. Esto es equivalente a lo que ya hacen algunos payloads de Metasploit Framework. En el segundo caso, el binario transferido a la víctima tendrá incluido todo el código del payload, lo que significa que será más pesado y posiblemente, más fácil de detectar.

Los formatos soportados son los más habituales y se pueden especificar con la opción “-f”. Concretamente se puede establecer: “exe”, “psh”, “dll” y “raw”. Con esto, la muestra debería de estar preparada para ser transferida y ejecutada en la máquina objetivo.

Se ha probado sobre un sistema Windows 10 actualizado y la transferencia se ha realizado sin ningún problema, el Windows Defender lo ha dejado pasar y una vez ejecutado se ha obtenido el “beacon” en el servidor C2 que se ha tenido que levantar previamente.

No obstante, hay que mencionar 2 cosas importantes:

1. El beacon utilizado ha sido el “staged”, ya que el “static” ha sido detectado a la primera
2. Aunque se ha transferido correctamente, a la hora de ejecutarlo ha aparecido un error que al parecer corresponde a una rutina de Visual C++ que se ha desplegado en el ejecutable y a Windows no le gustado nada. No obstante, si se pincha en “Omitir” el payload se ejecuta correctamente y se consigue la conexión tal y como se puede ver en la imagen anterior.

Una vez hechas las pruebas sobre Windows 10 actualizado, se ha procedido a ejecutar lo mismo sobre un sistema Windows 8.1 limpio (recién instalado y actualizado) para comprobar su funcionamiento. En este caso concreto ha ocurrido algo que resulta curioso y es que con este sistema actualizado y con su correspondiente Windows Defender activo ha conseguido detectar la amenaza en ambos casos, tanto para el beacon “staged” como para el “static”. Resulta curioso precisamente porque en un sistema Windows 10 ha funcionado, pero también es cierto que no era un sistema recién instalado aunque sí actualizado.

Aun queda por probar otros formatos que no sean un binario PE y hacerlo sobre un sistema Windows Server. Estas pruebas concretamente se llevarán a cabo en el siguiente post.

Un saludo y Happy Hack!
Adastra.