O agente não foi enganado. Usaram o crachá dele

// 00

A contagem da edição 1 se atualiza

começo assumindo um erro meu

Na edição anterior eu escrevi que, dos cinco casos analisados, apenas um tinha sido um ataque real que chegou a usuários. Os outros quatro eram divulgação coordenada, prova de conceito ou falha operacional, e eu insisti que confundir essas categorias destrói a credibilidade de quem escreve sobre segurança.

Essa contagem está desatualizada. Existe mais um caso, que não entrou na edição 1, e ele é maior do que o único que eu tinha contado.

Em agosto de 2025, um ator identificado pelo Google Threat Intelligence Group como UNC6395, e pelo time de inteligência da Cloudflare como GRUB1, exfiltrou dados de instâncias Salesforce de mais de setecentas organizações usando tokens roubados da integração do Drift. Entre as vítimas que confirmaram publicamente estão Cloudflare, PagerDuty, Palo Alto Networks, Proofpoint, SpyCloud, Tanium e Zscaler.

O Drift é o agente de chat de IA da Salesloft. Ele atende o visitante do site, responde pergunta, qualifica o interesse e captura o contato. Para esse contato virar oportunidade comercial, ele precisa cair no CRM. Então cada empresa instalou o Drift a partir do AppExchange e autorizou a conexão com o próprio Salesforce. Foi a credencial dessa conexão que o atacante roubou.

Abrir assumindo o erro é o preço de escrever sobre um assunto que se move. Prefiro pagar esse preço a manter uma contagem bonita.

// 01

O agente de IA não foi enganado

a tese desta edição, e ela contraria quase tudo que circula

A edição 1 tratou de ataques que entram pela conversa. Alguém escreve alguma coisa numa página, num e-mail ou num ticket, o agente lê aquilo como se fosse instrução, e passa a trabalhar para outra pessoa.

No caso Salesloft Drift, nada disso aconteceu. Ninguém escreveu nada para o agente ler. O modelo não foi manipulado, não recebeu instrução envenenada e não tomou nenhuma decisão errada. O agente sequer precisava estar em funcionamento no momento do ataque.

O que o atacante usou foi a identidade que aquele agente já tinha dentro dos sistemas de setecentas empresas.

// 02

O que é um token, em português

sem isso, o resto da edição não faz sentido

Quem autorizou a conexão

Alguém, em algum momento, instalou o Drift e clicou em autorizar. Provavelmente um gerente de marketing, provavelmente em quinze minutos, provavelmente numa tela que listava permissões que ninguém leu. A conexão ficou de pé por um ou dois anos, funcionando, e ninguém voltou a olhar para ela.

Essa conexão é o objeto do ataque.

Agora o crachá

Quando você entra no Salesforce, você digita usuário, senha e o segundo fator. O sistema confere quem você é e abre a sessão.

Uma integração não faz isso. Ela não tem usuário, não digita senha, não recebe SMS. O que ela recebe, uma vez só, no dia em que foi autorizada, é um token. Um crachá permanente emitido pelo Salesforce dizendo que quem apresentar aquilo pode ler determinados dados.

Três características desse crachá explicam o incidente inteiro.

• Ele não tem foto. O Salesforce não verifica quem está do outro lado da conexão, só confere se o crachá é válido.
• Ele não vence sozinho. Foi emitido em algum momento de 2023 ou 2024 e continuava valendo em agosto de 2025.
• Ele já é a autorização. Não existe um passo de login para o MFA proteger, porque o login já aconteceu, uma vez, anos atrás, e o resultado daquele login virou um arquivo guardado no servidor do fornecedor.

// 03

A cadeia foi de credencial do começo ao fim

o mesmo mecanismo se repete em três níveis

A Mandiant foi contratada pela Salesloft para determinar a causa raiz, e o resultado foi publicado no portal de confiança da própria Salesloft. Vale ler devagar.

Entre março e junho de 2025, o atacante acessou a conta do GitHub da Salesloft. Baixou conteúdo de vários repositórios, adicionou um usuário convidado e criou workflows. O resumo final da investigação, concluída em 30 de setembro de 2025, registra que ele usou Personal Access Tokens do GitHub da Salesloft para reconhecimento e enumeração de segredos, e exfiltrou segredos de variáveis de ambiente e repositórios de código. Token de novo, um degrau acima.

Com o que encontrou, acessou o ambiente AWS do Drift. Dentro dele estavam guardados os tokens OAuth das integrações de todos os clientes. Um arquivo com os crachás de setecentas empresas.

Em nenhum desses três degraus houve exploração de vulnerabilidade, quebra de senha ou engano de sistema. Em cada degrau havia uma credencial de longa duração guardada em algum lugar, esperando.

// 04

Como foi por dentro de uma vítima

a Cloudflare publicou o relatório mais detalhado que existe sobre este caso

É o que transforma o caso de estatística em cena. Todos os horários abaixo são UTC e vêm do postmortem de 2 de setembro de 2025.

Dois momentos merecem parar

O primeiro é 14 de agosto às 11h09, quando ele pergunta ao Salesforce quais são os limites operacionais da API. Ele quis saber de quanto era o teto antes de decidir quanto puxar, para roubar sem estourar nenhum contador e sem acender nenhum alarme. Isso derrota por construção qualquer controle que procure comportamento anormal.

O segundo é a duração. Foram nove dias de operação para pouco mais de três minutos de roubo. Tudo isso apresentando um crachá válido, dentro do horário comercial da API, sem gerar um único evento de login suspeito.

Fonte: Cloudflare, The impact of the Salesloft Drift breach on Cloudflare and our customers, 02.09.2025. Linha do tempo detalhada publicada no próprio postmortem.

// 05

O que foi levado é pior do que parece

o chamado de suporte virou cofre sem ninguém decidir isso

Não foram senhas de clientes nem dados financeiros. Foi o texto dos chamados de suporte: assunto, corpo da mensagem e contato de quem abriu. Anexos não foram acessados.

Acontece que ninguém trata chamado de suporte como sistema sensível. Quando um cliente está com um problema técnico às onze da noite, ele cola no ticket o log inteiro, a configuração, e às vezes a chave.

A Cloudflare escreve com todas as letras que não pede credencial em chamado. Ainda assim varreu os dados roubados com ferramentas próprias de detecção por regex, entropia e padrão, e encontrou 104 tokens de API da própria Cloudflare colados ali dentro por clientes. Todos foram rotacionados, sem atividade suspeita identificada.

O atacante sabia disso antes de começar. O objetivo primário avaliado pelo GTIG era colheita de credencial, e as buscas foram por padrões de chave AWS de longa duração, por menções a Snowflake e por strings de senha. A exfiltração do Salesforce era o meio. O alvo era o que as pessoas escreveram por descuido dentro do Salesforce.

// 06

Ninguém percebeu por conta própria

a parte desconfortável

A Cloudflare tem um dos programas de segurança mais maduros do mercado, publica postmortem de tudo e opera o próprio time de inteligência de ameaças.

A exfiltração terminou em 17 de agosto. A Cloudflare ficou sabendo em 23 de agosto, porque o Salesforce e a Salesloft avisaram.

Entre uma data e outra, em 20 de agosto, a Salesloft revogou os tokens de todos os clientes e publicou um aviso dizendo apenas que havia detectado um problema de segurança no Drift, pedindo que os administradores reautenticassem a conexão com o Salesforce. O aviso não mencionava roubo de token. A Cloudflare registra no relatório que, naquele momento, não tinha indicação de que aquilo dizia respeito ao ambiente dela.

Eu não estou dizendo que a Cloudflare falhou. Estou dizendo que a detecção desse tipo de acesso é estruturalmente difícil por quatro motivos que se somam.

1. O tráfego é legítimo e a credencial é válida, então nenhum controle de autenticação dispara.
2. O volume respeita os limites da plataforma, porque o atacante consultou quais eram.
3. Não existe evento de login, porque não houve login.
4. O log que registraria a anomalia na origem fica do lado do fornecedor.

Se acontecesse com você, você descobriria por e-mail.

// 07

O padrão que se repete

juntando os casos da edição 1 com este

Aparece uma coisa que eu não vi ninguém escrever.

Na edição 1, o atacante fornece a instrução. Ele escreve num lugar que o agente vai ler e o agente executa aquilo como se fosse ordem do dono.

Aqui, o atacante fornece a credencial. Ele apresenta o crachá do agente e o sistema executa aquilo como se fosse o agente.

São dois caminhos e um destino. Nos dois, uma ação é praticada em nome da empresa sem que nenhuma pessoa a tenha aprovado naquele momento. A diferença está em qual metade do agente foi ocupada, o comportamento ou a identidade.

A consequência é desagradável para quem está investindo hoje

Modelo melhor, guardrail melhor e filtro de prompt melhor resolvem apenas o primeiro caminho. Nenhum deles toca no segundo. Um modelo perfeito, incapaz de ser enganado por qualquer instrução, não teria mudado nada em agosto de 2025, porque o modelo não participou.

Nos dois caminhos vale a mesma coisa. Reduzir a autoridade permanente que o agente carrega. Se o agente só pode fazer o que a função dele exige, fica menos perigoso ser enganado e fica menos útil roubar o crachá dele.

// 08

A pergunta que ninguém sabia responder

três perguntas que ninguém tinha como responder em poucas horas

Quando o alerta saiu, cada empresa afetada precisou responder três coisas em poucas horas. Quais integrações de IA estão conectadas aos meus sistemas. Que permissões cada uma tem. Que credencial está por trás de cada uma, emitida quando e por quem.

Praticamente ninguém tinha essa lista pronta. A primeira recomendação do GTIG é revisar todas as integrações de terceiros conectadas à instância do Drift, o que pressupõe que exista alguém capaz de enumerá-las. O aviso da Salesloft aos parceiros de integração pede que revoguem chaves de API proativamente, o que pressupõe saber quais existem.

Eu poderia parar aqui e deixar isso como inferência a partir do comportamento das vítimas. Prefiro trazer medição, e ela é a próxima seção.

// 09

O que a gente mediu

a única evidência deste documento que não veio de fonte de terceiro

A gente rodou a varredura de descoberta do RADAR·AI contra uma frota de produção Databricks de um cliente. Esse cliente tinha feito levantamento manual antes, o que já coloca ele acima da média.

O inventário automático encontrou duas vezes e meia mais agentes do que a conferência humana, e revelou uma categoria inteira que ninguém tinha mapeado.

A distância entre o que uma empresa acha que tem e o que ela tem é o tamanho da superfície que ela não está defendendo. Em agosto de 2025, setecentas empresas descobriram esse número por e-mail.

// 10

O que teria segurado

separado por nível de garantia, do demonstrável ao probabilístico

Quase tudo que foi recomendado publicamente depois do incidente é limpeza. Revogar token, rotacionar chave, revisar integração são ações corretas, e todas acontecem depois do roubo. Vale separar o que impediria de acontecer do que apenas reduz o estrago.

Restrição de IP na aplicação conectada

Este é o controle mais forte do caso inteiro, e existia dos dois lados antes do ataque. O Salesforce permite configurar a política de IP de uma connected app para forçar restrição, o que faz o token só funcionar se a requisição vier de um endereço autorizado. A Salesloft publica a lista de IPs de onde o tráfego legítimo do Drift sai, e escreveu no próprio aviso que qualquer conexão autenticada com token do Drift vinda de fora daquela lista deveria ser tratada como maliciosa.

Os acessos à Cloudflare vieram de um endereço AWS e de um endereço DigitalOcean. Nenhum dos dois pertence ao Drift. Registro aqui uma inferência minha, e não um fato documentado. Com a restrição de IP ativa, o token roubado seria válido e inútil. O Salesforce teria recusado antes de olhar o crachá.

É determinístico porque não avalia intenção nem comportamento. É uma comparação de endereço. E é gratuito.

Escopo mínimo na aplicação conectada

O Drift existe para capturar um contato e jogar no CRM. Para isso ele precisa escrever Lead e Contact. O que o atacante levou foi o objeto Case, o texto dos chamados de suporte, que não tem nenhuma relação com a função de um chatbot de site. O GTIG recomenda explicitamente revisar os escopos das connected apps e evitar permissões amplas como acesso full. O token não faz o que o escopo não permite, independentemente de quem o está apresentando.

Segredo fora de campo de texto livre

Os 104 tokens que a Cloudflare precisou rotacionar não estavam num cofre. Estavam colados por clientes dentro do corpo de chamados. Nenhum controle de identidade protege isso, porque a credencial já estava do lado de dentro, em texto puro, num sistema classificado como comercial.

Credencial de curta duração no lugar de credencial permanente

A remediação que a Mandiant impôs à Salesloft inclui a eliminação de Personal Access Tokens e de colaboradores externos como meio de acesso ao GitHub. Foi exatamente o PAT que sustentou os três meses de reconhecimento no primeiro degrau. Credencial que expira sozinha transforma um comprometimento permanente num comprometimento com prazo.

Monitoramento de evento e alerta de exportação em massa

O Salesforce registra as consultas executadas e o volume de linhas retornadas. A Cloudflare tinha esses logs. Foi com eles que reconstruiu o ataque inteiro, inclusive a parte que o atacante tentou apagar.

Reconstruiu depois. O controle existia, o dado existia, o que não existia era um gatilho que transformasse exportação em massa por uma integração fora do padrão em um telefone tocando. Regra mal calibrada vira ruído que ninguém lê.

Rotação frequente de credencial

A Cloudflare passou a rotacionar os segredos das integrações semanalmente depois do incidente. Reduz a janela, não fecha a porta. O reconhecimento durou cinco dias e a exfiltração durou três minutos.

Varredura de segredo nos dados já armazenados

O GTIG recomenda rodar ferramentas como o Trufflehog nos objetos do Salesforce procurando chave e senha. A ironia vale ser dita, porque ela é instrutiva. O Trufflehog aparece no relatório da Cloudflare como o User-Agent do atacante no primeiro dia de reconhecimento. A mesma ferramenta, dos dois lados, dependendo de quem chega primeiro.

Autenticação multifator

Não entra na conta. Não existe login para proteger. O MFA defende o momento em que uma pessoa prova quem é, e aqui não havia pessoa, não havia momento e não havia prova.

Certificação do fornecedor

Preciso dizer isto em voz alta porque a Jump vive disso. A Salesloft tem ISO 27001, ISO 27701 e SOC 2 Tipo II, com os certificados publicados no mesmo portal de confiança que usei como fonte primária deste texto. Nada disso impediu o incidente.

Certificação atesta que existe processo documentado, revisado e auditado. Não atesta que o processo resiste a um ator específico num dia específico. O valor real de um fornecedor certificado apareceu depois. A Salesloft tinha portal de confiança, contratou resposta a incidente, publicou linha do tempo, publicou indicadores de comprometimento e publicou o resumo final da investigação. Isso é maturidade de processo, e é o que permitiu que esta edição existisse com fonte primária.

Detecção comportamental em tráfego de integração

Em 14 de agosto o atacante consultou o endpoint de limites da API antes de decidir quanto puxar. Um adversário que calibra o próprio volume para ficar dentro do normal derrota, por construção, um controle que procura o anormal.

// 11

Checklist para quem constrói

ordenado de maior para menor retorno

Nesta semana

1. Liste toda integração de IA conectada aos seus sistemas de registro: CRM, e-mail, armazenamento, service desk, mensageria. Se a lista não existe pronta, esse é o achado mais importante do exercício.
2. Para cada uma, responda quem autorizou, em que data, com que escopo e qual credencial está por trás. Escopo herdado de uma autorização feita em 2023 continua valendo hoje.
3. Ative restrição de IP em toda aplicação conectada cujo fornecedor publique faixa de origem. Comece pelas que leem dado de cliente.
4. Reduza escopo para o mínimo que a função exige. Se o agente captura lead, ele não precisa ler chamado de suporte.

Neste trimestre

1. Troque credencial permanente por credencial de curta duração onde a plataforma permitir, e estabeleça rotação com data para o resto.
2. Trate campo de texto livre voltado ao cliente como superfície de vazamento. Detecte segredo na entrada e expurgue o histórico.
3. Crie alerta para exportação em massa e para consulta de metadado de esquema originada em conta de integração. O padrão do atacante foi enumerar objeto, ler esquema, contar registro e só então exportar. Os três primeiros passos são baratos de detectar e acontecem dias antes do roubo.
4. Descubra onde ficam os logs de acesso de cada integração. Se o registro de quem usou o token está do lado do fornecedor e você não recebe cópia, você não tem como investigar.

No contrato

1. Exija notificação com prazo. A Salesloft revogou os tokens de todos os clientes em 20 de agosto e a Cloudflare foi notificada em 23. O intervalo entre a ação do fornecedor e o aviso ao cliente é um número que pertence ao contrato.
2. Exija entrega de indicadores de comprometimento e de linha do tempo, não apenas a comunicação de que houve incidente.
3. Peça a lista de IPs de origem e a documentação de escopo mínimo antes de autorizar, não depois.

// 12

Divergências em relação ao que circula

seis correções, cada uma com a fonte que a sustenta

O que eu não verifiquei

Quatro coisas que aparecem associadas a este caso e que eu deixo declaradas como não confirmadas em fonte primária.

• A nacionalidade do ator. A AppOmni descreve o UNC6395 como ator avaliado como chinês. O GTIG não atribui nacionalidade em nenhum momento do advisory. Fico com o GTIG.
• A fase de extorsão posterior e o surgimento de um site de vazamento associado a este conjunto de dados. Há relatos, não fui à fonte.
• Se alguma das credenciais roubadas foi usada em ataque subsequente. A Cloudflare afirma não ter identificado atividade suspeita nos 104 tokens. Sobre as demais vítimas, não há dado público consolidado.
• A divergência interna nas datas da contratação da Mandiant. O resumo final da investigação diz 26 de agosto de 2025. A atualização de 6 de setembro, no mesmo portal, diz 28 de agosto. Registro a inconsistência em vez de escolher uma.

// 13

O que isso exigiria operacionalmente

a partir daqui eu falo do que a gente faz na Jump

Quatro perguntas ficaram no caminho deste documento, e nenhuma delas é sobre o Drift.

1. Quantas credenciais de longa duração existem hoje na sua empresa, quem emitiu cada uma, e em que data.
2. Quantas chaves e senhas estão coladas dentro dos seus chamados de suporte neste momento.
3. Em quantos dias você saberia que um fornecedor seu foi comprometido, e por qual caminho.
4. Quantas das suas integrações que leem dado de cliente têm restrição de IP ativa.

Se você respondeu as quatro sem precisar consultar ninguém, pule esta seção. Ela não vai te acrescentar nada.

Das quatro, a gente trata de três. A segunda, a das chaves coladas dentro de chamado, depende de detecção de segredo no texto, que vive no produto de DLP de quem opera. Eu prefiro dizer isso agora a deixar você descobrir no fim.

Se não respondeu, é disso que a gente trata na Jump. Daqui em diante eu falo do nosso produto, separando o que existe hoje do que está no plano, porque misturar as duas coisas é o erro que este texto inteiro critica.

Todo controle que teria segurado este ataque já existia. Salesforce, GitHub e AWS ofereciam os três. O que falta numa empresa é alguém capaz de dizer, antes do incidente, quais credenciais existem, para que serviram quando foram criadas e o que elas podem fazer hoje.

O que o RADAR·AI faz hoje

responde 01 Descoberta multi-source com trinta conectores cobrindo código, nuvem, identidade, bancos, plataformas de dados, provedores de IA, bancos vetoriais, registries e Kubernetes. A cobertura de cada execução fica persistida, então o que não foi lido é registrado como não lido. Em agosto de 2025, a diferença entre não encontramos nada e não conseguimos olhar foi a diferença entre estar seguro e achar que estava.

responde 01 Inventário com dono. Uma linha por ativo de IA, com responsável, risco e status. Ativo sem dono é crítico por definição. É a resposta à pergunta de quem autorizou e quando.

responde 01 Conectores de identidade, que é onde vive a identidade não humana na maioria das empresas: Okta, AWS IAM e Azure AD. E conectores de plataforma de código, com o GitHub no nível de maturidade mais alto, validado contra ambiente real. O primeiro degrau da cadeia do Drift foi uma conta de GitHub.

responde 04 Guia de escopo mínimo consolidado para 26 conectores enterprise, com tipo de credencial, permissão necessária e permissão proibida. A gente aplica isso ao acesso que a própria plataforma pede, que é a única forma honesta de recomendar least privilege a um cliente.

O que está no plano, declarado como plano

Três itens do roadmap respondem diretamente ao que este caso expõe, e eu nomeio pelo nome que eles têm no plano de produto.

O limite, dito em voz alta

// 14

Fontes primárias

todas lidas diretamente; resumo de terceiro não entrou neste texto

• Google Threat Intelligence Group e Mandiant · Widespread Data Theft Targets Salesforce Instances via Salesloft Drift · 26.08.2025, atualizado em 28.08.2025
  cloud.google.com
  Janela de 8 a 18 de agosto, atribuição ao UNC6395, objetivo de colheita de credencial, consultas executadas, indicadores de comprometimento, recomendações, e a declaração de que o Google não foi cliente do Drift.
• Salesloft Trust Center · sequência de avisos e investigação da Mandiant · 20.08.2025 a 30.09.2025
  trust.salesloft.com
  Aviso inicial, sequência de desativação e restauração, FAQ de parceiros de integração, causa raiz e resumo final da investigação.
• Cloudflare · The impact of the Salesloft Drift breach on Cloudflare and our customers · 02.09.2025
  blog.cloudflare.com
  Linha do tempo minuto a minuto, os 104 tokens, o escopo exato do que foi acessado, as recomendações e os indicadores.
• FINRA · Cybersecurity Alert: Salesloft Drift AI Supply Chain Attack
  finra.org
  O número de mais de setecentas organizações e a equivalência entre UNC6395 e GRUB1.