← Volver al curso

Lab 3 — Caza de anomalías

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:

OBSERVATION ↓ SIGNALS ↓ CORRELATION ↓ CONTEXT ↓ HYPOTHESIS

Archivos necesarios

Para este laboratorio utilizaremos cuatro capturas de tráfico DNS: 

lab3-baseline.pcapng
lab3-long-qname.pcapng
lab3-dga-like.pcapng
lab3-tunneling-like.pcapng
Importante: los nombres de los archivos sirven para organizar el laboratorio, pero no deben utilizarse como evidencia. Tu conclusión debe surgir del tráfico que observes.

No necesitas generar tráfico adicional. Todo el análisis se realizará sobre los archivos PCAP proporcionados.

Parte 1 — Establecer un baseline

Abre:

lab3-baseline.pcapng

Antes 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:

dns

Observa la captura durante unos segundos. No intentes clasificar todavía cada paquete.

Pregunta: ¿Qué aspecto tiene el tráfico DNS cuando no estamos buscando algo específico?

Paso 2 — Observar solamente consultas

Aplica:

dns.flags.response == 0

Observa los QNAME y busca diversidad en:

Preguntas

  1. ¿Los QNAME tienen aproximadamente la misma longitud?
  2. ¿Todos pertenecen al mismo dominio?
  3. ¿Los nombres parecen generados automáticamente?
  4. ¿Existe un patrón temporal evidente?
  5. ¿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 == 3

Probablemente encontrarás algunas respuestas NXDOMAIN. Esto es importante.

NXDOMAIN ≠ ATTACK

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:

¿NXDOMAIN forma parte de un patrón junto con otras señales?

Parte 2 — Cuando el QNAME llama la atención

Abre:

lab3-long-qname.pcapng

Paso 1 — Mostrar consultas A

Aplica:

dns.flags.response == 0 && dns.qry.type == 1

Examina la columna Info. Encontrarás nombres relativamente cortos y otros considerablemente más largos.

Preguntas

  1. ¿Cómo cambia la longitud de los QNAME?
  2. ¿Todos los nombres largos parecen iguales?
  3. ¿Algunos siguen siendo comprensibles para una persona?
  4. ¿Otros contienen secuencias que parecen menos naturales?
  5. ¿La longitud por sí sola permite saber por qué existe esa consulta?

Selecciona una consulta corta y una larga y expande: 

Domain Name System → Queries

Compara sus nombres.

Paso 2 — Examinar las respuestas

Aplica:

dns.flags.response == 1

Observa el RCODE de las respuestas. En esta captura las consultas controladas reciben respuestas DNS satisfactorias.

Pregunta: Si un QNAME es muy largo pero DNS responde correctamente, ¿podemos concluir que existe un ataque?
LONG QNAME ≠ DNS TUNNEL

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.pcapng

Esta vez no busques solamente una consulta extraña. Busca comportamiento.

Paso 1 — Mostrar las consultas

Aplica:

dns.flags.response == 0 && dns.qry.type == 1

Observa los QNAME.

Preguntas

  1. ¿Cuántos nombres diferentes aparecen?
  2. ¿Los nombres son fáciles de leer?
  3. ¿Parecen palabras o servicios reconocibles?
  4. ¿Notas similitudes en su longitud y estructura?
  5. ¿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 == 3

Cuenta las respuestas y después compara mentalmente este resultado con el baseline.

Preguntas

  1. ¿NXDOMAIN aparece ocasionalmente o domina el conjunto observado?
  2. ¿Las respuestas NXDOMAIN están asociadas con los nombres pseudoaleatorios?
  3. ¿Tenemos ahora una señal o varias señales relacionadas?
MANY UNIQUE FQDNs + PSEUDORANDOM-LOOKING NAMES + HIGH NXDOMAIN ↓ STRONGER PATTERN

Este comportamiento es compatible con características que pueden observarse en actividad DGA-like.

Esto todavía no demuestra que exista malware. Para sostener una conclusión de ese tipo necesitaríamos contexto adicional sobre el cliente, procesos, endpoints, inteligencia de amenazas y otros datos.

Parte 4 — Cuando DNS funciona y aun así el patrón importa

Abre:

lab3-tunneling-like.pcapng

Esta captura introduce una diferencia importante.

Paso 1 — Examinar las consultas

Aplica:

dns.flags.response == 0 && dns.qry.type == 1

Observa los QNAME.

Preguntas

  1. ¿Cuántos FQDN diferentes observas?
  2. ¿Qué parte de los nombres cambia?
  3. ¿Qué parte permanece constante?
  4. ¿Los labels variables parecen lenguaje natural?
  5. ¿Existe un dominio base común?

Busca específicamente:

telemetry.example.com

Puedes 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.com

Paso 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:

NOERROR ≠ BENIGN

Del mismo modo que:

NXDOMAIN ≠ MALICIOUS

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:

MANY UNIQUE SUBDOMAINS + COMMON BASE DOMAIN + PSEUDORANDOM-LOOKING LABELS + REPEATED DNS ACTIVITY ↓ INTERESTING PATTERN

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é investigarías después?

¿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:

¿Qué señales aparecen juntas y qué hipótesis puedo construir a partir de ellas?

Parte 6 — El desafío final

Responde antes de continuar:

¿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.

OBSERVATION ↓ SIGNALS ↓ CORRELATION ↓ CONTEXT ↓ HYPOTHESIS

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:

Ahora imagina el mismo procedimiento con:

10 MILLION DNS QUERIES → 100 MILLION DNS QUERIES

La metodología sigue siendo válida. Lo que deja de ser viable es hacerla manualmente.

MANUAL ANALYSIS ↓ WORKS AT SMALL SCALE ↓ DNS VOLUME GROWS ↓ AUTOMATION BECOMES NECESSARY

Aquí termina el objetivo de este laboratorio.

Ya sabemos qué buscar. El siguiente problema es descubrir cómo hacerlo a escala.

Cierre del laboratorio

ONE SIGNAL ≠ AN ATTACK
MULTIPLE SIGNALS + CORRELATION + CONTEXT ↓ BETTER HYPOTHESIS

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.