El primer ransomware nativo del navegador asistido por IA no cifra archivos: secuestra la sesión y deja a las defensas mirando al lado

La parte inquietante de esta historia no es la sigla IA. A estas alturas, poner “asistido por IA” en un titular ya no impresiona a nadie con oficio. Lo que sí cambia el tablero es otra cosa: el ataque vive dentro del navegador, no necesita explotar una vulnerabilidad clásica y convierte una sesión legítima en una máquina de extorsión.

Eso es lo que ha puesto sobre la mesa Check Point Research al alertar este año de una muestra en la que un modelo de IA enlazó de forma autónoma un riesgo de navegación conocido en teoría con una técnica operativa de ransomware. Dicho en castellano llano: no encontró un agujero nuevo tipo CVE, no rompió el sistema operativo, no cifró el disco duro. Hizo algo más elegante y, por eso mismo, más incómodo para los equipos de defensa: secuestró el entorno de trabajo real del usuario allí donde hoy se hace casi todo, en el navegador.

Si tu programa de seguridad sigue pensando el ransomware como “malware que entra, cifra archivos y pide rescate”, vas con retraso. El navegador se ha convertido en sistema operativo de facto para banca, seguros, SaaS empresarial, CRM, correo, repositorios documentales y consolas de administración. Atacar ese punto ya no es una excentricidad de laboratorio. Es la evolución lógica.

No hace falta romper Windows si puedes secuestrar Chrome

La novedad técnica importa porque desplaza el foco desde la explotación de vulnerabilidades hacia el abuso del comportamiento normal del usuario y de la arquitectura web moderna. Un navegador hoy almacena sesiones activas, tokens, credenciales delegadas, acceso a aplicaciones críticas, extensiones con permisos amplios, almacenamiento local, service workers y capacidad para mantener interfaces persistentes. Todo eso, bien orquestado, permite fabricar un efecto ransomware sin tocar apenas el sistema de archivos.

Ese matiz cambia dos supuestos que llevaban años dominando la respuesta defensiva. El primero: que la extorsión depende del cifrado de datos. El segundo: que el punto de detección está en el endpoint o en la red. Aquí el daño puede producirse antes, en la capa de interacción. El usuario abre lo que cree una sesión de trabajo y acaba atrapado en una interfaz manipulada, sin acceso útil a sus aplicaciones, con datos de sesión comprometidos y con un mensaje de rescate que no necesita haber cifrado un solo documento local para ser eficaz.

La ironía es evidente. Llevamos años repitiendo a los usuarios que trabajen en la nube, que no descarguen nada, que usen aplicaciones web porque “todo está más controlado”. Y resulta que el navegador, precisamente por concentrar identidad, acceso y contexto de negocio, se convierte en un objetivo de alto valor. No porque sea inseguro por naturaleza, sino porque lo usamos como si fuera inocuo.

Qué significa exactamente “ransomware nativo del navegador”

Conviene poner orden, porque el término puede prestarse a exageraciones fáciles. Un “browser-native ransomware” no tiene por qué comportarse como el ransomware tradicional. Puede operar con cuatro efectos distintos, solos o combinados:

Primero, bloquear la interacción del usuario con la sesión mediante técnicas web persistentes: pantallas a pantalla completa, bucles, ventanas superpuestas, scripts que impiden navegación útil, abuso de notificaciones o redirecciones encadenadas. No es sofisticación militar; es saber qué piezas del navegador se pueden retorcer para volverlo impracticable.

Segundo, abusar de sesiones ya autenticadas. Si el usuario está conectado a correo corporativo, gestor documental, ERP o consola cloud, el atacante no necesita robar una contraseña en el sentido clásico. Le basta con aprovechar el estado autenticado, capturar tokens o manipular el flujo mientras la sesión sigue viva.

Tercero, exfiltrar o poner en riesgo datos accesibles desde el navegador. Aquí la extorsión puede dejar de basarse en “te cifro” para pasar a “te publico”, “te interrumpo” o “te mantengo fuera de tus procesos críticos”. La doble extorsión no requiere necesariamente cifrado local si el acceso operacional ya ha sido comprometido.

Cuarto, degradar la confianza en la interfaz. Un navegador manipulado puede presentar ventanas, formularios o flujos que el usuario interpreta como parte legítima de la aplicación. Esa capa de engaño es especialmente peligrosa en entornos donde una sola sesión permite aprobar pagos, acceder a datos de clientes o administrar infraestructura.

La pieza de Check Point Research apunta justo a ese salto: una IA no se limitó a producir código genérico, sino que conectó un riesgo teórico con una forma práctica de monetización criminal. Ahí está el avance. No en que la IA escriba scripts —eso ya lo hace cualquiera con paciencia y un prompt mediocre—, sino en que deduzca una cadena de abuso con valor operativo.

La IA aquí no sustituye al atacante. Le ahorra el tramo más caro

La tentación mediática es presentar estas historias como “la IA ataca sola”. Suena mejor, pero explica peor. Lo relevante no es la autonomía total, que suele estar bastante inflada, sino la reducción del coste cognitivo para construir cadenas de ataque plausibles.

Durante años, la ventaja del atacante residía en saber combinar piezas pequeñas: una técnica de engaño, una mala configuración, una sesión abierta, una API permisiva, una extensión sobredimensionada. Nada de eso era ciencia ficción. Lo difícil era unirlo con rapidez y convertirlo en algo reutilizable. Los modelos generativos y los agentes semiautónomos son buenos precisamente en eso: correlacionan, prueban, iteran y reformulan.

Eso tiene tres efectos prácticos.

El primero es la velocidad. Lo que antes exigía un perfil técnico con experiencia ahora puede prototiparse mucho más deprisa. No significa que cualquiera vaya a producir malware de primer nivel, pero sí que la fase de experimentación se abarata.

El segundo es la diversidad. Los equipos de defensa han mejorado mucho detectando familias conocidas, TTPs consolidadas y cadenas de ejecución repetidas. Cuando una IA genera variantes funcionales, aunque sean mediocres, obliga a defender comportamiento en lugar de firmas. Y defender comportamiento cuesta más.

El tercero es el descubrimiento de combinaciones “aburridas” que nadie estaba priorizando. Ahí hay una lección incómoda. A veces el mayor riesgo no es un zero-day espectacular, sino un uso malicioso de funciones previstas, desplegadas a escala con suficiente creatividad. La IA es especialmente útil para encontrar esas uniones de piezas aparentemente inocentes.

No es casualidad que agencias como ENISA lleven tiempo insistiendo en amenazas híbridas que mezclan ingeniería social, abuso de identidad y dependencia de servicios cloud. El navegador es el punto donde todo eso converge. Y esa convergencia, no el marketing de la IA, es lo que debería preocupar a un CISO.

Por qué este ataque encaja demasiado bien con la empresa de 2026

La mayoría de organizaciones ya no trabajan “con” aplicaciones web. Trabajan “desde” aplicaciones web. La diferencia no es semántica. Significa que correo, colaboración, soporte, ventas, back office, pagos, RR.HH. y acceso a infraestructura pasan por una sesión de navegador, casi siempre mediada por SSO, MFA y un puñado de extensiones que nadie revisa tanto como dice revisar.

Esa realidad hace que el navegador concentre cuatro activos de alto valor:

Identidad. La sesión ya autenticada es un premio. Si además hay single sign-on, una sola intrusión en el contexto del navegador puede abrir varias puertas a la vez.

Continuidad operativa. Si el navegador deja de ser fiable, una parte del negocio se detiene aunque los servidores sigan técnicamente sanos. Esa es la pesadilla de resiliencia operativa: infraestructura “up”, operación real “down”.

Datos. Buena parte de la información sensible ya no vive en un fichero local sino detrás de una pestaña, una API o un panel.

Capacidad de acción. Aprobar una transferencia, cambiar un proveedor, exportar una base de clientes o modificar una política cloud puede requerir solo una sesión válida y el rol adecuado.

Desde ese punto de vista, un ransomware de navegador no compite con el ransomware clásico. Lo complementa. Puede ser la fase inicial, la alternativa silenciosa o el mecanismo de presión cuando cifrar ya no es la única forma rentable de extorsionar.

Y aquí aparece un detalle poco cómodo para muchas empresas: su madurez de seguridad de navegador suele estar años por detrás de su madurez de endpoint. Hay EDR, XDR, SIEM, MFA, CASB y toda la sopa de letras imaginable. Pero cuando preguntas quién inventaría todas las extensiones instaladas, quién gobierna el almacenamiento local en aplicaciones críticas o quién monitoriza secuestros de sesión en tiempo real, el silencio se vuelve bastante elocuente.

No explotar una CVE también es una mala noticia para el compliance

Cuando un incidente se apoya en una vulnerabilidad conocida, el relato interno es relativamente cómodo. Se revisan parches, exposición, tiempos de remediación, responsable técnico y lecciones aprendidas. Hay una causalidad clara. Incluso la supervisión regulatoria entiende bien ese guion.

Cuando no hay explotación de CVE y el ataque se apoya en comportamiento permitido, identidad comprometida o abuso de la capa web, la conversación se complica. Ya no basta con decir “teníamos el parche pendiente” o “el proveedor publicó la corrección tarde”. Ahora la pregunta pasa a ser otra: ¿habíais diseñado controles pensando en cómo trabaja realmente vuestra plantilla?

Para las entidades sujetas a DORA, esa distinción importa mucho. El Reglamento (UE) 2022/2554 no se limita a exigir medidas técnicas abstractas. En su artículo 6 exige un marco interno de gestión del riesgo de las TIC sólido, completo y bien documentado. El artículo 8 pide identificar y clasificar funciones, activos de información y dependencias TIC. El artículo 9 va a gobernanza y protección. El artículo 10 entra en detección. El artículo 11, en respuesta y recuperación. Si tu operación depende del navegador y tus controles no lo reflejan, el problema no es solo técnico. Es de diseño del marco de resiliencia.

Más aún: DORA trata la continuidad operativa digital como una capacidad integral, no como una colección de productos de seguridad. Un incidente de secuestro de sesión o de degradación masiva del navegador puede afectar servicios críticos sin “caerse” la infraestructura tradicional. Ese tipo de escenario debe aparecer en análisis de impacto, playbooks, pruebas y comunicación interna. Si no aparece, tu mapa de riesgo está desactualizado.

NIS2 va en la misma dirección. La Directiva (UE) 2022/2555, en su artículo 21, obliga a medidas de gestión de riesgos de ciberseguridad que incluyan gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en la adquisición y mantenimiento de sistemas y políticas para evaluar la eficacia de las medidas. Un ataque de navegador que explota identidad, sesiones o dependencias SaaS no encaja ya en el viejo cajón de “phishing y listo”. Toca gestión de acceso, telemetría, hardening del cliente, gobierno de extensiones y continuidad.

También GDPR entra en escena antes de lo que algunos quisieran. Si el secuestro de sesión o la exfiltración asociada compromete datos personales, el artículo 33 del Reglamento (UE) 2016/679 obliga a notificar a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo no superior a 72 horas desde que se tenga constancia. Si el riesgo para los interesados es alto, el artículo 34 abre la puerta a la comunicación a los afectados. No hace falta un cifrado de base de datos al estilo 2019 para llegar ahí. Basta con acceso no autorizado o pérdida de confidencialidad sobre datos accesibles desde la sesión comprometida.

La lección es simple: el ataque no necesita parecerse al ransomware clásico para activar obligaciones regulatorias muy reales.

La diferencia entre un susto de laboratorio y un riesgo empresarial está en la sesión

No todo experimento técnico merece un despliegue mediático. Hay demos llamativas que no salen del PowerPoint. Pero aquí hay una razón para tomárselo en serio: la sesión autenticada es uno de los activos menos visibles y más infravalorados de la seguridad corporativa.

Muchas organizaciones invierten mucho en el momento del login y poco en lo que ocurre después. Autenticación multifactor, perfecto. Inicio de sesión adaptativo, bien. Políticas condicionales, mejor. Pero una vez dentro, la sesión suele gozar de una confianza bastante generosa. Tiempos de expiración largos, reautenticaciones limitadas, tokens con alcance amplio, aplicaciones que confían demasiado en el cliente, y un ecosistema de extensiones o componentes del navegador que rara vez pasa por un control serio de mínimo privilegio.

Un atacante que secuestra esa sesión no necesita ser invisible durante semanas. A veces le basta con 20 minutos buenos. Exportar datos, aprobar operaciones, cambiar credenciales, registrar persistencia o bloquear el trabajo del usuario. Ese impacto cabe perfectamente dentro de una campaña extorsiva.

Además, la experiencia del usuario juega a favor del atacante. La gente está acostumbrada a pestañas que fallan, aplicaciones SaaS que se cuelgan, redirecciones extrañas, ventanas de reautenticación, captchas absurdos y mensajes de error ininteligibles. Un secuestro de navegador no tiene que ser perfecto; solo tiene que parecer uno de esos problemas molestos que todos toleramos porque “la web corporativa va así”. Es un terreno fértil para el abuso.

Qué deberían revisar ya los CISO, sin esperar al siguiente titular grandilocuente

La respuesta útil no pasa por prohibir navegadores ni por improvisar un comité de pánico con doce directores y ninguna decisión. Pasa por cerrar huecos concretos en una capa que demasiadas empresas han tratado como si fuera solo UX.

Empieza por el inventario. No de equipos. De navegadores, perfiles, extensiones y aplicaciones críticas accesibles vía web. Si no sabes qué extensiones están activas en los dispositivos corporativos o BYOD autorizados, estás defendiendo a ciegas una superficie con permisos de lectura y modificación sobre páginas sensibles. Ese inventario debería cruzarse con criticidad de negocio y con privilegios de usuario.

Sigue por la sesión. Revisa duración, rotación y alcance de tokens, políticas de reautenticación para acciones críticas, protección frente a secuestro de cookies o abuso de almacenamiento del lado cliente. Si una sola sesión permite exportar datos sensibles y aprobar cambios administrativos sin paso adicional, la comodidad del usuario se ha comido al control.

Luego, endurece el navegador como activo corporativo. No es glamour técnico; es higiene básica de 2026. Políticas centralizadas para extensiones permitidas, aislamiento del navegador o enterprise browser cuando la criticidad lo justifique, bloqueo de instalaciones no aprobadas, segregación de perfiles, restricción de acceso a dominios de alto riesgo y control de descargas o pegado entre contextos si el caso de uso lo exige.

También toca telemetría. El SIEM tradicional suele ver el login, la llamada API o el evento del endpoint, pero no siempre la secuencia web anómala dentro de la sesión. Necesitas señales capaces de detectar comportamiento extraño en el navegador o en la aplicación: exportaciones masivas, secuencias imposibles, cambios de contexto, uso de extensiones no autorizadas, solicitudes repetitivas, abuso de notificaciones o interacción con páginas señuelo. Aquí la integración entre seguridad de identidad, CASB, logs SaaS, EDR y analítica del navegador deja de ser un lujo.

Por último, ensaya escenarios. No “ransomware” en abstracto. Escenarios concretos: un operador de tesorería pierde el control funcional del navegador con la sesión abierta; un administrador de CRM ve secuestrado su contexto y se exfiltran datos; un equipo de atención al cliente queda bloqueado sin que el backend se caiga. ¿Quién detecta? ¿Quién aísla la sesión? ¿Quién invalida tokens? ¿Quién decide si hay que notificar por GDPR art. 33? Si no puedes responder eso en menos de una hora, tu playbook necesita menos diapositivas y más realidad.

La capa olvidada: extensiones, almacenamiento local y permisos web

Si hay un ángulo sistemáticamente subestimado en la seguridad del navegador, es este. Las extensiones llevan años siendo una mezcla peculiar de utilidad, deuda técnica y fe. Algunas tienen permisos amplísimos: leer y modificar el contenido de páginas, interceptar tráfico, acceder al portapapeles, capturar datos introducidos en formularios. En entornos corporativos, eso es dinamita si no existe gobierno estricto.

El problema no es solo la extensión maliciosa de manual. También cuentan las extensiones legítimas con prácticas pobres de seguridad, cadenas de suministro comprometidas, cambios de propiedad del desarrollador o actualizaciones que amplían permisos. La historia reciente del software está llena de componentes confiables hasta que dejaron de serlo. El navegador no es una excepción; simplemente se audita bastante menos.

Luego está el almacenamiento local: cookies, localStorage, IndexedDB y otros mecanismos que muchas aplicaciones usan por rendimiento o experiencia de usuario. No todos son malos por sí mismos. El riesgo aparece cuando se guardan artefactos sensibles o se asume una confianza implícita en el cliente. Un atacante que opera en la capa del navegador puede aprovechar esos elementos para persistir, manipular flujos o reutilizar contexto.

Y no olvidemos los permisos web modernos. Portapapeles, notificaciones, pantalla completa, descargas, acceso a dispositivos en ciertos contextos. La web ha ganado capacidades por una razón obvia: queremos que haga más cosas. Cada capacidad útil también amplía el repertorio del abuso.

Si estás bajo presión regulatoria, este punto tiene una traducción práctica inmediata: tus políticas de hardening ya no pueden quedarse en sistema operativo y MDM. Deben incluir política de navegador. No porque quede bonito en una auditoría, sino porque la superficie real de operación se ha desplazado ahí.

Qué cambia para banca, seguros y fintech en Europa

En entidades financieras europeas, la gravedad es doble: por dependencia operativa y por expectativa supervisora. Muchas funciones críticas ya se ejecutan sobre consolas web de terceros, plataformas SaaS, herramientas de colaboración y paneles internos accesibles por navegador. Ese modelo aporta velocidad, sí. También concentra riesgo operacional en la sesión autenticada de usuarios con privilegios.

DORA obliga este año a demostrar resiliencia operativa digital de forma más creíble que en la era de los discursos voluntaristas. El artículo 13 exige políticas y procedimientos de continuidad y recuperación TIC; el artículo 15, capacidades de comunicación de incidentes; y el marco de pruebas del capítulo IV empuja a ejercicios que validen la eficacia real de los controles. Aunque el texto no diga “browser ransomware” —faltaría más—, sí exige que el marco cubra escenarios plausibles según funciones críticas, dependencias y vectores de riesgo reales.

Eso tiene implicaciones concretas para bancos, aseguradoras, entidades de pago y fintech. Si tus operaciones críticas pasan por aplicaciones web, deberías poder demostrar al supervisor al menos cuatro cosas: que has identificado esa dependencia, que has definido controles proporcionales sobre sesión y acceso, que puedes detectar abuso sin depender solo de malware clásico, y que tu respuesta operativa incluye invalidación de sesiones, rotación de credenciales y continuidad por canales alternativos.

Con NIS2 la presión alcanza también a muchos proveedores tecnológicos y entidades esenciales o importantes fuera del núcleo financiero. Y ahí aparece un problema de cadena de suministro. Un navegador comprometido en el puesto de un proveedor con acceso a sistemas del cliente puede convertirse en puerta lateral sin necesidad de comprometer primero la infraestructura del proveedor. Esto encaja de lleno con la preocupación de NIS2 por la seguridad de la cadena de suministro y con la lógica de terceros TIC de DORA, especialmente en las disposiciones sobre gestión de riesgo de proveedores en el capítulo V y, de forma muy directa, en el artículo 28 sobre terceros proveedores de servicios TIC.

Traducido: si subcontratas operación crítica accesible por web, la higiene del navegador del proveedor ya no es una rareza contractual. Es un tema de resiliencia.

La mala noticia para los defensores: muchas herramientas verán el síntoma, no la causa

En la práctica, un ataque nativo del navegador puede dejar rastros dispersos. El EDR verá poco o verá tarde si no hay payload clásico en disco. La protección de correo quizá detecte el vector inicial si entró por phishing, pero no el abuso posterior de la sesión. El CASB observará actividad cloud anómala si está bien integrado, aunque puede interpretarla como uso legítimo desde una sesión válida. El SOC acabará viendo piezas sueltas: exportaciones, redirecciones, accesos extraños, bloqueos de usuario, cambios de configuración, quizá una ola de tickets de soporte.

Ese patrón fragmentado exige correlación y contexto. Es decir, exige madurez. La defensa no puede depender solo de “firma mala = bloqueo”. Tiene que unir identidad, dispositivo, comportamiento de aplicación y estado de sesión.

Por eso la discusión sobre secure enterprise browsers, browser isolation remoto y controles de navegación corporativa ha ganado peso este año. No son la bala de plata —nada lo es—, pero sí responden a un hecho que durante demasiado tiempo se trató como detalle menor: el navegador es ya un plano de control del negocio. Si lo administras como un accesorio, te expones como si fuera un accesorio. Y no lo es.

Qué haría un equipo serio esta semana

No dentro de un trimestre. Esta semana.

Primero, identificaría qué funciones críticas dependen exclusivamente de navegador y qué roles las ejecutan. Tesorería, atención al cliente, administración cloud, gestión documental, back office de pólizas, pagos, CRM. La lista varía según sector, pero tiene que existir por nombre, responsable y aplicación concreta.

Después, revisaría controles de sesión en esas aplicaciones: expiración, reautenticación para acciones sensibles, revocación centralizada, logging útil y capacidad de invalidación inmediata. Esto parece básico hasta que intentas hacerlo y descubres que cada SaaS tiene su propia lógica, sus límites y sus concesiones a la comodidad.

Luego, impondría gobierno de extensiones y perfiles de navegador en usuarios de alto privilegio. No un correo amable recomendando prudencia. Gobierno real: allowlist, políticas de instalación, bloqueo por defecto cuando proceda y separación entre navegación general y acceso a funciones críticas.

En paralelo, el SOC o quien haga de SOC debería construir detecciones enfocadas a abuso de sesión y comportamiento web anómalo, no solo a ejecución de binarios o tráfico de mando y control. Aquí cuenta más el conocimiento del negocio que la herramienta de moda.

Y sí, tocaría sentar a seguridad, identidad, arquitectura de workplace y dueños de aplicaciones críticas en la misma mesa. No porque la colaboración sea preciosa, sino porque el problema cruza esas cuatro capas y cada una suele creer que el riesgo pertenece a las otras tres.

No estamos ante una curiosidad exótica. Estamos viendo el borrador del siguiente problema serio

Los ataques importantes rara vez llegan al mercado con etiqueta perfecta. Primero aparecen como prueba de concepto, investigación o rareza técnica. Después alguien les encuentra economía. Ahí despegan. Eso es exactamente lo que hay que vigilar en este caso: la transición de “demostración ingeniosa” a “modelo de extorsión viable”.

La economía puede salir por varias vías. Menor coste de desarrollo gracias a IA. Mayor tasa de éxito contra usuarios que viven en aplicaciones web. Menor dependencia de vulnerabilidades explotables y, por tanto, menor exposición a controles clásicos de parcheo. Mejor capacidad de operar en entornos donde el endpoint está razonablemente fortificado pero la sesión sigue siendo blanda.

Si además el ataque logra combinar bloqueo funcional, exfiltración selectiva y presión sobre continuidad operativa, el incentivo criminal existe. Y cuando existe incentivo, la industrialización suele llegar más rápido de lo que al sector le gustaría admitir.

Sería un error leer esta alerta como una extravagancia de laboratorio con aderezo de IA. Lo útil es verla como un aviso sobre dónde se está desplazando el valor ofensivo: identidad, sesión, contexto de negocio y capa web. Justo donde muchas organizaciones todavía tienen visibilidad desigual y controles parciales.

La pregunta no es si este será el último experimento de ransomware de navegador. No lo será. La pregunta que importa es bastante más incómoda: si mañana uno de tus usuarios con privilegios pierde el control efectivo de su navegador mientras mantiene abierta una sesión crítica, ¿tu organización lo detecta como incidente de seguridad, como problema de soporte o como “otra cosa rara del SaaS”?

Ese matiz decide horas. Y en incidentes de este tipo, las horas separan la anécdota cara del desastre regulatorio.