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
Modelo de amenaza
Sección titulada «Modelo de amenaza»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.
Red Team — diseño de C2 (conceptual)
Sección titulada «Red Team — diseño de C2 (conceptual)»Canales (cómo se mimetiza el tráfico)
Sección titulada «Canales (cómo se mimetiza el tráfico)»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 takedownEl principio: cuanto más se parezca el destino y la forma del tráfico a algo esperado en la red objetivo, menos destaca.
Beaconing (el patrón de check-in)
Sección titulada «Beaconing (el patrón de check-in)»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 operadorEste mismo patrón regular es, para el blue team, una de las firmas de comportamiento más detectables (ver abajo).
Perfiles maleables y mimetismo
Sección titulada «Perfiles maleables y mimetismo»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).
Resiliencia de la infraestructura
Sección titulada «Resiliencia de la infraestructura»redirectores capas (p. ej. CDN/categorías de confianza) que ocultan el servidor realDGA el implante genera dominios pseudoaleatorios por fecha -> difícil de prebloquearfast-flux rotación rápida de IPs/dominios para resistir el takedownFrameworks que el red team usa (referencia)
Sección titulada «Frameworks que el red team usa (referencia)»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.
Blue Team — detección
Sección titulada «Blue Team — detección»# 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 fijoTelemetría
Sección titulada «Telemetría»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.
Extraer el C2 de una muestra (análisis)
Sección titulada «Extraer el C2 de una muestra (análisis)»# 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 futurosHardening
Sección titulada «Hardening»- 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.
CVEs y casos reales
Sección titulada «CVEs y casos reales»- 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.
Checklist de prueba
Sección titulada «Checklist de prueba»- 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