Ghostcode contorna Mfa da microsoft para assumir contas em poucos segundos

7 минут чтения

GhostCode usa fluxo legítimo da Microsoft para contornar MFA e assumir contas em poucos segundos

Uma campanha de phishing batizada de GhostCode está explorando um recurso legítimo de autenticação da Microsoft para obter acesso a ambientes Microsoft 365 mesmo quando as contas estão protegidas por autenticação multifator, o MFA. Em vez de capturar diretamente a senha, os criminosos induzem o próprio usuário a aprovar uma sessão iniciada pelo atacante.

O método é especialmente perigoso porque a vítima pode visualizar uma página autêntica da Microsoft durante parte do processo. Ao inserir um código fornecido pelos criminosos e concluir o segundo fator, o usuário acredita estar autorizando uma ação comum, mas, na prática, libera o acesso a um dispositivo ou sessão controlada pelo invasor.

Campanha já foi observada em ataques reais

A atividade foi identificada no fim de agosto de 2026 pela Threat Response Unit da eSentire. Segundo a análise, os operadores entravam em contato com empresas por meio de formulários disponíveis em seus sites. Eles se apresentavam como representantes de compras de organizações legítimas, iniciavam uma conversa comercial e, depois, enviavam uma suposta documentação por meio do WeTransfer.

O arquivo recebido era um documento HTML protegido por senha. O conteúdo utilizava técnicas de ofuscação e mecanismos para dificultar a análise automatizada. Depois que a vítima acessava o material, era encaminhada para um processo de autenticação baseado em código de dispositivo.

A combinação entre engenharia social, infraestrutura legítima e páginas visualmente confiáveis reduz os sinais tradicionais de fraude. Não há necessariamente um domínio falso evidente, uma senha digitada em um formulário suspeito ou uma solicitação explícita para desativar o MFA.

O que é o Device Code Flow

O ataque explora o OAuth 2.0 Device Authorization Grant, conhecido no ecossistema Microsoft como Device Code Flow. Esse mecanismo foi criado para dispositivos com entrada limitada de texto, como televisores, equipamentos compartilhados e determinados sistemas embarcados.

O funcionamento legítimo é relativamente simples: um dispositivo apresenta um código ao usuário, que acessa uma página de autenticação em outro equipamento, informa o código e conclui o login. Depois da aprovação, o primeiro dispositivo recebe autorização para operar em nome daquela conta.

No GhostCode, os criminosos iniciam o fluxo em um equipamento sob seu controle e enviam o código à vítima. Quando ela informa esse código na página da Microsoft e confirma o MFA, não está protegendo o próprio computador. Está autorizando o dispositivo iniciado pelo atacante.

Esse ponto é fundamental: o MFA não é necessariamente quebrado tecnicamente. A autenticação multifator funciona conforme projetada, mas a aprovação é obtida por meio de manipulação psicológica. O problema está na autorização concedida à sessão errada.

Tokens e dispositivos podem garantir persistência

A velocidade observada durante os ataques aumenta consideravelmente o risco para as empresas. Em um dos incidentes analisados, os operadores realizaram nove chamadas de API bem-sucedidas, registraram três dispositivos em aproximadamente 78 segundos e obtiveram um Primary Refresh Token em cerca de 32 segundos.

Um Primary Refresh Token pode ser utilizado para ampliar a persistência do invasor e facilitar o acesso a serviços do Microsoft 365 sem exigir uma nova autenticação interativa a cada operação. Dependendo das permissões da conta comprometida, o atacante pode consultar mensagens, acessar arquivos, explorar aplicações corporativas e procurar informações úteis para novas fraudes.

Por isso, revogar apenas uma sessão ou excluir um único token pode não resolver o incidente. Caso dispositivos tenham sido registrados no tenant, eles também precisam ser identificados e removidos. A resposta deve abranger sessões ativas, tokens, dispositivos recém-inscritos, acessos ao Exchange Online, SharePoint, OneDrive e demais serviços conectados.

Proxies residenciais dificultam os alertas

A campanha também recorreu a proxies residenciais. Essa infraestrutura permite que o tráfego pareça originado de uma localização mais próxima da vítima ou de uma rede com características menos suspeitas.

Essa estratégia reduz a eficiência de alertas baseados somente em distância geográfica, “viagem impossível” ou mudanças bruscas de país. Uma conexão de um endereço residencial situado na mesma região do funcionário pode não gerar o mesmo nível de suspeita que um login vindo de uma infraestrutura de hospedagem localizada no exterior.

Por esse motivo, controles de identidade não devem depender exclusivamente de geolocalização. O contexto do dispositivo, o comportamento do usuário, o tipo de fluxo utilizado, a frequência de autenticação e alterações recentes no ambiente precisam ser analisados em conjunto.

Há recomendação oficial da Microsoft?

Existe orientação oficial para reduzir o risco associado ao Device Code Flow, embora não tenha sido identificada, até a publicação da análise, uma comunicação da Microsoft dedicada especificamente ao nome GhostCode.

A Microsoft considera esse fluxo de maior risco e recomenda bloqueá-lo quando ele não for necessário para as operações da organização. Quando houver uma justificativa legítima, a orientação é limitar o recurso por meio de políticas de Conditional Access, com exceções documentadas, restritas e monitoradas.

O Microsoft Entra permite criar uma política específica para bloquear o Device Code Flow. A abordagem recomendada é verificar primeiro se há utilização legítima, acompanhar os eventos de autenticação e, depois, aplicar o bloqueio de forma abrangente. Desde 1º de julho de 2026, novos tenants do Microsoft Entra com Security Defaults ativado passaram a bloquear o fluxo por padrão.

Medidas que as equipes devem adotar

Organizações que não dependem do Device Code Flow devem avaliar imediatamente seu bloqueio por Conditional Access. Antes da aplicação definitiva, é possível observar os registros de entrada ou utilizar políticas em modo report-only. Essa etapa ajuda a identificar aplicações, usuários ou processos que ainda utilizam o mecanismo.

Além do bloqueio, as equipes devem:

– revisar autenticações que utilizaram Device Code Flow;
– procurar registros de dispositivos criados recentemente;
– verificar tokens, sessões e aplicativos autorizados;
– invalidar sessões e credenciais da conta afetada;
– remover dispositivos desconhecidos do Microsoft Entra;
– analisar regras de encaminhamento e exclusão no Exchange;
– verificar alterações em caixas compartilhadas e permissões;
– revisar acessos ao SharePoint, OneDrive e Teams;
– investigar downloads e movimentações incomuns de arquivos;
– redefinir credenciais quando houver suspeita de comprometimento.

A conta envolvida no ataque deve ser tratada como potencialmente comprometida mesmo que a senha não tenha sido exposta. O usuário confirmou uma autorização que pode ter criado uma sessão persistente para o invasor.

Como melhorar a proteção contra esse tipo de fraude

O treinamento dos funcionários precisa deixar claro que uma aprovação de MFA não é automaticamente segura. Códigos de dispositivo recebidos por e-mail, mensagens ou contatos comerciais inesperados devem ser considerados suspeitos, principalmente quando a pessoa não iniciou o processo de login em outro equipamento.

As empresas também podem limitar quem tem permissão para registrar dispositivos, exigir dispositivos em conformidade e aplicar políticas de Conditional Access baseadas em risco. A autenticação resistente a phishing, como chaves de segurança compatíveis com FIDO2, oferece proteção adicional porque não depende apenas da aprovação manual de um código apresentado por um terceiro.

Outra medida importante é reduzir privilégios. Contas comuns, administrativas e de acesso a dados sensíveis devem estar separadas. Assim, mesmo que uma identidade seja comprometida, o impacto pode ser limitado.

O que observar durante a investigação

Os primeiros indícios podem aparecer como autenticações incomuns, criação inesperada de dispositivos, chamadas de API fora do padrão ou acessos a serviços que o usuário normalmente não utiliza. Também merecem atenção mudanças em regras de caixa postal, concessão de permissões, consentimento a aplicações e movimentação de arquivos em grande volume.

A linha do tempo deve ser reconstruída com precisão: recebimento da mensagem, abertura do arquivo HTML, uso do código, aprovação do MFA, registro de dispositivos, emissão de tokens e acessos posteriores. Essa sequência ajuda a diferenciar um simples evento de phishing de um comprometimento já consolidado.

O caso GhostCode demonstra que a proteção multifator precisa ser acompanhada por controles de autorização, monitoramento de dispositivos e políticas específicas para fluxos de autenticação de alto risco. Quando o usuário é induzido a aprovar a sessão errada, o MFA deixa de funcionar como barreira suficiente. O bloqueio preventivo do Device Code Flow, combinado com análise contínua de identidade e resposta rápida, é uma das principais formas de reduzir esse vetor de ataque.