Microsoft revela persistência de ataques do grupo ShinyHunters no Salesforce por um ano

O OAuth não é um sistema de login, é um protocolo de autorização delegada. Ele permite que aplicativos de terceiros acessem dados ou APIs em nome de um usuário sem receber sua senha, usando tokens com escopos e prazos definidos. Funciona como uma chave de manobrista: o usuário aprova uma permissão específica (ex: 'ler contatos'), e o app opera dentro dela. Mas essa confiança é frágil quando os tokens são roubados, os escopos são excessivos ou o consentimento é enganado por vishing, exatamente o que o ShinyHunters explorou por um ano inteiro. A fraqueza não está no código do Salesforce, mas na governança: centenas de empresas mantinham apps conectados inativos há meses, com acesso a dados sensíveis; outras deixaram funções de convidado com permissões GraphQL que permitiam extrair milhares de registros sem autenticação; e muitas não monitoravam o que esses apps faziam *depois* de autorizados, só se preocupavam com quem entrava, não com o que fazia dentro.

Essa falha estrutural é estratégica: as políticas de MFA, conditional access e sessão foram desenhadas para humanos, não para máquinas. Um app OAuth com escopo 'api' e 'refresh_token' pode rodar 24/7, acessar dados em massa e passar despercebido porque seu tráfego parece legítimo, até que alguém olhe para o volume de chamadas SOQL, a frequência de exportações ou a combinação de escopos concedidos. A nova integração entre Defender for Cloud Apps e o Salesforce Shield Event Monitoring fecha essa lacuna: agora é possível ligar cada requisição API a um app específico, seus escopos reais e seu histórico de uso, transformando o OAuth de um ponto-cego em um vetor auditável.

A cobertura CEVIU de 11 de março de 2026 já apontava o abuso de configurações de guest-user no Experience Cloud e o uso da ferramenta AuraInspector, mas como um padrão isolado. Agora, a Microsoft confirma que esse foi apenas um dos três vetores, todos operando sob a mesma lógica de exploração de confiança OAuth. Em 1º de julho, a CEVIU detalhava a campanha GRUB1/UNC6395 como um caso de phishing de OAuth e tokens roubados, hoje sabemos que ela fazia parte de um ciclo contínuo de ataques que começou em meados de 2025 e só foi interrompido em julho de 2026. O que era rumor sobre escala (‘centenas de clientes’) virou fato comprovado: Microsoft e Google confirmam mais de 1.000 organizações afetadas nas ondas Salesloft, Gainsight e Klue. E o que era recomendação genérica, ‘revogue tokens’, agora tem ferramenta concreta: o score de risco por app e a detecção em tempo real de atividade anômala via Real-Time Event Monitoring, lançados em conjunto com o Salesforce após a análise forense completa.

Para arquitetos de nuvem e equipes de governança, isso não é só sobre segurança: é sobre custo operacional e compliance. Um app OAuth mal configurado pode gerar milhões de chamadas API por mês, inflando custos de licença do Salesforce e saturando limites de consumo. Mais grave: a LGPD e a Lei Geral de Proteção de Dados exigem controle sobre o tratamento de dados pessoais por terceiros. Se um fornecedor como Klue ou Drift sofre uma violação e seus tokens OAuth são usados para extrair dados de CRM, a responsabilidade legal recai sobre a empresa que concedeu o acesso, não sobre o fornecedor. Ignorar a higiene de OAuth é ignorar uma obrigação contratual, fiscal e regulatória. A mudança não é técnica: é de postura. Deixar de tratar apps como 'coisas que funcionam' para tratá-los como 'identidades com privilégios' é o primeiro passo para uma arquitetura de nuvem madura.