Auditada la tienda en 04-02, giramos hacia la infraestructura interna de TechNova: la red 10.10.10.0/24, con su servidor Linux, el controlador de red, las estaciones y los servicios que el Módulo 3 dejó en la lista priorizada. Aquí la superficie no es una aplicación web, sino servicios de red y el propio medio de transporte: un servicio con CVE explotable, una sesión nula de SMB en el servidor interno, tráfico que quizá viaja sin cifrar y configuraciones débiles (SNMP public, DNS mal ajustado).

El encuadre se vuelve aún más delicado que en la web, porque varias técnicas de red pueden afectar a terceros o a la disponibilidad: un ARP spoofing mal hecho corta la red de una oficina; un módulo de explotación sobre un servicio frágil lo tumba. Por eso, más que nunca: solo el laboratorio autorizado de TechNova, dentro del alcance y la ventana pactada, con control del impacto (nada de denegación de servicio no acordada) y documentando cada acción. Y un límite claro: aquí conseguimos ejecución o acceso a un servicio; escalar privilegios y moverse por la red (pivoting) es Módulo 5, no lo tocamos.

1. La red como superficie de ataque
2. Explotar un servicio con CVE (Metasploit responsable)
3. MITM: ARP spoofing y sniffing
4. Ataques a SMB y NTLM relay
5. Configuraciones de red mal ajustadas (SNMP, DNS)
6. Detección: qué ve el IDS
7. Hardening de red (contrapartida)
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

Un servicio de red es un programa escuchando en un puerto (03-01/03-02). Se puede atacar por dos vías complementarias:

• Atacar el servicio: aprovechar un fallo del software que escucha (un CVE, una mala configuración, credenciales débiles) para lograr acceso o ejecución.
• Atacar el medio: interceptar o manipular el tráfico que viaja por la red (MITM), aprovechando protocolos sin autenticación (ARP) o sin cifrado (HTTP, FTP, Telnet).

Cuando un servicio corre una versión con CVE explotable confirmado (candidata validada en 03-03), Metasploit ofrece módulos ya escritos. Uso responsable en el laboratorio: verificar antes, elegir el módulo más fiable (recuerda el Rank de 04-01) y el payload de menor impacto.

Análisis: check valida la vulnerabilidad sin lanzar el exploit —úsalo siempre que exista—. Y en lugar de abrir directamente una shell interactiva, ejecutamos un simple id: la salida uid=1000(devapp) demuestra ejecución de comandos y confirma que hemos obtenido un punto de apoyo con privilegios limitados. Eso es todo lo que necesita el informe; consolidar esa shell y escalar es Módulo 5. La presentación a fondo de Metasploit está en 07-02.

Contrapartida (remediación): aplicar el parche o retirar el software en fin de vida, desactivar el modo debug de Werkzeug en cualquier entorno accesible, y no exponer servicios de desarrollo a la red. Segmentar para que dev no sea alcanzable desde donde no debe.

Mecanismo. En una LAN, el protocolo ARP no tiene autenticación: cualquier host puede afirmar "yo soy la puerta de enlace". Con ARP spoofing, el pentester engaña a una víctima y al gateway para que el tráfico pase a través de su máquina (man-in-the-middle), y ahí lo puede leer (sniffing) si va sin cifrar.

Marco: SOLO laboratorio. Esta técnica intercepta comunicaciones de terceros; fuera de un entorno autorizado es ilegal. Y hay que reenviar el tráfico (ip_forward) para no provocar una caída de red no acordada.

PoC de bajo impacto. Demostrar que se captura una credencial que viaja sin cifrar de un servicio de prueba (por ejemplo un login por HTTP o FTP en el laboratorio), capturando un par usuario/contraseña ficticio como evidencia. No se intercepta a usuarios reales ni se acumula tráfico masivo.

Contrapartida: cifrado en todas partes (HTTPS, SSH, SMB firmado) hace inútil el sniffing; en la red, Dynamic ARP Inspection y DHCP snooping en los switches, port security y segmentación por VLAN. Si todo va cifrado, el atacante ve bytes ilegibles.

El Módulo 3 confirmó una sesión nula de SMB en el servidor interno (10.10.10.55) con un recurso RRHH accesible: un hallazgo de configuración, sólido porque no depende de una versión.

PoC de bajo impacto (validar la sesión nula):

Listar el recurso y confirmar que RRHH es accesible sin credenciales demuestra el fallo. No se descargan todos los documentos: basta la evidencia del acceso.

NTLM relay (mecanismo, alto nivel). En redes Windows, si SMB no exige firma, un atacante que capture una autenticación NTLM puede reenviarla (relay) a otro servicio y autenticarse como la víctima sin conocer su contraseña. Es una técnica potente; a este nivel basta reconocer el patrón: autenticación capturada → reenviada → acceso. Herramientas como responder e impacket-ntlmrelayx la implementan.

Contrapartida: exigir firma SMB (SMB signing) neutraliza el relay; deshabilitar SMBv1, cerrar sesiones nulas y anónimas, y aplicar mínimo privilegio en los recursos compartidos. Retirar credenciales y datos sensibles de shares abiertos.

Muchos accesos no vienen de un CVE, sino de un servicio mal configurado (hallazgos confirmados y muy fiables):

Leer solo la rama system de SNMP o comprobar si el AXFR responde demuestra la fuga sin abusar: no volcamos toda la MIB ni recorremos el árbol entero. Cada uno con su arreglo en la tabla.

Los ataques de red son especialmente ruidosos y detectables, y conviene que el pentester lo sepa (y que el SOC del cliente lo entrene):

• ARP spoofing: genera respuestas ARP anómalas y MACs duplicadas; un IDS (Snort/Suricata) y herramientas como arpwatch lo detectan al instante.
• Explotación de servicios: las firmas de exploits conocidos disparan alertas; picos de conexiones fallidas y payloads sospechosos quedan en los logs.
• Enumeración SMB/SNMP: ráfagas de consultas anónimas o snmpwalk completos son patrones reconocibles.

Que el SOC de TechNova vea tu actividad no es un fracaso: es una validación de su capacidad de detección, y forma parte del valor del informe.

Consolidando las defensas de toda la lección:

• Cifrado por defecto: HTTPS, SSH, SMB firmado, SNMPv3, SFTP. Anula el sniffing.
• Switching seguro: Dynamic ARP Inspection, DHCP snooping, port security, VLANs. Anula el ARP spoofing y limita el alcance.
• Segmentación: que dev, producción y ofimática estén separadas; que un compromiso en una no dé la red entera.
• Endurecer servicios: parchear, retirar EOL, cerrar sesiones nulas/anónimas, cambiar credenciales y comunidades por defecto, restringir AXFR.
• Monitorización: IDS/IPS y revisión de logs para detectar lo que este mismo módulo genera.

• Lanzar ARP spoofing sin reenviar el tráfico. Si olvidas ip_forward, cortas la comunicación de la víctima: denegación de servicio no acordada. Configúralo antes.
• Usar módulos DoS o exploits de baja fiabilidad sobre servicios frágiles. Pueden tumbar el servicio del cliente. Prioriza Rank alto y usa check antes de run.
• Exfiltrar todo un share o toda la MIB SNMP. Rompe el control de impacto. Lista y extrae una muestra que pruebe el acceso.
• Interceptar tráfico fuera del laboratorio. El MITM sobre comunicaciones reales de terceros es ilegal. Solo entornos autorizados.
• Confundir explotación con post-explotación. Obtener la shell devapp es el final de esta lección; escalar a root o pivotar a otra subred es Módulo 5.
• Ignorar la contrapartida. Un hallazgo de red sin su hardening (cifrado, firma SMB, DAI, SNMPv3) es medio informe. El objetivo es que TechNova cierre la puerta.
• Consejo: en red, el cifrado y la segmentación resuelven la mayoría de estas clases de golpe. Cuando propongas remediación, empieza por ahí.

Ejercicio 1. Sobre el servidor interno 10.10.10.55 con sesión nula de SMB y recurso RRHH, describe la secuencia de PoC de bajo impacto para validar el acceso sin exfiltrar los documentos, y da tres medidas de hardening con las que TechNova cerraría el fallo.

Ejercicio 2. Vas a demostrar un ARP spoofing en el laboratorio para probar que cierto tráfico viaja sin cifrar. Explica qué preparas para no provocar una caída de red, qué evidencia mínima capturarías, y cuál es la contrapartida técnica que haría inútil el ataque.

Ejercicio 3. El Módulo 3 marcó SNMP con comunidad public en 10.10.10.30. Explica cómo validarías la fuga de información de forma controlada, por qué es un hallazgo fiable pese a no tener CVE, y cómo se remedia.

Solución 1. PoC: (1) smbclient -N -L //10.10.10.55/ para listar recursos sin credenciales y ver RRHH; (2) enum4linux -a 10.10.10.55 para confirmar usuarios/política vía sesión nula; (3) smbclient -N //10.10.10.55/RRHH -c 'ls' para listar el contenido y demostrar el acceso, sin descargar los documentos. Evidencia: la salida que muestra el recurso accesible sin autenticación. Hardening: (a) cerrar la sesión nula/anónima en la configuración SMB; (b) exigir firma SMB (mitiga además el NTLM relay) y deshabilitar SMBv1; (c) aplicar mínimo privilegio en el recurso y retirar los datos sensibles de RRHH de un share abierto, con permisos por grupo.

Solución 2. Preparación para no cortar la red: habilitar el reenvío de IP (echo 1 > /proc/sys/net/ipv4/ip_forward) antes de envenenar, para que el tráfico interceptado siga llegando a su destino; limitar el ataque a un host de prueba y a la ventana acordada. Evidencia mínima: un par usuario/contraseña ficticio capturado de un servicio en claro (login HTTP/FTP de laboratorio), como prueba de que el tráfico va sin cifrar. Contrapartida: cifrado extremo a extremo (HTTPS/SSH/SMB firmado) hace ilegible el tráfico interceptado, y en la red Dynamic ARP Inspection + DHCP snooping impiden el envenenamiento ARP.

Solución 3. Validación controlada: snmpwalk -v2c -c public 10.10.10.30 1.3.6.1.2.1.1 consultando solo la rama system para demostrar que la comunidad por defecto responde y filtra información (nombre del sistema, versión), sin recorrer toda la MIB. Es un hallazgo fiable porque es una configuración confirmada, no una sospecha por número de versión: no depende de un CVE ni de un posible retroporte, la fuga o existe o no, y aquí existe. Remediación: cambiar la comunidad por una robusta o, mejor, migrar a SNMPv3 (con autenticación y cifrado) y restringir por IP qué hosts pueden consultar.

Hemos llevado la explotación del navegador a la red. Sobre la infraestructura de TechNova hemos validado un servicio con CVE (obteniendo una ejecución de comandos de bajo privilegio con un simple id), confirmado la sesión nula de SMB de RRHH, entendido el mecanismo de MITM/ARP spoofing y NTLM relay, y comprobado fugas por SNMP y DNS mal configurados. Cada técnica, con su PoC que demuestra sin destruir, su detección (lo ruidosa que es para un IDS) y su contrapartida de hardening: cifrado, switching seguro, firma SMB, SNMPv3 y segmentación.

Fíjate en el límite que hemos respetado: hemos conseguido acceso o ejecución en servicios, pero nos hemos detenido justo ahí —consolidar, escalar y moverse por la red es el Módulo 5—. La siguiente lección, 04-04 Explotación de Vulnerabilidades de Sistemas, cierra el trío técnico: cómo obtener ejecución en un host aprovechando fallos del sistema operativo y servicios locales, con el desbordamiento de buffer explicado a nivel conceptual, hasta lograr un foothold con privilegios limitados. La escalada desde ese foothold seguirá siendo Módulo 5.