Binary Trail

Máquina de tipo respuesta a incidentes (IR) / análisis forense, no de explotación clásica: el propio enunciado entrega acceso root directo para simular a un analista que ya está dentro del servidor comprometido y debe reconstruir qué hizo un binario sospechoso.

Máquina: The Hackers Labs — Binary Trail SO: Ubuntu 24.04.1 LTS, kernel 6.8.0-51-generic Vector de entrada: Ninguno que explotar — acceso root/toor entregado por el enunciado (simulación de un equipo de respuesta a incidentes ya con acceso) Escalada de privilegios: No aplica (se entra directo como root) Objetivo real: Análisis forense de un binario (auth_proxy) hallado en un directorio no estándar (/opt), usando solo comandos básicos de Linux (sin herramientas avanzadas), tal como pide el propio enunciado Herramientas principales: nmap (descubrimiento de puertos), ssh/sshpass (acceso remoto), stat (permisos/metadatos de fichero), strings (extraer texto legible de un binario compilado), grep (búsqueda de rastros en logs)

Resumen de acceso y hallazgos

Cuestionario final — resultado

Glosario rápido

• IR (Incident Response) / DFIR: disciplina de responder a un incidente de seguridad ya ocurrido — identificar qué pasó, cómo, y qué impacto tuvo, en vez de intentar entrar desde fuera como en un pentest clásico.
• ELF (Executable and Linkable Format): formato estándar de los ejecutables en Linux. file y strings sirven para inspeccionarlo sin ejecutarlo.
• strings: extrae del binario todas las secuencias de texto legible (cadenas embebidas, nombres de funciones de librerías enlazadas, mensajes). No “descompila” el programa, pero suele revelar mucho de qué hace.
• system(): función de C que lanza un comando de shell desde dentro de un programa compilado. Es la forma en que un binario “normal” en apariencia puede ejecutar cualquier comando del sistema.
• Fichero oculto (dotfile): en Linux, cualquier archivo cuyo nombre empieza por . no aparece en un ls normal (hace falta ls -a). Es una técnica común para esconder artefactos a simple vista, no una protección real.
• logger: utilidad de línea de comandos de Linux que manda un mensaje a los logs del sistema (syslog) con una etiqueta (-t) elegida libremente por quien lo ejecuta — por eso un log puede decir “vino de tal proceso” sin que ese proceso lo haya escrito de verdad.
• auth.log: en Debian/Ubuntu, el log donde rsyslog registra todo lo relacionado con autenticación y con cualquier proceso que use syslog/logger bajo esa facilidad (auth/authpriv): logins SSH, uso de sudo, y en este caso también los mensajes que dejó auth_proxy.

Herramientas necesarias

• nmap: escáner de puertos; confirma qué servicios están expuestos antes de conectarse a nada.
• ssh / sshpass: cliente SSH y una utilidad para pasarle la contraseña sin que pida escribirla a mano, útil para automatizar comandos remotos.
• stat: muestra los metadatos completos de un fichero (permisos en octal, propietario, fechas de creación/modificación/acceso) — necesario para responder con el número exacto de permisos.
• strings: lista el texto legible embebido en un binario; permite intuir qué hace un programa sin necesidad de un desensamblador.
• grep: búsqueda de texto; con -a fuerza a tratar un archivo como texto aunque el sistema lo detecte como binario (útil porque algunos logs de journald/rsyslog en formato moderno no son ASCII puro), y con -n/-l da número de línea / solo el nombre del fichero que coincide.

Fase 0 — Preparación del laboratorio

Se descargó el .zip oficial de TheHackersLabs y se extrajo:

unzip "TheHackersLabs - Binary Trail.zip"
# → TheHackersLabs - Binary Trail.ova  (2.2 GB, disco de 25 GB)
# → TheHackersLabs - Binary Trail.pdf (enunciado)

El PDF del enunciado es la pieza clave que cambia el enfoque de esta máquina respecto a las anteriores del laboratorio: en vez de pedir explotarla desde fuera, plantea un escenario ya post-compromiso y entrega las credenciales directamente:

“Un servidor Linux crítico […] se ha identificado la presencia de un binario desconocido ubicado en un directorio no estándar […] Evita confiar en herramientas avanzadas; utiliza únicamente las capacidades básicas disponibles en un entorno estándar de Linux […] Login: root / toor”

Import y arranque, igual que el resto del laboratorio (Bridged por defecto → se fuerza a host-only):

VBoxManage import "TheHackersLabs - Binary Trail.ova" --dry-run   # vista previa: Ubuntu_64, 2 CPUs, 2048 MB
VBoxManage import "TheHackersLabs - Binary Trail.ova"
VBoxManage modifyvm "TheHackersLabs - Binary Trail" --nic1 hostonly --hostonlyadapter1 vboxnet0
VBoxManage startvm "TheHackersLabs - Binary Trail" --type headless

Para reproducir desde cero, con la VM apagada:

VBoxManage controlvm "TheHackersLabs - Binary Trail" poweroff
VBoxManage startvm "TheHackersLabs - Binary Trail" --type headless

Fase 1 — Reconocimiento de red

Se descubre la IP asignada por DHCP en la red host-only comparando la MAC de la VM con lo que responde arp-scan:

arp-scan --interface=vboxnet0 --localnet
# 192.168.56.106  08:00:27:be:db:de   ← coincide con la MAC de la NIC de Binary Trail

Escaneo completo de puertos TCP:

nmap -sC -sV -p- --min-rate 2000 -oN loot/nmap-tcp-full.txt 192.168.56.106

Resultado: un único puerto abierto.

22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.5

Lectura: no hay web, ni FTP, ni ningún otro servicio que dé pie a un vector de entrada externo. Esto, sumado a que el propio PDF ya entrega credenciales, confirma que el reto no es “cómo entrar” sino “qué encuentras una vez dentro”.

Fase 2 — Acceso inicial

Se usa directamente la credencial del enunciado:

sshpass -p 'toor' ssh [email protected] "id; hostname; uname -a"

uid=0(root) gid=0(root) groups=0(root)
oscar
Linux oscar 6.8.0-51-generic #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec 5 13:09:44 UTC 2024 x86_64

El hostname es oscar — el mismo nombre del creador que ya aparecía en la máquina El Topo DNS ([+] Creador: Oscar en su pantalla de login), confirmando que es del mismo autor dentro del laboratorio.

Nota honesta: antes de asumir que el enunciado era la única vía, se comprobó explícitamente que no hubiera una cadena de explotación alternativa (una descripción previa mencionaba esteganografía + cracking de hash + un fichero Office + fuerza bruta SSH). Se buscó evidencia de cada paso directamente en el sistema:

find / -xdev \( -iname '*.jpg' -o -iname '*.png' -o -iname '*.bmp' \) 2>/dev/null   # solo iconos estándar de Ubuntu
find / -xdev \( -iname '*.docx' -o -iname '*.zip' -o -iname '*.odt' \) 2>/dev/null  # nada del escenario
grep -vE '/nologin|/false' /etc/passwd                                              # solo root y sync — nunca hubo "3 usuarios"
grep -na 'Failed password' /var/log/auth.log.1                                      # cero resultados, no hubo fuerza bruta
grep -na 'Accepted password' /var/log/auth.log.1                                    # solo accesos de "root", sin otro usuario

Ningún rastro de esa cadena existe en esta build de la máquina (descargada dic-2024). Se documenta esta comprobación en vez de omitirla: esa descripción de 5 pasos corresponde a otro escenario o a otra versión, no a la VM real que se analizó aquí.

Fase 3 — Análisis forense del binario sospechoso

3.1 — Localizar el binario y su directorio “no estándar”

El enunciado dice que el binario está en “un directorio no estándar”. En Linux, /opt es precisamente el directorio pensado para software de terceros instalado manualmente (no gestionado por el paquete del sistema como sí lo son /usr/bin o /usr/sbin) — un lugar habitual para que algo fuera de lugar pase desapercibido:

ls -la /opt/

-rwxr-xr-x 1 root root 16008 dic 21  2024 /opt/auth_proxy
drwxr-xr-x 2 root root  4096 dic 21  2024 /opt/lab/

Pregunta 1 → nombre del binario sospechoso: auth_proxy.

3.2 — Función principal del binario

Junto al binario hay un directorio /opt/lab/ con su código fuente en C — un lujo que no se tiene en un incidente real (normalmente solo queda el binario compilado), pero que aquí sirve para verificar con certeza lo que hace, en vez de solo inferirlo:

cat /opt/lab/auth_proxy.c

#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("Running auth_proxy...\n");
    system("touch /etc/.shadow_auth");
    return 0;
}

Se confirma que el binario compilado coincide con ese código usando strings (lista las cadenas de texto legible embebidas en el ejecutable, sin necesidad de ejecutarlo ni desensamblarlo):

strings /opt/auth_proxy | grep -E "Running|touch"

Running auth_proxy...
touch /etc/.shadow_auth

Función principal: el binario no hace nada relacionado con autenticación real pese a su nombre (“proxy de autenticación”) — es un nombre señuelo. Su única acción es imprimir un mensaje y, mediante system(), lanzar el comando de shell touch /etc/.shadow_auth, que crea (o actualiza la fecha de) un fichero vacío oculto en /etc.

3.3 — Fichero oculto y sus permisos

stat /etc/.shadow_auth
cat /etc/.shadow_auth

  File: /etc/.shadow_auth
  Access: (0600/-rw-------)  Uid: (0/root)  Gid: (0/root)
  Birth: 2024-12-21 09:16:29
Archivo creado por auth_proxy para pruebas internas.

El nombre .shadow_auth es otro señuelo: imita al fichero real /etc/shadow (donde Linux guarda las contraseñas hasheadas) para que, a simple vista en un listado largo de /etc, un analista distraído lo confunda con algo del propio sistema operativo y no lo investigue. Los permisos 0600 (lectura/escritura solo para el propietario, aquí root) coinciden con los que normalmente tendría un fichero sensible legítimo — otro motivo por el que pasa desapercibido.

• Pregunta 2 → fichero que oculta: /etc/.shadow_auth.
• Pregunta 5 → permisos numéricos: 600.

3.4 — Rastros en los logs del sistema

El código fuente no llama a ninguna función de log (syslog, openlog) — solo a printf y system(). Sin embargo, al buscar el nombre del binario en los logs del sistema aparece igualmente:

grep -rl 'auth_proxy' /var/log

/var/log/auth.log.1

grep -na 'auth_proxy\|shadow_auth' /var/log/auth.log.1

137:Dec 21 10:32:45 server auth_proxy: touch /etc/.shadow_auth
138:Dec 21 10:32:45 server auth_proxy: Probando creación de archivos ocultos
171:Dec 21 10:32:45 server auth_proxy: touch /etc/.shadow_auth
172:Dec 21 10:32:45 server auth_proxy: Probando creación de archivos ocultos
197:Dec 21 10:32:45 server auth_proxy: touch /etc/.shadow_auth
198:Dec 21 10:32:45 server auth_proxy: Probando creación de archivos ocultos

Detalle importante para el análisis (no cambia la respuesta, pero sí la interpretación): como el binario en sí no tiene código de logging, estas líneas no las escribió el programa al ejecutarse — las generó alguien (el atacante, o quien preparó la prueba) a mano con la utilidad logger, que permite mandar un mensaje a syslog con cualquier etiqueta de origen que se quiera (logger -t auth_proxy "touch /etc/.shadow_auth"). Es decir, el propio rastro en los logs pudo ser fabricado para simular que el binario reporta su actividad — una lección de análisis forense real: un log puede mentir sobre su origen si el atacante tiene permisos para escribir en syslog.

• Pregunta 3 → comando que dejó rastros: touch /etc/.shadow_auth.
• Pregunta 4 → archivo de logs: /var/log/auth.log.1.

3.5 — Cómo llegó al servidor

Se revisó el resto de auth.log.1 en busca de vectores de entrada:

grep -na 'Accepted password\|Invalid user\|Failed password' /var/log/auth.log.1

96:  Accepted password for root from 192.168.1.112 port 46082 ssh2
168: Accepted password for root from 192.168.1.112 port 35360 ssh2
194: Accepted password for root from 192.168.1.112 port 52522 ssh2

No hay ningún Failed password ni usuario distinto de root — solo tres sesiones SSH exitosas ya como root, desde la misma IP (192.168.1.112, la máquina de quien preparó/probó el laboratorio). No hay evidencia de que el binario haya llegado por un exploit remoto; todo indica que fue colocado manualmente por quien tenía ya acceso root (coherente con /opt/lab/auth_proxy.c estando ahí mismo, como si fuera el entorno donde se compiló in situ) para simular un artefacto sospechoso a analizar, no un ataque real en curso.

Diagrama resumen

             /opt/lab/auth_proxy.c  --gcc-->  /opt/auth_proxy (ELF, 16008 B)
                                                      |
                                          system("touch /etc/.shadow_auth")
                                                      |
                                                      v
                                    /etc/.shadow_auth (0600, root:root)
                                    "Archivo creado por auth_proxy para pruebas internas."

  alguien con acceso ya root ejecuta 3 veces auth_proxy
                                                      |
                                                      v
                     logger -t auth_proxy "touch /etc/.shadow_auth"          } rastro fabricado,
                     logger -t auth_proxy "Probando creación de..."          } no generado por el binario
                                                      |
                                                      v
                                        /var/log/auth.log.1 (líneas 137-198)

Causas raíz y mitigación

«El hombre es una criatura que se acostumbra a todo, y creo que esa es la mejor definición que se puede dar de él.»
— Fiódor Dostoyevski, Memorias de la casa muerta