Pentesting IoT y hardware hacking: del chip a la nube del dispositivo

Un dispositivo conectado es mucho más que su app: tiene una placa con puertos de depuración, una memoria con su firmware, una radio y una nube que recibe datos de toda la flota. Lo auditamos entero en nuestro laboratorio, como lo haría un atacante con el dispositivo en la mano, y te entregamos cada hallazgo con su prueba de concepto y su referencia a OWASP IoT Top 10, EN 18031 y el Cyber Resilience Act.

Dimensiona tu proyecto · Solicitar evaluación IoT

¿Prefieres hablarlo? Llámanos al +34 960 730 013

Del chip a la nube — Hardware, firmware, radio, app, API y OTA en un mismo alcance
UART · JTAG · SPI — Interfaces de depuración y memorias probadas en laboratorio
EN 18031 — Hallazgos mapeados a la norma de la directiva RED, al CRA y a OWASP IoT Top 10
Retest — Verificación de las correcciones de firmware y backend incluida

Por qué un dispositivo IoT es un riesgo distinto

Un servidor se audita desde la red. Un dispositivo IoT, además, se puede abrir: cualquiera que compre una unidad tiene en la mesa su placa, su memoria y sus puertos de depuración, y lo que saque de ella —una contraseña de fábrica, una clave privada, una forma de saltarse la autenticación— suele servir para todas las unidades vendidas. Por eso un fallo en un dispositivo rara vez es de uno: es de la flota entera.

A eso se suma que el dispositivo vive dentro de la red del cliente. Una cámara, un controlador de climatización o un PLC comprometidos sirven de punto de apoyo para llegar a la red corporativa, y en entornos industriales el impacto puede ser físico.

Y ya no es solo una cuestión de riesgo. Desde el 1 de agosto de 2025, los equipos radioeléctricos conectados a internet que se venden en la UE deben cumplir los requisitos de ciberseguridad del Reglamento Delegado (UE) 2022/30 de la directiva RED, con las normas EN 18031 como vía para demostrarlo. El Cyber Resilience Act obliga desde el 11 de septiembre de 2026 a notificar las vulnerabilidades explotadas y será plenamente aplicable el 11 de diciembre de 2027. Un pentest IoT es la forma de saber, antes que un atacante o que un organismo de control, qué se puede sacar de tu dispositivo.

Un dispositivo, de la placa a la nube

Explora la placa componente a componente para ver qué probamos en cada uno, o reproduce una cadena de ataque típica: de los pads de la consola serie a la telemetría de toda la flota.

Consola serie UART (OWASP IoT I9 · I10): Identificamos los pads TX, RX y GND, la velocidad de la línea y qué expone la consola: mensajes de arranque, el gestor de arranque y si se puede interrumpir para obtener una shell. Hallazgo habitual: Consola de U-Boot interrumpible o shell de root sin contraseña, dejada para las pruebas de fábrica.
Depuración JTAG/SWD (OWASP IoT I10): Localizamos los puntos de depuración y comprobamos si la protección de lectura está activa o si se puede detener el procesador, leer su memoria interna y modificar el código en ejecución. Hallazgo habitual: Puerto de depuración abierto en producción: volcado de la flash interna del microcontrolador, claves incluidas.
Memoria flash SPI (OWASP IoT I5 · I7): Leemos la memoria con una pinza SOIC o desoldándola, extraemos el sistema de archivos y analizamos binarios, configuraciones y componentes de terceros con sus versiones. Hallazgo habitual: Firmware sin cifrar con claves privadas y contraseñas, y librerías con vulnerabilidades públicas de hace años.
Procesador y arranque seguro (OWASP IoT I4 · I5): Revisamos la cadena de arranque seguro y la protección de claves en el hardware y, cuando el alcance lo incluye, probamos inyección de fallos (glitching) y ataques de canal lateral. Hallazgo habitual: Arranque seguro desactivado o mal configurado: el dispositivo ejecuta cualquier firmware que se le cargue.
Radio: Wi-Fi, BLE, Zigbee (OWASP IoT I2 · I7): Capturamos y analizamos las comunicaciones inalámbricas: emparejamiento y características GATT de BLE, redes Zigbee, Z-Wave o LoRa, reutilización de claves y repetición de mensajes. Hallazgo habitual: Características BLE escribibles sin emparejamiento que permiten abrir, encender o reconfigurar el dispositivo desde cerca.
Servicios de red (OWASP IoT I2 · I9): Revisamos los servicios que el dispositivo expone en la red local y en internet: paneles web, Telnet, SSH, UPnP, MQTT o puertos de depuración olvidados. Hallazgo habitual: Telnet o un panel web con credenciales por defecto, las mismas en todas las unidades.
App móvil de gestión (OWASP IoT I3): Auditamos la app que configura el dispositivo con la metodología de OWASP MASVS: almacenamiento, comunicaciones y cómo se da de alta y se asocia un dispositivo a una cuenta. Hallazgo habitual: La app guarda la clave del dispositivo en claro o permite asociar un dispositivo ajeno conociendo su número de serie.
API y nube del fabricante (OWASP IoT I3 · I8): Probamos cómo se autentica cada dispositivo ante la nube, la separación entre clientes y los brókeres MQTT o las API que reciben la telemetría y envían órdenes. Hallazgo habitual: Un mismo certificado para toda la flota o temas MQTT sin control de acceso: un dispositivo ve los datos de todos.
Actualizaciones OTA (OWASP IoT I4): Comprobamos cómo llega y se verifica una actualización: firma, canal cifrado, protección contra la vuelta a versiones antiguas y comportamiento si la actualización falla a medias. Hallazgo habitual: Actualizaciones sin firma o servidas por HTTP: una actualización manipulada se instala y sobrevive a los reinicios.

Cadena de ataque

Consola UART con shell de root: Con un adaptador USB-serie en los pads de la placa, la consola muestra el arranque y U-Boot se deja interrumpir: cambiando los parámetros de arranque se obtiene una shell de root sin contraseña.
Volcado de la flash SPI: Una pinza SOIC sobre la memoria y un programador leen los 16 MB de firmware sin desoldar nada. No está cifrado: el sistema de archivos se extrae entero.
Secretos dentro del firmware: En el sistema de archivos aparecen la clave privada del dispositivo —la misma en todo el lote— y el hash de la contraseña de root con un algoritmo obsoleto.
Suplantación ante la nube: Con el certificado extraído, el bróker MQTT del fabricante acepta la conexión y deja suscribirse a los temas de todos los dispositivos: la telemetría de la flota entera.
Actualización sin firma: El servidor de actualizaciones entrega el firmware por HTTP y el dispositivo solo comprueba un hash que envía el mismo servidor: una versión manipulada se instalaría y persistiría.

Cadena ilustrativa construida con hallazgos habituales en este tipo de auditorías; no describe un dispositivo ni un fabricante concretos. La salida de la terminal es un ejemplo.

Qué cubre un pentest IoT

Reconocimiento del hardware: identificación de componentes, hojas de datos, pistas y puntos de prueba de la placa
Interfaces de depuración y comunicación interna: UART, JTAG, SWD, SPI e I2C
Extracción y análisis de firmware: lectura de memorias, sistema de archivos, binarios, secretos embebidos y componentes de terceros (SBOM)
Arranque seguro, protección de claves y, cuando el alcance lo incluye, inyección de fallos y canal lateral
Comunicaciones inalámbricas: Wi-Fi, Bluetooth Low Energy, Zigbee, Z-Wave, LoRa y protocolos propietarios
Servicios de red del dispositivo: paneles web, Telnet, SSH, UPnP, MQTT y CoAP
App móvil de gestión, según OWASP MASVS
API cloud y brókeres del fabricante: autenticación de dispositivos, separación entre clientes y órdenes remotas
Mecanismo de actualización OTA: firma, canal, protección contra versiones antiguas y recuperación
Entornos OT/ICS: evaluación según IEC 62443 y segmentación por niveles del modelo Purdue

Metodología

Alcance y modelo de amenazas: Acordamos qué capas entran (hardware, firmware, radio, app, nube), cuántas unidades hay disponibles y qué atacante se simula: alguien en la red, alguien cerca con una radio o alguien con el dispositivo en la mano.
Reconocimiento del dispositivo: Abrimos la unidad, identificamos componentes y puntos de prueba, y mapeamos interfaces, protocolos y servicios. Lo no destructivo va primero.
Firmware: Extraemos el firmware por la vía menos invasiva posible y analizamos sistema de archivos, binarios, configuraciones, secretos embebidos y componentes con vulnerabilidades conocidas.
Comunicaciones y ecosistema: Capturamos el tráfico de radio y de red y probamos la app de gestión, la API cloud y el mecanismo de actualización, que es donde un fallo se convierte en un problema de toda la flota.
Explotación y cadenas de ataque: Encadenamos los hallazgos para demostrar el impacto real: de la placa a la nube, o del dispositivo a la red corporativa o al sistema de control.
Informe y retest: Entregamos cada hallazgo con prueba de concepto, severidad y recomendación para el equipo de firmware y de backend, mapeado a OWASP IoT Top 10, EN 18031 e IEC 62443, y verificamos las correcciones.

Entregables

Informe ejecutivo con el riesgo para el producto y la flota, priorizado
Informe técnico con prueba de concepto de cada vulnerabilidad y pasos para reproducirla
Mapa de la superficie de ataque del dispositivo: interfaces, servicios, protocolos y ecosistema
Clasificación de hallazgos por OWASP IoT Top 10 y referencia a los requisitos de EN 18031 o IEC 62443 que aplican
Inventario de componentes de terceros detectados en el firmware, con sus vulnerabilidades conocidas
Recomendaciones de corrección para hardware, firmware, comunicaciones y backend
Retest de las correcciones y apoyo al fabricante durante la remediación

Casos de uso

Fabricantes que necesitan evidencias de seguridad antes de lanzar un producto o para su expediente técnico de la directiva RED o del Cyber Resilience Act
Empresas que integran dispositivos de terceros (cámaras, controladores, sensores) y quieren saber qué meten en su red
Industria con PLC, SCADA o redes OT conectadas a la red corporativa
Operadores de infraestructuras críticas: energía, agua y transporte
Fabricantes y hospitales con dispositivos médicos conectados
Domótica, cerraduras inteligentes y sistemas de gestión de edificios (BMS)
Startups de hardware que deben superar la due diligence de un cliente o un inversor

Qué cubre cada enfoque

Muchos "pentests IoT" se quedan en la red o en la app. Lo que se ve, y lo que no, según hasta dónde se llega.

	Escáner de red	Pentest de la app y la API	Pentest IoT completo
Puertos de depuración (UART, JTAG)	No	No	Sí, en laboratorio
Firmware y secretos embebidos	No	Solo lo que expone la app	Extracción y análisis completo
Radio (BLE, Zigbee, LoRa)	No	Parcial	Captura, emparejamiento y repetición
App y nube del fabricante	No	Sí	Sí, encadenado con lo anterior
Actualizaciones OTA	No	Parcial	Firma, canal y vuelta a versiones antiguas
Evidencia para EN 18031 y CRA	Mínima	Parcial	Hallazgos mapeados a los requisitos

Compara con

Preguntas frecuentes sobre pentesting IoT

¿Necesitáis acceso físico al dispositivo?

Para un test completo, sí. La API cloud, la app móvil y las comunicaciones de red se pueden probar en remoto, pero el análisis de hardware y de firmware necesita el dispositivo en nuestro laboratorio.

¿Cuántas unidades necesitáis?

Lo ideal son dos o tres: algunas pruebas de hardware pueden exigir desoldar componentes o dejar una unidad inservible. Si solo hay una, se planifica empezando por las técnicas no destructivas y se acuerda contigo antes cualquier paso que pueda dañarla.

¿Necesitáis el firmware o el código fuente?

No es imprescindible: extraer el firmware de la propia placa es parte de la prueba, porque es lo que haría un atacante. Si nos lo facilitas, junto con los esquemas o el código, el análisis llega más lejos en el mismo tiempo.

¿Qué exige la directiva RED a un dispositivo conectado?

Desde el 1 de agosto de 2025, el Reglamento Delegado (UE) 2022/30 obliga a los equipos radioeléctricos que se conectan a internet, y a algunos que tratan datos personales o permiten pagos, a cumplir requisitos de ciberseguridad. Las normas EN 18031-1, -2 y -3 son la vía para presumir la conformidad. Un pentest aporta la evidencia técnica de que esos requisitos se cumplen de verdad, más allá de la documentación.

¿Y el Cyber Resilience Act?

El CRA se aplica a casi cualquier producto con elementos digitales que se venda en la UE. Desde el 11 de septiembre de 2026 los fabricantes deben notificar a ENISA las vulnerabilidades activamente explotadas, y el 11 de diciembre de 2027 será plenamente aplicable, con requisitos de seguridad desde el diseño, gestión de vulnerabilidades y actualizaciones durante la vida del producto.

¿Podéis hacer el pentest sin afectar a la producción industrial?

Sí. En entornos OT trabajamos con el equipo de planta para definir ventanas de mantenimiento, priorizamos técnicas pasivas y hacemos las pruebas más invasivas sobre equipos de reserva o en un banco de pruebas, nunca a ciegas sobre un proceso en marcha.

¿El informe sirve para el expediente técnico del producto?

Sí, como evidencia de las pruebas de seguridad: cada hallazgo indica qué se probó, cómo, el resultado y la referencia a la norma correspondiente, y el retest documenta que las correcciones funcionan. La evaluación de conformidad en sí la hace el fabricante o, cuando corresponde, un organismo notificado.

¿Cuánto dura un pentest IoT?

Depende sobre todo de cuántas capas entran en el alcance (hardware, firmware, radio, app, nube) y de cuántas unidades hay. Lo fijamos en la propuesta, con alcance y precio cerrados, después de una primera llamada en la que vemos el dispositivo y su ecosistema.

Normativa para fabricantes

Serie de análisis de hardware

Industria y casos reales

Fuentes

¿Listo para proteger tu empresa?

Responde la ficha de alcance a tu ritmo y la usaremos para preparar tu propuesta. Si prefieres hablarlo antes, reserva una llamada gratuita de 30 minutos.

Dimensiona tu proyecto · Solicitar evaluación IoT