Esta semana, el INCIBE-CERT publicó dos vulnerabilidades críticas en productos Cisco ampliamente desplegados en redes corporativas. CVE-2026-20160 permite a un atacante remoto no autenticado ejecutar comandos con privilegios de administrador a través de la API. CVE-2026-20093 permite saltarse la autenticación por completo. Ninguna de las dos requiere credenciales previas.
Supón que uno de esos dispositivos está en tu red. El parche existe, pero aún no se ha aplicado. Un atacante lo explota. Tiene acceso de administrador a tu infraestructura.
La pregunta que un pentesting no puede responder es: ¿qué pasa a continuación? ¿Lo detecta tu SOC? ¿En cuánto tiempo? ¿Puede el atacante moverse lateralmente antes de que alguien reaccione?
Eso es exactamente lo que mide un ejercicio de Red Team.
La diferencia que importa: vulnerabilidad vs. capacidad de detección
Un pentesting identifica vulnerabilidades técnicas en un sistema o conjunto de activos definidos. Su objetivo es encontrar fallos antes de que lo haga un atacante real. Es una prueba orientada a la superficie de ataque.
Un ejercicio de Red Team no busca vulnerabilidades en el sentido convencional. Su objetivo es simular a un adversario real —un grupo APT, un competidor con recursos, un atacante con motivación concreta— y responder una pregunta diferente: ¿cuánto daño puede hacer alguien que ya ha entrado antes de que tu organización lo detecte?
El MITRE ATT&CK Framework, mantenido por la organización MITRE, documenta las tácticas, técnicas y procedimientos (TTPs) de los grupos de amenaza activos. Un ejercicio de Red Team bien ejecutado emula esas TTPs en el entorno real del cliente, sin avisar al equipo de seguridad, para que la simulación refleje condiciones de ataque auténticas.
La diferencia práctica:
- El pentesting responde: "¿Tienes vulnerabilidades que un atacante podría explotar?"
- El Red Team responde: "Si un atacante las explotara, ¿lo detectarías?"
Ambas preguntas son necesarias. No son equivalentes.
Las tres preguntas que solo un Red Team puede responder
1. ¿Tu SOC ve lo que debería ver?
Un SOC (Security Operations Center) o servicio MDR (Managed Detection & Response) procesa alertas y eventos. Pero la calidad de esa detección depende de si las reglas, los playbooks y las integraciones están calibradas para detectar comportamiento malicioso real, no solo ruido.
En los ejercicios de Red Team que realizamos en Hard2bit, uno de los hallazgos más frecuentes es que el SOC genera alertas sobre el comportamiento del Red Team que nunca llegan a un analista: o quedan enterradas en el volumen de alertas de bajo nivel, o las reglas de correlación no las priorizan correctamente.
Un atacante que pasa 72 horas en una red sin ser detectado no es infrecuente. En un entorno sin Red Team, ese dato es desconocido.
2. ¿Cuánto tiempo tarda tu organización en detectar y reaccionar?
Las métricas estándar en operaciones de seguridad son el MTTD (Mean Time to Detect) y el MTTR (Mean Time to Respond). Ambas miden el tiempo desde que ocurre una técnica de ataque hasta que se genera una alerta, y desde la alerta hasta la contención.
El problema es que muchas organizaciones calculan estos valores sobre incidentes ya conocidos, no sobre ataques reales que superaron las detecciones. Un Red Team mide el MTTD y el MTTR en condiciones adversariales reales: el atacante no avisa, no reduce el ritmo, no excluye sistemas sensibles.
La diferencia entre un MTTD de 4 horas y uno de 4 días puede ser la diferencia entre contener un incidente y gestionar una brecha con impacto regulatorio.
3. ¿Hasta dónde puede llegar el atacante?
Los marcos regulatorios como NIS2 (Directiva (UE) 2022/2555, artículo 21) y DORA (Reglamento (UE) 2022/2554, artículo 26) exigen que las organizaciones evalúen periódicamente su capacidad de detección y respuesta ante incidentes. DORA en particular requiere pruebas de resiliencia que incluyan escenarios adversariales para entidades de alto impacto.
Un Red Team genera la evidencia técnica que respalda ese cumplimiento: rutas de ataque documentadas, técnicas utilizadas mapeadas contra MITRE ATT&CK, tiempos de detección medidos, y recomendaciones concretas de mejora.
¿Cuándo tiene sentido para una empresa mediana?
No toda organización necesita un Red Team. Tiene sentido cuando:
Ya tienes un pentesting anual en marcha. El Red Team no sustituye al pentesting; lo complementa. Si aún no identificas y parcheas vulnerabilidades sistemáticamente, un Red Team revelará problemas que ya deberías conocer.
Tienes un SOC o MDR activo. El Red Team valida que ese SOC funciona. Sin equipo de detección activo, el ejercicio mide algo que no existe.
Tu perfil regulatorio lo justifica. Empresas en sectores financiero, industrial, infraestructuras críticas o administración pública con obligaciones NIS2 o DORA tienen motivación normativa directa, además de la técnica.
Quieres saber el dato real, no el estimado. Si el comité de dirección pregunta "¿cuánto tiempo tardaríamos en detectar un ataque como el de [incidente reciente en el sector]?", un Red Team es la única forma de responder con datos propios en lugar de benchmarks de mercado.
Cómo estructuramos los ejercicios en Hard2bit
En Hard2bit ejecutamos ejercicios de Red Team con emulación de adversario específico: seleccionamos el grupo APT cuyo perfil de ataque es más relevante para el sector y las características del cliente, y ejecutamos sus TTPs documentadas en MITRE ATT&CK en el entorno real.
El ejercicio no lo sabe el equipo de seguridad del cliente. Sí lo sabe la dirección, que autoriza el alcance y los límites. Este enfoque —denominado blind Red Team— es el que genera los resultados más representativos, porque el equipo azul reacciona como lo haría ante un atacante real.
La duración habitual está entre 4 y 12 semanas, en función del tamaño del entorno y la complejidad del objetivo definido. El entregable final incluye:
- Rutas de compromiso documentadas paso a paso
- Técnicas mapeadas contra MITRE ATT&CK
- MTTD y MTTR medidos por fase del ataque
- Gaps de detección identificados en el SOC
- Plan de mejora priorizado por impacto
Conclusión
Un pentesting dice si tienes vulnerabilidades. Un Red Team dice si tu organización sobreviviría a que alguien las explotara.
Ambas preguntas son necesarias. La segunda es la que suelen hacer los CISOs que han tenido que gestionar un incidente real.
Si quieres saber cómo respondería tu organización ante un ataque con las características de los CVEs de Cisco publicados esta semana —acceso remoto sin autenticación, movimiento lateral, escalada de privilegios— es exactamente el tipo de escenario que diseñamos en nuestros ejercicios.
Habla con nuestro equipo para valorar si un Red Team tiene sentido en tu contexto actual y qué alcance sería el adecuado.
Referencias
- INCIBE-CERT: Múltiples vulnerabilidades en productos Cisco, abril 2026 — https://www.incibe.es/incibe-cert/alerta-temprana/avisos
- MITRE ATT&CK Framework — https://attack.mitre.org/
- Directiva NIS2 (UE) 2022/2555, artículo 21 — medidas de gestión de riesgos de ciberseguridad
- Reglamento DORA (UE) 2022/2554, artículo 26 — pruebas avanzadas de resiliencia operativa digital
- ENISA, 2026 European Cybersecurity Certification Conference: "Security claims must be proven — not promised" — https://www.enisa.europa.eu/events/2026-european-cybersecurity-certification-conference