Storm el infostealer que roba cookies y mantiene sesiones en la nube

A comienzos de 2026 apareció en los mercados clandestinos un nuevo infostealer llamado Storm, y su llegada no es solo la de otro programa malicioso más: supone una evolución en la forma en que los atacantes roban credenciales y secuestran sesiones. Según el análisis publicado por Varonis, Storm se oferta como servicio por suscripciones mensuales y por precios que, en su paquete estándar, quedan por debajo de los 1.000 dólares, ofreciendo a los operadores la capacidad de recolectar credenciales de navegadores, cookies de sesión, tokenes de cuentas de Google y carteras de criptomonedas, y luego enviar todos esos datos cifrados a infraestructura controlada por el atacante para su descifrado y explotación posterior (análisis de Varonis).

Para comprender la importancia de este cambio hay que remontarse al modo clásico de operación de los stealers. Tradicionalmente estas herramientas intentaban descifrar las credenciales directamente en la máquina comprometida, abriendo las bases locales de los navegadores (por ejemplo, usando bibliotecas SQLite) y manipulando los almacenes locales de contraseñas. Ese comportamiento local —el acceso directo a las bases de datos del navegador y la carga de librerías para desencriptar— era uno de los indicadores que las soluciones de endpoint empezaron a detectar con eficacia.

Con el tiempo las defensas evolucionaron y la industria del navegador también introdujo protecciones adicionales. Un ejemplo citado por los investigadores fue la introducción de mecanismos que atan claves de cifrado a la propia aplicación del navegador, lo que dificultó aún más la desencriptación local sin interactuar con el proceso del navegador. Los primeros intentos de evitar esa restricción implicaron inyectar código en el proceso del navegador o abusar de sus protocolos de depuración, técnicas que seguían dejando huella y podían ser detectadas por herramientas de seguridad. Frente a ello, los desarrolladores de stealers cambiaron de táctica: dejaron de intentar desencriptar localmente y empezaron a enviar los archivos cifrados a servidores externos para que todo el tratamiento ocurriera fuera del endpoint, eliminando así muchas de las telemetrías que las EDR/AV usan para identificar un robo de credenciales.

Storm lleva esa idea un paso más allá. Según el informe, el proyecto realiza el descifrado y el procesamiento server-side tanto para navegadores basados en Chromium como para los basados en Gecko (Firefox, Waterfox, Pale Moon), mientras que otras familias como StealC V2 todavía realizan parte del procesamiento en la máquina víctima. El repertorio de datos que Storm recoge es amplio: contraseñas guardadas, cookies de sesión, formularios y autofill, tokens de Google, datos de tarjetas, historial de navegación, documentos desde directorios del usuario y hasta sesiones de mensajería de aplicaciones como Telegram, Signal y Discord. También incluye objetivos apetecibles para ciberdelincuentes, como extensiones y aplicaciones de escritorio de monederos de criptomonedas, capturas de pantalla en varias pantallas y recolección de información del sistema. Gran parte de ese trabajo se realiza en memoria para reducir la posibilidad de detección.

Una de las capacidades que hace a Storm particularmente peligrosa es la automatización del paso siguiente a la recolección: en lugar de entregar a los compradores un volcado de credenciales y pedirles que las reutilicen manualmente, la herramienta vuelca los datos descifrados en un panel del operador y ofrece funciones que facilitan la restauración silenciosa de sesiones. Con un token de refresco de Google y un proxy SOCKS5 cuyo origen geográfico coincida razonablemente con la víctima, el panel puede recrear la sesión autenticada sin necesidad de introducir contraseñas, lo que convierte la cookie o el token robado en acceso persistente y fiable. Investigaciones previas de Varonis, como Cookie-Bite y SessionShark, ya habían mostrado cómo las cookies y tokens robados pueden hacer irrelevante el factor de autenticación adicional y permitir accesos sostenidos a servicios en la nube.

En cuanto a la arquitectura y la operación, Storm propone un modelo en el que cada operador conecta sus propios servidores virtuales a la infraestructura central del servicio, haciendo que los datos robados pasen primero por nodos controlados por los compradores antes de alcanzar el backend. Esa topología complica las acciones de derribo por parte de las fuerzas de seguridad, porque las denuncias o bloqueos se encuentran primero con hosts controlados por el operador. El panel de gestión incluye funciones orientadas a operaciones criminales: control de equipos con permisos granulares, reglas de detección automática por dominio que etiquetan credenciales por servicio (Google, Facebook, Twitter/X, cPanel, intercambios de criptomonedas) y mecanismos para priorizar objetivos. En las imágenes del panel analizadas por Varonis aparecían miles de registros procedentes de múltiples países y credenciales asociadas a intercambios de criptomonedas, redes sociales y servicios en la nube, lo que sugiere campañas activas y transaccionales donde esos datos acaban en mercados de credenciales.

El modelo comercial es igualmente preocupante desde la perspectiva de accesibilidad: Storm se oferta en distintos niveles, incluyendo una demo de corta duración y suscripciones mensuales estándar y para equipos, con precios que facilitan que pequeños grupos delictivos puedan operar con capacidades sofisticadas. Además, las compilaciones desplegadas continúan funcionando aun cuando la suscripción del operador expira, por lo que el impacto no desaparece automáticamente con la cancelación del servicio.

Frente a este panorama, la respuesta defensiva debe evolucionar. Los enfoques que se basan únicamente en la detección de actividad de descifrado local o en la protección per-endpoint dejan zonas ciegas cuando el procesamiento ocurre fuera del dispositivo comprometido. Por eso es esencial complementar esas defensas con controles que protejan las sesiones y detecten uso anómalo de credenciales. Implementar políticas de acceso condicional que exijan comprobaciones de integridad del dispositivo, ubicación y riesgo antes de permitir acciones sensibles, limitar la duración y el alcance de los tokens de refresco, y forzar re-autenticación para operaciones críticas ayuda a reducir la ventana de explotación. Los equipos de seguridad además deben priorizar la correlación de logs y el análisis de comportamiento de cuentas y dispositivos para identificar patrones como inicios de sesión desde ubicaciones incompatibles con la actividad previa o repeticiones de sesión desde proxies inusuales. Para referencia sobre buenas prácticas de gestión de sesiones, la comunidad tiene recursos como la guía de OWASP sobre gestión de sesiones (OWASP Session Management Cheat Sheet) y las recomendaciones de identidad de NIST (NIST SP 800-63B).

En el nivel operativo conviene revisar la telemetría de red y egress para detectar envíos inusuales de archivos cifrados hacia servidores externos y patrones de conexión que indiquen el uso de proxies o VPS recién provisionados. La telemetría de comportamiento de endpoints sigue siendo útil si se amplía para identificar actividades relacionadas (por ejemplo, procesos que crean muchos ficheros temporales en memoria, accesos concurrentes a múltiples perfiles de navegador o capturas de pantalla que coinciden con accesos recientes a cuentas sensibles). El uso de capacidades UEBA y detección basada en anomalías puede ayudar a descubrir accesos “legítimos” que no encajan con el historial de la cuenta y así bloquear o requerir verificación adicional. Microsoft y otros proveedores publican guías sobre cómo aplicar controles de acceso condicional y proteger tokens en entornos empresariales; estos controles son complementarios a la protección perimetral y per-endpoint (documentación de Azure AD Conditional Access).

La lección para las organizaciones es clara: el hecho de que un usuario no haya cambiado su contraseña ni haya recibido una notificación de fallo de login no implica que su sesión no haya sido comprometida. El robo de cookies y tokens permite movimientos laterales y accesos persistentes sin disparar alertas de contraseña, por lo que las defensas deben centrarse tanto en proteger los secretos como en validar el contexto y la integridad de cada sesión. En práctica, eso significa políticas de corto plazo y rotación para tokens, aplicación de controles de acceso más estrictos para recursos críticos, segmentación de privilegios, monitorización de uso anómalo de cuentas y una capacidad de respuesta que incluya la invalidación de sesiones comprometidas y la investigación de nodos sospechosos de egress.

Storm no es un caso aislado sino la manifestación de una tendencia: la externalización del trabajo de descifrado y la priorización del robo de sesiones por encima del robo directo de contraseñas. Ante ese escenario, las empresas que confían únicamente en la resistencia de las contraseñas y en controles endpoint tradicionales estarán en desventaja frente a atacantes que ya están comercializando automatización para restaurar sesiones robadas. Una estrategia defensiva moderna debe combinar buenas prácticas de gestión de identidades, controles de acceso adaptativos y monitorización avanzada de comportamiento para cerrar las vías que estas herramientas explotan.

Este artículo se basa en el informe técnico publicado por Varonis sobre el infostealer Storm y en investigaciones anteriores sobre robo de cookies y tokens (informe original en Varonis, Cookie-Bite, SessionShark). Para profundizar en estándares y recomendaciones sobre gestión de sesiones y autenticación, puede consultarse la guía de OWASP y la publicación NIST mencionadas arriba.