OPSEC en Red Team

Definición

OPSEC (Operations Security) es un proceso sistemático de 5 pasos originado en el ámbito militar. En ciberseguridad (contexto red team), NIST lo define como:

“Proceso sistemático y probado mediante el cual los posibles adversarios pueden ser privados de información sobre capacidades e intenciones, identificando, controlando y protegiendo evidencias generalmente no clasificadas de la planificación y ejecución de actividades sensibles.”

En el contexto red team, el adversario es el blue team (y posibles terceros maliciosos): su objetivo es detectar y bloquear las actividades del red team. OPSEC busca denegar al adversario cualquier información que le permita interferir con la operación.

Contexto

OPSEC no es un conjunto de reglas fijas; es un proceso iterativo de 5 pasos que se aplica antes y durante un engagement. Frameworks como MITRE ATT&CK y Lockheed Martin Kill Chain ayudan a los defensores a identificar los objetivos del adversario —por eso el red team debe anticipar qué información dejan esos frameworks visible al blue team.

Relación: Red Team Fundamentals, Red Team Engagement Planning, Threat Intelligence for Red Teams, Command and Control (C2).

Desarrollo

Los 5 pasos del proceso OPSEC

graph LR
    A[1. Identificar información crítica] --> B[2. Analizar amenazas]
    B --> C[3. Analizar vulnerabilidades]
    C --> D[4. Evaluar riesgos]
    D --> E[5. Aplicar contramedidas]

Paso 1 — Identificar Información Crítica

Información crítica: cualquier dato que, si el blue team la obtiene, degrada o impide la misión del red team. No tiene que ser secreta; basta con que sea útil para el adversario.

Ejemplos de información crítica en red teaming:

• Info del cliente: nombres de empleados, roles, infraestructura descubierta → compartir solo bajo principio de Least Privilege (PoLP).
• Info del red team: identidades, actividades, planes, capacidades y limitaciones.
• TTPs usados: si el blue team las conoce, puede preparar detecciones específicas.
• OS/cloud/C2 del red team: ej.: si el blue team sabe que usas Pentoo como OS, puede rastrear sus logs.
• IPs públicas del red team: bloquear una IP puede neutralizar toda la operación.
• Dominios registrados (phishing, C2): si el blue team los conoce, puede sinkhole o bloquear.
• Sitios web alojados (páginas de phishing).

Paso 2 — Analizar Amenazas

Threat analysis: identificar adversarios potenciales y sus intenciones y capacidades.

Preguntas clave (DoD OPSEC Program Manual):

1. ¿Quién es el adversario?
2. ¿Cuáles son sus objetivos?
3. ¿Qué TTPs usa?
4. ¿Qué información crítica ya ha obtenido?

Adversarios del red team:

Fórmula:

1
Amenaza = Adversario + Intención + Capacidad

Un adversario sin intención o capacidad no constituye una amenaza.

Paso 3 — Analizar Vulnerabilidades OPSEC

Una vulnerabilidad OPSEC existe cuando el adversario puede obtener información crítica, analizarla y actuar de forma que afecte al plan.

Nota importante: no confundir con vulnerabilidades técnicas de sistemas; aquí se refiere a brechas de seguridad operacional.

Ejemplos:

• Usar la misma IP pública para Nmap, Metasploit y hosting de phishing: si el blue team detecta una actividad y bloquea esa IP, bloquea todas simultáneamente.
• Base de datos de phishing sin securizar: bots maliciosos que escanean Internet la detectarán y comprometerán la operación (datos exfiltrados, credenciales del cliente expuestas).
• Un miembro del red team publica en redes sociales el nombre del cliente: el blue team detectará la operación antes de que empiece.

Paso 4 — Evaluación de Riesgos

NIST: proceso de identificar riesgos a operaciones, activos e individuos resultantes de la operación de un sistema.

En OPSEC: evaluar la probabilidad de que ocurra un evento junto con el coste esperado de ese evento.

Factores a considerar para cada contramedida:

1. Eficiencia de la contramedida para reducir el riesgo.
2. Coste de la contramedida vs. impacto de la vulnerabilidad explotada.
3. ¿Puede la contramedida revelar información al adversario?

Ejemplo de evaluación:

• Vulnerabilidad: misma IP para Nmap, Metasploit y phishing.
• Si el cliente tiene un SIEM: alta probabilidad de detección → riesgo alto.
• Si el cliente tiene recursos mínimos de monitoreo: riesgo bajo.

Paso 5 — Contramedidas

Las contramedidas están diseñadas para: (a) impedir que el adversario detecte información crítica, (b) proporcionar una interpretación alternativa (deception), o (c) negar el sistema de recolección del adversario.

Ejemplos de contramedidas:

Aplicación práctica: Ejemplos por categoría

Programas / OS / VM del red team

• Info crítica: OS, programas, hostname de VM.
• Amenaza: el blue team monitorea servicios y logs de red; el OS/VM puede quedar registrado.
• Vulnerabilidad: hostname kali2021vm en una red de equipos físicos → trivial de detectar.
• Riesgo: depende del servicio al que se conecta (VPN, web, etc.).
• Contramedida:
  • Cambiar hostname de VMs a algo inconspicuo o consistente con naming del cliente.
  • Personalizar user-agents de herramientas.
  • Ejemplo Nmap con user-agent custom:

    # Sin personalizar, Nmap publica "Nmap Scripting Engine" en logs del servidor
    nmap -sC --script-args http.useragent="Mozilla/5.0 (compatible)" target.com

Ejemplos adicionales

Escenario: Fuga de información por red social

• Un operador publica en Twitter: “Gran engagement con [Nombre_Cliente] esta semana”.
• El blue team monitorea menciones del cliente en RRSS → detectan la operación antes de que empiece.
• Contramedida: política estricta de no revelar información del cliente en ningún canal externo.

Escenario: Base de datos de phishing comprometida

• El red team lanza phishing y almacena credenciales capturadas en una BD sin contraseña.
• Un bot malicioso descubre la BD → exfiltra las credenciales reales del cliente.
• Contramedida: securizar toda infraestructura del red team como si fuera producción.

Pitfalls

• OPSEC como lista de verificación: OPSEC es un proceso dinámico, no una lista fija. Cada engagement tiene información crítica diferente.
• Usar la misma IP para todo: es el error más básico y común; siempre segregar infraestructura por función.
• Ignorar terceros maliciosos: el blue team no es el único adversario; actores externos también pueden detectar y explotar infraestructura del red team.
• OPSEC solo en planificación: debe aplicarse durante toda la ejecución del engagement.
• No pensar en los logs del servidor: herramientas como Nmap, Metasploit o navegadores dejan huellas identificables en logs remotos.

Diagrama — Los 5 pasos OPSEC

graph TD
    A["1. Identificar información crítica<br/>(Identidades, IPs, TTPs, dominios, OS)"]
    B["2. Analizar amenazas<br/>(Blue team, terceros maliciosos)"]
    C["3. Analizar vulnerabilidades<br/>(¿Puede el adversario obtener info crítica?)"]
    D["4. Evaluar riesgos<br/>(Probabilidad × Impacto)"]
    E["5. Aplicar contramedidas<br/>(Segregar IPs, cambiar hostnames, custom UA)"]
    A --> B --> C --> D --> E --> A

Referencias

• TryHackMe — OPSEC: https://tryhackme.com/room/opsec
• NIST OPSEC: https://csrc.nist.gov/glossary/term/opsec
• DoD OPSEC Program Manual: https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodm/520502m.pdf
• NIST Risk Assessment: https://csrc.nist.gov/glossary/term/risk_assessment
• Lockheed Martin Kill Chain: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html
• MITRE ATT&CK: https://attack.mitre.org/
• Pentoo OS: https://pentoo.github.io/

Notas relacionadas

• Red Team Fundamentals
• Red Team Engagement Planning
• Threat Intelligence for Red Teams
• Command and Control (C2)
• Risk Management