Red Team: simulación de adversario real para medir tu capacidad de detección

Un pentesting encuentra vulnerabilidades en un alcance acotado y conocido de antemano. Un Red Team simula lo que haría un atacante real con un objetivo concreto —acceder a tu ERP, exfiltrar datos de clientes, comprometer el dominio— combinando vectores técnicos, sociales y, cuando aplica, físicos, sin que tu equipo de seguridad sepa que está ocurriendo. La pregunta que responde no es "¿qué vulnerabilidades tenéis?", sino "¿nos habríais detectado?".

¿Por qué un pentesting no basta para saber si estáis preparados?

Un pentesting técnico es imprescindible, pero responde a una pregunta distinta: dentro de un alcance definido y en un plazo fijo, ¿qué vulnerabilidades existen? El equipo defensivo suele saber que está ocurriendo, lo que cambia su comportamiento. Un atacante real no avisa, no se limita a un único vector y no se detiene ante el primer control que encuentra: combina phishing dirigido, explotación técnica, movimiento lateral y, si hace falta, ingeniería social presencial, durante semanas, buscando el camino más silencioso hacia un objetivo de negocio concreto. Un Red Team es la única forma de comprobar si tu SOC, tus alertas y tu equipo de respuesta funcionan de verdad cuando nadie les avisa de antemano.

Qué cubre un ejercicio de Red Team

Definición de objetivo de negocio (crown jewels): qué activo o dato debe "capturar" el equipo rojo para considerar el ejercicio exitoso
Reconocimiento OSINT: superficie expuesta, empleados, tecnologías, filtraciones previas de credenciales
Vector de entrada inicial: phishing dirigido (spear phishing), explotación de servicios expuestos o ingeniería social
Post-explotación y movimiento lateral: escalada de privilegios, pivoting entre sistemas, persistencia
Evasión activa de EDR/AV y de las capacidades de detección del SOC (blue team)
Simulación de exfiltración de datos hacia infraestructura controlada, sin extraer datos reales de producción
Ingeniería social presencial cuando el alcance lo incluye: acceso físico a instalaciones, tailgating, dispositivos USB
Medición del tiempo de detección (MTTD) y de respuesta (MTTR) reales del equipo defensivo

Metodología del ejercicio (alineada con TIBER-EU / MITRE ATT&CK)

Definición de objetivo y reglas de intervención: Acordamos con dirección o CISO el objetivo de negocio, los sistemas estrictamente fuera de alcance y el protocolo de parada de emergencia. El equipo defensivo NO es informado del ejercicio.
Inteligencia de amenazas y reconocimiento: Construimos el perfil de ataque con TTPs (tácticas, técnicas y procedimientos) de actores reales relevantes para tu sector, y mapeamos la superficie expuesta: dominios, empleados, tecnologías, credenciales filtradas.
Intrusión inicial: Ejecutamos el vector de entrada acordado —phishing dirigido, explotación de un servicio expuesto o ingeniería social— buscando el punto de apoyo inicial con el menor ruido posible.
Post-explotación y persistencia: Escalamos privilegios, nos movemos lateralmente hacia el objetivo definido y establecemos persistencia evadiendo activamente EDR, AV y las alertas del SOC, documentando cada TTP usado.
Consecución del objetivo y cierre: Alcanzamos (o intentamos alcanzar) el objetivo de negocio acordado. Entregamos un informe conjunto con la cronología completa del ataque, qué detectasteis y cuándo, y un plan de mejora priorizado para el equipo azul.

Qué recibes al finalizar el ejercicio

Informe ejecutivo: si se alcanzó el objetivo, en cuánto tiempo y con qué nivel de sigilo
Cronología técnica completa del ataque (kill chain) con TTPs mapeados a MITRE ATT&CK
Línea temporal de detección: qué alertas se dispararon, cuáles no y por qué
Sesión conjunta con el SOC/equipo azul (purple teaming) para revisar cada técnica y mejorar reglas de detección
Plan de mejora priorizado: qué reforzar primero según el impacto real demostrado, no una lista genérica de hardening
Re-test opcional de los vectores de detección corregidos

¿Cuándo tiene sentido un Red Team en vez de un pentesting?

Ya tenéis un programa de pentesting maduro y las vulnerabilidades críticas obvias están corregidas
Tenéis SOC propio o externalizado y necesitáis validar que detecta ataques reales, no solo que existe
Estáis sujetos a DORA y vuestra entidad puede ser designada para TLPT (Threat-Led Penetration Testing)
Necesitáis justificar ante dirección una inversión en detección y respuesta con evidencia real, no hipotética
Habéis sufrido un incidente y necesitáis validar que las medidas correctivas realmente funcionan bajo un ataque real
Sector financiero, energético, sanitario o infraestructura crítica con exigencias regulatorias de resiliencia avanzada

Preguntas frecuentes sobre Red Team

¿En qué se diferencia exactamente un Red Team de un pentesting de Active Directory?

Un pentesting de Active Directory analiza el entorno AD en profundidad con un alcance técnico conocido, buscando el máximo de vulnerabilidades de configuración y escalada de privilegios. Un Red Team parte de fuera del perímetro, con un objetivo de negocio concreto, sin que el equipo defensivo lo sepa, y solo entra en AD si ese es el camino más realista hacia el objetivo — es una prueba de la organización completa, no del entorno AD en sí.

¿Es lo mismo que el TLPT que exige DORA?

El TLPT es un Red Team ejecutado bajo el marco regulatorio TIBER-EU, con proveedores acreditados específicamente y coordinación con el supervisor, obligatorio para entidades financieras designadas como críticas. Nuestro Red Team estándar sigue la misma lógica metodológica y es la preparación ideal antes de un TLPT formal; para el TLPT regulatorio en sí, te orientamos sobre el proceso de acreditación necesario.

¿Qué pasa si el equipo defensivo nos detecta el primer día?

Es un resultado válido y valioso — significa que vuestras defensas funcionan para ese vector. En ese caso, con vuestro consentimiento, podemos ajustar el ejercicio para seguir probando otros vectores o técnicas de evasión más avanzadas, maximizando el aprendizaje del ejercicio.

¿Incluye ingeniería social presencial y acceso físico?

Solo si se acuerda explícitamente en el alcance. No es un componente por defecto: algunas organizaciones lo incluyen (tailgating, dispositivos USB, suplantación de personal técnico) y otras prefieren limitarlo a vectores digitales. Se define en la fase de reglas de intervención.