A plataforma EvilTokens usou o fluxo legítimo de login por dispositivo para obter permissões OAuth e manter acesso a caixa de e-mail, arquivos, calendário e contatos mesmo após redefinição de senha.
| Componente | Fluxo de consentimento OAuth em organizações Microsoft 365, com permissões para e-mail, arquivos, calendário e contatos. |
| Vetor | Mensagem induzindo o usuário a inserir um código curto em microsoft.com/devicelogin, concluir MFA no domínio legítimo e aceitar permissões OAuth. |
| Impacto | Em cinco semanas, a plataforma EvilTokens comprometeu mais de 340 organizações Microsoft 365 em cinco países por meio de tokens de atualização escopados. |
| Prioridade | Inventariar concessões OAuth, revogar tokens suspeitos no nível da aplicação e revisar políticas de consentimento e acesso condicional. |
| Artefatos | Tokens de atualização com vida útil definida pela política do locatário, não por uma sessão interativa comum. |
| Mitigação | Redefinição de senha isolada não encerra a concessão; é necessária revogação explícita ou política que force novo consentimento. |
A campanha associada à plataforma de phishing como serviço EvilTokens explorou uma área que muitas defesas de identidade ainda tratam como secundária: a camada de consentimento OAuth. Em vez de capturar senha e reutilizá-la contra o provedor de identidade, o fluxo levou usuários a autenticar-se em um domínio legítimo, concluir o desafio de MFA esperado e aprovar permissões para uma aplicação. O resultado foi um token de atualização válido, emitido pelo próprio provedor de identidade e limitado aos escopos aceitos pelo usuário, mas suficiente para acessar caixa de e-mail, arquivos, calendário e contatos dentro do Microsoft 365.
O dado operacional mais relevante é que, em cinco semanas após entrar em atividade em fevereiro de 2026, a EvilTokens comprometeu mais de 340 organizações Microsoft 365 distribuídas por cinco países. O ataque não dependia de senha reutilizada nem de uma tentativa visível de burlar MFA durante o login. A vítima via uma sequência plausível: inserir um código curto, autenticar-se, passar pelo MFA e aceitar o fluxo. Para a organização, a emissão do token podia parecer uma autorização regular, porque o usuário realmente autenticou no provedor legítimo.
Essa técnica muda o ponto crítico do phishing. O clique que antes entregava uma credencial agora entrega uma concessão OAuth. Como a autenticação forte já ocorreu antes da emissão do token, MFA não bloqueia a autorização. A defesa precisa avaliar o consentimento, o escopo solicitado, a aplicação beneficiada, a duração do token e o cruzamento desse acesso com outros serviços SaaS conectados à mesma identidade.
O fluxo observado começa com uma mensagem que direciona o usuário ao login por dispositivo do Microsoft 365. A vítima recebe ou insere um código curto em microsoft.com/devicelogin, conclui a autenticação normal e passa pelo desafio de MFA. A etapa decisiva ocorre depois: o usuário aceita a concessão OAuth para uma aplicação controlada ou abusada pelo operador. Nesse momento, o atacante não recebe a senha; recebe um token de atualização autorizado, assinado pelo provedor de identidade e associado aos escopos aprovados.
A diferença técnica em relação ao roubo clássico de credenciais é importante para resposta a incidentes. Não há necessariamente um login com senha roubada, nem um evento óbvio de MFA falho ou de autenticação de origem estranha que revele a intrusão. O token é consequência de um fluxo legítimo e pode ser renovado enquanto a política do locatário permitir. O material analisado indica que tokens emitidos pela EvilTokens sobreviveram a redefinições de senha e continuaram válidos por semanas ou meses, dependendo da configuração do ambiente.
Os escopos descritos também ampliam o risco. Uma permissão apresentada ao usuário como leitura de e-mail pode alcançar mensagens, anexos e conversas compartilhadas disponíveis à conta. Uma permissão para acessar arquivos sem presença do usuário permite operação contínua sem nova interação humana. O problema defensivo não está apenas em um escopo isolado, mas na combinação entre identidade humana, aplicações aprovadas, integrações SaaS e agentes que passam a agir com permissões delegadas.
A superfície diretamente afetada são organizações Microsoft 365 nas quais usuários podem conceder permissões OAuth a aplicações ou integrações. O risco cresce quando o mesmo usuário possui acesso operacional a múltiplos ativos, como e-mail corporativo, calendários executivos, unidades compartilhadas, documentos financeiros, contratos e registros de clientes. A concessão não precisa abranger todo o locatário para ser valiosa; basta refletir o alcance real da identidade que a aprovou.
A situação fica mais complexa quando diferentes aplicações e integrações criam uma combinação tóxica de permissões. Um usuário pode aprovar uma ferramenta com acesso ao calendário e à caixa de e-mail, outra com acesso a arquivos compartilhados e uma terceira conectada a um sistema de relacionamento com clientes. Cada consentimento pode parecer aceitável isoladamente, mas a interseção dessas permissões forma uma ponte que nenhum dono de aplicação aprovou como uma superfície única.
O mesmo modelo de risco se aplica a conectores e agentes que adquirem alcance por consentimento. O contexto destaca que instalações de MCP, concessões OAuth e permissões de extensões de navegador seguem a mesma lógica de confiança concedida em um clique. A defesa precisa tratar essas pontes como parte do plano de identidade, não como exceções administradas apenas por cada aplicação.
- Usuários Microsoft 365 induzidos a aprovar consentimento OAuth após autenticação legítima e MFA concluído.
- Contas com acesso a e-mail, arquivos, calendário e contatos expõem dados acessíveis pelos escopos concedidos.
- Tokens de atualização podem manter acesso além da sessão original e além de uma simples redefinição de senha.
- Integrações SaaS e agentes conectados podem combinar permissões que não aparecem em um único log de aplicação.
A investigação deve começar pelas concessões OAuth recentes e incomuns, especialmente autorizações feitas por usuários que receberam mensagens pedindo uso do fluxo de login por dispositivo. O ponto de atenção não é apenas o evento de autenticação, porque ele pode ter ocorrido com MFA válido. A trilha mais útil está na criação da concessão, nos escopos aprovados, na aplicação beneficiada, na renovação de tokens e no comportamento posterior de acesso a e-mail, arquivos, calendário e contatos.
Equipes de detecção devem correlacionar consentimentos com mudanças de padrão. Um usuário que raramente aprova aplicações e passa a autorizar uma aplicação desconhecida com leitura de e-mail e acesso offline merece revisão imediata. A mesma análise vale para concessões próximas a mensagens de phishing, solicitações de código de dispositivo, acessos a dados fora do padrão e uso contínuo sem interação do usuário. Como a redefinição de senha pode não encerrar o token, a telemetria precisa confirmar revogação efetiva da concessão.
Também é necessário procurar riscos estruturais. Concessões antigas, tokens pouco usados, aplicações sem proprietário claro e integrações com escopos amplos criam persistência operacional para abuso futuro. O objetivo do hunting é montar o grafo entre identidade humana, aplicação, escopo, recurso acessado e token ativo, porque o abuso ocorre justamente nas pontes entre esses elementos.
- Novas concessões OAuth vinculadas a usuários que passaram por fluxo de login por dispositivo.
- Escopos com leitura de e-mail, acesso a arquivos, calendário, contatos ou acesso offline.
- Aplicações desconhecidas, sem proprietário interno ou aprovadas por usuários fora de um processo formal.
- Tokens que continuam renovando acesso após redefinição de senha ou encerramento de sessão.
- Acesso anômalo a mensagens, anexos, unidades compartilhadas e calendários logo após o consentimento.
A resposta deve tratar a concessão OAuth como credencial efetiva. Quando houver suspeita, a primeira etapa é identificar a aplicação, os escopos, o usuário que consentiu e os recursos alcançados. Em seguida, a organização deve revogar a concessão e os tokens associados no nível da aplicação, não apenas redefinir a senha do usuário. O contexto deixa claro que a senha isolada não invalida necessariamente o token de atualização emitido pelo fluxo OAuth.
A prevenção exige controles sobre quem pode conceder permissões, quais aplicações podem receber consentimento e quais escopos exigem revisão administrativa. Políticas de acesso condicional devem considerar reconsentimento, risco da aplicação e necessidade de revogação quando houver alteração de confiança. Organizações também devem manter inventário contínuo de concessões, integrações e agentes, porque auditorias pontuais não acompanham a velocidade com que esses vínculos são criados.
A validação final precisa confirmar que o token não está mais renovando acesso e que não existem concessões paralelas para a mesma identidade. Depois da contenção, a equipe deve revisar mensagens recebidas pela vítima, aprovações próximas no tempo e acessos a dados sensíveis dentro dos escopos autorizados. Esse processo reduz a chance de encerrar apenas o usuário comprometido enquanto a aplicação autorizada continua ativa.
- Revogar explicitamente concessões OAuth e tokens de atualização associados a aplicações suspeitas.
- Restringir consentimento de usuário para escopos sensíveis e exigir aprovação administrativa quando necessário.
- Mapear aplicações, integrações, agentes e permissões delegadas por identidade humana e não humana.
- Revisar tokens persistentes, concessões antigas e aplicações sem proprietário definido.
- Correlacionar consentimento, acesso a dados e mensagens de phishing antes de declarar contenção concluída.
0 Comentários