Notícia
Golpe usa 'passkey' como isca e rouba contas Microsoft 365 — o funcionário completa o MFA e mesmo assim perde tudo
Rodrigo ColissiIntrodução
Pesquisadores do Microsoft (empresa de tecnologia responsável pelo Windows, pelo Azure e pela suíte de produtividade em nuvem) Security Research rastreiam desde maio de 2026 uma sequência que se repete em intrusões na nuvem: um sign-in incomum, o cadastro de novos métodos de autenticação, atividade intensa via Microsoft Graph (API unificada da Microsoft para acessar identidade, e-mail, arquivos e demais serviços do Microsoft 365) e downloads de arquivos de SharePoint, OneDrive e e-mail. A porta de entrada, documentada no relatório divulgado em 09/09/2026 e repercutido pelo Cyber Security News, é um phishing com isca de "passkey": a vítima é convencida a "ajustar" a configuração de passkey, MFA ou SSO e acaba entregando a sessão inteira da conta Microsoft 365 (suíte de produtividade em nuvem com e-mail, documentos, reuniões e armazenamento de arquivos).
O ponto central do ataque é incômodo: o funcionário completa a autenticação multifator (MFA) (segunda etapa de verificação além da senha, como código, biometria ou notificação) normalmente e, mesmo assim, perde tudo. Duas técnicas se repetem nos casos investigados — adversary-in-the-middle (AiTM) (intermediário que espelha o site legítimo e retransmite o tráfego entre vítima e serviço real) e device-code flow (fluxo de autenticação em que o usuário aprova um código para liberar acesso a um aplicativo) —, ambas explicadas abaixo. Vale a honestidade: não há vítimas brasileiras confirmadas até o momento, a mecânica não é nova e não se trata de uma zero-day — o diferencial está na isca de passkey e na coleta lenta e silenciosa de dados. A campanha é o complemento direto do roubo de sessão relatado no caso BigBear 2.0, que usava a mesma mecânica AiTM com páginas espelhadas para capturar a prova de que o MFA foi concluído.
A isca: "passkey" como pretexto
A campanha começa longe do teclado: o funcionário recebe uma ligação ou SMS no celular pessoal de alguém que se apresenta como suporte de TI da própria empresa. O pretexto é urgente — a configuração de passkey (método de autenticação sem senha baseado em chaves criptográficas), de MFA ou de single sign-on (SSO) (login único que autentica uma vez e dá acesso a vários serviços) precisa ser atualizada para evitar interrupção. Em seguida, a vítima é direcionada para um site que reproduz fielmente a experiência de login da Microsoft; o link chega, em muitos casos, por SMS no celular pessoal.
A isca é só o pretexto: segundo a Microsoft, o cadastro de passkey raramente é o objetivo real do atacante — a narrativa serve para guiar a vítima até as páginas falsas. Em um número menor de casos, contas já comprometidas de colegas enviam a mesma mensagem pelo Microsoft Teams, o que torna o pedido muito mais convincente: quem pede é uma identidade confiável dentro da própria organização.
Os atacantes investem em reconhecimento prévio, coletando nomes, cargos e estrutura organizacional em redes sociais profissionais, e registram domínios genéricos nos quais o nome da empresa entra como subdomínio do domínio do atacante — por exemplo, contoso.add-passkey.com. Os domínios, registrados com frequência no registrar Nicenic e operacionais em poucas horas, permitem rotacionar a infraestrutura e dificultam o bloqueio antes que o funcionário clique no link.
As duas formas de roubar a sessão
Independentemente do pretexto, o roubo da sessão segue um de dois caminhos: o phishing AiTM ou o device-code flow. Abaixo apresentamos o fluxo resumido em cinco etapas e detalhamos cada variante em seguida.
Cadeia de ataque da campanha passkey
O phishing AiTM: o proxy entre a vítima e o login real
No AiTM, o site falso não captura só a senha: ele atua como proxy reverso e retransmite o login para o serviço legítimo da Microsoft em tempo real. A vítima digita e-mail e senha na página espelhada, completa o desafio de MFA normalmente — o código é validado pela própria Microsoft — e, no caminho, o atacante copia as credenciais e o token de sessão emitido pelo servidor real. É a mesma mecânica documentada no caso BigBear 2.0, operacionalizada com o framework Evilginx2. Em uma sequência observada pela Microsoft, o atacante entrou a partir de um dispositivo não gerenciado, completou o MFA e, na mesma sessão, navegou por My Sign-Ins, My Apps e pelo portal de aprovações da Microsoft por cerca de uma hora, enumerando arquivos sensíveis e aplicativos internos.
O device-code flow: a vítima entrega o acesso pela página oficial
Na segunda variante, o atacante não rouba cookie de navegador: ele convence a vítima a completar um device-code flow. Nesse fluxo legítimo do OAuth, um aplicativo exibe um código e pede que o usuário entre em uma página oficial da Microsoft para aprová-lo — é o mecanismo usado para autenticar TVs e consoles, por exemplo. A vítima digita o código na página real da Microsoft e aprova; o token de sessão é então emitido para o client controlado pelo atacante, que passa a acessar os recursos permitidos sem nunca ter tocado no navegador da vítima. Nos casos investigados, o token obtido foi reutilizado para contornar o MFA e seguir com a enumeração. Há ainda um terceiro padrão observado: o atacante entra com credenciais já comprometidas e completa o MFA com um método de aplicativo autenticador cadastrado dias antes — ou seja, com um fator que ele próprio registrou.
Por que completar o MFA não prova nada
A autenticação multifator valida que alguém respondeu ao desafio — não valida com quem o navegador está conversando. No AiTM, o desafio de MFA passa pelo proxy: a vítima acha que está falando com a Microsoft e está, só que através do atacante, que copia o resultado. No device-code, a aprovação acontece na página oficial da Microsoft, mas o token gerado é entregue ao aplicativo do atacante, não ao usuário. Nos dois casos, a prova de que o segundo fator foi concluído é capturada ou redirecionada — por isso prompts de autenticação merecem o mesmo escrutínio que um pedido de senha, especialmente depois de uma ligação ou SMS inesperado.
A persistência: fatores rogue e refresh tokens
Com a sessão nas mãos, o primeiro objetivo do atacante é transformar o acesso temporário em permanência. A Microsoft observou o cadastro de métodos de autenticação controlados pelo atacante — um número de telefone, um aplicativo autenticador ou um token OTP de software — diretamente na identidade da vítima. Esses fatores rogue (métodos de autenticação adicionados sem autorização do usuário) satisfazem desafios futuros de MFA sem a participação do funcionário.
O detalhe que derruba a resposta padrão de "trocar a senha resolve": a redefinição de senha pode não expulsar o atacante se sobrarem sessões ativas, refresh tokens (tokens que renovam a sessão sem novo login, normalmente válidos por até 90 dias) ou métodos de autenticação cadastrados por ele. Por isso a Microsoft recomenda investigar sign-ins arriscados em paralelo com cada novo fator registrado — e tratar o cadastro de método de MFA como evento de persistência, não como rotina.
A coleta silenciosa via Microsoft Graph
De posse de uma identidade válida e persistente, os atacantes usam o Microsoft Graph para mapear o que a vítima consegue alcançar: usuários, grupos, funções, aplicativos, permissões, sites, unidades, pastas, arquivos, caixas de correio e anexos. Uma requisição isolada a endpoints como /users, /groups ou /sites é rotineira em qualquer empresa — o problema é a soma: descoberta ampla seguida de recuperação de conteúdo revela uma intrusão coordenada.
A coleta em si é desenhada para passar despercebida. Os operadores miram SharePoint Online e OneDrive for Business com acesso e downloads em volume, e em alguns casos estendem a operação ao Exchange Online via API REST, para ler mensagens. O ritmo costuma ficar abaixo de 1.000 arquivos ou mensagens por hora — lento o bastante para se misturar ao uso normal da empresa e sustentável por horas ou dias. A automação transparece em detalhes como o user agent python-httpx e o uso de paginação ($top, $skiptoken, delta) para percorrer grandes conjuntos de resultados — mas, como alerta a Microsoft, um user agent isolado não é prova de nada; o contexto é que conta. A infraestrutura é rotacionada, com IPs diferentes para autenticação, reconhecimento e coleta, e parte do acesso saía de proxies anônimos.
Detecção e resposta
A detecção eficaz não trata um IP ou domínio como conclusivo — trata a sequência como um todo. A Microsoft recomenda correlacionar sinais de identidade, Microsoft Graph, SharePoint, OneDrive e Exchange, centralizando os logs em um SIEM como o Wazuh e bloqueando os domínios conhecidos na camada de DNS, com serviços como o Quad9. Os padrões que mais importam: um sign-in incomum seguido do cadastro de novo método de MFA; descoberta intensa via Graph (usuários, funções, sites, caixas de correio); acesso via proxy anônimo; download automatizado em volume; e buscas concentradas em anexos e caixas de correio. A Microsoft publicou queries de advanced hunting que isolam identidades tocando várias categorias de reconhecimento na mesma sessão — por exemplo, dez ou mais requisições cobrindo três ou mais categorias de endpoints em 30 minutos.
Em comprometimento confirmado, a resposta é: revogar sessões ativas e refresh tokens, redefinir credenciais, remover métodos de autenticação não autorizados e regras de caixa de correio criadas pelo atacante, e exigir novo cadastro seguro dos fatores. Sessões roubadas podem sobreviver a um simples password reset — o tratamento é de incidente de identidade, não de troca de senha.
Indicadores de comprometimento (IoCs)
Os domínios abaixo foram publicados pela Microsoft e pelo Cyber Security News. Estão defangados, com a entidade . no lugar dos pontos, para evitar resolução acidental; reative-os apenas em plataformas controladas de inteligência de ameaças, como MISP, VirusTotal ou seu SIEM. Como a infraestrutura é rotacionada e pode ser reatribuída, a ausência de um indicador não descarta atividade.
| Domínio (defangado) | Tema da isca |
|---|---|
| passkeyhelpdesk.com | Suporte de passkey |
| secure-passkey.com | Segurança de passkey |
| setupmypasskey.com | Configuração de passkey |
| add-passkey.com | Cadastro de passkey |
| integratedsso.com | SSO |
| oktasession.com | Sessão de provedor de identidade |
| keysyncos.com | Sincronização de chaves |
| oskeysync.com | Sincronização de chaves |
| oskeysetup.com | Configuração de chaves |
| oskeyregister.com | Registro de chaves |
| syncmykey.com | Sincronização de chaves |
| myconnectkey.com | Conexão de chaves |
| oskeyconnect.com | Conexão de chaves |
| validationsetupac.com | Validação e configuração de conta |
| portalsetuphub.com | Portal de configuração |
Como se proteger
MFA phishing-resistant. A única autenticação que resiste estruturalmente ao AiTM é a baseada em FIDO2 (padrão de autenticação sem senha com chaves criptográficas) — passkeys, chaves de segurança e Windows Hello for Business. A asserção criptográfica é vinculada ao domínio de origem: na página falsa, a chave se recusa a assinar. Exija esse nível de autenticação via Conditional Access para administradores e usuários sensíveis, e trate SMS e códigos como fatores phishable.
Bloqueie o device-code flow. Se não houver necessidade de negócio explícita, bloqueie os fluxos de device code e de transferência de autenticação via Conditional Access — é a forma de cortar a segunda variante do ataque na origem.
Revogue sessões e refresh tokens. Em comprometimento confirmado, revogue sessões ativas e refresh tokens, redefina credenciais, remova fatores rogue e regras de mailbox, e exija re-registro seguro dos métodos de autenticação. Trocar a senha sozinho não expulsa quem tem sessão viva ou token válido.
Audite o que roda com Microsoft Graph. Revise o consentimento de aplicativos, exija aprovação de administrador para novos consentimentos e audite service principals com permissões privilegiadas como Mail.Read, Files.Read.All e Directory.Read.All. Ative os logs de atividade do Graph e a auditoria de caixas de correio, com alertas para enumeração anômala, registro de métodos de autenticação e volume alto de downloads.
Limite dispositivos não gerenciados. Políticas que restringem o acesso de dispositivos não gerenciados a sessões web sem download ou sincronização, junto com a desativação de links de compartilhamento anônimos em SharePoint e OneDrive, reduzem a superfície de coleta.
Políticas baseadas em risco. Exija dispositivo gerenciado e conforme para Exchange, SharePoint e aplicativos com permissão de Graph, bloqueie o registro de informações de segurança em sessões de alto risco e aplique acesso condicional a sign-ins e usuários arriscados.
Treine e crie um canal de verificação. Confirmar pedidos inesperados de helpdesk por um canal interno conhecido — nunca pelo número ou link informado pelo chamador — e oferecer um canal verificado para reportar solicitações de autenticação suspeitas param o ataque antes de o acesso ser concedido. O treinamento deve cobrir golpes por voz, SMS e Teams, além do e-mail.
Conclusão
A campanha mostra que a isca evoluiu — passkey, SSO e "atualização de segurança" — mas o alvo continua o mesmo: a sessão, não a senha. Completar o MFA deixou de ser garantia de proteção quando o desafio passa por um proxy ou quando o próprio device-code entrega o token ao atacante; e a persistência via fatores rogue faz a simples troca de senha parecer solução quando não é. A defesa combina MFA phishing-resistant, bloqueio de device-code, revogação de sessões e monitoramento da sequência completa — identidade, Graph e armazenamento — em vez de indicadores isolados. A técnica é conhecida e não há, até agora, vítimas confirmadas no Brasil; mas a infraestrutura rotacionada, o pretexto convincente e a coleta silenciosa tornam a campanha um lembrete direto de que MFA phishable não é MFA.
Perguntas frequentes
O que é essa campanha de phishing com isca de passkey?
É uma operação de engenharia social rastreada pela Microsoft desde maio de 2026 em que atacantes se passam por suporte de TI por ligação, SMS ou Teams, usam a configuração de passkey, MFA ou SSO como pretexto e direcionam funcionários para páginas de login falsas. O objetivo não é cadastrar passkey: é roubar a sessão da conta Microsoft 365 via phishing AiTM ou device-code flow.
Por que completar o MFA não impediu o roubo da conta?
O MFA prova que alguém respondeu ao desafio, mas não prova com quem o navegador está conversando. No AiTM, o desafio passa por um proxy que retransmite o login real e copia o token de sessão no caminho. No device-code, a aprovação acontece na página oficial da Microsoft, mas o token é emitido para o aplicativo do atacante. Nos dois casos, o usuário completa o segundo fator e a sessão vai para as mãos erradas.
O que é device-code flow (device code phishing)?
É um fluxo legítimo do OAuth usado para autenticar aplicativos sem navegador — o usuário digita um código em uma página oficial da Microsoft para aprová-los. No abuso, o atacante convence a vítima a aprovar o código de um client controlado por ele; o token gerado pela aprovação é entregue a esse client, que passa a acessar os recursos sem roubar cookie do navegador.
O que é um ataque adversary-in-the-middle (AiTM)?
É uma evolução do man-in-the-middle: o atacante opera um proxy reverso que espelha o site legítimo e retransmite todo o tráfego entre vítima e serviço real. A vítima conversa com a Microsoft de verdade, mas toda a conversa passa pelo atacante, que copia credenciais e tokens de sessão no caminho — a mesma mecânica documentada no caso BigBear 2.0.
Como os atacantes mantêm o acesso depois de roubar a sessão?
Eles registram métodos de autenticação próprios na identidade da vítima — número de telefone, aplicativo autenticador ou token OTP de software. Esses fatores rogue permitem satisfazer desafios futuros de MFA sem o usuário. Uma redefinição de senha pode não expulsá-los se restarem sessões ativas, refresh tokens ou métodos cadastrados por eles.
Como os atacantes coletam dados sem serem notados?
Eles usam o Microsoft Graph para mapear usuários, grupos, sites, arquivos e caixas de correio, e baixam conteúdo de SharePoint, OneDrive e Exchange em ritmo lento — em geral menos de 1.000 arquivos ou mensagens por hora —, sustentado por horas ou dias. A automação (como o user agent python-httpx), a rotatividade de IPs e o acesso via proxy anônimo ajudam a atividade a se misturar ao uso normal.
Como saber se minha organização foi alvo?
Correlacione sinais em vez de olhar um IP isolado: sign-in incomum seguido de cadastro de novo método de MFA, descoberta intensa via Microsoft Graph, acesso via proxy anônimo, downloads automatizados e buscas concentradas em caixas de correio e anexos. Os domínios da tabela acima podem ser bloqueados no DNS e correlacionados no SIEM; a ausência de um indicador não descarta atividade, já que a infraestrutura é rotacionada.
O que fazer em caso de comprometimento confirmado?
Revogue sessões ativas e refresh tokens, redefina credenciais, remova métodos de autenticação não autorizados e regras de caixa de correio criadas pelo atacante, e exija re-registro seguro dos fatores. Trate o caso como incidente de identidade — sessões roubadas podem sobreviver a um password reset — e monitore a conta por atividade anômala nas semanas seguintes.
Fontes e leituras adicionais
- Cyber Security News — Hackers Use Passkey-Themed Phishing to Hijack Microsoft 365 Accounts and Steal Cloud Data — 10/09/2026
- Microsoft — Passkey-themed social engineering leads to identity and cloud compromise — 09/09/2026