Existe uma pergunta que resume o que há de mais inquietante no ConsentFix: e se o atacante nunca precisar da sua senha, nunca acionar o MFA, e ainda assim conseguir ler seu e-mail, seu SharePoint e suas conversas no Teams? É exatamente esse o mecanismo por trás dessa técnica, identificada pela empresa de segurança Push Security e documentada de forma independente por veículos como o BleepingComputer. Em vez de tentar capturar uma credencial, o ConsentFix explora a confiança que o Microsoft Entra ID deposita em um dos seus próprios aplicativos internos — o Azure CLI — para induzir a vítima a entregar, sem perceber, um código de autorização que vale tanto quanto qualquer senha roubada. O resultado é um sequestro de conta que não aparece nos indicadores que a maioria das empresas monitora, porque tecnicamente nada de errado aconteceu do ponto de vista da autenticação: a vítima realmente fez login, com sua senha e seu MFA verdadeiros, só não no lugar que pensava.
O que é o ConsentFix
O ConsentFix é uma variação do que a comunidade de segurança já vinha chamando de ClickFix — ataques que aproveitam o hábito das pessoas de seguir instruções pequenas e aparentemente inofensivas durante um fluxo de verificação online, como clicar num botão ou copiar e colar um texto. A diferença do ConsentFix é o alvo: em vez de fazer a vítima executar um comando malicioso no próprio computador, ele faz a vítima completar, sem saber, um fluxo real de autorização OAuth do Microsoft Entra ID — e depois entregar, voluntariamente, o resultado desse fluxo para o atacante.
O nome é sugestivo: “fix” remete à sensação de estar completando uma etapa de verificação de rotina — algo como resolver um CAPTCHA ou confirmar um e-mail — quando, na realidade, o usuário está entregando as chaves da própria conta. O ataque foi observado pela primeira vez publicamente em dezembro de 2025 e ganhou uma versão automatizada e mais sofisticada, chamada ConsentFix v3, documentada em maio de 2026.
A peça central do mecanismo é o Azure CLI — a ferramenta de linha de comando que administradores usam para gerenciar recursos do Azure. Como aplicativo de primeira parte da própria Microsoft, o Azure CLI já vem confiável, por padrão, em qualquer ambiente do Microsoft Entra ID: ele não exige aprovação administrativa para gerar tokens, não pode ser bloqueado ou desabilitado pelo administrador do tenant, e fica isento de várias das restrições de consentimento que se aplicam normalmente a aplicativos de terceiros. São exatamente essas características — desenhadas para tornar a vida do administrador legítimo mais fácil — que o ConsentFix explora.
Como o ataque funciona na prática
Etapa 1 — A isca chega por um canal que parece confiável
A campanha começa com um link de phishing distribuído por e-mail, resultado de busca manipulado ou site comprometido — em alguns casos entregue através de serviços legítimos como Dropbox, o que dificulta a inspeção por ferramentas de segurança. Ao clicar, a vítima é direcionada a uma página que apresenta um desafio de verificação falso, do tipo Cloudflare Turnstile, pedindo o e-mail corporativo. Esse passo não é apenas cosmético: serve para o atacante filtrar quem é um alvo real de negócio, descartando bots e pesquisadores de segurança antes de avançar com a próxima etapa.
Etapa 2 — Um fluxo de autenticação de verdade é aberto
Depois de passar pela verificação, a vítima é instruída a clicar em um botão de “Entrar” — que abre, numa nova aba, uma tela de login genuína da Microsoft, gerada para o Azure CLI. Não há nada de falso nessa tela: é o endereço real da Microsoft, usando o client ID legítimo do Azure CLI. Se a vítima já estiver autenticada no navegador — o que é comum durante o expediente de trabalho — esse login acontece de forma silenciosa, sem pedir senha nem MFA novamente, porque a sessão já provou a identidade dela mais cedo naquele dia.
Etapa 3 — O código de autorização vira uma URL que a vítima entrega sozinha
Ao concluir esse login, a Microsoft redireciona o navegador para um endereço local (localhost) que contém, na própria URL, o código de autorização OAuth gerado para aquela sessão. A instrução da página maliciosa pede que a vítima copie essa URL da barra de endereço e a cole de volta na página de “verificação” — completando, sem perceber, a entrega do código para a infraestrutura do atacante.
Etapa 4 — O atacante troca o código por acesso persistente
De posse do código, um backend automatizado — em campanhas mais recentes, orquestrado via serviços como Pipedream — troca imediatamente essa informação por tokens de acesso e de atualização junto ao endpoint de token da Microsoft. A partir daí, o atacante tem acesso à conta com o mesmo nível de permissão que o Azure CLI concede, o que inclui, dependendo do perfil da vítima, leitura de e-mails no Exchange Online, arquivos no OneDrive e no SharePoint, conversas no Teams e, em contas com privilégio elevado, possibilidade de enumerar o diretório do Entra ID ou escalar acesso dentro do Azure.
Por que o MFA, por si só, não segura esse ataque
A reação mais comum de gestores de TI ao ouvir sobre um novo ataque de identidade é perguntar se o MFA da empresa resolve o problema. Com o ConsentFix, a resposta exige mais nuance. Tecnicamente, o MFA não é “quebrado” nem contornado por uma falha de segurança — ele simplesmente já foi cumprido antes, na sessão de navegador que a vítima já tinha aberta naquele dia. O fluxo de autorização do Azure CLI aproveita essa sessão existente para gerar o código sem exigir nova verificação, porque, do ponto de vista técnico, o Entra ID entende que aquela pessoa já provou sua identidade horas antes.
Isso é bem diferente de um ataque tradicional de força bruta ou de phishing de credencial simples. A tabela abaixo resume as diferenças:
| Característica | Ataque tradicional de credencial | ConsentFix |
|---|---|---|
| Rouba senha | Sim | Não |
| Passa pelo MFA | Exige contornar ou interceptar | Aproveita sessão já autenticada — MFA não é solicitado de novo |
| Usa malware | Frequentemente | Não — usa apenas o navegador da vítima |
| Usa fluxo legítimo da Microsoft | Não | Sim — login real do Azure CLI |
| Gera alerta de login incorreto | Geralmente sim | Não — o login em si é genuíno |
| Fica visível para antivírus/endpoint | Às vezes | Raramente — nada é executado no dispositivo |
Para o contexto mais amplo de por que a autenticação multifator tradicional deixou de ser suficiente isoladamente, mesmo fora do cenário específico do ConsentFix, vale complementar com o artigo sobre por que MFA não é mais suficiente em 2026.
Quais dados podem ser comprometidos
O alcance do dano depende do que o token obtido permite acessar — e, em ambientes onde a vítima tem privilégios administrativos, esse alcance é significativo:
- Microsoft Exchange Online — leitura completa de e-mails, anexos e, em alguns casos, criação de regras de caixa de entrada que redirecionam ou ocultam mensagens específicas, uma técnica clássica de persistência pós-comprometimento
- SharePoint Online — acesso a bibliotecas de documentos, contratos e arquivos financeiros que o usuário comprometido tinha permissão de ver
- OneDrive — arquivos corporativos armazenados na conta individual, incluindo qualquer backup ou cópia de trabalho pessoal salva ali
- Microsoft Teams — histórico de conversas e arquivos compartilhados, com potencial de expor informação estratégica trocada informalmente entre equipes
Um agravante relevante: como o acesso concedido pelo Azure CLI pode incluir capacidade de enumerar o Microsoft Entra ID, contas comprometidas de usuários com algum privilégio administrativo abrem caminho para movimentação lateral dentro do ambiente Azure, não apenas para leitura de conteúdo do Microsoft 365.
ConsentFix, consent phishing e abuso de OAuth: entendendo a diferença
Vale separar três termos que aparecem frequentemente misturados em discussões sobre esse tema, porque cada um descreve uma técnica ligeiramente diferente.
Consent phishing é a categoria mais ampla e mais antiga: o atacante registra um aplicativo de terceiros — às vezes com nome parecido com uma ferramenta legítima — e convence a vítima a conceder permissões como Mail.Read, Files.Read.All ou Directory.Read.All a esse app malicioso, geralmente através de um e-mail convidando para “revisar um documento” ou “aceitar um convite de colaboração”. A vítima vê uma tela de consentimento pedindo permissões, e a decide (erroneamente) aceitar.
Abuso de OAuth (OAuth Abuse) é o termo guarda-chuva para qualquer exploração do protocolo OAuth 2.0 fora do uso pretendido — inclui tanto o consent phishing tradicional quanto técnicas mais sofisticadas de manipulação de token.
ConsentFix é uma técnica específica dentro desse universo, e sua característica distintiva é não depender de uma tela de consentimento visível para a vítima aceitar. Como o Azure CLI já é um aplicativo pré-aprovado e de primeira parte, não há tela de “este app está solicitando as seguintes permissões” para a vítima recusar — o fluxo inteiro parece (e tecnicamente é) um login legítimo do zero ao fim, com a única ação humana sendo copiar e colar uma URL. Essa ausência de uma decisão explícita de consentimento é o que torna o ConsentFix mais perigoso e mais difícil de capturar em treinamentos de conscientização tradicionais, que ensinam as pessoas a desconfiar de telas de permissão — não a desconfiar de instruções para copiar e colar um link.
A evolução resume-se numa progressão que vale ter em mente: os ataques de identidade avançaram de roubo de senha, para roubo de token, para sequestro de sessão, e agora para manipulação do próprio processo de consentimento e autorização — cada etapa exigindo menos do atacante e sendo mais difícil de detectar do que a anterior.
Como identificar sinais de comprometimento
Como o login em si é genuíno, os sinais de um ataque ConsentFix bem-sucedido não aparecem como uma tentativa de acesso falhada — aparecem em padrões mais sutis, que exigem olhar ativamente, não esperar um alerta automático óbvio:
- Concessões recentes de OAuth ao Azure CLI em horários ou de locais que não correspondem ao padrão normal de uso administrativo daquela conta
- Tokens ativos e de longa duração associados a sessões que não têm atividade correspondente de navegação humana visível
- Acesso de API a partir de endereços IP que não coincidem com o IP do login original — um padrão característico de o atacante usar o token a partir de sua própria infraestrutura, separada do dispositivo da vítima
- Movimentação lateral — leitura sequencial de múltiplas caixas de e-mail, enumeração de usuários no diretório, ou acesso incomum a recursos do Azure logo após uma concessão de token suspeita
- Compartilhamentos inesperados de arquivos do SharePoint ou OneDrive, criados sem que o usuário legítimo tenha realizado a ação
Como verificar aplicativos conectados ao Microsoft 365
A verificação mais direta que uma equipe de TI pode fazer hoje, sem esperar por nenhuma ferramenta adicional, é revisar o que já está conectado ao ambiente. O caminho no Microsoft Entra Admin Center é:
Enterprise Applications → Consent and Permissions → User Consent Settings
Nessa área é possível ver quais aplicativos têm permissões concedidas por usuários, revisar concessões recentes e, criticamente, verificar se a configuração atual permite que qualquer usuário autorize apps livremente sem revisão administrativa — que é exatamente a configuração que amplia a exposição a esse tipo de ataque.
As configurações que toda empresa Microsoft 365 deveria revisar imediatamente
User Consent Settings
Restringir ou eliminar a capacidade de usuários comuns concederem consentimento a aplicativos por conta própria é a mudança de maior impacto e menor esforço técnico disponível. Reduz drasticamente a superfície de ataque para qualquer variante de consent phishing.
Admin Consent Workflow
Em vez de simplesmente bloquear todo consentimento de usuário, o fluxo de aprovação administrativa permite que solicitações legítimas de acesso a novos aplicativos passem por revisão humana antes de serem concedidas — equilibrando segurança com a necessidade real do negócio de adotar novas ferramentas.
Conditional Access
Políticas de Acesso Condicional com Proteção de Token (Token Protection) — disponível em licenciamento Entra ID Premium P1 ou P2 — vinculam o token de acesso ao dispositivo ou sessão de origem, impedindo que um código roubado seja usado em outra máquina. Bloquear especificamente o fluxo de autenticação por código de dispositivo via Conditional Access também reduz a superfície de exploração para variantes relacionadas.
Risk-Based Access
Políticas baseadas em risco de login e de usuário, via Microsoft Entra Identity Protection, ajudam a capturar padrões anômalos de uso de token mesmo quando a autenticação original foi tecnicamente legítima.
Privileged Identity Management (PIM)
Contas administrativas são o alvo de maior valor para esse tipo de ataque — o PIM garante que privilégio elevado só existe pelo tempo estritamente necessário, reduzindo a janela de exposição mesmo se uma conta for comprometida.
Esses controles estão diretamente alinhados às boas práticas de gestão de identidade que já detalhamos no artigo sobre segurança Microsoft 365 e no artigo sobre ataques à identidade que contornam o MFA.
Como o Microsoft Entra ID ajuda a mitigar ataques como o ConsentFix
A boa notícia é que a Microsoft já disponibiliza, dentro do próprio Entra ID, a maior parte dos controles necessários — o desafio está em garantir que estejam de fato configurados, não apenas disponíveis. Os recursos mais relevantes para esse cenário específico:
- Conditional Access — controle central de políticas de acesso, incluindo a Proteção de Token mencionada acima
- Identity Protection — detecção automática de padrões de risco associados a identidades e sessões
- Risky Users e Risky Sign-ins — sinalizadores específicos que ajudam a equipe de segurança a priorizar investigação
- PIM (Privileged Identity Management) — controle de tempo de vida de privilégio administrativo
- Access Reviews — revisão periódica programada de quem tem acesso a quê, capturando concessões que deveriam ter sido revogadas há tempo
Como adotar Zero Trust para reduzir esse risco
O ConsentFix é um exemplo direto de por que a arquitetura de Zero Trust deixou de ser um conceito abstrato de segurança e passou a ser uma resposta prática a ameaças concretas. Os três princípios centrais do modelo se aplicam quase literalmente a esse cenário: verificar explicitamente significa não confiar em uma sessão só porque ela já foi autenticada uma vez naquele dia; menor privilégio significa que mesmo uma conta comprometida via ConsentFix tem seu dano limitado se não tiver acesso administrativo desnecessário; e assumir violação significa desenhar a arquitetura de segurança presumindo que, em algum momento, uma sessão será comprometida — e garantindo que isso não signifique acesso irrestrito a tudo.
Na prática, isso se traduz em cinco camadas trabalhando juntas no Microsoft 365: MFA (mesmo sabendo suas limitações contra esse ataque específico, continua necessário contra a maioria das outras ameaças), conformidade de dispositivo verificada antes de conceder acesso, Entra ID com políticas de Conditional Access robustas, Microsoft Defender monitorando comportamento pós-autenticação, e Microsoft Intune garantindo que apenas dispositivos gerenciados e íntegros acessem dados corporativos sensíveis.
Checklist: sua empresa está exposta ao ConsentFix?
Responda às sete perguntas abaixo com sim ou não:
- Usuários podem autorizar aplicativos livremente, sem revisão administrativa?
- Não existe um Admin Consent Workflow configurado?
- O MFA não está habilitado para 100% dos usuários?
- Não há revisão periódica de aplicações com acesso via OAuth?
- Existem mais de três Global Administrators no tenant?
- Não há políticas de Conditional Access configuradas?
- Não há controle de conformidade de dispositivo via Intune?
Conte quantas respostas foram sim (indicando uma lacuna de segurança):
| Respostas positivas (lacunas) | Nível de risco |
|---|---|
| 0 a 2 | 🟢 Baixo risco |
| 3 a 5 | 🟡 Atenção — vale priorizar correção |
| Mais de 5 | 🔴 Alto risco — ação recomendada com urgência |
O que um Microsoft 365 Identity Risk Assessment revela sobre essa exposição
Um checklist rápido ajuda a ter uma primeira noção, mas não substitui uma avaliação técnica completa do ambiente. Um assessment de risco de identidade examina, de forma estruturada, exatamente os pontos que o ConsentFix explora: configuração de MFA por usuário e por grupo, políticas de OAuth e consentimento, cobertura real de Conditional Access (não apenas se existe, mas se está em modo de aplicação ou apenas de relatório), contas privilegiadas e seu tempo de exposição, integração com Intune para conformidade de dispositivo, cobertura do Defender, e maturidade geral de governança de identidade.
O resultado prático desse tipo de avaliação inclui um score de maturidade comparável a benchmarks do setor, uma matriz de risco priorizada por impacto e facilidade de exploração, um relatório executivo que traduz achados técnicos para decisão de investimento, e um plano de remediação com prioridades claras — não apenas uma lista de problemas sem ordem de urgência.
Esse é o modelo de Cyber & Cloud Risk Assessment que a InfoB aplica, com foco específico em identidade, configuração do ambiente Microsoft, políticas de segurança e gestão de acesso — as mesmas dimensões que determinam se um ambiente está exposto ou protegido contra técnicas como o ConsentFix. Para o processo mais amplo de auditoria de ambiente antes de identificar esse tipo de lacuna, o artigo sobre auditoria Microsoft 365 detalha as dimensões avaliadas.
Para fechar
O ConsentFix não é só mais uma técnica de phishing com nome novo — é evidência de uma mudança de direção nos ataques de identidade. Grupos ofensivos deixaram de gastar energia tentando adivinhar ou capturar senhas e passaram a mirar diretamente na camada de confiança que sustenta tudo em torno dela: tokens, sessões, consentimentos e a fé implícita que a arquitetura de identidade deposita em aplicativos “de dentro de casa”. Isso significa que qualquer empresa que meça sua segurança de identidade apenas pela pergunta “temos MFA habilitado?” está respondendo a uma pergunta de dois anos atrás, não à ameaça de agora.
Se sua empresa usa Microsoft 365 e ainda não revisou as configurações de consentimento OAuth e Conditional Access recentemente, o checklist acima é um ponto de partida honesto — e, se o resultado te preocupou, a InfoB pode ajudar a transformar essa preocupação em um plano concreto.
Perguntas frequentes
O que é o ataque ConsentFix?
É uma técnica de phishing que rouba um código de autorização OAuth em vez de uma senha. A vítima copia e cola, numa página maliciosa, um link contendo esse código — gerado por um app de primeira parte da Microsoft, geralmente o Azure CLI, que já é confiável e não pode ser bloqueado. Com o código, o atacante obtém acesso sem nunca ter visto a senha real.
O ConsentFix consegue contornar o MFA?
Na prática, sim, mas de um jeito específico: se a vítima já está autenticada no navegador, o MFA não é pedido de novo durante o fluxo, porque o Azure CLI aproveita essa sessão já aberta. Não é um bypass técnico do MFA — o ataque simplesmente acontece depois que o MFA já foi cumprido naquele dia.
É possível bloquear o app usado pelo ConsentFix?
Não diretamente. O Azure CLI é um app de primeira parte presente por padrão em todo tenant do Entra ID, e administradores não conseguem removê-lo como fariam com um app de terceiros suspeito. A defesa precisa vir de Conditional Access com Proteção de Token, bloqueio de fluxos de código de dispositivo, e monitoramento de concessões OAuth incomuns.
Minha empresa já foi atacada por ConsentFix sem eu saber?
É possível — esse é justamente o motivo de preocupação. Como o ataque não gera tentativa de login com senha errada, os sinais ficam nos logs de concessão OAuth e no padrão de uso de token, não em alertas óbvios. Revisar aplicativos conectados no Microsoft Entra Admin Center é o primeiro passo prático para verificar.