Cómo las amenazas basadas en el navegador eluden la seguridad de red tradicional

Los registros de su cortafuegos están limpios, el agente de su terminal no muestra ninguna alerta y el servicio de reputación de URL ha dado luz verde al sitio web. Sin embargo, un atacante acaba de obtener las cookies de sesión de un responsable financiero para el sistema SaaS de nóminas de su empresa, ha accedido a su intranet y ha sustraído los datos de remuneración de todo un trimestre, todo ello a través de una pestaña del navegador que no ha activado ni una sola alerta. Las amenazas basadas en el navegador no son nuevas, pero la brecha entre su forma de actuar actual y lo que los controles tradicionales de perímetro y de terminales estaban diseñados para detectar nunca ha sido tan amplia.

Este artículo describe los mecanismos específicos que utilizan los atacantes para convertir el navegador en un arma, explica por qué los sistemas de defensa tradicionales no los detectan de forma sistemática y señala cuáles deben ser las prioridades actuales de los equipos de seguridad.

La anatomía de un ataque perpetrado a través del navegador que su pila de aplicaciones no detectó

Imagínese lo siguiente: un analista de compras de una empresa manufacturera busca un proveedor industrial especializado. Un resultado de búsqueda patrocinado —publicado a través de una red publicitaria importante y legítima— aparece en primer lugar. El dominio del anuncio supera el filtrado de URL; la reputación de la propia plataforma publicitaria es impecable. El analista hace clic. La página de destino identifica la versión del navegador, confirma que no se trata de un entorno aislado, carga una carga útil de JavaScript ofuscada tras tres capas de redireccionamiento y descarga un programa de robo de información que recopila todas las credenciales almacenadas en el gestor de contraseñas del navegador. El antivirus del terminal detecta un proceso de Chromium firmado que realiza lo que suelen hacer los navegadores —ejecutar JavaScript— y no toma ninguna medida.

MITRE ATT&CK documenta este patrón como T1189 (Drive-by Compromise): los atacantes obtienen acceso a un sistema a través de un usuario que visita un sitio web durante su navegación habitual. Entre los métodos de distribución se incluyen sitios web legítimos en los que se ha inyectado código malicioso, archivos de script servidos desde un almacenamiento en la nube comprometido y anuncios maliciosos servidos a través de proveedores publicitarios legítimos (malvertising).

Incluso Google reconoce la magnitud del problema: solo en 2024, Google bloqueó 5.1 mil millones de anuncios maliciosos y suspendió 39.2 millones de cuentas de anunciantes (Informe de seguridad de Google Ads, 2025). Esas cifras son abrumadoras, y aun así solo representan lo que se ha detectado. Los anuncios que logran pasar constituyen la superficie de ataque a la que su SOC es más vulnerable, ya que todos los controles de la cadena —DNS, categoría de URL, certificado TLS, firma del punto final— consideraron que la infraestructura publicitaria era fiable.

Si esta sesión del analista se hubiera canalizado a través de remote browser isolation, el código JavaScript se habría ejecutado en un contenedor efímero en la nube. El programa de robo de información no habría tenido ningún proceso local al que conectarse, ningún almacén de credenciales que leer ni ninguna vía de persistencia en el terminal.

Por qué la seguridad de red tradicional falla sistemáticamente en el navegador

Las defensas perimetrales tradicionales se diseñaron para un mundo en el que las amenazas llegaban en forma de archivos transmitidos por la red o de conexiones a direcciones IP maliciosas conocidas. El navegador ha invertido ese modelo. Es aquí donde fallan los controles específicos:

Lagunas en la inspección del tráfico cifrado

El Informe sobre ataques cifrados de ThreatLabz de 2024 reveló que el 87 % de las amenazas se ocultaban en el tráfico TLS/SSL. La mayoría de las pasarelas web seguras heredadas o bien no pueden descifrar TLS 1.3 a gran escala, o bien excluyen de la inspección amplias categorías de tráfico —como la banca, los portales sanitarios o las aplicaciones SaaS con «certificate pinning»—. Un atacante que aloje una página de recopilación de credenciales tras un certificado válido de Let's Encrypt en un dominio recién registrado aprovecha esta brecha sin problemas. Un analista del SOC que revise los registros del proxy observará una conexión HTTPS saliente hacia una CDN. Nada parece sospechoso hasta que ya es demasiado tarde.

Filtrado de URL y retraso en la información de reputación

Las bases de datos de reputación de URL son reactivas. Una campaña de publicidad maliciosa que utilice un dominio nuevo, enmascare su página de destino para mostrar contenido inofensivo a los rastreadores y envíe la carga útil real únicamente a las víctimas que coincidan con una huella digital específica del navegador no aparecerá en ninguna fuente de información sobre amenazas hasta después de la primera oleada de infecciones. Considere una campaña típica de software troyanizado distribuida a través de anuncios en buscadores: los sitios promocionan una aplicación de aspecto legítimo, el dominio de descarga supera los controles de reputación y el malware permanece inactivo durante semanas antes de activarse —tiempo suficiente para eludir la mayoría de los bloqueos retroactivos de URL—.

Puntos ciegos de los programas antivirus y de EDR para dispositivos finales en el navegador

Los ataques en el navegador resultan difíciles de detectar para las herramientas de seguridad de los terminales, ya que los rastros son efímeros, quedan ocultos en la memoria del navegador y se transmiten de forma casi instantánea para preservar la experiencia del usuario (Notas técnicas de seguridad de GitLab, 2025). Cuando una carga útil maliciosa de JavaScript se ejecuta dentro del motor V8 del navegador, no guarda ningún archivo en el disco; manipula el DOM, lee los campos de los formularios y extrae datos a través de conexiones WebSocket que parecen idénticas al tráfico legítimo del navegador. Los agentes EDR que supervisan los árboles de procesos, las escrituras de archivos y los cambios en el registro no detectan nada que justifique una acción.

Qué ha cambiado: el navegador se ha convertido ahora en el espacio de trabajo de la empresa

Tres cambios que han coincidido han convertido al navegador, que antes era una preocupación secundaria, en la principal superficie de ataque:

En primer lugar, el SaaS ha sustituido a la red como perímetro. Cuando los empleados acceden a Salesforce, Workday, ServiceNow y Microsoft 365 a través de un navegador, la sesión del navegador constituye la capa de acceso. Una sesión de navegador comprometida otorga el mismo acceso que una VPN comprometida —a menudo incluso más—, ya que las sesiones de SaaS suelen persistir entre dispositivos y carecen de los registros de la capa de red que proporcionan las conexiones VPN.

En segundo lugar, el número de ataques a través de la web como vector de infección inicial está aumentando considerablemente. El informe «Mandiant M Trends 2025» reveló que la exposición a riesgos en la web pasó del 5 % al 9 % de los vectores de infección iniciales entre 2023 y 2024, lo que supone casi el doble. La exposición a riesgos en la web abarca los ataques «drive-by», los anuncios maliciosos, el envenenamiento de SEO y los sitios web comprometidos. Este aumento no es una fluctuación aleatoria; refleja que los atacantes están recurriendo deliberadamente a la distribución a través del navegador, ya que así eluden los controles en los que las organizaciones han invertido.

En tercer lugar, el robo de credenciales y el secuestro de sesiones se han industrializado. Las credenciales robadas fueron el segundo vector de acceso inicial más común, con un 16 % de los incidentes investigados, según el informe «Mandiant M Trends 2025». El informe «Verizon 2025 DBIR» señaló que se utilizaron credenciales robadas en el 22 % de las filtraciones. Muchas de esas credenciales proceden del navegador: contraseñas rellenadas automáticamente, cookies en el almacenamiento local y tokens de sesión capturados por programas de robo de información que se ejecutan en el contexto de renderizado. La convergencia entre el malware de robo de información, los mercados de credenciales y el navegador como espacio de trabajo implica que una sola sesión de navegador comprometida puede desbloquear toda la cadena de ataque de un atacante.

Extensiones del navegador: el ataque a la cadena de suministro que no está supervisando

Un coordinador de marketing instala una popular extensión de Chrome para la revisión gramatical que cuenta con 500 000 usuarios y una valoración de 4,8 estrellas. Seis meses después, el desarrollador de la extensión la vende a un comprador desconocido. El nuevo propietario lanza una actualización silenciosa que añade código para extraer cookies y tokens de sesión de todos los sitios web que visita el usuario, incluido el portal corporativo de inicio de sesión único (SSO). No se activa ninguna alerta porque la extensión ya era de confianza, la actualización se realizó a través de la tienda oficial y la extracción utiliza llamadas HTTPS estándar.

En diciembre de 2024, un actor malicioso llevó a cabo un ataque a la cadena de suministro de software utilizando cuentas de desarrolladores comprometidas para distribuir actualizaciones maliciosas de extensiones de navegador desde la Chrome Web Store (GitLab Security Tech Notes, 2025). El actor malicioso actualizó las extensiones con código que extraía datos de los encabezados HTTP y del contenido DOM basándose en una configuración dinámica; se trató de un ataque sofisticado que afectó al menos a 3,2 millones de usuarios.

El modelo operativo es alarmantemente sencillo. La pauta más recurrente desde finales de 2024 ha sido el secuestro de confianza a través de actualizaciones: los atacantes publican en tiendas oficiales, comprometen a los desarrolladores o se apoderan de extensiones ya consolidadas, para luego distribuir a gran escala actualizaciones maliciosas a los usuarios existentes. Las extensiones «latentes» permanecen inofensivas el tiempo suficiente para ganarse la confianza de los usuarios y, a continuación, activan comportamientos de espionaje, robo de tokens o redireccionamiento a través de actualizaciones.

Desde la perspectiva de un SOC, este tipo de ataque es prácticamente invisible. La extensión opera dentro del proceso del navegador, se comunica a través de HTTPS con dominios que pueden haber sido registrados recientemente o estar alojados en plataformas en la nube, y accede exactamente al mismo contenido de la página que ve legítimamente el usuario. Los agentes de los terminales no lo detectan. La supervisión de la red detecta tráfico cifrado dirigido a una CDN. Las únicas contramedidas eficaces son una gestión granular de las extensiones —listas de permitidos, auditoría de permisos, fijación de versiones— y el aislamiento de las sesiones del navegador mediante el aislamiento del navegador, de modo que ni siquiera una extensión comprometida pueda acceder al terminal real.

Robo de credenciales y secuestro de sesiones: cómo burlar la autenticación multifactorial (MFA) a través del navegador

Un administrador de nóminas recibe un correo electrónico sobre una actualización de la política de prestaciones. El enlace abre una página que se parece exactamente a la página de inicio de sesión del proveedor de identidad de la empresa: misma imagen de marca, mismo icono de candado del certificado y misma estructura de dominio, siempre que el usuario no examine detenidamente el subdominio. El administrador introduce sus credenciales y su token de autenticación multifactorial (MFA). Un atacante situado en el proxy intermedio reenvía las credenciales al proveedor de identidad real en tiempo real, captura la cookie de sesión y la reproduce desde su propio navegador. El atacante dispone ahora de una sesión autenticada. La autenticación multifactorial (MFA) cumplió su función —autenticó al usuario—, pero el atacante se apropió del resultado de dicha autenticación.

MITRE ATT&CK T1185 (Secuestro de sesión del navegador) describe cómo los atacantes se aprovechan de las vulnerabilidades de seguridad y de la funcionalidad inherente al software del navegador para alterar contenidos, modificar el comportamiento de los usuarios e interceptar información. Un ejemplo concreto es cuando un atacante inyecta software en un navegador que le permite heredar cookies, sesiones HTTP y certificados de cliente SSL. Con estos permisos, un atacante podría, en teoría, acceder a cualquier recurso de una intranet, como SharePoint o el correo web. El pivote del navegador también puede eludir la seguridad que proporciona la autenticación de dos factores.

No se trata de una preocupación teórica. Los kits de phishing de tipo «adversario en el medio» se han convertido en productos de uso generalizado. Los kits de «phishing como servicio» utilizan ahora técnicas de «navegador dentro del navegador» (BitB) que muestran ventanas de navegador falsas dentro del navegador real del usuario para imitar los flujos de inicio de sesión legítimos. Estos kits presentan pantallas de inicio de sesión convincentes, con barras de direcciones falsificadas, y capturan tanto las credenciales como los tokens de sesión activos. Emplean comprobaciones de protección contra bots, carga condicional, rotación rápida de dominios y ofuscación de código para eludir la detección.

Los controles de red tradicionales —la reputación IP, el filtrado por antigüedad de dominio e incluso la supervisión de la transparencia de los certificados— tienen dificultades para seguir el ritmo de la rápida renovación de la infraestructura. La defensa más eficaz consiste en impedir, desde el principio, que la página de phishing se cargue en el navegador del usuario, que es precisamente lo que hace una secure web gateway de última generación con RBI integrado: aunque el usuario haga clic, la página se carga en un contenedor aislado donde no es posible registrar las credenciales mediante keyloggers ni interceptar los tokens de sesión.

Exfiltración basada en JavaScript: pérdida de datos a través del motor de renderizado

Un analista de una empresa del sector sanitario abre un portal de investigación que ha sido comprometido a través de un script de análisis de un tercero. El código JavaScript inyectado lee de forma silenciosa el DOM de una aplicación SaaS con pestañas que el analista tiene abierta —concretamente, un panel de control de historiales de pacientes—, serializa los datos visibles en un blob JSON y los envía mediante un método POST a un punto final controlado por el atacante a través de una conexión WebSocket que simula tráfico de telemetría. No se descargó ningún archivo. No se instaló ningún ejecutable. Las reglas de DLP que vigilan los archivos adjuntos, las escrituras en USB o las subidas a la nube nunca se activan.

Este escenario ilustra por qué data loss prevention extenderse a la propia sesión del navegador. El código JavaScript que se ejecuta en el navegador tiene acceso de lectura a todo lo que el usuario puede ver. Las restricciones de origen cruzado ayudan, pero los scripts propios comprometidos, las bibliotecas contaminadas de la cadena de suministro y las extensiones maliciosas operan todos dentro del mismo origen que la aplicación legítima.

Mandiant no pudo determinar el vector de infección inicial en el 34 % de las intrusiones registradas en 2024 (M Trends 2025), una proporción que apunta a posibles deficiencias en las capacidades de registro y detección de las empresas. La exfiltración a través del navegador es probablemente uno de los factores que contribuyen a esa brecha: cuando los datos salen a través del motor de renderizado en lugar de hacerlo a través del sistema de archivos, el rastro forense es mínimo.

Lo que deben hacer ahora los equipos de seguridad

El desajuste estructural entre las amenazas que se transmiten a través del navegador y los controles de la capa de red no se resolverá por sí solo. A continuación se presenta un plan de acción con las medidas priorizadas:

1. Implemente remote browser isolation el tráfico de alto riesgo

RBI ejecuta el contenido web en un contenedor en la nube desechable y transmite únicamente la salida visual segura al terminal. Las cargas útiles de publicidad maliciosa, los ataques «drive-by» y la exfiltración basada en JavaScript se detienen en el contenedor. Comience con las URL sin clasificar y las categorías de riesgo, y amplíe posteriormente el alcance a todo el tráfico web de los usuarios con privilegios y los puestos de responsabilidad. La plataforma SSE Skyhigh Security, con RBI integrado, evita la complejidad de implementación propia de los productos de aislamiento independientes.

2. Aplicar la inspección TLS sin excepciones

Si la gran mayoría de las amenazas se ocultan en el tráfico cifrado, eximir de inspección a amplios segmentos de tráfico HTTPS crea un punto ciego garantizado. Las arquitecturas modernas de SWG (gateway de seguridad web) basadas en la nube pueden inspeccionar TLS 1.3 a gran escala sin la latencia ni los problemas de gestión de certificados propios de los dispositivos tradicionales. Tal y como destaca la norma NIST SP 800-207, el modelo «zero trust» parte de la base de que no se concede confianza implícita a los activos ni a las cuentas de usuario basándose únicamente en su ubicación física o en la red. Este principio se extiende a las sesiones cifradas: se debe confiar en la identidad y en los datos, no en la capa de protocolo.

3. Desactivar las extensiones del navegador

Implement an allowlist of approved extensions. Audit permissions aggressively—any extension requesting <all urls host permissions or access to cookies and web requests should require security review. Pin extension versions to prevent silent malicious updates. For organizations that cannot fully restrict extensions, RBI provides a safety net by isolating extension activity from the corporate session.

4. Incorporar DLP al contexto del navegador

Los sistemas DLP a nivel de archivo y de red no detectan la filtración de datos basada en JavaScript. Las políticas de DLP integradas, aplicadas a través de una pasarela de seguridad web y en la nube de Skyhigh, pueden inspeccionar el contenido dentro de la sesión del navegador, detectando operaciones de copiar y pegar de datos confidenciales hacia destinos no autorizados, aplicando marcas de agua digitales a las capturas de pantalla de contenido confidencial del navegador y controlando las descargas en dispositivos no gestionados.

5. Adoptar un sistema de autenticación resistente al phishing

Las claves de seguridad de hardware compatibles con FIDO2 vinculan la autenticación al dominio legítimo, lo que hace que el phishing de tipo «man-in-the-middle» resulte estructuralmente imposible, incluso si el usuario hace clic en un enlace malicioso. La vinculación del token de sesión y la evaluación continua del estado de seguridad reducen aún más el margen de exposición.

La urgencia: las lagunas en la detección se están ampliando, en lugar de reducirse

La mediana mundial del tiempo de permanencia alcanzó los 11 días en 2024 (Mandiant M Trends 2025), y muchas intrusiones se detectan durante la primera semana. Esto puede parecer alentador, hasta que se tiene en cuenta que los ataques basados en el navegador pueden completar toda su cadena de ataque en cuestión de minutos: la obtención de credenciales, el secuestro de sesión, la exfiltración de datos y la limpieza, todo ello en el marco de una única sesión del navegador que puede que nunca aparezca en los registros de los terminales o de la red.

El 57 % de las organizaciones se enteró por primera vez de una filtración ocurrida en 2024 a través de una fuente externa (Mandiant M Trends 2025). Si no es su propio SOC el que detecta la filtración, la pregunta es si sus herramientas disponen de alguna visibilidad sobre el navegador. Para la mayoría de las organizaciones, la respuesta sincera es no. El informe DBIR de Verizon de 2025 puso de relieve esta realidad al constatar que la intervención humana influyó en el 60 % de las brechas de seguridad; y, en un mundo centrado en el navegador, es precisamente en este donde tiene lugar dicha interacción humana.

El navegador es el lugar donde los empleados se autentican, donde se consultan y manipulan datos confidenciales, y donde se ejecutan los flujos de trabajo de SaaS. Se trata de la superficie de punto final más importante de la empresa y, sin embargo, sigue siendo la menos protegida. Cada mes que transcurre sin ampliar los controles de seguridad al navegador supone un mes de riesgo acumulado e incalculable.