Sumário
- O Google Threat Intelligence Group relatou que, desde 8 de agosto até pelo menos 18 de agosto de 2025, o UNC6395 direcionou-se a instâncias de clientes Salesforce usando tokens OAuth comprometidos associados ao aplicativo de terceiros Salesloft Drift.
- O aviso de confiança da Salesforce informou que a Salesloft, em colaboração 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 Centro de Confiança da Salesloft posteriormente afirmou que a Mandiant investigou uma intrusão suspeita impactando o produto Drift, e que a investigação avaliou a causa raiz, escopo, contenção, remediação e segmentação entre os aplicativos Drift e Salesloft.
- O incidente mostra que o consentimento OAuth não é um plano de fundo administrativo. Uma integração com permissões profundas pode se tornar um caminho de acesso a dados de CRM de clientes, casos de suporte, credenciais incorporadas em registros e sistemas downstream em nuvem.
- A responsabilização 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, a resposta do AppExchange, os canais de notificação aos clientes, a visibilidade de auditoria e a 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 disponibilizavam a integração.
A linha do tempo pública começa com autoridade delegada
O comunicado do Google Threat Intelligence Group,Widespread Data Theft Targets Salesforce Instances via Salesloft Drift, é a fonte técnica central. O GTIG afirmou que, desde 8 de agosto de 2025 até pelo menos 18 de agosto de 2025, o ator rastreado como UNC6395 direcionou-se a 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 da Salesforce e procurou por segredos, como chaves de acesso AWS, senhas e tokens Snowflake.
OComunicado de Segurançada própria Salesforce definiu a fronteira da plataforma. A Salesforce afirmou 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 comunicado 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 os invasores exploraram uma vulnerabilidade de software central da Salesforce.
OCentro de Confiançada Salesloft posteriormente descreveu a investigação da Mandiant sobre uma intrusão suspeita que impactava o produto Drift. Afirmou 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. O Google e a Salesforce descrevem a atividade no início até meados de agosto. O comunicado da Salesforce diz que os tokens foram invalidados e o Drift removido do AppExchange. Aanálise da AppOmni sobre a violação Drift-Salesforcetambém registra que a Salesloft e a Salesforce revogaram os tokens OAuth do Drift e que as organizações afetadas 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 responsabilização é 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 um roubo comum de senha
Muitos manuais de resposta a violações ainda assumem um login humano. Redefina a senha, adicione MFA, revise o histórico de login e siga 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. Ele pode contornar alguns controles de login humano porque se espera que o aplicativo chame APIs sem uma pessoa presente.
Isso não significa que o MFA seja irrelevante. O MFA pode impedir o comprometimento inicial do usuário e pode proteger os fluxos de consentimento administrativo. Mas depois que um token de aplicativo válido existe, os controles importantes são os escopos do aplicativo, o armazenamento de tokens, o tempo de vida do token de atualização, a revisão do aplicativo, a velocidade de revogação, o monitoramento de API e a detecção de anomalias no acesso a dados. Um cliente pode ter um bom MFA humano e ainda assim ficar exposto se o token de um aplicativo de terceiros for roubado.
O comunicado TLP:CLEAR do FBI e IC3,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 Driftcontextualizou o incidente para empresas financeiras regulamentadas, afirmando que tokens de autenticação OAuth roubados permitiram que agentes mal-intencionados se passassem pelo aplicativo confiável Drift e obtivessem acesso não autorizado aos ambientes dos clientes.
Esses dois comunicados mostram por que isso foi uma questão de governança, não apenas uma violação do fornecedor. As empresas regulamentadas tiveram que examinar se um aplicativo de terceiros tinha acesso aos dados da Salesforce, se segredos estavam armazenados em registros de CRM e se clientes ou prospects haviam sido 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 aplicativos externos que se integram à 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
Os 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 escopos.
O GTIG relatou que o UNC6395 consultou e exportou sistematicamente dados de ambientes Salesforce e procurou credenciais nos registros. Isso significa que a exposição não se limitou a uma lista de campos pertencente à Salesloft. Envolveu dados de clientes Salesforce 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 fundamental em relação a uma violação da própria tabela de clientes de um fornecedor. O token comprometido permitiu que o invasor acessasse 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 em aplicativos conectados. Oboletim de segurançada Arctic Wolf também contextualizou o evento em torno de tokens OAuth comprometidos do Salesloft Drift e roubo de dados da Salesforce. Essas fontes são análises de fornecedores, mas reforçam o mesmo ponto de controle: as integrações SaaS criam identidades não humanas que merecem governança de ciclo de vida.
O termo "identidade não humana" pode soar abstrato. Neste incidente, significa uma credencial de aplicativo que pode agir sem um humano no teclado. Pode ser aprovada uma vez e persistir. Pode ter acesso amplo porque o acesso amplo torna a integração útil. Pode não aparecer nos painéis comuns de login de usuários. Pode sobreviver ao processo de negócios que a justificou. Uma vez roubada, pode se mover rapidamente porque as chamadas de API são normais para essa identidade.
O marketplace de aplicativos conectados faz parte da cadeia de controle
O comunicado da Salesforce disse que o Drift foi removido do AppExchange até uma investigação mais aprofundada. Essa resposta é importante porque o AppExchange não é apenas um diretório. É um sinal de confiança. Os clientes muitas vezes inferem que os aplicativos listados no marketplace passaram por um processo de revisão e são apropriados para instalação. O marketplace não elimina a diligência do cliente, mas influencia as escolhas dos clientes.
Quando um aplicativo do marketplace se torna um caminho de acesso de campanha, a responsabilidade da plataforma não é ter causado a violação do fornecedor. A responsabilidade é detectar, comunicar, desabilitar e ajudar os clientes a se recuperarem mais rapidamente do que a descoberta cliente por cliente permitiria. Uma plataforma vê as instalações de aplicativos em todos os tenants. Ela pode identificar quais clientes instalaram o aplicativo. Pode coordenar a revogação de tokens. Pode notificar os clientes afetados. Pode remover ou suspender a listagem.
Essa visibilidade entre clientes é precisamente o motivo pelo qual a governança da plataforma é importante.
A Salesforce parece ter usado esse papel de plataforma no registro público: seu comunicado diz que trabalhou com a Salesloft, invalidou tokens, removeu o aplicativo e notificou as organizações afetadas. A questão de responsabilização é a rapidez com que isso aconteceu em relação à primeira atividade suspeita e se os clientes tiveram acesso suficiente aos logs para determinar sua própria exposição. O GTIG relatou que a atividade da campanha começou já em 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 o comportamento da API e revisam os aplicativos conectados. Mas a responsabilidade do cliente é limitada pelas possibilidades 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 de difícil acesso, 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 tripartite. É uma cadeia: a Salesloft tinha que proteger o Drift e seus tokens; a Salesforce tinha que governar a confiança dos aplicativos conectados e a revogação de emergência; os clientes tinham que restringir o acesso a aplicativos e remover segredos dos dados de CRM; os invasores exploraram a cadeia.
Dados de CRM tornaram-se uma superfície de caça a segredos
A descoberta mais perturbadora do GTIG não foi apenas que os registros de CRM foram exportados. Foi que o ator procurou por segredos. Um ambiente Salesforce pode conter casos de suporte, notas de vendas, detalhes de integração de clientes, tópicos de solução de problemas técnicos, chaves de API coladas em tickets, terminais VPN, identificadores de conta de nuvem, credenciais de integração, senhas acidentalmente armazenadas em comentários de casos ou anexos com dados operacionais sensíveis. Esse material não deveria estar em registros de CRM, mas em organizações reais, muitas vezes está.
Isso desloca o dano da privacidade para o risco lateral. Se um invasor usa uma exportação de CRM para encontrar chaves AWS, tokens Snowflake, credenciais VPN ou outros segredos, a violação pode passar da exposição de dados do cliente para o comprometimento da infraestrutura. O sistema CRM se torna um mapa de outros sistemas. É o local onde as equipes de suporte documentam problemas, e essa documentação pode incluir as pistas necessárias para atacar os sistemas que estão sendo suportados.
O comunicado público do GTIG diz que as organizações devem procurar por segredos e rotacionar credenciais. Esse conselho é operacionalmente caro porque os clientes precisam pesquisar em seus próprios dados material que nunca deveriam ter armazenado ali. O incidente, portanto, expõe uma falha de higiene de dados na camada do cliente. Mas o gatilho foi o comprometimento de uma integração confiável. Os clientes podem não ter percebido que um chatbot ou uma integração de fluxo de receita poderia alcançar registros contendo credenciais.
A Salesforce e os clientes podem reduzir esse risco tratando a varredura de segredos como um controle de CRM. Os registros devem ser verificados em busca de padrões de chave. Os fluxos de trabalho de suporte devem desencorajar a colagem de senhas ou tokens. Campos sensíveis devem ser mascarados. Os escopos do aplicativo não devem incluir objetos que não são necessários. As exportações devem ser monitoradas. Esses não são controles exóticos; são respostas práticas à realidade de que os sistemas de CRM contêm dados operacionais confusos.
O risco também explica por que a notificação ao cliente é importante. Se uma organização cliente foi afetada, sua equipe de segurança precisava saber com rapidez suficiente para pesquisar registros, rotacionar segredos expostos, verificar logs de nuvem downstream e alertar seus próprios clientes, se necessário. Um aviso atrasado ou vago poderia permitir que segredos roubados permanecessem válidos.
A revogação foi necessária, mas não foi recuperação por si só
A revogação de token fecha o caminho imediato de acesso delegado. O comunicado da Salesforce e o GTIG descrevem a revogação ou invalidação dos tokens de acesso e atualização do Drift. Isso foi necessário. Não removeu, por si só, os dados já exportados ou os segredos já coletados. A recuperação teve que continuar dentro dos ambientes dos clientes.
O primeiro passo de recuperação é o escopo da exposição: quais objetos Salesforce foram acessados, quais registros foram consultados, quais trabalhos de API foram executados e quais integrações foram usadas? Adocumentação de monitoramento de eventos e segurança de transaçõesda Salesforce e os logs de API podem ser importantes aqui, mas a disponibilidade dos logs varia de acordo com a edição, configuração, retenção e maturidade do cliente. Os comunicados públicos não podem substituir a evidência no nível do tenant.
O segundo passo é a rotação de segredos. Se os registros continham chaves AWS, tokens Snowflake, credenciais VPN, chaves de API, senhas ou segredos de webhook, esses segredos precisavam ser encontrados e rotacionados. Isso é difícil porque os segredos podem estar em campos de texto livre, anexos, comentários de casos, logs de chat ou objetos personalizados. A busca automatizada ajuda, mas pode não detectar formatos incomuns. A revisão manual é lenta.
O terceiro passo é a notificação a clientes e downstream. Um cliente Salesforce cujos dados de CRM foram exportados pode ter obrigações com seus próprios clientes, funcionários, prospects, parceiros e reguladores. Isso cria um efeito cascata. O incidente da Salesloft tornou-se o incidente da plataforma Salesforce, que se tornou o incidente de cada cliente afetado, que pode se tornar o aviso ao cliente de cada cliente afetado. O custo de um comprometimento OAuth se propaga para fora.
O quarto passo é a revisão da governança de aplicativos. Os clientes precisam perguntar quais outros aplicativos conectados têm escopos semelhantes, se ainda são necessários, se os tokens de atualização são de longa duração, se os proprietários dos aplicativos são conhecidos, se as revisões de risco do fornecedor estão atualizadas e se existem manuais de revogação de emergência. O incidente do Drift deve ser tratado como um ensaio para todas as outras integrações SaaS com permissões profundas.
O rótulo de IA não mudou o problema de responsabilização
Algumas discussões públicas enquadraram o Drift como uma integração de chatbot de IA. Isso é importante para o contexto do produto, mas a falha de segurança não foi mágica devido à IA. A questão principal era o acesso SaaS delegado. Um chatbot, ferramenta de engajamento de vendas, widget de suporte, conector de análise, ferramenta de enriquecimento de dados ou plataforma de automação de marketing podem todos se tornar perigosos se detiverem tokens amplos para os sistemas dos clientes.
A IA pode aumentar o apetite por integrações porque as empresas querem que as ferramentas de conversação vejam mais contexto. Um chatbot de vendas ou suporte é mais útil se puder ler registros de CRM, responder a perguntas de clientes, atualizar casos, encaminhar leads e personalizar respostas. Cada escopo adicional aumenta a utilidade e o risco. Se o token por trás desse escopo for roubado, o invasor receberá o mesmo contexto amplo que tornou o produto atraente.
Esta é a economia de segurança da automação SaaS. Os fornecedores vendem fluxos de trabalho mais fluidos. Os clientes aprovam o acesso porque o fluxo de trabalho economiza mão de obra. As plataformas hospedam o modelo de permissão porque as integrações expandem o valor do ecossistema. O risco é que nenhuma das partes precifique totalmente o custo de um comprometimento de token até depois de uma campanha. O incidente do Drift é um estudo de caso desse risco subprecificado.
O alerta da FINRA é importante porque as empresas financeiras regulamentadas não podem tratar isso como uma notícia geral de tecnologia. Se uma empresa financeira usou o Drift com a Salesforce, ela teve que avaliar se dados de clientes, prospects ou internos foram expostos e se credenciais em registros de CRM criaram risco downstream. A mesma lógica se aplica na saúde, educação, software, contratação pública e em qualquer setor onde a Salesforce contém contexto operacional sensível.
O incidente expôs uma assimetria de visibilidade
As plataformas veem padrões que os clientes individuais não podem. Um único cliente pode notar um comportamento estranho de API em sua própria organização Salesforce. A Salesforce pode ver instalações de aplicativos do AppExchange, invalidações de tokens e padrões entre clientes. A Salesloft pode ver a telemetria do produto Drift e a custódia de tokens. O Google Threat Intelligence pode ver a atividade de ameaça entre clientes e suas próprias investigações. Nenhum cliente pode ver a campanha inteira.
Essa assimetria cria deveres. A parte com visibilidade entre clientes deve alertar rapidamente. A parte com telemetria de produto deve investigar e conter rapidamente. A plataforma deve ajudar a identificar quais clientes são afetados. Os clientes devem agir rapidamente uma vez notificados. Se qualquer parte esperar por evidências perfeitas, o invasor pode continuar usando autoridade válida.
O registro público sugere ação coordenada, mas não a velocidade exata da escalada interna. O GTIG disse que a campanha começou já em 8 de agosto. O comunicado da Salesforce relatou ações de invalidação e remoção. O Centro de Confiança da Salesloft afirma que a Mandiant foi contratada em 26 de agosto. Essas datas mostram movimento, mas não mostram quando cada parte soube o suficiente para agir ou quais sinais estavam disponíveis antes.
Essa linha do tempo ausente é importante porque as campanhas OAuth são rápidas. Uma vez que os tokens são roubados, o invasor pode automatizar consultas e exportações. Uma diferença de dias pode determinar se os clientes rotacionam segredos antes ou depois do uso. Uma análise postmortem de alta qualidade mostraria o tempo de detecção, o tempo de decisão, o tempo de invalidação de token, o tempo de notificação ao cliente e o tempo de disponibilidade de logs.
O que os clientes devem aprender sem serem culpados
Os clientes têm responsabilidades, mas a lição não deve se tornar "os clientes deveriam saber mais." Muitos clientes instalam aplicativos do marketplace porque confiam nos sinais de confiança da plataforma. Eles aprovam escopos porque os fornecedores dizem que os escopos são necessários. Eles armazenam dados operacionais no CRM porque os funcionários usam o CRM como a memória compartilhada do trabalho do cliente. Esses são comportamentos comerciais normais, não atos imprudentes por padrão.
A melhor lição é a governança disciplinada de aplicativos conectados. Os clientes devem inventariar aplicativos conectados, proprietários, escopos, tempos de vida dos tokens, datas de último uso e status de risco do fornecedor. Eles devem remover aplicativos que não são mais necessários. Eles devem restringir perfis e conjuntos de permissões disponíveis para aplicativos. Eles devem verificar dados de CRM em busca de segredos. Eles devem monitorar o comportamento da API por aplicativo, não apenas por usuário. Eles devem ter um manual para revogação de token de emergência.
A Salesforce pode tornar essas responsabilidades dos clientes mais fáceis ou mais difíceis. Explicações claras de permissões de aplicativos, pontuação de risco de aplicativos, avisos administrativos para escopos amplos, inventário simples de tokens, melhor expiração padrão, alertas de anomalias e revisão robusta do AppExchange podem reduzir a carga do cliente. O design da plataforma molda o comportamento do cliente.
A Salesloft e outros fornecedores SaaS também podem reduzir a carga armazenando tokens com segurança, minimizando os escopos necessários, rotacionando credenciais, publicando atualizações de incidentes rapidamente e comprovando a segmentação. A referência do Centro de Confiança da Salesloft à verificação da segmentação entre os aplicativos Drift e Salesloft é importante porque os clientes precisam de confiança de que o comprometimento de um produto não se tornou um comprometimento mais amplo do fornecedor.
Os padrões OAuth explicam por que tokens portadores exigem disciplina extra
O OAuth foi projetado para autorização delegada. A especificação central do OAuth 2.0,RFC 6749, permite que um cliente obtenha tokens de acesso a recursos com a autorização do proprietário do recurso. O design é poderoso porque o usuário não precisa fornecer sua senha ao cliente. O risco é que um token de acesso geralmente é uma credencial portadora: quem o detém pode usá-lo dentro de seu escopo até que expire ou seja revogado.
O modelo de ameaça OAuth e as considerações de segurança naRFC 6819alertam sobre vazamento de tokens, armazenamento de tokens, reprodução, phishing, abuso de redirecionamento e a necessidade de limitar escopo e tempo de vida. A mais recente Melhor Prática Atual de Segurança do OAuth 2.0,RFC 9700, continua essa direção enfatizando padrões defensivos modernos. Esses padrões não são relatórios de incidentes da Salesforce. Eles explicam por que a campanha Drift foi estruturalmente perigosa.
Se um token Drift tivesse amplo acesso à Salesforce, o próprio token incorporava confiança. Uma equipe de segurança poderia remover a senha do usuário, impor MFA e ainda assim enfrentar riscos se o token do aplicativo permanecesse válido. É por isso que a revogação de token foi a ação de emergência. Também é por isso que a próxima camada é a minimização de escopo. Um token roubado com escopo restrito pode ser prejudicial, mas limitado. Um token roubado com amplo acesso de leitura pode se tornar uma ferramenta de exportação de dados.
A técnica do MITRE ATT&CKSteal Application Access Tokendescreve adversários roubando tokens de acesso de aplicativos para acessar sistemas e APIs remotos. Sua técnica paraUse Alternate Authentication Materialcobre o padrão mais amplo de usar artefatos de autenticação válidos em vez de senhas. Essas estruturas ajudam a nomear a classe de ataque sem exagerar os fatos específicos da Salesforce: o problema era material delegado válido nas mãos erradas.
A lição padrão é simples, mas operacionalmente difícil. Tokens devem ser tratados como segredos. Tokens de atualização devem ser tratados como segredos especialmente sensíveis, pois podem gerar acesso futuro. Os escopos devem ser tão restritos quanto o produto pode tolerar. Os tokens devem ser rotacionáveis e revogáveis. Os logs devem mostrar o uso de tokens por aplicativo e por objeto. Os clientes devem saber quais identidades não humanas podem ler seus dados. As plataformas devem dificultar a aprovação silenciosa de escopos perigosos.
A higiene de aplicativos conectados precisa de um proprietário, não de uma planilha após a violação
Muitas organizações descobrem seus aplicativos conectados durante um incidente. Isso é tarde demais. Um inventário de aplicativos conectados deve existir antes da campanha: nome do aplicativo, fornecedor, proprietário do negócio, proprietário técnico, escopos, perfis instalados, último uso, política de token de atualização, objetos de dados acessados, status do contrato e procedimento de remoção. Se ninguém é proprietário do aplicativo, ninguém é proprietário do risco.
A documentação da Salesforce paragerenciar aplicativos conectadosepolíticas OAuth para aplicativos conectadosmostra que a plataforma oferece controles administrativos. A questão é se os clientes têm a equipe, o conhecimento e os incentivos para usá-los bem. Uma pequena empresa pode instalar uma ferramenta de chat de vendas e nunca revisar seus escopos. Uma grande empresa pode ter centenas de aplicativos conectados e nenhuma cadência de revisão unificada.
É aqui que o design da plataforma deve reduzir erros. Escopos perigosos devem ser visíveis em linguagem simples. Aplicativos conectados não utilizados devem ser fáceis de encontrar. Aplicativos com tokens de atualização devem ser destacados. Aplicativos de alto risco devem ter opções de expiração ou reautorização periódica. Os administradores devem poder revogar o acesso ao aplicativo sem interromper fluxos de trabalho não relacionados. As equipes de segurança devem receber alertas de anomalias de API específicos por aplicativo.
Os clientes também precisam de política. Nenhum aplicativo deve receber acesso amplo sem um proprietário nomeado e data de revisão. Nenhum aplicativo deve permanecer instalado depois que o proprietário do negócio sair. Nenhum aplicativo deve armazenar segredos em registros de CRM apenas porque é conveniente. Nenhum aplicativo deve ser isento de manuais de incidentes porque é "apenas uma ferramenta de vendas." A campanha Drift mostrou que uma ferramenta de vendas pode se tornar um caminho de incidente de segurança.
O problema é em parte econômico. Aplicativos conectados economizam mão de obra. A revisão custa mão de obra. Se o benefício é imediato e o risco é raro, as organizações subinvestem em revisão. A plataforma e o fornecedor podem reduzir esse desequilíbrio diminuindo o custo de uma boa governança: painéis claros, pontuações de risco, recomendações automatizadas e padrões mais seguros.
Os logs devem responder a perguntas que um cliente pode agir
As orientações de incidentes geralmente dizem aos clientes para revisar os logs. Esse conselho só é útil se os logs responderem às perguntas certas. Para a campanha Drift, os clientes precisavam saber quais tokens de aplicativo foram usados, quais objetos Salesforce foram consultados, quais registros foram exportados, de quais IPs, com qual contexto de usuário, em qual janela de tempo e se as consultas procuraram por strings semelhantes a segredos.
O monitoramento de eventos da Salesforce, logs de API e relatórios de aplicativos conectados podem ajudar, mas o acesso a evidências completas pode depender de licenciamento, retenção e configuração. Um cliente que não possui a edição correta ou pipeline de exportação de logs pode receber um aviso e ainda assim ter dificuldade para determinar a exposição. Isso é uma questão de governança da plataforma. Quando uma integração do marketplace é abusada entre clientes, a plataforma está na melhor posição para fornecer pacotes de evidências normalizados.
Os clientes também precisam de um caminho de triagem repetível. Primeiro, identificar se o Drift estava instalado e conectado. Segundo, determinar se os tokens estavam ativos durante a janela da campanha. Terceiro, inspecionar a atividade da API atribuída ao aplicativo. Quarto, identificar o acesso a objetos e campos. Quinto, pesquisar segredos nos registros exportados ou acessíveis. Sexto, rotacionar quaisquer segredos que possam ter sido expostos. Sétimo, notificar as partes downstream se dados regulamentados ou de clientes estiverem envolvidos.
O comunicado do FBI/IC3 e as orientações do GTIG apontam os clientes para esse tipo de ação, mas a execução varia muito. Uma grande empresa financeira pode ter uma equipe de operações de segurança e um lago de logs. Uma pequena empresa de SaaS pode ter um administrador Salesforce, um fornecedor de segurança gerenciada e um backlog. A mesma campanha, portanto, cria cargas de recuperação desiguais.
Essa desigualdade é importante para a responsabilização. As plataformas que atendem empresas de níveis de maturidade muito diferentes não devem presumir que todos os clientes podem interpretar logs brutos ou indicadores de inteligência de ameaças. Evidências acionáveis e específicas do tenant reduzem o custo da resposta e a chance de que segredos roubados permaneçam válidos.
Segredos em registros de CRM são uma falha evitável, mas comum
Uma lição desconfortável é que os clientes precisam parar de tratar o CRM como um local seguro para segredos operacionais. As equipes de suporte e vendas geralmente colam chaves de API, credenciais, tokens portadores, segredos de webhook, detalhes de VPN ou capturas de tela em casos e notas porque estão tentando resolver um problema. O CRM se torna um arquivo de conveniência. Quando uma integração pode lê-lo, o arquivo de conveniência se torna um repositório de segredos.
AFolha de Dicas de Gerenciamento de Segredosda OWASP explica por que os segredos precisam de armazenamento controlado, rotação e disciplina de acesso. A campanha Drift aplica esse princípio aos dados de CRM. Se segredos aparecerem em registros, uma exportação de CRM pode se tornar um chaveiro.
A correção é em parte técnica: examinar registros em busca de padrões de segredos, mascarar campos sensíveis, restringir anexos e alertar quando formatos de chave conhecidos aparecerem. Também é cultural: treinar as equipes de suporte para não solicitar ou armazenar segredos, fornecer canais de entrada seguros para material de diagnóstico necessário e facilitar a eliminação de segredos quando descobertos. Se a organização pune o suporte lento, mas não as anotações de suporte inseguras, os funcionários continuarão tomando atalhos.
A Salesforce e os fornecedores de integração podem ajudar criando recursos de detecção de segredos e alertando os clientes quando escopos amplos de aplicativos incluem objetos que provavelmente contêm dados operacionais sensíveis. Mas os clientes ainda são responsáveis pela higiene dos dados dentro de suas organizações. O incidente Drift não criou a má prática de armazenar segredos no CRM; revelou como essa prática pode amplificar um comprometimento de token de terceiros.
O registro público deve preservar o que não aconteceu
É igualmente importante declarar o que o registro público não mostra. As fontes não mostram que os invasores exploraram uma vulnerabilidade central da Salesforce. Elas não mostram que todos os clientes Salesforce foram afetados. Elas não mostram que todos os clientes conectados ao Drift tiveram os mesmos dados exportados. Elas não mostram que todos os registros exportados continham segredos. Elas não mostram que o conjunto mais amplo de produtos da Salesloft foi comprometido além do que a investigação da Salesloft descreveu.
Esses limites protegem a justiça. Eles também tornam a lição real mais nítida. O incidente é sério sem exagero, porque uma integração confiável tornou-se um caminho de acesso delegado aos ambientes dos clientes. A gravidade vem do modelo de confiança, não da necessidade de inventar um zero-day da plataforma.
O incidente também não deve ser reduzido a "risco de terceiros" em um sentido vago. O risco específico de terceiros foi a custódia de tokens e a autoridade de aplicativos conectados. Um fornecedor pode ter relatórios SOC, contratos e questionários de segurança e ainda assim possuir tokens que exigem proteção excepcional. As revisões de risco de fornecedores dos clientes precisam perguntar como as integrações SaaS armazenam tokens, quais escopos exigem, com que rapidez os tokens podem ser revogados e quais evidências o fornecedor pode fornecer após um incidente.
A revisão do AppExchange da plataforma também precisa de especificidade. Não deve apenas verificar se um aplicativo funciona e atende aos requisitos básicos de segurança no momento da listagem. Deve apoiar o monitoramento contínuo, a suspensão rápida, a notificação ao cliente e a revalidação pós-incidente. A confiança em um marketplace é uma obrigação contínua, não um selo único.
Quais evidências mudariam a avaliação
A avaliação poderia mudar em qualquer direção com mais evidências. Se detalhes forenses posteriores mostrarem que os tokens comprometidos eram extremamente restritos, que as exportações foram limitadas e que os clientes afetados receberam logs completos no nível de objeto rapidamente, a gravidade operacional deve ser reduzida. Se evidências posteriores mostrarem escopos mais amplos, tokens de longa duração, armazenamento fraco de tokens, revogação atrasada ou exposição generalizada de segredos, a gravidade deve aumentar.
Se a Salesforce publicar mais detalhes sobre melhorias no monitoramento do AppExchange, recursos de inventário de tokens, pacotes de logs para clientes ou padrões mais seguros para aplicativos conectados, isso fortaleceria o registro de reparação. Se a Salesloft publicar mais detalhes sobre a causa raiz, custódia de tokens, segmentação e remediação do cliente, isso fortaleceria a responsabilização do fornecedor. Se os reguladores emitirem conclusões, elas devem ser avaliadas separadamente do registro atual de comunicados públicos.
Até lá, as evidências sustentam uma conclusão de controle de alta confiança: os ecossistemas SaaS precisam de governança de aplicativos conectados que trate tokens delegados como credenciais de produção, não como encanamento de integração.
Essa conclusão é útil precisamente porque evita alegações exageradas. Permite que os clientes fortaleçam os aplicativos conectados sem esperar por um registro judicial final. Permite que as plataformas melhorem os controles de marketplace e de tokens sem admitir uma falha na plataforma central que as evidências não mostram. Permite que os fornecedores tratem a custódia de tokens como uma obrigação de segurança do produto. A lição da campanha não é especulativa: o acesso delegado pode ser roubado e, quando isso acontece, o ecossistema precisa saber quem pode revogá-lo, quem pode explicá-lo e quem pode provar o que ele tocou.
Exercícios de revogação devem ser rotineiros
A maneira mais rápida de saber se a governança OAuth é real é executar um exercício de revogação antes de um incidente. Escolha um aplicativo conectado não crítico. Identifique o proprietário do negócio, escopos, usuários, tokens, logs, fluxos de trabalho dependentes e caminho de reversão. Revogue o acesso em uma janela controlada e meça o que quebra. Em seguida, documente quem aprovou a restauração e quais evidências mostraram que o aplicativo era seguro para reconectar.
Esse exercício transforma o inventário abstrato de aplicativos em conhecimento operacional. Mostra se a segurança pode encontrar o aplicativo, se os administradores podem revogá-lo, se o negócio entende o fluxo de trabalho, se os usuários recebem instruções claras e se os logs podem provar o que o aplicativo acessou. Também revela onde as equipes têm medo de mexer em integrações antigas porque ninguém sabe por que elas existem.
A campanha Drift mostra por que essa prática é importante. Em um comprometimento real, a organização não pode passar dias descobrindo quem é o proprietário de uma integração enquanto os invasores usam tokens roubados. Um cliente preparado pode revogar primeiro, investigar rapidamente e reconectar apenas com evidências. Um cliente despreparado pode hesitar, porque cada token parece continuidade dos negócios.
O teste de responsabilização
A campanha Drift-Salesforce deve ser julgada por meio de sete controles.
Primeiro, custódia de tokens: a Salesloft protegeu os tokens de acesso e atualização como credenciais altamente sensíveis e sua arquitetura minimizou a exposição de tokens entre o Drift e outros produtos?
Segundo, design de escopos: a integração do Drift solicitou apenas as permissões da Salesforce de que precisava e os clientes entenderam o raio de impacto ao aprovar essas permissões?
Terceiro, governança do marketplace: o processo de revisão, monitoramento e remoção de emergência do AppExchange da Salesforce reduziu o risco do cliente com rapidez suficiente quando o aplicativo do fornecedor se tornou inseguro?
Quarto, detecção entre clientes: a Salesforce, a Salesloft e os parceiros de inteligência de ameaças identificaram padrões de campanha com rapidez suficiente para revogar tokens antes de novas exportações?
Quinto, evidências do tenant: os clientes afetados receberam logs, evidências de acesso a objetos e orientação suficientes para determinar o que foi consultado e se segredos foram expostos?
Sexto, higiene de segredos: os clientes armazenaram senhas, chaves de API, tokens de nuvem ou credenciais VPN em registros Salesforce e os rotacionaram após a exposição?
Sétimo, comunicação pública: os comunicados preservaram a distinção crítica de que o núcleo da Salesforce não foi explorado, deixando claro que os dados de clientes da Salesforce foram acessados por meio de tokens de aplicativos confiáveis?
A conclusão final não é que a Salesforce era o produto vulnerável. O registro público diz o oposto: o problema não decorreu de uma vulnerabilidade na plataforma central da Salesforce. A conclusão é que a fronteira de confiança da Salesforce inclui aplicativos conectados porque os clientes experimentam a plataforma por meio de seu ecossistema. Os tokens OAuth são autoridade delegada. Quando uma integração confiável perde essa autoridade, a plataforma, o fornecedor e o cliente têm deveres distintos.
A campanha Drift tornou esses deveres visíveis da maneira mais desconfortável: transformando uma integração de produtividade aprovada em uma chave nas mãos de um invasor.