El patrón del que nadie quiere hablar
El ejercicio «Locked Shields 2026 » concluyó en Tallin el April 24, con más de 4,000 participantes de 41 países que formaron 16 equipos multinacionales para hacer frente a aproximadamente 8,000 ciberataques en tiempo real dirigidos contra infraestructuras críticas: defensa aérea, voto electrónico, 5G, gestión de satélites y un sistema de generación de energía completamente operativo. Los comunicados oficiales, como siempre, elogiaron la capacidad de los participantes para «detectar y responder a actividades cibernéticas maliciosas».
Esa interpretación es cierta. Además, año tras año, es el tema del que todo el mundo quiere hablar, y eso oculta discretamente una tendencia menos halagüeña: los equipos azules que tienen dificultades no las tienen porque sus estrategias de SOC fueran deficientes. Tienen dificultades porque algo se ha roto bajo sus pies y no lo vieron venir. Ellos miraban hacia la planta 7 , mientras que el equipo rojo ya se encontraba en la planta 2.
Si ha formado parte de un equipo azul, ya sabe de qué se trata. Un servicio deja de funcionar. Los primeros diez minutos los pasa gritándole al cortafuegos. Los siguientes diez se pasan en la consola EDR. Para cuando alguien ejecute « » o «arp -a », o consulte una tabla BGP, la ronda ya habrá transcurrido hasta la mitad.
Esta entrada constituye un recorrido por el modelo OSI, no porque el modelo de siete capas sea algo sagrado, sino porque constituye la guía más clara para los ingenieros que han caído en un pensamiento irreflexivo en materia de seguridad informática. Si su primera reacción ante un «fallo del servicio» es «comprobar el WAF», se está saltando cinco capas de superficie de ataque en las que el equipo rojo ya se ha adentrado.
Índice
Por qué el modelo OSI sigue mereciendo su lugar
Cada pocos años, alguien publica un artículo en el que se afirma que «el modelo OSI ha quedado obsoleto; utilice TCP/IP». Tienen razón en que el modelo es una abstracción: las capas 5 y 6 , en particular, se dedican principalmente a tareas administrativas en las pilas modernas. Se equivocan al pensar que esto lo hace inútil. OSI es un modelo de clasificación. Cuando algo falla o está siendo objeto de un ataque, recorrer las capas de abajo hacia arriba es la forma más rápida de localizar el origen del fallo, en lugar de limitarse a lo que sus herramientas puedan detectar.
Los equipos rojos lo saben. Eligen la capa en la que su detección es más débil. En un entorno de «Locked Shields», eso casi nunca corresponde a la Capa 7.
Capa 1: Física
En el ejercicio se abstrae la capa física, pero la lección es aplicable: gestión fuera de banda, servidores de consola, KVM, interfaces de gestión «lights-out» (iDRAC, iLO, IPMI). Estos dispositivos suelen dejarse con las credenciales predeterminadas o en VLAN de gestión compartidas, y ofrecen una vía que elude todos los controles de detección situados por encima de ellos.
El sincero fracaso del equipo azul: , al considerar la red OOB como «infraestructura, fuera del alcance». Está dentro del ámbito de aplicación. Si el color rojo puede llegar a su iDRAC, el cortafuegos situado por encima de él es meramente decorativo.
Capa 2: Enlace de datos
Es aquí donde se produce una cantidad desproporcionada de daños, y es la capa en la que la mayoría de los defensores con más experiencia han dejado de pensar porque «el switch se encarga de ello». El interruptor no lo gestiona. El conmutador aplica lo que haya configurado, que a menudo es nada.
El catálogo de ataques «Layer 2 » no es nuevo. Esa es la cuestión. Nada de esto constituye una investigación novedosa:
- La suplantación de ARP y el envenenamiento de caché siguen funcionando en cualquier segmento que no cuente con inspección dinámica de ARP. Proporciona al atacante una posición de «hombre en medio» invisible para sus herramientas de nivel 3+
- La técnica de inundación de la tabla CAM convierte un conmutador en un concentrador, difundiendo tramas que el atacante puede interceptar
- Salto de VLAN mediante doble etiquetado o uso indebido del protocolo DTP: su red «segmentada» está a solo un puerto troncal mal configurado de convertirse en una red plana
- Escasez de DHCP y DHCP no autorizado : asigne su propia puerta de enlace y redirija todo el tráfico a través de ella
- Los ataques STP contra « » pretenden ser el puente raíz, modifican la topología L2 y obligan al tráfico a pasar por su punto de escucha
- La inyección de LLDP/CDP resulta útil para el reconocimiento y, en algunas plataformas, para engañar a los dispositivos vecinos
Las medidas de seguridad son antiguas, están bien documentadas y se aplican de forma crónicamente incompleta: seguridad portuaria, supervisión de DHCP, inspección dinámica de ARP, BPDU Guard, Root Guard, desactivación de DTP y separación de las VLAN de gestión. Ninguno de ellos aparece en la portada de un informe técnico de un proveedor. Todos ellos deciden las rondas.
El sincero fracaso del equipo azul: confiar en que el equipo de redes lo había hecho en 2019 y no volver a verificarlo nunca más. Realice las comprobaciones. Tardan una hora.
Capa 3: Red (y sí, BGP)
La capa IP es donde los defensores se sienten cómodos, pero esa comodidad desaparece en cuanto se entra en el ámbito de los protocolos de enrutamiento.
En el caso del enrutamiento interno (OSPF, EIGRP, IS-IS), se repite el mismo patrón que en el L2 . La autenticación es opcional en el protocolo, obligatoria en la práctica y se desactiva habitualmente «por el momento» en entornos de laboratorio y de pruebas, lo que acaba traduciéndose en una «memoria muscular» en la fase de producción. Un atacante que se encuentre en un segmento de interconexión sin autenticación OSPF MD5/SHA puede inyectar rutas, desviar el tráfico hacia un «agujero negro» o redirigirlo de forma discreta.
Y luego está el BGP. El BGP gestiona Internet basándose en un modelo de confianza cuyas raíces se remontan a los RFC 1105 y 1989, y los escenarios de «Locked Shields» lo incluyen cada vez más, ya que los adversarios del mundo real también lo hacen. La superficie de ataque pertinente:
- Secuestros de rutas: , en los que se anuncia un prefijo más específico del que usted no es propietario para desviar el tráfico hacia usted
- Fugas de rutas: , en las que se comunican rutas aprendidas de un nodo a otro infringiendo la política, a menudo de forma accidental, con el mismo impacto operativo que un secuestro de ruta.
- Restablecimiento de sesiones: « », que utiliza tráfico TCP manipulado para interrumpir sesiones BGP. Por este motivo existe el TCP-AO (RFC 5925), o lo que históricamente se denominaba TCP MD5
- Manipulación de rutas: . La inserción de rutas AS al principio y el uso indebido de comunidades para desviar el tráfico de formas que su sistema de supervisión no detecta, ya que las rutas siguen siendo «válidas».
Las medidas de mitigación son de carácter operativo, no relacionadas con el producto: validación del origen mediante RPKI, límites máximos de prefijos, filtros de prefijos en cada sesión de eBGP, autenticación de pares y BGPsec cuando sea posible. Si su respuesta a la pregunta «¿somos vulnerables a una fuga de rutas procedente de nuestro proveedor de acceso?» es «el cortafuegos lo detendrá», no será así. El cortafuegos detecta los paquetes que llegan. No se da cuenta de que llegaron por un camino que no debería existir.
El sincero fracaso del equipo azul: , al considerar el enrutamiento como un «problema del equipo de redes», aislado del ámbito de la seguridad. Tanto en un ejercicio como en la realidad, el enrutamiento es sinónimo de seguridad.
Capa 4: Transporte
Aquí hay menos complicaciones, pero los aspectos básicos siguen siendo importantes: protección contra inundaciones SYN, tiempos de espera TCP razonables, tener en cuenta que una sesión TCP inactiva puede ser secuestrada si se producen fugas de números de secuencia, y vectores de amplificación UDP en cualquier servicio que tenga expuesto (DNS, NTP, memcached, CLDAP). La mayoría de los defensas lo hacen con soltura. El error en el punto L4 no suele consistir en la detección. Se trata de una exposición de « ». Servicios a los que se puede acceder desde segmentos desde los que no debería ser posible acceder a ellos.
Capas 5 y 6: Sesión y presentación
En la práctica, se trata de «TLS y todo lo que lo rodea». Algoritmos de cifrado débiles, certificados caducados o validados de forma incorrecta, errores de configuración en la reanudación de sesiones y TLS mutuo que, en realidad, no es mutuo porque el servidor no verifica la cadena de certificados del cliente. Los escenarios de «Locked Shields» suelen incluir configuraciones erróneas de TLS como trampa deliberada. Los defensores que se limitan a comprobar que «HTTPS está activado» pasan por alto este aspecto.
La otra cuestión subestimada del L5/6 es la gestión de sesiones de las aplicaciones: identificadores de sesión predecibles, tokens que no se renuevan y JWT sin firma. Se trata de L7 vulnerabilidades en el sentido que les da la OWASP, pero se sitúan en la intersección entre la sesión y la presentación, y constituyen la forma en que un atacante que ya ha conseguido un punto de apoyo logra acceder a una identidad de larga duración.
Nivel 7: Aplicación
Es aquí donde se concentran, de hecho, la mayoría de las herramientas defensivas, razón por la cual la mayoría de los defensores tienden a pensar en este ámbito de forma instintiva. Vulnerabilidades web, comportamiento del malware, uso indebido de la autenticación y fallos en la lógica de las API. Nada de eso carece de importancia, simplemente es algo muy habitual, y su pila ya lo tiene en cuenta. El error que hay que corregir es justo el contrario: si, tras treinta minutos de trabajo en un incidente, sigue buscando una explicación « L7 » cuando los síntomas no coinciden, vuelva a revisar los pasos anteriores.
El cortafuegos no es el tema central
Una hipótesis de trabajo basada en años de informes posteriores a los ejercicios «Locked Shields» y en las actividades profesionales cotidianas que los sustentan: el ingeniero medio con experiencia del equipo azul concede demasiada importancia a la detección y muy poca a la configuración. La detección es lo que hace que sus herramientas se vendan. La configuración es lo que realmente determina si se gana o se pierde la ronda.
A useful pre-engagement 5 step checklist for an experienced defender, in the order an attacker thinks about them:
- ¿Se ha reforzado la seguridad de la capa 2 en todos los conmutadores de acceso: seguridad de puertos, supervisión DHCP, DAI, BPDU Guard, sin DTP y VLAN de gestión separada?
- ¿Se autentifican las sesiones de los protocolos de enrutamiento, con filtros «max-prefix» y «prefix» en cada par eBGP? ¿Se aplica realmente la validación de la RPKI, o simplemente está habilitada?
- ¿Se encuentran los planos de gestión (OOB, iDRAC/iLO/IPMI, gestión de conmutadores y consolas de hipervisor) en un segmento al que el atacante no pueda acceder desde un terminal de usuario comprometido?
- ¿Se verifica la configuración de TLS, en lugar de darse por sentada?, ¿incluida la validación del certificado de cliente cuando se afirma que se utiliza mTLS?
- A continuación, el conjunto de herramientas L7 : reglas de WAF, cobertura de EDR, detecciones de SIEM y guías de respuesta a incidentes.
El orden es importante. Los cuatro primeros puntos son aquellos en los que se pierden rondas de forma imperceptible antes incluso de que comience la fase de « » (IR) . Además, son los elementos que menos probabilidades tienen de aparecer en una diapositiva de revisión trimestral, ya que no generan alertas cuando funcionan correctamente.
Dónde encaja Tanium (una vez que se han sentado las bases)
Quiero ser sincero en cuanto al alcance. Tanium no autentifica a sus pares de BGP. No configura la inspección dinámica de ARP en sus conmutadores de acceso. Los cuatro primeros puntos de la lista de comprobación anterior corresponden a la ingeniería de redes, y ninguna plataforma de terminales puede sustituir esa labor.
Sin embargo, en cuanto vuelve a subir por la pila, el panorama cambia. Porque, una vez que el plano de red está configurado correctamente, la siguiente pregunta es: ¿sabe realmente qué se está ejecutando en cada terminal? ¿Se le han aplicado los parches, se ha reforzado y se ha configurado tal y como usted cree? ¿Ejecutar los servicios que debe, y nada más?
Esa es la capa en la que implementamos Tanium en Locked Shields 2026. Durante el periodo de emisión en directo, la plataforma ofreció:
- Inventario en tiempo real de todos los servidores del parque informático para Windows y Linux, incluidos los segmentos que se incorporaron a mitad del ejercicio
- La lista de materiales de software y la visibilidad a nivel de biblioteca abarca todos los puntos finales, hasta el nivel de los componentes y las versiones
- Datos sobre vulnerabilidades vinculados directamente a la corrección: ; localice la biblioteca vulnerable e implemente la corrección desde la misma consola
- Implementación automática del agente de Tanium en los hosts recién detectados, sin necesidad de una cola de incorporación manual
- Distribución y actualización de los agentes antivirus y EDR de los socios , implementados junto con Tanium en todo el parque informático desde una única consola
- Aplicación de parches de terceros para sistemas operativos y a gran escala , como las actualizaciones acumulativas de Windows, .NET, SharePoint, el núcleo de Linux y los parches de bibliotecas
- Se implementaron y volvieron a aplicar en todo el entorno scripts de refuerzo , de modo que ningún servidor quedara sin configurar
- La rotación de credenciales locales se implementó con una periodicidad frecuente para limitar la vida útil de cualquier contraseña robada
- Paquetes personalizados de respuesta ante incidentes , elaborados bajo presión e implementados en la flota, que abarcan la implementación de reglas de cortafuegos, la limpieza de rastros de persistencia y la eliminación de implantes.
- Detección proactiva de amenazas ( ) en todo el parque de terminales desde una única consola
- Entrega de comandos basada en agentes como alternativa cuando las rutas de red estándar se veían afectadas
Nada de eso sustituye a una correcta comprensión de «Layer 2 ». Todo deja de funcionar si no sabe qué puntos finales tiene. Ambas disciplinas son complementarias. Los equipos que obtienen buenos resultados en Locked Shields funcionan en paralelo: un plano de red reforzado en la base y un conjunto de terminales totalmente gestionado y con visibilidad completa en la parte superior.
Conclusión
«Locked Shields» es impresionante, y el trabajo con infrarrojos que muestra es auténtico. Sin embargo, la experiencia sigue demostrando, año tras año, que los defensas con experiencia se imponen en las líneas más sólidas. El equipo que haya protegido el ARP y el DHCP en el segmento de acceso, haya autenticado sus sesiones de enrutamiento y haya segmentado su plano de gestión superará, por término medio, al equipo que cuente con un manual de estrategias SOAR más sofisticado.
Si hay algo que debe recordar de esta publicación: , la próxima vez que se produzca un fallo y su primer impulso sea abrir la consola del cortafuegos, abra primero show mac address-table o show ip bgp summary . La respuesta se encuentra allí con más frecuencia de lo que le gustaría admitir. A continuación, una vez que el plano de red funcione correctamente, asegúrese de disponer de una plataforma de terminales real que se integre en él. Empecemos por lo básico. La plataforma, en segundo lugar. En ese orden.
Cifras y citas de «Locked Shields 2026 » a través de ; CCDCOE, ; SHAPE OTAN; y detalles del escenario del ejercicio confirmados a través de ; SANS Institute.
. Imagen destacada de: Blue Team 10 @ Locked Shields
