Las contraseñas y la autenticación multifactor protegen el proceso de inicio de sesión. No protegen necesariamente una sesión autenticada del navegador después de completar el inicio de sesión. Esta distinción se ha vuelto importante para las cuentas de IA porque una sesión activa puede conllevar acceso al uso de modelos de pago, conversaciones, material cargado, flujos de trabajo conectados y otras capacidades concedidas a la cuenta.
Anthropic advirtió recientemente a algunos usuarios de Claude que malware infostealer común había copiado sesiones de inicio de sesión activas de equipos infectados. Según la información de BleepingComputer, los atacantes reutilizaron esas sesiones para entrar en cuentas y consumir el uso disponible. Anthropic respondió revocando las sesiones afectadas, cerrando la sesión de los usuarios, eliminando métodos de pago guardados y reembolsando cargos que identificó como no autorizados. La empresa dijo que no tenía motivos para creer que el malware se originara en Claude o fuera consecuencia de usar el servicio.
Esto no se describió como un atacante descifrando contraseñas o superando un desafío MFA. Tras autenticarse correctamente, el navegador normalmente recibe una cookie o un token. El navegador presenta ese artefacto en solicitudes posteriores para que la persona usuaria no tenga que introducir una contraseña y completar MFA en cada página. Si el malware extrae el artefacto y un servicio lo acepta desde otro entorno, el atacante puede heredar un estado ya autenticado.
MITRE ATT&CK clasifica este comportamiento como el uso de una cookie de sesión web robada. Su descripción explica que un adversario puede importar una cookie robada a un navegador bajo su control y utilizar la aplicación como la víctima mientras la sesión siga activa. La técnica puede eludir algunos protocolos MFA porque la sesión subyacente ya superó la autenticación. Microsoft describe el patrón comparable como «pass-the-cookie»: el malware extrae cookies del navegador y un atacante las inserta en otro navegador para superar puntos de control que se aplicarían durante un inicio de sesión nuevo.
Por tanto, es más preciso decir que el robo de sesión puede eludir la necesidad de una contraseña nueva y un desafío MFA. No demuestra que se haya recuperado la contraseña, que el segundo factor se haya vulnerado criptográficamente ni que MFA no tenga valor. MFA sigue bloqueando muchos ataques basados solo en credenciales robadas. El problema es que un artefacto de sesión reutilizable se sitúa después de esas protecciones y puede funcionar temporalmente como una credencial por derecho propio.
La primera respuesta debería ser la contención desde otro dispositivo de confianza. Abra los controles de administración de sesiones del servicio de IA y termine las sesiones desconocidas. Si el servicio ofrece una opción de cierre de sesión global, úsela cuando el alcance sea incierto. La página de sesiones activas de Anthropic permite a los usuarios de Claude revisar dispositivos y navegadores conectados y terminar remotamente las sesiones que no reconocen. Esta acción se dirige directamente al estado de autenticación robado; cambiar solo la contraseña puede no invalidar de inmediato todas las sesiones existentes de todos los servicios.
Después, proteja la vía de recuperación. Revise la cuenta de correo electrónico principal, sus sesiones activas, direcciones de recuperación, números de teléfono de recuperación y métodos de autenticación. El correo electrónico suele controlar los restablecimientos de contraseña de otros servicios, por lo que un atacante que conserve acceso allí puede revertir el trabajo de recuperación posterior. Elimine el acceso de pago guardado cuando sea adecuado, examine compras o consumo sin explicación y comunique la actividad no autorizada mediante el proceso de soporte oficial del proveedor.
A continuación, investigue el equipo afectado antes de crear sesiones de reemplazo en él. La advertencia de Anthropic hizo hincapié en que cerrar la sesión de una persona detiene la sesión robada, pero no elimina el malware. Si el infostealer sigue activo, volver a iniciar sesión simplemente le dará una nueva sesión que copiar. Use herramientas de seguridad de endpoints reputadas y siga el proceso de respuesta a incidentes del propietario del dispositivo o de la organización. Cuando la confianza en la limpieza sea baja, reconstruir el dispositivo desde una fuente de confianza puede proporcionar un límite de recuperación más claro que volver a iniciar sesión y analizar repetidamente.
Solo después de trasladar la recuperación de la cuenta a un entorno de confianza y de abordar el endpoint deben los usuarios restablecer las credenciales expuestas y establecer sesiones nuevas. Las contraseñas almacenadas en el navegador o introducidas mientras el malware estaba activo merecen una revisión que vaya más allá de la cuenta de IA. Los infostealers de uso general están diseñados para recopilar diversos tipos de información disponible localmente; por ello, una advertencia de Claude debe tratarse como evidencia de una vulneración más amplia del dispositivo, no como un problema aislado del uso del modelo.
Los equipos deben ampliar esa revisión según aquello a lo que pudiera acceder la persona afectada. El entorno de un desarrollador puede contener credenciales de repositorios, acceso a la nube, tokens de registros de paquetes, claves API y sesiones de trabajo. El incidente de Claude informado se refería a sesiones de inicio de sesión en navegador; no estableció un compromiso de claves API de Anthropic, consolas de desarrollador, proveedores de identidad empresariales ni de todas las demás credenciales de una máquina infectada. Revisar esos activos es una precaución justificada por la naturaleza del malware generalista que roba información, no una prueba de que se haya tomado cada activo.
Después de la contención, conserve e inspeccione la evidencia que proporcionen los sistemas disponibles. Los registros útiles incluyen historial de sesiones, notificaciones de seguridad, cambios de consumo, compras, detecciones de endpoint, eventos del proveedor de identidad y registros de auditoría administrativa. Microsoft recomienda examinar las cuentas comprometidas en busca de persistencia y modificaciones sospechosas tras un robo de token. Las comprobaciones exactas dependen de la aplicación, pero el principio es duradero: revocar el artefacto detiene una vía de acceso, mientras que la investigación determina si el atacante creó otra.
El informe público de Claude sustenta un conjunto limitado de conclusiones. Los equipos de algunas personas usuarias estaban infectados con infostealers comunes; se recopilaron y abusaron sesiones activas de Claude; y Anthropic aplicó medidas correctivas de cuenta y pagos. El informe identificó varias familias de malware de Windows y un número menor de casos en Mac. También describió el agotamiento inesperado del uso como un síntoma que algunas personas afectadas podían observar.
El informe no revela el número total de usuarios afectados, la ventana completa de abuso, el uso no autorizado total ni el método de detección de la investigación. No establece que los sistemas centrales, los modelos o la base de datos de cuentas de Anthropic fueran vulnerados. Tampoco prueba que los atacantes leyeran historiales de conversaciones, abrieran archivos cargados, usaran conectores o cambiaran la configuración de las cuentas. Una sesión válida puede ofrecer capacidades disponibles para su usuario, pero el posible acceso y la actividad demostrada de un atacante no son la misma afirmación.
Esa cautela importa para las decisiones de seguridad. Subestimar el evento como una mera reutilización de contraseña produciría un orden de recuperación equivocado. Sobrestimarlo como una vulneración de la plataforma identificaría erróneamente el punto de entrada comunicado. La interpretación defendible es que malware de endpoint corrompió la confianza representada por el estado autenticado del navegador y que el abuso resultante se hizo visible dentro del servicio de IA.
Para compradores y administradores, la visibilidad de las sesiones es el primer control de producto que se debe evaluar. ¿Pueden los usuarios ver dispositivos y navegadores activos, ubicaciones aproximadas y actividad reciente? ¿Pueden terminar una sesión sin interrumpir todos los dispositivos? ¿Hay también una opción fiable de cierre de sesión global para incidentes inciertos? ¿Pueden los administradores revocar sesiones de forma centralizada, y es el efecto inmediato en experiencias web, de escritorio, móviles y conectadas?
La semántica de la revocación merece un escrutinio particular. Microsoft señala que revocar un token de actualización no necesariamente invalida de inmediato un token de acceso ya emitido; el acceso puede persistir hasta que ese token expire, a menos que la plataforma admita una aplicación más rápida. Los proveedores de IA no necesitan usar la arquitectura de Microsoft para afrontar la misma cuestión de evaluación: después de que un usuario o administrador pulse «cerrar sesión», ¿qué artefactos de autenticación dejan de funcionar, en qué superficies y con qué rapidez?
La duración de la sesión es otra compensación que examinar. Los artefactos de vida más corta reducen el periodo en que un token copiado es útil, pero también fuerzan más reautenticación y pueden interrumpir el trabajo de larga duración. La reautenticación basada en el riesgo puede proporcionar un límite más selectivo al exigir una comprobación para acciones sensibles, entornos inusuales u operaciones elevadas. Los clientes deben preguntar qué eventos desencadenan una nueva comprobación de autenticación y si los cambios de pagos guardados u otras acciones importantes reciben protección adicional.
La detección y la notificación determinan qué tan pronto pueden funcionar los controles reactivos. Las capacidades útiles incluyen alertas para sesiones desconocidas, ubicaciones inusuales, consumo anormal y cambios en la configuración de seguridad. Ninguna es concluyente por sí sola: los usuarios legítimos viajan, cambian de red, cambian de navegador y varían su uso de IA. Los productos deben combinar señales, conservar un historial de auditoría útil y dar a los usuarios suficiente contexto para distinguir la actividad ordinaria de una sesión que deben revocar.
Las políticas de dispositivos administrados pueden reducir la exposición de cuentas organizativas. Microsoft recomienda visibilidad sobre dónde se autentican los usuarios, controles de cumplimiento de dispositivos para aplicaciones importantes y controles de sesión compensatorios para dispositivos no administrados. Los equipos que evalúan servicios de IA deben determinar si los planes empresariales pueden restringir el acceso a dispositivos conocidos, integrarse con controles de identidad existentes, separar la administración privilegiada del uso rutinario y permitir una contención rápida sin esperar la respuesta de cada empleado.
Las sesiones vinculadas a dispositivos ofrecen una defensa más directa contra la repetición de cookies exportadas. El diseño Device Bound Session Credentials de Google usa una clave privada no exportable respaldada por hardware y cookies de corta duración. El navegador debe demostrar repetidamente la posesión de la clave correspondiente antes de que el servidor emita nuevas cookies de sesión. Por tanto, una cookie copiada a otra máquina debería expirar pronto sin la clave que conserva el dispositivo. Google anunció la disponibilidad pública para usuarios de Windows en Chrome 146 y dijo que la compatibilidad con macOS seguiría en una versión posterior.
Esta protección no es automática ni absoluta. Un servicio debe implementar los endpoints de registro y actualización requeridos, y la compatibilidad del navegador por sí sola no indica que un producto de IA concreto use DBSC. La vinculación a dispositivos está diseñada para dificultar la repetición remota de cookies exportadas; no hace fiable un equipo infectado. El malware que opera en el dispositivo aún puede robar otra información o actuar a través del entorno comprometido. La recuperación, el uso en varios dispositivos, el hardware no compatible y la identidad federada también plantean preguntas de implementación que los compradores deben pedir a los proveedores que expliquen.
La postura de producto más sólida combina capas: protección de endpoints para reducir el robo, sesiones visibles y revocables para contenerlo, ventanas de autenticación más cortas o sensibles al riesgo para limitar su utilidad, detección para identificar el abuso y vinculación a dispositivos para hacer más difícil repetir artefactos exportados. Los procedimientos de soporte claros y la reparación de facturación reducen el daño tras el fallo de los controles, pero deben complementar el diseño preventivo en lugar de sustituirlo.
Para los usuarios de IA, la regla práctica es sencilla: un pico inesperado de uso o una advertencia de sesión puede ser un incidente de endpoint incluso cuando la contraseña y el método MFA parecen no haber cambiado. Revocar el acceso desde un dispositivo limpio, proteger las cuentas de recuperación, investigar el endpoint, rotar las credenciales expuestas y solo entonces crear nuevas sesiones de confianza. Para los equipos, la lección duradera es más amplia: evalúen el estado de sesión autenticada con la misma seriedad que las contraseñas, las claves API y otras credenciales, porque los atacantes ya lo hacen.
Combinamos fuentes primarias, documentación de producto y casos de uso reales para ayudarte a valorar si una herramienta encaja en tu flujo de trabajo.