BYOEDR: así convirtió Akamai SentinelOne en un caballo de Troya en DEF CON 34

1. Volcado de memoria de un proceso protegido por PPL

Un administrador local utiliza el método Dump del objeto COM SentinelHelper.1 para volcar la memoria de cualquier proceso con Protección de Procesos Ligera (PPL). La interfaz SentinelHelper.1 es una herramienta administrativa legítima, pero estaba expuesta sin un control de acceso adecuado. Esto permite a un atacante con privilegios de administrador local burlar por completo las protecciones PPL, pudiendo leer el contenido de la memoria de procesos como Windows Defender .

2. Inyección de código no firmado en el proceso elevado

Tras volcar la memoria del proceso protegido por PPL, el atacante inyecta código no firmado en ese proceso elevado. El punto crítico es que esta inyección de código se origina desde un componente firmado por SentinelOne; el sistema operativo confía en el código firmado por SentinelOne. El código no firmado inyectado, que viaja dentro de un portador de confianza, sortea las comprobaciones de integridad de código de Windows .

3. Blindaje del malware frente a la detección y eliminación

Por último, el atacante aprovecha los mismos procesos e interfaces de confianza de SentinelOne para impedir que el propio EDR detecte o elimine el malware inyectado. Dado que el malware se ejecuta dentro —o junto a— los procesos de confianza de SentinelOne, los mecanismos anti-manipulación y de autoprotección del EDR protegen al malware de sí mismo, impidiendo su detección y eliminación .

El atacante también puede instalar un agente falso de SentinelOne sin necesidad de una licencia válida y bloquear la telemetría de gestión mediante manipulación local del DNS, aislando así el sistema comprometido de la consola central de administración .

¿Qué vulnerabilidad explota?

El problema raíz reside en que SentinelOne expuso potentes interfaces COM —en concreto SentinelHelper.1— a los administradores locales sin un control de acceso adecuado. Además, sus binarios de instalación firmados podían ser reutilizados para realizar acciones privilegiadas que los binarios no firmados no pueden realizar .

Hasta la fecha de la divulgación, no se ha reportado de forma pública un identificador CVE para este fallo concreto .

Es importante señalar que el ataque requiere privilegios de administrador local en la máquina objetivo. No es una vulnerabilidad de ejecución remota de código. Sin embargo, una vez que un atacante consigue acceso de administrador local mediante un compromiso inicial independiente (como explotar una aplicación vulnerable o usar credenciales robadas), BYOEDR le permite eludir las protecciones PPL que deberían contener ese tipo de compromiso .

El parche: SentinelOne Agent 26.1.1

SentinelOne corrigió el problema reportado en la versión 26.1.1 de su agente. La corrección consiste en endurecer las interfaces COM expuestas y restringir el uso de los binarios de instalación y los componentes de confianza . Las organizaciones deben asegurarse de que todos los agentes de SentinelOne estén actualizados a la versión 26.1.1 o posterior de inmediato .

Implicaciones más amplias para el software de seguridad de confianza

La técnica BYOEDR pone de manifiesto un problema de confianza fundamental: el software de seguridad recibe privilegios elevados y un acceso profundo al sistema por diseño. Cuando esas capacidades quedan expuestas a través de interfaces accesibles o binarios firmados, los atacantes pueden reutilizarlos como herramientas ofensivas .

• PPL no es una defensa absoluta. Las protecciones PPL pueden ser sorteadas si un componente firmado por PPL (como un EDR) expone una primitiva de volcado de memoria o de inyección de código a los usuarios locales .
• Los binarios firmados son un arma de doble filo. La firma de código garantiza el origen, no la seguridad. Los atacantes pueden aprovecharse de los productos de seguridad que 'viven de la tierra' (LOLSPs, por sus siglas en inglés) de forma similar a cómo abusan de los binarios fiables del sistema operativo .
• La responsabilidad del proveedor es primordial. Los proveedores de seguridad deben auditar sus propias interfaces COM, los controles de acceso de sus controladores y la lógica de validación de sus instaladores con el mismo rigor que aplican para encontrar fallos en software de terceros .

Pasos de mitigación para las organizaciones

Para defenderse de los ataques BYOEDR, las organizaciones deberían tomar las siguientes medidas:

1. Actualizar de inmediato — Asegurarse de que todos los agentes de SentinelOne estén actualizados a la versión 26.1.1 o posterior .
2. Endurecer el acceso de administrador local — Dado que el ataque requiere privilegios de administrador local, hay que limitar y controlar estrictamente las cuentas administrativas. Implementar acceso de administrador just-in-time (JIT) y monitorizar cualquier elevación de privilegios inusual .
3. Monitorizar el abuso de COM — Implementar reglas de detección para el uso sospechoso de las interfaces COM de SentinelOne (por ejemplo, SentinelHelper.1 o llamadas inesperadas a métodos Dump) por parte de procesos que no sean de SentinelOne .
4. Aplicar el principio de mínimo privilegio de forma general — Tratar a todos los agentes de seguridad como posibles superficies de ataque. Restringir los inicios de sesión interactivos, aplicar control de aplicaciones (por ejemplo, WDAC o AppLocker) y segmentar los flujos de trabajo administrativos .
5. Revisar las prácticas de hardening de los proveedores — Al evaluar productos EDR/XDR, preguntar a los proveedores cómo protegen sus propias interfaces privilegiadas frente al abuso local, no solo frente a exploits remotos .

Una familia creciente de ataques de abuso de confianza

BYOEDR no es un caso aislado. Una técnica similar llamada 'Bring Your Own Installer' (BYOI), descubierta por Stroz Friedberg (de Aon) en 2025, explota el proceso de actualización/desactualización de SentinelOne para desactivar las protecciones anti-manipulación, dejando los endpoints sin protección para la ejecución de malware . Se ha observado que BYOI se utiliza en ataques reales para desplegar el ransomware Babuk .

La combinación de BYOEDR y BYOI demuestra que los atacantes están apuntando cada vez más a la confianza depositada en el propio software de seguridad, y no solo a las vulnerabilidades de las aplicaciones que este protege.