Principais conclusões
- Ao testar 38 aplicações adicionais desde a nossa pesquisa inicial, a Semperis encontrou duas que eram vulneráveis ao abuso do nOAuth. Reportámos as nossas descobertas sobre essas duas aplicações aos fornecedores de software.
- Uma das aplicações vulneráveis tinha permissões que permitiriam a um invasor voltar ao Microsoft 365, reforçando que o nOAuth pode colocar em risco não apenas os dados na aplicação SaaS, mas também o património do Microsoft 365 de uma organização.
- No nosso caso mais recente com o Microsoft Security Response Center, o MSRC classificou esta vulnerabilidade como moderada. No entanto, a Semperis mantém a nossa classificação de GRAVE. O nOAuth ainda é difícil de detetar para os clientes de aplicações vulneráveis e impossível de defender para os clientes de aplicações vulneráveis. O abuso está documentado publicamente e é de baixa complexidade, uma vez que uma aplicação vulnerável é encontrada.
Este artigo é uma continuação da nossa pesquisa original sobre nOAuth. Embora pareça que foi ontem que divulgámos essas descobertas na TROOPERS25 e na fwd:cloudsec 2025, a nossa pesquisa começou no outono de 2024.
Ao realizar pesquisas adicionais sobre o nOAuth seis meses após a nossa conversa original e, novamente, um ano após a nossa pesquisa inicial, descobrimos que o risco de abuso do nOAuth ainda existe e que muitas organizações ainda não estão cientes dessa vulnerabilidade.
Durante outubro e novembro de 2025, testámos 38 aplicações adicionais quanto ao abuso do nOAuth e descobrimos que duas delas eram vulneráveis. Durante a nossa pesquisa anterior, testámos 104 aplicações e descobrimos que nove eram vulneráveis. Isso significa que, em termos percentuais acumulados, cerca de 8% das aplicações disponíveis são vulneráveis ao nOAuth.
Entendendo como os aplicativos SaaS se integram ao Microsoft 365
A API do Microsoft Graph é a API unificada para aceder a tudo no Microsoft 365: Exchange Online, SharePoint, OneDrive e a maioria dos outros serviços do Microsoft 365. As aplicações SaaS de terceiros que pretendem integrar-se com estes serviços solicitam acesso ao Microsoft Graph para que possam interagir com os dados ou serviços dos utilizadores em seu nome.
Um exemplo é o Calendly, que solicita permissões para o calendário do utilizador para que possa gerir as suas reuniões no Office 365 (Figura 1). Para maior clareza, o Calendly não é vulnerável ao nOAuth. Estamos simplesmente a usá-lo como um aplicativo de referência para ajudar a compreender o comportamento comum dos aplicativos SaaS.
Quando um utilizador acede à aplicação, desde que as permissões tenham sido consentidas, a aplicação SaaS recebe um token de acesso OAuth 2.0 do Entra ID. A aplicação usa então esse token de acesso com a API do Microsoft Graph para aceder ao serviço. Neste exemplo, o token de acesso fornecido ao Calendly tem permissões Calendar.ReadWrite e Calendar.ReadWrite.Shared.
Em muitos cenários, a aplicação SaaS também recebe um token de atualização (Figura 2). Esse token permite que a aplicação SaaS mantenha o acesso aos dados do utilizador, mesmo que ele não esteja a utilizar ativamente a aplicação.
Por que as aplicações SaaS precisam desse tipo de acesso? No nosso exemplo, esse acesso permite que o Calendly marque compromissos com clientes na sua agenda, mesmo que você não esteja a utilizar ativamente a aplicação. Dessa forma, a aplicação SaaS pode continuar a fazer "coisas" com os seus dados nos bastidores.
Isso é ótimo para a produtividade, e não há nada de errado com as permissões solicitadas. Mas quando essas permissões são combinadas com a vulnerabilidade ao nOAuth, o cenário fica propício para que invasores abusem do aplicativo e, potencialmente, voltem ao Microsoft 365.
A diferença entre autenticação e autorização
Para entender completamente como o nOAuth pode facilitar o retorno ao Microsoft 365, é necessário saber que o OpenID Connect (OIDC) facilita a autenticação com um token de identificação, e o OAuth 2.0 facilita a autorização com um token de acesso. Quando um token de atualização acompanha um token de acesso, a aplicação SaaS pode obter novos tokens de acesso, independentemente de o utilizador estar autenticado.
Deixando de lado as nuances da linguagem de identidade, o OIDC facilita o login do utilizador numa aplicação. O OAuth 2.0 facilita as permissões que uma aplicação tem sobre os dados do utilizador. Um token de atualização permite que a aplicação aceda aos dados do utilizador, mesmo que ele não esteja conectado (Figura 3).
Quando um utilizador acede a uma aplicação pela primeira vez, pode ocorrer autenticação e autorização: a aplicação pode receber um token de identificação para o utilizador e um token de acesso para que a aplicação possa aceder aos recursos do Microsoft 365. Para o utilizador final, esse processo geralmente é transparente, exceto quando a aplicação nunca foi usada e é necessário consentimento.
Existem muitas estruturas e bibliotecas para gerenciar tokens, mas, em última análise, é o desenvolvedor de aplicativos SaaS que determina como os tokens são gerenciados.
Quando um utilizador se autentica posteriormente, a aplicação pode (ou não) tentar solicitar um novo token de acesso e atualização, se os tokens existentes ainda forem válidos. Como a autenticação e a autorização são essencialmente tratadas como funções diferentes, essa desconexão entre os dois fluxos permite que os invasores se posicionem.
Abuso do nOAuth para a transição para o Microsoft 365
Durante a nossa pesquisa inicial, descobrimos uma aplicação vulnerável que tinha integrações com o Microsoft 365 com permissões Calendars.ReadWrite.Shared. De acordo com a documentação da Microsoft, esta integração:
Permite que a aplicação crie, leia, atualize e elimine eventos em todos os calendários da organização aos quais o utilizador tem permissão de acesso. Isso inclui calendários delegados e partilhados.
Preocupante, mas não algo que possibilitaria um ataque como o comprometimento de e-mails comerciais (BEC).
Desta vez, encontramos um conjunto de permissões muito mais amplo e preocupante (Figura 4):
- Calendários.Leitura/Escrita
- Enviar e-mail
- Contactos.Leitura/Escrita
- Correio.LeituraEEscrita
- acesso_offline
Como mencionado anteriormente, essas permissões são preocupantes porque permitem que um invasor não apenas comprometa o utilizador dentro do aplicativo SaaS, mas também use a interface do aplicativo para voltar ao Microsoft 365.
Lembre-se de que autenticação e autorização são funções diferentes com tokens diferentes. O invasor basicamente obtém controlo sobre o acesso dos utilizadores no Microsoft 365 por meio desses tokens de acesso e atualização gerenciados no aplicativo SaaS (Figura 5).
Na aplicação SaaS vulnerável, esse comportamento manifesta-se como a capacidade de um invasor enviar e-mails como o utilizador comprometido (Figura 6).
Como o e-mail é de um utilizador legítimo no locatário, o invasor agora tem uma maneira eficaz de agir como o utilizador comprometido no Exchange Online (Figura 7).
O invasor não tem acesso direto ao token de acesso, portanto, a interface do utilizador da aplicação SaaS determina como ele pode interagir com os recursos do Microsoft 365. Ainda assim, essas descobertas reforçam as nossas preocupações de longa data com o nOAuth e o potencial acesso a dados e caminhos laterais que ele pode permitir.
Pesquisar sobre o nOAuth é como tentar provar uma negação.
Quando publicámos as nossas conclusões em junho de 2025, as perguntas mais comuns que recebemos foram sobre quantas aplicações no total poderiam estar vulneráveis. Isso é compreensível, pois números indefinidos não rendem boas manchetes.
No entanto, era — e ainda é — impossível quantificar quantas aplicações poderiam estar vulneráveis. Uma pesquisa pelo número de aplicações SaaS existentes retorna um número que varia entre 70.000 e mais de 300.000. O catálogo de aplicações Microsoft 365 Defenders Cloud lista 36.932 aplicações SaaS, mas nem todas elas se integram com o Entra ID para autenticação.
Não importa como você faça os cálculos, será sempre uma estimativa. Na extremidade inferior, se 50% de todos os aplicativos usarem o Entra ID para autenticação, testar 142 (de 35.000) aplicativos nos coloca em 0,4% testados. Na extremidade superior (de 150.000 aplicativos), isso nos colocaria em 0,098% testados.
Na Troopers, afirmei que encontrámos nove aplicações vulneráveis e duvido que tenhamos encontrado 90% de todas as aplicações vulneráveis. Agora, com as nossas novas descobertas, duvido que 11 seja o total de aplicações vulneráveis existentes. É simplesmente impossível saber.
A Microsoft saberia quantas aplicações estão configuradas com removeUnverifiedEmailClaim definido como falso e quantas aplicações estão isentas para usar essa reivindicação. Mas isso não indica se a aplicação é vulnerável.
No que diz respeito às permissões, embora tenhamos encontrado apenas abusos em aplicações com integrações do Exchange Online, as integrações com o SharePoint e o OneDrive são igualmente populares. Seria ingênuo acreditar que apenas uma determinada percentagem das aplicações com essas integrações são vulneráveis ao nOAuth. Existem centenas de outras permissões do Microsoft Graph, muitas das quais seriam altamente preocupantes se um invasor as obtivesse. Na verdade, fazer isso é o principal objetivo de outro ataque muito comum: concessões de consentimento ilícitas.
Cronograma e resposta do MSRC
- 18 de novembro de 2025: Com novas descobertas específicas do Microsoft 365 e essa capacidade de voltar atrás, abrimos um caso com o MSRC. Fornecemos todos os detalhes das descobertas, por escrito e num vídeo que mostra o ataque contra o nosso utilizador de teste. Também pedimos ao MSRC para descontinuar a capacidade de enviar uma reivindicação de e-mail não verificada. Conforme discutimos na nossa publicação original, existem outras maneiras de receber a reivindicação de e-mail.
- 3 de dezembro de 2025: O MSRC respondeu que o caso é considerado de risco moderado e encerrou o caso. Na sua resposta, o MSRC declarou o seguinte:
Após uma investigação cuidadosa, avaliámos este caso como uma vulnerabilidade de gravidade moderada. As nossas respetivas equipas de produtos/serviços foram notificadas sobre isso e poderão trabalhar na adição de mecanismos de defesa em profundidade adicionais, conforme necessário, em versões futuras.
Como resultado, estamos a encerrar este caso.
Por que o nOAuth ainda é importante
Continuaremos a pesquisar aplicações vulneráveis ao nOAuth e a defender mudanças na Microsoft, por vários motivos:
- O abuso do nOAuth está publicamente documentado.
- Pesquisas comprovaram o acesso a informações confidenciais em plataformas como os Sistemas de Gestão de Recursos Humanos (HRMS).
- Pesquisas comprovaram que existem caminhos potenciais de movimento lateral para voltar ao Microsoft 365.
- Os clientes de aplicações vulneráveis não têm defesa contra o nOAuth.
- Pesquisadores de segurança comprovaram que é relativamente fácil identificar os clientes de aplicações SaaS.
- Usar plataformas como o LinkedIn para segmentar utilizadores privilegiados de aplicações SaaS e deduzir os seus endereços de e-mail também é simples.
Instantâneo da Semperis
Embora as organizações empresariais não tenham defesas fortes contra o nOAuth, é importante compreender o risco relativo aos seus dados. Antes de adotar uma nova aplicação SaaS, pergunte ao fornecedor se ele está ciente da pesquisa sobre o nOAuth e indique os nossos blogs.
Para fornecedores e programadores, seguir as especificações OpenID Connect da Microsoft é fundamental para garantir que a sua aplicação não seja vulnerável ao nOAuth. Para mais detalhes, consulte a nossa pesquisa anterior.
Recursos relacionados
• Alerta de abuso do nOAuth: apropriação total da conta de aplicações SaaS entre locatários da Entra
• Sessão sob demanda do nOAuth (TROOPERS25)
