Túneles C2 sobre DoH y conexiones WebSocket

En una empresa bien administrada, todas las consultas DNS del puerto 53 se dirigen al resolutor corporativo, donde el Blue Team analiza dominios nuevos y entropía. Un atacante evade este control haciendo que su malware no use el puerto 53: envía las consultas DNS encapsuladas en peticiones HTTPS estándar hacia resolutores públicos de DoH (como Cloudflare 1.1.1.1 o Google 8.8.8.8) a través del puerto 443. Para el cortafuegos perimetral, parece navegación web ordinaria cifrada.

Aunque el contenido de la petición DoH viaja cifrado en HTTPS, los defensores cuentan con varias señales para detectarlo: 1) La IP de destino en el puerto 443 corresponde a resolutores públicos conocidos (1.1.1.1, 8.8.8.8). 2) Las peticiones HTTP/2 o HTTP/3 tienen cabeceras específicas (application/dns-message). La política de seguridad corporativa debe bloquear en el cortafuegos el acceso directo a IPs de resolutores DoH públicos, forzando a todos los equipos a utilizar los servidores internos autorizados.

Una conexión HTTP habitual abre un socket, pide un recurso y lo cierra. Un canal C2 sobre WebSockets inicia con una petición HTTP que incluye la cabecera Upgrade: websocket. Tras la aceptación del servidor (código 101 Switching Protocols), la conexión TCP permanece abierta indefinidamente en el puerto 443, permitiendo al atacante enviar comandos y recibir resultados en tiempo real sin emitir constantes peticiones periódicas (polling) que llamen la atención.

En el análisis de flujos (NetFlow o conn.log de Zeek), los túneles WebSockets maliciosos destacan por su perfil asimétrico: conexiones TCP que duran horas o días hacia IPs externas que no pertenecen a servicios conocidos de mensajería o chat corporativo, con paquetes pequeños transmitidos a intervalos regulares (keep-alives) combinados con picos esporádicos de tráfico cuando el operador ejecuta comandos.