Command and Control (C2)

Definición

Un C2 Framework (Command and Control) es una plataforma que permite a un red team (u operador ofensivo) gestionar de forma centralizada los activos comprometidos durante un engagement. Los agentes desplegados en los sistemas víctima se comunican periódicamente con el servidor C2, recibiendo instrucciones y enviando resultados.

Contexto

Los C2 Frameworks son una pieza fundamental tanto en red teaming como en las operaciones de actores maliciosos avanzados (APTs). Permiten gestionar múltiples compromisos simultáneamente, facilitan el movimiento lateral y proporcionan capacidades post-explotación avanzadas. El dominio de al menos un C2 Framework es esencial para cualquier operador red team.

Relación: Red Team Fundamentals, OPSEC (Red Team), Threat Intelligence for Red Teams.

Desarrollo

Componentes principales de un C2 Framework

1. C2 Server

Hub central al que los agentes hacen callback. Espera instrucciones del operador y las distribuye a los agentes conectados.

2. Agents / Payloads

Programa generado por el C2 que ejecuta en el sistema comprometido y hace callback al listener. Diferencias clave frente a una reverse shell estándar:

• Comandos pseudo predefinidos (upload/download, etc.)
• Altamente configurables: frecuencia de beacon, jitter, protocolos, etc.

3. Listeners

Aplicación en el servidor C2 que espera callbacks en un puerto/protocolo específico. Ejemplos: DNS, HTTP, HTTPS, SMB.

4. Beacons

Proceso por el cual el agente hace callback al listener del C2 server a intervalos definidos.

Obfuscación de callbacks del agente

Sleep Timers

Definen el intervalo entre beacons. Un patrón regular es fácilmente detectable:

1
TCP/443 - 10:00:05.000
2
TCP/443 - 10:00:10.000
3
TCP/443 - 10:00:15.000
4
→ Beacon cada 5 segundos → detectable

Jitter

Añade variación aleatoria al sleep timer para imitar tráfico de usuario legítimo:

1
TCP/443 - 10:00:03.580
2
TCP/443 - 10:00:13.213
3
TCP/443 - 10:00:14.912
4
→ Patrón irregular → más difícil de detectar

Ejemplo Python de jitter básico:

1
import random
2
sleep = 60
3
jitter = random.randint(-30, 30)
4
sleep = sleep + jitter

Tipos de Payload

Flujo Stageless:

1. Víctima descarga y ejecuta el dropper.
2. El beacon al C2 empieza directamente.

Flujo Staged:

1. Víctima descarga y ejecuta el dropper (Stage 1).
2. Dropper hace callback al C2 para descargar Stage 2.
3. C2 envía Stage 2 a la víctima.
4. Stage 2 se carga en memoria.
5. Beacon C2 se inicializa.

Formatos de Payload

• PowerShell Scripts (con código C# compilable con Add-Type)
• HTA Files
• JScript Files
• Visual Basic Application/Scripts
• Microsoft Office Documents (macros)
• Executables (Windows PE)

Para más detalle: TryHackMe Weaponization room.

Módulos

Los módulos extienden la funcionalidad de agentes y servidor. El lenguaje varía por framework:

• Cobalt Strike: Aggressor Scripts
• PowerShell Empire: múltiples lenguajes
• Metasploit: Ruby

Post-Exploitation Modules

Operaciones tras el compromiso inicial: SharpHound para paths de lateral movement, dump de LSASS, etc.

Pivoting Modules

Permiten acceder a segmentos de red restringidos. Ejemplo: SMB Beacon convierte un host comprometido en proxy SMB para segmentos internos sin acceso directo al C2.

Flujo de pivoting SMB:

1. Víctimas en segmento restringido → callback a named pipe SMB en víctima del segmento abierto.
2. Víctima del segmento abierto → callback estándar al C2.
3. C2 → instrucciones al pivote → instrucciones al segmento restringido.

Ocultación de la infraestructura C2

Domain Fronting

Usa servicios de CDN conocidos (ej.: Cloudflare) para enmascarar el tráfico C2:

1. El operador registra un dominio que redirige tráfico a través de Cloudflare.
2. La víctima hace beacon al dominio C2.
3. Cloudflare proxea la petición y la reenvía al servidor real según el Host header.
4. El servidor C2 responde a Cloudflare, que lo retransmite a la víctima.

Resultado: la geolocalización muestra Cloudflare, no el C2 real.

C2 Profiles (Redirectors)

Técnica presente en diversas tecnologías: NGINX Reverse Proxy, Apache Mod_Proxy/Mod_Rewrite, Malleable HTTP C2 Profiles (Cobalt Strike).

Permiten controlar elementos de las peticiones HTTP entrantes para distinguir tráfico legítimo de tráfico C2:

• Petición con header X-C2-Server → responde con instrucciones C2.
• Petición sin header → devuelve una web genérica.

Referencias: Malleable C2 Profiles para Cobalt Strike

C2 Frameworks principales

Frameworks gratuitos

Frameworks de pago

Para una lista exhaustiva: C2 Matrix — mantenido por Jorge Orchilles y Bryson Bort.

Setup básico — Armitage (ejemplo)

Armitage como GUI de Metasploit ilustra los conceptos básicos de administración C2:

Prerrequisitos:

# Iniciar PostgreSQL (necesario para la DB de Metasploit)
systemctl start postgresql

# Configurar variable de entorno
export MSF_DATABASE_CONFIG=/root/.msf4/database.yml

Iniciar Teamserver:

cd /opt/armitage/release/unix
./teamserver <IP_OPERADOR> <CONTRASEÑA_COMPARTIDA>

Conectar cliente Armitage:

./armitage
# Conectar a Host: <IP_OPERADOR>, Port: 55553

Seguridad: nunca exponer la interfaz de gestión del C2 públicamente. Los operadores deben acceder vía SSH port forwarding (TCP/55553).

Consideraciones OPSEC en C2

• No exponer el C2 directamente: usar redirectors/domain fronting.
• Customizar beacons: jitter + sleep timers realistas.
• Malleable profiles: imitar tráfico del adversario emulado (ver Threat Intelligence for Red Teams).
• Perfiles de C2 distintos por fase: recon, lateral movement y exfiltración deben tener perfiles diferenciados.
• No reutilizar IPs/dominios entre actividades (ver OPSEC (Red Team)).
• Staged payloads: preferidos para evadir AV vs. stageless.

Ejemplos

Ejemplo de flujo completo con Cobalt Strike:

1. Red team configura listener HTTPS con Malleable Profile que imita tráfico de APT 39.
2. Genera payload staged (dropper pequeño) que elude detección AV.
3. Dropper entregado vía spearphishing → víctima ejecuta → Stage 2 descargado en memoria.
4. Beacon con jitter de ±30% sobre sleep de 60s → tráfico semi-irregular.
5. Operador usa SMB beacon para pivotear a red interna sin salida directa a Internet.
6. Post-explotación: SharpHound → rutas de lateral movement → dump LSASS en memoria.

Pitfalls

• Beacon regular sin jitter: patrón trivialmente detectable por firewalls y SIEM.
• Exponer interfaz de gestión C2 a Internet: cualquier analista puede identificar y analizar el servidor C2.
• No usar Malleable Profiles/Redirectors: el tráfico C2 por defecto tiene firmas conocidas.
• Stageless en entornos con AV moderno: alta probabilidad de detección frente a staged.
• Reutilizar infraestructura: si el C2 es quemado en un engagement, invalidar toda la infraestructura asociada.
• Pago vs. gratuito: frameworks open-source tienen firmas bien documentadas en AV; en entornos con EDR maduro, valorar el uso de frameworks premium.

Diagrama — Arquitectura C2

graph TD
    OP[Operador Red Team] -->|Instrucciones| CS[C2 Server]
    CS -->|Beacon response| CF[Cloudflare / Redirector]
    CF -->|Beacon| V1[Víctima 1 - Red abierta]
    V1 -->|SMB pivot| V2[Víctima 2 - Red restringida]
    V1 -->|SMB pivot| V3[Víctima 3 - Red restringida]

    CS --- LP[Listener HTTP/HTTPS/DNS/SMB]
    V1 --- AG1[Agent/Beacon]
    V2 --- AG2[Agent/Beacon]

Referencias

• TryHackMe — Intro to C2: https://tryhackme.com/room/introtoc2
• C2 Matrix: https://howto.thec2matrix.com/
• Metasploit Framework: https://www.metasploit.com/
• Cobalt Strike: https://www.cobaltstrike.com/
• PowerShell Empire: https://bc-security.gitbook.io/empire-wiki/
• Covenant: https://github.com/cobbr/Covenant
• Sliver (Bishop Fox): https://github.com/BishopFox/sliver
• Brute Ratel: https://bruteratel.com/
• Malleable C2 Profiles: https://blog.zsec.uk/cobalt-strike-profiles/
• Armitage: https://web.archive.org/web/20211006153158/http://www.fastandeasyhacking.com/

Notas relacionadas

• Red Team Fundamentals
• Red Team Engagement Planning
• Threat Intelligence for Red Teams
• OPSEC (Red Team)
• Red Team Playbook (Guia avanzada)
• Nmap