El red teaming es una simulación autorizada de un adversario real que se ejecuta a la vez contra las personas, los procesos y la tecnología de una organización, con un objetivo concreto y sin ser detectada. El éxito se mide por lo que alcanzan los atacantes y por lo que notan los defensores, no por cuántas vulnerabilidades aparecen en el ejercicio.
En el reporte State of Attacks 2026 de Fluid Attacks, que cubre las pruebas de seguridad realizadas entre el 1 de enero y el 31 de diciembre de 2025, el 87 % de las vulnerabilidades de severidad crítica se identificó mediante revisión manual y no con herramientas automatizadas. Esas son las fallas que un adversario encadena en una ruta de ataque, y las que un escáner tiene menos probabilidad de encontrar.
Esta página explica la disciplina: qué es el red teaming, cómo se ejecuta un ejercicio, los marcos que lo estructuran, en qué se diferencia del pentesting y qué exigirle a un proveedor. También deja clara la posición de Fluid Attacks.
¿Qué es el red teaming?
El red teaming es una simulación de adversario dirigida a un objetivo. Un equipo de especialistas ofensivos, autorizado por escrito y por lo general desconocido para los defensores, elige un objetivo concreto —privilegios de administrador de dominio, un sistema de pagos, una base de datos de clientes determinada— y avanza hacia él con la mezcla de explotación técnica, ingeniería social y acceso físico que permitan las reglas de enfrentamiento.
El sigilo es la restricción que define al red teaming, y es lo que lo separa de cualquier otra evaluación. Si los defensores saben que el ataque viene, se comportan distinto y el ejercicio deja de medir aquello para lo que existe. Rafael Alvarez, CTO y cofundador de Fluid Attacks, lo planteó sin rodeos en un texto sobre atacar sin anunciarse:
"It's absurd that, in these attacks, red team members report progress or request permissions from blue team members…" (es absurdo que, en estos ataques, los miembros del red team reporten avances o pidan permisos a los del blue team).
El alcance es la organización completa, no un sistema. Por eso el red teaming llega a empleados, proveedores, lectores de credenciales y mesas de ayuda, y por eso termina en un relato —cómo un atacante pasó de afuera al objetivo— y no en una lista de hallazgos.
Tres cosas que no es:
No es un pentest más largo: un pentest busca encontrar tantas fallas como sea posible dentro de un límite definido. Un ejercicio de red teaming se detiene apenas tiene una cadena que funciona.
No es una evaluación de vulnerabilidades: los puntajes de severidad describen fallas aisladas. El red teaming describe qué pasa cuando varias se usan juntas.
No es breach and attack simulation: el BAS repite técnicas conocidas de forma automática y continua. El red teaming depende de personas improvisando contra un objetivo vivo.
¿Por qué es importante el red teaming?
El red teaming es importante porque pone a prueba las dos capacidades que ningún escaneo evalúa: si los defensores detectan una intrusión mientras ocurre, y si la respuesta de la organización la contiene. Todo lo demás que mide una evaluación es una condición previa para esas dos.
La detección es una afirmación hasta que alguien la prueba
Un despliegue de EDR, una regla de correlación en el SIEM y un manual de respuesta a incidentes son afirmaciones sobre lo que pasaría durante un ataque. Siguen siendo afirmaciones hasta que un adversario se mueve por el entorno y alguien revisa qué se disparó, quién lo vio y cuánto tardó en actuar.
Esa medición es el producto del red teaming, y es la razón por la que Alvarez sostiene que a los defensores hay que dejarlos en la incertidumbre. Si no pueden distinguir a un atacante simulado de uno real, escribe, el blue team "will always be in a state of alert and respond according to defined procedures" (siempre estará en estado de alerta y responderá según los procedimientos definidos). Un equipo en alerta permanente es el punto, no un efecto secundario.
La vía de entrada rara vez es la que defendiste
Dos brechas lo explican mejor que cualquier argumento. La intrusión a Target en 2013 es la ruta de ataque de libro que va del proveedor al núcleo, y el informe del Comité de Comercio del Senado de Estados Unidos de marzo de 2014 la analizó como una kill chain, documentando los puntos donde el ataque pudo detenerse. Está ampliamente documentado que los atacantes entraron con credenciales robadas a un proveedor externo antes de llegar a los sistemas de pago: una ruta que ninguna evaluación limitada a una sola aplicación encontraría.
En 2021, el CEO de Colonial Pipeline declaró ante el Comité de Seguridad Nacional y Asuntos Gubernamentales del Senado de Estados Unidos que los atacantes "exploited a legacy virtual private network (VPN) profile that was not intended to be in use" (explotaron un perfil heredado de VPN que no debía estar en uso) (testimonio escrito, 8 de junio de 2021). El aviso de CISA sobre el ransomware DarkSide mapea a MITRE ATT&CK las técnicas que el grupo usó después. Ningún escáner marca un perfil de VPN olvidado, porque funciona exactamente como fue diseñado. El red teaming parte de la pregunta del atacante, no de la de la herramienta, y trata ese perfil por lo que es: una puerta sin vigilancia.
Las cadenas empiezan en la autenticación débil
Esto no es anecdótico. En el reporte State of Attacks 2026 de Fluid Attacks, el tipo de vulnerabilidad que concentró la mayor porción de la exposición total al riesgo fue la ausencia o evasión del mecanismo de autenticación, con el 19,1 %. La autenticación es a la vez el control más valioso de derrotar para un adversario y el que las organizaciones más suelen dar por resuelto, y por eso un ejercicio de red teaming casi siempre va primero por ahí.
El red teaming y Fluid Attacks
Fluid Attacks no ofrece red teaming
Fluid Attacks no vende red teaming ni ejecuta ejercicios de red team. Su oferta son pruebas continuas de seguridad de aplicaciones a través de once técnicas: SAST, AI SAST, DAST, SCA, CSPM, MAST, secret scanning, container scanning, Secure Code Review, Pentesting as a Service (PTaaS) y Reverse Engineering. Ninguna de las once es una simulación de adversario contra defensores a los que nunca se les avisó.
El tema no es ajeno. Los pentesters de Fluid Attacks tienen certificaciones hechas específicamente para esta disciplina —OSEP, CRTP, CRTM, Red Team Operator, Active Directory Red Team Specialist, AWS y Azure Red Team Expert— y las 59 herramientas que usan están publicadas abiertamente, entre ellas BloodHound, CrackMapExec, Rubeus, mimikatz y Covenant. El conocimiento operativo del red teaming está en la casa. El ejercicio no está en la lista de precios.
Qué hace Fluid Attacks en su lugar, y por qué
El argumento a favor de las pruebas continuas frente a los ejercicios periódicos es un argumento sobre qué caduca. Una evaluación puntual describe un sistema que deja de existir en el momento en que entra el siguiente commit, y la brecha se amplía con cada despliegue.
Las cifras detrás de esa posición son concretas. En el benchmark de Fluid Attacks sobre 36 herramientas AppSec de terceros, ejecutado contra un objetivo de evaluación con 1.201 vulnerabilidades en 105 categorías CWE, un pentester de Fluid Attacks que trabajó 49 días encontró 1.076 de ellas: 89,6 % de recall con 100 % de precision. El mejor resultado automatizado de la misma prueba, el del propio escáner de Fluid Attacks, fue de 22,7 % de recall, y el promedio de las otras 34 herramientas fue de 1,7 %. Lo más revelador: 743 vulnerabilidades, el 61,9 % del total, las encontró solo el pentester, invisibles para todas las herramientas de la comparación.
Recall y precision por herramienta; el pentester encontró 743 vulnerabilidades que ninguna herramienta detectó.
Qué cubre el red teaming que las pruebas continuas no
Decir el límite importa más que el discurso de venta. Las pruebas continuas de seguridad de aplicaciones examinan código, infraestructura, configuración de nube y dependencias. No llaman a un empleado haciéndose pasar por soporte de TI, no entran a un edificio detrás de alguien que sostiene la puerta y no miden cuánto tarda un centro de operaciones de seguridad en escalar una alerta a las 3 a. m.
Esas son superficies de ataque reales, y el red teaming es la disciplina construida para probarlas. Una organización que necesita esa medición necesita un ejercicio de red teaming y debería contratarlo. Decir lo contrario sería vender un escáner como sustituto de un simulacro de incendio.
Dónde se encuentran los dos
Las vulnerabilidades que el red teaming encadena son las mismas que las pruebas continuas encuentran y cierran primero. La base de datos pública de vulnerabilidades de Fluid Attacks cataloga 384 tipos de debilidad mapeados a 182 requisitos de seguridad, 2.021 correcciones y 66 estándares indexados, entre ellos MITRE ATT&CK, donde 36 mitigaciones de ATT&CK están ligadas a requisitos numerados, y NIST SP 800-115.
Fluid Attacks mapea 36 mitigaciones de MITRE ATT&CK a sus propios requisitos de seguridad numerados.
Tres entradas caen justo en la mitad de una ruta de ataque típica: escalamiento de privilegios, ausencia o evasión del mecanismo de autenticación y credenciales administrativas almacenadas en memoria caché. Cada una trae un tiempo esperado de remediación: 60 minutos para la primera. Cerrarlas sale mejor que enterarse en un ejercicio de que eran eslabones de una cadena.
Cómo elegir un proveedor de red team
Esto es lo que conviene verificar antes de firmar.
Acreditación basada en inteligencia: CREST acredita proveedores bajo disciplinas creadas para este trabajo, entre ellas Intelligence Led Penetration Testing (STAR) y STAR-FS. Pregunta qué acreditación tiene el proveedor y para qué servicio, y después confírmalo tú mismo en el CREST Marketplace en vez de creerle a una presentación comercial.
Reglas de enfrentamiento por escrito, antes de empezar: objetivos, sistemas fuera de alcance, técnicas permitidas, contactos de escalamiento y fechas de retroalimentación. La regla de Alvarez es el piso correcto: "The red team must have complete authorization on paper and by email and all forms of legal protection…" (el red team debe tener autorización completa en papel y por correo, y todas las formas de protección legal).
Un criterio de alerta temprana pactado de antemano: define qué hallazgos son lo bastante graves para detener el ejercicio y contenerse de inmediato, y cuáles esperan al informe. Sin esa línea, un proveedor o interrumpe todo el tiempo o se sienta sobre algo urgente.
Independencia, y prueba de que la verificaste: TIBER-EU pone la carga sobre ti, al señalar que la entidad evaluada "should carry out due diligence to make sure its chosen provider meets all the requirements" (debe hacer la debida diligencia para asegurarse de que el proveedor elegido cumple todos los requisitos). Revisar al proveedor es tu trabajo, no el suyo.
Evidencia sobre la que puedas actuar: acuerda los formatos antes de que empiece el ejercicio. Fluid Attacks publica los formatos de evidencia que soporta —capturas anotadas, grabaciones en video del ataque, reportes ejecutivos en PDF y técnicos en XLSX— y una lista comparable es justo exigírsela a cualquiera.
Consentimiento y propiedad: el proveedor debe confirmar la autorización del dueño de cada activo en alcance. En el alcance del SLA documentado de Fluid Attacks, la propiedad es uno de los cuatro criterios que delimitan qué se puede probar.
Red teaming, pentesting y BAS no son alternativas
Estos tres se presentan casi siempre como una escalera de madurez, lo que confunde: responden preguntas distintas y una organización puede necesitar los tres a la vez. Dos variables los separan con claridad: quién sabe que el ataque está ocurriendo y qué tan amplio es el objetivo.
| Breach and attack simulation | Pentesting | Red teaming |
Pregunta que responde | ¿Nuestros controles detienen técnicas conocidas? | ¿Qué es explotable en este sistema? | ¿Puede un adversario llegar al objetivo sin ser detectado? |
Objetivo | Controles de seguridad | Un sistema o aplicación definidos | La organización completa, incluidas personas e instalaciones |
Defensores enterados | Sí | Por lo general sí | No, por diseño |
Lo ejecuta | Una plataforma automatizada | Pentesters | Especialistas ofensivos, a menudo con apoyo de inteligencia de amenazas |
Termina en | Un reporte de cobertura de controles | Una lista de vulnerabilidades con evidencia | Un relato de una o varias rutas de ataque |
Cadencia | Continua | Continua o periódica | Periódica, de semanas a meses por ejercicio |
De los tres, el red teaming es el único que se juzga por pasar inadvertido, y esa diferencia arrastra todo lo demás: alcance, duración, costo y a quién se le avisa. Ejecutar red teaming contra una empresa que nunca ha hecho revisión segura de código es comprar una confirmación cara de algo que pruebas más baratas habrían encontrado en una tarde.
Red team, blue team, purple team y white team
En un ejercicio maduro aparecen cuatro equipos, y confundirlos es la fuente de confusión más común cuando se habla de red teaming.
Equipo | Rol | Actividades típicas |
🔴 Red team | Ofensiva | Simulación de adversarios, sigilo, encadenamiento de exploits en rutas de ataque, prueba de la respuesta a incidentes provocándola |
🔵 Blue team | Defensa | Detección con SIEM y EDR, análisis forense, contención de amenazas, endurecimiento de configuraciones |
🟣 Purple team | Colaboración | Sesiones en vivo donde se ejecutan técnicas ofensivas mientras los defensores afinan sus reglas de detección en tiempo real |
⚪ White team | Control | Autoriza el ejercicio, custodia las reglas de enfrentamiento, arbitra incidentes, es el único grupo interno que sabe |
Los nombres no son universales en el red teaming: TIBER-EU llama al cuarto grupo control team y suma un quinto del lado del regulador.
El purple teaming es un modo de trabajo y no un departamento permanente, y cambia medición por aprendizaje. Apenas los atacantes anuncian lo que hacen para que los defensores miren, el ejercicio dejó de ser red teaming: pasa a ser excelente para afinar reglas de detección e inútil para averiguar si esas reglas se habrían disparado solas.
Cómo se ejecuta un ejercicio de red team
Un ejercicio de red teaming recorre seis fases, y la única que la mayoría de las organizaciones planea bien es la primera. La tabla mapea cada fase con lo que los defensores deberían poder ver y con el tipo de debilidad del catálogo de Fluid Attacks que suele hacerla posible.
Fase | Qué hacen los atacantes | Qué deberían detectar los defensores | Debilidad relacionada |
1. Objetivos y reglas | Definen objetivo, alcance, técnicas permitidas y ruta de escalamiento con el white team | Nada: esta fase es invisible a propósito | — |
2. Reconocimiento | Inteligencia de fuentes abiertas sobre empleados, proveedores, activos expuestos y tecnologías | Enumeración inusual de activos públicos | — |
3. Acceso inicial | Phishing y otras formas de ingeniería social, reutilización de credenciales, servicios expuestos, entrada física | Inicios de sesión anómalos, dispositivos nuevos, alertas del gateway de correo | |
4. Escalamiento de privilegios | Abuso de roles mal configurados y credenciales en caché para obtener acceso administrativo | Creación de cuentas privilegiadas, manipulación de tokens | |
5. Movimiento lateral | Movimiento lateral entre hosts y relaciones de confianza hacia el objetivo | Tráfico este-oeste entre sistemas que normalmente no se hablan | |
6. Objetivo y reporte | Alcanzan el objetivo, documentan la cadena, hacen la retroalimentación con todos los equipos | Preparación de datos y volúmenes de exfiltración | — |
Las herramientas que usa el red teaming son conocidas y en buena parte públicas: BloodHound mapea rutas de ataque en Active Directory, mimikatz cosecha credenciales, CrackMapExec automatiza el movimiento entre hosts y frameworks como Covenant corren el comando y control. Los pentesters de Fluid Attacks usan muchas de esas mismas herramientas en pruebas continuas, y la lista completa está publicada en su documentación.
Hay un punto sobre la última fase que vale la pena decir, porque se maneja mal de forma rutinaria. Las vulnerabilidades encontradas durante un ejercicio de red teaming normalmente no se remedian hasta que el ejercicio cierra: arreglarlas sobre la marcha corta la cadena que el equipo venía construyendo y destruye la demostración del impacto. La excepción es el criterio de alerta temprana pactado en la fase uno. Todo lo demás espera al informe.
Los marcos sobre los que se construye un ejercicio de red team
Tres obras de referencia cargan casi todo el peso en el red teaming, y un proveedor que no pueda fijar su posición frente a las tres está improvisando.
MITRE ATT&CK
MITRE ATT&CK es una base de conocimiento curada de tácticas y técnicas de adversarios tomadas de observaciones del mundo real. Les da a los dos lados de un ejercicio de red teaming un mismo vocabulario: los atacantes describen lo que hicieron con identificadores de técnica, y los defensores contrastan su telemetría contra esos mismos identificadores. Fluid Attacks mapea 36 mitigaciones de ATT&CK a sus propios requisitos de seguridad en su base de datos pública.
NIST SP 800-115
La Technical Guide to Information Security Testing and Assessment del NIST, publicada en septiembre de 2008, es la referencia formal para planear evaluaciones técnicas, analizar hallazgos y construir estrategias de remediación. La mayoría de los procesos de compra todavía apunta a ella cuando especifica trabajo ofensivo, red teaming incluido. Fluid Attacks mapea sus secciones a 25 de sus propios requisitos.
TIBER-EU, DORA y CREST
TIBER-EU —Threat Intelligence-based Ethical Red Teaming— fue publicado por el Banco Central Europeo y los bancos centrales nacionales de la UE en mayo de 2018 como el marco para pruebas basadas en inteligencia sobre entidades financieras. Separa cinco equipos: el blue team, evaluado sin saberlo; el control team, el pequeño grupo interno que sí sabe; un proveedor de inteligencia de amenazas; los evaluadores del red team; y el TIBER cyber team, que supervisa el cumplimiento del lado de la autoridad. La debida diligencia sobre los proveedores recae en la entidad evaluada.
La Digital Operational Resilience Act hizo después obligatorio el threat-led penetration testing para las entidades financieras significativas de la UE, bajo el Artículo 26, y TIBER-EU se actualizó en 2024 para alinearse con ella. Por eso la demanda de red teaming crece más rápido en sectores regulados.
Cuándo una organización está lista para el red teaming
Una organización está lista para el red teaming cuando su respuesta a "¿qué está roto en nuestro software?" se volvió aburrida. Si un programa de pruebas de seguridad cierra fallas de forma continua y el backlog abierto no tiene nada crítico, la pregunta que queda —si alguien notaría a un intruso— vale la pena pagarla.
Los datos sugieren que la mayoría todavía no llega. En el reporte State of Attacks 2026 de Fluid Attacks, el 70 % de los sistemas evaluados tenía al menos una vulnerabilidad de severidad alta o crítica, frente al 53,3 % en 2024, y la tasa general de remediación llegó al 62,2 % al cierre de 2025. Los sistemas que usaron un CI Gate para bloquear compilaciones inseguras llegaron al 72 %, contra el 58 % de los que no.
Tres señales de preparación son concretas: las vulnerabilidades se remedian en días y no en trimestres, existe un proceso documentado de respuesta a incidentes y ya se ensayó, y alguien es dueño de la decisión de escalar de madrugada. Sin la tercera, el red teaming solo va a probar que nadie estaba mirando.
Conclusiones
El red teaming mide algo que ningún escáner reporta: si una organización nota y detiene a un adversario real. Es simulación de adversarios sobre personas, procesos y tecnología, juzgada por los objetivos alcanzados y las alertas que nadie vio, y se gana su costo cuando las preguntas más baratas ya tienen respuesta.
Fluid Attacks ofrece pruebas continuas con pentesters y escáneres, que cierran las vulnerabilidades que un adversario encadenaría y que, en su propio benchmark, sacaron a la luz 743 fallas que ninguna herramienta automatizada de una comparación de 36 detectó. Los dos son complementos y no competidores, y quien venda el segundo como el primero está vendiendo un detector de humo como un simulacro de incendio.
Preguntas frecuentes
¿Cuál es la diferencia entre red teaming y pentesting?
El alcance y el sigilo. El pentesting examina un sistema definido e intenta encontrar en él todas las fallas explotables, por lo general con conocimiento de los defensores. El red teaming apunta a la organización completa, persigue un objetivo específico, incluye a las personas y la seguridad física, y se ejecuta sin avisarle al blue team.
¿Debería el blue team saber de un ejercicio de red team?
No. Solo el white team debería saber. El ejercicio existe para medir detección y respuesta en condiciones realistas, y los defensores que esperan un ataque escalan más rápido de lo que lo harían un día cualquiera. TIBER-EU incorpora esa separación en el marco, evaluando al blue team sin que lo sepa.
¿Deben corregirse las vulnerabilidades durante un ejercicio de red team?
Por lo general no: esperan al informe final. Remediar a mitad del ejercicio rompe la cadena de ataque que el equipo está construyendo y destruye la evidencia del impacto real. La excepción es un criterio pactado antes de empezar, que defina qué hallazgos son lo bastante críticos para disparar una alerta y una contención inmediatas.
¿Alguna regulación exige red teaming?
En los servicios financieros de la UE, en la práctica sí. La Digital Operational Resilience Act exige threat-led penetration testing para las entidades financieras significativas, y TIBER-EU es el marco que las autoridades nacionales usan para ejecutarlo. Fuera de ese sector, el red teaming suele ser una decisión de riesgo y no una obligación legal.
¿Fluid Attacks hace red teaming?
No. Fluid Attacks no ofrece red teaming ni ejecuta ejercicios de red team. Provee pruebas continuas de seguridad de aplicaciones combinando IA, escáneres y pentesters en once técnicas. En su benchmark contra 36 herramientas de terceros, un pentester de Fluid Attacks encontró 1.076 de 1.201 vulnerabilidades —89,6 % de recall—, incluidas 743 que ninguna herramienta automatizada detectó.
Encuentra las rutas antes de que alguien las recorra
Nuestros pentesters y escáneres prueban tu software de forma continua, así las vulnerabilidades que un adversario encadenaría se cierran mucho antes de que valga la pena un ejercicio de red teaming. Prueba gratuita · Contáctanos.
Empieza ya con el PTaaS de Fluid Attacks
