Telemetría EDR: Qué Datos Recopila y Cómo los Usa para Detectar

Por qué la telemetría importa más que las alertas

Cuando un EDR genera una alerta, esa alerta es una interpretación de la telemetría. Pero la telemetría raw, los datos crudos que el agente recopila del endpoint, es lo que realmente importa para la investigación y el threat hunting.

Un EDR con buena detección pero poca telemetría te dirá que algo malo pasó. Un EDR con telemetría rica te permitirá entender exactamente qué pasó, cómo pasó, y qué más hizo el atacante antes y después de la detección. La diferencia entre investigar un incidente en 2 horas y en 2 días a menudo depende de la telemetría disponible.

Los seis pilares de la telemetría EDR

1. Telemetría de procesos

La telemetría de procesos es el pilar fundamental de cualquier EDR. Cada vez que se crea un proceso en el sistema, el agente EDR registra un conjunto de datos que permite reconstruir qué se ejecutó y en qué contexto.

Datos capturados en la creación de proceso:

• PID y PPID. Identificador del proceso y de su proceso padre. Permite reconstruir árboles de procesos. Si explorer.exe (PID 1234) lanza cmd.exe (PID 5678), que a su vez lanza powershell.exe (PID 9012), el EDR captura toda la cadena.
• Nombre del ejecutable y ruta completa. C:\Windows\System32\cmd.exe vs C:\Users\Public\cmd.exe. La ruta es un indicador clave: un ejecutable legítimo en una ruta inusual es sospechoso.
• Línea de comando completa. El argumento más valioso para detección. powershell.exe -enc SQBFAFgAIAAoAE4A... revela una ejecución de PowerShell con comando codificado en Base64, técnica habitual de malware.
• Usuario y nivel de privilegio. Qué cuenta ejecutó el proceso. Un proceso ejecutado como SYSTEM desde un contexto de usuario normal indica una posible escalada de privilegios.
• Hash del ejecutable. MD5, SHA1 y SHA256 del binario. Permite verificar si el ejecutable coincide con malware conocido o si ha sido modificado respecto a la versión legítima.
• Integridad del proceso. Nivel de integridad del token (Low, Medium, High, System en Windows). Un proceso de integridad High lanzado desde uno Medium indica elevación de privilegios.
• Timestamp. Momento exacto de creación con precisión de milisegundos. Esencial para correlación temporal con otros eventos.

Por qué es fundamental para detección:

La mayoría de las técnicas ATT&CK de ejecución (T1059 Command and Scripting Interpreter, T1053 Scheduled Task, T1047 WMI) se detectan primariamente a través de telemetría de procesos. Un EDR que no capture la línea de comando completa pierde la capacidad de detectar una parte significativa de las técnicas de ataque modernas.

Ejemplo de detección:

Un documento Word malicioso (T1566.001 Spearphishing Attachment) ejecuta una macro que lanza PowerShell:

winword.exe → cmd.exe /c powershell.exe -nop -w hidden -enc [base64]

El EDR detecta la cadena: proceso de Office lanzando un intérprete de comandos que ejecuta PowerShell con flag de ejecución oculta y payload codificado. Tres indicadores de comportamiento malicioso en una sola cadena de procesos.

2. Telemetría de archivos

La telemetría de archivos registra operaciones de creación, modificación, renombrado y eliminación de archivos en el sistema.

Datos capturados:

• Operación. Crear, escribir, renombrar, eliminar.
• Ruta completa del archivo. Incluyendo el directorio. Escritura en C:\Windows\System32\ desde un proceso no privilegiado es sospechosa.
• Hash del archivo. Calculado tras la escritura. Permite identificar archivos maliciosos conocidos.
• Tamaño. Un ejecutable de 50KB en %TEMP% recién descargado y ejecutado es un patrón clásico de dropper.
• Proceso responsable. Qué proceso creó o modificó el archivo. PowerShell escribiendo un ejecutable en disco es un indicador fuerte.
• Timestamps. Creación, modificación, acceso. Timestomping (T1070.006) altera estos valores para dificultar el análisis forense.

Eventos clave para detección:

Escritura de ejecutables. Cualquier proceso que escriba un archivo .exe, .dll, .sys, .scr en directorios inusuales. Los droppers típicamente escriben el payload en %TEMP%, %APPDATA% o C:\ProgramData.

Modificación de archivos de sistema. Cambios en archivos de configuración del sistema, DLLs de sistema, o archivos en directorios protegidos. Puede indicar DLL side-loading (T1574.002) o hijacking.

Creación de scripts. Archivos .ps1, .bat, .vbs, .js creados por procesos que normalmente no generan scripts. Un proceso svchost.exe creando un archivo .ps1 es altamente sospechoso.

Ransomware. La telemetría de archivos es crítica para detectar ransomware. El patrón es inconfundible: un proceso que lee, cifra y reescribe miles de archivos en secuencia rápida, frecuentemente renombrándolos con una extensión nueva (.encrypted, .locked, .lockbit).

3. Telemetría de registro (Windows)

El registro de Windows es el mecanismo principal de configuración del sistema operativo, y también el mecanismo de persistencia favorito del malware.

Datos capturados:

• Operación. Crear clave, establecer valor, eliminar clave/valor.
• Ruta del registro. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run es la clave de autorun más clásica.
• Nombre y valor. Qué se escribió. Un valor que apunta a C:\Users\Public\malware.exe en una clave de autorun es un indicador directo de persistencia.
• Proceso responsable. Qué proceso realizó la modificación.
• Valor anterior. Algunos EDR registran el valor previo a la modificación, útil para detectar modificaciones en configuraciones de seguridad.

Claves de registro críticas para detección:

Las claves que un EDR debe monitorizar con prioridad alta incluyen las de autorun (Run, RunOnce en HKLM y HKCU), las de servicios (HKLM\SYSTEM\CurrentControlSet\Services), las de tareas programadas, las de Image File Execution Options (usadas para T1546.012 IFEO injection), y las de AppInit_DLLs.

Ejemplo de detección de persistencia:

Proceso: powershell.exe (PID 4532)
Operación: SetValue
Clave: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Nombre: "WindowsUpdate"
Valor: "C:\Users\john\AppData\Local\Temp\svchost.exe"

Un valor nuevo en autorun que apunta a un ejecutable en directorio temporal, con un nombre que imita un proceso legítimo de Windows. Clásico de malware.

4. Telemetría de red

La telemetría de red del agente EDR captura las conexiones de red que originan o reciben los procesos del endpoint.

Datos capturados:

• Proceso. Qué proceso inició la conexión.
• IP destino y puerto. A dónde se conecta. Conexiones a IPs en países inusuales o a puertos no estándar son indicadores de C2.
• Protocolo. TCP, UDP, DNS, HTTP/HTTPS.
• Dirección. Entrante o saliente.
• Volumen de datos. Bytes enviados y recibidos. Exfiltración de datos genera patrones de volumen anómalos.
• Nombre de dominio. Resuelto por DNS antes de la conexión.

Patrones de detección:

Beaconing. Comunicaciones periódicas a un servidor C2. Un proceso que contacta la misma IP cada 60 segundos (con jitter) durante horas es un patrón de beacon. Los EDR avanzados aplican análisis estadístico para detectar beaconing con intervalos variables.

Conexiones directas a IP. La mayoría del tráfico legítimo se dirige a dominios, no a IPs directamente. Un proceso que se conecta directamente a una IP por un puerto no estándar merece investigación.

DNS tunneling. Queries DNS inusualmente largas o frecuentes a subdominios de un dominio específico pueden indicar exfiltración de datos por DNS (T1071.004).

Limitación importante: La telemetría de red del agente EDR es por proceso, pero no inspecciona el contenido del tráfico cifrado (TLS). Para inspección de contenido se necesita un NTA/NDR complementario o TLS inspection en el proxy/firewall.

5. Carga de módulos (DLLs y librerías)

La telemetría de módulos registra qué librerías dinámicas (DLLs en Windows, shared objects en Linux) carga cada proceso.

Datos capturados:

• Nombre y ruta de la DLL.
• Hash de la DLL.
• Proceso que carga la DLL.
• Tipo de carga. Estática (en import table) o dinámica (LoadLibrary).
• Firma digital. Si la DLL está firmada y por quién.

Por qué importa:

Múltiples técnicas de ataque explotan la carga de DLLs:

DLL Side-Loading (T1574.002). Un ejecutable legítimo firmado carga una DLL maliciosa del mismo directorio en lugar de la DLL legítima del sistema. El EDR detecta que el hash de la DLL cargada no coincide con la versión conocida.

DLL Injection (T1055.001). Un proceso inyecta una DLL en el espacio de memoria de otro proceso. El EDR detecta la carga de una DLL no esperada en un proceso que normalmente no la utiliza.

Reflective DLL Loading. Carga de DLL directamente en memoria sin tocar disco. Algunos EDR detectan esto monitorizando llamadas a API de bajo nivel como VirtualAllocEx + WriteProcessMemory.

Ejemplo práctico:

El proceso Teams.exe carga version.dll desde su directorio de instalación en lugar de C:\Windows\System32\. La DLL no está firmada por Microsoft. Esto indica un posible DLL side-loading donde el atacante ha colocado una DLL maliciosa en el directorio de Teams para que se cargue automáticamente.

6. Telemetría DNS

Aunque los DNS queries son parte de la telemetría de red, merecen mención separada por su importancia en la detección de amenazas.

Datos capturados:

• Dominio consultado. El nombre de dominio completo (FQDN).
• Tipo de registro. A, AAAA, CNAME, TXT, MX.
• Proceso que originó la consulta.
• Respuesta. IP resuelta.
• Timestamp.

Patrones de detección vía DNS:

Dominios DGA (Domain Generation Algorithm). Familias de malware como Emotet, Qakbot o Necurs generan algorítmicamente cientos de dominios por día. Los EDR aplican modelos de machine learning o heurísticas (longitud, entropía, distribución de caracteres) para detectar queries a dominios DGA.

DNS over HTTPS (DoH) y DNS over TLS (DoT). Algunas variantes de malware usan DoH para evadir monitorización DNS. El EDR detecta conexiones HTTPS al puerto 443 de resolvers DoH conocidos (8.8.8.8, 1.1.1.1) desde procesos que normalmente no realizan resolución DNS propia.

Resolución de dominios C2 conocidos. Feeds de inteligencia de amenazas proporcionan listas de dominios C2 activos. El EDR compara cada query DNS contra estas listas en tiempo real.

Cómo funcionan los motores de detección

La telemetría por sí sola es solo datos. El motor de detección es lo que transforma esos datos en alertas accionables. Los EDR modernos combinan múltiples enfoques:

Reglas estáticas (IOC matching)

El enfoque más simple: comparar hashes de archivos, IPs de conexión y dominios DNS contra listas de indicadores de compromiso conocidos. Efectivo para malware conocido, inútil para malware nuevo o personalizado.

Reglas de comportamiento (Behavioral rules)

Reglas que detectan patrones de comportamiento independientemente del malware específico. Una regla como "proceso de Office lanza intérprete de scripts que ejecuta comando codificado" detecta cualquier documento malicioso que use esta técnica, no solo los que tienen un hash conocido.

Los EDR comerciales incluyen cientos o miles de estas reglas, frecuentemente mapeadas a técnicas MITRE ATT&CK. CrowdStrike usa Indicators of Attack (IOAs), SentinelOne usa STAR rules, Microsoft Defender usa Detection rules con KQL.

Machine Learning

Modelos entrenados con telemetría de millones de endpoints para identificar anomalías. Dos enfoques principales:

Clasificación de archivos. Modelos que analizan las características estáticas de un ejecutable (imports, secciones, entropía, strings) para clasificarlo como benigno o malicioso sin necesidad de firma.

Análisis de comportamiento. Modelos que analizan secuencias de eventos (proceso creado, archivo escrito, conexión de red establecida, registro modificado) para detectar patrones de ataque que las reglas individuales no capturan.

Correlación temporal

El motor de detección no evalúa eventos aislados: correlaciona secuencias temporales. Un proceso PowerShell ejecutándose es normal. Un proceso PowerShell lanzado desde Word, que descarga un archivo, lo ejecuta, y ese archivo establece una conexión a una IP externa, es un ataque. La correlación de estos eventos en una ventana temporal es lo que genera la detección.

Telemetría que los EDR no capturan (y deberían)

Memoria

La inspección de memoria en tiempo real es costosa en rendimiento. La mayoría de EDR solo inspeccionan la memoria de un proceso cuando hay un trigger (una detección previa o una solicitud de análisis). Esto deja un punto ciego: malware que opera exclusivamente en memoria (fileless malware) puede ejecutar payloads completos entre inspecciones.

Tráfico cifrado

El agente EDR ve que un proceso establece una conexión TLS, pero no puede inspeccionar el contenido sin realizar TLS interception, que requiere configuración adicional y puede afectar el rendimiento. Los metadatos de TLS (JA3 fingerprint, SNI, certificate) proporcionan algo de visibilidad, pero no contenido.

Actividad del kernel

Los EDR modernos operan principalmente en user-space con callbacks del kernel. La visibilidad de rootkits que operan a nivel de kernel depende de la profundidad de los hooks del agente en el kernel, que varía significativamente entre vendors.

Firmware y hardware

La telemetría EDR no cubre firmware (UEFI/BIOS) ni implantes de hardware. Ataques como LoJax (rootkit UEFI de APT28) operan por debajo del nivel de visibilidad del agente EDR.

La relación entre telemetría y MITRE ATT&CK

MITRE realiza evaluaciones periódicas de vendors EDR (ATT&CK Evaluations) que clasifican las capacidades de detección en categorías directamente relacionadas con la telemetría:

Telemetry. El EDR registró el evento (capturó la telemetría) pero no generó alerta. El dato está disponible para hunting manual.

General. El EDR detectó actividad sospechosa pero sin especificar la técnica ATT&CK exacta.

Tactic. El EDR identificó la táctica (Execution, Persistence, Lateral Movement) pero no la técnica específica.

Technique. El EDR identificó la técnica ATT&CK específica (T1059.001 PowerShell, T1547.001 Registry Run Keys).

La diferencia entre "Telemetry" y "Technique" es la calidad de la detección. Un EDR con alta telemetría pero baja detección requiere analistas expertos que hagan threat hunting sobre los datos raw. Un EDR con alta detección a nivel de técnica genera alertas accionables que analistas menos experimentados pueden investigar.

Recomendaciones prácticas

Para analistas SOC. Conoce exactamente qué telemetría genera tu EDR. Lee la documentación del vendor sobre los tipos de eventos que captura. Si tu EDR no captura líneas de comando completas, tienes un punto ciego crítico.

Para threat hunters. La telemetría raw es tu material de trabajo. Verifica el período de retención de telemetría de tu licencia. Si solo retiene 7 días, no podrás buscar actividad de APT con semanas o meses de persistencia.

Para CISOs evaluando EDR. No evalúes solo la tasa de detección. Pregunta por la telemetría: qué eventos captura, cuánto retiene, y si puedes exportarla. Un EDR que genera buenas alertas pero no permite acceder a la telemetría raw te limita cuando necesites investigar algo que no detectó automáticamente.

Para equipos de detection engineering. Mapea tu telemetría disponible contra la matriz ATT&CK. Identifica las técnicas que tu EDR debería detectar con la telemetría que tiene pero que aún no detecta. Esas son tus oportunidades para escribir reglas de detección personalizadas.