Llevo más de una década metido en auditorías de seguridad, y si hay un área donde veo que las empresas, especialmente las pymes españolas del sector industrial y de servicios, están completamente ciegas, es en la seguridad de los dispositivos IoT que despliegan por miles. La realidad es que en 2026, con la explosión de la automatización y la Industria 4.0, un PLC, una cámara IP o un router industrial comprometido no es solo una molestia; es la puerta trasera perfecta hacia la red corporativa crítica. Y el núcleo de todo ese riesgo reside en el firmware. La mayoría de los equipos de seguridad se limitan a escanear la IP del dispositivo, ven un puerto 80 abierto y ya está, pero el problema gordo, el que realmente duele, está enterrado en el binario que ese aparato ejecuta desde su memoria flash. En mi experiencia, el 90% de las vulnerabilidades críticas en estos entornos no se descubren con un Nmap, sino con un análisis forense y de ingeniería inversa del firmware. Vamos al lío.
El proceso no es moco de pavo, pero es metodológico. Primero, tienes que conseguir el binario, lo que a veces es una batalla en sí misma. Luego, desempaquetarlo y extraer el sistema de archivos, que suele ser un rompecabezas de formatos propietarios. Finalmente, y aquí es donde está la chicha, analizar ese sistema de archivos en busca de secretos, configuraciones por defecto, binarios vulnerables y backdoors. Recuerdo un pentest del año pasado para una cadena hotelera que usaba un sistema centralizado de climatización y cerraduras "inteligentes". El fabricante, un proveedor asiático de bajo coste, no nos facilitaba el firmware bajo ningún concepto. Tuvimos que extraerlo físicamente del chip de memoria de un dispositivo de prueba. Lo que encontramos dentro, una clave SSH hardcodeada y común a todos los dispositivos de la marca a nivel mundial, justificó por sí sola todo el proyecto.
Cómo extraer firmware de dispositivos IoT: más allá de la descarga oficial
Lo ideal es siempre obtener el firmware desde el sitio web del fabricante. Parece obvio, pero en 2026 aún hay fabricantes que no lo publican, o lo publican en portales ocultos, o peor, solo lo distribuyen bajo petición con acuerdos de confidencialidad absurdos. Cuando no es posible, hay que ir a métodos más ofensivos. La extracción física es el gold standard. Esto implica abrir el dispositivo, identificar la memoria flash (normalmente un chip SPI NOR o NAND) y volcarla con un hardware como el Flashcat USB o un programaador CH341a. Es un proceso delicado pero que te da el binario exacto que está corriendo, incluyendo posibles modificaciones posteriores.
# Ejemplo de uso de flashrom con un programaador CH341a en Linux
# Primero, identificar el chip. Necesitas haber conectado el programaador al chip de memoria.
sudo flashrom --programmer ch341a_spi --detect
# Si detecta el chip (ej: MX25L6406E), proceder al volcado completo.
sudo flashrom --programmer ch341a_spi --chip MX25L6406E --read firmware_dump.bin
# Verificar que el volcado es correcto (sin errores de lectura)
sudo flashrom --programmer ch341a_spi --chip MX25L6406E --verify firmware_dump.bin
Si no puedes o no quieres abrir el dispositivo, la extracción por software es la siguiente opción. Muchos dispositivos tienen mecanismos de debug o puertos UART (esos cuatro pines que ves en la placa) que permiten acceder a una shell. Conectándote con un adaptador USB-to-TTL a 3.3V, a menudo puedes conseguir una terminal root. Desde ahí, puedes hacer un dd de la memoria MTD (Memory Technology Device). El problema que veo constantemente en auditorías es que los equipos no saben ni qué es un UART. Es una habilidad básica ya.
# Una vez en la shell del dispositivo (ej: a través de UART), identificar las particiones MTD.
cat /proc/mtd
# Deberías ver algo como: mtd0: 00080000 00010000 "u-boot"
# Para volcar la partición que contiene el sistema de archivos raíz (normalmente mtd2 o mtd3)
dd if=/dev/mtd2 of=/tmp/rootfs.bin
# Luego, transferir el archivo a tu estación de análisis via netcat o scp si hay red.
# En tu máquina: nc -lvp 4444 > rootfs.bin
# En el dispositivo: nc <TU_IP> 4444 < /tmp/rootfs.bin
Otra vía, a menudo infrautilizada, es explotar vulnerabilidades en el servidor web o en los servicios de gestión para lograr un RCE (Remote Code Execution) y luego volcar el firmware desde dentro. Esto es un pentest dentro del pentest, pero en un escenario real, un atacante no va a pedir el firmware amablemente.
Desempaquetar y extraer el sistema de archivos: el rompecabezas binario
Tienes el binario, un archivo de varios megabytes o incluso cientos de MB. Ahora, ¿qué diablos hay dentro? Los fabricantes usan formatos contenedores propietarios para empaquetar el bootloader, el kernel y el sistema de archivos raíz (rootfs). Herramientas como binwalk (en 2026 seguimos usando la versión 2.3.3 ampliamente) son tu mejor amigo. Pero ojo, binwalk no es magia. La mayoría de las veces necesitarás un enfoque manual.
La primera ejecución de binwalk firmware_dump.bin te dará una idea de los ficheros y sistemas de archivos embebidos. Busca firmas de sistemas de archivos comunes: Squashfs (muy común en routers), Cramfs, JFFS2, YAFFS2, o incluso un simple CPIO archive. El truco está en que muchas veces el firmware está comprimido (con LZMA, gzip) o encriptado (ligeramente, con XOR). En un análisis para un fabricante de cámaras de seguridad español en 2024, nos encontramos con que el rootfs estaba ofuscado con un XOR de un byte (0xAA). Era una "seguridad por ofuscación" ridícula que se rompía en segundos.
# Script Python simple para probar descifrado XOR cuando sospechas ofuscación.
# Guardar como xor_decrypt.py
import sys
def xor_decrypt(data, key):
return bytes([b ^ key for b in data])
if len(sys.argv) != 4:
print(f"Uso: {sys.argv[0]} <fichero_entrada> <fichero_salida> <key_hex>")
sys.exit(1)
with open(sys.argv[1], 'rb') as f:
encrypted = f.read()
key = int(sys.argv[3], 16)
decrypted = xor_decrypt(encrypted, key)
with open(sys.argv[2], 'wb') as f:
f.write(decrypted)
print(f"[+] Fichero descifrado con XOR key 0x{key:02x}. Ahora ejecuta 'file' y 'binwalk' sobre él.")
Una vez identificado y extraído el sistema de archivos (a veces binwalk -Me lo hace automáticamente, otras veces hay que hacer dd con los offsets manualmente), montas el rootfs. Aquí es donde empieza la verdadera caza. Montas la imagen Squashfs en tu Linux y tienes ante ti todo el sistema de archivos del dispositivo: los binarios de usuario, los scripts de inicio, las librerías compartidas y, lo más crítico, los ficheros de configuración.
Buscando vulnerabilidades en el rootfs: donde viven los demonios
Tener el rootfs es como tener las llaves del reino. Ahora la pregunta es: ¿Qué debes buscar exactamente para encontrar vulnerabilidades críticas? Esto no es un escaneo automatizado; es threat hunting a nivel de código y configuración. Sinceramente, la mayoría de las empresas españolas que audito no tienen ni el proceso ni las habilidades para esto, y se limitan a confiar en el fabricante, un error garrafal.
Lo primero, y más obvio, son las credenciales por defecto y hardcodeadas. Grep es tu dios aquí. Busca en todos los ficheros de texto, scripts, binarios e incluso dentro de los propios binarios (strings) palabras como password, pass, key, secret, admin. No te fíes de que estén en claro; a veces están en base64, un cifrado débil o, como en el caso que comenté, en MD5 sin salt. En 2026, aún encuentras admin:admin en dispositivos que controlan infraestructura crítica. Es desalentador.
# Comandos básicos para buscar secretos en un rootfs extraído y montado en /mnt/rootfs
cd /mnt/rootfs
# Buscar cadenas en todos los ficheros, incluyendo binarios
strings * 2>/dev/null | grep -i -E "(password|pass=|key=|secret=|token=)" | head -20
# Buscar en ficheros de configuración y scripts
find . -type f \( -name "*.sh" -o -name "*.conf" -o -name "*.cfg" -o -name "*.ini" \) -exec grep -l -i "password" {} \;
# Buscar hashes MD5, SHA1 o patrones de base64
find . -type f -exec grep -l -E '[0-9a-f]{32}' {} \; # MD5
find . -type f -exec grep -l -E '[0-9a-f]{40}' {} \; # SHA1
find . -type f -exec grep -l -E '^[A-Za-z0-9+/]+={0,2}$' {} \; # Posible base64
Lo segundo son los binarios vulnerables. El firmware suele contener versiones antiguas de servicios como busybox, dropbear (SSH), lighttpd o servicios propietarios escritos en C. Tienes que identificar cada binario, determinar su versión (con strings binario | grep -i version o binario --version) y cruzar esa información con bases de datos de CVEs. Herramientas como cve-bin-tool (del proyecto OWASP) pueden ayudar, pero nada sustituye el conocimiento manual. En un router de un operador de telecomunicaciones que analizamos, encontramos una versión de libcurl de 2018 con al menos 5 CVEs críticas que permitían RCE. El dispositivo era accesible desde Internet. Una bomba de relojería.
Por qué los servicios de red personalizados son el mayor riesgo
Aquí va una opinión fuerte: el riesgo más grande no suele estar en los componentes de código abierto conocidos, sino en los servicios de red personalizados que escriben los fabricantes. Son demonios escritos en C, a menudo sin las más mínimas prácticas de seguridad, sin ASLR, sin canarios de pila, y que escuchan en puertos altos. Estos servicios son cajas negras. La única forma de analizarlos es con ingeniería inversa estática (con Ghidra o IDA Pro) y dinámica (debugging a través del UART o de la red si tienes suerte).
Te pongo un ejemplo real de un caso de 2025. Un dispositivo de control industrial tenía un servicio en el puerto 5000 que parseaba comandos de gestión. Con Ghidra, en unas horas, identificamos un desbordamiento de búfer en la función que manejaba el parámetro "device_id". No había ninguna mitigación. Creamos un PoC en Python que, al enviar un paquete con 600 'A's, conseguíamos un crash y, con un poco más de trabajo, ejecución de código. El fabricante ni siquiera era consciente. Este tipo de hallazgos son los que diferencian un análisis de firmware superficial de uno que realmente mitiga riesgo.
Tendencias 2026: Automatización, SBOM y regulación
Para 2026, el panorama está cambiando, aunque lentamente. La presión regulatoria, especialmente con la extensión de normativas como la CRA (Cyber Resilience Act) en Europa, está forzando a los fabricantes a proporcionar un SBOM (Software Bill of Materials) y a mantener un ciclo de vida de seguridad más robusto. Esto, en teoría, debería hacer más fácil nuestro trabajo. La realidad es que muchos SBOMs iniciales serán incompletos o falsos, y habrá que verificarlos con el análisis de firmware.
La automatización con herramientas como firmware-analysis-toolkit (FAT) o el uso de emulación con qemu para ejecutar y testear binarios del firmware en un entorno controlado está ganando tracción. Pero ojo con esto: la emulación de firmware completo es compleja y a menudo falla por dependencias de hardware específico. Es mejor centrarse en emular y fuzzear binarios individuales una vez extraídos.
La recomendación final, tras años viendo los mismos errores, es clara: las organizaciones que despliegan IoT deben exigir contractualmente al fabricante el firmware y el SBOM para realizar análisis de seguridad independientes antes del despliegue masivo. Incluir cláusulas que penalicen la presencia de vulnerabilidades críticas o credenciales hardcodeadas. Es la única forma de cambiar la dinámica. Analizar firmware ya no es un arte oscuro para reversers; es una competencia de seguridad básica para cualquier equipo que toque operacional technology (OT) o IoT. El que no lo haga, estará firmando un cheque en blanco para el próximo incidente.
Recursos y referencias
- FACT (Firmware Analysis and Comparison Tool) - El framework más completo. Ideal para automatizar la extracción, análisis y comparación de firmwares. https://firmware-analysis-and-comparison-toolkit.github.io/
- Binwalk - La navaja suiza del análisis de firmware. Documentación y plugins para manejar formatos propietarios. https://github.com/ReFirmLabs/binwalk
- OWASP Firmware Security Testing Guide (FSTG). Una guía metodológica excelente que cubre todo el proceso, desde la adquisición hasta el fuzzing. https://github.com/OWASP/FSTG
- Exploit Database (Exploit-DB) y NVD. Para cruzar versiones de binarios y librerías extraídas con CVEs conocidas. https://www.exploit-db.com/ / https://nvd.nist.gov/