A maioria de nós pensa numa invasão de conta como alguém adivinhando ou roubando uma senha. Mas um padrão que vem aparecendo em vários incidentes recentes funciona de forma diferente: o invasor nunca chega a tocar na sua senha. Em vez disso, ele faz você entregar algo que funciona como uma chave reserva para uma conta na qual você já está logado — um dispositivo vinculado, um token de autorização, uma sessão — e passa direto pelas trancas nas quais você normalmente confiaria.

Dois exemplos tornam o mecanismo concreto. Pesquisadores de segurança descreveram recentemente um golpe no WhatsApp que se espalha a partir de contas já sequestradas, no qual uma mensagem pede que você "vote" num amigo em um concurso. Ela leva você por uma página que imita a configuração de "dispositivo vinculado" do WhatsApp, ou instrui você a digitar um código no seu próprio menu de dispositivos vinculados. Completar esse fluxo adiciona o telefone do invasor como um segundo dispositivo, totalmente autorizado, na sua conta — com acesso total de leitura e envio — sem que ele precise digitar uma senha em momento algum. Como a senha nunca foi tocada, você não recebe nenhum e-mail de redefinição de senha nem alerta de tentativa de login malsucedida. A sessão fraudulenta simplesmente fica ali, quieta, na sua lista de dispositivos, como mais uma entrada.

Separadamente, a Microsoft alertou sobre uma campanha que abusa dos portais cativos de Wi-Fi de hotéis e conferências — aquela página de "aceitar os termos" que você vê ao se conectar. Invasores posicionados no caminho da rede redirecionam as vítimas para páginas de login falsas ou falsos avisos de "código do dispositivo" que, uma vez concluídos, entregam tokens de autorização em vez de senhas. O efeito é o mesmo: uma sessão que parece legítima para o serviço, porque tecnicamente ela é — só que agora pertence a outra pessoa.

Por que suas defesas habituais não detectam isso

Um gerenciador de senhas protege a senha. A autenticação de dois fatores protege o momento do login. Nenhum dos dois está observando o que acontece depois que uma sessão ou dispositivo é autorizado, que é exatamente a brecha para a qual esses ataques foram criados. A única forma confiável de detectar essa categoria de comprometimento é verificar periodicamente, à mão, quais dispositivos e aplicativos têm atualmente acesso permanente às suas contas — em vez de esperar por um alerta que esses ataques são especificamente projetados para não disparar.

A auditoria de sessões de 15 minutos

Faça isso para as contas mais importantes (e-mail, WhatsApp/Telegram, banco e qualquer coisa ligada à sua identidade ou dinheiro) e configure um lembrete recorrente para repetir o processo. Onde os nomes dos menus mudarem com o tempo, procure por termos como "dispositivos", "sessões" ou "aplicativos conectados":

  • WhatsApp: Configurações → Dispositivos conectados. Qualquer coisa que você não reconheça, toque nela e encerre a sessão imediatamente.
  • Google: myaccount.google.com/security → "Seus dispositivos" e, separadamente, "Apps e serviços de terceiros" (às vezes chamado de "Fazer login com o Google"). Revogue o acesso de tudo que você não usa ativamente.
  • Conta Microsoft: account.microsoft.com/devices para a lista de dispositivos; account.microsoft.com/activity para o histórico de logins.
  • Apple ID: Ajustes → [seu nome] em um iPhone/iPad, ou Ajustes do Sistema em um Mac, mostra todos os dispositivos conectados ao seu Apple ID.
  • Facebook/Instagram (Meta): Configurações → Central de Contas → Senha e segurança → Onde você está conectado.
  • Aplicativos bancários e financeiros: a maioria tem uma tela de "gerenciar dispositivos" ou "sessões ativas" nas configurações de segurança, embora a redação varie de instituição para instituição — confira a sua agora para já saber onde encontrar quando precisar.

Enquanto estiver nesses menus, dê uma olhada também em qualquer lista de "aplicativos conectados" ou de permissões OAuth — aplicativos antigos e extensões de navegador que você autorizou anos atrás e esqueceu são exatamente o tipo de acesso permanente que essa classe de ataque tenta criar do zero.

Se você encontrar algo que não reconhece

Remova ou encerre a sessão do dispositivo ou aplicativo desconhecido primeiro — não espere. Depois, mesmo que o invasor talvez não tenha precisado da sua senha, troque-a mesmo assim como uma medida extra de segurança, e reative a autenticação de dois fatores caso tenha sido desativada (alguns sequestros a desativam para facilitar o retorno). Verifique se o invasor configurou algo para manter acesso persistente, como novas regras de encaminhamento no e-mail, novos números de telefone ou e-mails de recuperação, ou novos dispositivos adicionados em outros lugares — uma sessão sequestrada costuma ser usada para plantar um segundo ponto de apoio antes que o primeiro seja descoberto. Por fim, se a conta comprometida for uma em que seus contatos confiam (como o WhatsApp), avise as pessoas de que mensagens suas do passado recente — especialmente qualquer coisa pedindo dinheiro, votos ou códigos — podem não ter sido enviadas por você.

Uma armadilha específica de viagens que vale a pena destacar

Se você estiver se conectando ao Wi-Fi de um hotel, aeroporto ou conferência e a página do portal cativo pedir que você "faça login" numa conta da Microsoft, do Google ou similar, ou mostrar um código de dispositivo para digitar, desconfie por padrão — o Wi-Fi legítimo de hotel quase nunca precisa que você autentique uma conta pessoal na nuvem para ficar online. Feche o navegador e conecte-se pelo compartilhamento de internet do seu celular ou por uma VPN; e se precisar mesmo usar o Wi-Fi do hotel, evite fazer login em qualquer coisa sensível nele.

Mais uma dica, para quem escreve ou publica código

A mesma lógica de "não é a sua senha, é a sua sessão/token" se aplica a credenciais de desenvolvedor. Um incidente recente de cadeia de suprimentos envolvendo um pacote npm envenenado monitorava especificamente a rotação de credenciais e podia disparar a partir dela — o que significa que o movimento instintivo inicial (rotacionar seus tokens) foi, nesse caso, o movimento errado. Se você suspeitar que uma credencial de build ou de CI foi exposta, verifique o que o pacote comprometido realmente fez antes de rotacionar qualquer coisa, em vez de presumir que a rotação sozinha resolve o problema.

Coloque isso no calendário

Nada disso é uma solução pontual — é um hábito, da mesma forma que conferir o extrato bancário é um hábito. Escolha uma data recorrente (o primeiro dia do mês funciona bem) e passe pelas listas de dispositivos/sessões acima. É uma verificação de quinze minutos que detecta exatamente o tipo de invasão silenciosa e sem senha que todo o resto da sua configuração de segurança foi feita para não perceber.