Senhas e autenticação multifator protegem o processo de entrada. Elas não protegem necessariamente uma sessão autenticada do navegador depois que o login é concluído. Essa distinção se tornou importante para contas de IA porque uma sessão ativa pode incluir acesso ao uso pago de modelos, conversas, materiais enviados, fluxos de trabalho conectados e outras capacidades concedidas à conta.
A Anthropic alertou recentemente alguns usuários do Claude de que malware infostealer comum havia copiado sessões de login ativas de computadores infectados. Segundo a reportagem da BleepingComputer, atacantes reutilizaram essas sessões para entrar em contas e consumir o uso disponível. A Anthropic respondeu revogando as sessões afetadas, desconectando usuários, removendo métodos de pagamento salvos e reembolsando cobranças que identificou como não autorizadas. A empresa afirmou não ter motivo para acreditar que o malware tenha se originado no Claude ou resultado do uso do serviço.
Isso não foi descrito como um invasor quebrando senhas ou vencendo um desafio de MFA. Depois que o usuário é autenticado com sucesso, o navegador normalmente recebe um cookie ou token. O navegador apresenta esse artefato em solicitações posteriores para que o usuário não precise digitar a senha e concluir MFA em cada página. Se o malware extrai o artefato e um serviço o aceita a partir de outro ambiente, o atacante pode herdar um estado já autenticado.
O MITRE ATT&CK classifica esse comportamento como uso de um cookie de sessão web roubado. Sua descrição explica que um adversário pode importar um cookie roubado para um navegador sob seu controle e usar o aplicativo como a vítima enquanto a sessão permanecer ativa. A técnica pode contornar alguns protocolos de MFA porque a sessão subjacente já passou pela autenticação. A Microsoft descreve o padrão comparável como “pass-the-cookie”: o malware extrai cookies do navegador, e um atacante os insere em outro navegador para passar por verificações que se aplicariam durante um novo login.
Portanto, é mais preciso dizer que o roubo de sessão pode contornar a necessidade de uma nova senha e de um desafio MFA. Isso não prova que a senha foi recuperada, que o segundo fator foi quebrado criptograficamente ou que MFA não tem valor. MFA continua bloqueando muitos ataques baseados apenas em credenciais roubadas. O problema é que um artefato de sessão reutilizável fica a jusante dessas proteções e pode temporariamente funcionar como uma credencial por si só.
A primeira resposta deve ser a contenção a partir de outro dispositivo confiável. Abra os controles de gerenciamento de sessão do serviço de IA e encerre sessões desconhecidas. Se o serviço oferecer uma opção de desconexão global, use-a quando o escopo for incerto. A página de sessões ativas da Anthropic permite que usuários do Claude revisem dispositivos e navegadores conectados e encerrem remotamente sessões que não reconhecem. Essa ação atinge diretamente o estado de autenticação roubado; mudar apenas a senha pode não invalidar imediatamente todas as sessões existentes em todos os serviços.
Em seguida, proteja o caminho de recuperação. Revise a conta de e-mail principal, suas sessões ativas, endereços de recuperação, números de telefone de recuperação e métodos de autenticação. O e-mail frequentemente controla redefinições de senha de outros serviços; por isso, um atacante que mantenha acesso ali pode reverter o trabalho posterior de recuperação. Remova acesso de pagamento salvo quando apropriado, examine compras ou consumo sem explicação e denuncie atividade não autorizada pelo processo oficial de suporte do provedor.
Depois, investigue o computador afetado antes de criar sessões substitutas nele. O alerta da Anthropic enfatizou que desconectar um usuário interrompe a sessão roubada, mas não remove o malware. Se o infostealer continuar ativo, entrar novamente apenas lhe dará uma nova sessão para copiar. Use ferramentas reputadas de segurança de endpoint e siga o processo de resposta a incidentes do proprietário do dispositivo ou da organização. Quando a confiança na limpeza for baixa, reconstruir o dispositivo a partir de uma fonte confiável pode oferecer uma fronteira de recuperação mais clara do que entrar novamente e escanear repetidamente.
Somente depois de mover a recuperação da conta para um ambiente confiável e tratar o endpoint os usuários devem redefinir credenciais expostas e estabelecer novas sessões. Senhas armazenadas no navegador ou inseridas enquanto o malware estava ativo merecem revisão além da conta de IA. Infostealers de uso geral são construídos para coletar vários tipos de informações disponíveis localmente; portanto, um alerta do Claude deve ser tratado como evidência de um comprometimento mais amplo do dispositivo, não como um problema isolado de uso do modelo.
As equipes devem ampliar essa revisão conforme aquilo a que a pessoa afetada poderia acessar. O ambiente de um desenvolvedor pode conter credenciais de repositórios, acesso à nuvem, tokens de registros de pacotes, chaves de API e sessões de trabalho. O incidente relatado do Claude dizia respeito a sessões de login no navegador; ele não estabeleceu o comprometimento de chaves de API da Anthropic, consoles de desenvolvedor, provedores corporativos de identidade ou todas as demais credenciais em uma máquina infectada. Revisar esses ativos é uma precaução justificada pela natureza do malware de roubo de informações de uso geral, não uma prova de que cada ativo foi levado.
Após a contenção, preserve e inspecione as evidências fornecidas pelos sistemas disponíveis. Registros úteis incluem histórico de sessões, notificações de segurança, alterações de consumo, compras, detecções de endpoint, eventos do provedor de identidade e logs administrativos de auditoria. A Microsoft recomenda examinar contas comprometidas em busca de persistência e modificações suspeitas após roubo de token. As verificações exatas dependem do aplicativo, mas o princípio é durável: revogar o artefato interrompe um caminho de acesso, enquanto a investigação determina se o atacante criou outro.
O relatório público do Claude sustenta um conjunto limitado de conclusões. Os computadores de alguns usuários estavam infectados por infostealers comuns; sessões ativas do Claude foram coletadas e abusadas; e a Anthropic aplicou remediação de conta e pagamento. O relatório identificou várias famílias de malware do Windows e um número menor de casos em Mac. Também descreveu a redução inesperada de uso como um sintoma que alguns usuários afetados poderiam observar.
O relatório não divulga o número total de usuários afetados, a janela completa de abuso, o uso não autorizado total ou o método de detecção da investigação. Ele não estabelece que os sistemas centrais, modelos ou banco de dados de contas da Anthropic tenham sido violados. Tampouco prova que atacantes leram históricos de conversa, abriram arquivos enviados, usaram conectores ou alteraram configurações de conta. Uma sessão válida pode oferecer capacidades disponíveis para seu usuário, mas possível acesso e atividade de atacante demonstrada não são a mesma alegação.
Essa contenção importa para decisões de segurança. Subestimar o evento como mera reutilização de senha produziria a ordem errada de recuperação. Superestimá-lo como uma violação de plataforma identificaria incorretamente o ponto de entrada relatado. A interpretação defensável é que malware de endpoint corrompeu a confiança representada pelo estado autenticado do navegador, e o abuso resultante se tornou visível dentro do serviço de IA.
Para compradores e administradores, a visibilidade de sessão é o primeiro controle de produto a avaliar. Os usuários conseguem ver dispositivos e navegadores ativos, localizações aproximadas e atividade recente? Conseguem encerrar uma sessão sem interromper todos os dispositivos? Há também uma opção confiável de desconexão global para incidentes incertos? Administradores podem revogar sessões centralmente, e o efeito é imediato em experiências web, desktop, móveis e conectadas?
A semântica da revogação merece atenção especial. A Microsoft observa que revogar um token de atualização não necessariamente invalida imediatamente um token de acesso já emitido; o acesso pode persistir até que esse token expire, a menos que a plataforma suporte aplicação mais rápida. Fornecedores de IA não precisam usar a arquitetura da Microsoft para enfrentar a mesma questão de avaliação: depois que um usuário ou administrador pressiona “sair”, quais artefatos de autenticação deixam de funcionar, em quais superfícies e com que rapidez?
A vida útil da sessão é outra troca a examinar. Artefatos de vida mais curta reduzem o período em que um token copiado é útil, mas também exigem mais reautenticação e podem interromper trabalho de longa duração. A reautenticação baseada em risco pode oferecer uma fronteira mais seletiva, exigindo verificação para ações sensíveis, ambientes incomuns ou operações elevadas. Os clientes devem perguntar quais eventos disparam uma nova verificação de autenticação e se alterações de pagamentos salvos ou outras ações consequentes recebem proteção adicional.
Detecção e notificação determinam quão rapidamente os controles reativos podem operar. Capacidades úteis incluem alertas para sessões desconhecidas, locais incomuns, consumo anormal e alterações nas configurações de segurança. Nenhuma delas é conclusiva por si só: usuários legítimos viajam, mudam de rede, trocam de navegador e variam seu uso de IA. Os produtos devem combinar sinais, reter histórico de auditoria útil e dar aos usuários contexto suficiente para distinguir atividade comum de uma sessão que devem revogar.
Políticas de dispositivos gerenciados podem reduzir a exposição de contas organizacionais. A Microsoft recomenda visibilidade sobre onde os usuários se autenticam, controles de conformidade de dispositivos para aplicações importantes e controles compensatórios de sessão para dispositivos não gerenciados. Equipes que avaliam serviços de IA devem determinar se os planos empresariais podem restringir o acesso a dispositivos conhecidos, integrar-se aos controles de identidade existentes, separar a administração privilegiada do uso rotineiro e apoiar contenção rápida sem esperar a resposta de cada funcionário.
Sessões vinculadas ao dispositivo oferecem uma defesa mais direta contra a repetição de cookies exportados. O design Device Bound Session Credentials do Google usa uma chave privada não exportável, apoiada por hardware, e cookies de curta duração. O navegador deve provar repetidamente a posse da chave correspondente antes que o servidor emita novos cookies de sessão. Assim, um cookie copiado para outra máquina deve expirar rapidamente sem a chave mantida pelo dispositivo. O Google anunciou disponibilidade pública para usuários do Windows no Chrome 146 e disse que o suporte ao macOS viria em uma versão posterior.
Essa proteção não é automática nem absoluta. Um serviço precisa implementar os endpoints necessários de registro e atualização, e o suporte do navegador por si só não mostra que um produto de IA específico usa DBSC. A vinculação ao dispositivo é projetada para dificultar a repetição remota de cookies exportados; ela não torna confiável um computador infectado. Malware operando no dispositivo ainda pode roubar outras informações ou agir por meio do ambiente comprometido. Recuperação, uso em vários dispositivos, hardware não suportado e identidade federada também criam questões de implantação que os compradores devem pedir aos fornecedores que expliquem.
A postura de produto mais forte combina camadas: proteção de endpoint para reduzir roubo, sessões visíveis e revogáveis para contê-lo, janelas de autenticação mais curtas ou sensíveis a risco para limitar a utilidade, detecção para identificar abuso e vinculação ao dispositivo para tornar artefatos exportados mais difíceis de repetir. Procedimentos claros de suporte e remediação de cobrança reduzem danos após falhas de controles, mas devem complementar o design preventivo, não substituí-lo.
Para usuários de IA, a regra prática é simples: um pico inesperado de uso ou um aviso de sessão pode ser um incidente de endpoint mesmo quando a senha e o método MFA parecem inalterados. Revogue o acesso a partir de um dispositivo limpo, proteja contas de recuperação, investigue o endpoint, altere credenciais expostas e só então crie novas sessões confiáveis. Para equipes, a lição duradoura é mais ampla: avaliem o estado de sessão autenticada com a mesma seriedade de senhas, chaves de API e outras credenciais, porque os atacantes já o fazem.
Combinamos fontes primárias, documentação de produtos e cenários reais de uso para ajudar você a avaliar se uma ferramenta combina com seu fluxo de trabalho.