En agosto, un investigador de Akamai enseñó en DEF CON 34 cómo coger un EDR comercial —de los grandes, de los que se compran para estar tranquilo— y convertirlo en el escondite del atacante. La parte que se llevó los titulares fue el volcado de memoria. La que debería quitarte el sueño es el final del informe: una línea de texto en un fichero deja al agente mostrando «SECURE» mientras tu consola deja de recibir absolutamente nada.
Lo que Akamai encontró
La investigación es de Shahak Morag, del equipo de seguridad de Akamai, se presentó en DEF CON 34 y se publicó en el blog de investigación de la compañía el 7 de agosto de 2026. El objeto de estudio fue el agente de SentinelOne, y el punto de partida son tres objetos COM que el producto expone en la máquina: SentinelHelper.1, SentinelUI.1 y SentinelAgent.1.
Dentro del primero hay un método con una firma muy poco tímida: Dump(uint processId, string userDumpPath, string kernelDumpPath). Le pasas un PID y te escribe el volcado de memoria de ese proceso donde le digas. El detalle importante: ese método corre como proceso protegido (PPL) pero solo comprueba que quien llama sea administrador local. No valida desde dónde se le está llamando. Resultado: cualquier administrador local puede volcar la memoria de cualquier proceso protegido de la máquina —incluido el propio Microsoft Defender— sin driver malicioso y sin ningún fallo del sistema operativo.
El motivo de que falte esa validación es lo más humano del informe. El resto de funciones sí comprueban que quien llama esté dentro del directorio de instalación del producto; esta no, y Akamai lo liga a un script de diagnóstico propio, DiagnosticsCollector.ps1, que se ejecuta bajo el intérprete de PowerShell y por tanto desde otro directorio. Una necesidad legítima de soporte que acabó dejando una puerta abierta. Casi todas empiezan así.
SentinelOne corrigió lo reportado en la versión 26.1.1 del agente. Si eso fuera todo, este post sería un aviso de parcheo de tres líneas y se acabaría aquí. No lo es.
La segunda mitad: instalar tu propio EDR y quitarle el micrófono
El instalador del agente valida el site token —la cadena que dice a qué inquilino pertenece esa máquina— con una función llamada VerifyRegistrationSecret. Los investigadores le pasaron un JSON codificado en Base64 con este contenido:
{
"url": "http://127.0.0.1:8888/",
"site_key": "abc123xyz"
}
La instalación se completó sin que hubiera ningún servidor escuchando en el 8888 y sin una clave de sitio válida. El agente resultante no funciona —no protege nada— pero se muestra en «SECURE». Un EDR de mentira, firmado, corriendo con privilegios de proceso protegido, y con la lucecita verde puesta.
Y el último paso, que es el que de verdad importa para quien opera un parque. Otro método COM, GetAgentStatusJSON, devuelve entre otras cosas el campo mgmt-url: la dirección de la consola a la que ese agente reporta. Con ese dato, el atacante escribe una línea en C:\Windows\System32\drivers\etc\hosts resolviendo esa dirección a 127.0.0.1. Akamai lo describe sin adornos: eso bloquea toda la telemetría sin afectar a la apariencia de que el agente está en estado protegido.
Hemos escrito aquí sobre atacantes que apagan el EDR reiniciando en modo seguro. Aquello, al menos, se nota: el agente deja de estar. Esto es lo contrario y es peor. El agente sigue ahí, firmado, en verde, ocupando su casilla en tu informe de cobertura. Simplemente ha dejado de hablar contigo.
Las dos señales no valen lo mismo
Aquí está, para nosotros, la lectura útil de todo esto, y va mucho más allá de un producto concreto. Cuando alguien nos enseña cómo controla la seguridad de su parque, casi siempre nos enseña señales de presencia: el agente está instalado, el proceso corre, el estado dice protegido, la cobertura sale entera en verde. Todas esas señales nacen en el endpoint. Y quien tiene administrador local en el endpoint las controla.
Hay una señal que no nace ahí: la ausencia. Que tu consola lleve tres días sin recibir un solo evento de una máquina concreta es un hecho que ocurre en tu consola, no en la máquina. El atacante puede falsificar lo que el agente dice de sí mismo; no puede fabricar tráfico que nunca llega. Es la única señal de toda esta cadena que sigue siendo tuya después de que te comprometan el endpoint.
Dicho de otra forma: «EDR desplegado en el 100 % del parque» describe un inventario, no un control de seguridad. Mide cuántos agentes se instalaron; no dice nada sobre cuántos siguen hablando contigo.
El umbral que configuraste es la ventana que concediste
Toda consola de EDR tiene, en alguna pestaña, un ajuste del tipo «avisar si un agente lleva N días sin reportar». Ese número no es un parámetro de higiene. Es un contrato: es exactamente el tiempo que has aceptado estar ciego sobre una máquina. Si tienes 7 días para portátiles, has firmado 7 días.
Y sabemos por qué está alto: por los falsos positivos. Un portátil de vacaciones y un portátil silenciado se ven exactamente igual en la consola, y nadie quiere una alerta cada agosto. Por eso la solución no es bajar el umbral global —eso solo produce fatiga de alertas—, sino separar el umbral por clase de activo:
- ✓Un servidor que se calla treinta minutos no es un servidor de vacaciones. Es un incidente, y el umbral debería medirse en minutos.
- ✓Un portátil callado que da otras señales de vida —su usuario abre el correo, entra por VPN, coge una IP en la oficina— es la combinación que de verdad importa. Silencio en el EDR más actividad en cualquier otro sistema es un incidente, y esa correlación no la hace ninguna consola sola.
- ✓Un portátil callado y sin ninguna otra señal en agosto probablemente esté en un cajón. Ese es el caso que justifica el umbral largo, y es el único.
Lo más barato de detectar está al final de la cadena
Merece la pena mirar esta cadena por su coste. Entender los objetos COM, los procesos protegidos y la firma de código es trabajo de investigador. Falsificar el site token requiere haber leído el instalador. Pero el paso que te deja ciego —el que convierte un compromiso en una semana de barra libre— es escribir una línea de texto en un fichero. Y ese fichero tiene un hash y una fecha de modificación.
Vigilar la integridad de hosts es un control que ya viene en cualquier EDR y en cualquier RMM decente, no cuesta licencia, apenas genera ruido —salvo en máquinas de desarrollo, donde entre clientes de VPN y entornos de contenedores sí se toca, ese fichero se queda quieto— y en los parques que revisamos casi nunca está activado. Con honestidad: no es una bala de plata. Quien tiene administrador puede desviar el tráfico por otros sitios (un servidor DNS local, una regla de firewall). Pero es el movimiento más barato para el atacante, y por eso es la detección más barata para ti. Empieza por ahí.
Lo que miramos nosotros
Cuando revisamos el EDR de un cliente, estas seis cosas salen antes que la marca del agente:
- 1Alerta por ausencia de telemetría, con umbral distinto por clase de activo. Si el número está en la configuración por defecto, ese es tu tiempo de ceguera aceptado.
- 2Reconciliación de inventarios. La lista de máquinas de la consola del EDR contra otra fuente independiente: el directorio, el gestor de dispositivos, el RMM, las concesiones de DHCP. Lo interesante nunca es la coincidencia; son las diferencias en los dos sentidos.
- 3Alerta cuando aparece un agente nuevo con un grupo o un token de sitio que no reconoces. Un alta de agente debería ser un acto administrativo con nombre y apellidos, no un evento rutinario que nadie lee.
- 4Integridad del fichero
hostsen servidores y en puestos. Barato, silencioso y directamente relacionado con lo que acabamos de contar. - 5Un suelo de versión del agente escrito como política, no como sensación. En este caso concreto, 26.1.1. «Está actualizado» no es una respuesta; «ninguna máquina por debajo de X, y estas tres lo están» sí lo es.
- 6Alguien que mire la consola. Una alerta de ausencia que salta un sábado a las tres de la madrugada y espera al lunes es, para el atacante, la misma alerta que no existe.
Los cinco primeros son configuración, no proyecto: el segundo lleva su trabajo en un parque grande, pero ninguno necesita que nadie apruebe un presupuesto. El sexto es el que separa un EDR comprado de un EDR/MDR gestionado, y es el que casi nunca está resuelto. La detección sin nadie detrás acaba siendo un registro histórico: sirve para reconstruir lo que pasó, no para evitarlo.
Lo que no vamos a decir
- ✗No vamos a decir que este producto sea malo ni que haya que cambiar de fabricante. Akamai eligió un agente grande porque es donde el hallazgo tiene valor, el fabricante lo corrigió, y el propio informe encuadra el problema como de diseño de la categoría: interfaces locales, lógica de instalador y autoprotección insuficientemente endurecidas. Ninguna de estas cadenas se detiene comprando otro agente.
- ✗No vamos a decir que esto sea un 0-day remoto. Hace falta administrador local, y eso es una barrera real que conviene decir en voz alta. Lo que describe Akamai ocurre después de que alguien haya entrado, y ahí es donde se decide si un incidente te cuesta una tarde o una semana.
- ✗No hemos reproducido esto en laboratorio. Lo que contamos es lo que publica Akamai, leído con el criterio de quien opera parques ajenos. Si algún día lo montamos, lo contaremos con nuestros propios números.
La pregunta que deja el informe
La primera mitad del hallazgo se cierra con un parche: actualizas a 26.1.1 y esa puerta concreta queda cerrada. La segunda no se cierra del todo con ninguna versión, porque describe lo que ocurre cuando cualquiera con administrador local puede instalar software de seguridad y decidir a qué consola habla. Eso no se parchea, se gobierna.
Así que la pregunta con la que nos quedamos no es «¿tienes EDR?». Es esta otra: si una de tus máquinas dejara de reportar ahora mismo, ¿cuánto tardaría alguien en enterarse, y ese alguien tiene nombre? Si la respuesta empieza por «bueno, supongo que saltaría algo», ya sabes por dónde empezar.
Fuentes (verificadas): «Bring Your Own EDR: How to Turn a Commercial EDR into a Trojan Horse», Shahak Morag, blog de investigación de seguridad de Akamai, 7 de agosto de 2026 — objetos COM SentinelHelper.1, SentinelUI.1 y SentinelAgent.1, firma del método Dump, el script DiagnosticsCollector.ps1, la validación de VerifyRegistrationSecret, el campo mgmt-url de GetAgentStatusJSON, la redirección por el fichero hosts y la corrección en la versión 26.1.1 del agente: akamai.com. Presentado en DEF CON 34 (Las Vegas, 6-9 de agosto de 2026, fechas según defcon.org). Los umbrales, la separación por clase de activo y el criterio de detección por ausencia son lectura nuestra, no del informe.
¿Sabrías decir cuántas de tus máquinas llevan una semana sin reportar?
En everyWAN operamos EDR/MDR gestionado y monitorización 24/7 para empresas que no tienen —ni quieren tener— a alguien mirando una consola de madrugada. Revisamos umbrales, reconciliamos inventarios y ponemos nombre al que responde.
Microsoft 365
ES 
CAT 
EN