Há uma pergunta incómoda que os investigadores da Proofpoint colocam às equipas de segurança: e se um atacante conseguisse testar todas as contas da sua organização, e até confirmar quais as palavras-passe corretas, sem gerar um único registo de início de sessão bem-sucedido? É exatamente isso que uma nova técnica de evasão, batizada de OAuth client ID spoofing, permite fazer no Microsoft Entra ID — e pelo menos dois grupos de atacantes já a estão a usar em campanhas de grande escala.
Em resumo: O OAuth client ID spoofing explora o facto de o Entra ID devolver respostas de erro diferentes consoante o identificador de aplicação (client ID) enviado. Ao usar identificadores falsos mas com formato válido, os atacantes conseguem descobrir contas existentes e confirmar palavras-passe roubadas sem despoletar um início de sessão com sucesso — e, no registo, o nome da aplicação fica em branco. A Proofpoint identificou duas campanhas independentes que, juntas, visaram mais de 3 milhões de contas desde o final de 2025.
O ponto cego está nos próprios registos do Entra
Os registos de início de sessão do Entra ID são uma das principais fontes de telemetria que as equipas de segurança usam para detetar atividade maliciosa — desde tentativas de enumeração de contas a ataques de password spraying. O problema é que estes registos têm um comportamento que pode ser explorado.
Quando uma aplicação pede acesso a dados de um utilizador, recebe um identificador único global (o client ID). Esse identificador é enviado em cada pedido de autenticação e fica registado como ID da aplicação. A investigação da Proofpoint demonstrou que o Entra ID responde de forma diferente consoante esse client ID seja válido e corresponda, ou não, a uma aplicação registada — e é essa diferença que os atacantes exploram.
Como funciona o ataque, passo a passo
A técnica assenta em pedidos HTTP POST ao ponto de acesso de tokens OAuth 2.0 da Microsoft, usando o fluxo Resource Owner Password Credentials (ROPC), que permite submeter diretamente utilizador e palavra-passe. O atacante fornece um client ID com estrutura sintaticamente válida, mas que não corresponde a nenhuma aplicação real.
O código de erro devolvido (da família AADSTS) revela tudo o que o atacante precisa. Um erro AADSTS50126 indica um utilizador válido com palavra-passe errada. E, de forma reveladora, o erro AADSTS700016 — que significa “identificador de aplicação não reconhecido” — é devolvido quando o par utilizador e palavra-passe está correto. Ou seja: o atacante confirma credenciais válidas sem nunca gerar um início de sessão com sucesso.
O detalhe crítico para as equipas de defesa: quando é usado um client ID falso, não fica registado qualquer nome de aplicação. As deteções que procuram picos de tentativas associados a uma aplicação específica não veem nada, porque o campo está vazio.
Duas campanhas, mais de 3 milhões de contas visadas
A Proofpoint identificou duas grandes campanhas que adotaram a técnica de forma independente, o que sugere que o método está a entrar no reportório habitual dos atacantes, e não a ser um caso isolado.
A campanha UNK_pyreq2323, ativa de janeiro a março de 2026, distribuiu tentativas por mais de 700 000 client IDs falsos a partir de infraestrutura da Amazon Web Services (AWS). Visou mais de um milhão de contas em cerca de 4 000 organizações e o elevado volume de tentativas falhadas provocou o bloqueio de aproximadamente 28% dos utilizadores visados. O atacante limitou-se a alterar os últimos dígitos de um identificador conhecido (o da aplicação Exchange Online), reutilizando cada ID falso em até 12 utilizadores.
A segunda campanha, UNK_OutFlareAZ, começou em dezembro de 2025 e operou a uma escala ainda maior, apoiada sobretudo em infraestrutura da Cloudflare: mais de 2 milhões de utilizadores visados e 3,7 milhões de identificadores de aplicação falsos. Esta operação foi tecnicamente mais sofisticada, gerando um client ID único e totalmente aleatório para cada tentativa — uma abordagem que dificulta a correlação e a deteção.
Ambas recorreram a listas de nomes de utilizador genéricos (como dsmith ou jbrown) reutilizadas entre várias organizações — um sinal claro de enumeração automatizada em massa.
Porque é que escapa às defesas tradicionais
As ferramentas de enumeração clássicas visam aplicações first-party conhecidas, como utilitários de linha de comandos, o que gera picos de pedidos contra uma única aplicação e desencadeia alertas rapidamente. Ao fragmentar as tentativas por milhares de aplicações fictícias, os atacantes tornam a atividade muito mais difícil de correlacionar e conseguem escapar tanto a deteções por aplicação como a limites de tentativas.
Há ainda uma consequência subtil: as políticas de Acesso Condicional definidas para aplicações específicas não são acionadas por client IDs falsos. Mesmo quando a enumeração é detetada, as equipas de defesa podem não perceber que credenciais válidas foram efetivamente identificadas, deixando passar contas já comprometidas.
O que as equipas de segurança devem fazer
- Tratar as entradas dos registos de início de sessão sem nome de aplicação (ou com ID de aplicação em branco) como possíveis indicadores de client ID spoofing.
- Reconhecer que um código de erro AADSTS700016 pode sinalizar credenciais comprometidas, e não apenas uma tentativa de login falhada.
- Reforçar a autenticação multifator e resistente ao phishing, reduzindo o valor de qualquer credencial validada por este método.
- Rever a dependência do fluxo ROPC e restringir métodos de autenticação legados sempre que possível.
Porque é que isto importa em Portugal
Muitas organizações portuguesas assentam a sua identidade digital no Microsoft Entra ID, o que as coloca no mesmo perímetro de risco destas campanhas globais. A técnica é particularmente perigosa para entidades com equipas de segurança reduzidas, que dependem quase exclusivamente dos registos de início de sessão para detetar intrusões — precisamente o ponto cego explorado.
O tema cruza-se ainda com as exigências do novo regime jurídico da cibersegurança, que transpõe a diretiva NIS2 e obriga entidades essenciais e importantes a adotar deteção de incidentes e autenticação forte. Rever as regras do centro de operações de segurança para incluir a deteção de nomes de aplicação em branco é um passo concreto e de baixo custo que pode fazer a diferença.
Perguntas frequentes
O que é o OAuth client ID spoofing?
É uma técnica de evasão em que o atacante envia, nos pedidos de autenticação ao Microsoft Entra ID, um identificador de aplicação (client ID) falso mas com formato válido. Como o Entra responde de forma diferente consoante o identificador, o atacante consegue descobrir contas válidas e confirmar palavras-passe sem gerar um início de sessão bem-sucedido nos registos.
Porque é que este ataque é difícil de detetar?
Quando é usado um client ID falso, o registo de início de sessão do Entra fica sem nome de aplicação. As deteções que procuram picos de tentativas contra uma aplicação específica não veem a atividade, porque esse campo está em branco. Além disso, as políticas de Acesso Condicional definidas por aplicação não são acionadas.
Como pode a minha organização proteger-se?
Monitorizar os registos de início de sessão à procura de entradas sem nome de aplicação, tratar o código de erro AADSTS700016 como possível sinal de credenciais comprometidas, reforçar a autenticação multifator resistente ao phishing e restringir métodos de autenticação legados como o fluxo ROPC.
Esta informação tem caráter noticioso e baseia-se na investigação divulgada publicamente pela Proofpoint em julho de 2026.