Ataque ConsentFix: Como contornar MFA e sequestrar contas Microsoft via phishing OAuth

Uma nova e altamente eficaz técnica de phishing, informalmente chamada de 'ConsentFix' pela comunidade de segurança, está contornando com sucesso a autenticação baseada em senha e a autenticação multifator (MFA) para sequestrar contas de usuário da Microsoft. Este vetor de ataque representa uma mudança de paradigma, passando do roubo de credenciais para a manipulação do fluxo de concessão de autorização OAuth 2.0, um pilar do single sign-on (SSO) moderno e da integração de aplicativos.

A cadeia de ataque começa com um e-mail de phishing direcionado, SMS ou mensagem projetada para criar uma sensação de urgência. A vítima é direcionada para uma página de phishing profissionalmente elaborada que imita uma tela de login legítima da Microsoft. Crucialmente, esta página não é projetada para coletar nomes de usuário e senhas. Em vez disso, ela inicia uma solicitação de autorização OAuth 2.0 legítima para a plataforma de identidade da Microsoft (login.microsoftonline.com).

Quando o usuário clica em 'Entrar' nesta página enganosa, ele é redirecionado para o portal de login genuíno da Microsoft—um detalhe que muitas vezes tranquiliza as vítimas em potencial. O usuário então insere suas credenciais e completa qualquer desafio MFA, como aprovar uma notificação push ou inserir um código de um aplicativo autenticador. Neste ponto, as verificações de segurança tradicionais são satisfeitas.

A decepção crítica ocorre em seguida. Após a autenticação bem-sucedida, a Microsoft apresenta uma tela de consentimento OAuth pedindo ao usuário para conceder permissões a um aplicativo. O atacante registrou um aplicativo malicioso multilocatário no Azure, dando-lhe um nome convincente como 'Microsoft Security Suite', 'Visualizador de Documentos da Empresa' ou outro título plausível. A solicitação de permissão pede acesso significativo, como Mail.Read (ler e-mail), Calendars.ReadWrite (ler e gravar calendários), Contacts.Read (ler contatos), ou até mesmo User.Read.All (ler todos os perfis de usuário).

A maioria dos usuários, tendo acabado de completar o MFA e vendo a interface familiar da Microsoft, clica instintivamente em 'Aceitar' para prosseguir, acreditando que faz parte de uma atualização ou integração necessária. Ao conceder consentimento, o usuário autoriza o aplicativo do atacante a acessar os dados de sua conta Microsoft via Microsoft Graph API. A plataforma da Microsoft então emite um código de autorização para o aplicativo malicioso, que é trocado por um token de acesso e, mais importante, um token de atualização de longa duração.

Este token de atualização é a joia da coroa para o atacante. Ele permite gerar novos tokens de acesso de forma independente, mantendo acesso persistente à caixa de correio, OneDrive, calendário e contatos da vítima sem nunca mais precisar da senha ou MFA. A conta está efetivamente comprometida. O atacante pode então usar esse acesso para comprometimento de email comercial (BEC), exfiltração de dados, movimento lateral dentro de uma organização ou lançar mais campanhas de phishing de uma conta confiável.

Por que este ataque é particularmente eficaz:

1. Contorna o MFA: O usuário completa legitimamente o MFA no site real da Microsoft. O ataque explora o que acontece após a autenticação.
2. Explora a confiança na interface: Os usuários estão condicionados a confiar em pop-ups de autenticação da Microsoft. Os atacantes abusam dessa confiança apresentando uma solicitação de consentimento maliciosa imediatamente após um fluxo de login legítimo.
3. Sorrateiro e persistente: Nenhuma alteração de senha é necessária, então a vítima pode não notar nenhuma anomalia. O acesso persiste via tokens de atualização, que são mais difíceis para os usuários revogarem, pois não são tão visíveis quanto sessões ativas.
4. Difícil de detectar: O site de phishing inicial pode usar HTTPS e ter um domínio convincente. O núcleo do ataque aproveita a própria infraestrutura da Microsoft, dificultando que filtros de rede o bloqueiem.

Estratégias de mitigação e defesa:
Para usuários finais e administradores, a vigilância é a primeira linha de defesa. Os usuários devem ser treinados para tratar telas de consentimento OAuth com a mesma suspeita que páginas de login. Eles devem revisar cuidadosamente o nome do aplicativo, o editor e a lista de permissões solicitadas antes de conceder acesso. Uma solicitação para 'Ler todos os seus e-mails' de um aplicativo 'Visualizador de Documentos' desconhecido é um grande alerta vermelho.

As organizações podem tomar medidas proativas:

• Revisar e restringir aplicativos OAuth: Os administradores devem auditar regularmente os aplicativos consentidos no portal do Azure AD (Azure Active Directory > Aplicativos empresariais). Aplicativos suspeitos ou desnecessários devem ser revogados imediatamente.
• Implementar Controle de Aplicativo de Acesso Condicional: Usando soluções como o Microsoft Defender for Cloud Apps, os administradores podem monitorar e controlar sessões de usuário com aplicativos de terceiros, bloqueando o acesso ou exigindo verificação adicional para aplicativos de alto risco.
• Aproveitar as Restrições de Locatário: Para organizações, configurar restrições de locatário do Azure AD pode impedir que os usuários concedam consentimento a aplicativos de locatários não confiáveis.
• Desabilitar o consentimento do usuário: Em ambientes de alta segurança, os administradores podem desativar completamente o consentimento do usuário, exigindo que todas as permissões de aplicativos sejam revisadas e concedidas por um administrador de TI.
• Monitoramento aprimorado: Configurar alertas para quando os usuários concederem permissões de alto privilégio a aplicativos novos ou desconhecidos.

O dilema do 'ConsentFix' ressalta uma verdade fundamental na cibersegurança: à medida que as defesas em torno de um vetor (senhas e MFA) se fortalecem, os atacantes inovarão e mudarão o foco para explorar outros. Neste caso, eles visam a lacuna psicológica e processual entre a autenticação bem-sucedida e o acesso autorizado. Defender-se contra isso requer uma combinação de controles técnicos, educação contínua do usuário e uma postura de segurança proativa que assuma que os prompts de consentimento podem ser transformados em arma.