Hoaxshell proporciona de forma client-side una shell inversa que por el momento Microsoft Defender y posiblemente otros motores de AVs no estn detectando ya que se basa nicamente en el trfico http y https, segn nos comenta su desarrollador. Aunque ms adelante veremos como esto puede ser detectado a nivel de eventos de Windows y no por eventos producidos en la red.

Hoaxshell: obteniendo una shell remota

git clone https://github.com/t3l3machus/hoaxshell

cd ./hoaxshell

sudo pip3 install -r requirements.txt

chmod +x hoaxshell.py

[hoaxshell_1.png]

Figura 1: Ejecucin de hoaxshell obteniendo una shell inversa.

Buscando indicadores de compromiso para la deteccin de Hoaxshell

Analizando el trfico de red

Si analizamos la comunicacin de red una vez hemos lanzado el ataque de ejecucin de la shell sin cifrar (8080/http) se monta un servidor web apache con una URI generada aleatoriamente donde la mquina vctima descargar el payload automticamente cuando lo ejecute. Este es posible a travs del llamada Invoke-WebRequest incluido en el payload codificado en base64 que veremos descodificado ms adelante.

[wireshark_http_8080_hoaxshell.png]

Figura 2: Hoaxshell sin cifrar - Deteccin de trfico de red.

En el caso de lanzar el ataque con un certificado auto firmado va 443/https en la captura de trfico vemos el establecimiento de conexin Client Hello de TLS y el intercambio de claves en el handshake entre cliente/servidor. Por otro lado esto tambin nos genera un evento en el provider de Powershell en el cual vemos texto claro la decodificacin del payload que se ejecut en base64.

[event_https_443_hoaxshell.png]

Figura 3: Hoaxshell cifrando - Deteccin de trfico de red.

Analizando los eventos de Windows

[event4103_powershell_deteccion_hoaxshell.png]

Figura 4: Event Id. 4103 de Powershell generado por la ejecucin de Hoaxshell sin comunicacin cifrada.

El payload de Hoaxshell se genera codificado en base64 tanto para obtener una shell sin cifrar como cifrada, en el caso de lanzar una shell cifrada lgicamente el tamao del payload ser ms largo. Decodificando este payload podemos ver lo que est haciendo para poder invocar la shell inversa que despus se nos proporciona.

[hoaxshell_base64_decode.png]

Figura 5: Decodificando payload de Hoaxshell en base64.

Lanzando el ataque en su modo de comunicacin cifrada vemos que nos genera en el provider de Powershell los eventos Id. 4103 e Id. 4104 mostrando en texto claro las instrucciones del scriptblock de Powershell y que coincide con la decodificacin vista anteriormente en la figura 5.

[deteccion_hoaxshell_https_eventwin.png]

Figura 6: Event Id. 4103 y 4104 de Powershell generado por la ejecucin de Hoaxshell con comunicacin cifrada.

Creando IOC y reglas de deteccin en Wazuh

En este escenario vamos a utilizar Wazuh como SIEM para la creacin de los indicadores de compromiso y generar una regla de deteccin cuando se registre un evento relacionado con un posible ataque de Hoaxshell. Lgicamente esto puede ser exportable a otros formatos de reglas compatibles para otros sistemas de monitorizacin de eventos de seguridad.

En el caso de Wazuh aadimos al fichero agent.conf el provider de registro de Powershell indicando la recoleccin de este tipo de eventos.

[hoaxshell_agentconf_windows_powershell_wazuh.png]

Figura 7: Aadir el provider de registro Powershell/Operational.

En el fichero local_rules.xml creamos las reglas para su deteccin, la ltima regla ser la que realmente nos registre el posible ataque indicando el eventID 4103 y los posibles IOCs vistos anteriormente. 

 <rule id="100535" level="0">

  <if_sid>60009</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Information EventLog</description>

</rule>

<rule id="100536" level="0">

  <if_sid>60010</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Warning EventLog</description>

</rule>

<rule id="100537" level="0">

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <field name="win.system.severityValue">^ERROR$</field>

  <group>powershell,</group>

  <description>Powershell Error EventLog</description>

</rule>

<rule id="100538" level="0">

  <if_sid>60012</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Critical EventLog</description>

</rule>

  

<rule id="100540" level="12">

  <if_sid>100535</if_sid>

  <field name="win.system.eventID">4103</field>

  <field name="win.system.message" type="pcre2">(?i)powershell.exe.*-e</field>

  <field name="win.system.message" type="pcre2">(?i)Command.*;split-path.\$pwd.\\0x00</field>

  <field name="win.system.message" type="pcre2">(?i)Invoke-Expression</field>

  <description>Powershell hoaxshell detected</description>

</rule>

Por lo que se pudo comprobar y dado los indicadores de compromiso encontrados la deteccin es exitosa tanto si se ejecuta Hoaxshell en un modo de payload sin cifrar como con una comunicacin cifrada.

[hoaxshell_deteccion_regla_wazuh.png]

Figura 8: Creacin de reglas de deteccin e IOCs de Hoaxshell.

Con la regla guarda, ejecutamos de nuevo Hoaxshell y... bingo! vemos como nos est detectando la ejecucin y generacin de sesin de este tipo de shell en Powershell.

[hoaxshell_deteccion_wazuh.png]

Figura 9: Alerta en la ejecucin de un "Powershell hoaxshell detected"

Conclusiones

Podemos decir entonces que "esa shell indetectable" quizs no lo es tanto. Si bien es cierto que actualmente no est siendo detectada automticamente por Microsoft Defender como proteccin por defecto en un sistema Windows y es posible que otros motores de antivirus tampoco lo estn haciendo hay que saber que estableciendo unas polticas de auditora habilitadas en las mquinas, prcticamente todo deja un rastro que se acaba traduciendo en un evento o registro de log del sistema.

Sobre el tipo de payload cifrado o sin cifrar que podemos generar con Hoaxshell vemos que a nivel de evento de sistema es detectable, sin embargo a nivel de comunicacin de red es realmente donde est su ventaja ya que en una comunicacin sin cifrar podemos identificar la URI que genera pero en una comunicacin cifrada la comunicacin es TLS y no podra ser leda en un primer intento de deteccin.

Personalmente me resulta curioso que MS Defender no est detectando una simple ofuscacin codificada en base64 a travs de Powershell y que su vez no haga un monitoreo continuo de los eventos registrados donde se encuentran decodificados. Aunque estoy seguro de que Microsoft no tardar mucho en poner solucin a esto y ms con el revuelo que est habiendo actualmente con Hoaxshell y su facilidad de uso.

Con la colaboracin de @noloseconseguridad.

Saludos!

Port knocking o golpeteo de puertos es un mtodo que proporciona seguridad frente ataques de servicios de red, consiste en realizar una serie de peticiones de conexin con una secuencia ordenada de puertos para poder habilitar una regla previamente configurada en el mquina remota que nos permita abrir una comunicacin nica entre cliente/servidor y establecer finalmente una conexin abierta SSH hacia el servidor remoto. El uso de esta implementacin puede ser catalogado como seguridad por oscuridad. 

¿Cmo funciona una conexin SSH usando Port knocking? 

1. Tenemos un servidor SSH que expone el puerto por defecto 22 o bien otro un puerto especfico como por ejemplo 4422 (ser el puerto que se trate en este escenario).
2. Se aade una regla a nivel de firewall del propio servidor para rechazar todas conexiones entrantes sobre el puerto SSH previamente configurado 4422.
3. Para poder conectarnos a este servidor usando una tcnica de port kockning de hasta tres "golpeteos" de puertos para establecer una conexin SSH, necesitamos realizar una peticin a estos puertos, en este escenario mostrar tres formas de hacerlo (knockd, telnet y nmap).
4. Una vez realizado el knocking de puertos en el orden establecido (que veremos posteriormente en el fichero de configuracin) este disparar la accin de ejecutar un comando, este comando no ser ms que establecer una nueva regla en este caso va iptables para permitir la conexin SSH nicamente desde la IP origen que realiz la secuencia de golpeteo de puertos y no desde ninguna otra IP alcanzable de la misma red.
5. Finalmente para volver aplicar la regla de bloqueo y restablecer esta configuracin al terminar nuestra sesin, se lanzar el golpeteo de puertos de salida de SSH. De modo que la configuracin vuelva a restablecerse y vuelva a cerrarse el puerto hacia el exterior.

Configurando Iptables

Bloquear puerto SSH configurado va Iptables

En este escenario el servidor SSH se ejecuta en un entorno Debian y expone el puerto 4422 (en vez del puerto 22 por defecto).

Aadimos un regla iptables para rechazar todas las conexiones entrantes hacia el puerto 4422 del servidor SSH configurado. 

sudo iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset

Iptables: diferencias entre DROP y REJECT (estado de puertos "filtered" o "closed")

La teora nos dice que uso de DROP no har nada con el paquete recibido, simplemente lo descartar sin enviar ningn tipo de respuesta. Al contrario de REJECT donde se genera un paquete de respuesta rechazando la conexin, si no se especifica el tipo de respuesta por defecto este paquete sera un "ICMP Destination port unreachable".

En la prctica esto no es del todo cierto. Cuando la regla es DROP es cierto que el paquete se descarta y no se enva ningn paquete de respuesta, sin embargo una regla DROP anunciar que existe un control de puertos y los escneres sabrn que se est haciendo uso de un firewall devolviendo un estado de puerto "filtered". Ocurre lo mismo si solo usamos REJECT sin especificar un tipo concreto de respuesta, este responder con un paquete "ICMP Destination port unreachable" anunciando as el filtrado de dicho puerto.

Si lo que queremos es ocultar el puerto y devolver un estado "closed" como resultado en un escaneo de puertos, haciendo creer que el puerto o servicio que se ejecuta en el lado servidor no se est usando o simplemente no existe, debemos especificar un tipo de respuesta en una regla REJECT. 

Cuando usamos TCP o UDP sobre un puerto la respuesta debe responder con los flags RST/ACK, de este modo estaremos indicando a los escneres un estado de puerto "closed".

• TCP: iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset
• UDP: iptables -A INPUT -p udp --dport 4422 -j REJECT --reject-with icmp-port-unreachable

Reglas DROP y REJECT con estado "FILTERED" (TCP/UDP)

[nmap_filtered_1.png]

Figura 1: Estado de puerto "filtered" usando DROP en TCP.

[nmap_filtered_2.png]

Figura 2: Estado de puerto "open|filtered" usando DROP en UDP.

iptables -A INPUT -p tcp --dport 4422 -j REJECT

[nmap_filtered_3.png]

Figura 3: Estado de puerto "filtered" usando REJECT en TCP.

Reglas DROP y REJECT con estado "CLOSED" (TCP/UDP)

iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset

[nmap_filtered_4.png]

Figura 4: Estado de puerto "closed" usando REJECT en TCP.

iptables -A INPUT -p udp --dport 4422 -j REJECT --reject-with icmp-port-unreachable

o

iptables -A INPUT -p udp --dport 4422 -j REJECT

[nmap_filtered_5.png]

Figura 5: Estado de puerto "closed" usando REJECT en UDP.

Guardado y persistencia de reglas Iptables despus de reiniciar la mquina

Instalamos el paquete iptables-persistent.

sudo apt-get install iptables-persistent

Guardamos y cargamos reglas configuradas de Iptables.

sudo netfilter-persistent save
sudo netfilter-persistent reload

Para proporcionar la persistencia de las reglas configuradas de Iptables despus un reinicio de la mquina. En el fichero /etc/crontab aadimos la ejecucin para cargar las reglas guardas despus cada arranque del sistema.

sudo echo "@reboot sudo netfilter-persistent reload &" >> /etc/crontab

Implementacin de Port Knocking - knockd

Instalamos el servicio de knockd

sudo apt install -y knockd

Configuracin de knockd

Editamos el fichero de configuracin de /etc/knockd.conf.

[options]
        #UseSyslog
        logfile     = /var/log/knockd.log

[openSSH]
        sequence    = 7500,8200,9800
        seq_timeout = 5
        command     = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 4422 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9300,4500,6200
        seq_timeout = 5
        command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 4422 -j ACCEPT
        tcpflags    = syn

Por cuestiones de monitorizacin y depuracin de posibles errores establecemos un logfile especfico para este servicio con el path donde se almacenarn los logs de knockd. Comentamos UseSyslog ya que si mantenemos esto por defecto los logs se almacenarn en el fichero de sistema /var/log/syslog.

Disponemos de dos principales directivas. Una para abrir la conexin SSH (openSSH) y otra para cerrar y restablecer la configuracin de la conexin SSH (closeSSH).

Seccin openSSH:

• sequence: Se define la configuracin secreta de puertos a golpear. Se puede especificar tres o ms puertos y su vez indicar el tipo de protocolo, bien sea por tcp o udp. Por defecto se estable a tres puertos en protocolo tcp. En este caso modifiqu los puertos y secuencia en el siguiente orden: 7500,8200,9800.
• seq_timeout: Tiempo de esperar entre la ejecucin de un golpeteo a otro de puertos. Por defecto se establece a 5 segundos, aunque podemos aumentarlo si no fuese suficiente. No se recomienda establecer grandes intervalos de tiempo para evitar ataques de fuerza bruta que realizan esta accin de forma automatizada intentando encontrar la combinacin correcta de puertos. Una herramienta utilizada podra ser KnockIt - https://github.com/eliemoutran/KnockIt.
• command: Comando que el servidor ejecutar cuando detecte la combinacin correcta de puertos previamente golpeados. En este caso se agregar en una nueva regla (iptables -I) en el primer orden de la jerarqua de prioridad de la tabla INPUT de iptables para permitir nicamente desde la direccin IP origen la la conexin hacia el puerto 4422 configurado para este servidor SSH.
• tcpflags: Tipo de paquetes que reconocer el servidor como vlidos para el port knocking (en este caso con un flag syn).

Seccin closeSSH:

Los parmetros son los mismos que las anteriores con la diferencia de indicar otro nmero de secuencia distinta (en este caso: 9300,4500,6200) para ejecutar otra regla en el parmetro de command.

• command: Se eliminar (iptables -D) la regla aadida anteriormente. De modo que el servidor vuelva a "restablecer" con la configuracin inicial rechazando todas las solicitudes origen hacia el puerto 4422 de SSH.

Habilitar el daemon knockd

Editamos el fichero /etc/default/knockd. Establecemos START_KNOCKD a valor "1" para habilitar el servicio y en KNOCKD_OPTS indicamos la interfaz de red que que usar el servicio, en este caso enp0s3.

START_KNOCKD=1
KNOCKD_OPTS="-i enp0s3"

Iniciamos el servicio knockd y habilitamos un tipo de inicio automtico del servicio en el arranque del sistema.

sudo systemctl start knockd
sudo systemctl enable knockd

¿Cmo conectarse a un servidor SSH usando Port Knocking?

Analizando el escenario actual

• Mquina Debian - Cliente: 10.0.0.23
• Mquina Debian - Servidor: 10.0.0.22

En la siguiente captura se muestra un intento de conexin SSH desde la mquina cliente (10.0.0.23) sin el uso de Port knocking y vemos como la conexin ha sido rechazada.

Si comprobamos el estado de puerto con Nmap vemos que el puerto se muestra en un estado cerrado "closed". Esto es as porque previamente habamos especificado el tipo de respuesta en REJECT con un tcp-reset el cual nos devuelve un paquete RST/ACK (ver figura 1 para ms detalles).  

Si revisamos la configuracin de reglas de iptables en la mquina servidor (10.0.0.22) vemos como hay una regla que rechaza cualquier tipo de conexin por el puerto 4422 desde cualquier IP origen.

[port-knocking-ssh_1.png]

Figura 6: Intento de conexin SSH usando knockd sin el uso de secuencia Port Knocking.

Opcin 1: usando knock con Port Knocking

Desde la mquina cliente instalamos knockd. Para conectarnos al servidor remoto ejecutamos lo siguiente.

$ knock -v 10.0.0.22 7500 8200 9800
hitting tcp 10.0.0.22:7500
hitting tcp 10.0.0.22:8200
hitting tcp 10.0.0.22:9800

Una vez golpeado los puertos el orden de secuencia de correcto, ejecutamos ssh para conectarnos al servidor por el puerto configurado 4422.

ssh -p 4422 user@10.0.0.22

En la siguiente captura de pantalla podemos ver como despus realizar el intento de conexin SSH al servidor remoto usando la combinacin correcta de golpeteo de puertos este ejecuta el comando establecido en la directiva "openSSH" configurado en el fichero /etc/knockd.conf donde se indica que se aada en primer orden una nueva regla iptables para permitir la comunicacin nicamente a la IP origen de la mquina cliente permitiendo as la conexin SSH hacia la mquina servidor remota.

Como prueba podemos comprobar el estado de conexin de puertos con Nmap, desde la mquina cliente permitida vemos como el puerto 4422 est en estado abierto "open", sin embargo si comprobamos lo mismo desde otra mquina de la red con otra IP origen distinta vemos como para esa otra mquina el estado del puerto 4422 es "closed". Por lo tanto podemos decir que las reglas estn funcionando correctamente y estamos "ocultando" o ms bien filtrando el uso de las comunicaciones en un puerto concreto entre otras mquinas, la mquina cliente origen y la mquina servidor.

Si revisamos la mquina servidor vemos como ahora existe una nueva regla de iptables en el orden de prioridad 1 (ser la primera regla que interprete el firewall) permitiendo la conexin al puerto 4422 desde la IP origen 10.0.0.23 (mquina cliente). Si analizamos los logs /var/log/knockd.log tambin verificamos que se ejecut correctamente el orden de secuencia de golpeteo de puertos y el comando que agrega esta regla al firewall local de iptables.

Finalmente salimos de la sesin SSH remota, para volver restablecer las reglas iptables de la mquina servidor y as volver rechazar las conexiones por el puerto 4422 a todas las mquinas e incluida la mquina cliente. Ejecutamos la secuencia de golpeteo de puertos establecida en la directiva de "closeSSH". De esta forma si volvemos a revisar las reglas en la mquina servidor vemos como esta se elimina y se vuelve establecer con prioridad 1 la regla de bloqueo que rechaza todas las conexiones desde cualquier IP origen.

[port-knocking-ssh_2.png]

Figura 7: Intento de conexin SSH usando knockd con la secuencia correcta de Port Knocking.

Opcin 2: usando telnet con Port Knocking

Otra forma de realizar port knocking es hacer uso del comando telnet. Recibir un mensaje de "Connection refused", pero est bien, ya que telnet est deshabilitado en ese puerto y solo queremos enviar un paquete con flag "TCP SYN". 

$ telnet 10.0.0.22 7500

Trying 10.0.0.22...

telnet: Unable to connect to remote host: Connection refused

$ telnet 10.0.0.22 8200

Trying 10.0.0.22...

telnet: Unable to connect to remote host: Connection refused

$ telnet 10.0.0.22 9800

Trying 10.0.0.22...

telnet: Unable to connect to remote host: Connection refused

Una vez se concluya el comando telnet durante las tres secuencias de puertos, la conexin SSH por el puerto 4422 se abrir para la mquina cliente.

[port-knocking-ssh_3.png]

Figura 8:  Intento de conexin SSH usando telnet con la secuencia correcta de Port Knocking.

Opcin 3: usando Nmap con Port Knocking

Otra forma de realizar port knocking es hacer uso de la herramienta de escaneo de puertos Nmap. Con el parmetro -sS podemos enviar hacia el servidor paquetes con flag "TCP SYN". Concatenando la secuencia de comandos correcta podemos lanzar este tipo de paquetes ejecutando as la regla que nos permite establecer conexin con el servidor SSH remoto.

sudo nmap -sS -p7500 10.0.0.22 ; nmap -sS -p8200 10.0.0.22 ; nmap -sS -p9800 10.0.0.22

[port-knocking-ssh_4.png]

Figura 9: Intento de conexin SSH usando Nmap con la secuencia correcta de Port Knocking.

Conclusiones

Aadir este mecanismo como mtodo de autenticacin SSH en servidores es una buena medida de seguridad por oscuridad. Si bien este proceso es divertido de implementar y verlo en accin, es posible que no sea factible implementarlo en entornos de produccin donde hay una gran cantidad de servidores SSH o si se necesita automatizar accesos SSH.

Considero que es una buena medida de seguridad a implementar solamente para aquellos servidores realmente crticos y que tengan una cierta exposicin externa en los que dado su diseo de arquitectura subyacente de red no permita ser protegido en capas anteriores con un firewall o DMZ. Incluso podramos aadir una segunda capa de proteccin como sera la implementacin de un segundo factor de autenticacin 2FA en conexiones SSH.

Saludos!