Planificación de un engagement de Red Team

Definición

La planificación de un red team engagement es el proceso estructurado de definir objetivos, alcance, reglas de operación y planes de campaña antes de ejecutar cualquier acción ofensiva. Una planificación deficiente equivale a una campaña sin rumbo: el objetivo número 1 siempre es satisfacer los objetivos del cliente.

Contexto

Sin objetivos claros y concretos no existe estructura de planificación válida. Los objetivos del cliente marcan el tono para toda la documentación y planificación posterior. Ver también: Red Team Fundamentals, OPSEC (Red Team).

Desarrollo

1) Scope y Objetivos del Cliente

El primer paso es definir conjuntamente con el cliente sus objetivos. Esto determina si el engagement será:

• General (internal/network pentest): menos enfocado, TTPs estándar.
• Focused (adversary emulation): emula un APT específico según el sector de la empresa (ej.: APT38 para instituciones financieras).

Ejemplo de objetivos (Global Enterprises):

1. Identificar misconfigurations y debilidades de red (foco en sistemas externos).
2. Evaluar efectividad de sistemas EDR.
3. Evaluar postura de seguridad general (SIEM, remediación, segmentación DMZ/interna).
4. Uso de white cards permitido según downtime.
5. Evaluar impacto de exposición/exfiltración de datos.

Scope típico (lo que NO se puede hacer/atacar):

• No system downtime is permitted under any circumstances.
• No DDoS/DoS.
• No malware dañino (ransomware, etc.).
• No exfiltración de PII.
• Ataques en 10.0.4.0/22 permitidos; 10.0.12.0/22 prohibidos.
• Interacción con *.bethechange.xyz prohibida.

Regla clave: el scope lo fija el cliente. El red team solo puede objetar si afecta al engagement; jamás puede modificarlo unilateralmente.

2) Rules of Engagement (RoE)

Documento legalmente vinculante que formaliza objetivos y scope con detalle de expectativas entre ambas partes. Es el primer documento oficial del proceso y requiere autorización de ambas partes (puede acompañarse de NDA).

Template de referencia: redteam.guide RoE Template

3) Campaign Planning

Aplica la información del scope y RoE a planes operativos concretos. Cada red team tiene su metodología interna; a continuación se describe un conjunto de cuatro planes:

Referencia adicional: redteam.guide engagement checklist

4) Engagement Plan — CONOPS

El Concept of Operations (CONOPS) es el resumen ejecutivo del engagement; se redacta desde una perspectiva semi-técnica asumiendo que el lector tiene conocimiento mínimo o nulo.

Componentes mínimos del CONOPS:

• Nombre del cliente
• Proveedor de servicios
• Timeframe
• Objetivos generales / fases
• Otros objetivos de entrenamiento (ej.: exfiltración)
• Herramientas/técnicas de alto nivel planificadas
• Threat group a emular (si aplica)

5) Engagement Plan — Resource Plan

Detalla fechas, conocimiento requerido y recursos. Se redacta en forma de listas/bullets (no narrativa):

• Header: personal redactor, fechas, cliente.
• Engagement Dates: Recon, Initial Compromise, Post-Exploitation, fechas misceláneas.
• Knowledge Required (opcional): por fase.
• Resource Requirements: personal, hardware, cloud, otros.

6) Operations Plan

Documento flexible que expande el CONOPS con detalles específicos. Incluye el plan de comunicaciones del red cell.

Secciones habituales:

• Header (personal, fechas, cliente)
• Condiciones de parada/halt
• Personal asignado
• TTPs y ataques planificados
• Communications plan (vectr.io / Email / Slack)
• RoE (opcional)

7) Mission Plan

Documento interno del red cell con acciones exactas a ejecutar.

Detalle mínimo:

• Objetivos
• Operadores asignados
• Exploits/ataques
• Targets (usuarios, máquinas, objetivos)
• Variantes del plan de ejecución

Distinción clave: el Operations Plan habla el lenguaje del negocio/cliente; el Mission Plan habla el lenguaje del operador red cell.

Ejemplos

Jerarquía de documentación (resumen):

1
Client Objectives + Scope
2
        ↓
3
Rules of Engagement (RoE)  ← Legalmente vinculante
4
        ↓
5
Engagement Plan
6
  ├── CONOPS (resumen ejecutivo semi-técnico)
7
  └── Resource Plan (fechas, personal, hardware)
8
        ↓
9
Operations Plan
10
  ├── Personal y responsabilidades
11
  ├── TTPs planificados
12
  └── Communications Plan
13
        ↓
14
Mission Plan
15
  └── Comandos exactos + tiempos + operadores
16
        ↓
17
Remediation Plan
18
  └── Informe + consulta de remediación

Pitfalls

• Objetivos vagos: “mejorar la seguridad” no es un objetivo accionable. Exige objetivos concretos (hosts, datos, sistemas).
• Scope definido por el red team: el scope es territorio exclusivo del cliente. El red team puede objetar, nunca imponer.
• Saltarse la RoE: operar sin documento legalmente vinculante expone a ambas partes a consecuencias legales.
• Mission plan demasiado rígido: el engagement evoluciona; el mission plan debe tener variantes contempladas.
• No tener stopping conditions: sin condiciones de parada claras, el red team puede causar daños no previstos (ej.: producción caída).
• No separar Operations Plan del Mission Plan: el cliente no necesita ver los comandos exactos; el operador no necesita el resumen ejecutivo para operar.

Diagrama — Flujo de planificación

graph TD
    A[Reunión con cliente] --> B[Client Objectives + Scope]
    B --> C[Rules of Engagement - RoE]
    C --> D[Engagement Plan]
    D --> D1[CONOPS]
    D --> D2[Resource Plan]
    D --> E[Operations Plan]
    E --> F[Mission Plan]
    F --> G[Ejecución del Engagement]
    G --> H[Remediation Plan + Report]

Referencias

• TryHackMe — Red Team Engagements: https://tryhackme.com/room/redteamengagements
• RoE Template: https://redteam.guide/docs/templates/roe_template/
• Red Team Checklist: https://redteam.guide/docs/checklists/red-team-checklist/
• APT38 (para scoping por industria): https://web.archive.org/web/20230325143301/https://content.fireeye.com/apt/rpt-apt38

Notas relacionadas

• Red Team Fundamentals
• Threat Intelligence for Red Teams
• OPSEC (Red Team)
• Command and Control (C2)
• Red Team Playbook (Guia avanzada)