El protocolo que nadie se anima a cerrar

Todo el edificio de la red corporativa está hecho de puertas que se pueden cerrar. El 445 se cierra. El 3389 se cierra, y ojalá lo hicieras. El tráfico saliente se filtra por proxy, se inspecciona, se bloquea por reputación. Pero hay un puerto que queda abierto siempre, en todas partes, hacia el resolver de la organización, y es el 53. Nadie lo cierra del todo, porque cerrar el DNS es que las máquinas dejen de encontrar a las otras máquinas: es apagar internet puertas adentro y que te llamen a las tres de la mañana. Esa imposibilidad práctica de bloquearlo es exactamente lo que lo convierte en el mejor canal encubierto que hay.

El puerto que no se puede cerrar sin apagar la luz.

El DNS es plomería. Traduce nombres a números y nadie lo mira, del mismo modo que nadie mira las cañerías hasta que hay una inundación. Los cortafuegos perimetrales dejan salir UDP y TCP por el 53 hacia los resolvers sin inspeccionar la carga, porque inspeccionar cada consulta de nombre de cada máquina es caro y porque, total, “es solo DNS”. Ese “es solo DNS” es una de esas frases que suenan tranquilizadoras hasta que alguien las usa en tu contra. Un implante que habla por DNS no necesita abrir ningún puerto raro, no dispara la alarma del proxy, no aparece en la lista de conexiones sospechosas: usa la misma tubería que usa Windows para encontrar el controlador de dominio. Sale por la puerta que dejaste abierta porque tenías que dejarla abierta.

El mensaje va en la pregunta, no en la respuesta.

Acá está la parte elegante, y la que cuesta ver la primera vez. Uno piensa en el DNS como un sistema de preguntas y respuestas: pregunto por ejemplo.com, me responde una IP. Pero para exfiltrar no hace falta la respuesta —hace falta la pregunta—. El implante codifica los datos robados dentro del propio nombre que consulta: en vez de preguntar por www, pregunta por 4a7f2e9c8b1d0a6f.datos.dominio-del-atacante.xyz, donde esa tira de basura hexadecimal en el subdominio es el archivo, troceado y codificado. El resolver corporativo, obedientemente, no encuentra ese nombre en su caché, así que lo reenvía hacia arriba hasta llegar al servidor autoritativo del dominio —que es del atacante—, y ahí, del otro lado, alguien lee el subdominio, lo decodifica, y ya tiene el pedazo. La respuesta viaja de vuelta camuflada en un registro TXT o NULL, que son los campos donde el DNS admite texto arbitrario y que casi nadie audita. Los datos salieron de la red sin que una sola conexión “saliente” figure como tal. Salieron preguntando.

La entropía delata al que habla en clave.

Un canal así es sigiloso, no invisible, y la diferencia es todo. El truco que lo hace funcionar —meter datos en los nombres— es también su tell, porque un nombre de dominio legítimo no se parece en nada a datos codificados. mail.google.com es corto, pronunciable, repetido millones de veces. 4a7f2e9c8b1d0a6f8e3c... es largo, aleatorio y único: alta entropía, la medida de cuánto se parece una cadena a ruido. Ningún dominio que una persona vaya a visitar tiene etiquetas de sesenta caracteres de hexadecimal puro. Entonces se caza por la forma del nombre: longitud anómala de las etiquetas, entropía por encima de un umbral, y —la señal más gorda— volumen. Exfiltrar un documento por DNS significa trocearlo en miles de consultas diminutas (chunking), y eso dispara el número de resoluciones hacia un único dominio padre de un modo que no tiene explicación inocente. Sube también la tasa de NXDOMAIN, la respuesta que significa “ese nombre no existe”, porque muchas de esas consultas-basura no apuntan a nada real: son puro transporte. Una máquina que de golpe genera diez mil consultas hacia subdominios irrepetibles de un .xyz recién registrado, con la mitad devolviendo NXDOMAIN, no está resolviendo nombres. Está hablando.

Lo que pasa mientras nadie mira la tubería.

El túnel es solo el canal; adentro pasa un incidente entero, y con la calma de quien se sabe invisible. Con el C2 andando por DNS, el intruso perfila el entorno —qué usuario, qué máquina, qué comparte la red—, encuentra los recursos por SMB (los eventos 5140 en el firewall interno, si alguien los mira), junta los documentos que le interesan, y antes de sacarlos los comprime en una carpeta temporal, en AppData o en Temp, porque un .zip gordo que aparece de la nada es más fácil de mover en pedazos. Esa compresión previa —el staging— es una de las señales más útiles y de las más ignoradas: el EDR puede ver nacer un archivo comprimido voluminoso justo después de una racha de lecturas sobre documentos financieros, y esa secuencia, compresión más lecturas más consultas DNS anómalas, es una historia, no tres alertas sueltas. El SOC del caso no cazó el túnel por ninguna de esas cosas por separado. Lo cazó cuando el volumen de resoluciones hacia un dominio nuevo se volvió estadísticamente insostenible, y recién ahí bloqueó el 53 hacia todo lo que no fuera el resolver corporativo. Tarde para los primeros megabytes; a tiempo para el resto.

Es el mismo patrón que ya conté con el ritmo del beacon y con el cebo que llama a casa: la infraestructura que existe para funcionar de buena fe es, por eso mismo, la que mejor se abusa. El resolver reenvía la consulta porque su trabajo es reenviar consultas. No hay bug que explotar. Hay una función legítima usada para un fin que no era el suyo, que es la forma más difícil de detectar precisamente porque, mirada de cerca, cada paso individual es correcto.

La pregunta que uno querría poder hacer —"¿este DNS es malicioso?"— no tiene respuesta a nivel de una consulta: una consulta a un dominio raro es rara, no es un crimen. La respuesta aparece un nivel más arriba, en la estadística: en la entropía de los nombres, en el volumen por dominio padre, en la curva de NXDOMAIN. No se caza la consulta. Se caza la conversación. Y la conversación, cuando alguien está usando la plomería para hablar en clave, tiene una forma que la plomería honesta nunca tuvo.