Violação do Salesloft Drift: um ataque de movimentação lateral entre fornecedores que requer um novo modelo de segurança compartilhada

Por que esse ataque (B2)ⁿ enfatiza a necessidade de um modelo de responsabilidade compartilhada para integrações SaaS e identidades não humanas.
Silverfort Imagem
Blog da Salesloft Roy Imagem em destaque - 1 - Bloco do blog

Em meados de agosto de 2025, foi relatada a violação do Salesloft Drift, impactando gigantes como Palo Alto Networks, Salesforce, Cloudflare e seus clientes. Os invasores roubaram e abusaram de centenas de tokens OAuth para acessar ambientes Salesforce e extrair dados confidenciais, demonstrando consequências comprovadas e potenciais em larga escala. 

Ao ler os relatórios, resisti à ideia de classificá-los como mais um "ataque à cadeia de suprimentos". Este ataque foi diferente.  

Estava relacionado a roubo de identidades não humanas e uma quebra de confiança com um movimento lateral TTP com esteroides, também conhecido como movimento lateral entre fornecedores.  Foi um ataque de empresa para empresa. Ou, rotulado de uma forma muito mais científica, um (B2)ⁿ Ataque. Essa cadeia de confiança quebrada torna muito difícil para as vítimas do ataque se protegerem. 

Pense nisso: Atacante → Deriva → Salesloft → Salesforce → O cliente → Cliente do Cliente. 

Cada salto estendeu a superfície de ataque e, uma vez Tokens OAuth foram roubados, os invasores tinham um caminho confiável através de cada fornecedor. O impacto comprovado já inclui centenas de organizações afetadas, registros de casos roubados e mais de 100 tokens de API expostos, com potencial para um comprometimento muito mais amplo, à medida que os invasores mineram esses dados em busca de chaves de nuvem e outras credenciais.  

Grandes organizações mantêm milhares de parcerias e integrações, e não possuem um modelo de "integração segura". Essa cadeia de integração resulta em um relacionamento mais do que 1:1. Então, como podemos prevenir, detectar ou responder mais rapidamente a esses tipos de ataques e nos proteger dos efeitos dominó? 
 
Obviamente, isto também levanta uma questão maior: precisamos de pressionar por uma modelo de segurança compartilhada para provedores de SaaS, não apenas para gigantes da infraestrutura de nuvem como AWS, Microsoft e Google Cloud, que fizeram chamadas semelhantes em 2020? Neste artigo, explicarei onde está o verdadeiro problema e como os fornecedores e os CISOs podem construir uma estrutura de responsabilidade compartilhada que leve em conta todas as dependências e, em última análise, reduza risco de movimento lateral. 
 
Parece interessante? Continue lendo. Se for útil, adoraria saber sua opinião. 

Mais detalhes sobre a violação

Com base em diferentes fontes (mencionadas abaixo), em agosto de 2025, invasores identificados como UNC6395 roubaram tokens de atualização OAuth da integração do Drift com o Salesforce da Salesloft. Esses tokens permitiram que o Drift consultasse instâncias do Salesforce em nome de mais de 700 clientes. Uma vez invadidos, os invasores exportaram dados de contato, registros de casos e até chaves de API incorporadas em tickets ou anexos. 
 
As empresas impactadas incluíram empresas de alto perfil como Cloudflare, Proofpoint e Palo Alto Networks. A Cloudflare divulgou que 104 tokens de API e dados confidenciais de casos foram comprometidos. A Salesforce e a Salesloft responderam revogando os tokens do Drift e removendo o aplicativo do AppExchange, e os clientes finais também desativaram essa integração como contramedida. Para alguns, era tarde demais, pois seus dados, incluindo segredos de acesso, já haviam vazado.  
 
Análises mais aprofundadas revelaram que os invasores tiveram acesso aos repositórios do GitHub da Salesloft, permitindo um reconhecimento mais aprofundado e possivelmente auxiliando no roubo de tokens. O Google também relatou abuso limitado de tokens OAuth do Drift Email em ambientes do Google Workspace. Pior ainda, os invasores buscaram chaves da AWS, tokens Snowflake e outras credenciais nos dados roubados, multiplicando o impacto potencial. 

Embora muitas das postagens e artigos publicados nas últimas semanas girem em torno da ideia de que este ciberataque foi uma violação de dados "tradicional", exploração de SaaS ou até mesmo um comprometimento de agente de IA, este incidente é diferente. É um exemplo puro de IAM complexidade, ou, para simplificar, uma bagunça total de IAM (não malha) que todos enfrentamos na era do SaaS, da IA ​​e da explosão de identidades não humanas (NHIs). O chatbot Drift é um aplicativo de software projetado para automatizar conversas, portanto, não atua com autonomia ou tomada de decisão independente. Em vez disso, opera dentro de fluxos de trabalho e integrações predefinidos. E o OAuth usado para a integração é um NHI (identidade não humana). 

O que podemos aprender

Nós, como clientes, não estamos prontos para nos proteger contra (B2)ⁿAtaques do NHI

Não é fácil responder à pergunta básica de "Quais dos nossos fornecedores foram afetados?" e "Quais dados e acessos eles tinham no Salesforce sobre nós?" Esses tipos de movimento lateral ataques que revelam a interconexão dos nossos sistemas digitais enfatizam que é mais difícil do que pensamos deter os hackers, porque muitas vezes somos os últimos a ter consciência do impacto ao longo da cadeia alimentar.  

O risco B2B2B é real e precisamos de um modelo de responsabilidade compartilhada

Não se tratava apenas de Drift → Salesforce → clientes. Tratava-se de Drift → Salesforce → dados SaaS de clientes → serviços em nuvem. Cada salto ampliava o raio de ação. Os fornecedores devem levar em conta os fornecedores dos seus fornecedores. 

Os tokens são identidades – e devem ser geridos como tal, independentemente da distância B2B

Tokens OAuth não são apenas "cola técnica". São identidades não humanas que devem ser tratadas com o mesmo rigor que contas humanas: de curta duração, com escopo definido, rotacionadas e monitoradas. São identidades que todos (incluindo invasores) podem assumir, se não forem protegidas adequadamente. 

Seus segredos e credenciais também residem nos dados – não apenas os seus, mas também os de seus parceiros.

Anotações de casos e anexos frequentemente contêm chaves ou configurações confidenciais. Uma vez violados, CRMs e sistemas de suporte se tornam minas de ouro em termos de credenciais. A varredura e a eliminação de segredos em dados de SaaS devem se tornar uma prática padrão.

Kill-switches centralizados são importantes

A capacidade da Salesforce de revogar tokens Drift globalmente ajudou a conter a disseminação. Todas as plataformas devem ter a capacidade de habilitar a revogação emergencial em larga escala.

Além da cadeia de suprimentos: Compreendendo (B2)ⁿ 

É tentador categorizar isso simplesmente como um ataque à cadeia de suprimentos ou risco de terceiros. Mas essa abordagem é muito ampla e oculta a mecânica específica. 
 
O que vimos aqui está mais próximo de um ataque cruzado (B2)ⁿ, uma forma de movimento lateral entre fornecedores. 
 
Em essência, parece com isso: 

Como a violação do Drift operou usando a técnica de movimento lateral entre fornecedores

  1. Um cliente, por exemplo, a Palo Alto Networks, usa uma plataforma SaaS, como o Salesforce. 
  2. Para aumentar o valor, a Palo Alto Networks conecta um 3rd aplicativo de festa – Salesloft para Salesforce. 
  3. A Salesloft adquire a Drift, que detinha tokens OAuth que concediam acesso da Saleloft à Salesforce em nome da Palo Alto Networks. 
  4. Se os dados do Salesforce da Palo Alto Networks contiverem segredos incorporados (como chaves de API), os invasores que violarem o Drift poderão explorar os dados do Salesforce para acessar mais profundamente o ambiente de outro fornecedor.  

Isso é confiança federada — assim como confiança implícita — se transformando em risco federado. Cada integração parece inofensiva isoladamente, mas, quando encadeadas, criam um caminho para o invasor atravessar várias organizações. Daí a ideia de (B2)ⁿ: vínculos entre empresas multiplicados, aumentando a exposição. 

Construindo um modelo de responsabilidade compartilhada para (B2)ⁿ Integrações SaaS

Na tabela abaixo, você verá onde cada parte da cadeia assume a responsabilidade de evitar ataques de movimentação lateral entre fornecedores:

O modelo de responsabilidade compartilhada proposto para integrações SaaS

O caminho a seguir através da responsabilidade partilhada

Até que se chegue a um acordo mútuo sobre um novo modelo de segurança compartilhada, para cada integração ou token/chave/certificado/identidade criado para uma terceira ou quarta parte, os líderes de CISO e IAM devem exigir que seus fornecedores lhes forneçam algum tipo de visibilidade do ciclo de vida do token, volume de uso, monitoramento básico de anomalias no uso e muito mais. No mínimo, trabalhar com os fornecedores para confirmar a disponibilidade de um "kill switch" ou botão de atualização.   

E para os próprios fornecedores, vamos garantir que capacitamos nossos parceiros de integração e clientes finais com essa visibilidade e, como parte do acesso pago, parte dos pacotes básicos.

Referências

Grupo de Análise de Ameaças do Google: atualizações UNC6395 –
https://cloud.google.com/blog/topics/threat-intelligence/unc6395-drift-attack

Aviso da Salesforce sobre a remoção do aplicativo Drift 
https://help.salesforce.com/s/articleView?id=005134951&language=en_US&type=1 

Análise da Unidade 42 da Palo Alto Networks  
https://unit42.paloaltonetworks.com/threat-brief-compromised-salesforce-instances/

Divulgação da Cloudflare sobre tokens comprometidos 
https://blog.cloudflare.com/response-to-salesloft-drift-incident/

Investigação da Mandiant sobre o comprometimento do Salesloft no GitHub –
https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift

Ousamos levar a segurança da identidade ainda mais longe.

Descubra o que é possível.

Configure uma demonstração para ver o Silverfort Plataforma de segurança de identidade em ação.

new hero (1)

Silverfort adquire a Fabrix Security

Fornecendo segurança de identidade autônoma em tempo de execução.

Pioneira no primeiro mecanismo autônomo de controle de acesso em tempo de execução, projetado para proteger todas as identidades humanas, de máquinas e de agentes, usando contexto profundo e a velocidade da IA.