Le robaron la sesión, no la contraseña

No fue una brecha de Anthropic. Ese es el primer dato y conviene decirlo antes que cualquier otro, porque el titular fácil es el contrario.

Este fin de semana Anthropic empezó a enviar correos a usuarios de Claude con un aviso incómodo: un actor malicioso está usando malware infostealer común para robar sesiones de Claude desde las computadoras de las personas, y con esas sesiones entra a las cuentas y consume los límites de uso. Las palabras son de la empresa. Las familias de malware identificadas hasta ahora son Vidar, Lumma, StealC, RedLine y Acreed en Windows, y Atomic Stealer en un número pequeño de Mac. La respuesta de Anthropic fue cerrar las sesiones de los afectados, eliminar los métodos de pago guardados y devolver los cargos no autorizados. Y una advertencia que casi nadie destacó: cerrar sesión invalida lo robado, pero no quita el malware del equipo.

Ninguno de esos programas es nuevo ni sofisticado. Son ladrones de credenciales que se venden por suscripción, que llegan por software pirata, por instaladores falsos, por un crack de algo. Llevan años haciendo lo mismo: barren contraseñas guardadas, historial y cookies del navegador, y lo empaquetan en un archivo que se vende por lotes. Lo nuevo no es el malware. Lo nuevo es lo que encontraron adentro.

Lo que realmente se robaron

Una cookie de sesión no es una contraseña. Es la prueba de que alguien ya se autenticó. Cuando usted entra a un servicio y pasa el segundo factor, el servidor le entrega un token que dice, en efecto, «esta persona ya demostró quién es, déjenla pasar». Ese token vive en el navegador y viaja en cada petición. Quien lo tiene, es usted.

Por eso el detalle que más me interesa de este caso es el que suena aburrido: el atacante nunca tocó la infraestructura de Anthropic. No hubo exploit, no hubo vulnerabilidad en el proveedor, no hubo escalada de privilegios. Hubo una laptop con malware y un archivo de cookies. El segundo factor no falló; simplemente ya se había cumplido, y el token que lo certificaba estaba guardado en disco.

Esto rompe una suposición que muchos equipos todavía tienen escrita en su política de seguridad: que activar MFA cierra el tema del acceso. MFA protege el momento de la autenticación. No protege la sesión que nace de ella. Si la sesión dura semanas, si sobrevive a cambios de dispositivo, si no está atada a nada verificable del cliente, entonces el segundo factor es una puerta blindada al costado de una ventana abierta.

Por qué esto pega distinto en 2026

Hace tres años, robarle a alguien la sesión de una herramienta de IA era robarle un chat. Hoy es otra cosa. La cuenta de un proveedor de modelos suele tener, colgando de ella, claves de API, repositorios conectados, integraciones con el correo y el calendario, contexto de proyectos internos y un método de pago con límite de gasto. El daño de este incidente concreto fue económico y acotado: consumo de cuota ajeno. El daño posible es de otra categoría.

Y hay una asimetría que no se discute lo suficiente. El proveedor puede reaccionar, y Anthropic reaccionó bien: invalidó sesiones, quitó los medios de pago, devolvió el dinero. Pero reaccionar es todo lo que puede hacer. La causa raíz estaba fuera de su perímetro, en un equipo que no administra, con un usuario que quizá instaló algo que no debía. Ningún acuerdo de nivel de servicio cubre eso. Ninguna certificación del proveedor lo evita.

Al mismo tiempo, el ecosistema abierto se está moviendo en la dirección contraria. El mismo fin de semana, OpenClaw publicó su versión dos punto cero con más de dieciséis mil pull requests fusionados, y el cambio que a mí me pareció más relevante no fue de producto sino de arquitectura: una sola frontera de confianza por gateway. Es decir, dejar de asumir que un agente con acceso a todo es aceptable porque el usuario ya se autenticó una vez. Es la misma pregunta que este incidente pone sobre la mesa, respondida desde el otro lado.

Qué haría yo si dirijo tecnología en una empresa

Tres cosas concretas, en este orden.

Primero, acortar la vida de las sesiones en todo lo que tenga capacidad de gastar dinero o de leer código. No en todo: acortar sesiones en herramientas triviales solo genera fricción y usuarios que buscan atajos. En las que importan, sí, y con reautenticación obligatoria ante cambios de contexto.

Segundo, tratar el endpoint como parte del perímetro de la IA, no como un tema aparte del área de soporte. Si el equipo de una persona está comprometido, todas sus sesiones lo están, sin importar qué tan bien esté configurado el proveedor. Eso incluye una conversación adulta sobre software pirata en equipos de trabajo, que es la vía de entrada clásica de esta familia de malware.

Tercero, inventariar qué cuelga de cada cuenta de IA. La mayoría de las empresas no sabe responder qué pasa si mañana alguien entra con la sesión de su desarrollador senior. Esa respuesta debería ser corta y aburrida, no una investigación.

Mi lectura

El incidente en sí es menor: cuota consumida, cargos devueltos, sesiones cerradas. Lo que me parece que marca es otra cosa. Durante dos años la conversación sobre seguridad e IA fue casi toda sobre el modelo: inyección de prompts, fuga de datos de entrenamiento, alucinaciones con consecuencia. Este caso no tiene nada que ver con el modelo. Es identidad, sesiones y gestión de endpoints, tres disciplinas viejas y poco glamorosas, aplicadas a un activo nuevo.

Cuando en Indrox revisamos la postura de seguridad de un cliente que está adoptando IA, la parte difícil casi nunca es el modelo. Es que nadie sabe cuántas sesiones activas hay, dónde viven y qué pueden tocar. Este fin de semana ese problema dejó de ser hipotético y tuvo factura.