0. Arquitectura y Flujo de la Auditoría
Este proyecto simula un escenario completo de Red Teaming (auditoría ofensiva) contra un dispositivo IoT, abarcando desde el despliegue de infraestructura hasta la interceptación de datos sensibles.
El entorno se divide en tres roles estratégicos que interactúan entre sí:
1. El Objetivo (Target) - Raspberry Pi Zero 2 W
-
Función: Simula un “Smart Hub” comercial vulnerable.
-
Estado: Ejecuta servicios críticos sin asegurar:
-
HTTP (Puerto 80): Panel de control web sin cifrado.
-
Telnet (Puerto 23): Administración remota obsoleta en texto plano.
-
SNMP (Puerto 161): Gestión de red con comunidad pública.
-
2. La Estación de Control (Attacker) - Windows 11 + Ducky
-
Función: Ordenador central del auditor. Desde aquí se lanzan las herramientas de reconocimiento y ataque.
-
Herramienta de Reconocimiento (C2): Se utiliza Ducky Network UI para escanear la red, identificar el objetivo (Discovery) y revelar su superficie de ataque (Port Scanning). Su rol es indicar dónde atacar.
-
Herramienta de Explotación: Se utiliza Mitmproxy para ejecutar un ataque Man-in-the-Middle basado en los hallazgos previos de Ducky.
3. El Cliente (Victim) - Dispositivo Móvil
-
Función: Generador de tráfico legítimo.
-
Interacción: El usuario intenta acceder al panel de control del Objetivo. Gracias a la configuración del proxy, este tráfico es desviado inadvertidamente a través de la Estación de Control, permitiendo la captura de credenciales y datos.
Diagrama Lógico del Proyecto
-
Despliegue: Se configura la Raspberry Pi (Target).
-
Descubrimiento: Ducky escanea la red y detecta 192.168.1.55 con puertos 80 y 23 abiertos.
-
Ataque: Basado en el informe de Ducky, el auditor despliega un Proxy (Mitmproxy) en el puerto 8888.
-
Compromiso: El móvil navega hacia el Target, pero el tráfico es interceptado y leído por el auditor.
Fase 1: Despliegue del Entorno de Laboratorio (Target)
Objetivo: Configurar un dispositivo IoT simulado (Raspberry Pi Zero 2 W) exponiendo servicios estándar y vulnerables para su posterior auditoría.
1. Aprovisionamiento de Servicios
Se ha configurado el dispositivo con la IP estática.
{width=“6.267716535433071in”
height=“3.3194444444444446in”}
1.1 Servidor Web (Simulación de Panel de Control)
Se instaló Apache2 para simular una interfaz de administración web en el puerto 80.
Comando ejecutado: `sudo apt install apache2`
{width=“6.267716535433071in”
height=“2.2222222222222223in”}
1.2 Configuración SNMP (Protocolo de Gestión)
Se habilitó el servicio `snmpd` modificando el archivo `/etc/snmp/snmpd.conf` para permitir conexiones externas (listening on UDP:161) y estableciendo la comunidad `public` para simular una configuración por defecto insegura.
Evidencia de configuración:
{width=“6.267716535433071in”
height=“3.736111111111111in”}
1.3 Exposición de Protocolos Legacy (Telnet)
Se habilitó el servicio Telnet (puerto 23) para servir como indicador de vulnerabilidad durante la fase de escaneo de puertos.
Estado del Activo: El dispositivo “Smart Hub” está operativo y exponiendo los puertos 22 (SSH), 23 (Telnet), 80 (HTTP) y 161 (SNMP).
Fase 2: Configuración del Entorno de Auditoría (Windows 11)
Objetivo: Desplegar las herramientas de control (C2) y análisis en la estación de trabajo del auditor.
2.1 Despliegue de Ducky (Network UI)
Se clonó el repositorio y se configuró un entorno virtual en Python. Debido a la ausencia de un fichero de dependencias (`requirements.txt`), se realizó un análisis dinámico de importaciones para reconstruir el entorno.
{width=“5.088542213473316in”
height=“2.698069772528434in”}
Stack Tecnológico: Python 3.x, PySide6 (GUI).
Dependencias Críticas Identificadas e Instaladas:
* `scapy`, `netifaces`: Para la manipulación de paquetes y gestión de interfaces.
* `pysnmp`: Para la enumeración de topología (necesario para auditar el puerto 161).
* `paramiko`, `telnetlib3`: Para clientes SSH y Telnet integrados.
* `zxcvbn`: Para auditoría de fortaleza de contraseñas.
{width=“6.267716535433071in”
height=“3.611111111111111in”}
Resolución de Problemas (Troubleshooting)
-
Error: Bloqueo en splash screen “Checking for pysnmp”.
-
Solución: Instalación manual de `pysnmp` y `pycryptodomex`.
-
Error: Pop-up “Missing telnetlib3”.
-
Solución: Instalación de la librería asíncrona `telnetlib3`.
{width=“5.429146981627297in”
height=“3.0553641732283463in”}
2.2 Despliegue de Trafexia (Análisis de Tráfico)
Ahora vamos a preparar tu PC (Windows) para atacar/auditar esa IP 192.168.1.55. Necesitamos levantar Ducky (Python) y Trafexia (Node.js).
Requisito previo crítico: Asegúrate de tener instalado Npcap en Windows (es necesario para que Ducky/Scapy pueda escanear la red). Si no lo tienes, instálalo desde [npcap.com]{.underline} (marca la casilla “Install Npcap in WinPcap API-compatible Mode”).
Fase 3: Ejecución de Auditoría - Reconocimiento Activo
Operador: Sammi De Blas
Objetivo: Identificar la superficie de ataque expuesta en el dispositivo IoT (192.168.1.55) y validar la detección de servicios inseguros.
3.1 Preparación del Entorno (Simulación de Vulnerabilidad)
Durante la fase de configuración, se detectó que el servicio telnetd no estaba escuchando activamente debido a la configuración por defecto de inetd. Para simular un escenario de riesgo real (exposición de protocolos de texto plano), se forzó la apertura del puerto mediante Netcat.
Comando ejecutado en el Target (Raspberry Pi):
sudo nc -l -p 23 &
Desglose técnico del comando:
-
sudo: Eleva privilegios (necesario para abrir puertos < 1024, conocidos como puertos bien conocidos o well-known ports).
-
nc: Invoca Netcat, la “navaja suiza” de redes.
-
-l (Listen): Configura Netcat para “escuchar” conexiones entrantes en lugar de iniciar una conexión.
-
-p 23: Especifica el puerto 23 (estándar para Telnet).
-
&: Ejecuta el proceso en segundo plano (background), liberando la terminal para seguir trabajando.
Evidencia de ejecución:
{width=“3.994792213473316in”
height=“1.2910564304461942in”}
3.2 Verificación de Conectividad (Capa 3 OSI)
Antes de iniciar el escaneo de puertos (Capa 4), se validó la accesibilidad del host mediante el protocolo ICMP (Internet Control Message Protocol). Esto descarta problemas de enrutamiento o bloqueos totales por firewall.
Comando ejecutado en la Estación de Auditoría (Windows):
ping 192.168.1.55
Análisis de la respuesta:
-
TTL=64: El Time To Live de 64 confirma que el sistema operativo remoto es probablemente basado en Linux (Windows suele usar 128).
-
Tiempo < 3ms: Confirma que el dispositivo está en la red local (LAN) con latencia mínima.
Evidencia de conectividad:
{width=“5.348958880139983in”
height=“2.407919947506562in”}
3.3 Escaneo de Superficie de Ataque (Capa 4 OSI)
Se utilizó la herramienta Ducky Network UI (módulo Port Scanner) para enumerar los servicios TCP disponibles. La herramienta realiza un barrido de puertos conectándose a los sockets abiertos.
Configuración del Escaneo:
-
Target: 192.168.1.55
-
Rango: 1-1024 (Puertos privilegiados).
-
Método: TCP Connect Scan (Full Handshake).
Resultados del Análisis:Interpretación de Seguridad:
Puerto Protocolo Estado Nivel de Riesgo Descripción Técnica
22 SSH OPEN Bajo Servicio de administración remota cifrado. Esencial para la gestión, pero requiere protección contra fuerza bruta. 23 Telnet OPEN CRÍTICO Protocolo obsoleto que transmite credenciales en texto plano. Su presencia indica una grave falta de hardening o un dispositivo legado. 80 HTTP OPEN Medio Servidor web detectado. Al no ser HTTPS (443), el tráfico web es susceptible de interceptación.
La detección simultánea de los puertos 23 y 80 expone al dispositivo a vectores de ataque de Interceptación de Tráfico (Sniffing). Un atacante en la misma red podría capturar contraseñas de administración (vía Telnet) o datos de sesión (vía HTTP) sin necesidad de descifrado complejo.
Evidencia del hallazgo (Ducky UI):
{width=“5.588542213473316in”
height=“1.364643482064742in”}
{width=“5.696522309711286in”
height=“1.3891327646544183in”}
Fase 3B: Interceptación de Tráfico (Man-in-the-Middle)
Objetivo: Demostrar la inseguridad del protocolo HTTP interceptando las comunicaciones entre un dispositivo cliente (móvil) y el objetivo IoT (192.168.1.55).
3.4 Despliegue de Infraestructura de Interceptación y Resolución de Conflictos
Durante la fase inicial de despliegue de herramientas, se seleccionó Trafexia para el análisis de tráfico.
Sin embargo, se identificaron incompatibilidades críticas relacionadas con la compilación de librerías nativas (Node-gyp y Python ABI mismatch) en el entorno Windows host.
Para garantizar la continuidad de la auditoría y cumplir con los objetivos de análisis, se realizó una migración técnica hacia Mitmproxy, una herramienta estándar en la industria para la auditoría de tráfico HTTP/HTTPS.
Esta decisión permitió establecer un proxy transparente sin comprometer la integridad del sistema operativo anfitrión.
Herramienta seleccionada: Mitmproxy (versión 12.2.1)
Interfaz de gestión: Mitmweb (Web-based user interface)
3.5 Configuración del Vector de Ataque
Se configuró la estación de trabajo del auditor para actuar como un proxy explícito, obligando a todo el tráfico del dispositivo móvil a transitar por la interfaz de red controlada antes de llegar al objetivo.
Configuración del Proxy (Estación de Auditoría): Dirección IP: 192.168.1.135 Puerto de Escucha: 8888 (TCP) Protocolo: HTTP Proxy
Configuración del Cliente (Dispositivo Móvil): Se modificó la configuración de red Wi-Fi del dispositivo para enrutar el tráfico a través de la IP del auditor. Adicionalmente, se instaló el certificado de autoridad de certificación (CA) propio de Mitmproxy para permitir la inspección de tráfico SSL/TLS si fuera necesario, aunque el objetivo opera en HTTP plano.
{width=“6.267716535433071in”
height=“3.5in”}
3.6 Ejecución y Captura de Tráfico
Se procedió a navegar desde el dispositivo móvil hacia la dirección IP del objetivo (192.168.1.55). La herramienta de interceptación registró exitosamente la solicitud, confirmando que el tráfico fluye a través del punto de control establecido.
Análisis de la Captura: Solicitud Interceptada: GET [http://192.168.1.55/]{.underline} Código de Estado: 200 OK User-Agent: Android 10 / Mobile Safari
{width=“1.773332239720035in”
height=“3.9427088801399823in”}
Hallazgo de Seguridad: La captura evidencia que la comunicación se realiza en texto plano (HTTP).
No existe cifrado en la capa de transporte, lo que permite a un atacante posicionado en la red local leer, modificar o redirigir el tráfico sin que el usuario final o el dispositivo lo detecten.
{width=“6.267716535433071in”
height=“2.9583333333333335in”}
Conclusiones de la Fase 3 La auditoría ha confirmado que el dispositivo objetivo presenta una superficie de ataque significativa, exponiendo servicios de administración inseguros (Telnet) y canales de comunicación no cifrados (HTTP), validando las hipótesis iniciales de vulnerabilidad.
{width=“6.267716535433071in”
height=“2.9722222222222223in”}