Hunting de Command and Control (C2): Beaconing, DNS Tunneling y Domain Fronting

Command and Control en el Ciclo de Ataque

El Command and Control (C2, CC, C&C) es la fase del ataque donde el adversario mantiene comunicacion con los sistemas comprometidos para enviar comandos, recibir datos y gestionar la operacion. Sin C2, el adversario pierde control sobre los sistemas comprometidos.

La deteccion de C2 es un punto de alto valor en el hunting porque:

1. Confirma compromiso activo (no solo persistencia dormida)
2. Permite identificar la infraestructura del adversario
3. Proporciona IOCs accionables (IPs, dominios, certificados)
4. La comunicacion C2 es continua, lo que multiplica las oportunidades de deteccion

Los adversarios modernos usan tecnicas sofisticadas para camuflar las comunicaciones C2 como trafico normal: HTTPS sobre puertos estandar, domain fronting via CDNs, DNS tunneling y protocolos encapsulados. El hunting de C2 se centra en detectar estas tecnicas a traves de sus metadatos, no de su contenido.

Deteccion de Beaconing

El beaconing es el patron mas caracteristico de C2. Un implante se comunica con el servidor C2 a intervalos regulares, tipicamente entre 30 segundos y 15 minutos. Los frameworks C2 modernos (Cobalt Strike, Sliver, Havoc) introducen jitter (variacion aleatoria) para evitar intervalos perfectamente regulares, pero la periodicidad subyacente sigue siendo detectable.

Analisis estadistico basico

El metodo mas simple es calcular los intervalos entre conexiones consecutivas a un mismo destino y analizar la distribucion:

# Pseudocodigo para analisis de beaconing
conexiones = filtrar_por_destino(conn_log, ip_destino)
conexiones.sort_by(timestamp)

intervalos = []
for i in range(1, len(conexiones)):
    delta = conexiones[i].timestamp - conexiones[i-1].timestamp
    intervalos.append(delta)

media = mean(intervalos)
desviacion = std(intervalos)
coeficiente_variacion = desviacion / media

# Beaconing tipico: coeficiente de variacion bajo
# (intervalos consistentes)
# CV menor a 0.3 es sospechoso
# CV menor a 0.1 es muy sospechoso (beaconing casi perfecto)

Analisis de frecuencia con FFT

La Transformada Rapida de Fourier (FFT) convierte una serie temporal en componentes de frecuencia. Si hay beaconing, la FFT mostrara un pico dominante en la frecuencia correspondiente al intervalo del beacon.

import numpy as np

# timestamps en segundos de las conexiones a un destino
timestamps = np.array([...])

# Crear serie temporal binaria (1 = hay conexion, 0 = no)
# con resolucion de 1 segundo
start = timestamps[0]
end = timestamps[-1]
series = np.zeros(int(end - start) + 1)
for t in timestamps:
    series[int(t - start)] = 1

# FFT
fft_result = np.fft.rfft(series)
frequencies = np.fft.rfftfreq(len(series), d=1.0)
magnitudes = np.abs(fft_result)

# Buscar picos significativos
# Un pico en frecuencia f corresponde a un intervalo de 1/f segundos
threshold = np.mean(magnitudes) + 3 * np.std(magnitudes)
peaks = frequencies[magnitudes > threshold]

# Si hay un pico dominante, convertir a intervalo
for f in peaks:
    if f > 0:
        intervalo_segundos = 1.0 / f
        print(f"Posible beaconing cada {intervalo_segundos:.0f} segundos")

Factores que complican la deteccion

Jitter alto. Los frameworks C2 modernos usan jitter de hasta 40-50%, lo que aumenta la variabilidad. El beaconing con 50% de jitter en un intervalo de 60 segundos produce conexiones entre 30 y 90 segundos. El FFT detecta la periodicidad subyacente, pero la magnitud del pico es menor.

Sesiones largas. Algunos C2 usan sesiones TCP persistentes en lugar de conexiones discretas. En este caso, el beaconing se manifiesta como paquetes dentro de la sesion, no como conexiones separadas.

Trafico mixto. Si el implante se comunica a traves de un dominio que tambien recibe trafico legitimo, el beaconing queda enmascarado.

Herramientas para deteccion de beaconing

RITA (Real Intelligence Threat Analytics). Analiza logs de Zeek y calcula scores de beaconing automaticamente. Es la herramienta open source de referencia.

# Importar logs de Zeek
rita import /opt/zeek/logs/2026-06-09 dataset-hunt

# Mostrar beacons ordenados por score
rita show-beacons dataset-hunt --columns score,src,dst,connections

Elastic ML. El modulo de machine learning de Elastic puede detectar periodicidad en conexiones de red configurando un job de anomaly detection sobre conn logs.

Deteccion de DNS Tunneling

El DNS tunneling encapsula datos dentro de consultas y respuestas DNS. El adversario codifica los datos como subdominios en las queries (datos salientes) y los recibe como respuestas TXT (datos entrantes).

Indicadores de DNS tunneling

Indicador	Valor normal	Sospechoso
Longitud del FQDN	Menos de 50 chars	Mas de 50 chars
Longitud del subdominio	Menos de 20 chars	Mas de 30 chars
Entropia del subdominio	Baja (palabras legibles)	Alta (codificacion Base32/64)
Volumen de queries a un dominio	Menos de 100/hora	Miles por hora
Tipo de query	A, AAAA	TXT, NULL, CNAME
Tamano de respuesta TXT	Menos de 255 bytes	Cerca de 255 bytes consistentemente
NXDOMAIN ratio	Bajo	Puede ser alto si el tunel no resuelve

Consulta de hunting

# DNS queries con subdominios largos (posible tunneling)
event.code: "22" AND
dns.question.name: /[a-z0-9]{30,}\..+/

# Volumen alto de DNS queries a un mismo dominio base
# (agrupar por dominio de segundo nivel y contar)

# Con logs de Zeek: queries DNS con subdominios largos
cat dns.log | zeek-cut query | \
  awk -F. '{sub = ""; for(i=1;i<=NF-2;i++) sub = sub $i; print length(sub), $0}' | \
  awk '$1 > 40' | sort -rn | head 30

Herramientas especializadas

dnscat2 detection. El tunel dnscat2 usa queries TXT y CNAME con subdominios codificados en hex. Buscar patrones de caracteres hexadecimales en subdominios con alto volumen.

Iodine detection. Iodine usa queries NULL con subdominios codificados en Base128. El tamano de las queries es consistentemente grande.

Identificacion de Domain Fronting

Domain fronting usa una CDN (Content Delivery Network) como intermediario para ocultar el destino real del trafico. El trafico parece ir a un dominio legitmio de la CDN, pero el header Host dentro del HTTPS redirige al servidor C2 real.

Como funciona

1. El implante hace una conexion HTTPS al dominio frontal (ej: cdn.cloudfront.net)
2. El TLS SNI muestra el dominio frontal (visible en la red)
3. Dentro del tunel HTTPS, el header Host apunta al dominio C2 real
4. La CDN redirige la peticion al servidor C2 basandose en el Host header

Deteccion

Discrepancia SNI vs Host. Si tienes inspeccion TLS (proxy corporativo), la discrepancia entre el SNI y el Host header es el indicador definitivo. Sin inspeccion TLS, la deteccion es indirecta.

Indicadores sin inspeccion TLS:

Factores sospechosos:
  - Trafico HTTPS a CDNs (cloudfront.net, azureedge.net,
    fastly.net) desde procesos que normalmente no usan CDNs
  - Volumen significativo y periodico a subdominios de CDN
    (patron de beaconing sobre CDN)
  - Procesos inusuales comunicandose con CDNs (svchost.exe,
    rundll32.exe)
  - Certificados wildcard de CDN en conexiones desde
    procesos no-navegador

Consulta de hunting

# Trafico a CDNs conocidas desde procesos no-navegador (Sysmon Event ID 3)
event.code: "3" AND
destination.domain: (
  *.cloudfront.net OR *.azureedge.net OR *.fastly.net OR
  *.akamaiedge.net OR *.googleapis.com
) AND
NOT process.name: (chrome.exe OR firefox.exe OR msedge.exe OR iexplore.exe)

Analisis JA3/JA3S para C2

Los hashes JA3 identifican el software cliente basandose en los parametros del handshake TLS (cipher suites, extensiones, curvas). Los frameworks C2 tienen hashes JA3 caracteristicos que difieren de los navegadores legitimos.

Proceso de hunting con JA3

1. Extraer hashes JA3 unicos de ssl.log de Zeek
2. Comparar contra el baseline de JA3 de la organizacion (navegadores, aplicaciones conocidas)
3. Investigar hashes JA3 que no pertenecen al baseline
4. Buscar hashes conocidos de C2 frameworks en bases de datos publicas

# JA3 hashes unicos con conteo (Zeek)
cat ssl.log | zeek-cut ja3 | sort | uniq -c | sort -rn | head 20

# JA3 por IP origen y destino (contexto completo)
cat ssl.log | zeek-cut id.orig_h id.resp_h id.resp_p ja3 server_name | \
  sort -t$'\t' -k4 | head 50

JA3 conocidos de C2 frameworks

La comunidad de seguridad mantiene bases de datos de hashes JA3 asociados a herramientas maliciosas. Aunque los adversarios pueden modificar los parametros TLS para cambiar el hash JA3, muchos no lo hacen por defecto.

Puntos de referencia:

• ja3er.com: base de datos de JA3 con etiquetas de software
• ThreatFox (abuse.ch): IOCs que incluyen hashes JA3
• Publicaciones de Salesforce (creadores de JA3)

Patrones de C2 en Trafico Cifrado

Incluso con HTTPS, los metadatos de la comunicacion revelan patrones de C2:

Tamano consistente de datos

Los beacons de check-in tipicamente tienen un tamano de peticion y respuesta consistente (el implante envia su status y el servidor responde "sin comandos"). Cuando hay un comando, el tamano de la respuesta cambia.

Patron a buscar en conn.log:
  - Multiples conexiones al mismo destino
  - orig_bytes y resp_bytes consistentes en la mayoria
  - Cambios puntuales en el tamano (comando enviado/recibido)

Timing de respuesta

Los servidores C2 suelen responder rapidamente a los check-ins (la respuesta es precomputada). El tiempo de respuesta es tipicamente uniforme y menor que el de un servidor web normal que procesa contenido dinamico.

Ausencia de actividad humana

El trafico C2 automatizado no tiene las pausas, cambios de ritmo y variabilidad del trafico generado por un usuario humano navegando. Un host que genera trafico HTTPS perfectamente periodico sin variabilidad tipica de uso humano es candidato a investigacion.

C2 sobre Protocolos No Estandar

Algunos adversarios usan protocolos menos monitorizados para C2:

ICMP tunneling

Datos encapsulados en paquetes ICMP echo request/reply (ping). Detectable por:

• Volumen alto de ICMP entre un host interno y un externo
• Payload de ICMP con tamano mayor al normal (mas de 64 bytes)
• Patrones de beaconing en los timestamps de ICMP

C2 sobre HTTPS con WebSocket

WebSocket permite comunicacion bidireccional persistente. Un C2 sobre WebSocket se manifiesta como una conexion TCP larga al puerto 443 con transmision de datos bidireccional intermitente.

C2 sobre servicios cloud legitimos

Algunos implantes usan APIs de servicios cloud como canal C2:

• Google Sheets o Docs como dead drop
• Slack o Teams como canal de comandos
• GitHub o GitLab como repositorio de payloads

La deteccion se basa en identificar trafico anomalo a estas APIs desde procesos no autorizados.

Metodologia de Hunting de C2

Paso 1: Identificar candidatos a beaconing

Usar RITA, analisis estadistico o ML para generar una lista de pares (source, destination) con scores de beaconing alto.

Paso 2: Filtrar falsos positivos

El beaconing legitimo es comun: heartbeats de aplicaciones, polling de actualizaciones, checks de certificados, telemetria. Filtrar por:

• Destinos conocidos (update servers, telemetria de OS)
• Procesos conocidos (Windows Update, antivirus, backup)
• Puertos y servicios estandar con justificacion

Paso 3: Investigar candidatos restantes

Para cada candidato no descartado:

• Verificar el destino en feeds de CTI (MalwareIntel, OTX, ThreatFox)
• Analizar el certificado TLS (self-signed, issuer inusual)
• Verificar el hash JA3 contra bases de datos
• Correlacionar con actividad de endpoint (Sysmon: que proceso genera el trafico)
• Verificar el WHOIS del dominio/IP (registro reciente, hosting bulletproof)

Paso 4: Confirmar o descartar

Si la evidencia es suficiente para confirmar C2, escalar a respuesta a incidentes. Si no es concluyente, documentar y agregar a la lista de seguimiento.

Conclusion

El hunting de C2 es una de las actividades mas rentables en threat hunting porque la comunicacion C2 es continua y genera patrones detectables. Incluso con cifrado y tecnicas de evasion, los metadatos de la comunicacion (frecuencia, tamano, timing, certificados, JA3) proporcionan senales suficientes para la deteccion.

La combinacion de analisis de beaconing (estadistico o FFT), deteccion de DNS tunneling (longitud, entropia, volumen), verificacion de domain fronting (proceso vs destino) y fingerprinting JA3 cubre la mayoria de las tecnicas de C2 usadas por adversarios actuales. La clave es no depender de una sola tecnica de deteccion, sino correlacionar multiples indicadores para aumentar la confianza.