Parte: 7 — Red Team y operaciones ofensivas · Fuente: Red Team Development and Operations (Vest & Tubberville) ⏱️ Duración estimada: 90 min · Nivel: Intermedio
Entender qué distingue realmente a un ejercicio de Red Team de un pentest tradicional: no es "hacking más avanzado", sino un cambio de filosofía. El alumno aprenderá a encuadrar una operación adversarial en torno a objetivos de negocio, a definir Rules of Engagement (RoE) sólidas y a articular por qué emular a un adversario mejora la defensa mucho más que un listado de vulnerabilidades.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Pentest vs Red Team vs VA | Evita vender un servicio por otro y fija expectativas |
| 2 | Objetivos ("crown jewels") | Un Red Team persigue metas, no cobertura exhaustiva |
| 3 | Rules of Engagement | Define lo permitido; protege legal y operativamente |
| 4 | Assumed breach | Ahorra tiempo cuando el foco es detección, no perímetro |
| 5 | Threat-informed vs opportunistic | Emular a un actor real da realismo y relevancia |
| 6 | Trusted agent y white cell | Coordina el ejercicio y evita incidentes reales |
| 7 | Métricas de éxito | Traduce el ejercicio en valor defensivo medible |
No es que el Red Team sea "un pentest con hackers mejores". Es que responde a una pregunta distinta. El pentest pregunta "¿qué vulnerabilidades explotables hay en este alcance?"; el Red Team pregunta "si un adversario real fuera a por nuestras joyas de la corona, ¿lo detectaríamos y responderíamos a tiempo?". La primera evalúa sistemas; la segunda evalúa a personas y procesos —el SOC, la detección, el plan de respuesta—. Confundirlas lleva al desastre comercial clásico: vender un Red Team a quien todavía no parchea lo básico, entregar un informe de tres hallazgos sigilosos y dejar al cliente pensando que "no encontraron nada".
Hay un continuo de madurez, no un ranking de dificultad:
| Servicio | Pregunta que responde | Métrica de éxito | Ruido tolerado |
|---|---|---|---|
| Vulnerability Assessment | ¿Qué debilidades conocidas tengo? | Cobertura y exhaustividad | Máximo (escaneo abierto) |
| Penetration test | ¿Qué puede explotar un atacante aquí? | Nº y severidad de vías demostradas | Alto (importa encontrar, no esconderse) |
| Red Team | ¿Detectamos y respondemos a un adversario con objetivo? | Tiempo a detección/respuesta y objetivos logrados | Mínimo (el sigilo es parte de la prueba) |
Cada uno es el correcto en un momento distinto de madurez. Un VA es la base; el pentest demuestra impacto; el Red Team solo aporta valor cuando ya existe una capacidad defensiva que medir.
Un pentest busca ancho (cubrir el alcance); un Red Team busca profundidad hacia una meta. Esa meta se expresa primero en lenguaje de negocio —"¿puede un externo leer la nómina en tres semanas sin ser visto?"— y luego se traduce en flags técnicas verificables: leer una tabla señuelo marcada, obtener credenciales de un DBA, alcanzar un segmento aislado. Las flags convierten el difuso "hackear la empresa" en un criterio binario de éxito, y evitan que el ejercicio degenere en una caza indiscriminada de bugs.
Gastar dos de tres semanas cruzando el perímetro por phishing suele ser malgastar el presupuesto cuando lo que la organización quiere saber es qué pasa después de la primera víctima —porque el phishing, con tiempo, siempre acaba funcionando—. El modelo assumed breach concede un punto de apoyo inicial (una workstation, un usuario de bajo privilegio) y enfoca el ejercicio en la post-explotación: movimiento lateral, escalada, detección. No es "hacer trampa"; es reconocer un hecho estadístico y comprar realismo donde de verdad importa.
Todo lo anterior solo es ético y seguro dentro de un marco escrito: las Rules of Engagement. Fijan qué sistemas están dentro y fuera de alcance, qué técnicas se prohíben (DoS, ransomware real, tocar dispositivos médicos o SCADA de producción), la ventana horaria y los contactos de escalado. En paralelo, una white cell (personas informadas del ejercicio) permite la deconfliction: cuando el SOC ve una alerta y no sabe si es un incidente real o el Red Team, un canal de confirmación evita activar un plan de crisis innecesario.
El entregable de un Red Team no es una lista de CVEs: es una medición de la defensa. Las tres métricas nucleares son el TTD (tiempo a detección: cuánto tardó el Blue Team en ver la actividad), el TTR (tiempo a respuesta: cuánto tardó en contenerla) y la cobertura (qué porcentaje de las técnicas ejecutadas generó una alerta). Estas cifras, más el camino narrado hasta las flags, son lo que convierte el ejercicio en mejoras concretas de detección —y el puente natural hacia el purple teaming, donde Red y Blue afinan juntos.
| Término | Definición concisa |
|---|---|
| Red Team | Emulación de un adversario con objetivo para medir detección y respuesta |
| Penetration test | Evaluación técnica que busca demostrar el máximo de vías explotables |
| Vulnerability Assessment (VA) | Inventario de debilidades conocidas, sin explotación profunda |
| Crown jewels | Activos críticos cuyo compromiso define el éxito del ejercicio |
| Flag | Meta técnica verificable derivada del objetivo de negocio |
| Rules of Engagement (RoE) | Contrato que fija alcance, técnicas permitidas, ventanas y contactos |
| Assumed breach | Empezar con un punto de apoyo ya concedido para evaluar la post-explotación |
| Threat-informed | Ejercicio guiado por la inteligencia de un adversario real |
| White cell | Personas informadas que supervisan el ejercicio y pueden pausarlo |
| Trusted agent | Contacto autorizado que confirma o desmiente actividad del ejercicio |
| Deconfliction | Proceso para distinguir una alerta del ejercicio de un incidente real |
| TTD | Tiempo a detección: cuánto tarda la defensa en ver la actividad |
| TTR | Tiempo a respuesta: cuánto tarda en contener la actividad |
| Cobertura de detección | Porcentaje de técnicas ejecutadas que generaron alerta |
| Purple team | Colaboración en tiempo real de Red y Blue para mejorar detecciones |
| Operation Charter | Documento breve que fija objetivo, flags, RoE y métricas del ejercicio |
Esta clase es de planificación; el "tooling" es documental. Prepara:
⚠️ Todo el ejercicio se plantea sobre una organización ficticia de laboratorio o con autorización escrita. La planificación sin autorización no ataca nada, pero define el marco legal que hace ético todo lo que viene después.
Como esta clase es conceptual, el laboratorio es un taller de planificación de un ejercicio para "ACME Corp":
Produce un documento de una página ("Operation Charter") para ACME Corp que contenga: objetivo de negocio, 3 flags, tipo de inicio, 6 RoE, un plan de deconfliction y 3 métricas de éxito. Criterio de aceptación: cualquier persona ajena podría leerlo y saber qué está autorizado, qué se persigue y cómo se medirá el éxito, sin ambigüedad.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| El cliente esperaba "todas las vulnerabilidades" | Se vendió Red Team pero se necesitaba un pentest; alinea expectativas antes de firmar |
| El equipo dispara alarmas y cunde el pánico | Falta deconfliction; establece un canal y un código con la white cell |
| El ejercicio se sale de alcance | RoE vagas; especifica sistemas, técnicas y ventanas con precisión |
| No hay forma de decir si "salió bien" | Objetivos no verificables; define flags concretas y medibles |
| Se toca producción crítica | Falta lista de exclusiones; marca sistemas prohibidos explícitamente |
❓ ¿Un Red Team siempre es "mejor" que un pentest? No. Si una organización aún no parchea lo básico, un pentest da más valor. El Red Team evalúa detección/respuesta; solo tiene sentido cuando ya existe una capacidad defensiva que medir.
❓ ¿Qué es "purple team" en este contexto? Cuando Red y Blue colaboran en tiempo real para mejorar detecciones. Lo veremos en la Clase 178; aquí basta saber que es el destino natural del valor del ejercicio.
❓ ¿El assumed breach no "hace trampa"? No: reconoce que el phishing eventualmente funciona y enfoca el presupuesto en lo que de verdad se quiere evaluar (¿detectamos y respondemos una vez dentro?).
Clase 160 — Reporte de análisis de malware