Phishing com tema de passkey leva a invasão de contas na nuvem

A Microsoft publicou em 9 de setembro de 2026 a análise de uma cadeia de intrusão em ambientes de nuvem que começa com um telefonema. Alguém que se apresenta como suporte de TI liga para o celular pessoal do funcionário e avisa, com urgência, que a passkey, o MFA ou o SSO precisam ser reconfigurados imediatamente para evitar interrupção do acesso. A vítima é levada a uma página que imita a tela de login da Microsoft, e a partir daí a conta corporativa deixa de ser dela.

O detalhe que dá a esta campanha seu valor prático é contraintuitivo: a passkey quase nunca é o alvo. Segundo a Microsoft, o tema serve de pretexto para conduzir a vítima até um fluxo de adversary-in-the-middle (AiTM) ou até o fluxo de código de dispositivo. No primeiro caso, o atacante intercepta credenciais e o token de sessão; no segundo, a própria vítima autoriza o acesso em nome do invasor, em uma página legítima da Microsoft.

A atividade é rastreada desde maio de 2026 e envolve mais de um grupo. A Microsoft atribui o acesso inicial a operadores como Storm-3121, ligado às extorsões conduzidas sob as marcas ShinyHunters e Falcon, e Storm-3032, um conjunto de atores que se desmembrou do grupo BlackFile e hoje opera sob a marca Helix.

Por que o pretexto da passkey funciona

Passkeys são credenciais baseadas em criptografia de chave pública, ligadas ao domínio do site legítimo. Justamente por isso resistem a phishing: uma passkey registrada para o domínio verdadeiro não é apresentada a um site clonado. A Microsoft continua recomendando passkeys e FIDO2 como defesa, e nada na campanha indica falha no protocolo.

O que o atacante explora é o momento de transição. Empresas em processo de adoção de passkeys estão enviando comunicados legítimos sobre reconfiguração de autenticação, e o funcionário não estranha mais um pedido nesse sentido. O golpe se apoia na expectativa criada pelo próprio projeto de segurança da organização.

O Plugged Ninja já cobriu um caso vizinho em julho de 2026, quando a Okta alertou para a campanha de vishing “Pink”, que registrava passkeys controladas pelo atacante em contas Microsoft 365. São episódios distintos, com atores e telemetria diferentes, mas o padrão de usar o vocabulário da autenticação moderna como isca se repete.

A infraestrutura de engano

Os operadores registram domínios genéricos e embutem o nome da empresa-alvo como subdomínio, produzindo endereços que parecem familiares em uma leitura rápida. A Microsoft cita o padrão nomedaempresa[.]dominiomalicioso[.]com e exemplos como contoso[.]add-passkey[.]com. Vários domínios são criados para a mesma organização, permitindo rotação rápida.

Os temas usados nos domínios divulgados oficialmente pela Microsoft se agrupam assim:

Os domínios costumam ficar operacionais em poucas horas. A Microsoft observou registros feitos no registrador Nicenic e faz questão de ressalvar que o registro, por si só, não implica envolvimento do registrador na atividade. Em parte dos casos, os atacantes usam contas já comprometidas para enviar as mesmas mensagens pelo Microsoft Teams, aproveitando a confiança em um remetente interno.

Da sessão roubada à persistência

Em uma das intrusões investigadas, a Microsoft reconstruiu a sequência minuto a minuto. O acesso começou por um login no aplicativo OfficeHome a partir de um dispositivo não gerenciado. Um minuto depois o MFA foi concluído — com um método não resistente a phishing — e a sessão foi estabelecida. Nos quinze minutos seguintes, a mesma sessão passou por My Apps, My Profile, Microsoft Approval Management, Microsoft Account Controls e My Sign-Ins, chegando a SharePoint Online, Outlook Web e ao portal interno de aplicações virtuais.

A Microsoft é cuidadosa ao qualificar o que a telemetria prova: os eventos de autenticação mostram que a sessão pediu acesso a recursos, mas não comprovam, isoladamente, que um documento tenha sido aberto ou que um anexo tenha sido baixado. Essa distinção importa para quem for reproduzir a investigação.

Estabelecido o acesso, o primeiro objetivo do atacante é transformá-lo em permanente. Em vez de depender apenas de credenciais roubadas, ele registra um método de MFA sob seu controle: um novo telefone, um aplicativo autenticador ou um token OTP em software. Nos registros de auditoria, isso aparece como uma operação Update user. em que a lista de dispositivos cresce e o novo item traz o nome NO_DEVICE e a marcação SoftwareTokenActivated.

Em um terceiro padrão observado, o invasor entrou com credenciais válidas e aprovou o MFA com um método PhoneAppOTP registrado dias antes, o que sugere um comprometimento anterior deixado dormente. A automação usada nessa etapa foi construída em Node.js sobre o Microsoft Graph.

Reconhecimento pelo Graph e coleta lenta

O ponto mais instrutivo do relatório é o desafio de detecção. Chamadas isoladas ao Microsoft Graph para /users, /groups ou /sites são rotina em qualquer empresa. O sinal aparece na progressão: quando a mesma identidade percorre o perfil do tenant, enumera o diretório, inspeciona papéis privilegiados e métodos de autenticação registrados, mapeia aplicações e concessões OAuth, localiza bibliotecas de documentos e, só então, começa a recuperar conteúdo.

A Microsoft observou ainda que os atacantes rotacionam infraestrutura entre as fases, usando endereços IP diferentes para autenticação, reconhecimento e exfiltração. Isso torna a correlação por indicador de rede pouco confiável e reforça a leitura por comportamento.

A coleta final não é um assalto relâmpago. A exfiltração se estendeu de algumas horas a vários dias, com o cuidado deliberado de manter menos de mil arquivos ou mensagens acessados por hora — volume que se confunde com uso corporativo normal. Em vários casos a Microsoft observou o agente de usuário python-httpx associado a acessos de alto volume no SharePoint e no OneDrive, e adverte que o agente de usuário sozinho não deve ser tratado como malicioso.

O que isso muda para quem defende

O caso expõe uma lacuna de visibilidade que não se resolve com mais ferramenta no endpoint. Se a vítima abre o link de phishing no celular pessoal, fora do Defender for Endpoint, a etapa inicial simplesmente não existe na telemetria. A Microsoft registra que, em muitas investigações, a lembrança do funcionário sobre uma ligação ou um SMS foi a primeira e às vezes a única evidência de como o comprometimento começou.

Há também um limite claro no que a análise afirma. A Microsoft descreve a atividade como “consistente com” coleta automatizada e potencial exfiltração, e não apresenta números de organizações afetadas, volume de dados extraídos ou prejuízo financeiro. Tampouco há indicação pública de alvos no Brasil — o valor da leitura aqui é o padrão, não a geografia.

Do lado positivo, a cadeia descrita é longa e cheia de pontos de interrupção. Diferentemente de uma exploração de vulnerabilidade, que pode ser instantânea, esta intrusão exige telefonema, página falsa, registro de MFA, semanas de reconhecimento e dias de coleta. Cada uma dessas etapas é observável por quem tiver os registros certos ligados.

Recomendações

• Exigir MFA resistente a phishing (FIDO2, passkeys, Windows Hello for Business) por acesso condicional, em vez de aprovação por notificação ou OTP.
• Bloquear os fluxos de código de dispositivo e de transferência de autenticação por acesso condicional, abrindo exceção apenas onde houver necessidade de negócio comprovada.
• Aplicar acesso condicional estrito ao registro de informações de segurança: frequência de login sempre interativa, exigência de dispositivo gerenciado ou local nomeado e força de autenticação resistente a phishing.
• Habilitar os registros de atividade do Microsoft Graph e a auditoria de caixas postais, e alertar sobre enumeração anômala, registro de novo método de autenticação e acesso de alto volume a arquivos ou e-mails.
• Revisar métodos de autenticação recém-registrados em contas com logins incomuns e remover os não autorizados após validar com o usuário.
• Em comprometimento confirmado, revogar sessões e tokens de atualização, redefinir credenciais, remover métodos de autenticação e regras de caixa postal criados pelo atacante e exigir novo registro seguro dos fatores.
• Limitar dispositivos não gerenciados a sessões web sem download ou sincronização e desativar links de compartilhamento anônimo no SharePoint e no OneDrive.
• Definir e divulgar um procedimento rigoroso de verificação de identidade antes de qualquer reset de credencial ou MFA iniciado pelo suporte, com alerta em cada ocorrência.

Conclusão

A campanha não quebra passkeys: ela usa o nome delas. É uma diferença que muda a resposta. Quem concluir que a tecnologia falhou tende a adiar a migração, que é exatamente o efeito mais útil para o atacante — porque o MFA por notificação e por OTP, esse sim, foi contornado nos casos descritos.

O que observar a seguir é se o pretexto se desloca para outros temas de identidade à medida que a adoção de passkeys amadurece, e se a Microsoft passa a divulgar escala e setores afetados. Por ora, a orientação prática independe disso: reduzir a superfície de fluxos de autenticação abusáveis, tratar o registro de fator como evento crítico e ler a atividade do Graph como sequência, não como chamadas soltas.

Fontes e referências

• Microsoft Security Blog — Passkey-themed social engineering leads to identity and cloud compromise (9 de setembro de 2026)
• MITRE ATT&CK — técnica T1556.006, Modify Authentication Process: Multi-Factor Authentication (identificador consultável no site do MITRE)
• MITRE ATT&CK — técnica T1078.004, Valid Accounts: Cloud Accounts
• Plugged Ninja — Okta alerta para campanha de vishing “Pink” que registra passkeys adversariais em contas Microsoft 365
• Plugged Ninja — Abuso de identidade no Teams e Slack quadruplica, diz Unit 42