El punto ciego del EDR: 3 formas en que los ataques de navegador evaden la telemetría de endpoint
El EDR sigue siendo necesario cuando los atacantes ejecutan código en el host. El problema comienza si los equipos esperan que el EDR marque cada acción anómala, incluida la actividad SaaS basada en navegador que desde el endpoint puede parecer una sesión de usuario normal.
En entornos con alta dependencia de SaaS, un empleado puede autenticarse en una aplicación en la nube, aprobar una solicitud OAuth, abrir archivos sensibles o subir datos a través de una sesión de navegador. Es posible que la acción nunca cree un ejecutable nuevo controlado por el atacante ni un proceso que las defensas de endpoint clasificarían como malicioso.
Como en el incidente de Salesloft Drift de 2025: UNC6395 obtuvo tokens OAuth asociados con integraciones de Drift y los usó para realizar llamadas API de gran volumen contra los entornos Salesforce de los clientes. Así, el acceso SaaS autenticado permitió el robo de datos sin un proceso de malware que el EDR pudiera inspeccionar.
El navegador se ha convertido en la capa de acceso principal para aplicaciones SaaS corporativas, flujos de identidad, archivos y consolas de administración. El Browser Security Report 2026 de NordLayer encontró que el acceso por navegador está presente en el conjunto completo de 504 aplicaciones revisadas, y el 79% de las herramientas solo están disponibles a través del navegador.
Eso convierte las sesiones de navegador en una ubicación central para acciones de usuario que pueden no producir los artefactos de endpoint que el EDR fue diseñado para analizar.
El EDR todavía detecta ejecución en el host, malware, persistencia y comportamiento a nivel de proceso. Pero en entornos con alta dependencia de SaaS, algunos ataques se llevan a cabo a través de flujos de navegador e identidad que no crean los artefactos de endpoint que el EDR está diseñado para inspeccionar.
En ataques de phishing adversario-en-el-medio, extensiones de navegador maliciosas, cargas no autorizadas o señuelos de ejecución basados en portapapeles, la acción decisiva ocurre dentro del navegador o de la aplicación en la nube.
Phishing adversario-en-el-medio (AiTM)
En 2026, un actor de amenazas que Microsoft rastrea como Storm-2755 atacó a empleados canadienses mediante envenenamiento de motores de búsqueda y anuncios maliciosos. Las víctimas que buscaban términos como "Office 365" eran redirigidas a una página de inicio de sesión de Microsoft 365 controlada por el atacante.
La infraestructura AiTM luego actuaba como proxy del flujo de autenticación en tiempo real y capturaba credenciales, así como cookies de sesión y tokens de acceso OAuth emitidos tras una autenticación exitosa.
Storm-2755 luego reproducía la sesión robada. Microsoft observó que el mismo ID de sesión cambiaba del navegador de la víctima a un agente de usuario Axios, lo que mostraba que el token de autenticación se estaba reutilizando desde una infraestructura controlada por el atacante.
Los atacantes accedieron a servicios de Microsoft, buscaron información de nómina y recursos humanos, crearon reglas de bandeja de entrada para ocultar mensajes sobre cambios bancarios y, en algunos casos, accedieron a Workday.
La mecánica es típica del phishing AiTM. La víctima abre una página de phishing que se interpone entre el usuario y el proveedor de identidad real. La página recopila el nombre de usuario y la contraseña, retransmite el desafío MFA legítimo y pasa la respuesta del usuario al servicio real. El atacante puede entonces capturar el material de sesión autenticado.
Desde la telemetría ordinaria de procesos del endpoint, el flujo de autenticación puede parecer legítimo. El endpoint puede no revelar que un proxy AiTM ha interceptado la sesión (aunque otras señales de endpoint, identidad, red o XDR pueden exponer el ataque).
La mejor forma de prevenir muchos ataques AiTM es utilizar autenticación resistente al phishing FIDO2 WebAuthn: la respuesta de autenticación está criptográficamente vinculada al origen legítimo. Además, los controles del navegador pueden ayudar a bloquear destinos de phishing conocidos, restringir el acceso a aplicaciones web no aprobadas y detener el ataque antes.
Añadir controles a nivel de navegador con NordLayer Browser
NordLayer Browser brinda a TI control centralizado sobre áreas de un ataque que el EDR puede no ver con claridad: acceso web, extensiones de navegador, transferencias de archivos y acciones del portapapeles. La protección contra amenazas web puede bloquear destinos de phishing y maliciosos. Las políticas de extensiones pueden permitir o bloquear extensiones específicas de Chrome.
El tráfico del navegador también se puede enrutar a través de una IP dedicada, que las organizaciones pueden incluir en listas de permitidos para acceso SaaS o usar como condición de red en políticas de identidad donde el proveedor de identidad lo admita.
Extensiones de navegador comprometidas
Las extensiones de navegador crean un tipo diferente de problema de visibilidad. Dejan archivos en el perfil del navegador y su código se ejecuta dentro de los procesos del navegador. El EDR puede detectar una extensión sospechosa o actividad de red inusual. Pero el comportamiento de la extensión aún puede parecer ordinario a nivel del host.
Una extensión maliciosa puede usar API estándar del navegador para leer el contenido de la página, observar URL, interactuar con formularios y enviar datos por HTTPS. Ninguna de esas acciones requiere necesariamente un nuevo proceso o un ejecutable sospechoso. Sin contexto específico del navegador, un equipo de seguridad puede ver el tráfico del navegador pero no saber qué extensión lo inició, a qué datos accedió o si la extensión estaba aprobada.
Un ejemplo reciente: en marzo de 2026, Microsoft informó sobre extensiones maliciosas de Chromium que parecían asistentes de IA. Estas extensiones se instalaron aproximadamente 900.000 veces, con actividad confirmada en más de 20.000 inquilinos empresariales. Las extensiones recopilaban URL visitadas y contenido de conversaciones de ChatGPT y DeepSeek, y enviaban periódicamente estos datos a una infraestructura controlada por el atacante.
Por lo tanto, el host puede mostrar un proceso de navegador ordinario realizando conexiones HTTPS, mientras que la acción relevante para la seguridad es una extensión que lee y exporta contenido de la página. Las herramientas de endpoint pueden detectar partes de la actividad, pero el inventario de extensiones, los permisos y la política proporcionan el contexto necesario para determinar si ese comportamiento debería haberse permitido.
Los equipos de seguridad deben controlar la capa de extensiones directamente en lugar de esperar un dominio malicioso, una firma de malware conocida o una alerta de endpoint. Las organizaciones necesitan listas de extensiones permitidas, controles de instalación y revisiones de permisos para cualquier extensión que pueda leer o modificar contenido web.
Ataques de navegador antes de la ejecución en el endpoint
Algunos ataques de navegador se completan dentro de la sesión web. Un sitio web comprometido, un anuncio malicioso o un script inyectado pueden cambiar el contenido renderizado, leer datos accesibles de la página, redirigir la sesión o manipular el portapapeles. Estas acciones pueden ocurrir dentro de los permisos otorgados al navegador. No necesitan escribir archivos, lanzar malware ni crear un nuevo proceso. Un usuario también puede subir un archivo sensible o pegar texto confidencial en un servicio SaaS o de IA no autorizado sin que se instale ningún malware.
Aunque eso puede ser dañino, no necesariamente crea los artefactos que el EDR está diseñado para encontrar. Por ejemplo, los ataques ClickFix utilizan avisos de verificación falsos u otro contenido web para persuadir a la víctima de copiar y ejecutar un comando malicioso.
Microsoft observó esta secuencia en su campaña TerminalFix de agosto de 2026, una variante de ClickFix que comprometía sitios web y mostraba avisos falsos de CAPTCHA de Cloudflare. Al hacer clic en el paso de verificación falso se copiaba un comando malicioso de PowerShell al portapapeles, mientras la página indicaba a la víctima que abriera Windows Terminal o PowerShell y lo pegara.
Hasta entonces, el atacante había dependido del contenido del navegador, la manipulación del portapapeles y la interacción del usuario. La ejecución del comando cambiaba la telemetría: se ejecutaba PowerShell, se descargaba y extraía un archivo ZIP, seguía la carga lateral de DLL, se creaba persistencia en el registro y tareas programadas, comenzaba el descubrimiento de Active Directory y el host comprometido establecía un túnel inverso.
Los controles del navegador pueden detener el ataque antes de la ejecución en el host bloqueando la página maliciosa, restringiendo el acceso al portapapeles o limitando acciones riesgosas del navegador. Si el usuario ejecuta el comando copiado, la actividad pasa a la telemetría de endpoint, donde el EDR puede inspeccionar la ejecución de PowerShell, los archivos descargados, la persistencia, el descubrimiento y las conexiones salientes.
El control debe coincidir con la acción
El EDR por sí solo no cubre todas las acciones de alto riesgo en un entorno con alta dependencia de SaaS. Si los equipos esperan que la telemetría de endpoint marque cada inicio de sesión malicioso, aprobación de OAuth, carga desde el navegador o acción de extensión, pueden pasar por alto actividad que nunca se convierte en ejecución en el host.
Un entorno con alta dependencia de SaaS necesita controles en 3 capas conectadas:
- Navegador
- Identidad y SaaS
- Endpoint
Se necesitan controles del navegador antes de que los datos lleguen a un servicio SaaS o de IA no autorizado. Una vez que un usuario sube un archivo, pega texto confidencial u otorga acceso excesivo al navegador, la telemetría de endpoint puede no mostrar suficiente contexto para explicar o detener la acción. La protección contra amenazas web puede bloquear sitios de phishing y maliciosos. Las políticas de extensiones pueden evitar que código no aprobado lea contenido web. La DLP de navegador puede restringir cargas, descargas y acciones de copiar y pegar según el destino.
En entornos con alta dependencia de SaaS, el navegador es la capa de acceso principal para datos corporativos, proveedores de identidad y flujos de administración. Los controles deben operar en esa capa porque los inicios de sesión maliciosos, concesiones OAuth, acceso de extensiones, cargas y acciones del portapapeles pueden no crear artefactos de endpoint. El EDR sigue siendo necesario para la ejecución en el host. Pero cuando un ataque permanece dentro de una sesión de navegador, el navegador no es solo otra aplicación que monitorear, sino la superficie de ataque.
Para obtener datos sobre la exposición del navegador y la capacidad de las organizaciones para abordarla, lea el informe de amenazas basadas en web de NordLayer.
Explore NordLayer Browser en 30 minutos. Vea cómo su equipo puede implementar controles gestionados del navegador, identificar el uso de aplicaciones no aprobadas y aplicar políticas de acceso en todos los equipos. Reserve una demostración.
Sobre el autor:
Andrius tiene más de 20 años de experiencia en el campo de TI y ha estado muy interesado en la ciberseguridad desde 2015. Ahora lidera su equipo como vicepresidente de estrategia de producto en NordLayer, una plataforma de seguridad de red lista para usar para empresas.
Impulsa la agenda de desarrollo investigando extensamente el mercado, comprendiendo las necesidades de los clientes y evaluando capacidades técnicas. Andrius prioriza fomentar la confianza dentro del equipo de producto, empoderándolo para abordar desafíos de seguridad complejos y traducir descubrimientos en capas mejoradas de protección para los clientes.
Patrocinado y escrito por NordLayer Browser.
Deja una respuesta