O código de erro é a pista

Proofpoint documentou duas campanhas este ano que validam credenciais roubadas contra Entra ID sem nunca produzir um login bem-sucedido. A técnica é simples o suficiente para explicar em uma frase: envie uma senha para o endpoint do token com um client ID que não corresponde a nenhum aplicativo registrado e leia o erro que você recebe. Esses códigos de erro importam, mas o vazamento maior é onde cada código está na sequência de autenticação.

Três códigos, três significados diferentes

As solicitações vão para o endpoint OAuth 2.0 Resource Owner Password Credentials (ROPC): um POST contendo nome de usuário, senha e client_idExpand. Esta técnica é especificamente limitada ao ROPC, e restringi-la está entre as mitigações.

Três respostas importam:

• AADSTS50034 (UserAccountNotFoundExpand): A conta não está no diretório.
• AADSTS50126 (InvalidUserNameOrPasswordExpand): Documentado como um erro genérico que cobre qualquer falha.
• AADSTS700016: O identificador do aplicativo não foi encontrado no diretório.

AADSTS50126 não deveria discriminar entre um nome de usuário incorreto e uma senha incorreta, mas o comportamento observado os separa. Uma tentativa falha contra um nome de usuário inexistente não é registrada no log de entrada, porque o Entra só escreve uma linha no log depois de validar um nome de usuário como válido. O Entra retorna 50034 para contas ausentes e 50126 para contas presentes com senha incorreta, o que é uma distinção comportamental observada que a documentação da Microsoft não deixa clara. O escopo também importa. Essas observações aplicam-se a tenants gerenciados no endpoint de token. Tenants federados validam senhas localmente via Pass-through Authentication (PTA) ou ADFS, então o caminho do erro é diferente.

Os logs comprovam as diferenças no manuseio:

AADSTS700016 indica que um registro de aplicativo está quebrado. Visto após uma série de tentativas de autenticação com client IDs desconhecidos, confirma que o invasor possui uma senha válida.

As duas campanhas

UNK_pyreq2323 esgotou a infraestrutura AWS de 14 de janeiro de 2026 até o início de março. Gerou mais de 700.000 IDs de cliente falsificados ao randomizar os seis últimos dígitos de um identificador legítimo de aplicação first-party do Exchange Online (por exemplo, 00000002-0000-0ff1-ce00-000000XXXXXXExpand). Alvo de mais de um milhão de contas em cerca de 4.000 tenants, reutilizou cada ID falsificado em não mais que 12 contas antes de descartá-lo. Um ID de aplicação Microsoft first-party é pré-consentido em cada tenant, então IDs que mantêm esse prefixo parecem legítimos em vez de ruído.

UNK_OutFlareAZ apareceu em dezembro de 2025 e retornou em fevereiro e março de 2026, operando pela infraestrutura da Cloudflare contra mais de 2 milhões de usuários com 3,7 milhões de IDs de aplicativos falsificados.

Os dois usaram métodos de geração diferentes, e a diferença é importante para a detecção. Enquanto pyreq2323 mantinha um prefixo real e reutilizava cada ID até 12 vezes, OutFlareAZ gerava um UUIDv4 aleatório novo por solicitação, um usuário por ID, então qualquer heurística baseada em reutilização não o detecta.

(Proofpoint rastreia ambas as campanhas sob sua designação UNK_Expand, que marca clusters não atribuídos em vez de atores nomeados.)

Detecção

Os defensores viram as falhas e os bloqueios, mas não conseguiam identificar quais dessas falhas eram confirmações de credenciais. O sinal estava lá, junto com todos os usuários que digitavam a senha errada naquela manhã, mas era ilegível sem saber qual código de erro separar. A metade realmente invisível é a enumeração. Nomes de usuário inexistentes não geram nenhuma linha de log, então o reconhecimento que precede tudo o mais não deixa rastros em nenhum tenant.

Cada uma dessas solicitações é registrada nos logs de login interativo. Isso decorre da própria definição da Microsoft: IsInteractiveExpand cobre logins onde o usuário fornece um fator de autenticação, a definição menciona explicitamente senhas, e o ROPC envia uma senha.

A assinatura é um nome de aplicação em branco:

A linha dois é o que você está procurando. Combine isnotempty(AppId)Expand com isempty(AppDisplayName)Expand para isolar o caso bem formado, mas não registrado, em vez de capturar também lixo malformado.

A consulta que importa retorna comprometimentos de credenciais confirmados:

      SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "700016"
| where isnotempty(AppId) and isempty(AppDisplayName)
| project TimeGenerated, UserPrincipalName, AppId, IPAddress,
          UserAgent, AuthenticationProtocol, ResultDescription
| order by TimeGenerated asc
      

Cada linha é um par de credenciais validadas pelo Entra, então trate a saída como uma lista de redefinição de senha e revogação de sessão. Não é um ticket de registro de aplicativo, e o erro mais grave aqui é encaminhar 700016 acessos para quem possui os registros de aplicativos.

Para detecção de campanha, pivote na fonte em vez do ID do cliente:

      SigninLogs
| where TimeGenerated > ago(7d)
| where isnotempty(AppId) and isempty(AppDisplayName)
| summarize
    DistinctAppIds = dcount(AppId),
    TargetedUsers  = dcount(UserPrincipalName),
    ConfirmedCreds = countif(ResultType == "700016"),
    WrongPassword  = countif(ResultType == "50126"),
    Lockouts       = countif(ResultType == "50053"),
    UserAgents     = make_set(UserAgent, 10)
  by IPAddress, bin(TimeGenerated, 1h)
| where DistinctAppIds > 10
| order by DistinctAppIds desc
      

Focar em IPAddressExpand é intencional. Qualquer heurística baseada no limite de reutilização de 12 contas identifica pyreq2323 e ignora completamente OutFlareAZ, porque este último nunca reutiliza um ID. Ambas as campanhas parecem iguais na origem: uma origem apresentando um grande número de IDs de cliente que não resolvem nada. Manter ConfirmedCredsExpand e LockoutsExpand na mesma linha mostra o ruído ao lado dos verdadeiros comprometimentos.

O que a correção cobre e não cobre

Restringir ROPC através do Conditional Access é a decisão certa e a Proofpoint recomenda isso. Mas quero ser claro sobre o que isso proporciona.

Não afeta a enumeração. AADSTS50034 é retornado quando Entra resolve o nome de usuário, antes de qualquer validação de credenciais e dois passos antes da avaliação da política. Nenhuma política de Conditional Access pode interceptar uma resposta emitida antes da consulta da política, e nenhuma linha de log é escrita independentemente da configuração do tenant. A enumeração de nomes de usuário contra seu diretório sobrevive a todos os controles do lado do tenant, incluindo um bloqueio rígido de autenticação legada.

Uma política que bloqueia a autenticação legada retorna AADSTS53003, BlockedByConditionalAccessExpand. Pela mesma lógica de ordenação, 53003 só é alcançável após a senha ser validada, então a mensagem de erro do invasor torna-se 50126 em vez de 53003. Código diferente, mesma informação.

Referências

• Proofpoint: pesquisa sobre aplicações fantasmas
• Microsoft: Referência de códigos de erro AADSTS do Entra ID
• Microsoft: referência da tabela SigninLogs
• Microsoft: Credenciais de senha do proprietário do recurso OAuth 2.0
• Microsoft: Bloqueie a autenticação legada com Acesso Condicional