Consent phishing: apps OAuth maliciosos que roubam acesso sem senha

O que é consent phishing e por que ele não precisa da sua senha

O phishing tradicional quer roubar credenciais. O usuário recebe um e-mail falso, abre uma página parecida com a da Microsoft e digita login e senha, que vão direto para o criminoso. Por isso as empresas investiram em autenticação multifator (MFA), filtros de e-mail e treinamento. O consent phishing, também chamado de concessão ilícita de consentimento, segue outro caminho. O atacante não pede a senha. Ele pede uma permissão.

O golpe usa o OAuth 2.0, o mesmo padrão que permite a um aplicativo legítimo, como um agendador de reuniões ou um assinador de documentos, acessar o calendário ou os arquivos do usuário sem conhecer a senha dele. O atacante cadastra um aplicativo no Microsoft Entra ID (antigo Azure AD) com nome e logotipo confiáveis, como "Visualizador de PDF", "Office Secure Docs" ou "Assinatura Digital", e envia o link de autorização para a vítima. A tela que aparece é real e está hospedada no domínio da Microsoft. Ela apenas pergunta se o usuário quer conceder acesso àquele aplicativo.

Quando o usuário clica em Aceitar, a Microsoft emite tokens de acesso para o aplicativo. A partir daí, o criminoso lê os e-mails, baixa arquivos do OneDrive e do SharePoint, consulta contatos e, dependendo das permissões, envia mensagens em nome da vítima. Nada disso exige a senha, e o acesso continua mesmo que a senha seja trocada logo depois.

Como o ataque funciona, passo a passo

O consent phishing engana porque, do ponto de vista técnico, quase tudo nele é legítimo. A página de login é verdadeira, o certificado é verdadeiro e o fluxo de autorização é o mesmo que milhões de aplicativos usam todos os dias. O que é falso é a intenção de quem pede o acesso. Uma campanha típica segue este roteiro:

1. Registro do aplicativo: o atacante cria um app multilocatário em um tenant próprio, ou em um tenant comprometido, com nome e ícone que imitam ferramentas corporativas.
2. Escolha das permissões: ele solicita escopos como Mail.Read, Mail.Send, Files.ReadWrite.All, Contacts.Read e, quase sempre, offline_access, que gera um token de atualização e mantém o acesso por semanas ou meses.
3. Isca: a vítima recebe um e-mail sobre "documento compartilhado", "fatura pendente" ou "nova política de RH", com um link que leva à tela oficial de consentimento da Microsoft.
4. Login legítimo: o usuário entra com a própria conta e, se houver MFA, aprova a notificação no celular normalmente.
5. Consentimento: aparece a lista de permissões e o usuário clica em Aceitar, muitas vezes sem ler.
6. Exploração: com os tokens em mãos, o atacante acessa a Microsoft Graph API, extrai dados, procura conversas financeiras e prepara fraudes de pagamento (BEC) ou novos ataques contra clientes e fornecedores.

Tudo acontece em poucos segundos e não deixa nenhum sinal claro para o usuário. Para ele, foi só mais uma tela da Microsoft pedindo autorização, algo que ele já viu dezenas de vezes ao conectar aplicativos do dia a dia.

Por que MFA e troca de senha não resolvem

Muitos gestores de TI ficam surpresos ao descobrir que o MFA não protege contra esse ataque. A explicação é simples: o MFA confirma que quem está fazendo login é o próprio usuário, e no consent phishing é mesmo o usuário quem faz login. A segunda etapa de autenticação funciona exatamente como deveria. O problema surge depois, quando esse usuário autenticado entrega uma permissão duradoura para um terceiro.

A troca de senha também não basta, o que é ainda mais perigoso. Os tokens OAuth concedidos a um aplicativo ficam ligados a uma concessão de permissão (o chamado OAuth2PermissionGrant), e essa concessão não depende da senha. Enquanto ela existir, o aplicativo pode renovar os próprios tokens e continuar acessando a caixa de correio. É comum a equipe de TI resetar a senha, confirmar o MFA, dar o incidente por encerrado e o atacante continuar lendo os e-mails da diretoria por meses.

No consent phishing, a senha nunca foi o alvo. Enquanto o consentimento não for revogado, o atacante continua dentro, com MFA ativo e senha nova.

Por isso a defesa precisa estar no lugar certo: no controle de quem pode conceder permissões a aplicativos e no monitoramento contínuo dos aplicativos que já têm acesso ao ambiente.

Sinais de alerta: como reconhecer um app OAuth malicioso

Treinar os usuários continua sendo importante, e eles precisam saber que uma tela de consentimento merece tanta atenção quanto um pedido de senha. Na tela de permissões da Microsoft, alguns sinais indicam que algo está errado:

• Editor não verificado: aplicativos legítimos de empresas conhecidas costumam exibir o selo de editor verificado. A ausência dele, somada a um nome genérico, é um alerta. O selo sozinho, porém, não garante nada, porque já houve campanhas que abusaram de contas de parceiro comprometidas para obtê-lo.
• Permissões desproporcionais: um "visualizador de PDF" não precisa ler, enviar e excluir e-mails nem acessar todos os arquivos da organização.
• Acesso contínuo: a frase "manter acesso aos dados aos quais você concedeu acesso" indica o escopo offline_access, que dá persistência.
• Contexto inesperado: o consentimento surgiu depois de clicar em um link recebido por e-mail, e não ao instalar uma ferramenta que você mesmo procurou.
• Nome e domínio incoerentes: o aplicativo diz ser de uma empresa, mas o domínio de redirecionamento ou o editor exibido não tem relação com ela.
• Urgência na mensagem: "documento expira hoje", "assinatura pendente" ou "acesso será bloqueado" são táticas clássicas de pressão.

Mesmo assim, não dá para deixar a decisão só nas mãos do usuário. Uma única pessoa que aceite o pedido já basta para expor a caixa de correio inteira e, a partir dela, toda a rede de contatos da empresa. A proteção real vem da configuração do tenant.

Como bloquear apps não autorizados no Microsoft 365

O Microsoft Entra ID oferece controles nativos para eliminar boa parte do risco. O objetivo é tirar do usuário comum o poder de conceder permissões sensíveis e criar um processo formal para que aplicativos legítimos continuem sendo aprovados sem travar o trabalho. Uma configuração recomendada inclui:

1. Restringir o consentimento do usuário: em Entra ID > Aplicativos empresariais > Consentimento e permissões, desative o consentimento do usuário ou permita apenas apps de editores verificados com permissões classificadas como de baixo impacto.
2. Ativar o fluxo de consentimento do administrador: com ele, o usuário que precisa de um aplicativo envia uma solicitação justificada, e um administrador revisa as permissões antes de aprovar. A produtividade se mantém e a decisão sai das mãos de quem não tem contexto técnico.
3. Classificar as permissões: defina quais escopos são de baixo risco (como User.Read e openid) e deixe todo o resto sujeito a revisão.
4. Revisar os aplicativos existentes: faça um inventário dos apps empresariais com permissões delegadas ou de aplicativo e remova os que ninguém reconhece, os abandonados e os que têm escopos excessivos.
5. Monitorar continuamente: configure alertas para eventos de "Consentimento para aplicativo" nos logs de auditoria e use recursos como a governança de aplicativos do Microsoft Defender for Cloud Apps para detectar apps com comportamento anômalo, como um volume atípico de leitura de e-mails.
6. Aplicar acesso condicional e políticas de risco: combine as políticas de consentimento com acesso condicional, proteção de identidade e logins com risco para dificultar o uso de contas comprometidas.

A Microsoft vem endurecendo os padrões de consentimento em novos tenants, mas muitos ambientes antigos ainda permitem que qualquer usuário autorize qualquer aplicativo. Vale conferir essa configuração hoje.

Essas medidas não exigem licenciamento caro nem mudanças drásticas na rotina. Na maioria dos casos, são ajustes de política que levam poucas horas para planejar e aplicar e fecham uma das portas de entrada mais exploradas em ataques contra o Microsoft 365.

Encontrou um app suspeito? Como responder e como a Duk pode ajudar

Se a sua empresa identificou um aplicativo desconhecido com acesso a caixas de correio ou arquivos, aja rápido e na ordem certa. Primeiro, desative o login do aplicativo nas propriedades do app empresarial, para cortar o acesso na hora. Em seguida, revogue as concessões de permissão e remova a entidade de serviço. Depois, revogue as sessões e os tokens de atualização dos usuários afetados. Por fim, investigue o que foi acessado: logs de auditoria unificados, eventos de leitura de e-mail, regras de caixa de entrada criadas para encaminhar mensagens para fora e envios feitos em nome da vítima. Só troque senhas depois disso, como medida complementar, e não como solução principal.

Essa investigação exige familiaridade com o Entra ID, a Microsoft Graph e as ferramentas de auditoria do Microsoft 365, e precisa ser feita depressa, porque cada hora com o consentimento ativo é mais uma hora de exposição. Para a maioria das pequenas e médias empresas, manter essa competência dentro de casa, disponível o tempo todo, não é viável.

A Duk Informática & Cloud atua há mais de 18 anos como parceira de TI de empresas brasileiras e atende mais de 550 clientes. Como Microsoft Gold Partner, a Duk revisa e endurece tenants Microsoft 365: restringe o consentimento de aplicativos, implanta o fluxo de aprovação por administrador, faz o inventário dos apps OAuth já autorizados, configura alertas de auditoria e responde a incidentes quando um consentimento malicioso é detectado. Se você quer saber quais aplicativos têm acesso aos e-mails da sua empresa neste momento, fale com a equipe da Duk e agende uma avaliação de segurança do seu ambiente Microsoft 365.