Atores de ameaça exploram uma lacuna na telemetria de login do Microsoft Entra ID para validar credenciais roubadas e enumerar usuários sem gerar eventos de entrada bem-sucedidos, evadindo alertas tradicionais.
| Componente | Microsoft Entra ID (Azure AD), endpoint de token OAuth 2.0, fluxo ROPC |
| Vetor | Envio de requisições HTTP POST com parâmetro client_id falsificado (spoofing) para inferir validade de usuário e senha através de códigos de erro AADSTS, sem gerar logs de sucesso |
| Impacto | Validação em escala de credenciais comprometidas, evasão de detecção baseada em nome de aplicativo, travamento de contas (lockout) e potencial acesso inicial não autorizado |
| Prioridade | Desabilitar o fluxo de autenticação ROPC onde possível e monitorar logs de sign-in com campos de nome de aplicativo em branco |
Uma nova técnica de evasão de telemetria, denominada spoofing de ID de cliente OAuth, está sendo ativamente utilizada por pelo menos dois grupos distintos de atores de ameaça para validar credenciais roubadas em ambientes de nuvem. O ataque explora uma lacuna no comportamento do serviço de token do Microsoft Entra ID, que retorna respostas de erro diferentes dependendo da validade das credenciais fornecidas, mesmo quando o identificador do aplicativo (client ID) é inválido ou falso. Essa característica permite que adversários verifiquem listas de usuários e senhas em grande escala sem que um evento de 'login bem-sucedido' seja registrado nos logs de auditoria convencionais.
A metodologia elimina a necessidade de um aplicativo OAuth registrado e real para realizar a autenticação. Ao manipular o campo client_id nas requisições, os atacantes conseguem contornar mecanismos de detecção que se baseiam na identificação de tráfego anormal para aplicativos específicos. Como o ID do cliente não corresponde a uma aplicação legítima, os registros de login não exibem o nome do aplicativo, dificultando a visualização da atividade maliciosa em painéis de segurança padrão e permitindo que a varredura de credenciais ocorra de forma stealth.
O ataque utiliza o fluxo de concessão de Credenciais de Senha do Proprietário do Recurso (ROPC), que permite a troca direta de credenciais (usuário e senha) por um token de acesso via requisição HTTP POST. O ponto crítico da exploração reside na injeção de um identificador de cliente (GUID) falsificado no parâmetro 'client_id'. Pesquisas indicam que o serviço de token do Entra ID não rejeita imediatamente a requisição se o client_id for um UUIDv4 sintaticamente válido, mesmo que não corresponda a nenhum aplicativo existente no diretório.
Ao processar a tentativa de login, o serviço responde com códigos de erro padrão do AADSTS (Azure Active Directory Security Token Service). A análise dessas respostas permite que o script do atacante diferencie entre cenários de 'usuário não encontrado', 'senha incorreta' ou 'acesso concedido', realizando assim a enumeração de contas e a validação de senhas. Como o client_id é forjado, o evento de log resultante contém o ID do aplicativo (o UUID falso), mas deixa o campo 'Nome do Aplicativo' em branco. Isso fragmenta a telemetria, pois cada requisição pode usar um UUID diferente, impedindo que sistemas de detecção identifiquem um volume de falhas concentrado em um único aplicativo conhecido.
A técnica foi identificada em duas grandes campanhas independentes observadas no final de 2025 e início de 2026, classificadas como UNK_OutFlareAZ e UNK_pyreq2323. O grupo UNK_OutFlareAZ iniciou suas operações em dezembro de 2025, utilizando infraestrutura da Cloudflare para direcionar ataques contra mais de 2 milhões de usuários. Este ator adotou uma abordagem de geração de UUIDs aleatórios para cada requisição, pulverizando a tentativa de autenticação entre milhões de 'aplicativos' fictícios. A metodologia de enumeração seguiu uma ordem alfabética, sugerindo o uso de wordlists pré-compiladas para descoberta de usuários.
Já a campanha UNK_pyreq2323, ativa de janeiro a março de 2026, operou a partir de infraestrutura da Amazon Web Services (AWS) e focou em aproximadamente 1 milhão de contas distribuídas por quase 4.000 tenants (locais). A tática deste grupo diferia ao modificar apenas os dígitos finais de IDs de aplicativos conhecidos e reutilizar esses IDs modificados em tentativas contra até 12 usuários diferentes. Devido à alta volume de tentativas de senha falhas, cerca de 28% dos usuários alvo sofreram bloqueios de conta (account lockout), o que pode gerar negação de serviço e chamar atenção, embora a validação das credenciais tenha ocorrido de forma disfarçada.
A principal superfície atacada são os locatários do Microsoft Entra ID que ainda permitem o uso do fluxo de autenticação ROPC. Organizações que dependem de autenticação herdada ou scripts legítimos baseados em usuário/senha são mais suscetíveis, pois o ROPC não suporta nativamente a imposição de Autenticação Multifator (MFA) interativa, confiando apenas na força da senha. A exploração afeta a capacidade de defesa baseada em telemetria, pois os controles comuns de Acesso Condicional que visam aplicativos específicos tornam-se ineficazes, visto que o client_id spoofing não corresponde a nenhum objeto de política real.
- Ambientes Microsoft Entra ID com autenticação por senha permitida (ROPC)
- Logs de signIn onde o campo 'Nome do Aplicativo' está ausente, mas o 'ID do Aplicativo' presente
- Políticas de Acesso Condicional que não cobrem tentativas de login de baixo nível ou sem contexto de aplicativo
A detecção dessa atividade requer uma mudança de foco dos alertas tradicionais baseados em 'aplicativo' para alertas baseados em padrões de comportamento e anomalias nos campos de identificação. As equipes de segurança devem procurar por uma alta concentração de eventos de falha de login (códigos AADSTS 50126 ou 50034) originados de endereços IP desconhecidos, proxies públicos ou infraestruturas de nuvem (como AWS e Cloudflare), onde o campo de nome do aplicativo esteja vazio. A presença de milhares de IDs de aplicativos únicos gerando falhas para um conjunto limitado de usuários é um indicador forte (IOC) de spoofing de ID de cliente.
- Investigar logs de signIn com 'AppDisplayName' vazio e 'AppId' preenchido com GUIDs aleatórios
- Correlacionar falhas de login de múltiplos IDs de aplicativos distintos para as mesmas identidades de usuário
- Monitorar tentativas delogin provenientes de User-Agens atípicos associados a ferramentas de automação ou bibliotecas Python comuns
- Alertar sobre picos de erros AADSTS que indicam validação de credenciais sem sucesso subsequente
A ação defensiva primária é a desabilitação do fluxo de autenticação ROPC no ambiente do Microsoft Entra ID. Ao bloquear esse método, a organização força o uso de fluxos de autenticação mais modernos e seguros, que exigem interação do usuário e suportam MFA, neutralizando a eficácia de ataques de stuffing de credenciais. Caso o ROPC seja estritamente necessário para legados, recomenda-se restringir seu uso a sub-redes específicas ou dispositivos gerenciados e implementar políticas rigorosas de bloqueio de conta para limitar o impacto de tentativas de adivinhação de senha.
- Desabilitar o fluxo de autenticação ROPC para todos os usuários, exceto aqueles com necessidade crítica de negócioJustificada
- Implementar Acesso Condicional para bloquear requisições de autenticação de locais de rede não confiáveis ou IPs de saída pública de provedores de nuvem
- Configurar políticas de proteção contra enumeração de identidade do Microsoft Entra ID, quando disponível
- Revisar frequentemente logs de diagnóstico para identificar IDs de aplicativos fictícios antes que a varredura progrida para a fase de exploração
0 Comentários