Josimar Hedler
Índice
Uma nova técnica de phishing baseada em OAuth chamada ConsentFix está chamando a atenção da comunidade de segurança. Diferente dos ataques tradicionais que buscam roubar senhas, essa abordagem explora fluxos legítimos de autorização para obter tokens OAuth válidos, permitindo acesso a recursos sem a necessidade de credenciais ou bypass direto de MFA.
O ataque combina engenharia social com o fluxo de consentimento de aplicações, enganando usuários para gerar códigos de autorização que podem ser trocados por access tokens e refresh tokens. Isso evidencia uma mudança importante no cenário de ameaças: o foco dos atacantes está migrando da autenticação para a autorização, explorando a confiança nos mecanismos de OAuth utilizados em plataformas como o Microsoft Entra ID e serviços do Microsoft.
O que é e como funciona um ataque de phishing OAuth do ConsentFix?
O ConsentFix é uma técnica recente de phishing baseada em OAuth que explora fluxos legítimos de autorização para obter acesso a contas sem roubar credenciais diretamente. Nesse tipo de ataque, o usuário é levado a interagir com uma página maliciosa que simula um processo de correção ou verificação de autenticação. A vítima é então direcionada para um fluxo de login legítimo do Microsoft Entra ID, onde realiza a autenticação normalmente. Durante esse processo, é gerado um authorization code do OAuth, que faz parte do mecanismo padrão de autorização utilizado por aplicações integradas.
Em seguida, por meio de engenharia social, o usuário é induzido a copiar ou compartilhar esse código ou uma URL específica contendo o código de autorização. O atacante utiliza esse código para trocá-lo por tokens OAuth válidos, como access tokens e refresh tokens, que permitem acessar APIs e recursos do ambiente da Microsoft, incluindo serviços do Microsoft 365. Como o processo de autenticação ocorre de forma legítima pelo próprio usuário, controles tradicionais como MFA não impedem o ataque, pois o que está sendo explorado não é a autenticação em si, mas o fluxo de autorização do OAuth.
Por que o ConsentFix é tão perigoso?
O ConsentFix é considerado especialmente perigoso porque não depende do roubo de credenciais, como ocorre em ataques de phishing tradicionais. Em vez disso, ele explora o próprio fluxo de autorização do OAuth, permitindo que o atacante obtenha tokens de acesso válidos após a autenticação legítima do usuário. Isso significa que mesmo ambientes protegidos com MFA, passkeys ou outros mecanismos de autenticação forte ainda podem ser impactados, pois o ataque não quebra a autenticação ele abusa da etapa de consentimento e autorização dentro de plataformas como o Microsoft Entra ID.
Outro fator que aumenta o risco é que o ataque utiliza infraestrutura legítima e fluxos confiáveis, o que dificulta sua detecção por controles tradicionais de segurança. Como o login acontece em páginas reais da Microsoft, muitas soluções de proteção baseadas apenas em detecção de phishing ou credenciais comprometidas podem não identificar a atividade como maliciosa. Na prática, o atacante passa a operar com tokens válidos, podendo acessar APIs e recursos corporativos como se fosse o próprio usuário, o que amplia o impacto potencial do comprometimento.
Como os usuários são atraídos para o ataque ConsentFix?
Em campanhas relacionadas ao ConsentFix, os atacantes utilizam páginas web manipuladas para iniciar o processo de comprometimento. Essas páginas podem aparecer em resultados de busca, em links distribuídos por mensagens ou até mesmo dentro de sites legítimos que foram comprometidos. Quando a vítima acessa o conteúdo, é apresentada a uma suposta etapa de verificação necessária para continuar navegando, algo que visualmente pode lembrar mecanismos comuns de validação usados por serviços de proteção contra bots.
Durante esse processo, o usuário é incentivado a informar seu e-mail ou realizar uma ação para confirmar o acesso ao conteúdo. A página então identifica se o domínio informado pertence a uma organização corporativa ou educacional. Caso o domínio esteja dentro do perfil de interesse dos atacantes, a vítima é direcionada para um fluxo real de autenticação do Microsoft Entra ID. A partir daí, técnicas de engenharia social levam o usuário a concluir etapas que acabam expondo dados do processo de autorização OAuth, permitindo que os invasores obtenham tokens válidos para acessar serviços da Microsoft.
Criando uma estratégia para mitigar esse ataque.
Ataques como o ConsentFix se aproveitam de aplicações confiáveis já presentes no ambiente e de fluxos legítimos do OAuth, o que reduz a eficácia de mecanismos tradicionais voltados apenas para detecção de phishing. Por esse motivo, a estratégia de defesa precisa ir além da proteção de credenciais e considerar como permissões e autorizações de aplicativos são concedidas dentro do Microsoft Entra ID. As medidas de proteção devem ser definidas levando em conta o nível de risco aceitável, as necessidades operacionais e o contexto de cada organização.
Outro ponto importante é entender como cada aplicativo se comporta em relação às políticas de Acesso Condicional. Nem todas as aplicações nativas da Microsoft são tratadas da mesma forma por esses controles, o que exige abordagens diferentes de proteção. Por isso, as estratégias de mitigação podem ser organizadas em dois conjuntos principais: medidas aplicáveis a aplicativos que são plenamente governados por políticas de Acesso Condicional e medidas voltadas a aplicativos que, por limitações técnicas ou configuração, não são afetados por essas políticas.
Aplicando medidas de segurança para proteger e reduzir o risco de uso indevido de tokens.
Essa abordagem é considerada uma das formas mais eficazes de reduzir o risco associado ao ConsentFix. A proteção baseada em token utiliza o conceito de proof of possession (PoP), que associa o token ao dispositivo onde a autenticação foi realizada. Dessa forma, o token passa a depender de um elemento criptográfico vinculado ao ambiente de origem, dificultando seu uso fora desse contexto.
Na prática, mesmo que um invasor consiga obter um authorization code por meio de técnicas de phishing, ele não conseguirá utilizá-lo em outro dispositivo para gerar tokens válidos. Isso ocorre porque o processo de troca do código exige a comprovação criptográfica vinculada ao dispositivo original, impedindo que o código seja reutilizado em um sistema controlado pelo atacante.
Atenção: As implementações apresentadas em nossos artigos foram desenvolvidas com base em documentações oficiais e nas boas práticas recomendadas pela Microsoft. Entretanto, enfatizamos que qualquer implementação deve ser previamente testada em ambientes de homologação ou testes para garantir a segurança e a estabilidade do ambiente de produção
Pré-requisitos
Usar esse recurso requer licenças P1 Microsoft Entra, você pode consultar mais sobre licenciamento do Microsoft Entra ID aqui.
Os clientes com licenças Microsoft 365 Business Premium também podem usar recursos de Acesso Condicional.
Após entender os conceitos, vamos partir para o Hands-On.
Vá para o portal do Microsoft Entra ID
- Expanda a opção do Entra ID
- Desça ate Conditional access
- Create new policy
Defina um nome descritivo, em Assingments selecione todos os usuários
Atenção: Se for necessário excluir alguma conta dessa política, o ideal é que isso seja evitado sempre que possível, mantendo todos os usuários protegidos pelo controle. No entanto, durante a fase inicial de testes, pode ser útil aplicar a política primeiro em um usuário administrador específico para avaliar como ela se comporta no ambiente. Dessa forma, é possível validar o impacto da configuração antes de expandi-la para os demais usuários. Caso ocorra algum comportamento inesperado, apenas essa conta de teste será afetada, permitindo ajustes na política sem impactar o restante do ambiente.
Em Target resources, selecione Office 365, essa opção representa um conjunto de serviços do Microsoft 365, incluindo Exchange Online, SharePoint Online, Microsoft Teams e OneDrive, garantindo que a política seja aplicada aos principais workloads utilizados pelos usuários.
- Em Conditions
- Procure por Device Plataforms
- Marque Configure como YES
- Select device plataform
- Windows e deois em clique em done.
Em Device platforms, selecione Windows, a proteção de token depende de recursos de segurança do dispositivo para associar o token à origem da autenticação, atualmente, o suporte mais consistente para esse mecanismo está em dispositivos Windows, especialmente quando registrados ou gerenciados no ambiente.
- Ainda em Conditions
- Selecione Client apps
- Em configuere marque YES
- Selecione Mobile apps and desktop clients, depois clique e Done
Por que selecionar Mobile apps and desktop clients isso aplica a política aos clientes modernos que utilizam autenticação OAuth, como Outlook, Teams e outros aplicativos do Microsoft 365. Isso garante que a política seja aplicada a aplicativos que suportam os mecanismos de segurança necessários, como proteção de token
Em Access controls -> Session, habilite Require Token Protection, essa opção força o vínculo do token ao dispositivo que realizou a autenticação, dessa forma, mesmo que um token seja interceptado por um atacante, ele não poderá ser reutilizado em outro dispositivo.
Atenção: No Windows, a proteção de tokens funciona apenas com aplicativos que utilizam um broker de autenticação compatível. Caso um cliente não ofereça suporte a esse mecanismo, ele não conseguirá atender ao requisito da política e o acesso ao recurso será bloqueado.
Esse detalhe é importante, pois explica por que alguns aplicativos funcionam enquanto outros não quando a Token Protection é ativada. Muitos clientes antigos ou que não utilizam broker simplesmente não conseguem cumprir o requisito e acabam sendo bloqueados pela política.
Importante: essa funcionalidade não se aplica a todos os recursos do ambiente, parte dos aplicativos nativos da Microsoft ainda não oferece compatibilidade completa com esse mecanismo de controle, além disso, o funcionamento depende do uso do Windows Authentication Manager (WAM) como intermediário de autenticação, e algumas versões do PowerShell podem precisar de ajustes ou configurações adicionais.
Também é necessário considerar o impacto operacional dessa configuração, dependendo do cenário, ela pode interferir no acesso de usuários a serviços do Microsoft 365. Por isso, o ideal é validar o comportamento da política em um grupo piloto ou ambiente de testes antes de ampliar a implementação para toda a organização.
Limitar o acesso a aplicativos nativos específicos apenas a usuários autorizados
Se o mecanismo de proteção de tokens não abranger todos os serviços utilizados no ambiente, uma alternativa eficaz é limitar quem pode utilizar ferramentas de linha de comando. Ao impedir que usuários sem necessidade operacional acessem essas utilidades, a área exposta para exploração diminui consideravelmente.
Vamos ver como transformar essas aplicações em pontos de controle, ajudando a evitar que códigos de autorização ou tokens sejam utilizados de forma indevida.
Ainda no portal do Microsoft Entra ID
Desça ate -> Entra ID -> Conditional Access -> Create new policy, de um nome sugestivo, em Assignments, selecione todos os usuário, e em Exclude selecione um grupe de usuários ou usuários específicos, contas de Brek Glass se desejar.
Para este exemplo, foram selecionados os recursos Azure Resource Manager e Azure Resource Graph, pois são APIs administrativas frequentemente utilizadas por ferramentas de automação e linha de comando no ambiente Azure.
Nota: No entanto, a escolha dos recursos deve sempre ser avaliada de acordo com a realidade de cada organização. Dependendo do ambiente, outras aplicações administrativas ou APIs podem precisar ser incluídas na política para garantir uma cobertura adequada de segurança.
Em Target Resouces, clique em Select resouces, depois em Select specific resources selecione os Recursos que deseja bloquear
Em Access controls, ->Grant -> selecione Block access, depois clique em Select, deixe esse política em modo Report-only, assim você pode analisar o impacto dela como se estivesse aplicada realmente.
É importante identificar quais usuários realmente precisam desse tipo de acesso e excluí-los da política quando necessário. Caso contas utilizadas por automações ou processos operacionais não sejam consideradas, pode haver impacto no funcionamento de scripts, integrações ou rotinas administrativas.
Além disso, esse modelo exige um controle administrativo constante, pois o grupo de exceção precisa ser revisado e mantido atualizado ao longo do tempo para refletir corretamente as necessidades do ambiente.
Conclusão
Os exemplos apresentados ao longo deste artigo mostram como um fluxo de autenticação legítimo pode ser explorado quando não existe visibilidade ou controle adequado sobre o uso de tokens e aplicações administrativas. Nos prints analisados, é possível observar como políticas de Acesso Condicional podem ser configuradas para reduzir a superfície de ataque, restringindo o acesso a APIs administrativas e aplicando controles adicionais sobre o processo de autenticação.
O ataque ConsentFix reforça um ponto importante da arquitetura de segurança moderna: a proteção de identidade não deve se limitar apenas à autenticação do usuário. Em ambientes baseados em OAuth, a segurança também depende de como tokens são emitidos, utilizados e controlados dentro do ambiente.
Por esse motivo, organizações que utilizam Microsoft Entra ID devem adotar uma abordagem arquitetural que combine múltiplas camadas de proteção, como políticas de Acesso Condicional, controle de permissões administrativas, monitoramento de autenticações e mecanismos de proteção de tokens. Esses controles ajudam a reduzir significativamente o risco de abuso de fluxos legítimos de autenticação.
Link de referência: What is Conditional Access?
Link de referência: Token Protection in Microsoft Entra Conditional Access
Chegamos ao final de mais um artigo, e você ouviu falar sobre ConsentFix? Compartilhe sua experiência, quais desafios encontrou?… faça parte de jornada você também.