3.10 · C2 e infraestructura ofensiva

Panorama#

Una reverse shell es frágil. La conexión de vuelta que abre el shellcode de 3.6, la que dispara una inyección de comando de 3.2 o una webshell de 3.5, y el acceso ya elevado que deja la escalada de 3.9, comparten el mismo problema: son un hilo único que se corta si cae el proceso, que no sobrevive a un reboot, que no gestiona varios hosts a la vez y que no se puede compartir entre operadores. El comando y control —command and control, C2— es la infraestructura que convierte ese hilo en un sistema: un canal fiable, persistente y reutilizable por el que el agente comprometido recibe órdenes y devuelve resultados. Es el sistema nervioso de la post-explotación, el eje sobre el que giran el movimiento lateral, la persistencia y la exfiltración.

La tesis que ordena el capítulo es una paradoja. El mismo canal que da control es el artefacto más detectable de toda la intrusión. Un host que ejecuta código robado se ve poco; un host que habla con el exterior a intervalos regulares, mes tras mes, es una anomalía que ningún atacante puede eliminar, porque sin ese diálogo no hay operación. Todo lo que sigue —los frameworks, los perfiles que imitan tráfico de Amazon, los redirectors, el domain fronting, el jitter que desincroniza el latido— es ingeniería contra ese único hecho: esconder una conversación que no puede dejar de suceder. El encuadre viene de la metodología de 3.1: en un assumed breach exercise el 0-day ya entró, y lo que el ejercicio mide es si el equipo azul detecta el C2 y los pasos que le siguen. «Ser descubierto es parte de la evaluación», y quemar cuatro o cinco entornos al ser detectado es un resultado válido que demuestra que las defensas funcionan.

flowchart LR
  A["Foothold / reverse shell\n(3.2 · 3.5 · 3.6 · 3.9)"] --> B["Agente / Beacon\nen la víctima"]
  B -->|"heartbeat → tasking → exfil"| R["Redirector\n(socat / mod_rewrite)"]
  R --> T["Team Server (C2)\nfuera del alcance del Blue"]
  T --> O["Operador\n(consola / GUI)"]
  B -.->|"SMB beacon"| B2["Otros hosts\n(sin egress propio)"]
  T --> P["→ evasión (3.11)\n→ pivoting (3.13)\n→ exfiltración (3.12)"]

La anatomía de un C2#

Entender un framework de C2 empieza por descomponerlo en sus tres piezas, porque son las mismas en cualquiera —Cobalt Strike, Sliver o uno escrito a mano— y porque conocer su protocolo interno es exactamente lo que permite detectarlo. El proyecto educativo de 0xsp, que construye un C2 mínimo en Free Pascal, expone la anatomía sin adornos:

• El team server orquesta toda la operación. Es un servidor de API —típicamente JSON REST sobre HTTPS con un certificado self-signed— con almacenamiento en base de datos (SQLite en el ejemplo) que guarda operadores, tareas y agentes. Corre multi-threaded para atender dos mundos a la vez: el de los operadores humanos y el de los agentes en las víctimas. Esa separación es deliberada —el API que toca el operador nunca es el mismo que el que tocan los agentes—, y cada listener que crea el operador levanta su propio servidor de agente aislado.
• El operador es la interfaz humana: una consola o una GUI que se autentica contra el team server y desde la que se listan los agentes conectados, se les asignan tareas y se leen los resultados. En el ejemplo Pascal es una GUI GTK que envía cada petición dentro de un hilo para no congelarse; en Cobalt Strike es el cliente Java que se conecta al team server.
• El agente —beacon en la jerga de Cobalt Strike, decoy en el ejemplo— es el código que corre en la víctima. Es un cliente HTTP muy personalizado que solo habla con los endpoints del C2, cross-platform y ligero.

Sobre esas tres piezas corre un único protocolo, y es el patrón que define a todos los C2 modernos: heartbeat → tasking → exfil. El agente, al arrancar, hace un heartbeat (un GET a un endpoint de verificación) para confirmar que el C2 está vivo; si responde, se marca conectado. A partir de ahí sondea un endpoint de tareas a intervalos, y aquí aparece una decisión de diseño reveladora: en vez de un bucle while —que consume CPU—, el agente usa un timer con un intervalo fijo (3000 ms en el ejemplo). En cada latido, si hay una tarea en estado PENDING, la ejecuta, la marca COMPLETED y exfiltra el resultado por POST. Dos rasgos completan el cuadro: si el C2 cae después de recibir resultados, el agente reintenta cuando vuelve; y si el handshake inicial falla, no ejecuta nada —«comportamiento menos ruidoso»—.

El ejemplo Pascal, por ser un demo, arrastra fallos reales que un C2 de producción debe evitar y que ilustran de paso por qué la propia infraestructura ofensiva es superficie de ataque: el token de autenticación es solo un base64(usuario:contraseña) sin rotación, y las consultas se arman por concatenación de strings —un SQL injection de manual, la misma clase de 3.2, ahora dentro del arma—. Los team servers reales han tenido vulnerabilidades análogas; la infraestructura del atacante no es mágicamente segura.

El catálogo de frameworks#

No existe «el» C2: se elige según el entorno, el presupuesto y el nivel de sigilo requerido. La familia se puede ordenar por su rasgo dominante.

Cobalt Strike sigue siendo la referencia porque no trae exploits —su valor aparece después de tener ejecución de código—: su Beacon está diseñado para post-explotación sigilosa, y su ecosistema (perfiles Malleable, Aggressor Scripts para automatizar) no tiene par. Precisamente por su ubicuidad, sus artefactos por defecto están intensamente firmados, y de ahí el auge de sucesores open-source como Sliver, Havoc y Mythic, que ofrecen el mismo modelo (beacon, perfiles, listeners mTLS/DNS) con menos huella conocida.

Empire representa el eje de la evasión moderna: ejecuta agentes PowerShell dentro de un runspace .NET sin invocar el binario powershell.exe, evadiendo las detecciones que vigilan ese proceso, con todo lo demás —Mimikatz, keyloggers, módulos— viviendo en memoria. Ese patrón fileless es el que arrastra hacia la evasión de AV/EDR (3.11). dnscat2 ocupa el otro extremo: cuando la red solo deja salir consultas DNS, tunela el C2 cifrado sobre ellas a través de un servidor autoritativo propio, atravesando casi cualquier egress restrictivo —el mismo principio de la connect-back shell que cruza el firewall de salida en 3.6, llevado a un protocolo que casi nunca se bloquea—.

Villain aporta una capacidad que los demás no cubren: el C2 colaborativo. Dos o más instancias en máquinas distintas se federan como sibling servers —conectando al team server de otra y aceptando con un código de un solo uso— y sincronizan sus sesiones en tiempo real, de modo que varios operadores ven las mismas shells. Su motor es HoaxShell, una reverse shell sobre HTTP/HTTPS que mezcla el C2 con peticiones web ordinarias; el precio de esa comodidad, otra vez, es un beaconing de baja varianza a un único endpoint.

Infraestructura desechable y resiliente#

El framework es solo el motor; alrededor va la infraestructura, y su regla de diseño es que debe poder quemarse sin perder la operación. Si todos los agentes hablan con uno o dos endpoints, el equipo azul desmonta la campaña de un golpe al bloquear ese destino. La respuesta se construye en capas.

Los servidores de ataque son VPS baratos y desechables (DigitalOcean, AWS Lightsail), provisionados de forma repetible para poder clonar N instancias idénticas: PTF (PenTesters Framework de TrustedSec) para instalar el arsenal, o Terraform (Red Baron de Coalfire) para levantar toda la infra —phishing, C2, DNS— de forma automatizada, endurecida con iptables para restringir el origen del SSH y de los payloads.

Entre el agente y el team server se interpone un redirector: un socat o un Apache con mod_rewrite que recibe el tráfico del agente y lo reenvía al C2 real. Su función es desacoplar el dominio de la campaña del servidor que lo procesa: cuando un dominio se quema, se reemplaza el redirector sin rehacer el entorno ni exponer la IP del team server. Es la misma idea que la federación por redirectors de Villain, donde una shell compartida entre siblings viaja por una ruta que oculta el origen.

La capa más fina la dan los SMB Beacons de Cobalt Strike: solo un host habla con internet y el resto de los comprometidos se comunican con él por SMB (canalizando el C2 sobre named pipes). Si el análisis forense atrapa un host secundario, no encuentra el dominio C2 —porque ese host nunca lo tocó—. Es el eslabón que conecta el C2 con el pivoting y tunneling (3.13): la reverse shell de un host dual-homed —una máquina con dos interfaces en subredes distintas, detectada con un simple ifconfig— se vuelve el puente hacia un segmento interno inalcanzable, y el tráfico de los agentes internos sale por ese único punto.

Evasión del canal: parecerse al tráfico normal#

Los firewalls de aplicación y los IDS de capa 7 buscan tráfico anómalo. La estrategia del C2 no es esconderse —un canal cifrado hacia un destino raro es en sí mismo la anomalía— sino disolverse en el tráfico legítimo.

Los Malleable C2 Profiles de Cobalt Strike hacen que cada petición del Beacon parezca una petición normal a un sitio de confianza: la URI imita /s/ref=nb_sb_noss_1/..., el header Host dice www.amazon.com, aparecen las cabeceras x-amz-id que un cliente real de Amazon envía. Como los perfiles públicos ya tienen firmas conocidas, la disciplina operativa es modificar todos los strings estáticos, cambiar el User-Agent, usar certificados TLS reales (nunca los default del framework), aplicar jitter y comunicar por POST (el GET limita el volumen a unos 2048 caracteres).

El domain fronting va un paso más allá: esconde el origen del C2 detrás de un CDN de alta reputación. Todo el tráfico se dirige aparentemente a a0.awsstatic.com (o a un dominio de Google/Alibaba) —una conexión que ningún firewall bloquea—, pero el host header interno redirige la petición, dentro del CDN, a la distribución del atacante. El SNI del TLS y el destino real divergen; el defensor ve una conexión a Amazon. (AWS y Google han mitigado la técnica desde entonces, pero el patrón sobrevive en otros proveedores.)

HoaxShell y dnscat2 son dos encarnaciones del mismo principio en protocolos distintos: HoaxShell embebe el C2 en HTTP/HTTPS ordinario, y dnscat2 lo esconde en consultas DNS. Y por encima de todos ellos está el tratamiento del latido: el beaconing con jitter —una variación aleatoria del intervalo, digamos ±30 %— rompe la periodicidad perfecta que delataría al timer fijo de la anatomía. El jitter es la línea que separa un C2 maduro de un demo educativo.

De la shell frágil a la sesión usable#

El C2 también resuelve la ergonomía. Una reverse shell cruda es un pseudo-terminal limitado, sin historial, sin control de trabajos, que se pierde con un Ctrl-C mal puesto. La mejora canónica es el upgrade a TTY: en Windows, ConPtyShell (Invoke-ConPtyShell) convierte el pseudo-shell en una PowerShell totalmente interactiva con soporte TTY real, sin herramientas externas. Sobre esa base, el ciclo de vida de sesión de un framework —generar payloads codificados, listar y adjuntarse a sesiones, poner alias memorables en lugar de IDs largos, matar sesiones concretas, purgar la metadata cacheada de los implantes— es lo que hace operable un compromiso de decenas de hosts. Todo esto encadena hacia adelante: la sesión estable es el punto de partida del pivoting (3.13) y de la exfiltración por canales encubiertos (3.12).

Defensa y detección#

La paradoja del C2, vista desde el otro lado, es una ventaja del defensor: el canal que no puede dejar de existir es el que lo delata. La caza del C2 —C2 hunting— ataca cada capa de la evasión anterior.

• Beaconing y jitter. El punto débil estructural. Un análisis de periodicidad sobre los logs del proxy detecta el latido: peticiones a intervalos regulares hacia un mismo destino. El jitter solo desplaza el problema —una desviación estándar baja sigue siendo una firma—, y un timer fijo como el del demo Pascal (3000 ms, sin jitter) es trivial de cazar. Conexiones long-lived a un único endpoint, User-Agents raros y volumen simétrico de subida/bajada completan el perfil.
• Fingerprinting de TLS y desajuste del host header. El domain fronting se delata por la divergencia entre el SNI del handshake TLS y el host header real (inspección TLS mediante). Los certificados self-signed en puertos atípicos, y las huellas JA3/JA3S/JARM del cliente y el servidor TLS, identifican familias de C2 aun bajo cifrado, porque cada framework negocia el TLS de una forma característica.
• Firmas de perfil y de protocolo. Los Malleable C2 profiles públicos tienen firmas Suricata/Snort sobre sus URIs y cabeceras. Los endpoints característicos de un C2 casero —/agent/heart_beat, /tasks/view/?profile_UUID=, un Authorization: Basic que es base64(usuario:contraseña)— son igual de reconocibles. El modelo PENDING → COMPLETED con exfil por POST es el patrón request-tasking que un NDR/UEBA modela como tráfico de mando.
• DNS tunneling. dnscat2 genera un volumen anómalo de consultas a subdominios largos y de alta entropía —la firma del tunneling sobre DNS—, cazable por scoring de entropía y por volumen por dominio.
• PowerShell sin powershell.exe. Empire y sus parientes evaden la vigilancia del proceso, pero dejan rastro en AMSI, en el Script Block Logging (Event ID 4104) —donde el one-liner EncodedCommand aflora ya desofuscado, sobre todo con Constrained Language Mode activo— y en la carga de System.Management.Automation.dll por un proceso que no es PowerShell. La ejecución de comandos por el agente (exec_command lanzando procesos hijos) deja Sysmon 1 / Event ID 4688; el pipe SMB de un SMB Beacon deja Sysmon 17/18.
• Postura. Egress filtering con allowlist (los handlers del demo escuchan en 4443/8080/6501/8888; restringir la salida por defecto rompe muchos C2 antes de que beacen), inspección TLS, segmentación de red (que contiene el pivot del host dual-homed), application allowlisting (WDAC/AppLocker frena HoaxShell y las reverse-TCP antes de ejecutar) y logging de PowerShell a nivel de runspace, no solo del .exe.

Toda esta telemetría se correlaciona en el SIEM —el beacon, la resolución DNS anómala, el proceso hijo, la carga de la DLL— como una sola historia de mando y control, no como alertas sueltas; la caza específica de C2 por periodicidad, jitter y entropía se detalla del lado blue en la caza de C2 (P5), y la correlación con la telemetría de Active Directory en 4.9 · Defensa de AD. En términos de MITRE ATT&CK, el capítulo cubre T1071 (Application Layer Protocol: Web/DNS), T1090 (Proxy: redirectors), T1568.002 (Domain Fronting), T1572 (Protocol Tunneling), T1573 (Encrypted Channel: TLS self-signed), T1571 (Non-Standard Port), T1132.001 (Data Encoding: Base64) y T1041 (Exfiltration Over C2 Channel).

flowchart TD
  C["Canal C2\n(debe persistir y hablar afuera)"] --> B["Beaconing\n(periodicidad / jitter bajo)"]
  C --> D["Domain fronting\n(SNI ≠ host header)"]
  C --> E["TLS self-signed\n(JA3 / JARM)"]
  C --> F["DNS tunneling\n(entropía / volumen)"]
  C --> G["PowerShell fileless\n(AMSI / 4104 / DLL load)"]
  B & D & E & F & G --> H["Correlación SIEM\n= una historia de C2"]
  H --> I["→ caza de C2 (P5)\n→ contención / egress allowlist"]

Referencias#

• red-infra/hacker-playbook3/cap-01 — Pregame: red team vs pentest y assumed breach, infraestructura desechable (VPS, PTF, Red Baron), el catálogo de frameworks (Metasploit, Cobalt Strike, Empire, dnscat2, PoshC2, Merlin, Pupy), redirectors, domain fronting, SMB Beacons y Malleable C2 Profiles.
• red-infra/c2-docs/cap-01 — Villain C2 / HoaxShell: C2 colaborativo con federación sibling-server, HoaxShell como reverse shell HTTP-blend, ConPtyShell, descubrimiento de pivot en host dual-homed, ciclo de vida de sesión y el playbook de mitigación.
• red-infra/c2-docs/cap-02 — Building Operational C2C in Pascal: la anatomía de tres piezas (team server / operador / agente) y el protocolo heartbeat → tasking → exfil, con el beaconing de intervalo fijo, el certificado self-signed y las debilidades (token Base64, SQLi) que ilustran la superficie del propio C2.
• MITRE ATT&CK — TA0011 Command and Control y Sliver — framework C2 open-source de referencia actual.
• Cobalt Strike Malleable C2 y el trabajo de bluescreenofjeff / SpecterOps sobre redirectors y perfiles.