En los otros dos posts anteriores sobre Shad0w he realizado un análisis sobre las capacidades de evasión que tiene esta herramienta y los resultados han sido bastante satisfactorios sobre sistemas Windows actualizados y con versiones recientes o no, ya que solamente se ha probado la evasión y conexión con el C2, ahora es el momento de probar los beacons en funcionamiento. Si te los has perdido puedes leerlos aquí:

Entornos C2 sobre sistemas Windows con Shad0w: Evasión de mecanismos de seguridad – Parte 1 de 2.
Entornos C2 sobre sistemas Windows con Shad0w: Evasión de mecanismos de seguridad – Parte 2 de 2.

Hay que verificar si el funcionamiento de los Beacons es el esperado y si en algún momento durante su ejecución, son detectados por parte del sistema objetivo, teniendo en cuenta que como se ha mencionado anteriormente, el sistema se encuentra debidamente actualizado.

Lo primero, evidentemente, es generar el beacon, transferirlo a la víctima y ejecutarlo, lo cual permitirá generar una nueva sesión en el C2 de Shadow. Tal como se ha visto en el post anterior, los beacons generados en formato EXE han sido detectados rápidamente por Windows Defender, sin embargo en el caso del beacon en formato PowerShell se ha conseguido la evasión correctamente.

Existen algunos comandos básicos para interactuar con la máquina comprometida y que son precisamente los que ayudarán a probar que efectivamente, el payload que se está ejecutando en la víctima pasa desapercibido y no se detecta por parte del Windows Defender. Y este es el punto en el que me he llevado las manos a la cabeza:

Muy bien, supuestamente hay una conexión con el objetivo pero los comandos ejecutados no devuelven ningún resultado lo que significa a efectos prácticos, que aunque se han evadido las restricciones impuestas en el sistema objetivo el beacon resulta completamente inútil.
¿Cuál es el motivo de esto? como se ha comentado en el post anterior, a la hora de ejecutar el fichero PS1, el entorno de Powershell arroja un error y detiene su ejecución justo después de que se establece la conexión con el C2. Por lo tanto, el handler de Shad0w asume que hay una conexión establecida pero a la hora de intentar ejecutar cualquier comando que se le indica, simplemente no obtiene ninguna respuesta. Con las pruebas realizadas en los posts anteriores ninguno de los binarios generados (“staged” y “static”) era capaz de evadir las restricciones de seguridad del sistema, por lo tanto y muy a mi pesar, podría afirmar que Shad0w no tiene el mejor de los resultados en un sistema Windows 8.1. Y ojo, cambiando la frase que más he escuchado a amigos y conocidos (“En mi local funciona”), diré que esto “En mi local NO funciona”, lo que significa que puede que “En tu local funcione”, así que te animo a lo que pruebes y si obtienes unos resultados distintos escribas un comentario en este post.

Nuevamente, se genera un beacon del tipo “staged” ya que como se ha comentado en los post anteriores, Windows 10 actualizado y con las medidas de seguridad activas, era capaz de detectar la muestra en formato PS1 y un binario PE con todas las instrucciones incluidas en él (static). Una vez recibida la conexión por parte del sistema objetivo se puede comprobar que a diferencia de lo visto en Windows 8.1, con esta sesión sí que se puede trabajar y ejecutar los comandos disponibles en los Beacons de Shad0w.

Una de las primeras cosas a tener en cuenta cuando se interactúa con los Beacons de Shad0w es que su comportamiento es muy similar a los agentes en Empire Framework ya que se ejecuta una instrucción y no hay que esperar la respuesta, ésta llega después de forma asíncrona. Esto puede ser confuso ya que en ocasiones los resultados de los comandos ejecutados tardan en llegar y se solapan con otras instrucciones que se están ejecutando en ese preciso momento o incluso, puede ocurrir que nunca llegue una respuesta a un comando ejecutado previamente. “Es lo que hay”. Por otro lado, aunque en términos generales el Beacon funciona correctamente y se mantiene activa la sesión sin detección alguna por parte de la máquina comprometida, hay comandos que requieren otras dependencias (binarios) que no se encuentran disponibles en el contenedor Docker que se ha creado partiendo de la imagen oficial.

Esto tiene “fácil” solución, ya que basta simplemente con ubicar en el contenedor esos binarios que hacen falta para ejecutar las instrucciones con normalidad. Esto es  así porque en el repositorio oficial de la herramienta, en el directorio “bin” se hace referencia a otro repositorio externo (submodulo) y cuando se clona con “git clone” sin más parámetros, los contenidos de dicho submodulo no se copian. En cualquier caso, dichos binarios se encuentran disponibles  aquí y se pueden descargar y mover al contenedor en funcionamiento o volver a construir la imagen Docker asegurándose de que antes de hacerlo, dichos binarios están en su sitio, basta simplemente con clonar el repositorio incluyendo sus correspondientes submodulos: git clone –recurse-submodules https://github.com/bats3c/shad0w.

Como se puede ver en la imagen anterior funciona correctamente. A partir de este punto se han ejecutado varias pruebas sobre los comandos disponibles en el beacon y ninguna ha sido detectada por el sistema comprometido, excepto aquellas que subían o descargaban ficheros, es decir, las instrucciones “upload” y “download” hacían que el Windows Defender con el análisis en tiempo real detectara el payload y cortaba la conexión, por lo tanto es mejor no hacer uso de dichas instrucciones y si hace falta realizar procesos de exfiltración, posiblemente la mejor opción será utilizar alguno de los binarios disponibles en LOLBas, tal como ya se ha mencionado anteriormente en la serie sobre enumeración en sistemas Windows para post-explotación.

Un saludo y Happy Hack!
Adastra.