Hack the box Sherlocks: Knock Knock

¡Hola de nuevo!

En esta ocasión vamos a resolver un reto de la plataforma Hack The Box. Hack The Box dispone de retos o capture the flag con un enfoque Blue Team denominados como Sherlocks.

Nombre: Knock Knock

Dificultad: Media

Enlace al reto: https://app.hackthebox.com/sherlocks/Knock%20Knock

Descripción: como DFIR tienes que responder a un incidente de seguridad en la organización Forela. Un servidor crucial de la compañía ha sido víctima de un ciberataque. Este incidente ocurre en un momento crítico para la empresa ya que está expandiendo su negocio en Pakistán, bajo el liderazgo del desarrollador senior Abdullah. A pesar de que supuestamente se dispone de políticas de bastionado estrictas este fue expuesto por error a Internet, creando una puerta para el actor de la amenaza. La organización te ofrece una captura de paquetes de red alrededor del momento del incidente (1-2) días porque no sabe exactamente cuándo obtuvo acceso el atacante. El objetivo: analizar cómo y cuándo se produjo el ataque y qué hizo el atacante.

Importante: no se responde a las preguntas de forma numerada tal y como plantea HTB la resolución. Lo que tratamos es de trasladar al lector un enfoque basado en una metodología de investigación tal y como se haría en una situación real de ataque. No obstante, las respuestas están marcadas en negrita a lo largo del artículo.

Análisis y resolución

Ya que solo disponemos de una captura de red y ningún hilo del que tirar para comenzar la investigación debemos plantear hipótesis y buscar comportamientos sospechosos. Para mí claramente lo primero que se me viene a la cabeza es intentar ponerme en la perspectiva del atacante. Una de las primeras fases a la hora de realizar un ataque es la de reconocimiento.

Protocolo TCP

Antes de nada es importante conocer como funciona el protocolo TCP. En concreto, el Handshake. Se trata de un proceso fundamental en el protocolo de comunicación TCP/IP que establece una conexión fiable entre dos dispositivos en una red. Este proceso garantiza que ambos dispositivos están preparados para intercambiar datos y que la conexión es válida y segura. El handshake de TCP se realiza en tres pasos conocidos como el three-way handshake o apretón de manos en tres pasos. A continuación, se detallan estos pasos:

1. SYN (Synchronize): El cliente envía un segmento TCP con el bit de sincronización (SYN) activado a la dirección IP del servidor para iniciar una conexión. Este segmento incluye un número de secuencia inicial (ISN, Initial Sequence Number), que es un valor aleatorio.
2. SYN-ACK (Synchronize-Acknowledge): El servidor recibe el segmento SYN del cliente, lo reconoce enviando de vuelta un segmento que tiene tanto el bit SYN como el bit ACK (Acknowledgment) activados. El servidor también incluye su propio número de secuencia inicial en el segmento y un número de acuse de recibo que es el ISN del cliente más uno (ISN+1).
3. ACK (Acknowledge): El cliente recibe el segmento SYN-ACK del servidor y responde con un segmento que tiene el bit ACK activado. Este segmento contiene un número de acuse de recibo que es el ISN del servidor más uno (ISN+1), confirmando así que el cliente ha recibido y reconocido el SYN del servidor.

Hipótesis inicial

Durante la fase de reconocimiento se suelen realizar escaneos de red sobre la infraestructura expuesta de una organización. Por norma general, los escaneos se realizan sobre el protocolo TCP. Existen múltiples tipos de técnicas de escaneos de red pero las más comunes son las que envían paquetes SYN contra los puertos de los servidores esperando recibir una respuesta SYN/ACK. Si reciben una respuesta SYN/ACK quiere decir que el puerto esta abierto. Existen varias herramientas para realizar escaneos de red pero la más conocida y comúnmente utilizada es Nmap. Os dejo por aquí una referencia a la documentación donde podréis informaros de los diferentes tipos de escaneo de red: tipos de escaneo de red.

Teniendo en cuenta esto, hay que hacer uso de una herramienta de análisis de paquetes de red. En este caso, vamos a usar Wireshark. Ante de nada vamos a configurar la vista de timestamp a formato fecha y hora (UTC). En respuesta ante incidentes y forense siempre UTC por favor 😆.

Con Wireshark podemos obtener la traza completa de comunicaciones realizadas entre los dispositivos a lo largo de toda la captura de red. Para ello, hay que hacer clic sobre:

Sobre la ventana que muestra la estadística de conversaciones hay que hacer clic sobre «TCP» y ordenar por puerto «B» (destino) de manera ascendente:

Si nos fijamos bien ya se puede visualizar claramente como la IP 3[.]109[.]209[.]43 envía paquetes contra diferentes puertos de la IP interna 172.31.39.46. Se puede ver como va puerto por puerto de manera incremental con un intercambio de paquetes mínimo (2 paquetes) tal y como se produce en un escaneo de puertos normalmente.

Hasta aquí podemos afirmar que la IP del atacante es la 3[.]109[.]209[.]43 y que la IP interna del servidor afectado de Forela es 172.31.39.46.

Investigación puertos abiertos

Vamos a continuar tirando del hilo. Para ello hay que descubrir que puertos se ha encontrado abiertos el atacante. Basándonos en la comunicación TCP, todo puerto abierto en caso de ser contactado debería teóricamente de responder con «SYN/ACK» tal y como hemos visto anteriormente. Hay que filtrar en Wireshark por este criterio con origen la IP del servidor y destino la IP del atacante:

ip.src == 172.31.39.46 && tcp.flags.syn == 1 && tcp.flags.ack == 1 && ip.dst == 3.109.209.43

Consultando de nuevo el apartado estadísticas de conversaciones con el filtro aplicado se pueden visualizar los puertos abiertos. Voy a exportar el resultado a CSV para poder trabajar sobre los datos.

Tras filtrar por puertos destino (Port B) y eliminar duplicados se obtiene un listado de un total de 43 puertos abiertos.

En este punto es donde os tengo que indicar que el CTF no admite como respuesta 43 puertos (aunque teóricamente si que lo son). En concreto, los puertos abiertos para la respuesta son: 21,22,3306,6379,8086.

Timestamp del inicio del ataque

Filtrando por la IP del atacante como origen y la IP del servidor como destino se puede observar que el inicio del ataque fue el día 21/03/2023 10:42:23. Es el primer paquete intercambiado.

Añadiendo al filtro los puertos abiertos:

ip.src ==  3.109.209.43 && ip.dst == 172.31.39.46 && ((tcp.dstport == 21 || tcp.dstport == 22 || tcp.dstport == 3306 || tcp.dstport == 6379 || tcp.dstport == 8086))

Llama la atención la gran cantidad de comunicaciones contra el puerto 21 con respecto al resto. Además, filtrando por bytes de mayor a menor también resalta que ha habido más información intercambiada:

Filtrando únicamente por puerto 21 como destino:

ip.src ==  3.109.209.43 && ip.dst == 172.31.39.46 && ((tcp.dstport == 21))

Acceso inicial

Se puede ver como el atacante hace uso de la técnica de fuerza bruta de credenciales T1110.003: «Password Spraying». Esta técnica consiste en utilizar una lista de contraseñas contra diferentes posibles cuentas de una organización con el objetivo de obtener un acceso válido.

Observando los intentos de acceso, se puede ver claramente como el atacante obtiene acceso correcto con un usuario y contraseña concretos. Para ello, hacer uso del filtro:

ip.src == 3.109.209.43 && ip.dst == 172.31.39.46 && ((tcp.dstport == 21)) && ftp

Llegado a cierto punto se identifica perfectamente como el intento de fuerza bruta tiene fin y comienza el input de comandos FTP. Esto indica que el atacante ha obtenido acceso.

Haciendo clic derecho sobre el último intento de acceso con contraseña y seleccionando «Follow –> TCP Stream» se puede visualizar la traza completa de paquetes en esa comunicación TCP:

Efectivamente, el atacante inicio sesión correctamente:

Análisis comunicación FTP expuesto

De la traza completa de la comunicación FTP se puede observar:

SYST

• Comando: SYST
• Respuesta: 215 UNIX Type: L8
• Descripción: El cliente solicita información sobre el sistema operativo del servidor. El servidor responde indicando que es un sistema UNIX.

FEAT

• Comando: FEAT
• Respuesta: 211-Features: EPRT EPSV MDTM PASV REST STREAM SIZE TVFS 211 End
• Descripción: El cliente solicita una lista de características soportadas por el servidor. El servidor proporciona una lista de características disponibles, como EPRT, EPSV, MDTM, etc.

EPSV

• Comando: EPSV
• Respuesta: 229 Entering Extended Passive Mode (|||53637|)
• Descripción: El cliente solicita al servidor que entre en modo pasivo extendido para la transferencia de datos. El servidor responde indicando que ha entrado en modo pasivo extendido en el puerto 53637.

LIST -la

• Comando: LIST -la
• Respuesta: 150 Here comes the directory listing. 226 Directory send OK.
• Descripción: El cliente solicita una lista detallada de los archivos y directorios. El servidor confirma que está enviando la lista y luego confirma que la transferencia ha sido exitosa.

EPSV

• Comando: EPSV
• Respuesta: 229 Entering Extended Passive Mode (|||7831|)
• Descripción: El cliente vuelve a solicitar el modo pasivo extendido para otra transferencia de datos, esta vez en el puerto 7831.

NLST

• Comando: NLST
• Respuesta: 150 Here comes the directory listing. 226 Directory send OK.
• Descripción: El cliente solicita una lista de nombres de archivos en el directorio actual. El servidor responde con éxito enviando la lista.

TYPE I

• Comando: TYPE I
• Respuesta: 200 Switching to Binary mode.
• Descripción: El cliente solicita cambiar al modo de transferencia binaria. El servidor confirma el cambio.

SIZE .backup

• Comando: SIZE .backup
• Respuesta: 213 265
• Descripción: El cliente solicita el tamaño del archivo .backup. El servidor responde que el tamaño es 265 bytes.

EPSV

• Comando: EPSV
• Respuesta: 229 Entering Extended Passive Mode (|||11365|)
• Descripción: El cliente solicita el modo pasivo extendido para la transferencia del archivo .backup, en el puerto 11365.

RETR .backup

• Comando: RETR .backup
• Respuesta: 150 Opening BINARY mode data connection for .backup (265 bytes). 226 Transfer complete.
• Descripción: El cliente solicita descargar el archivo .backup. El servidor confirma la apertura de la conexión de datos y luego la transferencia exitosa.

MDTM .backup

• Comando: MDTM .backup
• Respuesta: 213 20230321102655
• Descripción: El cliente solicita la fecha de modificación del archivo .backup. El servidor responde con la fecha y hora en formato YYYYMMDDHHMMSS.

SIZE fetch.sh

• Comando: SIZE fetch.sh
• Respuesta: 213 356
• Descripción: El cliente solicita el tamaño del archivo fetch.sh. El servidor responde que el tamaño es 356 bytes.

EPSV

• Comando: EPSV
• Respuesta: 229 Entering Extended Passive Mode (|||63669|)
• Descripción: El cliente solicita el modo pasivo extendido para la transferencia del archivo fetch.sh, en el puerto 63669.

RETR fetch.sh

• Comando: RETR fetch.sh
• Respuesta: 150 Opening BINARY mode data connection for fetch.sh (356 bytes). 226 Transfer complete.
• Descripción: El cliente solicita descargar el archivo fetch.sh. El servidor confirma la apertura de la conexión de datos y luego la transferencia exitosa.

MDTM fetch.sh

• Comando: MDTM fetch.sh
• Respuesta: 213 20230317121434
• Descripción: El cliente solicita la fecha de modificación del archivo fetch.sh. El servidor responde con la fecha y hora en formato YYYYMMDDHHMMSS.

QUIT

• Comando: QUIT
• Respuesta: 221 Goodbye.
• Descripción: El cliente finaliza la sesión FTP. El servidor responde confirmando la terminación de la sesión.

El atacante ha obtenido dos ficheros del servidor:

• .backup
• fetch.sh

Para ver el contenido de los ficheros hay que obtenerlos con los siguientes pasos:

Fichero .backup

El contenido del fichero es el siguiente:

La verdad que al analizar su contenido no sabía exactamente lo que era. A simple vista, se puede observar que se trata de la configuración de una herramienta o servicio en la que se hace mención a un servicio FTP interno y credenciales a un servidor de .backup.

Port Knocking

Buscando información por internet encontré que se trata de una configuración asociada a una herramienta llamada knockd. Esta herramienta permite hacer uso de la técnica Port Knocking. Es un método de control de acceso a redes que consiste en enviar una serie específica de conexiones a puertos cerrados en una secuencia predefinida. Solo después de recibir la secuencia correcta, el servidor configurado abre un puerto o una serie de puertos para permitir la conexión del cliente. Esta técnica es utilizada para mejorar la seguridad, ya que oculta la existencia de servicios y dificulta los intentos de escaneo de puertos por parte de atacantes.

Por lo que entendiendo el contenido del fichero:

sequence: 29999,50234,45087

• Descripción: Esta es la secuencia específica de puertos que el cliente debe «golpear» en el orden exacto para activar el comando asociado.

seq_timeout: 5

• Descripción: El tiempo máximo (en segundos) permitido para completar la secuencia de golpes. Si la secuencia completa no se recibe dentro de este tiempo, se descarta.

command: /sbin/iptables -I INPUT -s %IP% -p tcp --dport 24456 -j ACCEPT

• Descripción: El comando que se ejecutará cuando la secuencia correcta se reciba. En este caso, se agrega una regla a iptables para permitir el tráfico TCP desde la dirección IP que envió la secuencia correcta (%IP%) hacia el puerto 24456.
• Desglose del comando:
  • /sbin/iptables -I INPUT: Inserta una nueva regla en la cadena INPUT de iptables.
  • -s %IP%: Especifica la dirección IP de origen que envió la secuencia correcta.
  • -p tcp --dport 24456: Especifica que la regla se aplica al tráfico TCP dirigido al puerto 24456.
  • -j ACCEPT: Indica que el tráfico coincidente debe ser aceptado.

tcpflags: syn

• Descripción: Especifica que knockd debe considerar solo los paquetes TCP con el flag SYN establecido. Esto asegura que solo las conexiones de inicio se consideren para el port knocking.

Es decir, el atacante ha obtenido acceso a esta información y probablemente haya ejecutado la secuencia de puertos para establecer posteriormente conexión contra el servicio FTP interno.

Vamos a verlo con Wireshark con el siguiente filtro:

ip.src == 3.109.209.43 && ip.dst == 172.31.39.46 && ((tcp.dstport == 29999 || tcp.dstport == 50234 || tcp.dstport == 45087 || tcp.dstport == 24456))

Efectivamente, el servidor le responde al atacante y se produce conexión completa contra el puerto 24456 ya que existe un «FIN, ACK» TCP. Ejecuta la secuencia completa estableciendo contacto contra los puertos 29999, 50234 y finalmente a las 21/03/2023 10:58:50 UTC contra 45087. Es decir, el atacante como mínimo a contactado contra el servicio FTP interno del servidor.

Análisis comunicación FTP interno

El atacante ha contactado contra el servicio FTP interno y hay que analizar que actividad ha realizado. Para ello, aplicamos el filtro de Wireshark apuntando al puerto del servicio 24456:

ip.src == 3.109.209.43 && ip.dst == 172.31.39.46 && ((tcp.dstport == 24456))

De nuevo, sobre el primer paquete hacemos uso de la opción «Follow –> TCP Stream» para ver la trama completa de la comunicación. Lo que se puede ver es lo siguiente inicialmente:

Parece que el atacante ha probado las credenciales registradas sobre el fichero .backup y se ha autenticado correctamente el día 21/03/2023 11:00:01 UTC (haciendo clic sobre «230 Login successful» te indica la trama correspondiente):

• Credenciales: abdullah.yasin:XhlhGame_90HJLDASxfd&hoooad (son las credenciales del servicio FTP interno del desarrollador senior Abdullah)

Fichero .archived.sql

Se puede observar que durante la comunicación se solicita la descarga del fichero «.archived.sql». Aplicando el filtro:

(ip.src == 3.109.209.43 && ip.dst == 172.31.39.46) || (ip.src == 172.31.39.46 && ip.dst == 3.109.209.43)

Hay que dirigirse a la trama 211114. Se trata de la conexión que abre el servidor con el atacante para hacerle entrega del fichero. Observando la traza con «Follow» –> «TCP stream» se identifica el código de la base de datos. La base de datos tiene como nombre «AWS_SECRETS» y crea una tabla llamada «AWS_EC2_DEV» cuya estructura contiene los datos de nombres de usuario, ID de usuario y contraseña de AWS.

Se identifican las credenciales del desarrollador senior Abdullah de un servidor EC2 de desarrollo de AWS:

• ID Usuario: 391629733297
• Contraseña: yiobkod0986Y[adij@IKBDS

Continuando la revisión de toda la comunicación completa se identifican los siguientes aspectos clave:

• El atacante es capaz de acceder a directorios críticos del sistema, realizar enumeración y descubrimiento de información
• El atacante solicita la transferencias de los siguientes ficheros:
  • «Tasks to get Done.docx»
  • reminder.txt
  • .reminder
  • /etc/passwd

Parece interesante saber que información contienen estos ficheros ya que el atacante ha podido obtenerlos. Posicionándonos sobre algunas tramas se puede ver el contenido interno de los ficheros. No obstante, en el caso de los binarios vamos a toparnos con contenido ilegible. Ya que Wireshark no detecta este tráfico como trama FTP habrá que obtener los binarios de una manera un poco distinta a la que hemos usado anteriormente con los ficheros fetch.sh y .backup.

Fichero Tasks to get Done.docx

Este problema lo enfrentamos con el fichero «Tasks to get Done.docx». Para obtenerlo hay que posicionarse sobre la trama 211158. Hacer clic derecho y «Follow TCP Stream»:

Hay que transformar los datos de la comunicación a formato «Raw» y guardar el resultado con el nombre del fichero.

Al abrirlo, podemos observar una gráfica de deadline de tareas a llevar a cabo:

La fecha límite para encontrar 20 desarrolladores para Forela es el 30/08/2023.

Fichero /etc/passwd

Posicionándonos sobre la trama 211273 se puede observar su contenido:

El atacante ha obtenido información sobre usuarios del sistema. Entre ellos, llaman la atención los que disponen de shell predefinida como:

• abdullah.yasin:/bin/sh
• tony.shephard:/bin/sh
• ubuntu:/bin/bash
• cyberjunkie:/bin/bash

Fichero reminder.txt

El contenido del fichero informa al atacante de que el CEO de Forela va a realizar una visita a Pakistan el día 08/03/2023. Este tipo de información que puede llegar a parecer poco relevante de cara a que el atacante escale el ataque a nivel técnico sobre la infraestructura es realmente importante. Hay que recordar que normalmente el principal objetivo de los cibercriminales es lucrarse económicamente. Información de este tipo puede ser utilizada por ejemplo para llevar a cabo estafas al CEO, BEC Email, etc. Así que cuidadito. Si quieres saber más sobre phishing y correos maliciosos te recomiendo la serie de artículos de Phishing con Gophish del blog.

Fichero .reminder

Este fichero se encuentra en la ruta /opt/reminders/.reminder. El contenido de este informa al atacante de que Forela puede disponer de un repositorio Git con información confidencial:

Realizando una búsqueda básica OSINT por Google encuentro un repositorio con nombre «Forela-dev». Mala pinta tiene esto 😌 .

Buceando un poco sobre el repositorio doy con un fichero llamado internal-dev.yaml. Aparentemente no contiene ningún tipo de información confidencial. El problema se agrava cuando reviso el historial de commits del fichero. Se pueden visualizar claramente las credenciales de un servicio SSH con nombre de usuario «cyberjunkie». La password es: YHUIhnollouhdnoamjndlyvbl398782bapd

El usuario cyberjunkie es parte de los usuarios del sistema del servidor de Forela.

Análisis comunicación SSH expuesto

Aplicando el siguiente filtro se puede observar como el atacante inicia una sesión por SSH contra el servidor el día 21/03/2023 a las 11:25. Instantes después de cerrar la comunicación por FTP.

((ip.src == 3.109.209.43 && ip.dst == 172.31.39.46) || (ip.src == 172.31.39.46 && ip.dst == 3.109.209.43)) && ssh

Teniendo en cuenta que el atacante ya ha llegado al sistema con credenciales válidas y ha obtenido un shell interactiva podemos afirmar que se encuentra en la fase de instalación de la kill chain. Es decir, uno de sus objetivos podría ser dropear o descargar malware en el sistema objetivo. Normalmente esto lo suelen hacer realizando peticiones HTTP contra servidores para descargarlo con herramientas legítimas.

De hecho, aplicando el siguiente filtro se puede observar la descarga de un recurso muy sospechoso de la IP 13[.]233[.]179[.]35 con nombre Ransomware2_Server.zip.

ip.src == 172.31.39.46 && http

IOC (URL): http://13[.]233[.]179[.]35/PKCampaign/Targets/Forela/Ransomware2_Server.zip

Realizando «Follow HTTP Stream» observamos como el atacante ha hecho uso de la herramienta wget/1.21.2 en el servidor para dropear el ransomware.

Tras obtener el fichero a través de Wireshark y acceder a su contenido se puede confirmar que el atacante ha dropeado el malware «Gonnacry«. Enlace.

Conclusiones del incidente

Es muy importante poder construir una historia completa final del incidente tras realizar los análisis. De hecho, es recomendable ir documentando los análisis conforme vamos avanzando en la investigación e ir comprendiendo y construyendo la historia. Esto nos ahorrará mucho tiempo realizando análisis como pollos sin cabeza y centrar nuestros esfuerzos.

Resumen del incidente

El atacante inició un reconocimiento de red de la organización Forela. En esta etapa de enumeración encontró un servidor con diversos servicios expuestos a internet. Entre todos estos, utilizó la técnica de password spraying sobre el servicio FTP (puerto 21) que resulto teniendo éxito. Con acceso exitoso sobre el servicio FTP, comenzó a enumerar algunos directorios del sistema sobre los que tenía visibilidad. A raíz de dicha enumeración terminó encontrando un fichero de configuración del servicio knockd que contenía además credenciales del desarrollador de Forela Abdullah Yasin.

Desde ese momento el atacante sabe que se hace uso de Port Knocking en el servidor y ejecuta la secuencia de comunicación de puertos con la intención de provocar la apertura del puerto del servicio interno FTP asociado. Tras realizar la secuencia se comunica con éxito con el servicio FTP interno y hace uso de las credenciales de Abdullah encontradas anteriormente. Esto le autentica correctamente en el servicio del servidor.

El servicio FTP interno le ofrece la posibilidad de recorrer y enumerar sin problema gran parte de los recursos del sistema. Esto provoca que el atacante encuentre información confidencial como:

• Credenciales de autenticación del desarrollador Abdullah asociadas a un servidor EC2 de desarrollo de AWS.
• Información acerca de un repositorio de código de Forela.
• Información sobre procesos empresariales de Forela.
• Datos sobre usuarios internos del sistema.

De hecho, a raíz de encontrar información acerca de un repositorio de código de Forela, el atacante puede encontrar con técnicas OSINT credenciales válidas expuestas en Github de un servicio SSH del servidor. El atacante puede autenticar correctamente contra este servicio y descargar sobre el sistema de ficheros del servidor un fichero .zip cuyo contenido es un ransomware llamado «GonnaCry» orientado a sistemas Linux. Toda la actividad se produce el día 21/03/2023 desde las 10:42 UTC hasta las 11:42 UTC.

FIN.

Espero que te haya gustado ❤️.

¡Hasta la próxima!