Microsoft Mapeia Campanha de Um Ano de Roubo de Dados Salesforce Via Abuso de Confiança OAuth

Microsoft Mapeia Campanha de Um Ano de Roubo de Dados Salesforce Via Abuso de Confiança OAuth

Pesquisa revela três vetores de ataque que permitiram a exfiltração de dados corporativos sem exploração de vulnerabilidades, focando em engenharia social, comprometimento de fornecedores e falhas de configuração em endpoints de convidados.

ComponenteAmbientes Salesforce (Connected Apps, Experience Cloud, Aura endpoints) e ecossistema de integrações OAuth.
VetorTrês caminhos distintos: engenharia social via vishing para aprovação de app malicioso, comprometimento de fornecedores para roubo de tokens OAuth na cadeia de suprimentos, e acesso não autenticado a endpoints Aura mal configurados.
ImpactoExfiltração em massa de dados de CRM, descuberta e roubo de credenciais (AWS keys, tokens Snowflake), acesso persistente a registros corporativos e possibilidade de movimento lateral para outras plataformas SaaS.
PrioridadeInventariar e auditar rigorosamente todos os aplicativos conectados, escopos OAuth e permissões de usuário convidado; implementar monitoramento de eventos em tempo real via Salesforce Shield e integração com Microsoft Defender for Cloud Apps.
Resumo técnico

Uma pesquisa detalhada da Microsoft mapeou uma série de campanhas de extorsão e roubo de dados que ocorreram entre meados de 2025 e meados de 2026, direcionadas especificamente a ambientes corporativos do Salesforce. A análise indica que atores de ameaça, alinhados metodologicamente ao grupo de extorsão de dados conhecido como ShinyHunters, conseguiram acessar informações sensíveis sem explorar quaisquer vulnerabilidades técnicas na plataforma Salesforce. Em vez disso, os atacantes exploraram a confiança já estabelecida pelas organizações, utilizando-se principalmente de conexões OAuth que vinculam o Salesforce a aplicativos externos e fornecedores terceirizados.

A campanha destaca uma lacuna crítica nos controles de segurança modernos: enquanto o esforço da última década concentrou-se em proteger logins de usuários humanos através de autenticação multifator (MFA) e políticas de acesso condicional, as contas de serviço, integrações e aplicativos OAuth que realizam o trabalho pesado na pilha de SaaS frequentemente permanecem sem monitoramento e com permissões excessivas. A análise identificou três vetores distintos utilizados para obter acesso inicial e manter persistência, abrangendo setores como varejo, educação e manufatura.

Fluxo técnico e vetores de ataque

O primeiro caminho identificado pela Microsoft iniciou a onda de ataques e se baseia em engenharia social de alta precisão, especificamente vishing (phishing por voz). Atores de ameaça fizeram ligações telefônicas se passando por suporte de TI, convencendo funcionários a navegarem pela tela de consentimento OAuth do Salesforce. O objetivo era fazer com que o usuário autorizasse um aplicativo conectado controlado pelo atacante, que se disfarçava da ferramenta legítima 'Data Loader' do Salesforce. Uma vez concedido o consentimento, o aplicativo malicioso podia fazer chamadas de API em nome do usuário, permitindo a enumeração de dados da organização, acesso persistente a registros de CRM e a caça de credenciais que poderiam abrir portas para outras plataformas SaaS, sem a necessidade de uso de malware ou reutilização de senhas roubadas.

O segundo vetor elimina a necessidade de interação com o funcionário da vítima, focando no comprometimento da cadeia de suprimentos. Neste cenário, os atacantes comprometem um fornecedor terceirizado cujo aplicativo já possui acesso OAuth aos ambientes Salesforce de seus clientes. Ao invadir o fornecedor, os atores roubam os segredos de conexão ou tokens de atualização e os utilizam para consultar e exportar dados de múltiplas instâncias downstream simultaneamente. Como o tráfego se origina de uma integração previamente aprovada e confiável, ele não dispara alertas de signin e se mistura com a automação de negócios normal. A Microsoft aponta incidentes específicos, como o comprometimento da Salesloft Drift em agosto de 2025 e da Gainsight em novembro de 2025, onde o acesso inicial ao fornecedor (via GitHub e AWS) permitiu o roubo de tokens OAuth subsequentemente usados contra clientes.

O terceiro caminho não requer credenciais de forma alguma, aproveitando configurações incorretas de permissões. A Microsoft observou um aumento na atividade de usuários convidados suspeita contra endpoints do Salesforce Aura, a estrutura por trás dos sites do Experience Cloud. Onde as permissões do usuário convidado estavam mal configuradas, os atores alcançaram a funcionalidade Aura sem autenticação. Ao chamar o controlador GraphQL do Aura, os atacantes utilizaram paginação baseada em cursor para puxar registros além do limite padrão de 2.000 registros por consulta, extraindo volumes de dados muito maiores do que o papel de convidado deveria permitir.

Superfície afetada e impacto

As campanhas afetaram um espectro amplo de locatários (tenants) Salesforce, com impacto confirmado em grandes corporações de diversos setores. No vetor de engenharia social, vítimas documentadas incluem grandes marcas de luxo e aviação, bem como confirmação de comprometimento em uma instância corporativa da própria Google em junho de 2025, onde dados de contato comercial públicos foram exfiltrados antes do bloqueio. No caso do comprometimento da cadeia de suprimentos (Salesloft e Gainsight), a estimativa é de que centenas de organizações, incluindo empresas de segurança cibernética e tecnologia, tenham tido seus dados expostos através do abuso de tokens de fornecedores comprometidos.

Os atacantes demonstraram um foco específico em informações que pudessem facilitar o movimento lateral ou extorsão. Por meio de consultas SOQL (Salesforce Object Query Language) executadas através dos tokens comprometidos, os operadores filtraram casos de suporte e outros objetos em busca de chaves de AWS, tokens do Snowflake e senhas. Após a extração, os atores apagavam seus trabalhos de consulta para retardar investigações forenses. O caso mais recente, registrado em junho de 2026, envolveu a plataforma de inteligência competitiva Klue, onde atacantes usaram uma credencial legada de uma integração de teste não implantada para injetar uma atualização de código e colher tokens de clientes, acessando dados do Salesforce e Gong de clientes como Huntress e Recorded Future.

  • Ambientes Salesforce com integrações OAuth de terceiros (ex: Drift, Gainsight, Klue).
  • Organizações que utilizam Experience Cloud com permissões de usuário convidado mal configuradas no framework Aura.
  • Instâncias Salesforce vinculadas a fornecedores cujas credenciais de desenvolvimento ou infrastructure-as-code (ex: GitHub, AWS) foram comprometidas.
Hunting e telemetria

A detecção dessas ameaças é historicamente difícil porque os controles de identidadetradicionais monitoram o ato de login, mas consideram o tráfego subsequente de um aplicativo ou integração confiável como legítimo. O sinal de comprometimento reside no comportamento pós-acesso: qual aplicativo conectado fez a chamada, quais escopos OAuth ele detém, quanta consulta está realizando e se esse volume é normal para o locatário. A Microsoft e a Salesforce trabalharam conjuntamente para expor esses sinais através do Defender for Cloud Apps e do Salesforce Shield Event Monitoring.

Para equipes de segurança (Blue Teams), a caça deve focar em anomalias no uso de API de aplicativos conectados. É crucial monitorar o uso de escopos elevados que não correspondem à função do aplicativo e identificar spikes de volume de dados acessados por contas de serviço ou integrações que geralmente são inativas. A atualização do conector Salesforce para o Defender for Cloud Apps agora incorpora o framework de Real-Time Event Monitoring, permitindo detecção quase em tempo real, atribuição de atividade a uma identidade específica de aplicativo e contexto de sessão mais rico.

Indicadores de comprometimento (IoCs) incluem o uso da ferramenta AuraInspector para sondar endpoints do Aura e padrões de consulta que utilizam paginação excessiva para extrair grandes conjuntos de dados via GraphQL sem autenticação. No contexto da cadeia de suprimentos, a telemetria deve alertar sobre tokens de atualização OAuth sendo utilizados a partir de intervalos de IP não familiares ou fora dos padrões de geolocalização do fornecedor, mesmo que o token em si seja válido criptograficamente.

  • Anomalias no volume de chamadas de API provenientes de aplicativos conectados específicos.
  • Uso de escopos OAuth excessivos por aplicativos de terceiros ou internos de baixa confiança.
  • Atividade de consulta SOQL massiva ou recorrente seguida de exclusão de jobs de consulta.
  • Acesso não autenticado a endpoints GraphQL do Salesforce Aura indicando exposição de usuário convidado.
Mitigação e resposta

A resposta a esse tipo de campanha exige uma mudança de paradigma do foco em login humano para a governança de identidade de máquina. A ação defensiva primária é realizar um inventário rigoroso de todos os aplicativos conectados ao Salesforce. Aplicações que não são utilizadas há mais de 90 dias, mas que ainda mantêm permissões ativas (tokens de atualização válidos), devem ter o acesso revogado imediatamente. As integrações ativas devem ter seus escopos OAuth revisados sob o princípio do menor privilégio necessário, removendo permissões de acesso a dados sensíveis se a função do app não o exigir.

Para proteger contra o vetor de usuário convidado, as organizações devem restringir drasticamente o acesso a endpoints do Experience Cloud e do framework Aura, garantindo que o usuário convidado não tenha permissões de leitura em objetos sensíveis ou capacidade de executar consultas complexas. A recomendação técnica inclui habilitar o Salesforce Shield Event Monitoring e integrá-lo a soluções SIEM ou CASB (Cloud Access Security Broker) como o Microsoft Defender for Cloud Apps para correlacionar eventos de autenticação com eventos de uso de dados.

Na eventualidade de um comprometimento suspeito de um fornecedor, a resposta defensiva deve assumir que os tokens OAuth emitidos para esse fornecedor estão comprometidos. A rotação imediata desses tokens e a revogação da autorização do aplicativo conectado são passos obrigatórios. O monitoramento contínuo deve procurar por tentativas de reautenticação ou reautorização por parte do fornecedor comprometido, o que pode indicar persistência do atacante tentando restabelecer o acesso.

  • Auditoria e revogação de aplicativos conectados inativos ou com escopos excessivos (Princípio do Menor Privilégio).
  • Implementação de pontuação de risco para aplicativos OAuth (0 a 100) e automação de políticas para bloqueio de high-risk apps.
  • Restrição de permissões de usuário convidado no Experience Cloud e desabilitação de acesso anônimo a endpoints GraphQL do Aura.
  • Integração do Salesforce com Microsoft Defender for Cloud Apps para visibilidade de eventos em tempo real e atribuição de apps conectados.

Postar um comentário

0 Comentários