Um kit de phishing comercializado em fóruns de cibercrime de língua russa promete aquilo que, até agora, era o calcanhar de Aquiles de qualquer atacante: manter o acesso a uma conta depois de a vítima trocar a palavra-passe e terminar todas as sessões. Segundo a análise divulgada pela empresa de segurança Abnormal, o iAuthFlow v2 inclui um módulo capaz de registar uma passkey controlada pelo atacante na conta comprometida, transformando um roubo de credenciais temporário numa porta das traseiras persistente. A investigação assenta na documentação, nos anúncios e nos vídeos de demonstração do vendedor — e não em campanhas observadas no terreno —, pelo que várias das capacidades anunciadas continuam por confirmar de forma independente.
Resposta rápida: Investigadores da Abnormal descrevem o iAuthFlow v2, um kit de phishing vendido por cerca de 10 mil dólares que, após enganar a vítima, usa a sessão autenticada para inscrever uma passkey do atacante na conta. Essa credencial pode continuar válida mesmo depois de a palavra-passe ser alterada e as sessões revogadas. Se suspeitar de comprometimento, não se limite a repor a palavra-passe: verifique passkeys e chaves de segurança registadas, métodos de recuperação, reencaminhamentos e filtros de correio, acessos delegados e autorizações OAuth.
Um kit de 10 mil dólares que resolve o problema dos atacantes
O iAuthFlow v2 foi identificado num fórum de cibercrime em língua russa, é descrito como uma forma avançada de phishing que garante acesso persistente à conta da vítima mesmo após a reposição da palavra-passe, e é anunciado a partir de 10 mil dólares para o pacote base, com módulos adicionais vendidos à parte. O objetivo comercial é explícito: resolver um problema recorrente de quem ataca contas — ficar de fora assim que a vítima deteta o comprometimento.
As demonstrações do vendedor centram-se em contas Google, mas são anunciados pacotes para iCloud, LinkedIn e Microsoft. Trata-se, portanto, de um modelo de phishing-as-a-service orientado às plataformas onde vivem as identidades pessoais e profissionais da maioria dos utilizadores — e onde uma conta de correio comprometida funciona como chave-mestra para dezenas de outros serviços.
Browser-in-the-middle: dois navegadores, uma ilusão
A técnica descrita não é o clássico proxy transparente do tipo adversary-in-the-middle. De acordo com a Abnormal, que examinou a documentação e os vídeos de demonstração do kit, a abordagem segue um modelo browser-in-the-middle (BitM) com dois ambientes de navegação distintos: a vítima julga estar a concluir a autenticação no seu próprio dispositivo, enquanto a infraestrutura do atacante retransmite a interação através de uma sessão de navegador separada, com a vítima a ver uma página de phishing que imita o serviço alvo.
Os dados introduzidos pela vítima são enviados para o serviço legítimo a partir do navegador alojado no servidor do atacante, que devolve à vítima os pedidos apresentados pela plataforma; o ciclo repete-se até a autenticação estar completa e, nessa altura, o kit passa a controlar uma sessão autenticada e usa-a para inscrever uma passkey controlada pelo atacante.
O detalhe mais engenhoso é o disfarce temporal. Em vez de encaminhar a vítima diretamente para a caixa de correio, o kit exibe um ecrã de carregamento com uma mensagem de “verificação” enquanto, em segundo plano, abre as definições de passkeys da conta através do navegador autenticado e pede uma nova credencial. A Abnormal ressalva que a Google pode exigir verificação adicional de identidade antes de permitir a alteração e que, na execução gravada, o registo do kit indica que a passkey foi criada seis segundos após a autenticação.
| Fase | O que acontece | O que a vítima vê |
|---|---|---|
| 1. Isco | A vítima é direcionada para uma página controlada pelo atacante | Uma página de início de sessão aparentemente legítima |
| 2. Retransmissão | O navegador do atacante replica o fluxo real de autenticação, incluindo desafios de MFA | Os passos habituais de login e verificação |
| 3. Pausa | Ecrã de “verificação/processamento” enquanto o módulo atua | Um breve carregamento |
| 4. Persistência | Registo de uma passkey associada a um dispositivo do atacante (seis segundos após a autenticação, na demonstração) | Nada de anormal |
| 5. Regresso | Autenticação futura sem necessidade da palavra-passe | Nenhum sinal, salvo auditoria das credenciais registadas |
Porque é que repor a palavra-passe já não chega
A lógica é simples e é exatamente esta que muda o manual de resposta a incidentes. Alterar a palavra-passe e revogar sessões não afeta a nova passkey, porque esta é uma credencial registada na conta e não um token derivado da palavra-passe; fica sob controlo do atacante e basta-lhe escolher outro método de autenticação no ecrã de início de sessão para voltar a entrar, sem sequer saber a palavra-passe atual.
Revogar sessões e rodar credenciais continua a ser necessário, mas pode não ser suficiente se o atacante tiver inscrito uma passkey na conta comprometida. Um ponto que permanece por esclarecer é onde fica armazenada a chave privada associada à passkey do atacante. Vale também notar que, até ao momento, não foram divulgados publicamente indicadores de comprometimento (IOC) — domínios, hashes ou infraestrutura — associados a este kit, o que limita a deteção baseada em listas de bloqueio e reforça a importância da telemetria de identidade.
O que verificar depois de uma conta comprometida
A recomendação dos investigadores é tratar a recuperação de uma conta como uma investigação e não como um simples botão de reposição. Segundo a Abnormal, a resposta não pode terminar na reposição da palavra-passe ou na revogação de sessões: as organizações têm de examinar o que mudou após a autenticação — sobretudo credenciais recém-inscritas, métodos de recuperação, autorizações OAuth e definições da caixa de correio — e remover tudo o que o atacante tenha deixado para trás, tratando o restauro da conta como uma investigação abrangente.
- Passkeys e chaves de segurança: listar todas as credenciais registadas e eliminar as que não reconhece.
- Métodos de recuperação: número de telemóvel, endereço alternativo e códigos de recuperação.
- Regras de correio: filtros, reencaminhamentos automáticos e respostas automáticas criadas sem o seu conhecimento.
- Acessos delegados e aplicações: delegação de caixa de correio e aplicações de terceiros com permissões OAuth.
- Dispositivos e sessões: terminar sessões e remover dispositivos desconhecidos — depois, e não antes, da limpeza das credenciais.
As passkeys deixaram de ser seguras? Não é essa a leitura
Importa separar duas coisas. O ataque descrito não quebra a criptografia das passkeys nem contorna a ligação à origem: explora o facto de a conta ainda permitir métodos de autenticação suscetíveis a phishing e de o registo de uma nova credencial poder ser feito a partir de uma sessão já autenticada. Numa passkey, o dispositivo gera um par de chaves, a privada permanece no dispositivo protegida por biometria ou PIN, a pública fica com o serviço, e a autenticação faz-se assinando um desafio sem que a chave privada circule na rede.
O problema está nos caminhos alternativos. Kits de AiTM já recorrem a ataques de downgrade, oferecendo à vítima uma opção menos segura em vez da passkey — ou seja, mesmo existindo um método resistente a phishing, a presença de um método de recurso mais fraco mantém a conta vulnerável. E o registo de passkeys já era abusado antes deste kit: a Okta documentou um painel PHP operado manualmente em tempo quase real que conduz a vítima pelas várias fases de autenticação, sendo provável que o ator de ameaça o use para tomar conta do acesso e levar o utilizador a aprovar o registo de uma passkey iniciado pelo atacante. Este tipo de campanha coincidiu com a possibilidade de os administradores configurarem campanhas que incentivam o registo de passkeys durante o início de sessão, com os atacantes a explorarem o próprio processo de melhoria de segurança como isco.
Porque é que isto importa em Portugal
O phishing é, há anos, o vetor dominante no ciberespaço de interesse nacional. Na 6.ª edição do relatório do CNCS, destacam-se grandes fugas de credenciais de entidades da administração pública, operadores de serviços essenciais e prestadores de serviços digitais, por vezes associadas à crescente ameaça dos infostealers, com o phishing, o smishing e outras formas de engenharia social entre as ciberameaças mais relevantes. O CNCS descreve ainda um cenário de cibercriminalidade profissionalizada que explora o fator humano e alimenta a compra e venda de credenciais em fóruns de cibercrime, tendo como principais visados os cidadãos, as PME, a administração pública, a banca e os setores dos transportes e da saúde. Um kit vendido a 10 mil dólares encaixa exatamente nesse mercado.
Para as organizações abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a consequência prática é dupla: as medidas de gestão de risco devem contemplar autenticação resistente a phishing e a monitorização de alterações às credenciais registadas; e os procedimentos de resposta a incidentes têm de incluir a verificação pós-autenticação, sob pena de uma notificação ao CERT.PT ser encerrada com o atacante ainda dentro da conta. Quando a caixa de correio comprometida contém dados pessoais — o caso mais comum —, aplica-se também o RGPD, com a obrigação de avaliar o risco para os titulares e, se for caso disso, notificar a CNPD no prazo de 72 horas. Uma persistência não removida significa violação continuada e reavaliação obrigatória do risco.
Para cidadãos e PME, a mensagem é mais simples: ative passkeys, mas revise periodicamente a lista de credenciais registadas nas contas Google, Microsoft, Apple e LinkedIn. Uma passkey que não reconhece é hoje um indicador de comprometimento tão sério como um reencaminhamento oculto para um endereço estranho.
Perguntas frequentes
O que é o iAuthFlow v2?
É um kit de phishing anunciado num fórum de cibercrime em língua russa, com um pacote base na ordem dos 10 mil dólares e módulos vendidos separadamente. Segundo a Abnormal, inclui um módulo capaz de registar uma passkey controlada pelo atacante numa conta já comprometida, garantindo acesso persistente.
As passkeys deixaram de ser seguras?
Não. O ataque não quebra a criptografia nem a ligação da passkey ao domínio legítimo: aproveita uma sessão obtida por phishing para inscrever uma credencial adicional. As passkeys continuam a ser dos métodos mais robustos, sobretudo quando os métodos de recurso suscetíveis a phishing são eliminados.
Como sei se alguém registou uma passkey na minha conta?
Nas definições de segurança da conta existe uma lista de passkeys e chaves de segurança registadas, normalmente com data de criação e dispositivo associado. Qualquer entrada que não reconheça deve ser removida, seguida da revisão de métodos de recuperação, regras de correio e aplicações autorizadas.
Repor a palavra-passe chega para recuperar uma conta comprometida?
Deixou de chegar. Uma passkey inscrita pelo atacante não depende da palavra-passe, pelo que sobrevive à reposição e à revogação de sessões. A recuperação deve incluir a auditoria de tudo o que mudou depois da autenticação e a remoção de qualquer credencial, delegação ou autorização deixada para trás.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Abnormal, pela Okta, pela Microsoft e pelo Centro Nacional de Cibersegurança (CNCS/CERT.PT).