Uma onda de intrusões descrita pela Microsoft em 9 de setembro de 2026 começa com uma ligação para o celular pessoal do funcionário: alguém que se apresenta como do suporte de TI alega que a passkey, a autenticação multifator ou o login único precisa ser atualizado naquele instante para evitar interrupção do acesso. Quem segue o link cai em uma página que imita o portal de entrada da Microsoft, entrega credenciais e tokens de sessão e, pouco depois, tem a conta usada para enumerar e baixar documentos em massa do SharePoint, do OneDrive e do Exchange. A pesquisa da Microsoft Security Research avalia que a sequência de invasão é consistente com coleta automatizada a partir de identidades na nuvem comprometidas, atividade observada desde maio de 2026. Organizações que concentram identidade, e-mail e arquivos em nuvem corporativa são o alvo direto; a ação prioritária é auditar agora os registros recentes de métodos de autenticação e correlacionar logins anômalos com uso intenso do Microsoft Graph.
Como o golpe começa
O contato inicial raramente parece um ataque: é uma chamada ou mensagem de texto no número pessoal do empregado, com senso de urgência fabricado e vocabulário técnico correto. O pretexto da passkey raramente é o objetivo real do invasor. O relatório da Microsoft é explícito: a narrativa de atualização de passkey serve como pretexto convincente para conduzir a vítima a um phishing adversary-in-the-middle, que captura credenciais e tokens de sessão, ou a um phishing de código de dispositivo, em que o próprio usuário autoriza o acesso em nome do atacante em uma página de autenticação legítima.
Um detalhe dificulta a investigação: quando a vítima abre o link no celular pessoal, fora do alcance das ferramentas de proteção de endpoint da empresa, quase não resta evidência forense do passo inicial. Em muitos casos, a lembrança do empregado sobre uma ligação ou um SMS é o único indício do início da invasão, e a reconstrução depende de conectar esse relato aos eventos posteriores de entrada, emissão de token e mudança de métodos de autenticação.
A preparação também é social. Os criminosos pesquisam a estrutura da organização e os funcionários em redes profissionais antes de agir, e em parte dos casos reutilizam contas já comprometidas para enviar mensagens temáticas de passkey pelo Microsoft Teams, aproveitando a confiança em um colega real. A infraestrutura de phishing muda rápido: domínios genéricos recebem o nome da empresa-alvo como subdomínio, no padrão nomedaempresa ponto domínio malicioso ponto com, com exemplos observados como add-passkey ponto com, secure-passkey ponto com e integratedsso ponto com. Vários desses domínios ficam operacionais em poucas horas, o que dá pouco tempo para bloqueio antes do contato com os empregados.
Da sessão roubada à persistência
A Microsoft descreve três padrões de comprometimento da identidade. No primeiro, um login anômalo no OfficeHome a partir de um dispositivo não gerenciado conclui a autenticação multifator por meio de phishing e mantém a sessão ativa por cerca de uma hora, tempo em que o invasor enumera aplicativos, perfil, portais de aprovação e arquivos sensíveis. No segundo, a vítima digita um código em página legítima de autenticação por código de dispositivo e o token emitido é reaproveitado pelo cliente controlado pelo atacante, contornando o segundo fator sem roubar cookie de navegador. No terceiro, o criminoso entra com credenciais já roubadas e valida com um método PhoneAppOTP registrado dias antes, sinal de que a preparação começou bem antes da campanha visível.
Em todos os caminhos, o passo seguinte é transformar acesso temporário em controle duradouro: o atacante registra um método de autenticação próprio, como um novo número de telefone, um aplicativo autenticador ou um token de senha única por software. Com esse fator inserido na identidade da vítima, desafios futuros de autenticação podem ser respondidos sem participação do usuário legítimo. A automação é explícita: parte da atividade roda por sistema desenvolvido em Node.js sobre o Microsoft Graph, o que explica a velocidade da progressão observada entre o login inicial e o acesso a bibliotecas de documentos, caixa de correio e portais internos.
Coleta em massa via Graph
Depois da persistência, vem o reconhecimento da nuvem: enumeração de diretório, descoberta de funções e entidades de serviço, rótulos de sensibilidade e repositórios disponíveis, tudo consultando a API do Graph com a identidade comprometida. Em seguida, a coleta assume volume: eventos de acesso e download de arquivos no SharePoint Online e no OneDrive aparecem em grande quantidade, com trechos da caixa de correio acessados por API REST do Exchange, incluindo o recurso de download de anexos. A Microsoft classifica o conjunto como coleta e possível exfiltração automatizada, com uso de atividade em Python para retirada rápida dos dados.
O alvo final não é criptografia de sistemas, e sim extorsão por furto de informação. Segundo a pesquisa, o acesso inicial dessa campanha é aproveitado por uma gama de atores, incluindo os grupos Storm-3121, associado a invasões que terminam em extorsão das linhas ShinyHunters e Falcon, e Storm-3032, que reúne operadores que se separaram do grupo BlackFile e atuam sob a bandeira de extorsão Helix. Para a equipe defensiva, isso muda a resposta: o relógio corre entre o login suspeito e a retirada de documentos, não entre a invasão e um eventual ransomware.
Sinais a investigar agora
Domínios e endereços mudam rápido; a sequência de comportamento é o que serve de base durável para busca. A tabela resume os sinais de maior valor e onde verificá-los:
| Sinal | Onde verificar | Ação imediata |
|---|---|---|
| Login anômalo de dispositivo não gerenciado | Logs de entrada do provedor de identidade | Correlacionar com mudança de método de autenticação na mesma janela |
| Novo método de autenticação ou dispositivo registrado | Logs de auditoria de usuários | Confirmar com o titular por canal conhecido e remover se não reconhecido |
| Volume alto de chamadas ao Microsoft Graph | Auditoria de API do Graph | Investigar enumeração seguida de pedidos de conteúdo |
| Downloads em massa no SharePoint e no OneDrive | Eventos de acesso e download de arquivos | Comparar com a linha de base do usuário |
| Acesso REST a caixas de correio e anexos | Logs do Exchange | Verificar pesquisas e coleta fora do padrão |
| Domínio novo com o nome da empresa como subdomínio | Monitoramento de registros de DNS | Bloquear no proxy e na filtragem de e-mail |
Resposta priorizada
Para casos confirmados, a sequência de resposta começa por revogar sessões ativas e tokens de atualização das identidades afetadas, redefinir credenciais, remover os métodos de autenticação registrados pelo atacante, eliminar regras de caixa de correio criadas por ele e exigir novo registro seguro de fatores. Como prioridade seguinte, a equipe deve revisar o fluxo de código de dispositivo: se não há necessidade de negócio, restrinja-o por acesso condicional, e trate como paliativo o pareamento por número, reconhecendo que não substitui fatores resistentes.
No plano estrutural, a orientação é direta: MFA resistente a phishing é o padrão-ouro recomendado pelo CISA. A orientação do CISA sobre MFA resistente a phishing recomenda que todas as organizações adotem fatores baseados em FIDO e WebAuthn como parte dos princípios de Zero Trust, priorizando contas administrativas e de help desk, exatamente os perfis que os criminosos imitam e exploram. A migração completa leva tempo; comece pelos grupos de maior risco. Complemente com um protocolo interno de verificação de suporte: nenhum registro de método de autenticação é feito por solicitação telefônica, e todo pedido sensível é confirmado por retorno a um canal previamente conhecido. Reduza também a dependência de códigos de seis dígitos em favor do vínculo criptográfico com a origem do login, porque é esse elo que o golpe tenta quebrar.