Panorama: la paradoja del C2, vista desde el otro lado#

La infraestructura de comando y control (3.10) cerraba con una tensión que el operador ofensivo no puede resolver del todo: un implante existe para recibir órdenes y entregar resultados, de modo que tiene que comunicarse. Puede cifrar el contenido, imitar el perfil de un navegador, esconderse detrás de una red de distribución de contenido o repartirse entre servicios legítimos, pero no puede quedarse callado y seguir siendo útil. El capítulo anterior cerró la fase en que el adversario se mueve por la red interna; este cierra la fase en que habla con afuera, que es la que lo acompaña de principio a fin.

Sobre esa obligación se construye toda la caza de C2. Y su consecuencia metodológica es la que ordena el capítulo: como el contenido está cifrado y es cada vez más inaccesible, las señales que sirven son de forma. La periodicidad con que el implante llama a casa, la proporción entre lo que envía y lo que recibe, la cadena que declara como cliente, la entropía del nombre que resuelve, la cantidad de consultas que dispara hacia un mismo dominio padre. Ninguna de esas propiedades desaparece al cifrar el canal, porque todas viven en los metadatos de la sesión, y los metadatos son justamente lo que registran los sensores de red.

Este capítulo cierra tres hilos del bloque rojo a la vez: el C2 de 3.10, los canales encubiertos y la exfiltración (3.12) en su plano de red, y la correlación de infraestructura (2.4) —que aparece aquí en su función original, la de atribuir el destino una vez que se lo identificó—.

flowchart LR
    A["Endpoint
comprometido"] --> B["DNS
consulta de resolución"]
    A --> C["Proxy web
petición HTTP/CONNECT"]
    A --> D["Cortafuegos
sesión IP:puerto"]
    B --> E{"¿Qué revela
cada sensor?"}
    C --> E
    D --> E
    E --> F["DNS: entropía del nombre,
NXDOMAIN, TXT/NULL, volumen"]
    E --> G["Proxy: método, User-Agent,
Referer, cs-bytes/sc-bytes
(ciego al URI si no hay inspección TLS)"]
    E --> H["Firewall: puertos, dirección,
bytes agregados, periodicidad"]
    F --> I["Señales de FORMA
que sobreviven al cifrado"]
    G --> I
    H --> I

Los tres sensores y el mapa de sus puntos ciegos#

Antes de las técnicas conviene fijar qué observa cada plano, porque una parte grande de los errores de investigación consiste en buscar una señal en el sensor que estructuralmente no puede darla.

El cortafuegos registra la sesión a nivel de red: IP de origen y destino, puerto, protocolo, bytes enviados y recibidos, duración, y si la política permitió o denegó el tráfico. No sabe nada del contenido ni del nombre de dominio, pero es el único que ve todo el tráfico, incluido el que no pasa por el proxy —y los implantes que usan puertos no estándar o protocolos que no son HTTP dependen justamente de eso—.

El proxy web actúa como intermediario obligatorio de las peticiones salientes de los clientes internos (un forward proxy, por oposición al reverse proxy que filtra el tráfico entrante hacia servidores propios). Al mediar cada petición registra metadatos mucho más ricos: además de IP y puerto, el usuario autenticado, el dominio, el método HTTP, el código de estado, la categoría de la URL, el Content-Type, el Referer, el User-Agent y el conteo separado de bytes enviados y recibidos. Es el sensor definitivo del tráfico web saliente.

El DNS ve algo que los otros dos no: el nombre que el endpoint quiso resolver, antes de que exista conexión alguna. Un implante que resuelve un dominio y todavía no se conecta ya dejó rastro, y un túnel que usa DNS como transporte vive enteramente en este plano.

El punto ciego que más pesa es el del proxy, y conviene enunciarlo con precisión porque condiciona todo lo que sigue. Cuando no hay inspección TLS habilitada para un dominio o categoría, el cliente pide al proxy que abra un túnel opaco con el método CONNECT hacia el puerto 443 del destino. A partir de ahí el proxy transporta bytes cifrados sin poder leerlos: registra la conexión, el dominio y los volúmenes, pero queda ciego a la ruta específica (el URI-path) y al recurso accedido. En una red donde casi todo es HTTPS, esto significa que el grueso del análisis de proxy trabaja con dominio, método, volumen, temporización y cabeceras del establecimiento —exactamente las señales de forma— y no con contenido.

La inspección TLS recupera visibilidad pero no es gratis ni universal. Es un man-in-the-middle autorizado, con costo de rendimiento, implicaciones de privacidad que suelen exigir exclusiones legales (banca, salud), y limitaciones técnicas frente al certificate pinning de muchas aplicaciones. La conclusión práctica no es descartarla sino diseñar la detección para que no dependa de ella: si la caza solo funciona con el contenido en claro, deja de funcionar en la mitad del tráfico.

Cortafuegos: reconocimiento, asimetría y volumen#

Los registros de cortafuegos rinden en tres momentos distintos del ciclo de ataque, y los tres se leen con los mismos cuatro campos.

Reconocimiento. El escaneo es la primera señal medible. Desde afuera, los adversarios barren bloques de direcciones públicas buscando servicios expuestos —el 3389 de RDP sigue siendo el favorito, con fuerza bruta detrás—. Desde adentro, un equipo que ya cayó explora a sus vecinos: en el caso documentado, el host 10.10.10.10 itera sobre los puertos 445 (SMB), 23 (Telnet) y 3389 (RDP) contra el resto del segmento, y el analista descubre que 10.10.10.80 y 10.10.10.16 respondieron en 3389 con conteo de bytes en ambas direcciones, lo que confirma que el canal es viable. Ese es el paso previo al capítulo anterior: el mapa de rutas de propagación que precede al movimiento lateral (5.6).

Movimiento lateral por asimetría. La señal más útil del cortafuegos para el lateral no es qué puertos se usaron sino cuántos bytes fueron en cada dirección. Sumando el volumen por sesión, el caso analizado muestra un host que transfiere unos 17 MB al destino y recibe apenas 0,42 MB. Ese desbalance es el patrón clásico del drop: alguien está depositando una herramienta —psexesvc.exe o equivalente— en el otro extremo. Es la misma maniobra que 5.6 leyó desde el destino con 5140/5145 y 7045, vista ahora desde el plano de red y sin necesidad de tocar el host.

Exfiltración por volumen. El tercer uso es el más directo. En el caso documentado, la IP interna 10.10.10.10 envía un flujo enorme y sostenido hacia 31.216.144.5, un destino que no figura en ninguna línea base. La consulta WHOIS sobre esa dirección la ubica en la red de MEGA (mega.nz), lo que convierte una anomalía volumétrica en una fuga confirmada hacia un servicio de almacenamiento en la nube. Vale subrayar el movimiento metodológico, porque es exactamente el de 2.4: la telemetría identifica el destino, y el OSINT de infraestructura lo atribuye.

La distinción de política que ordena todo esto es la de filtrado de ingreso frente a filtrado de egreso (ingress vs egress filtering). Casi todas las organizaciones controlan con rigor lo que entra; muchas menos controlan lo que sale, y el C2 y la exfiltración viven enteramente en la dirección saliente. Una política de egreso restrictiva —solo los puertos y destinos necesarios, y solo desde los equipos que los necesitan— es a la caza de C2 lo que la segmentación de 5.6 fue al lateral: reduce el problema antes de tener que detectarlo.

Proxy: cabeceras que mienten y volúmenes que no#

Si el cortafuegos aporta forma y volumen, el proxy aporta identidad del cliente. Y ahí es donde el malware se delata, porque tiene que declarar algo.

El User-Agent es la mejor señal barata que existe. Un implante emite peticiones desde un proceso que no es un navegador, y esa diferencia aflora de tres maneras. La primera es la más burda y la más frecuente: la cadena declara el intérprete. El registro Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.14393.1944 no requiere análisis —es PowerShell descargando algo, y en el 99 % de los entornos eso no debería estar pasando contra un dominio externo—. Lo mismo vale para las cadenas de bibliotecas de scripting como python-requests. La segunda es la aleatorización: el minero PCASTLE genera cadenas de seis caracteres sin sentido (lasdowdmvvx) justamente para no repetir una firma estática, lo que lo vuelve cazable por entropía y rareza en lugar de por valor —un User-Agent visto una sola vez en toda la organización es sospechoso por definición—. La tercera es la falsificación bien hecha, y se rompe por inconsistencia: en el caso analizado, el implante declara ser un Chrome sobre Android (SM-G960F), pero el historial de ese mismo host muestra que su navegación legítima siempre usó un perfil de Chrome sobre Windows 10. El agente móvil no es imposible; es imposible en ese host.

El Referer admite el mismo tratamiento. Los adversarios lo falsifican para simular que la petición vino de una búsqueda, pero la mentira se cae en la línea temporal: si la petición sospechosa declara venir de una búsqueda de Google, tiene que existir, minutos antes y desde la misma IP interna, el acceso real a esa URL de búsqueda. Cuando no está, el campo fue insertado estáticamente en el código del implante. Es un buen ejemplo del principio general del capítulo: la cabecera individual se puede fabricar, la coherencia con el resto del historial no.

El método y la asimetría de bytes mapean las fases. El par cs-bytes (enviados por el cliente) y sc-bytes (recibidos) cuenta la historia del compromiso si se lo lee en orden. Una sesión de C2 recién establecida muestra más bytes recibidos que enviados: el adversario está bajando el payload secundario al endpoint. Cuando la proporción se invierte y el tráfico pasa a estar dominado por peticiones POST y CONNECT con volúmenes salientes crecientes, la fase cambió. El caso documentado lo muestra con claridad casi didáctica: las primeras diez peticiones tienen sc-bytes mayor (instalación), después los métodos pasan a ser exclusivamente POST y CONNECT con cargas de 1 MB cada una (recolección), y finalmente una ráfaga donde cs-bytes supera los 50 MB —la exfiltración consumada—.

Una consulta de caza que rinde en casi cualquier proxy: agrupar por (host interno, dominio de destino, User-Agent) durante 24 horas y ordenar por suma de cs-bytes descendente. Las primeras filas son, en orden de frecuencia, respaldos legítimos a la nube, cargas de archivos a servicios corporativos y —cuando aparece— la exfiltración. Cruzar el mismo agrupamiento con count(distinct User-Agent) por host expone las cadenas vistas una sola vez.

Beaconing: la periodicidad y el jitter con que se la disimula#

El beaconing —el latido con que el implante contacta a su servidor a intervalos regulares para pedir órdenes o entregar datos— es la firma de comportamiento más característica del C2, porque deriva de su diseño. El implante no puede saber cuándo el operador tendrá una orden nueva, así que pregunta periódicamente. Ese intervalo de espera (sleep interval) puede ser de un minuto, de una hora o de un día, y define el balance entre capacidad de respuesta del operador y ruido generado.

Detectarlo es un problema de series temporales, no de firmas. Se toman las marcas de tiempo de las conexiones entre un par host-destino, se calculan los intervalos entre conexiones sucesivas y se busca baja dispersión: un canal legítimo de navegación humana produce intervalos caóticos, mientras que un beacon produce una distribución concentrada alrededor de su valor de espera. La señal se refuerza con la uniformidad volumétrica —los latidos sin órdenes que entregar transportan aproximadamente la misma cantidad de bytes cada vez— y con la duración: una relación host-destino que se sostiene sin interrupción durante días, incluso fuera del horario laboral, es anómala aunque cada conexión individual sea trivial.

La contramedida ofensiva es el jitter: una variación aleatoria que el operador añade al intervalo base —por ejemplo, un 30 % sobre un beacon de sesenta segundos, con lo que las conexiones caen en cualquier punto entre 42 y 78 segundos— para romper el ritmo. El jitter degrada la detección, pero rara vez la elimina, y conviene entender por qué: aplana el pico de la distribución de intervalos, pero la distribución sigue estando acotada alrededor de un valor central, cosa que la navegación humana no hace. Un histograma de intervalos con jitter del 30 % sigue viéndose radicalmente distinto del de un usuario real, que alterna ráfagas de decenas de peticiones en segundos con horas de silencio. Elevar el jitter al punto de imitar tráfico humano obliga a sacrificar tanta regularidad que el canal se vuelve poco práctico para operar —que es la forma que toma, en este plano, la paradoja del capítulo—.

Dominios: entropía, novedad y reputación prestada#

El paso siguiente es mirar hacia dónde se habla, y aquí las categorías útiles son cuatro.

Los algoritmos de generación de dominios (DGA) son la respuesta del malware al bloqueo por lista: en lugar de un dominio fijo que el defensor puede sinkholear, el implante genera algorítmicamente cientos de nombres seudoaleatorios por día (del tipo imvhhht.ru) e intenta resolverlos hasta que uno responde —el operador solo necesita registrar el del día—. Deja dos señales fuertes y complementarias: alta entropía en la cadena del nombre (un dominio legítimo tiende a ser pronunciable; uno generado, no) y sobre todo una ráfaga de respuestas NXDOMAIN, porque la enorme mayoría de los nombres que consulta no existen. Un host que produce decenas de NXDOMAIN por minuto contra nombres de alta entropía está, casi por definición, infectado.

Los dominios recién registrados (newly registered domains) son el recurso de las campañas efímeras: no tienen historial, de modo que ningún motor de reputación los clasifica como maliciosos todavía. La contramedida es tratar la edad del dominio como atributo de riesgo por derecho propio y aplicar fricción a lo registrado en los últimos treinta días. En la misma familia entran el DNS dinámico (zapto.org, no-ip.org y similares), que da al operador un nombre estable sin registrar nada, y los TLD de bajo costo (.xyz, .top), sobrerrepresentados en la infraestructura maliciosa por razones puramente económicas. La categoría «no clasificado» del proxy merece un lugar propio: no es una acusación, pero un dominio que ningún proveedor de reputación conoce y al que un solo host de la organización contacta cada sesenta segundos concentra demasiadas rarezas juntas.

Las dos últimas categorías son la respuesta adversaria a todo lo anterior, y consisten en pedir prestada reputación ajena. El domain fronting abusa de las redes de distribución de contenido: la conexión TLS se establece contra un dominio legítimo y de excelente reputación alojado en la CDN, mientras el dominio malicioso real viaja en la cabecera Host cifrada, invisible desde afuera. El abuso de sitios de confianza (living-off-trusted-sites) va más lejos y elimina el dominio propio: el C2 se hospeda en GitHub, Pastebin, Discord, Telegram o un túnel de ngrok, servicios que ninguna organización puede bloquear en bloque sin romper trabajo legítimo. Contra ambas, la detección por reputación de dominio simplemente no aplica, y hay que volver a las señales de forma —periodicidad, volumen, proceso de origen, User-Agent— más el contexto de qué host y qué usuario están involucrados. Que un servidor de bases de datos consulte una URL cruda de GitHub cada cinco minutos es anómalo con independencia de la reputación impecable de GitHub.

DNS tunneling: cuando el canal es la resolución misma#

El caso extremo de canal encubierto en red convierte al DNS de mecanismo de descubrimiento en transporte. Su atractivo para el adversario es puramente estructural: el tráfico DNS es omnipresente, los cortafuegos permiten el puerto 53 hacia los resolvers corporativos casi sin excepción, y muy pocas organizaciones inspeccionan la carga útil de las consultas. Además, el implante nunca contacta directamente al servidor del adversario —consulta al resolver legítimo de la organización, que hace la recursión por él—, así que desde el cortafuegos la conversación parece interna e irreprochable.

El mecanismo es bidireccional y usa elementos del propio estándar. Hacia afuera, los datos se codifican en subdominios largos y de alta entropía de un dominio cuyo servidor autoritativo controla el adversario. Hacia adentro, las órdenes vuelven incrustadas en registros TXT o NULL, que admiten carga arbitraria. El playbook documentado recorre la cadena completa: implante inicial, despliegue de la baliza DNS, check-in con registros TXT de TTL sospechosamente bajo, subdominios codificados, descubrimiento de usuarios y equipos, enumeración de recursos compartidos (con sus 5140 correspondientes, otra vez el plano de 5.6), recolección de documentos sensibles, staging —compresión en AppData o Temp, que el EDR debería ver como creación inesperada de un archivo comprimido voluminoso— y finalmente chunking: la fragmentación de los datos en miles de consultas.

Y ahí es donde el canal se rompe, porque la exfiltración por DNS es estadísticamente insostenible. Transmitir megabytes en fragmentos que caben en una etiqueta de nombre de dominio exige un volumen de consultas que no tiene ninguna analogía legítima. Las señales que se disparan juntas son: número de consultas hacia un mismo dominio padre órdenes de magnitud sobre la línea base, longitud media y entropía de las etiquetas muy por encima de lo normal, proporción anómala de registros TXT o NULL, ratio de bytes salientes elevado, y tasa de NXDOMAIN alta. En el caso documentado el SOC detiene la operación exactamente así —volumen inusual de resoluciones hacia un dominio recién registrado, con salto de NXDOMAIN y ancho de banda saliente anómalo desde un solo equipo— y contiene bloqueando el puerto 53 hacia resolvers externos, que es también lo que frustra el intento de repliegue del adversario hacia un resolver alternativo.

La lección de arquitectura es directa y de las más rentables del capítulo: ningún endpoint debería poder hablar DNS con nadie que no sea el resolver corporativo. Con esa sola regla, el túnel queda obligado a pasar por un punto donde se lo registra y se lo puede analizar, y el repliegue a un resolver externo se vuelve imposible en lugar de meramente ruidoso.

De la detección a la atribución#

Identificar el destino es el final del trabajo de detección y el principio del de inteligencia. Aquí el capítulo se apoya en 2.4, cuyo instrumental era ofensivo en su presentación original pero es idéntico en su forma defensiva: con una IP o un dominio de C2 en la mano, el WHOIS y su histórico, el histórico de certificados TLS, los identificadores compartidos y las bases de datos de amenazas permiten expandir un indicador aislado a la infraestructura completa de la campaña. El movimiento más citado —el histórico de certificados que destapa el host real detrás de Cloudflare— fue introducido allí precisamente como técnica de atribución de C2, y este es su lugar de aplicación.

El propósito de ese esfuerzo no es la curiosidad. Un indicador atómico bloqueado es un dominio muerto que el adversario reemplaza en minutos; el conjunto de dominios que comparten certificado, registrante o identificador de analytics es el que permite bloquear la campaña en lugar del indicador y, sobre todo, buscar retrospectivamente en los registros si algún otro host de la organización tocó cualquiera de ellos. Es el ascenso por la pirámide del dolor que planteó 5.1: pasar del hash y la IP —que el adversario cambia sin costo— a la infraestructura y la metodología, que le cuestan rehacer.

Postura: qué se hace antes de tener que cazar#

Ordenado, otra vez, de más estructural a más analítico:

  • Filtrado de egreso restrictivo. La navegación general solo por el proxy; el tráfico saliente directo desde servidores, denegado salvo excepción justificada. Es lo que obliga al implante a pasar por un sensor.
  • DNS corporativo obligatorio: puerto 53 hacia el exterior bloqueado para todo lo que no sea el resolver de la organización, y registro completo de consultas en él. Sin esto, el plano DNS no existe como telemetría.
  • Inspección TLS donde sea viable, con exclusiones documentadas, pero detección diseñada para funcionar sin ella. Todo lo de este capítulo —periodicidad, volumen, entropía de nombres, cabeceras del establecimiento— sobrevive al cifrado.
  • Fricción por atributo de dominio: bloquear o marcar dominios recién registrados, DNS dinámico y categorías no clasificadas, en lugar de perseguir listas de indicadores que caducan.
  • Línea base de User-Agent y de pares host-destino. Saber qué cadenas y qué relaciones son normales es lo que convierte «una petición con PowerShell» de dato en alerta. Es la aplicación directa del principio de 5.2: no se sabe qué es anómalo sin saber qué es normal.
  • Cacería periódica por periodicidad y volumen, con la consulta de agrupación por host-destino-agente como punto de partida, y con una regla nueva como entregable —el hunt-to-detection de 5.1—.

Con esto quedan cerrados el C2 de 3.10, el plano de red de los canales encubiertos de 3.12 y la función de atribución de 2.4. Lo que este capítulo trató por el canal, la detección de exfiltración y el estegoanálisis (5.9) lo retoma por el dato: qué se fue, cómo se lo detecta cuando viaja escondido dentro de otro archivo, y por qué el estegoanálisis es un problema estadístico. Y el implante que produce todo este tráfico —cómo se lo desarma, y cómo evade al sensor del host— es materia de la detección de evasión y el análisis de malware (5.8).

Referencias#

  • blue-dfir/effective-threat-investigation/cap-09 — investigación con registros de cortafuegos: campos, tráfico permitido y denegado, escaneo externo e interno, asimetría de bytes en movimiento lateral, exfiltración por volumen, filtrado de ingreso y de egreso.
  • blue-dfir/effective-threat-investigation/cap-10 — análisis de registros de proxy web: campos del log, forward y reverse proxy, métodos HTTP, User-Agent, Referer, Content-Type, y el límite del método CONNECT sin inspección TLS.
  • blue-dfir/effective-threat-investigation/cap-11 — caza de comunicaciones salientes: reputación de dominio, DGA, DNS dinámico, User-Agent anómalo y falsificado, asimetría de bytes por fase, beaconing y jitter, domain fronting, abuso de sitios de confianza.
  • blue-dfir/incident-playbook/cap-08 — playbook de DNS tunneling: baliza DNS, registros TXT y NULL, subdominios de alta entropía, staging y compresión, chunking, NXDOMAIN y contención por bloqueo del puerto 53.
  • MITRE ATT&CK — T1071 (Application Layer Protocol) y sus subtécnicas .001 (Web Protocols) y .004 (DNS); T1568.002 (Domain Generation Algorithms); T1090.004 (Domain Fronting); T1102 (Web Service); T1572 (Protocol Tunneling); T1001 (Data Obfuscation); T1048.003 (Exfiltration Over Unencrypted Non-C2 Protocol); T1074 (Data Staged); T1560 (Archive Collected Data). Mitigaciones M1031 (Network Intrusion Prevention), M1037 (Filter Network Traffic), M1021 (Restrict Web-Based Content).