Volver al glosario

EDR

8 min de lectura

El EDR, o endpoint detection and response, es un agente instalado en servidores y puestos de trabajo que registra lo que hacen los procesos, señala el comportamiento que encaja con técnicas conocidas de atacante y le da a quien responde la capacidad de investigar y de aislar la máquina. Primero graba y después bloquea, y eso es lo que lo separa de un antivirus.

24 de julio de 2026
Compartir:

Cómo funciona

Un agente de EDR se sitúa por debajo de las aplicaciones y mira al sistema operativo hacer su trabajo. Registra la creación de procesos con la línea de comandos completa y la cadena de padres, la carga de módulos, los cambios en ficheros y en el registro, las conexiones de red y el contenido de los scripts en el momento en que se entrega al intérprete. En Windows esa telemetría sale de las llamadas del núcleo, del sistema de trazas de eventos y de una interfaz que permite a los productos de seguridad ver el contenido de scripts y macros después de descodificarse y antes de ejecutarse.

Ese flujo va a dos sitios. Un motor local lo contrasta con reglas de comportamiento y puede actuar de inmediato, matando un proceso o bloqueando una escritura. Y una copia se envía a una consola donde se retiene, se correlaciona entre máquinas y se puede buscar. La retención es la parte que más importa durante un incidente: es lo que permite a quien responde preguntar qué estaba haciendo esta máquina cuarenta minutos antes de la alerta, que es una pregunta que ningún control preventivo sabe contestar.

La mitad de respuesta no es decorativa. El aislamiento de red que deja al agente conectado y corta todo lo demás, el acceso remoto a una máquina en la que ya no confías, y la capacidad de recuperar un fichero o matar un proceso en todo el parque, son lo que convierte una detección en una contención que se mide en minutos y no en días.

La lógica de detección es de comportamiento, no de firma. No busca un fichero conocido. Busca un proceso de ofimática que lanza un intérprete de comandos, un binario de servicio que escribe en un directorio de usuario, un proceso que lee la memoria de la autoridad de seguridad local, o una máquina que de repente se autentica contra otras cuarenta. Por eso caza cosas que nadie ha visto antes, y también por eso produce alertas que necesitan a una persona.

Qué sale mal

El fallo que más explotamos no es la evasión. Es la cobertura. Un parque compra licencias para su flota y despliega sobre la flota que conoce, y siempre queda un resto: el controlador de dominio que nadie quiso tocar, el dispositivo en el que el fabricante prohíbe agentes, el servidor de compilación, la máquina de salto, la imagen de escritorio virtual que se clonó antes de instalar el agente, las cargas de trabajo Linux que quedaron fuera del alcance del despliegue. En una prueba interna buscamos el hueco antes de buscar un bypass, porque el hueco es gratis y casi siempre está.

El segundo fallo es el modo de respuesta. Buena parte de los despliegues que nos encontramos funcionan en modo de solo detección, o en todas partes o en los servidores que importan, porque un falso positivo rompió algo una vez. Esa es una decisión defendible y tiene que ser una decisión explícita. En solo detección, el control no es el producto: es quien lea la alerta, y si la alerta cae en una cola que nadie mira fuera de horario, el tiempo medio de respuesta es lo que dure un fin de semana.

Luego está la evasión propiamente dicha, que es real y más estrecha de lo que sugieren tanto los fabricantes como los atacantes. Las técnicas que restauran la ruta original de las llamadas al sistema, las que se ejecutan enteras dentro de un proceso de confianza, o las que cargan un controlador firmado pero vulnerable para actuar desde el núcleo, existen todas y funcionan a veces. Lo que no hacen es volver invisible a un atacante: silencian un sensor mientras el resto de la telemetría sigue fluyendo. En nuestros proyectos, la lección útil para el cliente rara vez es «tu EDR se puede saltar». Es que nuestra actividad quedó grabada y nadie miró la grabación.

El tercer fallo es el más silencioso. Los atacantes que solo usan herramientas que ya están en la máquina, que es el living off the land, no disparan nada anómalo porque no se ejecutó nada anómalo. Distinguir a un administrador usando una herramienta de gestión remota de un intruso usando esa misma herramienta no es una pregunta de producto. Es una pregunta sobre si alguien sabe qué aspecto tiene lo normal en esa máquina.

EDR, XDR, MDR y SIEM

Estos cuatro se venden unos contra otros y no son el mismo tipo de cosa. Dos son categorías de producto, uno es un modelo de entrega y otro es una plataforma. Compararlos por funcionalidades se salta eso.

EDR XDR MDR SIEM
Qué es Un producto en los endpoints Un producto sobre endpoint, identidad, correo y cloud Un servicio: otro opera tus herramientas Una plataforma que ingiere registros de todo
De dónde vienen los datos De un agente De varios sensores propios, a veces de terceros De lo que el proveedor opere De cualquier cosa que sepa mandar un registro
Trabajo principal Detectar y responder en la máquina Correlacionar entre tipos de señal Vigilarlo las veinticuatro horas Agregar, correlacionar, retener, informar
Qué no hace Ver lo que no tiene agente Sustituir la retención de registros para auditoría Arreglar lo que encuentra Actuar por su cuenta
Se compra en lugar de Antivirus Varios productos sueltos Un equipo propio a turnos Nada: complementa

La lectura práctica: el MDR es ortogonal a los otros tres, porque se puede comprar encima de cualquiera de ellos. El XDR es EDR con más sensores de un solo fabricante, lo que compra correlación y cuesta portabilidad. Y el SIEM no sustituye al EDR: no tiene agente ni puede actuar sobre una máquina. Cuando una obligación normativa exige retener registros de todo el parque, lo que la satisface es el SIEM, y ningún producto de endpoint lo hace.

Errores frecuentes

Desplegarlo y dejar la política por defecto. Los valores por defecto están ajustados para no romper nada en ningún cliente. El ajuste fino, las exclusiones y la decisión de qué bloquea y qué solo avisa son el proyecto; la instalación no lo es.

Excluir directorios enteros para callar el ruido. Cada exclusión amplia es un sitio desde el que ejecutar. Las buscamos, y cuando se pueden leer desde una máquina a la que llegamos, son el camino más rápido.

Dar por hecha la cobertura total. Concilia la lista de agentes contra el directorio, el hipervisor y el inventario cloud todos los meses. El número no va a cuadrar, y la diferencia es el hallazgo de verdad.

Tomar el volumen de alertas como métrica. El número que importa es cuánto se tarda en que alguien toque una alerta grave a las tres de la mañana, y si esa persona tiene autoridad para aislar una máquina sin pedir un cambio.

Comprarlo para contentar a un auditor. Un auditor pregunta cuál es el control y cómo sabes que funciona. Un recuento de agentes no es evidencia de ninguna de las dos cosas.

Cómo detectar los huecos

Prueba la cobertura antes de probar las detecciones. Concilia los agentes contra todas las fuentes de verdad que tengas, y trata cualquier máquina que no pueda llevar agente como un riesgo aceptado con dueño con nombre y con un control compensatorio, no como una excepción en una hoja de cálculo.

Después prueba las detecciones a propósito en vez de esperar a que te ataquen. Ejecuta una técnica conocida de forma controlada, en una máquina que importe, y comprueba tres cosas por este orden: si la telemetría la registró, si saltó una regla y si alguien actuó. Casi todos los parques pasan la primera, unos cuantos pasan la segunda, y en la tercera está el hueco honesto. Ese ejercicio es un purple team en su forma más simple, y no necesita un presupuesto grande para merecer la pena.

Mapea lo que salta contra MITRE ATT&CK para que la respuesta a «a qué somos ciegos» sea una lista de identificadores de técnica y no una impresión. Y vigila que el agente no se calle: un sensor que deja de informar o es una máquina rota o es una máquina hostil, y las dos necesitan que alguien mire.

Dónde aparece esto en una auditoría

En un informe de red team o de interna, el EDR aparece dos veces. Una como cobertura, donde listamos las máquinas a las que llegamos que no tenían agente y desde dónde llegamos a ellas. Y otra como resultado, donde anotamos qué hicimos, a qué hora, y si se detectó, si generó alerta o si alguien actuó.

La evidencia que entregamos es una cronología: nuestra acción, la marca de tiempo y la entrada correspondiente en la consola del propio cliente si existe. Esa comparación es más útil que cualquier aprobado o suspenso, porque enseña con precisión dónde se paró la cadena. Hemos escrito informes en los que todos los pasos quedaron registrados correctamente y el hallazgo fue que nadie abrió la consola en nueve días.

La severidad se escribe contra la consecuencia, no contra el producto. «El EDR no nos bloqueó» no es un hallazgo por sí solo. «Una máquina privilegiada no tenía agente y fue nuestra ruta hasta el dominio» sí lo es.

Esto es una de las cosas que un ejercicio de emulación de adversarios mide de forma directa.

Preguntas frecuentes

¿El EDR es solo un antivirus mejor? No. Un antivirus decide si un fichero es malo y lo bloquea. El EDR registra comportamiento de forma continua, detecta patrones de actividad y no ficheros, retiene los datos para poder investigar, y le da a quien responde la capacidad de actuar sobre una máquina a distancia. Casi todos los productos de EDR incluyen la función de antivirus como una parte más.

¿Se puede saltar un EDR? Sí, y esa no es la pregunta útil. Se pueden silenciar sensores concretos y esquivar reglas concretas. La invisibilidad total en todas las fuentes de telemetría es mucho más difícil, y en la práctica a los atacantes se les encuentra por la actividad que quedó grabada y no por la alerta que saltó.

¿Seguimos necesitando un SIEM si tenemos EDR? Normalmente sí. El EDR ve las máquinas con agente. Los cortafuegos, los proveedores de identidad, las pasarelas de correo, los planos de control cloud y las aplicaciones no lo tienen, y las obligaciones de retención de registros los cubren a todos.

¿El EDR detiene el ransomware? Detiene automáticamente buena parte del ransomware de oportunidad. Hace mucho menos contra un operador que tiene credenciales válidas, que usa las herramientas de administración que ya vienen en el sistema y que desactiva o desinstala el agente desde una cuenta privilegiada antes de empezar a cifrar, que es la secuencia de la mayoría de los casos graves.

¿Quieres ver cómo trabajamos en Asperis Security?

Agenda 30 minutos con uno de nuestros especialistas. Revisamos tu stack y te decimos qué conviene probar primero.