C2 frameworks explicados:

qué es Cobalt Strike o Sliver y cómo se detectan

Serie Red Team  |  unfantasmaenelsistema.com

La serie Red Team ha recorrido el ataque fase a fase: reconocimiento, acceso inicial, escalada de privilegios, movimiento lateral y persistencia. Falta la pieza que lo cose todo y que la mayoría de informes de incidentes acaba mencionando: el mando y control, o C2. Es la infraestructura que un operador usa para dirigir a distancia los equipos que ya ha comprometido, y frameworks como Cobalt Strike, Sliver o Mythic son las herramientas que la industrializan.

Este artículo es conceptual y defensivo. No hay instrucciones de despliegue, ni configuración de beacons, ni perfiles listos para copiar, ni una sola técnica de evasión de EDR. El objetivo es entender qué es un C2, de qué partes se compone y —sobre todo— cómo se detecta, porque esa es la parte que de verdad se paga en un SOC y la que cierra la serie por el lado azul.

1. Qué es un C2 y por qué existe

Command and Control (C2, C&C o C2C) es la táctica TA0011 de MITRE ATT&CK: el conjunto de técnicas que un adversario emplea para comunicarse con los sistemas que controla dentro de una red víctima. Una vez que hay un punto de apoyo, el atacante necesita un canal fiable para enviar órdenes, recibir resultados y traer más herramientas. Ese canal, y el software que lo gestiona, es el C2.

En un ejercicio de red team con contrato, el C2 cumple exactamente la misma función pero al servicio de la defensa: permite emular a un adversario real de forma controlada para medir si el equipo de detección y respuesta ve lo que tiene que ver. El valor del ejercicio no está en «entrar», sino en el informe que compara lo que hizo el operador con lo que registró el defensor.

• Botnets tradicionales: C2 masivo y ruidoso, orientado a controlar miles de equipos (spam, DDoS, minería). Canales históricos: IRC, HTTP a dominios fijos
• C2 de intrusión dirigida: sigiloso, pensado para pocas máquinas de alto valor y para pasar desapercibido durante semanas. Es el modelo de los frameworks que trata este artículo
• Red team / adversary emulation: el mismo software de intrusión dirigida, usado bajo contrato para validar defensas

2. Anatomía de un framework de C2

Aunque cada framework tiene su jerga, casi todos comparten la misma estructura de cuatro piezas. Entender qué hace cada una es entender dónde deja rastro.

2.1 El beacon y su ritmo

El agente rara vez mantiene una conexión abierta permanente: eso sería trivial de ver. En su lugar sondea al servidor a intervalos —cada varios segundos o varios minutos— preguntando «¿hay trabajo para mí?». A ese patrón se le llama beaconing. Para disimularlo, los frameworks añaden un jitter: una variación aleatoria sobre el intervalo base para que las llamadas no caigan en un reloj perfecto. Aun así, el promedio a lo largo del tiempo sigue siendo regular, y ahí es donde lo caza la analítica.

2.2 Frameworks habituales

• Cobalt Strike: comercial, de Fortra. El más extendido en operaciones reales, en buena parte por versiones filtradas y crackeadas. Su beacon es el más caracterizado por la industria de detección
• Sliver: de BishopFox, de código abierto en Go. Multiplataforma, con canales mTLS, HTTP/S, DNS y WireGuard. Muy usado en formación y en pentest
• Mythic: framework modular de código abierto; separa el servidor de los agentes, que son intercambiables (Apollo, Poseidon, etc.)
• Metasploit / Meterpreter: cubierto en su propio artículo; es un C2 más, aunque su rastro por defecto es el más conocido de todos
• Havoc, Empire, Covenant: otros proyectos abiertos que aparecen con frecuencia en informes y en laboratorios de formación

3. Canales de comunicación

El canal es el protocolo por el que hablan beacon y servidor. La elección busca mimetizarse con el tráfico legítimo de la organización, así que cada canal tiene un perfil de detección distinto.

4. Perfiles malleable, a alto nivel

Algunos frameworks —Cobalt Strike es el ejemplo más conocido— permiten definir un perfil que describe con detalle qué aspecto tiene el tráfico del beacon: qué cabeceras HTTP usa, qué rutas pide, cómo codifica los datos, cada cuánto sondea. La idea del operador es que el tráfico se confunda con el de una aplicación legítima concreta.

Para el defensor, la existencia de estos perfiles tiene dos lecturas. La mala: no basta con buscar la configuración «de fábrica», porque un operador competente la cambia entera. La buena: los perfiles públicos (los que circulan en repositorios y se reutilizan sin modificar) están catalogados, y muchas soluciones de red traen firmas para ellos. Además, por muy bien hecho que esté un perfil, sigue habiendo invariantes difíciles de ocultar: la regularidad estadística del beaconing, la huella TLS de la librería que genera la conexión, y el comportamiento del implante en memoria.

5. Detección de red

5.1 Analítica de beaconing

Es la técnica estrella contra el C2 y no depende de firmas. Consiste en analizar, sobre los logs de proxy, firewall y DNS, la cadencia de las conexiones entre cada host interno y cada destino externo. Un cliente que contacta con el mismo dominio cada 60 segundos ±10 % durante horas, moviendo poco volumen y sin actividad de usuario asociada, es sospechoso aunque el dominio tenga buena reputación y el tráfico vaya cifrado.

• Se calculan intervalos entre conexiones y se busca baja varianza (o varianza acotada, por el jitter)
• Se pondera con el tamaño de las transferencias: los beacons en reposo mueven paquetes pequeños y muy parecidos entre sí
• Herramientas de referencia en este terreno: RITA (de Active Countermeasures) sobre datos de Zeek, y los módulos de «beacon analytics» de la mayoría de NDR y SIEM
• El jitter dificulta el análisis ingenuo, pero al promediar una ventana larga el patrón reaparece

5.2 Huellas TLS: JA3, JA3S y JARM

Cuando un beacon abre una conexión TLS, la librería que usa produce un «Client Hello» con un orden concreto de cifrados y extensiones. El hash de esos parámetros es la huella JA3; la del servidor es JA3S. JARM va un paso más allá: sondea activamente un servidor con varios «hellos» y genera una huella de cómo responde. Los servidores de C2 conocidos —especialmente Cobalt Strike sin personalizar— tienen huellas JARM públicas que los NDR marcan de inmediato.

5.3 Indicadores de dominio e infraestructura

• Dominios registrados hace pocos días o semanas (categoría «newly registered domain»)
• Domain fronting o «domain borrowing»: el SNI dice un dominio de CDN legítimo y el Host real es otro
• Certificados TLS autofirmados o con campos por defecto (el certificado de ejemplo de Cobalt Strike es un caso de estudio clásico)
• Incoherencia entre lo que sirve un dominio a un navegador normal y lo que responde a las URIs del beacon

# Ejemplo ilustrativo sobre datos PROPIOS: destinos externos por regularidad de contacto
# (pseudo-consulta sobre logs de proxy ya centralizados en el SIEM)
por cada (host_interno, dominio_destino):
    intervalos = diferencias_de_tiempo(conexiones)
    if desviacion(intervalos) / media(intervalos) < 0.15 and media(bytes) < 2KB:
        marcar_para_revision(host_interno, dominio_destino)
 
# La idea: poca varianza en el intervalo + poco volumen + sin actividad de usuario = candidato a beacon

6. Detección en el endpoint

El tráfico se puede disfrazar; el comportamiento del implante en la máquina es más difícil de esconder del todo. Aquí Sysmon y un EDR aportan la telemetría clave.

• Escaneo de memoria: reglas YARA sobre el espacio de direcciones de procesos vivos detectan estructuras conocidas de beacons incluso cuando el tráfico es limpio (lo vimos en el artículo de YARA)
• Sleep masking y ofuscación en reposo existen para dificultar justo ese escaneo; no los cubrimos, pero el defensor debe saber que un único escaneo puntual puede no bastar
• Hunting de named pipes: listar pipes activos y contrastarlos con una línea base del parque es un hunt barato y productivo

# Revision en un sistema PROPIO durante un hunt (PowerShell)
Get-ChildItem \\.\pipe\ | Select-Object Name        # pipes activos vs. linea base conocida
 
# Sysmon: creacion de hilos remotos (posible inyeccion) en la ultima hora
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=8;
  StartTime=(Get-Date).AddHours(-1)} | Format-List TimeCreated, Message

7. Mapeo a MITRE ATT&CK

Encadenar las detecciones a la matriz ayuda a medir cobertura y a comunicar hallazgos. La actividad de C2 se concentra en TA0011, pero casi nunca viaja sola.

8. Practicarlo por el lado defensivo

Se puede montar un laboratorio para estudiar la telemetría de un C2 sin convertirlo en un campo de tiro. La clave es un entorno cerrado y el foco puesto en lo que ve el defensor.

• Red solo-anfitrión, sin NAT ni puente: el rango 192.168.56.x de la serie, sin salida a internet
• Una VM «víctima» Windows con Sysmon y reenvío de eventos, y una VM Linux con Zeek capturando el tráfico del segmento
• Frameworks abiertos y pensados para formación (Sliver, Mythic) o rangos ya preparados como DetectionLab o los laboratorios de Splunk Attack Range
• El objetivo de cada prueba es responder: ¿qué Event ID saltó?, ¿lo vio la analítica de beaconing?, ¿qué regla habría que escribir?
• Instantánea limpia antes de empezar; los agentes dejan procesos y persistencia que conviene revertir

Conclusión

Un C2 no es magia: es un servidor, un canal y un agente que sondea a intervalos. Cada una de esas piezas —el ritmo del beacon, la huella de su TLS, los named pipes que abre, el hilo que inyecta en otro proceso— deja un rastro que la telemetría adecuada convierte en alerta. Los frameworks modernos invierten mucho esfuerzo en disimular ese rastro, pero las invariantes estadísticas y de comportamiento son difíciles de borrar del todo.

Por eso la defensa contra el C2 se apoya menos en firmas y más en analítica: cadencia de conexiones sobre logs con retención larga, huellas TLS, hunting de pipes y escaneo de memoria, todo mapeado a ATT&CK para medir cobertura. Si has seguido la serie Red Team por curiosidad técnica, esta es la entrega que explica cómo se ve todo lo anterior desde la silla del defensor, que es donde está el trabajo.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)