Bloque 4 — Cuando el patrón importa más que el ataque
Objetivo del Bloque 4
Ir al laboratorio práctico del Bloque 4 ↓
Identificar patrones en grandes conjuntos de transacciones DNS y utilizar varias señales de comportamiento para determinar qué tráfico merece una investigación más profunda.
Durante este bloque analizaremos características como longitud de nombres, entropía, frecuencia, periodicidad, cantidad de NXDOMAIN y tamaño de las respuestas.
Una consulta aislada puede parecer extraña y seguir siendo legítima. El valor aparece cuando observamos repetición, similitud y contexto.
4.1 De una transacción a un patrón
En el Bloque 3 trabajamos con una unidad de análisis muy concreta:
QUERY → RESPONSEAhora ampliamos la perspectiva. Una captura puede contener cientos o miles de transacciones:
QUERY → RESPONSE
QUERY → RESPONSE
QUERY → RESPONSE
QUERY → RESPONSE
...Una sola transacción nos dice qué ocurrió en un momento específico. Muchas transacciones pueden mostrar cómo se comporta un cliente, una aplicación o un resolver a lo largo del tiempo.
Ejemplo
Una consulta como:
a8f3k2.example.compor sí sola no demuestra nada.
Pero si observamos:
a8f3k2.example.com
m91xq7.example.com
z4p8n1.example.com
k2v7c9.example.com
...generadas continuamente por el mismo cliente, la investigación cambia. Ya no preguntamos únicamente qué significa un nombre; preguntamos qué patrón existe entre las consultas.
Al observar muchas transacciones podemos medir:
LONGITUD
FRECUENCIA
PERIODICIDAD
SIMILITUD
VOLUMEN
RESULTADOS
TAMAÑO4.2 Longitud de nombres y labels
En el Bloque 1 vimos que un nombre DNS está formado por labels y que existen límites definidos para su longitud. Aquí no necesitamos volver a estudiar esos límites.
Ahora nos interesa una pregunta distinta:
¿La longitud de los nombres que observamos forma un patrón?
Ejemplo normal
www.example.com
mail.example.com
api.example.comEjemplo que merece atención
a8f3d91c7e4b2a9f.example.com
b9e2f84d7a1c5b30.example.com
c4a7e2d98f1b6c53.example.comPodemos observar:
- labels largos;
- cambios frecuentes;
- estructura similar;
- cadenas difíciles de interpretar visualmente.
Eso no demuestra exfiltración, tunneling o DGA. Sólo indica que existe una propiedad que merece análisis.
La longitud adquiere más valor cuando la correlacionamos con frecuencia, entropía y resultados.
4.3 Entropía y nombres que parecen aleatorios
Algunos nombres DNS contienen cadenas que visualmente parecen aleatorias:
a8f3d91c7e4b2a9f.example.com
x7q2m4p9k1z8n6c3.example.comMuchas aplicaciones legítimas generan identificadores, hashes, tokens o nombres dinámicos. Por eso no debemos diagnosticar basándonos únicamente en cómo se ve un label.
Más que una cadena aislada, buscamos repetición de propiedades como:
- longitud similar;
- alta variación;
- poca estructura reconocible;
- cambios frecuentes;
- gran cantidad de nombres diferentes.
La entropía puede ayudar a identificar comportamientos asociados con generación automática de nombres, DGA, transporte de datos mediante DNS o identificadores dinámicos de aplicaciones.
ALTA ENTROPÍA
+
LABELS LARGOS
+
ALTA FRECUENCIA
+
MUCHOS NOMBRES ÚNICOS4.4 Frecuencia y periodicidad
Otra propiedad importante aparece cuando observamos cuándo ocurren las consultas.
Frecuencia
La frecuencia indica cuántas consultas ocurren durante un periodo.
5 consultas / minuto
vs.
500 consultas / segundoUn volumen elevado puede llamar nuestra atención, pero una aplicación, un navegador, un proxy o un sistema de monitoreo también pueden generar muchas consultas legítimas.
Periodicidad
La periodicidad aparece cuando las consultas se repiten siguiendo intervalos similares.
Query
↓ 60 s
Query
↓ 60 s
Query
↓ 60 s
QueryEste comportamiento puede aparecer en health checks, monitoreo, aplicaciones que actualizan información periódicamente, descubrimiento de servicios o mecanismos de beaconing.
Durante el análisis conviene preguntar:
- ¿quién genera las consultas?
- ¿a qué dominio?
- ¿cuántos nombres diferentes aparecen?
- ¿con qué intervalo?
- ¿el comportamiento es constante o aparece en bursts?
- ¿es normal para ese cliente o aplicación?
4.5 DNS Rebinding: cuando el resultado también forma un patrón
Hasta ahora observamos patrones en cómo se generan las consultas. Pero también podemos encontrar patrones en las respuestas DNS.
Uno de ellos aparece cuando un nombre público devuelve una dirección que normalmente pertenece al entorno local:
PUBLIC DOMAIN
↓
127.0.0.1o:
PUBLIC DOMAIN
↓
192.168.x.xEste comportamiento puede activar mecanismos de protección contra DNS Rebinding.
¿Qué busca detectar una protección anti-rebinding?
De forma simplificada, un ataque de DNS Rebinding intenta utilizar un nombre aparentemente público para terminar accediendo a recursos que deberían ser locales o internos.
PUBLIC NAME
↓
PUBLIC RESPONSE
↓
PRIVATE / LOOPBACK RESPONSE
↓
INTERNAL RESOURCEUna respuesta privada o loopback puede existir por otras razones, como políticas del servicio, sinkholing o mecanismos utilizados para deshabilitar un endpoint.
Caso real: ssc.33across.com
Durante una investigación, Infoblox Threat Defense clasificó consultas a
ssc.33across.com como comportamiento de Rebinding porque el
dominio resolvía a 127.0.0.1.
La pregunta de troubleshooting fue:
¿Quién está generando esa respuesta?
Las consultas directas a los servidores autoritativos confirmaron que
127.0.0.1 estaba siendo publicado por el propio DNS
autoritativo y no era una dirección introducida por la red local.
Comparar resolvers cambia la perspectiva
Al consultar el mismo FQDN mediante distintos resolvers, las respuestas no siempre fueron iguales. Se observaron respuestas loopback y también direcciones públicas.
┌── Resolver A → 127.0.0.1
PUBLIC DOMAIN ──┼── Resolver B → 127.0.0.1
└── Resolver C → PUBLIC IPAhora ya no observamos únicamente una respuesta. Observamos un patrón de resultados.
¿Falso positivo o detección correcta?
La detección puede ser técnicamente correcta porque
PUBLIC NAME → LOOPBACK ADDRESS es un patrón asociado con
Rebinding. Pero la intención detrás del comportamiento podría ser
legítima, por ejemplo null routing, sinkhole o una respuesta condicionada.
Cómo investigar el patrón
4.6 Muchos NXDOMAIN
En el Bloque 3 analizamos NXDOMAIN como resultado de una transacción individual. Ahora cambia la pregunta.
QUERY → NXDOMAIN
QUERY → NXDOMAIN
QUERY → NXDOMAIN
QUERY → NXDOMAIN
...El filtro base sigue siendo:
dns.flags.rcode == 3pero ahora nos interesa cuántas veces ocurre, quién lo genera y qué nombres aparecen.
Podemos preguntar:
- ¿provienen del mismo cliente?
- ¿afectan al mismo dominio?
- ¿los subdominios cambian constantemente?
- ¿los nombres parecen generados automáticamente?
- ¿el volumen aumenta de forma sostenida o en bursts?
a83k2.example.com → NXDOMAIN
m91x7.example.com → NXDOMAIN
z42p8.example.com → NXDOMAIN
k27c9.example.com → NXDOMAINEse conjunto ya no describe sólo nombres inexistentes. Describe un patrón de generación de nombres.
Las causas también pueden ser legítimas: aplicaciones mal configuradas, search suffix incorrecto, software de descubrimiento o clientes buscando recursos que ya no existen.
MANY NXDOMAIN
+
UNIQUE SUBDOMAINS
+
HIGH ENTROPY
+
HIGH FREQUENCY4.7 Mensajes grandes y DNS Amplification
Otra señal aparece cuando existe una gran diferencia entre el tamaño de una consulta y el tamaño de su respuesta.
SMALL QUERY
↓
DNS SERVER
↓
LARGE RESPONSEDNS puede producir respuestas grandes de forma completamente legítima: múltiples registros, DNSSEC, información adicional o respuestas complejas.
¿Qué es la amplificación?
En un escenario de DNS Amplification, un atacante intenta aprovechar una consulta pequeña que produce una respuesta mucho mayor. Si además puede falsificar la dirección IP de origen en tráfico UDP, las respuestas pueden dirigirse hacia una víctima.
ATTACKER
│
│ small spoofed query
▼
DNS SERVER
│
│ large response
▼
VICTIMPodemos empezar buscando respuestas con muchos registros:
dns.count.answers > 10Pero en el curso no necesitamos memorizar un único umbral. Queremos comparar:
QUERY SIZE
vs.
RESPONSE SIZEPor ejemplo:
Query: 74 bytes
Response: 1250 bytesLa investigación gana fuerza cuando combinamos:
SMALL QUERY
+
LARGE RESPONSE
+
UDP
+
HIGH VOLUME
+
REPEATED REQUESTS4.8 Integrar señales
Durante este bloque observamos distintas propiedades del tráfico DNS:
LONGITUD
ENTROPÍA
FRECUENCIA
PERIODICIDAD
NXDOMAIN
REBINDING
TAMAÑO DE RESPUESTACada una puede llamar nuestra atención, pero ninguna basta por sí sola.
Combinar señales
Por ejemplo:
MISMO CLIENTE
+
CIENTOS DE SUBDOMINIOS ÚNICOS
+
LABELS LARGOS
+
ALTA ENTROPÍA
+
ALTA FRECUENCIAUna sola característica podría ser legítima. Juntas forman un patrón que merece investigación.
Cuatro preguntas para organizar el análisis
| Dimensión | Pregunta |
|---|---|
| WHO | ¿Quién genera el comportamiento? |
| WHAT | ¿Qué nombres, tipos o respuestas aparecen? |
| HOW OFTEN | ¿Con qué frecuencia o periodicidad ocurre? |
| HOW DIFFERENT | ¿Qué tan distinto es del comportamiento esperado? |
Workflow del Bloque 4
Los patrones no aparecen porque una señal sea extraña. Aparecen cuando varias observaciones muestran un comportamiento consistente.
Referencias
- Farnham, G. Detecting DNS Tunneling. SANS Institute / GIAC.
-
Material práctico del curso utilizado para el caso de DNS Rebinding
de
ssc.33across.com.
Laboratorio práctico — Bloque 4
Busca patrones en cuatro capturas de laboratorio simuladas y construye hipótesis basadas en evidencia.
Datos del laboratorio: las cuatro capturas son ejemplos sintéticos creados para el curso; no representan ataques reales ni prueban intención maliciosa. Descárgalas antes de comenzar:
En este laboratorio analizarás diferentes capturas de tráfico DNS utilizando Wireshark. El objetivo no es identificar un ataque a partir de una única consulta, sino reconocer patrones mediante la combinación de diferentes señales.
Objetivo
Al finalizar este laboratorio deberás ser capaz de construir una hipótesis basada en evidencia y explicar por qué una sola característica no es suficiente para determinar que existe actividad maliciosa.
Durante el análisis observaremos señales como:
- longitud y estructura de los QNAME;
- composición de los nombres;
- cantidad de FQDN únicos;
- respuestas NXDOMAIN;
- concentración de consultas;
- dominios base compartidos;
- comportamiento a lo largo del tiempo.
Archivos necesarios
Para este laboratorio utilizaremos cuatro capturas de tráfico DNS:
lab3-baseline.pcap
lab3-long-qname.pcap
lab3-dga-like.pcap
lab3-tunneling-like.pcapNo necesitas generar tráfico adicional. Todo el análisis se realizará sobre los archivos PCAP proporcionados.
Parte 1 — Establecer un baseline
Abre:
lab3-baseline.pcapAntes de buscar anomalías necesitamos entender cómo se comporta una muestra de tráfico DNS relativamente normal.
Paso 1 — Mostrar solamente DNS
Aplica el siguiente filtro:
dnsObserva la captura durante unos segundos. No intentes clasificar todavía cada paquete.
Paso 2 — Observar solamente consultas
Aplica:
dns.flags.response == 0Observa los QNAME y busca diversidad en:
- dominios consultados;
- longitud de los nombres;
- tipos de consulta;
- intervalos entre consultas.
Preguntas
- ¿Los QNAME tienen aproximadamente la misma longitud?
- ¿Todos pertenecen al mismo dominio?
- ¿Los nombres parecen generados automáticamente?
- ¿Existe un patrón temporal evidente?
- ¿Ves diversidad entre las consultas?
No buscamos una respuesta binaria. Estamos construyendo una referencia contra la cual compararemos las demás capturas.
Paso 3 — Buscar NXDOMAIN
Aplica:
dns.flags.response == 1 && dns.flags.rcode == 3Probablemente encontrarás algunas respuestas NXDOMAIN. Esto es importante.
Un usuario puede escribir incorrectamente un dominio, una aplicación puede consultar un nombre que ya no existe o un servicio puede realizar consultas que legítimamente produzcan NXDOMAIN.
La pregunta importante no es “¿Existe NXDOMAIN?”, sino:
Parte 2 — Cuando el QNAME llama la atención
Abre:
lab3-long-qname.pcapPaso 1 — Mostrar consultas A
Aplica:
dns.flags.response == 0 && dns.qry.type == 1Examina la columna Info. Encontrarás nombres relativamente cortos y otros considerablemente más largos.
Preguntas
- ¿Cómo cambia la longitud de los QNAME?
- ¿Todos los nombres largos parecen iguales?
- ¿Algunos siguen siendo comprensibles para una persona?
- ¿Otros contienen secuencias que parecen menos naturales?
- ¿La longitud por sí sola permite saber por qué existe esa consulta?
Selecciona una consulta corta y una larga y expande:
Domain Name System → QueriesCompara sus nombres.
Paso 2 — Examinar las respuestas
Aplica:
dns.flags.response == 1Observa el RCODE de las respuestas. En esta captura las consultas controladas reciben respuestas DNS satisfactorias.
La longitud puede ser una señal útil, pero necesita contexto. Un nombre largo puede aparecer legítimamente en servicios cloud, sistemas de distribución, telemetría, tracking, aplicaciones o infraestructuras automatizadas.
Parte 3 — Muchos nombres que no existen
Abre:
lab3-dga-like.pcapEsta vez no busques solamente una consulta extraña. Busca comportamiento.
Paso 1 — Mostrar las consultas
Aplica:
dns.flags.response == 0 && dns.qry.type == 1Observa los QNAME.
Preguntas
- ¿Cuántos nombres diferentes aparecen?
- ¿Los nombres son fáciles de leer?
- ¿Parecen palabras o servicios reconocibles?
- ¿Notas similitudes en su longitud y estructura?
- ¿Los nombres comparten necesariamente un mismo dominio base?
Ahora tenemos una señal que no aparecía con la misma intensidad en el baseline:
muchos nombres únicos con apariencia pseudoaleatoria.
Pero todavía no debemos concluir nada.
Paso 2 — Examinar NXDOMAIN
Aplica:
dns.flags.response == 1 && dns.flags.rcode == 3Cuenta las respuestas y después compara mentalmente este resultado con el baseline.
Preguntas
- ¿NXDOMAIN aparece ocasionalmente o domina el conjunto observado?
- ¿Las respuestas NXDOMAIN están asociadas con los nombres pseudoaleatorios?
- ¿Tenemos ahora una señal o varias señales relacionadas?
Este comportamiento es compatible con características que pueden observarse en actividad DGA-like.
Parte 4 — Cuando DNS funciona y aun así el patrón importa
Abre:
lab3-tunneling-like.pcapEsta captura introduce una diferencia importante.
Paso 1 — Examinar las consultas
Aplica:
dns.flags.response == 0 && dns.qry.type == 1Observa los QNAME.
Preguntas
- ¿Cuántos FQDN diferentes observas?
- ¿Qué parte de los nombres cambia?
- ¿Qué parte permanece constante?
- ¿Los labels variables parecen lenguaje natural?
- ¿Existe un dominio base común?
Busca específicamente:
telemetry.example.comPuedes utilizar:
dns.qry.name contains "telemetry.example.com"Observa qué ocurre con el label situado a la izquierda.
Tenemos muchos nombres diferentes, pero todos siguen una estructura similar:
<variable>.telemetry.example.comPaso 2 — Examinar las respuestas
Aplica:
dns.flags.response == 1 && dns.flags.rcode == 0 && dns.qry.name contains "telemetry.example.com"Las consultas reciben NOERROR.
Esto introduce una lección fundamental:
Del mismo modo que:
El RCODE nos dice el resultado de la operación DNS. No determina por sí mismo la intención del tráfico.
Paso 3 — Pensar como analista
Observa nuevamente las consultas.
Ahora tenemos varias señales:
Este comportamiento es compatible con algunas características que podrían observarse en DNS tunneling-like traffic.
Pero seguimos sin demostrar que exista un túnel DNS real.
¿Qué host genera las consultas? ¿Qué proceso las genera? ¿El dominio es conocido? ¿Existe inteligencia de amenazas relacionada? ¿Es normal ese comportamiento para ese dispositivo? ¿Qué volumen mantiene durante periodos más largos?
Parte 5 — Correlacionar las evidencias
Ahora compara los cuatro PCAP y completa la siguiente tabla utilizando solamente tus observaciones.
| Señal | Baseline | Long QNAME | DGA-like | Tunneling-like |
|---|---|---|---|---|
| QNAMEs largos | ||||
| Apariencia pseudoaleatoria | ||||
| Muchos FQDN únicos | ||||
| NXDOMAIN | ||||
| Dominio base común | ||||
| Frecuencia / concentración | ||||
| Varias señales correlacionadas |
No existe una fórmula matemática que debas aplicar aquí. El objetivo es aprender a preguntarte:
Parte 6 — El desafío final
¿Cuál de las cuatro capturas demuestra que existe un ataque?
La respuesta es: ninguna, por sí sola.
Las capturas permiten encontrar comportamientos diferentes y algunas contienen patrones compatibles con técnicas que merecerían investigación, pero los PCAP por sí solos no demuestran intención maliciosa.
Ésta es precisamente la diferencia entre encontrar una anomalía y completar una investigación.
Una hipótesis sólida puede justificar nuevas acciones de investigación. No sustituye la evidencia adicional necesaria para confirmar qué está ocurriendo.
Parte 7 — El problema de escala
Durante este laboratorio pudiste:
- abrir una captura;
- leer los QNAME;
- aplicar filtros;
- contar NXDOMAIN;
- comparar nombres;
- identificar dominios base;
- observar frecuencia;
- correlacionar señales.
Ahora imagina el mismo procedimiento con:
La metodología sigue siendo válida. Lo que deja de ser viable es hacerla manualmente.
Aquí termina el objetivo de este laboratorio.
Ya sabemos qué buscar. El siguiente problema es descubrir cómo hacerlo a escala.
Cierre del laboratorio
El objetivo no es encontrar una señal mágica. El objetivo es aprender a reconocer cuándo diferentes señales forman un patrón que merece una investigación más profunda.