Entre 12 e 17 de agosto de 2025, a Cloudflare, gigante de segurança cibernética com sede em San Francisco, viu sua instância da Salesforce ser invadida por meio de credenciais roubadas de um chatbot de IA da Salesloft Drift. O ataque, conduzido pelo grupo UNC6395 — vinculado ao ShinyHunters — não foi um golpe direto, mas uma invasão por cadeia de suprimentos: um dos parceiros de suporte da Cloudflare se tornou a porta dos fundos. A descoberta veio apenas em 23 de agosto, mas o dano já estava feito: centenas de organizações globais foram afetadas, e dados sensíveis de clientes foram expostos — não nos servidores internos, mas nas caixas de suporte da Salesforce, onde clientes, em boa-fé, compartilharam senhas, tokens e chaves de acesso.
O que aconteceu, passo a passo?
No dia 9 de agosto, às 11:51 UTC, os invasores começaram a investigar o ambiente da Cloudflare. Em 12 de agosto, às 22:14 UTC, usaram um token OAuth roubado da integração entre o Drift e a Salesforce — originado do IP 44.215.215.108.109 — para entrar no sistema. Não precisaram de phishing, nem de senhas fracas. Eles exploraram uma falha de confiança: a integração automática entre ferramentas de suporte e CRM. A partir daí, começaram a mapear os objetos de suporte da Salesforce, usando o endpoint /sobjects/Case/describe/ para entender a estrutura dos dados. Em seguida, executaram uma consulta massiva, colhendo centenas de milhares de registros de casos de suporte.
Os dados roubados incluíam nome da empresa, e-mail, telefone, domínio e país — tudo padrão. Mas o perigo real estava nas conversas de suporte: trechos de chat onde clientes, tentando resolver problemas, colavam chaves da AWS, tokens do Snowflake, até credenciais de API. A Cloudflare insiste que nunca pede essas informações — mas os clientes, por desatenção ou pressa, ainda assim as enviavam. Foram 104 tokens de API comprometidos. E o pior? Nenhum uso malicioso foi detectado ainda. Mas isso não significa que não vai acontecer.
Outras vítimas e o padrão se repete
A Cloudflare não estava sozinha. No mesmo dia, a Proofpoint, de Sunnyvale, confirmou que seu ambiente da Salesforce também foi invadido pelo mesmo método. Em seguida, vieram os nomes pesados: Palo Alto Networks, Zscaler, PagerDuty e Tanium. Todos tinham o mesmo ponto fraco: o Drift da Salesloft. A própria Salesloft admitiu, em comunicado, que o objetivo principal dos invasores era roubar credenciais de nuvem — especialmente chaves de acesso da AWS e do Snowflake, ferramentas críticas para empresas de tecnologia.
Isso não é isolado. Em junho de 2025, o grupo ShinyHunters já havia invadido o Salesforce do Google por meio de vishing — ligações falsas disfarçadas de suporte técnico. Agora, a tática evoluiu: em vez de enganar pessoas, eles enganam sistemas. Eles não precisam de senhas fortes. Precisam apenas de uma integração mal configurada, um token esquecido, uma permissão exagerada.
A resposta da Cloudflare: mais do que corrigir, reinventar
Quando descobriram o ataque, os executivos da Cloudflare não hesitaram. Desativaram imediatamente a integração com o Drift. Rotacionaram todos os 104 tokens comprometidos — mesmo sem evidência de uso. Desconectaram todas as integrações de terceiros com a Salesforce. E, o mais importante, passaram a exigir autenticação de dois fatores obrigatória para qualquer acesso externo. Em um blog publicado em 2 de setembro, admitiram: “Somos responsáveis pelas ferramentas que usamos para apoiar nosso negócio. Por isso, nos desculpamos sinceramente.”
Essa humildade é rara. Muitas empresas culpam o parceiro. A Cloudflare assumiu a culpa. E isso é o que faz a diferença. Porque o problema não é o Drift. O problema é que empresas confiam demais em integrações automáticas — e esquecem que cada conexão é uma porta.
Por que isso importa para você?
Se sua empresa usa Salesforce com qualquer chatbot, assistente de suporte ou ferramenta de terceiros, você está em risco. Não porque o software é ruim — mas porque a confiança cega é a maior vulnerabilidade. Especialistas da Seqrite apontam que as técnicas usadas por UNC6395 se sobrepõem às de outro grupo, o UNC6040, que já atacou empresas por vishing. Ou seja: a mesma estratégia, apenas com uma nova entrada. Ainda em agosto, o INCIBE-CERT alertou que pequenas e médias empresas estavam sendo alvo de ataques semelhantes no Brasil e na Europa. O padrão é claro: invadir por dentro, usando o que a empresa já acredita ser seguro.
A Cloudflare não perdeu seus servidores. Não teve ransomware. Mas perdeu a confiança — e isso é mais caro. Clientes que compartilharam chaves de API em chats de suporte agora precisam trocar tudo. E não é só uma senha. É uma cultura de segurança que precisa mudar.
O que vem a seguir?
Em outubro, a Salesforce deve lançar novas restrições para integrações OAuth de terceiros, exigindo revisão manual e limites de permissão mais rígidos. A própria Salesloft anunciou que está revisando todos os seus conectores com clientes corporativos. Mas isso não basta. As empresas precisam de auditorias contínuas de integrações — não apenas quando algo dá errado. E precisam treinar suas equipes de suporte: nunca compartilhar credenciais em chats, mesmo que o sistema pareça seguro.
Este ataque não foi um acidente. Foi um sinal. Um aviso de que a segurança do futuro não está nos firewalls, mas nas conexões que deixamos abertas — e esquecidas.
Frequently Asked Questions
Como eu sei se minha empresa foi afetada por esse ataque?
Se sua empresa usava a Cloudflare, Proofpoint, Palo Alto Networks, Zscaler, PagerDuty ou Tanium e compartilhou dados de suporte via chatbot entre 12 e 17 de agosto de 2025, há risco. A Cloudflare notificou clientes diretamente, mas outras empresas ainda estão investigando. Revise seus registros de suporte: se já enviou tokens, senhas ou chaves de API em conversas com suporte técnico, troque imediatamente. Não espere um e-mail.
O Drift da Salesloft é inseguro?
Não — o problema não é o chatbot em si, mas como ele foi configurado. Muitas empresas deram permissões excessivas a integrações de terceiros, sem monitoramento. O Drift funciona bem quando usado com restrições rigorosas. O erro foi de quem o conectou, não de quem o fez. A Salesloft já está corrigindo isso, mas a responsabilidade final é da empresa que integra.
Quais dados foram realmente expostos?
Apenas informações contidas nos casos de suporte da Salesforce: nome da empresa, e-mail, telefone, domínio e país. Mas o perigo real está nos trechos de texto das conversas — onde clientes, por descuido, colaram chaves de acesso da AWS, tokens do Snowflake e até senhas de bancos de dados. Esses dados não são armazenados pela Cloudflare, mas foram expostos porque foram enviados pelos próprios clientes.
Por que demorou tanto para a Cloudflare anunciar o ataque?
Porque os invasores não deixaram rastros claros. Eles não mexeram em servidores internos, não instalaram malware. Só acessaram dados de suporte — algo que parece inofensivo. A Cloudflare só descobriu o ataque em 23 de agosto, após alertas externos. Foi preciso uma investigação forense minuciosa para encontrar o ponto de entrada. Isso mostra como ataques sutis são mais difíceis de detectar que os tradicionais.
Como evitar que isso aconteça com minha empresa?
Revise todas as integrações de terceiros com sua Salesforce. Exija autenticação de dois fatores, limite permissões de acesso e monitore logs de API. Treine sua equipe de suporte: nunca compartilhe credenciais em chats, mesmo que pareçam seguros. E exija que parceiros façam o mesmo. A segurança não é um produto — é um hábito.
Esse ataque é parte de uma tendência maior?
Sim. Em 2025, ataques a integrações de nuvem cresceram 300% segundo a Kaspersky. Atacantes estão deixando de invadir servidores e começando a invadir confiança. Se você confia em um parceiro, eles confiam em você. Eles não precisam de força bruta — só de uma conexão mal configurada. Esse é o novo front da cibersegurança.
Suellen Cook
novembro 20, 2025 AT 00:44Essa história é um alerta brutal: não adianta ter firewalls impenetráveis se sua equipe ainda coloca senha em um chat de suporte. A falha não é técnica, é humana. E ninguém quer admitir isso.
Alexsandra Andrade
novembro 20, 2025 AT 19:03Exatamente. E olha que eu trabalho em suporte há 12 anos - já vi gente colar chave da AWS num ticket porque ‘o sistema era seguro’. Ninguém ensina isso. Ninguém treina. E depois fica tudo na culpa do ‘terceiro’.
Luana Karen
novembro 21, 2025 AT 11:39Isso me lembra uma frase que ouvi de um mentor: ‘A segurança não é um produto, é um hábito’. E hábitos se constroem com repetição, não com políticas. Se o seu time não entende que um chat não é um vault, você já perdeu antes de começar. A Cloudflare foi corajosa em admitir - e isso é raro. Muitas empresas ainda jogam a culpa no Drift, como se ele tivesse entrado sozinho no sistema.
Na verdade, o Drift só fez o que foi autorizado. O erro foi não limitar permissões, não monitorar logs, não treinar. E isso é cultural. Não técnico. E mudar cultura leva tempo. Muito tempo.
Eu já vi empresas que obrigam dois fatores até para acessar o café. Mas permitem que um analista de suporte cole um token do Snowflake em uma conversa com um bot. Onde está a lógica?
Se você quer segurança, comece treinando sua equipe como se fossem soldados. Não como se fossem assistentes de escritório. Porque, no fim, o ataque não foi ao sistema. Foi à confiança cega.
E aí, sua empresa já fez um treinamento real sobre isso nos últimos 6 meses? Ou só mandou um PDF de 20 páginas que ninguém leu?
Luiz Felipe Alves
novembro 22, 2025 AT 07:07Na verdade, o problema é mais profundo: a indústria de software criou uma ilusão de segurança. Acreditamos que se algo é ‘integrado’, então é seguro. Mas integração não é sinônimo de confiança. É sinônimo de exposição. E os atacantes sabem disso. Eles não precisam quebrar nada. Só precisam esperar alguém fazer o trabalho sujo por eles: colar credenciais num chat.
Isso é o que chamamos de ‘ataque por complacência’. E é o mais eficaz. Porque ninguém se protege de uma falha que nem sabe que existe. A Cloudflare foi vítima de uma cultura de ‘isso não vai acontecer com a gente’. E isso é o pior tipo de vulnerabilidade.
Se você tem integrações com Salesforce e chatbots, revise agora. Não espere um e-mail. Revise seus logs. Olhe os casos de suporte. Pergunte: alguém já colou algo que não deveria? Se sim, troque tudo. Não espere. Não confie. Não acredite em ‘sistema seguro’.
Essa não é uma questão de tecnologia. É uma questão de disciplina. E a maioria das empresas não tem.
Wagner Wagão
novembro 22, 2025 AT 16:24Quero só dizer: isso não é só da Cloudflare. É de todo mundo que usa CRM e acha que ‘o cliente sabe o que faz’. Mas o cliente não sabe. O cliente tá com pressa, cansado, tentando resolver um problema. E se o sistema permite colar uma chave AWS num chat, ele vai colar. Não é burrice. É design falho.
Se você é responsável por uma ferramenta de suporte, pare de pensar em UX como ‘fácil de usar’. Pense em UX como ‘difícil de errar’. Seja impossível colar credenciais. Bloqueie. Avisar não adianta. O ser humano é previsível. O sistema tem que ser inteligente o suficiente para proteger o ser humano de si mesmo.
Isso aqui não é culpa do Drift. É culpa de quem permitiu que o Drift tivesse acesso sem limites. E de quem não treinou ninguém. E de quem não fez auditoria. E de quem achou que ‘isso nunca acontece’.
Se sua empresa usa integrações, faça um audit agora. Não amanhã. Hoje. Porque o próximo ataque não vai esperar.
isaela matos
novembro 23, 2025 AT 11:07Mais um caso de empresa que se acha a dona da verdade e depois finge que foi vítima. Tudo isso é marketing de medo. Eles querem que a gente compre mais segurança… e não é isso que o mundo precisa.
Carla Kaluca
novembro 23, 2025 AT 11:08o drifft é o culpado mesmo, se eles nao tivesse a integraçao com salesforce isso nao tinha acontecido. e a cloudflare nao fez nada pra impedir, so ficou olhando. eu ja tinha avisado que isso ia acontecer. e agora? quem paga os prejuizos?
TATIANE FOLCHINI
novembro 24, 2025 AT 01:24Desculpa, mas eu não entendo como vocês podem confiar em um bot para lidar com dados sensíveis. Isso é irresponsável. E se o bot tivesse sido hackeado antes? Vocês nem saberiam. Acho que vocês deveriam ter feito isso antes de tudo isso acontecer. Será que vocês realmente se importam com seus clientes?
Thiago Silva
novembro 25, 2025 AT 17:30Essa história é uma piada. Eles perderam chaves de API porque alguém colou num chat? Sério? Isso é o que chamam de ‘segurança moderna’? Meu avô tinha um caderno com senhas e era mais seguro que essa galera. Acho que o futuro da cibersegurança é voltar ao papel e caneta. Ou melhor: desligar tudo e viver em uma cabana.
Enquanto isso, a Salesforce continua vendendo integrações como se fossem brinquedos. E as empresas continuam clicando em ‘aceitar’ sem ler nada. É como se a gente estivesse vivendo num filme de ficção científica, mas escrito por um adolescente de 14 anos.
Eu não confio mais em nada. Nada mesmo.
Nicoly Ferraro
novembro 27, 2025 AT 03:29Eu só quero dizer que isso me deixou com medo. Não por causa da tecnologia - mas por causa da gente. Porque no fundo, todos nós já fizemos isso. Colamos uma senha, um token, uma chave… só porque ‘era rápido’. E aí, quando acontece, a gente fica chocado. Mas não foi surpresa. Foi consequência.
Se você tem um time de suporte, pare agora. Pergunte: já teve alguém colando credencial no chat? Se sim, você já foi atacado. Só não sabe ainda.
Recomece. Treine. Crie regras que não dependem de memória. Crie sistemas que bloqueiam. E pare de achar que ‘a pessoa vai se lembrar’. Ela não vai. Ninguém vai.
Edilaine Diniz
novembro 28, 2025 AT 05:03Isso é tão real… eu trabalho em uma empresa pequena e já tive um cliente mandando senha de banco no chat. Eu não sabia o que fazer. Só falei: ‘não envie isso aqui’. Mas não tinha política pra isso. Acho que todos precisam de um guia simples, tipo: ‘nunca, nunca, nunca envie credenciais aqui’. Um adesivo na tela, um pop-up, algo. Ninguém lê termos de uso. Mas se aparecer um alerta vermelho, aí sim, todo mundo olha.
Stephane Paula Sousa
novembro 29, 2025 AT 11:20o ataque nao foi ao sistema foi a confianca e a preguica humana. tudo que precisava era um bot que nao aceitasse texto com palavras como aws ou token. mas ninguem quer fazer isso porque custa. e ai o mundo vira um filme de terror com senha em chat
Francielly Lima
novembro 30, 2025 AT 12:55É lamentável que, em pleno século XXI, ainda se permita que credenciais de acesso a sistemas críticos sejam tratadas como se fossem mensagens de WhatsApp. A Cloudflare demonstrou, em sua resposta, um nível de maturidade institucional raro - mas isso não deve servir de elogio, e sim de vergonha coletiva. O fato de que organizações de tecnologia ainda operem com integrações de terceiros sem controle de escopo, sem auditoria contínua e sem treinamento formal de seus colaboradores revela uma falha sistêmica, não técnica. A segurança não é um recurso adicional; é o alicerce. E, quando esse alicerce é construído com areia, a tempestade não é uma surpresa - é uma consequência lógica.
Os invasores não utilizaram exploits sofisticados. Não precisaram de zero-days. Eles exploraram a mais antiga e mais eficaz vulnerabilidade da humanidade: a confiança desmedida. A confiança de que o sistema é seguro. A confiança de que o cliente sabe o que faz. A confiança de que ‘não vai acontecer com a gente’. Essa é a falha. Não o Drift. Não o Salesforce. A mentalidade.
Se sua empresa ainda permite que agentes de suporte interajam com clientes por canais não auditáveis, você não tem um problema de segurança. Você tem um problema de liderança. E, se você não está agindo agora, não está protegendo seus clientes. Está apenas esperando o próximo título de noticia.
Ana Carolina Campos Teixeira
dezembro 2, 2025 AT 09:22Este caso demonstra a falência da cultura de segurança corporativa. A Cloudflare não foi vítima - foi negligente. A integração com o Drift foi autorizada sem revisão de segurança. Os tokens não foram rotacionados por meses. A equipe de suporte não foi treinada. E agora, com um blog de desculpas, tentam se apresentar como heróis. Não são. São apenas os últimos de uma longa fila de empresas que acreditaram que ‘tecnologia resolve tudo’.
Se a segurança fosse prioridade, não haveria integrações sem aprovação manual. Não haveria acesso de terceiros sem MFA obrigatório. Não haveria suporte sem treinamento contínuo. Mas não há. Porque é mais barato ignorar. E mais lucrativo esperar que o cliente pague a conta depois.
Este não é um ataque. É um retrato da indústria.
Joseph Fraschetti
dezembro 2, 2025 AT 18:25Então, se eu entendi direito… o ataque aconteceu porque alguém colou uma senha num chat? Tipo, tipo mesmo? Tipo, como se fosse um WhatsApp? Isso é real? Sério? Porque eu tô aqui pensando: se isso aconteceu com a Cloudflare, então tá tudo errado. Não é o bot, não é o sistema, não é o hacker. É a gente. A gente acha que é seguro, mas não é. A gente acha que o cliente sabe, mas não sabe. A gente acha que o sistema vai proteger, mas não protege. E aí, quando acontece, todo mundo fala ‘ah, mas a gente não sabia’. Mas a gente sabia. Só não quis ver.
Se eu tivesse um bot e alguém colasse uma chave AWS, eu bloqueava. Eu mandava um alerta. Eu não deixava passar. Mas ninguém fez isso. Porque é mais fácil deixar. E agora? Agora todo mundo tem que trocar tudo. Porque um erro de uma pessoa afetou centenas. Isso é o que acontece quando a gente confia demais. E a gente confia demais porque é mais fácil.
Eu acho que a gente precisa parar de achar que segurança é coisa de técnico. É coisa de todo mundo. E se a gente não mudar isso, o próximo ataque vai ser pior. Muito pior.