Saltearse al contenido

Command & Control

El Command & Control (C2 o C&C) es el canal por el que un implante recibe órdenes y devuelve datos al operador. Esta ficha lo trata con paridad Red Team / Blue Team: cómo se diseñan los canales y el comportamiento de un C2 a nivel conceptual —para emularlos en un ejercicio autorizado y para reconocerlos al analizar una muestra— y cómo se detectan, extraen sus indicadores (IOCs) y se cortan. El C2 es la táctica TA0011 de MITRE ATT&CK y el punto de la kill chain donde el defensor tiene más palanca: cortarlo corta el control del adversario.

sequenceDiagram
    participant I as Implante
    participant C as Servidor C2
    loop Beaconing periódico (con jitter)
        I->>C: check-in (HTTPS / DNS)
        C-->>I: tarea (comando)
        I->>C: resultado
    end

El implante tiene que hablar con el operador atravesando egress, proxy, inspección TLS y NDR sin destacar. El adversario resuelve eso mimetizándose con tráfico legítimo y espaciando las comunicaciones; el defensor lo caza por lo que ese tráfico no puede ocultar del todo: su periodicidad, su destino y su correlación con un proceso anómalo en el endpoint.

HTTP/HTTPS el más común; se camufla entre tráfico web (a veces domain fronting / CDN)
DNS datos en consultas/respuestas; lento pero suele estar permitido (ver net-dnsattacks)
Protocolos legítimos Slack/Telegram/Discord/GitHub/servicios cloud como portador ("C2 over trusted")
Dead drop recoger órdenes de perfiles/pastes públicos (social media, pastebin)
P2P botnets sin servidor central, más resistentes al takedown

El principio: cuanto más se parezca el destino y la forma del tráfico a algo esperado en la red objetivo, menos destaca.

El implante consulta al C2 periódicamente (“beacon”). El diseño del beacon es un equilibrio entre sigilo y control:

- intervalo (sleep) + jitter aleatorio para romper la periodicidad exacta
- check-ins pequeños y de tamaño similar cuando no hay comando pendiente
- un intervalo largo evade mejor pero da menos interactividad al operador

Este mismo patrón regular es, para el blue team, una de las firmas de comportamiento más detectables (ver abajo).

Los frameworks modernos permiten modelar el tráfico (cabeceras, URIs, User-Agent, forma de las peticiones) para que imite a un servicio real —los malleable C2 profiles— y ejecutar en memoria (BOFs, post-ex in-process) para dejar pocos artefactos en disco. Es la unión de C2 y evasión (ver Evasión de defensas).

redirectores capas (p. ej. CDN/categorías de confianza) que ocultan el servidor real
DGA el implante genera dominios pseudoaleatorios por fecha -> difícil de prebloquear
fast-flux rotación rápida de IPs/dominios para resistir el takedown

En ejercicios autorizados se emplean frameworks de C2 ya hechos: Cobalt Strike (comercial, el estándar de facto), Sliver, Mythic, Havoc, Metasploit/Meterpreter. Reconocer sus artefactos y perfiles por defecto es también trabajo de blue team: sus fugas y su madurez open-source han extendido estas capacidades a atacantes de todo nivel.

# red (lo más potente contra C2)
- beacon analysis: periodicidad del tráfico en NDR/SIEM (RITA, Zeek, Arkime)
- destinos a dominios recién registrados, raros o de baja reputación
- DNS: subdominios largos/aleatorios, TXT anómalos, volumen alto (tunneling/DGA)
- TLS: JA3/JA3S de familias conocidas, certificados autofirmados/anómalos
- IOCs de C2 (dominios/IPs) de threat intel -> bloqueo en DNS/firewall/proxy
# endpoint
- proceso inusual con conexiones salientes periódicas (EDR + Sysmon event 3)
- correlación: el mismo proceso que persiste (mal-persist) y habla a un destino fijo

Sysmon network connect (3), DNS query (22), process create (1); logs de proxy/DNS/firewall; captura de red para el análisis de periodicidad (Zeek/RITA). La correlación proceso↔red en el SIEM es lo que convierte un beacon en una alerta accionable.

# estático (ver mal-static): dominios/IPs/URLs en strings o en la config cifrada
# -> tras desempacar/descifrar aparecen los C2 (config extraction, ver mal-dynamic)
# dinámico (ver mal-dynamic): ejecutar en lab AISLADO con red simulada (INetSim/FakeNet)
# -> capturar a qué destinos intenta conectar y qué envía
# DGA: reconocer el algoritmo permite predecir y bloquear/sinkhole los dominios futuros
  • Egress filtering: default-deny saliente + allowlist de destinos corta la mayoría de C2 (ver Evasión de firewalls e IDS).
  • Protective DNS y filtrado por categorías (dominios recién registrados, DGA, tunneling).
  • NDR / beacon analysis (RITA/Zeek) + EDR correlacionando proceso↔red.
  • Threat intel (IOCs de C2) en DNS/firewall/proxy/EDR; inspección TLS donde sea viable.
  • Tras detectar un C2, caza retrospectiva: buscar esos IOCs en logs históricos de toda la flota.
  • C2 sobre servicios legítimos: APTs y commodity malware usando Telegram/Discord/GitHub/Google Drive como portador (MITRE T1102 Web Service, T1071 Application Layer Protocol).
  • Fugas de Cobalt Strike: su uso masivo por ransomware (Conti, LockBit) y la caza de sus beacons por defecto (perfiles, named pipes) son referencia de detección.
  • DGA: familias como Conficker y numerosas botnets; el sinkholing de dominios DGA es una técnica de respuesta consolidada.
  • DNS tunneling (T1071.004) y domain fronting (T1090.004) como evasión de egress en campañas reales.
  • Identificar el canal de C2 de la muestra (HTTP/DNS/legítimo/dead drop)
  • Extraer los C2 (estático + config / dinámico con red simulada aislada)
  • ¿Usa DGA? → reconocer el algoritmo para predecir dominios
  • Caracterizar el beaconing (intervalo, jitter, tamaños)
  • Capturar IOCs de red (dominios/IPs/URLs/JA3)
  • Identificar el framework si aplica (artefactos/perfil por defecto)
  • Blue: ¿lo caza el beacon analysis (RITA/Zeek) y la correlación proceso↔red?
  • Mapear a MITRE ATT&CK (TA0011 Command and Control)
  • Bloqueo/sinkhole + caza retrospectiva de IOCs