El aviso lo mandó Anthropic, no tu antivirus

El 30 de agosto se supo que Anthropic estaba mandando un correo a algunos usuarios de Claude. Lo resume una frase suya: «hemos sabido recientemente de un actor malicioso que está usando malware infostealer común para robar sesiones de inicio de Claude de los ordenadores de la gente, y después usar esas sesiones para acceder a las cuentas y consumir su uso». La cobertura lo trató como una noticia de inteligencia artificial. No lo es. Si alguien de tu empresa recibió ese correo, lo que tienes delante es un parte de infección de un equipo de tu parque, firmado por un proveedor que ni siquiera es tuyo.

Vendemos automatización e IA y ciberseguridad, así que el interés está declarado desde la primera línea. Por eso empezamos por la parte que nos quita el argumento fácil, y que Anthropic dejó escrita sin ambigüedad: «no tenemos ningún motivo para creer que este malware esté relacionado con Claude, se haya instalado a través de Claude o tenga que ver con nada que hicieras con Claude». Es malware genérico, del que llega con un instalador no oficial o una aplicación maliciosa. No hay agujero en el producto. Y aun así, para bastantes empresas, este va a ser el aviso de seguridad más útil del mes.

Lo que pasó, y por dónde se enteraron

Las familias que Anthropic nombra son las de siempre: Vidar, LummaC2, StealC, RedLine y Acreed en Windows, y Atomic Stealer (AMOS) en macOS, este último en un número pequeño de casos. Lo que copian tampoco es nuevo: contraseñas guardadas, cookies del navegador y credenciales almacenadas en local. Anthropic cerró la sesión a los afectados, revocó las sesiones comprometidas, quitó los métodos de pago guardados de las cuentas, devolvió los cargos que identificó como no autorizados y mantuvo los planes hasta el final del periodo de facturación en curso.

La frase que a nosotros nos parece la más interesante de todo el aviso es esta otra, y no habla de seguridad: «si tus límites de uso parecían recargarse y luego vaciarse mientras tú no estabas usando Claude, esta fue probablemente la causa». Ahí está el sensor. El indicio que hizo saltar todo esto no fue un antivirus, ni una regla de detección, ni un analista mirando telemetría de un equipo. Fue el consumo: cuentas que gastaban a horas en que su dueño no estaba. Un patrón de facturación.

Claude no es el incidente. Es el canario.

Hay otra frase en el aviso que conviene leer dos veces, porque es la que reclasifica el asunto entero: «cerrarte la sesión en Claude detiene las sesiones robadas, pero no elimina el malware». Un infostealer no va a por una cuenta concreta. Va a por el perfil del navegador entero y por lo que haya guardado en el disco. Si el equipo de un empleado tuyo entregó la cookie de Claude, entregó al mismo tiempo todo lo demás que viviera en ese perfil: la sesión de Microsoft 365, el portal de la VPN, el panel del router, el GitLab, el correo web, el gestor de contraseñas si estaba desbloqueado.

Claude es solo el sitio donde el robo se nota, y se nota por una razón tonta: el ladrón gasta. De todas las sesiones que hay en un perfil de navegador de oficina, la de la herramienta de IA es de las pocas que tienen un contador que se vacía. Si te roban la sesión del correo corporativo, nadie va a ver un límite de uso agotándose de madrugada. Por eso este aviso llegó y los otros no. Es el mismo origen que ya vimos en agosto, cuando alguien vendía directorios enteros de Entra con más fichas que empleados: no había ninguna brecha de plataforma, las credenciales se rastrearon hasta infecciones de infostealer en equipos de usuarios. Y en macOS ya contamos cómo llega ese malware sin explotar ninguna vulnerabilidad: lo pega el propio usuario en la Terminal. Lo que este caso añade a lo que ya dijimos al hablar de passkeys no es el diagnóstico —el eslabón se movió al equipo, eso ya estaba dicho— sino la aritmética de lo que pasa después, que es lo que viene ahora.

El MFA no falló: no llegó a jugar

Casi toda la cobertura resume esto como «el robo esquiva el doble factor». Es cierto, pero está mal contado, y el matiz cambia lo que hay que hacer. El MFA no falló. El MFA no llegó a entrar en juego. Una cookie de sesión no es una credencial: es el comprobante de una autenticación que ya ocurrió y que salió bien. El atacante no inicia sesión, así que no hay ningún momento en el que alguien pueda pedirle un segundo factor. Reproduce una sesión que ya estaba iniciada. Es la misma familia de problema que contamos con los tokens de las aplicaciones conectadas a Microsoft 365, con una diferencia importante: allí el token lo concedías tú firmando un consentimiento, y aquí te lo sacan del disco sin preguntarte nada.

Los cinco eventos que cortan una sesión, y el que no está

Si tu identidad corporativa vive en Microsoft Entra, el mecanismo que existe para esto se llama evaluación continua de acceso (CAE). En vez de esperar a que caduque el token, los servicios se suscriben a una lista de eventos críticos y reaccionan casi en tiempo real. La documentación enumera exactamente cinco:

• La cuenta de usuario se borra o se deshabilita.
• Se cambia o se restablece la contraseña del usuario.
• Se activa el MFA para el usuario.
• Un administrador revoca explícitamente todos los refresh tokens del usuario.
• Microsoft Entra ID Protection detecta riesgo de usuario alto.

Ahora lee la lista otra vez buscando «el equipo del usuario está infectado». No está. No existe un evento crítico que signifique «esta máquina está entregando cookies». La única puerta por la que ese hecho puede entrar es la quinta, el riesgo de usuario alto, y esa puerta hay que abrirla: o lo deduce ID Protection por su cuenta, o alguien lo marca. Dicho de otra forma, y es nuestra lectura, no una cita: el estado que de verdad importa aquí no es un estado que el emisor de tokens conozca por sí solo. Alguien tiene que contárselo. Si nadie se lo cuenta, el token sigue siendo válido porque, desde donde mira Entra, no ha pasado nada.

La aritmética de la revocación, sin adornos

Los números están todos publicados y conviene tenerlos juntos, porque casi nadie los pone en la misma frase. Sin CAE, la vida por defecto de un token de acceso es de una hora. Con CAE, ese token pasa a ser de larga duración, hasta veintiocho horas, precisamente porque la revocación deja de depender del reloj y pasa a depender de los eventos. La respuesta a un evento crítico se describe como «casi en tiempo real», con una latencia declarada de hasta quince minutos por el tiempo de propagación (la aplicación de políticas de ubicación por IP sí es instantánea). Y la implementación inicial, dice la propia documentación, se centra en Exchange, Teams y SharePoint Online.

Aquí está el detalle que echa abajo el plan de mucha gente. Lo primero que hace casi todo el mundo cuando sospecha de una cuenta es sacar a esa persona de un grupo o meterle una política nueva de acceso condicional. Pues bien: la documentación dice que los cambios en políticas de acceso condicional y en pertenencia a grupos pueden tardar hasta un día en ser efectivos, por replicación entre Entra y los proveedores de recurso, con una optimización que baja a dos horas los cambios de política y que, dicho por la propia documentación, todavía no cubre todos los escenarios. Lo único que corta hoy es revocar la sesión a propósito: el botón «Revocar sesión» de la ficha del usuario o el comando Revoke-MgUserSignInSession. Y tres avisos más de la letra pequeña: CAE no soporta cuentas de invitado —o sea, los externos: el consultor, la agencia, tu propio proveedor de IT—; si la suma de rangos IP de tus ubicaciones con nombre supera los 5.000, CAE deja de aplicar el cambio de ubicación en tiempo real y vuelve a emitir un token de una hora (aunque sigue aplicando el resto de eventos y políticas); y SharePoint Online, según la misma página, no admite los eventos de riesgo de usuario, que era justo la quinta puerta de la lista de antes.

La defensa específica existe. Mira dónde está.

Contra exactamente este ataque —reproducir un token robado desde otra máquina— Microsoft tiene un control que se llama Token Protection. La idea es buena y es la correcta: cuando un usuario registra un dispositivo compatible, se emite un Primary Refresh Token ligado criptográficamente a ese dispositivo, de manera que aunque un atacante robe el token no puede usarlo desde otro equipo. Con Token Protection activo, Entra solo acepta esos tokens de sesión ligados al dispositivo.

Ahora la parte honesta, que sale de la misma página de documentación, actualizada en agosto de 2026. Token Protection está en disponibilidad general para aplicaciones nativas en Windows, iOS/iPadOS y macOS, y los recursos donde se puede exigir son Exchange Online, SharePoint Online y Teams (en Windows, además, Azure Virtual Desktop y Windows 365). Para aplicaciones de navegador está en vista previa en Windows y macOS, y limitada a determinadas aplicaciones web que acceden a Azure Resource Manager, con requisitos adicionales de sistema operativo, navegador y extensión. En iOS/iPadOS, el navegador directamente no está soportado. Y un matiz que la propia página deja ver: el apartado de dispositivos compatibles titula el bloque de Apple como «vista previa» y exige macOS 14 o superior, o iOS 16 o superior, con el complemento Enterprise SSO de Microsoft y solo en dispositivos gestionados por MDM.

Pon esas dos frases al lado de lo que pasó. El robo fue en el navegador. La defensa diseñada exactamente contra este ataque está generalmente disponible en el sitio donde el robo no ocurrió, y en vista previa, con lista de aplicaciones, en el sitio donde sí ocurrió. No es una crítica a Microsoft, que además recomienda desplegarlo en modo solo informe antes de exigirlo: es la foto real de agosto de 2026, y conviene tenerla delante antes de prometerle a nadie —o a un comité— que esto está resuelto con una casilla. Y esa foto solo cubre las aplicaciones de tu directorio; el robo de Claude, si la suscripción es personal, cae fuera del encuadre entero.

¿Cuántas cuentas de IA hay en tu empresa que tú no puedas cerrar?

Esta es la pregunta que nos parece que deja el caso, y no va de Claude ni de ningún fabricante en concreto. Va del inventario. Hazte estas cuatro, con papel:

• ¿Están esas suscripciones a nombre de la empresa y dentro de tu directorio, o las pagó alguien con su tarjeta y su correo personal?
• Si mañana tienes que cortarle el acceso a esa persona, ¿tienes el botón, o tienes que pedírselo por favor?
• Si le roban la sesión, ¿quién se entera, y por dónde? En este caso se enteró el proveedor, y se enteró por el consumo. Tú te enteraste porque te reenviaron un correo.
• ¿Qué hay pegado en ese historial de conversaciones? Un fragmento de configuración, un log con nombres de servidor, una tabla de precios, el borrador de un contrato. Nada de eso es secreto de estado, y todo eso lo pega gente normal para que le ayuden con su trabajo.

Nada de esto es un ataque a la IA en la empresa. Nosotros la usamos y la montamos: parte de nuestra propia automatización interna corre sobre n8n autoalojado. Y por eso mismo ya escribimos sobre el piloto de IA que nadie apagó, que acaba en producción sin dueño porque nadie decidió nunca que lo fuera. Esto es exactamente lo mismo, pero de la cuenta en vez del servidor: lo que entra por la puerta de atrás no se inventaría, y lo que no se inventaría no se puede apagar.

A quién no le pide casi nada

Lo decimos aunque no nos convenga. Si tus herramientas de IA están contratadas a nombre de la empresa, entran por inicio de sesión único y sus cuentas viven en tu directorio, esto es media hora de trabajo y no un proyecto: revocas sesiones de quien haya podido estar infectado, cambias contraseña y le pasas un análisis al equipo. Ya está. No necesitas comprar nada ni llamar a nadie. Si además tenías el correo de Anthropic reenviado a IT en cuestión de minutos, tu problema real de hoy es otro y este artículo no va contigo.

Si tu gente usa cuentas personales, no tienes media hora de trabajo: tienes una conversación pendiente. Y la conversación tampoco se arregla comprando nada, porque el problema no es técnico. La gente no se saca una suscripción por su cuenta para saltarse a IT; se la saca porque la necesita para trabajar y porque pedirla por el canal oficial tarda tres semanas. Si prohíbes sin dar alternativa, lo único que consigues es que la próxima vez no te lo cuenten.

Lo que haríamos el lunes

• Preguntar quién ha recibido ese correo, y preguntarlo sin ánimo de pillar a nadie. La mitad del valor de este ejercicio está en que la gente lo diga sin miedo. Si el que lo cuenta se lleva una bronca, dejas de enterarte a partir del segundo.
• Tratar el equipo como el incidente, no la cuenta. Análisis completo antes de volver a iniciar sesión, que es exactamente el orden que recomienda Anthropic y no es casualidad: si vuelves a entrar en un equipo que sigue infectado, le regalas la sesión nueva.
• Revocar la sesión corporativa a propósito, sin confiar en que caduque sola: «Revocar sesión» en la ficha del usuario o Revoke-MgUserSignInSession. Cambiar la contraseña también sirve, porque es uno de los cinco eventos críticos. Sacar a la persona de un grupo, no: eso puede tardar un día.
• Mirar qué más vivía en ese perfil de navegador, y no solo Microsoft 365. El portal de la VPN, el panel del router, el hosting, el banco, la herramienta de facturación. Es una lista aburrida de escribir y es la que de verdad mide el alcance.
• Escribir la lista de herramientas de IA que usa tu gente, con quién paga cada una. Esta no es urgente y es la única que cambia algo el mes que viene.

Quién dio el aviso

Lo que nos llamó la atención de este caso no es el malware. Hay uno cada semana y la mayoría de las familias de la lista llevan años funcionando. Lo que nos llamó la atención es la cadena de quién se entera de qué. Un equipo de una empresa se infecta. Un proveedor de inteligencia artificial detecta un patrón de gasto raro. Y el aviso aterriza en el buzón personal de un empleado, que decide si lo reenvía o no. En toda esa cadena no aparece ni el departamento de IT de la empresa ni ninguna herramienta suya.

Nos gustaría poder decir que eso es raro. No lo es. Es lo que pasa cuando una parte de las herramientas que usa tu gente se contrata sin pasar por ti: el sensor deja de ser tuyo y pasa a ser la factura de otro. Anthropic hizo bien su parte —avisó, revocó, quitó las tarjetas y devolvió el dinero—, pero Anthropic solo podía ver su trozo, y su trozo era el consumo de su producto. El equipo infectado sigue donde estaba.

Fuentes (consultadas el 31 de agosto de 2026): el texto del aviso de Anthropic, las frases citadas entre comillas, las familias de malware (Vidar, LummaC2, StealC, RedLine y Acreed en Windows; Atomic Stealer en macOS, en un número pequeño de casos), y las acciones de la compañía —cierre de sesión, revocación de sesiones comprometidas, retirada de los métodos de pago guardados, devolución de los cargos no autorizados y continuidad de los planes hasta el final del periodo de facturación— proceden de la cobertura de BleepingComputer del 30 de agosto de 2026 y de la de Security Affairs del 31 de agosto, que reproducen el mismo correo. No hemos recibido ese correo: lo que citamos es lo que esas dos publicaciones reproducen, y lo decimos porque importa. Los cinco eventos críticos, la vida por defecto del token de acceso de una hora, los tokens de larga duración de hasta veintiocho horas en sesiones CAE, la latencia de hasta quince minutos por propagación frente a la aplicación instantánea de las políticas de IP, el foco inicial en Exchange, Teams y SharePoint Online, el retraso de hasta un día en cambios de políticas y de pertenencia a grupos (con optimización a dos horas que no cubre todos los escenarios), las dos formas de revocar la sesión al instante, la falta de soporte para cuentas de invitado, el umbral de 5.000 rangos IP en ubicaciones con nombre (con la advertencia de que CAE sigue aplicando el resto de eventos y políticas) y que SharePoint Online no admite los eventos de riesgo de usuario salen de «Continuous access evaluation in Microsoft Entra» (Microsoft Learn). El funcionamiento de Token Protection, el vínculo criptográfico del Primary Refresh Token con el dispositivo, la disponibilidad general para aplicaciones nativas en Windows, iOS/iPadOS y macOS, los recursos donde puede exigirse, el estado de vista previa para aplicaciones de navegador en Windows y macOS limitado a determinadas aplicaciones web que acceden a Azure Resource Manager, el «Not supported» del navegador en iOS/iPadOS, el encabezado «Apple (Preview)» del apartado de dispositivos compatibles con sus requisitos de macOS 14 o iOS 16, complemento Enterprise SSO y gestión por MDM, y la recomendación de desplegarlo en modo solo informe salen de «How Token Protection Enhances Conditional Access Policies» (Microsoft Learn), página actualizada en agosto de 2026. Son nuestras, y las marcamos como criterio y no como hechos publicados: la reclasificación del aviso como parte de infección de un equipo; la lectura de que el sensor de este caso fue el consumo y no la seguridad; la idea de que Claude es el canario porque el ladrón gasta y por tanto se nota, mientras que en otras sesiones robadas no hay contador que se vacíe; la observación de que «el equipo del usuario está infectado» no figura entre los cinco eventos críticos y que ese estado tiene que contárselo alguien al emisor de tokens; la contraposición entre dónde está generalmente disponible Token Protection y dónde ocurrió el robo; todo el apartado del inventario de cuentas de IA y sus cuatro preguntas; el checklist del lunes; la observación de que la mayoría de esas familias de malware llevan años en circulación; y la lectura final sobre la cadena de quién se entera de qué. Anthropic afirma explícitamente que el malware no guarda relación con Claude y nosotros no insinuamos lo contrario en ningún punto del artículo.