Resumo

  • O Google Threat Intelligence Group relatou que, a partir de 8 de agosto até pelo menos 18 de agosto de 2025, o UNC6395 direcionou instâncias de clientes Salesforce usando tokens OAuth comprometidos associados ao aplicativo de terceiros Salesloft Drift.
  • O aviso de confiança da Salesforce disse que a Salesloft, trabalhando com a Salesforce, invalidou tokens de acesso e atualização ativos e removeu o Drift do AppExchange; o problema não decorreu de uma vulnerabilidade na plataforma central da Salesforce.
  • O Trust Center da Salesloft disse posteriormente que a Mandiant investigou uma suspeita de intrusão que afetou o produto Drift e que a investigação avaliou a causa raiz, escopo, contenção, remediação e segmentação entre o Drift e os aplicativos Salesloft.
  • O incidente mostra que o consentimento OAuth não é algo administrativo trivial. Uma integração com permissões profundas pode se tornar um caminho de acesso para dados de CRM do cliente, casos de suporte, credenciais incorporadas em registros e sistemas em nuvem downstream.
  • A responsabilidade segue o controle. A Salesloft controlava o produto Drift e a custódia dos tokens. A Salesforce controlava a governança de aplicativos conectados da plataforma, resposta do AppExchange, canais de notificação ao cliente, visibilidade de auditoria e revogação emergencial de tokens. Os clientes controlavam as aprovações de aplicativos conectados e a higiene dos dados, mas muitas vezes apenas depois que a plataforma e o fornecedor disponibilizaram a integração.

A linha do tempo pública começa com autoridade delegada

O aviso do Google Threat Intelligence Group,Widespread Data Theft Targets Salesforce Instances via Salesloft Drift, é a principal fonte técnica. O GTIG disse que, a partir de 8 de agosto de 2025 até pelo menos 18 de agosto de 2025, o ator rastreado como UNC6395 direcionou instâncias de clientes Salesforce por meio de tokens OAuth comprometidos associados ao aplicativo de terceiros Salesloft Drift. O GTIG disse que o ator exportou grandes volumes de dados de várias instâncias corporativas do Salesforce e procurou por segredos, como chaves de acesso AWS, senhas e tokens Snowflake.

O próprioAviso de Segurançada Salesforce definiu o limite da plataforma. A Salesforce disse que o incidente envolveu o aplicativo Drift publicado pela Salesloft, que a Salesloft, em colaboração com a Salesforce, invalidou tokens de acesso e atualização ativos, e que o Drift foi removido do AppExchange. O aviso também disse que o problema não decorreu de uma vulnerabilidade na plataforma central da Salesforce. Essa declaração é importante e deve ser preservada. O incidente não é evidência de que atacantes exploraram uma vulnerabilidade de software central da Salesforce.

OTrust Centerda Salesloft posteriormente descreveu a investigação da Mandiant sobre uma suspeita de intrusão que afetou o produto Drift. Disse que a Mandiant foi contratada em 26 de agosto de 2025 para determinar a causa raiz e o escopo, auxiliar na contenção e remediação e verificar a segmentação entre os aplicativos Drift e Salesloft. Essa fonte é importante porque coloca a investigação na camada do fornecedor, não apenas na camada da plataforma Salesforce.

A sequência de resposta pública é importante. Google e Salesforce descrevem atividades no início e meados de agosto. O aviso da Salesforce diz que os tokens foram invalidados e o Drift removido do AppExchange. A análise da AppOmni sobre aviolação Drift-Salesforcetambém registra que a Salesloft e a Salesforce revogaram os tokens OAuth do Drift e que as organizações impactadas foram notificadas diretamente pela Salesforce. Obriefing de ameaçasda Unit 42 rastreia a campanha como credenciais OAuth comprometidas usadas para exfiltrar dados de ambientes Salesforce afetados.

O fato crítico de responsabilidade é a autoridade delegada. O OAuth permite que um usuário ou administrador conceda a um aplicativo acesso a dados e ações sem compartilhar a senha do usuário. Esse design é essencial para o SaaS moderno. Também é perigoso quando um aplicativo de terceiros tem escopos amplos, tokens de atualização de longa duração, custódia fraca de tokens e acesso a dados de CRM de alto valor. O token se torna a autoridade.

Isso não foi roubo comum de senha

Muitos manuais de violação ainda pressupõem um login humano. Redefinir a senha, adicionar MFA, revisar o histórico de login e seguir em frente. A campanha Drift mostra por que isso é insuficiente. Um token OAuth não é o mesmo que um usuário digitando uma senha. Ele pode representar um aplicativo confiável que já tem consentimento para acessar dados. Pode contornar alguns controles de login humano porque o aplicativo deve chamar APIs sem uma pessoa presente.

Isso não significa que o MFA seja irrelevante. O MFA pode evitar o comprometimento inicial do usuário e proteger fluxos de trabalho de consentimento administrativo. Mas depois que um token de aplicativo válido existe, os controles importantes são escopos de aplicativo, armazenamento de tokens, tempo de vida do token de atualização, revisão de aplicativos, velocidade de revogação, monitoramento de API e detecção de anomalias de acesso a dados. Um cliente pode ter um bom MFA humano e ainda estar exposto se o token de um aplicativo de terceiros for roubado.

O aviso do FBI e IC3 TLP:CLEAR,Cyber Criminal Groups UNC6040 and UNC6395 Compromising Salesforce Platforms, alertou que o UNC6395 usou tokens OAuth comprometidos para o aplicativo Salesloft Drift e que o mecanismo de acesso diferia de outras campanhas focadas na Salesforce. Oalerta de segurança cibernética da FINRA sobre o ataque à cadeia de suprimentos de IA do Salesloft Driftenquadrou o incidente para empresas financeiras regulamentadas, dizendo que tokens de autenticação OAuth roubados permitiram que atores de ameaças se passassem pelo aplicativo confiável Drift e obtivessem acesso não autorizado aos ambientes dos clientes.

Esses dois avisos mostram por que isso foi uma questão de governança, não apenas uma violação de fornecedor. Empresas regulamentadas tiveram que examinar se um aplicativo de terceiros tinha acesso a dados do Salesforce, se segredos estavam armazenados em registros de CRM e se clientes ou prospects foram expostos. O problema da plataforma e do fornecedor tornou-se um problema de conformidade do cliente.

A documentação da Salesforce sobreaplicativos conectadosdescreve o modelo básico de integração de aplicativos externos com o Salesforce. Sua documentação OAuth para aplicativos conectados, incluindoconfigurações OAuth, mostra por que escopos e políticas são importantes. Esses documentos não são evidências do incidente. Eles explicam a superfície de controle.

Escopos transformaram confiança em raio de explosão

Escopos OAuth definem o que um aplicativo pode fazer. Em um design mínimo, um aplicativo obtém apenas o acesso necessário para uma tarefa específica. Em um design amplo, ele pode ler ou escrever grandes classes de registros, chamar APIs, atualizar o acesso e operar em uma ampla superfície de dados. A campanha Drift questiona se a conveniência da integração superou a disciplina de escopo.

O GTIG relatou que o UNC6395 consultou e exportou sistematicamente dados de ambientes Salesforce e pesquisou registros em busca de credenciais. Isso significa que a exposição não se limitou a uma lista de campos de propriedade da Salesloft. Envolveu dados de CRM do cliente acessíveis por meio da integração. Se um cliente tinha segredos em casos, notas, tópicos de suporte, transcrições de chat, campos personalizados ou anexos do Salesforce, esses segredos poderiam se tornar o próximo estágio de risco.

Esta é uma diferença chave de uma violação da própria tabela de clientes de um fornecedor. O token comprometido permitiu que o atacante alcançasse o ambiente Salesforce de cada cliente conectado. O dano dependia do que cada cliente armazenava, de como sua organização Salesforce estava configurada, de quais objetos o aplicativo podia acessar e se segredos estavam incorporados nos registros. A mesma classe de token roubado poderia produzir danos diferentes entre os clientes.

A análise da AppOmni enfatizou a prevenção SaaS-para-SaaS e a dificuldade de visibilidade entre aplicativos conectados. Oboletim de segurançada Arctic Wolf também enquadrou o evento em torno de tokens OAuth do Salesloft Drift comprometidos e roubo de dados do Salesforce. Essas fontes são análises de fornecedores, mas reforçam o mesmo ponto de controle: integrações SaaS criam identidades não humanas que merecem governança de ciclo de vida.

O termo "identidade não humana" pode parecer abstrato. Neste incidente, significa uma credencial de aplicativo que pode agir sem um humano no teclado. Pode ser aprovada uma vez e depois persistir. Pode ter acesso amplo porque o acesso amplo torna a integração útil. Pode não aparecer em painéis de login de usuário comuns. Pode sobreviver ao processo de negócios que a justificou. Uma vez roubada, pode se mover rapidamente porque chamadas de API são normais para essa identidade.

O marketplace de aplicativos conectados faz parte da cadeia de controle

O aviso da Salesforce disse que o Drift foi removido do AppExchange pendente de investigação adicional. Essa resposta é importante porque o AppExchange não é apenas um diretório. É um sinal de confiança. Os clientes muitas vezes inferem que aplicativos listados no marketplace passaram por um processo de revisão e são apropriados para instalar. O marketplace não elimina a devida diligência do cliente, mas influencia as escolhas do cliente.

Quando um aplicativo do marketplace se torna um caminho de acesso de campanha, a responsabilidade da plataforma não é que ela causou a violação do fornecedor. A responsabilidade é que ela precisa detectar, comunicar, desabilitar e ajudar os clientes a se recuperar mais rápido do que a descoberta cliente por cliente permitiria. Uma plataforma vê instalações de aplicativos entre locatários. Pode identificar quais clientes instalaram o aplicativo. Pode coordenar a revogação de tokens. Pode notificar clientes afetados. Pode remover ou suspender a listagem.

Essa visibilidade entre clientes é precisamente por que a governança da plataforma é importante.

A Salesforce parece ter usado esse papel de plataforma no registro público: seu aviso diz que trabalhou com a Salesloft, invalidou tokens, removeu o aplicativo e notificou organizações impactadas. A questão de responsabilidade é quão rápido isso aconteceu em relação à primeira atividade suspeita e se os clientes tiveram acesso a logs suficientes para determinar sua própria exposição. O GTIG relatou atividade da campanha a partir de 8 de agosto; a revogação de tokens foi relatada em 20 de agosto. O público pode ver o intervalo aproximado, mas não o processo interno de decisão de detecção.

Os clientes também têm responsabilidades. Eles escolhem aplicativos, aprovam escopos, armazenam segredos em registros, monitoram comportamento de API e revisam aplicativos conectados. Mas a responsabilidade do cliente é limitada pelas funcionalidades da plataforma. Se as revisões de aplicativos conectados são difíceis de entender, se os escopos são muito amplos, se os logs são difíceis de acessar, se o inventário de tokens é fragmentado ou se a confiança no marketplace é vaga, os clientes tomam decisões com visibilidade incompleta.

O incidente, portanto, não deve ser enquadrado como um simples exercício de culpa tripla. É uma cadeia: a Salesloft teve que proteger o Drift e seus tokens; a Salesforce teve que governar a confiança dos aplicativos conectados e a revogação de emergência; os clientes tiveram que restringir o acesso do aplicativo e remover segredos dos dados de CRM; os atacantes exploraram a cadeia.