Plantilla de Informe de Red Team 2026: Estructura, Hallazgos y Resumen Ejecutivo

Un informe de red team es lo único que sobrevive al engagement. El acceso que obtuviste, las shells que dejaste, el domain admin que comprometiste — nada de eso importa si el informe no lo comunica claramente a quienes necesitan actuar.

La mayoría de los informes de red team fallan de una de dos maneras: están escritos para otros red teamers (y los ejecutivos los ignoran), o están tan simplificados para ejecutivos que el equipo técnico no puede remediar nada. Un buen informe habla a ambas audiencias al mismo tiempo.

Esta guía te da la plantilla completa — estructura, desglose sección por sección, formato de hallazgos, fórmula para el resumen ejecutivo, y el lenguaje que realmente mueve a las organizaciones a solucionar problemas.

Por Qué la Mayoría de los Informes de Red Team Fallan

Algunos patrones que se repiten constantemente:

Demasiado técnico de principio a fin. El resumen ejecutivo son tres páginas de CVE IDs y cadenas de exploit. El CISO lee el primer párrafo, hojea el resto y le pide a su equipo que “lo atiendan”. Nada se prioriza.

Demasiado vago en los hallazgos. “El sistema era vulnerable a escalación de privilegios.” Bien. ¿Cómo? ¿Por qué vía? ¿Reproducible cómo? El sysadmin intenta verificarlo, no puede, y lo cierra como “no se puede reproducir”.

Sin narrativa. Una lista de hallazgos no es un informe de red team. Un informe de red team cuenta la historia de lo que un atacante haría realmente — el camino desde el acceso inicial hasta el objetivo. La mayoría de los informes omite esto por completo.

Remediación como afterthought. “Parchea el sistema.” Útil. ¿Qué parche? ¿Qué versión? ¿Qué cambio de configuración? Cuando esta sección es vaga, la remediación se estanca.

La plantilla a continuación soluciona todo esto.

Estructura General del Informe

Un informe completo de red team tiene siete secciones:

1. Portada y Metadatos
2. Resumen Ejecutivo
3. Alcance y Reglas de Compromiso
4. Narrativa del Ataque
5. Hallazgos Técnicos
6. Matriz de Resumen de Riesgo
7. Hoja de Ruta de Remediación

Cada sección tiene una audiencia diferente. Los ejecutivos leen 1-2. Los gerentes de seguridad leen 1-4. Los equipos técnicos leen todo.

Sección 1: Portada y Metadatos

Mantenlo limpio. Campos requeridos:

Título del Informe:    Informe de Evaluación Red Team
Cliente:               [Nombre de la Organización]
Período de Evaluación: [Fecha de Inicio] – [Fecha de Fin]
Fecha del Informe:     [Fecha de Entrega]
Versión del Informe:   1.0 (Final)
Clasificación:         CONFIDENCIAL — DISTRIBUCIÓN RESTRINGIDA
Preparado Por:         [Nombre del Líder / Equipo Red Team]
Contacto:              [Email / Teléfono]

Agrega una lista de distribución si sabes quién debe recibirlo. Los informes de red team son documentos sensibles — la distribución no controlada es un riesgo real.

Sección 2: Resumen Ejecutivo

Esta es la sección más importante y la que se escribe peor consistentemente. Escríbela para alguien que tiene 90 segundos y ningún conocimiento técnico.

La fórmula:

Qué hicimos → Qué encontramos → Qué significa → Qué hacer al respecto

Extensión: Máximo una página. Dos párrafos cortos más una lista de viñetas.

Plantilla:

Durante [período], [Equipo/Empresa] realizó una evaluación de red team de [X días] del [descripción del entorno — p.ej., “perímetro externo, red interna y entorno de Active Directory”] de [Organización]. La evaluación simuló un actor de amenaza realista con el objetivo de [objetivos — p.ej., “obtener acceso no autorizado a sistemas financieros y exfiltrar datos sensibles”].

El equipo logró con éxito [resultado de alto nivel — p.ej., “comprometer completamente el dominio en 48 horas desde el acceso inicial, acceder a [X] sistemas sensibles y exfiltrar [Y] registros sin activar ninguna alerta de seguridad”]. La ruta de ataque principal explotó [causa raíz en una línea — p.ej., “una cuenta de usuario susceptible a phishing, una aplicación web interna sin parchar y permisos de Active Directory mal configurados”]. Estos hallazgos indican que un actor de amenaza motivado podría lograr [impacto al negocio — p.ej., “acceso total a datos de clientes y sistemas financieros con los controles de detección actuales”].

Hallazgos Críticos:

• [Hallazgo Crítico 1 — una oración, lenguaje de impacto al negocio]
• [Hallazgo Crítico 2]
• [Hallazgo Crítico 3]

Recomendación Clave: [Una oración — la acción más importante a tomar]

Qué evitar en el resumen ejecutivo:

• Números de CVE (nadie en el C-suite conoce CVE-2025-XXXXX)
• Jerga técnica sin traducción
• Voz pasiva (“se identificaron vulnerabilidades” → “encontramos”)
• Más de cinco viñetas
• Llamar “crítico” a todo (diluye la palabra)

Sección 3: Alcance y Reglas de Compromiso

Esta sección protege a ambas partes y establece el contexto para todo lo que sigue.

Incluir:

• Objetivos en alcance: Rangos IP, dominios, aplicaciones, ubicaciones físicas
• Objetivos fuera de alcance: Lo que fue explícitamente excluido
• Vectores de ataque probados: Red externa, phishing, físico, nube, inalámbrico, etc.
• Tipo de evaluación: Black box / gray box / white box / assumed breach
• Reglas de compromiso: ¿DoS prohibido? ¿Sistemas de producción fuera de límites? ¿Solo en horario laboral?
• Contactos de deconflicción: A quién llamar si algo falla
• Fechas de inicio/fin: Con timestamps si aplica

Tabla de alcance de ejemplo:

Sección 4: Narrativa del Ataque

Esto es lo que separa un informe de red team de una salida de escáner de vulnerabilidades. La narrativa del ataque cuenta la historia del engagement de forma cronológica — cómo entraste, cómo te moviste, a qué llegaste.

Escríbelo como un informe de inteligencia de amenazas sobre tu propia operación. Tercera persona, tiempo pasado, factual. Guía al lector a través de la kill chain.

Estructura:

4.1 Acceso Inicial

¿Cómo entraste? ¿Qué vector funcionó?

En el Día 1, el equipo red team identificó una oportunidad de phishing usando datos disponibles públicamente en LinkedIn. Se envió un correo de spear-phishing a tres empleados del departamento de finanzas. Un usuario hizo clic en el enlace e ingresó credenciales en un portal de inicio de sesión clonado. Las credenciales capturadas eran válidas para la VPN interna.

Incluir:

• Método utilizado
• Objetivo seleccionado y por qué
• Qué tuvo éxito (y qué falló, brevemente)
• Timestamp si aplica

4.2 Establecimiento de Foothold

¿Qué hiciste una vez adentro?

Con credenciales VPN válidas, el equipo se conectó a la red interna a las 14:23 del Día 1. La enumeración inicial de hosts identificó una estación de trabajo Windows 10 asignada al usuario comprometido. Se desplegó un beacon C2 mediante un documento con macro maliciosa enviado como adjunto de correo de seguimiento. La ejecución se confirmó a las 14:51. El beacon estableció comunicación saliente sobre HTTPS hacia la infraestructura C2 del equipo usando un canal con domain fronting.

4.3 Escalación de Privilegios

¿Cómo pasaste de usuario a algo más?

La cuenta de usuario comprometida tenía derechos de administrador local en 14 estaciones de trabajo adicionales, identificadas mediante análisis con BloodHound. El movimiento lateral a una estación de trabajo secundaria reveló una cuenta de servicio Kerberoastable (svc_backup) con contraseña débil. El hash fue crackeado offline en 6 minutos. La cuenta svc_backup tenía privilegios de Domain Admin mediante membresía anidada en grupos.

4.4 Movimiento Lateral

¿Cómo te expandiste?

Con privilegios de Domain Admin mediante svc_backup, el equipo extrajo NTDS.dit del controlador de dominio usando un ataque DCSync. Se extrajeron todas las 2.847 credenciales del dominio. Luego el equipo accedió al servidor de la aplicación financiera usando las credenciales cacheadas del CFO, obteniendo acceso a [X] registros.

4.5 Logro del Objetivo

¿Alcanzaste el objetivo declarado?

El equipo accedió a la base de datos financiera objetivo a las 09:14 del Día 3, exfiltrando exitosamente un conjunto de muestra de 500 registros para demostrar la ruta de ataque. La exfiltración completa de la base de datos (estimada en 1,2M de registros) sería factible en menos de 4 horas dado el ancho de banda disponible. Toda la ruta de ataque — desde el phishing inicial hasta la exfiltración de datos — se completó sin activar ninguna alerta en el SIEM.

4.6 Detecciones Fallidas

Opcional pero de alto valor. Documenta qué controles fallaron en detectarte.

Sección 5: Hallazgos Técnicos

Esta es la sección de evidencia detallada. Cada hallazgo tiene su propia entrada. Todos siguen el mismo formato.

Plantilla de Formato de Hallazgo

ID de Hallazgo:     RTF-001
Título:             [Título corto y descriptivo — no un nombre de CVE]
Severidad:          Crítica / Alta / Media / Baja / Informativa
Puntuación CVSS:    [Opcional, si aplica]
Estado:             Explotado / Identificado (no explotado) / Verificado

Sistemas Afectados:
  - [hostname / IP / URL]

Descripción:
  [2-3 oraciones explicando qué es la vulnerabilidad y por qué existe.
  Escribe para un sysadmin senior que la verificará y remediará.]

Evidencia:
  [Capturas de pantalla, salida de comandos, pasos de proof-of-concept.
  Suficiente para que otro profesional pueda reproducirlo.]

Impacto al Negocio:
  [¿Qué significa esto en términos de negocio? ¿Exposición de datos?
  ¿Interrupción operativa? ¿Riesgo regulatorio? ¿Daño reputacional?]

Pasos de Explotación (si fue explotado):
  1. [Paso 1]
  2. [Paso 2]
  3. [Resultado]

Remediación:
  [Pasos específicos y accionables. No "parchea el sistema" —
  "Aplica KB5XXXXXX, aplica la configuración de Group Policy X,
  rota la contraseña de la cuenta de servicio svc_backup y
  elimínala de Domain Admins."]

Referencias:
  - [Enlace CVE, aviso del proveedor, documentación relevante]

Niveles de Severidad — Úsalos de Forma Consistente

No inventes tus propias definiciones. Usa un estándar:

Importante: La severidad debe reflejar tanto la explotabilidad como el impacto en contexto. Una CVE Crítica en una máquina de prueba aislada no equivale a una Media en un sistema de pago público. Ajusta según corresponda y documenta tu razonamiento.

Ejemplo de Hallazgo Completo

ID de Hallazgo:     RTF-003
Título:             Active Directory Kerberoasting — Contraseña Débil en Cuenta de Servicio
Severidad:          Crítica
Estado:             Explotado — Domain Admin obtenido

Sistemas Afectados:
  - svc_backup (DOMINIO\svc_backup)
  - DC01.empresa.local (Controlador de Dominio)

Descripción:
  La cuenta de servicio DOMINIO\svc_backup tiene configurado un Service
  Principal Name (SPN) de Kerberos, haciéndola elegible para Kerberoasting.
  La cuenta utiliza una contraseña débil que fue crackeada offline en
  aproximadamente 6 minutos usando un wordlist estándar. La cuenta es miembro
  del grupo Domain Admins, proporcionando control total sobre el entorno de
  Active Directory.

Evidencia:
  [Captura: salida de GetUserSPNs mostrando svc_backup]
  [Captura: sesión de Hashcat crackeando el hash TGS]
  [Captura: ruta en BloodHound mostrando svc_backup → Domain Admins]

Impacto al Negocio:
  Compromiso total del entorno de Active Directory. Un atacante con acceso
  de Domain Admin puede crear cuentas backdoor, deshabilitar controles de
  seguridad, acceder a todos los sistemas y datos, y mantener acceso
  persistente indefinidamente. Este hallazgo por sí solo representa un
  compromiso organizacional completo.

Pasos de Explotación:
  1. Identificación de cuentas Kerberoastables: GetUserSPNs.py DOMINIO/user:pass -dc-ip 10.0.0.1 -request
  2. Se guardó el hash TGS y se ejecutó: hashcat -m 13100 hash.txt rockyou.txt
  3. Contraseña crackeada: "Verano2024!" (6 minutos, wordlist estándar)
  4. Se autenticó como svc_backup y se confirmó membresía en Domain Admins

Remediación:
  1. Rotar inmediatamente la contraseña de la cuenta de servicio svc_backup
     a una contraseña generada aleatoriamente de 25+ caracteres.
  2. Eliminar svc_backup del grupo Domain Admins — las cuentas de servicio
     deben operar con privilegios mínimos.
  3. Auditar todos los SPNs de cuentas con privilegios elevados:
     Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties MemberOf
  4. Considerar el uso de Group Managed Service Accounts (gMSA) que usan
     contraseñas complejas rotadas automáticamente administradas por AD.
  5. Habilitar alertas de ATA/Defender for Identity para patrones de Kerberoasting.

Referencias:
  - https://attack.mitre.org/techniques/T1558/003/
  - https://docs.microsoft.com/es-es/windows-server/security/group-managed-service-accounts/

Sección 6: Matriz de Resumen de Riesgo

Una página visual que da a los stakeholders una lectura rápida del panorama general de riesgo.

Tabla Resumen de Hallazgos:

Distribución por Severidad:

Crítica:    ■■■ (2)
Alta:       ■■■■■ (3)
Media:      ■■ (2)
Baja:       ■ (1)
Informativa: (0)

Resumen de Cadena de Ataque:

Correo Phishing → Captura de Credenciales → Acceso VPN (sin MFA)
     → Kerberoasting → Domain Admin → DCSync → Compromiso Total

Mapea esto a MITRE ATT&CK si tu cliente lo usa — ayuda a su equipo azul a priorizar reglas de detección.

Sección 7: Hoja de Ruta de Remediación

No te limites a listar lo que está roto — dales un plan.

Niveles de prioridad:

Hoja de ruta de ejemplo:

P1 — Inmediata (dentro de 72 horas):

• Rotar todas las contraseñas de cuentas de servicio del dominio, especialmente svc_backup
• Habilitar MFA en VPN de inmediato
• Resetear credenciales de todos los usuarios objetivo del phishing
• Revisar membresía del grupo Domain Admins y eliminar cuentas innecesarias

P2 — Corto plazo (2–4 semanas):

• Implementar Defender for Identity o equivalente — configurar detección de Kerberoasting
• Auditar y eliminar derechos excesivos de admin local en estaciones de trabajo
• Revisar y reforzar alertas del SIEM — asegurar detección de patrones de beacon C2
• Parchear todos los sistemas con CVE Crítico/Alto

P3 — Mediano plazo (1–3 meses):

• Migrar cuentas de servicio a gMSA
• Implementar solución PAM para acceso privilegiado
• Realizar capacitación de concientización sobre phishing para todo el personal, re-prueba anual obligatoria
• Revisar el modelo de niveles de Active Directory e implementarlo si no está en lugar

P4 — Largo plazo (3–6 meses):

• Implementar segmentación de red Zero Trust
• Aplicar política de gestión de puertos USB
• Establecer cadencia de evaluación anual de red team
• Ejercicio de purple team para validar la cobertura de detección mejorada

Guía de Lenguaje y Tono

Algunas reglas rápidas que mejoran significativamente los informes:

Usa voz activa.

• ❌ “Las credenciales fueron capturadas por el equipo”
• ✅ “El equipo capturó las credenciales”

Usa lenguaje de impacto al negocio en los hallazgos.

• ❌ “El sistema es vulnerable a CVE-2024-XXXX”
• ✅ “Esta vulnerabilidad permite que un atacante lea todos los registros de clientes sin autenticación”

Sé específico con la remediación.

• ❌ “Habilitar MFA”
• ✅ “Habilitar MFA en la VPN Cisco AnyConnect usando Microsoft Authenticator — pasos de configuración en la documentación de Cisco KB12345”

No exageres tu propio trabajo.

• ❌ “La tradición élite del equipo nos permitió…”
• ✅ “Usando herramientas estándar disponibles públicamente, el equipo…”

No suavices el impacto.

• ❌ “Esto podría potencialmente permitir que un atacante…”
• ✅ “Esto permite que un atacante…” (si es verdad)

Apéndices

Incluye los necesarios:

• Apéndice A: Salida completa de herramientas / evidencia bruta
• Apéndice B: Metodología (PTES, OSSTMM, alineación con MITRE ATT&CK)
• Apéndice C: Glosario (para lectores no técnicos)
• Apéndice D: Documentación del alcance / cartas de autorización
• Apéndice E: Criterios de re-prueba (qué significa “corregido” para cada hallazgo)

Nota de Seguridad Operacional

Los informes de red team son los entregables más sensibles de tu engagement. Documentan exactamente cómo fue comprometido el entorno de tu cliente.

Reglas de entrega:

• Encripta el informe (PDF protegido por contraseña o contenedor encriptado)
• Entrega a través de un canal seguro — no por correo electrónico simple
• Confirma la recepción con el punto de contacto
• Elimina las copias de trabajo de tus propios sistemas después de confirmar la entrega
• Aclara con el cliente cómo almacenará y distribuirá el informe internamente

Lista de Verificación Final

Antes de enviar:

• El resumen ejecutivo cabe en una página
• Cada hallazgo tiene severidad, evidencia, impacto al negocio y remediación específica
• La narrativa del ataque cuenta una historia coherente desde el acceso inicial hasta el objetivo
• Ningún hallazgo dice solo “parchea el sistema” — la remediación es específica
• La matriz de riesgo está completa y precisa
• La hoja de ruta de remediación tiene niveles priorizados
• El informe está encriptado antes de la entrega
• Todas las capturas de pantalla están etiquetadas y son legibles
• El nombre del cliente y las fechas son correctos en todo el documento

Conclusión

El objetivo de un informe de red team no es demostrar lo que encontraste. Es darle a la organización exactamente lo que necesita para entender su riesgo y solucionarlo.

Escríbelo para dos audiencias — el ejecutivo que necesita entender el riesgo al negocio y aprobar el presupuesto de remediación, y el equipo técnico que necesita reproducir, verificar y corregir cada hallazgo. Si ambos pueden leer tu informe y obtener lo que necesitan sin llamarte, has escrito un buen informe.

¿Necesitas convertir los hallazgos de tu red team en informes pulidos listos para la sala de juntas? CipherWrite maneja la redacción técnica para equipos de ciberseguridad — desde notas en bruto hasta entregable final.