Problema

En entornos con cientos de servidores y agentes de monitoreo, los indicadores de compromiso (IoC) de una cadena de suministro pueden esconderse entre millones de eventos de registro. Los atacantes suelen aprovechar:

  • consultas DNS que generan subdominios de alta entropía (DGA) y respuestas CNAME que actúan como señal de “targeting”.
  • carga de DLLs sospechosas a través de procesos legítimos, visible en Sysmon EventID 7 y 22.
  • beacon de Cobalt Strike o herramientas similares que reutilizan procesos de infraestructura de gestión (por ejemplo, Orion).
  • abuso de tokens SAML para escalar privilegios en Azure AD.

Cuando los logs no están estructurados, los periodos de retención son cortos o los EDR están configurados con exclusiones amplias, esos eventos pasan desapercibidos. El resultado es una brecha que puede permanecer oculta semanas antes de que se detecte una exfiltración.

Causa

  1. Visibilidad DNS incompleta – Muchos entornos registran solo consultas a servidores internos, omitiendo respuestas externas o CNAME. Sin esa capa, la correlación entre subdominios generados por DGA y la infraestructura del atacante se pierde.

  2. Exclusiones excesivas en EDR – Herramientas como Defender o CrowdStrike a menudo se configuran para excluir procesos de gestión (Orion, SolarWinds, etc.) bajo la premisa de “no interferir”. Esa exclusión elimina la captura de eventos de carga de DLL y de red asociados.

  3. Ventanas de look‑back limitadas – Los equipos de SOC suelen buscar eventos en los últimos 24‑48 h. Un ataque de supply‑chain puede iniciar con una fase de “dormir” que dura varios días, por lo que los indicadores tempranos quedan fuera del rango de búsqueda.

  4. Ausencia de una línea base de comportamiento – Sin un perfil de tráfico DNS y de carga de módulos por host, cualquier desviación parece ruido. Los picos de consultas a dominios raros o la aparición de binarios firmados pero inusuales no generan alertas.

  5. Falta de detección de binarios firmados usados como resolvers DNS – Los atacantes pueden empaquetar resolvers DNS dentro de ejecutables firmados y lanzar consultas desde procesos legítimos. Los sistemas que solo bloquean binarios no firmados no detectan esta táctica.

Solución

Una estrategia de detección basada en correlación de eventos multi‑vector permite cubrir los huecos anteriores sin depender de firmas estáticas.

1. Normalizar y enriquecer logs DNS

  • Habilitar registro de respuestas completas (incluyendo CNAME) en los resolvers internos y exportarlas a Splunk/Elastic.
  • Añadir campos de entropía (por ejemplo, Shannon) a cada subdominio para identificar patrones DGA.
  • Crear una tabla de “dominios de confianza” y marcar cualquier consulta fuera de esa lista.

2. Correlacionar Sysmon 7 y 22 con eventos DNS

  • Un EventID 7 (creación de archivo) que coincide en tiempo con un EventID 22 (carga de DLL) y una consulta DNS de alta entropía sugiere beacon.
  • Utilizar la columna ProcessGuid como llave de unión entre los dos eventos y la tabla DNS.

3. Detectar patrones de Cobalt Strike en procesos de gestión

  • Buscar secuencias de llamadas a LoadLibrary con rutas que incluyan Orion o SolarWinds pero que carguen módulos fuera del directorio de instalación.
  • Aplicar firmas de “beacon” basadas en la longitud y frecuencia de los paquetes UDP/TCP hacia puertos comunes de C2 (443, 8443, 50050).

4. Monitorear Azure AD para abuso de SAML

  • Extraer eventos de SignInLogs y AuditLogs que contengan tokenType=SAMl2.
  • Correlacionar con cambios de rol o asignaciones de aplicaciones que no tengan precedentes en la última semana.
  • Generar alertas cuando un token SAML se usa desde una IP que nunca ha interactuado con Azure AD.

5. Implementar detección de binarios firmados como resolvers DNS

  • Crear una regla que inspeccione cualquier proceso con firma válida que realice llamadas a dnsapi.dll o a nslookup.exe.
  • Si el proceso no pertenece a la lista de aplicaciones de red aprobadas, elevar a alerta.

6. Ajustar ventanas de look‑back y retención

  • Configurar Splunk para retener al menos 30 días de eventos DNS y Sysmon.
  • Programar búsquedas programadas que revisen los últimos 7 días en busca de coincidencias de entropía y carga de DLL.

7. Generar una línea base automática

  • Ejecutar un script de recopilación de métricas de tráfico DNS y carga de módulos durante una semana “limpia”.
  • Almacenar los percentiles 95 y 99 como umbrales para futuras comparaciones.

Cuándo aplicar esta solución

  • Síntomas: aumento inesperado de consultas DNS a dominios no vistos, procesos de gestión que cargan DLLs fuera de su directorio, tokens SAML que aparecen en logs de Azure AD sin correlación de MFA.
  • Entornos: cualquier infraestructura que use SolarWinds, Orion, o herramientas de gestión similares; despliegues híbridos con Azure AD; organizaciones con Splunk, Elastic o una solución SIEM que acepte datos de Sysmon.
  • Exclusiones: si la arquitectura no incluye DNS interno o no se dispone de logs de Sysmon, la correlación completa no será posible; en esos casos, priorice la captura de DNS completo y la habilitación de Sysmon antes de aplicar la regla completa.

Código

# Exportar eventos DNS y Sysmon a Splunk usando la CLI de Splunk
splunk search "index=dns sourcetype=dnstap | eval entropy=shannon(subdomain) | where entropy>4.5" -output csv > /tmp/high_entropy_dns.csv

splunk search "index=sysmon sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational (EventID=7 OR EventID=22)" -output csv > /tmp/sysmon_dll_events.csv

# Unir ambos CSVs por timestamp (aprox. +/- 5s) usando awk
awk -F, 'NR==FNR{a[$1]=$0;next} {for (t in a) if ($1>=t-5 && $1<=t+5) print a[t]","$0}' /tmp/high_entropy_dns.csv /tmp/sysmon_dll_events.csv > /tmp/correlated_events.csv

Verificación

  1. Ejecutar la consulta de correlación en Splunk y revisar que el número de filas sea razonable (no cientos de miles).
  2. Confirmar que al menos un evento muestra una combinación de alta entropía DNS + carga de DLL fuera del directorio de instalación.
  3. Simular un beacon usando nslookup desde un proceso firmado y verificar que la regla de binario firmado como resolver dispara una alerta.
  4. En Azure AD, generar un token SAML de prueba desde una IP externa y comprobar que la alerta se genera según la regla de abuso de SAML.

Notas adicionales

  • Las métricas de entropía pueden variar según el idioma del dominio; ajusta el umbral (entropy>4.5) después de observar la línea base.
  • Evita excluir procesos de gestión en EDR sin una revisión exhaustiva; una exclusión demasiado amplia es la causa más frecuente de falsos negativos.
  • Cuando se implementen reglas de correlación, revisa el rendimiento de la búsqueda; usar campos indexados (ProcessGuid, src_ip) reduce la carga.
  • Mantén una lista de “dominios de confianza” actualizada; los proveedores de infraestructura a menudo cambian sus FQDN y pueden generar falsos positivos si no se actualiza.