Cómo funciona un EDR por dentro:

telemetría, ganchos y por qué a veces falla

Serie Blue Team  |  unfantasmaenelsistema.com

El EDR es la pieza de seguridad que más aparece en las conversaciones de un SOC y la que peor se entiende. Para mucha gente es una caja negra que «detecta cosas malas»: un agente que se instala, una consola en la nube y unas alertas que aparecen sin que quede claro de dónde salen. Esa opacidad es un problema práctico, porque un analista que no sabe qué ve su EDR tampoco sabe qué no ve, y por tanto no puede decidir qué otra telemetría necesita ni por qué una técnica concreta pasó desapercibida.

Este artículo abre la caja. No hay técnicas de evasión ni payloads: el objetivo es entender la arquitectura —de dónde saca los datos, cómo los procesa, cómo decide y por qué esa cadena tiene puntos ciegos— para poder evaluar un EDR con criterio y complementarlo donde haga falta.

1. EDR, antivirus y XDR: qué significa cada sigla

Un antivirus clásico (hoy se le llama EPP, Endpoint Protection Platform) tiene un objetivo concreto: impedir que un fichero malicioso conocido se ejecute. Trabaja sobre todo en el momento del acceso al fichero, compara con firmas y heurísticas, y su unidad de análisis es el binario.

Un EDR (Endpoint Detection and Response) añade una capa distinta: registra de forma continua lo que pasa en el endpoint —procesos que arrancan, conexiones de red, cambios en el registro, cargas de DLL, accesos a credenciales— y evalúa secuencias de comportamiento, no ficheros aislados. Su valor no está solo en bloquear, sino en dejar un rastro que permite investigar qué pasó, contener el equipo en remoto y responder. La «R» de response incluye aislar el host de la red, matar un proceso o recoger un artefacto para el analista.

XDR (Extended Detection and Response) es la correlación de esa telemetría de endpoint con la de otras fuentes —correo, identidad, red, cargas cloud— en un mismo motor. En la práctica la frontera entre un XDR y un buen SIEM con contenido de detección se difumina; lo relevante es que el endpoint sigue siendo la fuente más rica y la que este artículo desglosa.

2. De dónde saca los datos en Windows

Un EDR moderno en Windows no se apoya en una sola fuente, sino que combina varias porque cada una tiene un ángulo muerto que otra cubre. Estas son las principales.

2.1 ETW (Event Tracing for Windows)

Es el sistema de trazas del propio Windows. Cientos de componentes del sistema operativo publican eventos a través de proveedores ETW: creación de procesos, actividad de red, DNS, PowerShell (incluido el ScriptBlock logging), WMI, RPC, y —muy importante— Microsoft-Windows-Threat-Intelligence, un proveedor solo accesible desde código firmado con permisos especiales que expone llamadas sensibles del kernel (asignación de memoria ejecutable remota, manipulación de handles de procesos). Buena parte de la detección de inyección y de manipulación de memoria de un EDR sale de ahí.

2.2 Callbacks del kernel

Windows ofrece a los controladores un mecanismo oficial para «suscribirse» a eventos del sistema: `PsSetCreateProcessNotifyRoutineEx` avisa cuando arranca o termina un proceso, `PsSetCreateThreadNotifyRoutine` cuando se crea un hilo, `PsSetLoadImageNotifyRoutine` cuando se carga una imagen (EXE o DLL), y `ObRegisterCallbacks` permite filtrar los intentos de abrir un handle a otro proceso —así se detecta y a veces se frena el volcado de LSASS—. El componente del EDR que corre en modo kernel vive de estos callbacks.

2.3 Minifiltros de sistema de ficheros y filtros de red

Un minifilter se inserta en la pila de entrada/salida del sistema de ficheros y ve cada operación de lectura, escritura, creación y borrado: es como el EDR detecta cifrado masivo de ransomware o la escritura de un ejecutable en una carpeta sospechosa. En red, la Windows Filtering Platform (WFP) permite inspeccionar y bloquear conexiones a nivel de kernel, que es lo que sostiene el aislamiento de host.

2.4 AMSI y ELAM

AMSI (Antimalware Scan Interface) deja que PowerShell, el motor de scripts, Office y otras aplicaciones entreguen al motor antimalware el contenido ya desofuscado justo antes de ejecutarlo. ELAM (Early Launch Anti-Malware) permite que el controlador del EDR se cargue antes que el resto de controladores de terceros durante el arranque, para vigilar desde el minuto cero y dificultar que algo se cargue antes que él.

3. De dónde saca los datos en Linux

En Linux el reparto es distinto pero la idea es la misma: varias fuentes complementarias, unas en el kernel y otras en espacio de usuario.

• eBPF. Programas verificados que se cargan en el kernel y se enganchan a tracepoints, kprobes y LSM hooks para observar `execve`, conexiones, apertura de ficheros o llamadas concretas con muy poco coste. Es la base de la telemetría de los EDR y de herramientas abiertas como Falco o Tetragon
• auditd y el subsistema de auditoría del kernel: reglas sobre syscalls y accesos a rutas, con la ventaja de ser estándar y la desventaja de un formato pesado y difícil de correlacionar
• fanotify para vigilancia de acceso a ficheros (permite además bloquear el acceso hasta que el agente decide), y netlink para eventos de proceso
• Módulos de kernel propios, cada vez menos habituales: dan control total pero rompen con cada cambio de versión del kernel y son un riesgo de estabilidad

4. El recorrido del dato: agente, nube, detección, respuesta

Todas esas fuentes alimentan un agente local que hace la primera criba. El agente normaliza los eventos, los enriquece (árbol de procesos, usuario, hashes, firma del binario), aplica un primer juego de reglas en el propio endpoint —para poder bloquear en milisegundos sin depender de la red— y envía un resumen a la plataforma.

En la plataforma (normalmente en la nube del fabricante) ocurre lo que el endpoint no puede: correlación entre equipos, retención del histórico para búsqueda retrospectiva, aplicación de inteligencia de amenazas actualizada cada pocas horas y modelos más costosos. Cuando algo encaja con una detección, se genera una alerta con su contexto y, según la política, se dispara una respuesta automática o se deja en manos del analista: aislar el host, terminar el proceso, poner un fichero en cuarentena o lanzar la recogida de un paquete forense.

5. Cómo decide: firma, comportamiento y modelo estadístico

Un EDR no usa un único método de detección, sino una pila de ellos que se solapan:

La detección por comportamiento suele expresarse en términos de MITRE ATT&CK: la regla no dice «esto es el grupo X», dice «esto parece la técnica T1055 (inyección) precedida de T1003 (acceso a credenciales)». Por eso la cobertura de un EDR se mide por técnicas cubiertas, no por familias de malware.

6. Por qué un EDR falla a veces

Ningún EDR ve el 100 % de lo que pasa, y entender por qué —a alto nivel, sin entrar en cómo se explota— es lo que permite tapar los huecos con otra telemetría o con controles preventivos.

• Telemetría que no llega. Si la fuente correcta no está activada, no está soportada en esa versión del sistema, o el evento se pierde por saturación del búfer, la detección que dependía de ese dato simplemente no se dispara
• Reglas que no cubren la técnica. Una variación en el proceso que se usa, en el orden de los pasos o en el mecanismo concreto puede quedar fuera de la secuencia que la regla describe. El catálogo de detecciones siempre va por detrás de las técnicas
• Ruido que entierra la señal. En un entorno con miles de endpoints y herramientas de administración que hacen cosas parecidas a un ataque (PsExec, scripts, acceso remoto), una alerta real puede quedar sepultada entre falsos positivos mal ajustados
• Superficie fuera del endpoint. Un abuso que ocurre en la identidad cloud, en un dispositivo sin agente (un firewall, una impresora, un IoT) o en un servicio SaaS no lo ve un EDR de endpoint por definición
• El propio agente como objetivo. El componente del EDR es software y tiene su propia superficie: problemas de rendimiento que llevan a excluir carpetas enteras, dependencias de servicios que se pueden degradar, o versiones sin parchear. La configuración importa tanto como el producto

7. Cómo un equipo azul evalúa su EDR

Evaluar un EDR no es fiarse de la hoja de producto ni de una demo, sino medir cobertura de forma reproducible sobre el propio parque. Las vías habituales:

• Pruebas atómicas. Proyectos como Atomic Red Team publican acciones pequeñas y acotadas, una por técnica de ATT&CK, pensadas para lanzarse en un equipo de laboratorio y comprobar si generan telemetría, si generan alerta y con qué calidad. Se ejecutan de forma controlada y con registro de lo que se lanza y cuándo
• MITRE ATT&CK Evaluations (antes Engenuity): emulaciones públicas de adversarios reales sobre varios productos, con resultados abiertos. No dan un «ganador», pero muestran qué pasos detecta cada uno y a qué nivel (telemetría, alerta táctica, alerta técnica)
• Emulación de adversario con marcos como CALDERA o planes de emulación de MITRE, para cadenas completas en lugar de acciones sueltas, siempre en un entorno aislado y con autorización
• Mapa de cobertura sobre ATT&CK. Volcar qué técnicas se detectan, con qué fuente y con qué confianza en la matriz (herramienta: ATT&CK Navigator), y usar los huecos para priorizar nueva telemetría o nuevas reglas
• Métricas de operación. Tiempo hasta la detección, tasa de falsos positivos por regla, porcentaje de endpoints con el agente sano y reportando. Un EDR excelente mal desplegado rinde peor que uno modesto bien mantenido

# WINDOWS - comprobaciones de LECTURA sobre el estado de la telemetria (no es un ataque)
 
# Proveedores ETW disponibles y sesiones de traza activas
logman query providers | findstr /i "Threat-Intelligence Kernel-Process DNS PowerShell"
logman query -ets
 
# Estado del motor antimalware y de las protecciones
Get-MpComputerStatus | Select-Object AMRunningMode, RealTimeProtectionEnabled, BehaviorMonitorEnabled, IsTamperProtected
 
# Controladores de filtro cargados (minifilters de EDR/AV)
fltmc filters
 
# LINUX - ver los programas eBPF y las reglas de auditoria cargadas
sudo bpftool prog show
sudo auditctl -l

Conclusión

Un EDR es, por dentro, un sistema de recogida de telemetría del sistema operativo —ETW, callbacks de kernel, minifiltros y AMSI en Windows; eBPF, auditd y fanotify en Linux— conectado a un motor de detección que combina firmas, reglas de comportamiento y modelos, con una capa de respuesta remota encima. Cada fuente tiene un ángulo muerto y cada método de detección un límite conocido.

Verlo así cambia la conversación: en vez de tratar el EDR como un oráculo que acierta o falla, un equipo azul mide qué técnicas cubre su despliegue concreto, sobre su parque concreto, y dedica el esfuerzo a los huecos —más telemetría, endurecimiento preventivo, cobertura de red e identidad—. La caja negra deja de serlo en cuanto sabes qué cables entran y qué cables salen.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)