Qué es un Red Team: guía completa para empresas

Un Red Team es un equipo ofensivo que simula un ataque real y completo contra tu organización para medir si tu defensa lo detecta a tiempo y responde bien. No buscamos una lista larga de vulnerabilidades como en un pentesting clásico: buscamos entrar, persistir y conseguir un objetivo concreto (tomar control de Active Directory, exfiltrar datos sensibles, llegar al CEO) mientras tu Blue Team intenta cazarnos sin saber que estamos dentro. La diferencia con un pentest es de fondo: el pentest mide qué falla; el Red Team mide qué pasa cuando alguien lo aprovecha. Un ejercicio típico dura entre 6 y 16 semanas, combina OSINT, phishing dirigido, evasión de EDR y movimiento lateral, y termina con un debriefing honesto que suele cambiar prioridades de inversión en seguridad durante el siguiente año.

Qué es un Red Team

Un Red Team es un grupo de profesionales de ciberseguridad ofensiva que emula la conducta, las herramientas y los objetivos de un atacante real contra una organización concreta. La pregunta que responde no es "¿qué vulnerabilidades tengo?" sino "¿podría un grupo organizado hoy comprometer mi negocio sin que lo viéramos venir?".

El término viene del ámbito militar de la Guerra Fría. La RAND Corporation usaba "equipos rojos" para pensar como el adversario y poner a prueba planes de defensa. La transposición al mundo digital es exacta: en lugar de simular un ataque a una base, simulamos el compromiso de tu infraestructura para descubrir las grietas que un atacante motivado encontraría antes de que las encuentre él.

En la práctica, un ejercicio de Red Team:

• Empieza sin información privilegiada (modelo black-box) o con un punto de partida acordado (assumed breach).
• Persigue objetivos de negocio, no checklists técnicos: control del dominio, acceso a la base de datos de clientes, lectura de correos del comité de dirección.
• Usa cualquier vector razonable: phishing, ingeniería social telefónica, implants en USB, accesos físicos, vulnerabilidades expuestas en la web, fugas de credenciales en dark web.
• Se realiza sin previo aviso al equipo defensivo (Blue Team), salvo a un grupo reducido conocido como White Team que sí está al tanto y autoriza el ejercicio.
• Mide detección y respuesta, no solo explotación: ¿cuánto tarda el SOC en alertar tras el primer movimiento sospechoso? ¿se aísla el endpoint comprometido? ¿se cazan las credenciales reutilizadas?

Es deliberadamente incómodo. Y debería serlo: si todos los implicados se sintieran cómodos, no estaríamos midiendo la realidad.

Red Team vs Blue Team vs Purple Team: las diferencias en una tabla

Estos tres términos se mezclan constantemente en los pliegos. La distinción no es académica: cambia el coste, el calendario y, sobre todo, qué se mide.

La regla rápida: Red Team mide capacidad de detección bajo presión real; Purple Team forma al Blue Team mientras se atacan técnicas concretas. Si tu SOC nunca ha visto a un atacante moviéndose por dentro, hace falta primero Purple para enseñar y luego Red para examinar. Si ya tienes detecciones maduras y quieres una nota honesta, ve directamente a Red.

Qué hace exactamente un Red Team durante el ejercicio

Tras la planificación con el White Team, el equipo arranca por la fase menos visible y más decisiva: reconocimiento. Aquí no se ataca nada todavía; se construye un mapa.

Durante días o semanas, el Red Team rastrea OSINT público para entender la organización: organigramas en LinkedIn, dominios y subdominios olvidados, repositorios públicos con secretos filtrados, sistemas expuestos en Shodan, credenciales corporativas filtradas en combolists, proveedores externos con acceso a tu red. El objetivo es responder: ¿cómo entraría yo si fuera un atacante con presupuesto y paciencia?

Después llega el acceso inicial. Aquí lo que funciona casi siempre es lo aburrido: un correo de phishing con un señuelo creíble (una factura, un compartido de SharePoint falso, una invitación a una reunión interna), una combo de credenciales filtradas reutilizadas, o una vulnerabilidad de día N sin parchear en un servicio expuesto. Spoiler: el vector glamuroso del 0-day es el menos habitual.

Una vez dentro, el ejercicio cambia de tempo:

• Establecimiento de C2 (Command & Control) discreto, evitando dominios quemados y herramientas conocidas que el EDR detectaría al instante.
• Escalada de privilegios local para conseguir, por ejemplo, NT AUTHORITY\SYSTEM o root.
• Movimiento lateral entre máquinas saltando con técnicas como pass-the-hash, Kerberoasting o explotación de relaciones de confianza.
• Persistencia mediante tareas programadas, cuentas de servicio, GPOs maliciosas, implants en software legítimo.
• Acción sobre objetivos: exfiltración simulada, acceso a sistemas críticos, demostración de impacto.

Y todo esto sin disparar las alertas del SOC, a ser posible. Aquí está la parte difícil. Un buen Red Team no es el que mete diez exploits; es el que entra, vive seis semanas dentro y sale habiendo demostrado que pudo haber hecho cualquier cosa, sin que nadie levantara la mano.

¿Es un Red Team un grupo de hackers éticos?

Sí, técnicamente lo es: son profesionales que usan habilidades ofensivas con autorización contractual para mejorar la seguridad de sus clientes. Pero llamar a un Red Team "hackers éticos" se queda corto y mete ruido.

Un bug hunter en un programa de bug bounty también es un hacker ético. Un consultor que hace pentesting de una API también lo es. La diferencia con un Red Team es el alcance, la autorización y el objetivo:

• Alcance: no se limita a una aplicación o un perímetro. Es la organización entera.
• Autorización: hay un contrato firmado, un White Team identificado y normas de combate (ROE) por escrito sobre qué se puede y qué no se puede tocar.
• Objetivo: no es encontrar vulnerabilidades para que las arregles; es demostrar impacto de negocio y medir tu detección.

Por eso preferimos hablar de profesionales de ciberseguridad ofensiva o red teamers y reservar "hacker ético" para conversaciones más generales. La etiqueta importa menos que entender qué se contrata.

Tipos de ejercicios: TTX, full-scope, intelligence-led

No todos los ejercicios de Red Team son iguales. Conviene conocer los formatos antes de pedir presupuesto, porque la diferencia de coste entre un TTX y un TLPT es de uno o dos órdenes de magnitud.

Tabletop Exercise (TTX)

Un Tabletop Exercise es un ejercicio conversacional, no técnico. El equipo se sienta alrededor de una mesa (literal o virtualmente) y un facilitador presenta un escenario de ataque por fases. En cada fase, los participantes describen qué harían, qué herramientas usarían, qué decisiones tomarían.

• Duración: medio día a dos días.
• Coste: bajo.
• Cuándo: validar planes de respuesta, formar al comité de crisis, practicar la coordinación con legal y comunicación.

No es Red Team en sentido estricto, pero a menudo se vende como tal. Si en un pliego pone "Red Team" y la propuesta detalla únicamente sesiones presenciales sin acceso a sistemas, es un TTX y debería costar lo que cuesta un TTX.

Full-scope Red Team

El ejercicio "completo": acceso técnico real, vectores múltiples, objetivos de negocio, sin previo aviso al Blue Team. Aquí entra todo: phishing, implants, intrusión física opcional, ingeniería social, evasión de EDR, persistencia.

• Duración: típicamente 6 a 16 semanas.
• Coste: medio a alto, según alcance.
• Cuándo: evaluación honesta de madurez, validación de inversión en SIEM/SOAR/EDR, preparación para una auditoría exigente.

Es el formato que la mayoría de empresas tiene en mente cuando dice "queremos un Red Team".

Red Team intelligence-led (TIBER-EU / TLPT)

Variante regulada del full-scope con dos características diferenciales: el ejercicio se hace sobre sistemas en producción y se basa en inteligencia de amenazas específica del sector y de la entidad. Es la metodología que el BCE consolidó como TIBER-EU en 2018 y que DORA convierte en obligatoria, bajo el nombre TLPT, para entidades financieras designadas, con frecuencia mínima cada 3 años.

• Duración: 12 a 20 semanas habitualmente.
• Coste: alto. Rangos públicos del sector hablan de 80.000 a 250.000 € según complejidad.
• Cuándo: lo exige la normativa (DORA, TIBER local) o el regulador.

Si tu organización no es entidad financiera designada, no necesitas TLPT. Si lo es, necesitas proveedor acreditado: en TIBER-EU y TLPT entramos al detalle de los requisitos.

Red Team vs Pentesting: cuándo usar cada uno

Esta confusión es la que más cuesta dinero a las empresas. Compran "un Red Team" cuando lo que necesitan es un pentest, o piden un pentest barato cuando necesitan medir la cadena completa.

La regla práctica: si tu Blue Team todavía no detecta un escaneo masivo desde fuera, no estás listo para Red Team. Necesitas pentesting más tuning de detecciones primero. Saltar pasos es tirar el dinero.

Para decidir entre pentesting clásico y Red Team, pregúntate: ¿quiero saber qué vulnerabilidades tengo o quiero saber qué pasaría si alguien las aprovecha? La primera pregunta es pentest. La segunda es Red Team.

Las fases de un ejercicio de Red Team

Aunque cada proveedor tiene su variante, la cadena básica está estandarizada y se alinea con la Cyber Kill Chain y con MITRE ATT&CK. En Secra trabajamos con esta secuencia:

1. Planificación y normas de combate (ROE). Definimos objetivos, alcance, sistemas excluidos, ventanas horarias, mecanismo de kill switch y firmas. Aquí se acuerda qué pasa si alguien del SOC nos detecta y llama a las autoridades, porque pasa.
2. Threat intelligence específica del cliente. Estudiamos qué grupos APT atacan al sector, qué TTPs usan según MITRE ATT&CK, qué credenciales de la organización están filtradas, qué vectores son los más probables.
3. Reconocimiento (OSINT y enumeración pasiva). Sin tocar infraestructura del cliente. Mapa de personas, sistemas y proveedores.
4. Desarrollo de infraestructura ofensiva. Servidores C2, redirectores, dominios calientes y fríos, droppers únicos para el ejercicio, evasión específica del EDR del cliente.
5. Acceso inicial. Phishing, ingeniería social, vulnerabilidad expuesta, credenciales filtradas, físico. Lo que funcione primero.
6. Establecimiento de presencia. C2 estable, persistencia mínima viable, OPSEC.
7. Escalada y movimiento lateral. Privilegios locales, salto entre activos, abuso de relaciones de confianza, Kerberos.
8. Acción sobre objetivos. Demostración de impacto reproducible y verificable: capturas, hashes de archivos exfiltrados, registros de sesión.
9. Análisis de detección y respuesta. Cruce de la timeline del Red Team con los logs del SOC para identificar qué se vio, qué se ignoró y qué pasó completamente desapercibido.
10. Reporte y debriefing conjunto. Informe ejecutivo, informe técnico y sesión de debriefing abierto con el Blue Team. Esta sesión es, de lejos, la parte que más valor genera.

Es habitual que las fases 5 a 8 se iteren varias veces si el primer vector se quema. Un ejercicio realista contempla Plan B, C y D desde el principio.

Cuándo necesita una empresa un Red Team

No todas las organizaciones están listas para un Red Team. Pedirlo demasiado pronto desperdicia dinero y desmoraliza al equipo defensivo. Estos son los criterios honestos:

Sí tiene sentido si...

• Ya hay un SOC funcionando, propio o externo, con detecciones maduras.
• Has hecho pentests recientes y los hallazgos están en su mayoría remediados.
• Hay SIEM/EDR desplegados en producción y alguien revisa las alertas.
• La organización tiene un plan de respuesta a incidentes ensayado al menos una vez.
• Hay presupuesto para los hallazgos, no solo para el ejercicio.
• El comité de dirección ha aprobado la incomodidad del proceso.

No tiene sentido todavía si...

• No existen detecciones básicas (un escaneo desde Internet pasa desapercibido).
• Los pentests anteriores están sin remediar.
• No hay equipo defensivo, ni interno ni externo.
• Buscas un sello "hicimos Red Team" sin intención de actuar sobre el resultado.

En ese segundo escenario, lo que necesitas no es Red Team: es pentesting, endurecimiento de configuraciones, tuning de detecciones y, eventualmente, un Purple Team. Subir la nota antes de pedir el examen.

Cómo elegir un proveedor de Red Team

El mercado español tiene boutiques excelentes y consultoras que aprovechan el término sin tener equipo. Estos son los filtros que recomendamos a nuestros clientes cuando comparan ofertas:

1. Equipo nominal en la propuesta. Pide CVs, nicks de plataformas como HackTheBox, certificaciones (OSCP, OSEP, CRTO, CRTL, OSED, GXPN). Si la oferta no nombra a nadie, no hay equipo.
2. CVEs propias publicadas. Un Red Team que descubre vulnerabilidades en software comercial demuestra capacidad técnica real, no solo uso de Cobalt Strike. Pídelos por CVE.
3. Acreditación cuando aplica. Si vas a TLPT bajo DORA, solo proveedores acreditados según los RTS publicados por las ESAs. Sin esto, el ejercicio no cuenta.
4. Alineación con MITRE ATT&CK. Mapeo explícito de cada técnica usada al framework. Si el informe que presentan como muestra no incluye TTPs, falta rigor.
5. Plan de transparencia con el Blue Team. Un buen Red Team no oculta su trabajo cuando termina. Tiene que poder sentarse con el SOC y reproducir cada paso para que aprendan.
6. Política de OPSEC. Cómo gestionan la infraestructura ofensiva, los datos exfiltrados y la destrucción al cierre del ejercicio.
7. Referencias verificables. Pide hablar con clientes anteriores. Una boutique seria los facilita.

Si te ofrecen "Red Team" en menos de 4 semanas y por una fracción del rango habitual, no es Red Team. Es marketing.

Sobre nosotros: en Secra somos un equipo pequeño de ciberseguridad ofensiva con experiencia en banca, sector público y crítico, y CVEs publicadas a nuestro nombre. Si encajamos, hablamos; si no, te decimos a qué proveedor del sector deberías hablar y por qué.

Preguntas frecuentes sobre Red Team

¿Cuánto cuesta un ejercicio de Red Team?

Depende del alcance, la duración y si incluye vector físico o intelligence-led. Para un full-scope corporativo, los rangos públicos del sector se mueven entre 40.000 y 150.000 € para 6-12 semanas. Un TLPT bajo DORA sube a 80.000-250.000 € por la complejidad regulada y la duración mínima. Lo más útil es pedir 2-3 propuestas detalladas con jornadas y perfiles, y comparar coste por jornada y experiencia del equipo, no totales aislados.

¿Cuánto dura un ejercicio típico?

Un full-scope corporativo entre 6 y 16 semanas desde kick-off a debriefing. Un TLPT entre 12 y 20. La fase de reconocimiento e intelligence suele ocupar el primer tercio, lo que sorprende a quienes esperan acción inmediata.

¿El Red Team puede romper sistemas en producción?

Es uno de los riesgos que se acota en las normas de combate. En la mayoría de ejercicios full-scope, se evitan acciones que puedan generar denegación de servicio y se trabaja en horario acordado. Un TLPT, en cambio, se ejecuta en producción por diseño: ahí el riesgo se gestiona con mayor cantidad de salvaguardas (kill switch, comunicación con el White Team, ventanas controladas).

¿Cómo medir si el Red Team ha sido un éxito?

No se mide por número de objetivos comprometidos. Se mide por lo que aprendió el Blue Team y por las decisiones que cambió la dirección. Un ejercicio en el que el Red Team falla en algunos objetivos pero el SOC mejoró sus detecciones tres veces es un éxito. Uno en el que el Red Team comprometió todo pero nadie cambió nada después es un desastre.

¿Qué diferencia hay entre Red Team y APT simulation?

Casi ninguna en la práctica. APT simulation (o adversary emulation) suele referirse a un ejercicio Red Team enfocado a emular un grupo APT concreto (por ejemplo APT29, Lazarus o Sandworm) usando solo sus TTPs documentadas. Es un Red Team con guion. Útil cuando una organización quiere validar detecciones contra una amenaza específica de su sector.

¿Necesito tener un Blue Team interno para hacer Red Team?

No, pero necesitas alguien que vaya a recibir el resultado y actuar. Si tu defensa es un MSSP externo, puede valer si trabajan codo con codo durante el debriefing. Si no hay nadie que vaya a leer el informe ni cambiar nada, ahórrate el ejercicio.

¿Red Team y Bug Bounty son lo mismo?

No. Un programa de bug bounty recompensa hallazgos puntuales de investigadores externos sobre un alcance acotado y público. Un Red Team es un equipo dedicado, con plan, con objetivos de negocio, durante un periodo concreto, sin notificar a la defensa. Pueden coexistir y de hecho se complementan: el bug bounty mantiene presión continua sobre el perímetro; el Red Team da una foto profunda y puntual de la cadena completa.

---

Siguiente paso

Si has llegado hasta aquí, probablemente estás valorando si tu organización está lista. Dos caminos según en qué punto estés:

• Si todavía no tienes pentests recientes ni detecciones básicas afinadas: empieza por una auditoría web/móvil o de infraestructura y, en paralelo, despliega o externaliza un SOC.
• Si ya tienes una base defensiva razonable y quieres una prueba honesta: cuéntanos el contexto en contacto y te decimos si tiene sentido un ejercicio Red Team y, si encaja con nuestro pipeline, cómo lo plantearíamos. Si no encajamos, te orientamos hacia otro proveedor del sector que pueda hacerlo bien.

Y si lo tuyo es DORA y necesitas un TLPT acreditado, la lectura previa obligada es TIBER-EU y TLPT: Red Team intelligence-led en banca.