{"id":24864,"date":"2026-04-08T09:00:51","date_gmt":"2026-04-08T12:00:51","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=24864"},"modified":"2026-04-06T13:43:01","modified_gmt":"2026-04-06T16:43:01","slug":"supply-chain-attacks-in-2025","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/supply-chain-attacks-in-2025\/24864\/","title":{"rendered":"Ataques \u00e0 cadeia de suprimentos que marcaram 2025"},"content":{"rendered":"<p>Os ataques a cadeias de suprimentos t\u00eam sido uma das categorias mais perigosas de incidentes de ciberseguran\u00e7a <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2024\/52965\/\" target=\"_blank\" rel=\"noopener nofollow\">h\u00e1 anos<\/a>. Se o ano de 2025 nos ensinou alguma coisa, \u00e9 que os cibercriminosos est\u00e3o aumentando sua capacidade de ataque. Nesta an\u00e1lise detalhada, veremos ataques a cadeias de suprimentos realizados em 2025 que, embora n\u00e3o sejam os que causaram maiores preju\u00edzos financeiros, certamente foram os mais incomuns e chamaram a aten\u00e7\u00e3o do setor.<\/p>\n<h2>Janeiro de 2025: um RAT encontrado no reposit\u00f3rio do GitHub do DogWifTools<\/h2>\n<p>Como um \u201caquecimento\u201d ap\u00f3s o fim de ano, os cibercriminosos <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/solana-pumpfun-tool-dogwiftool-compromised-to-drain-wallets\/\" target=\"_blank\" rel=\"noopener nofollow\">realizaram in\u00fameros ataques de backdoor<\/a> a v\u00e1rias vers\u00f5es do DogWifTools. Trata-se de um utilit\u00e1rio projetado para lan\u00e7ar e promover vigorosamente <a href=\"https:\/\/pt.wikipedia.org\/wiki\/Memecoin\" target=\"_blank\" rel=\"noopener nofollow\">moedas de meme<\/a> baseadas em Solana no Pump.fun. Depois de comprometer o reposit\u00f3rio privado do GitHub para o DogWifTools, os invasores esperaram os desenvolvedores carregarem uma nova vers\u00e3o do utilit\u00e1rio, injetaram um RAT nela e trocaram o programa leg\u00edtimo por uma vers\u00e3o maliciosa apenas algumas horas depois. De acordo com os desenvolvedores, os agentes de amea\u00e7as instalaram com \u00eaxito as vers\u00f5es 1.6.3 a 1.6.6 do DogWifTools para Windows.<\/p>\n<p>O golpe final foi dado no fim de janeiro. Depois de usar o RAT para coletar uma grande quantidade de dados dos dispositivos infectados, os invasores esvaziaram as carteiras de criptomoedas das v\u00edtimas. As v\u00edtimas estimaram o total de mais de USD\u00a010\u00a0milh\u00f5es em criptomoedas, mas os invasores <a href=\"https:\/\/x.com\/JizzyGroup\/status\/1884395542072959208\" target=\"_blank\" rel=\"noopener nofollow\">contestaram<\/a> esse n\u00famero, embora n\u00e3o tenham revelado exatamente o valor total roubado.<\/p>\n<h2>Fevereiro de 2025: roubo de USD\u00a01,5\u00a0bilh\u00e3o do Bybit<\/h2>\n<p>Se janeiro foi s\u00f3 o aquecimento, o m\u00eas de fevereiro foi um colapso total. A <a href=\"https:\/\/www.kaspersky.com.br\/blog\/bybit-hack-lessons-how-to-do-self-custody-properly\/23601\/\" target=\"_blank\" rel=\"noopener\">invas\u00e3o da plataforma de c\u00e2mbio de criptomoedas Bybit<\/a> superou completamente os incidentes anteriores, tornando-se o maior roubo de criptomoedas da hist\u00f3ria. Os invasores conseguiram comprometer o software Safe{Wallet}, a solu\u00e7\u00e3o de armazenamento a frio de m\u00faltiplas assinaturas na qual a empresa confiava para gerenciar os seus ativos.<\/p>\n<p>Os funcion\u00e1rios da Bybit pensaram que estavam assinando uma transa\u00e7\u00e3o de rotina. Na realidade, eles estavam autorizando um contrato inteligente malicioso. Uma vez executado, ele esvaziou os fundos de uma carteira fria principal e os distribuiu em v\u00e1rias centenas de endere\u00e7os controlados pelo invasor. A transfer\u00eancia final ultrapassou 400 mil\u00a0ETH\/stETH, com um impressionante valor total de aproximadamente\u2026 USD\u00a01,5\u00a0bilh\u00e3o!<\/p>\n<h2>Mar\u00e7o de 2025: Coinbase \u00e9 alvo de comprometimento em cascata do GitHub Actions<\/h2>\n<p>O ano de 2025 seguiu com um ataque sofisticado que usou o <a href=\"https:\/\/www.kaspersky.com\/blog\/malicious-github-action-changed-files\/53179\/\" target=\"_blank\" rel=\"noopener nofollow\">comprometimento de v\u00e1rios GitHub Actions<\/a>, os padr\u00f5es de fluxo de trabalho usados para automatizar tarefas de DevOps padr\u00e3o, como seu principal mecanismo de entrega. Tudo come\u00e7ou com o roubo de um token de acesso pessoal pertencente a um mantenedor da ferramenta de an\u00e1lise SpotBugs. Usando esse ponto de apoio, os invasores publicaram um processo malicioso e conseguiram sequestrar um token de um mantenedor do fluxo de trabalho reviewdog\/action-setup, que tamb\u00e9m estava envolvido no projeto.<\/p>\n<p>A partir da\u00ed, eles comprometeram uma depend\u00eancia, o fluxo de trabalho tj-actions\/changed-files, modificando-o para executar um script Python malicioso. Esse script foi projetado para procurar segredos de alto valor, como chaves da AWS, do Azure e do Google Cloud, tokens do GitHub e do NPM, credenciais de banco de dados e chaves privadas do RSA. Por incr\u00edvel que pare\u00e7a, o script gravou tudo o que encontrou diretamente nos registros de compila\u00e7\u00e3o acess\u00edveis ao p\u00fablico em geral. Isso significa que os dados vazados n\u00e3o estavam dispon\u00edveis apenas para os invasores, mas tamb\u00e9m para qualquer pessoa experiente o suficiente para acess\u00e1-los.<\/p>\n<p>O alvo original dessa opera\u00e7\u00e3o era um reposit\u00f3rio pertencente \u00e0 plataforma de c\u00e2mbio de criptomoedas Coinbase. Felizmente, os desenvolvedores detectaram a amea\u00e7a a tempo e impediram o comprometimento. Ao que tudo indica, depois de perceberem que estavam prestes a perder o controle do pipeline tj-actions\/changed-files, os invasores adotaram uma abordagem indiscriminada. Isso colocou 23 mil reposit\u00f3rios em risco de vazamento de segredos. No final, <a href=\"https:\/\/thehackernews.com\/2025\/03\/github-supply-chain-breach-coinbase.html\" target=\"_blank\" rel=\"noopener nofollow\">v\u00e1rias centenas<\/a> desses reposit\u00f3rios realmente tiveram suas credenciais confidenciais expostas ao p\u00fablico.<\/p>\n<h2>Abril de 2025: um backdoor em 21 extens\u00f5es do Magento<\/h2>\n<p>Em abril, uma infec\u00e7\u00e3o foi <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/magento-supply-chain-attack-compromises-hundreds-of-e-stores\/\" target=\"_blank\" rel=\"noopener nofollow\">descoberta<\/a> em um amplo conjunto de extens\u00f5es do Magento, uma das plataformas mais populares para a cria\u00e7\u00e3o de lojas on-line. O backdoor foi incorporado em 21 m\u00f3dulos desenvolvidos por tr\u00eas fornecedores: Tigren, Meetanshi e MGS. As extens\u00f5es faziam parte da infraestrutura de v\u00e1rias centenas de empresas de com\u00e9rcio eletr\u00f4nico, incluindo pelo menos uma corpora\u00e7\u00e3o multinacional.<\/p>\n<p>De acordo com os pesquisadores que o descobriram, o backdoor na verdade foi implantado em 2019. Em abril de 2025, os invasores o acionaram para comprometer sites e fazer o upload de web shells. Isso foi feito por meio de uma fun\u00e7\u00e3o incorporada nas extens\u00f5es que executava um c\u00f3digo arbitr\u00e1rio extra\u00eddo de um arquivo de licen\u00e7a.<\/p>\n<p>Por ironia, os m\u00f3dulos infectados inclu\u00edam o MGS GDPR e o Meetanshi CookieNotice. Como os nomes sugerem, essas extens\u00f5es foram projetadas para ajudar os sites a cumprir os regulamentos de privacidade e processamento de dados dos usu\u00e1rios. Por fim, em vez de garantir a privacidade, o uso deles provavelmente levou ao roubo de dados e ativos financeiros do usu\u00e1rio por meio de <a href=\"https:\/\/www.kaspersky.com.br\/blog\/illicit-code-on-legitimate-sites\/21485\/\" target=\"_blank\" rel=\"noopener\">skimming digital<\/a>.<\/p>\n<h2>Maio de 2025: ransomware distribu\u00eddo por meio de um MSP comprometido<\/h2>\n<p>Em maio, os agentes de ransomware da gangue DragonForce <a href=\"https:\/\/www.thereregister.com\/2025\/05\/28\/dragonforce_ransomware_gang_sets_fire\/\" target=\"_blank\" rel=\"noopener nofollow\">obtiveram acesso<\/a> \u00e0 infraestrutura de um provedor de servi\u00e7os gerenciados (MSP) n\u00e3o identificado e a usaram para distribuir um ransomware e roubar dados das organiza\u00e7\u00f5es clientes do MSP.<\/p>\n<p>Ao que tudo indica, os invasores exploraram v\u00e1rias vulnerabilidades (incluindo uma falha cr\u00edtica) no SimpleHelp, a ferramenta de monitoramento e gerenciamento remoto usada pelo MSP. Essas vulnerabilidades foram descobertas em 2024 e divulgadas publicamente e corrigidas <a href=\"https:\/\/thehackernews.com\/2025\/01\/critical-simplehelp-flaws-allow-file.html\" target=\"_blank\" rel=\"noopener nofollow\">em janeiro de 2025<\/a>. Infelizmente, ficou claro que o MSP optou por n\u00e3o acelerar o processo de atualiza\u00e7\u00e3o, um atraso que a gangue do ransomware ficou mais do que feliz em explorar.<\/p>\n<h2>Junho de 2025: um backdoor em mais de uma d\u00fazia de pacotes npm populares<\/h2>\n<p>No in\u00edcio do ver\u00e3o, os invasores invadiram a conta de um dos mantenedores da biblioteca Glustack e usaram um token de acesso roubado para <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/supply-chain-attack-hits-gluestack-npm-packages-with-960k-weekly-downloads\/\" target=\"_blank\" rel=\"noopener nofollow\">injetar backdoors em 17 pacotes npm<\/a>. O mais popular desses pacotes, @react-native-aria\/interactions, ostentava 125 mil downloads semanais, enquanto todos os pacotes comprometidos combinados totalizaram mais de um milh\u00e3o.<\/p>\n<p>O que \u00e9 particularmente interessante nesse caso s\u00e3o as etapas que os desenvolvedores do Glustack <a href=\"https:\/\/github.com\/gluestack\/gluestack-ui\/issues\/2894#issuecomment-2955003750\" target=\"_blank\" rel=\"noopener nofollow\">seguiram ap\u00f3s o incidente<\/a>: primeiro, eles restringiram o acesso ao reposit\u00f3rio GitHub para contribuidores secund\u00e1rios; segundo, eles ativaram a autentica\u00e7\u00e3o de dois fatores (2FA) para publicar novas vers\u00f5es; e terceiro, eles prometeram implementar pr\u00e1ticas de desenvolvimento seguras, como fluxo de trabalho baseado em pull requests, revis\u00f5es sistem\u00e1ticas de c\u00f3digo, registro de auditorias e assim por diante. Em outras palavras, antes do incidente, um projeto com centenas de milhares de downloads semanais n\u00e3o tinha tais medidas em vigor.<\/p>\n<h2>Julho de 2025: pacotes npm populares infectados por meio de um ataque de phishing<\/h2>\n<p>Em julho, os <a href=\"https:\/\/www.thereregister.com\/2025\/07\/24\/not_pretty_not_windowsonly_npm\/\" target=\"_blank\" rel=\"noopener nofollow\">pacotes npm foram novamente<\/a> as estrelas do show, incluindo o pacote amplamente usado chamado \u201cis\u201d, que possui 2,7 milh\u00f5es de downloads semanais. Essa biblioteca de utilit\u00e1rios JavaScript fornece uma ampla variedade de fun\u00e7\u00f5es de verifica\u00e7\u00e3o de tipo e valida\u00e7\u00e3o de valor. Para realizar um ataque de phishing contra um dos propriet\u00e1rios do projeto, os invasores utilizaram com \u00eaxito um truque antigo: o <a href=\"https:\/\/encyclopedia.kaspersky.com\/glossary\/typosquatting\/\" target=\"_blank\" rel=\"noopener\">typosquatting<\/a> (usar o dom\u00ednio npnjs.com em vez de npmjs.com) e um clone do site oficial do npm.<\/p>\n<p>Em seguida, eles usaram a conta comprometida para publicar v\u00e1rias das suas pr\u00f3prias vers\u00f5es do pacote com um backdoor incorporado. A infec\u00e7\u00e3o passou desapercebida por seis horas: tempo suficiente para um grande n\u00famero de desenvolvedores baixarem os pacotes npm maliciosos.<\/p>\n<p>A mesma t\u00e1tica de phishing foi usada contra outros desenvolvedores. Os invasores aproveitaram v\u00e1rias contas de desenvolvedores comprometidas para distribuir <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/popular-npm-linter-packages-hijacked-via-phishing-to-drop-malware\/\" target=\"_blank\" rel=\"noopener nofollow\">diferentes variantes de sua carga maliciosa<\/a>. H\u00e1 tamb\u00e9m uma forte suspeita de que eles podem ter guardado parte dessa carga para ataques futuros.<\/p>\n<h2>Agosto de 2025: o ataque s1ngularity e o vazamento de centenas de segredos dos desenvolvedores<\/h2>\n<p>No final de agosto, <a href=\"https:\/\/www.kaspersky.com\/blog\/nx-build-s1ngularity-supply-chain-attack\/54223\/\" target=\"_blank\" rel=\"noopener nofollow\">um incidente apelidado de \u201cs1ngularity\u201d<\/a> continuou a tend\u00eancia de atingir desenvolvedores de JavaScript. Os invasores comprometeram o Nx, um sistema de compila\u00e7\u00e3o popular e uma ferramenta de otimiza\u00e7\u00e3o de pipeline de CI\/CD. O c\u00f3digo malicioso injetado nos pacotes pesquisou diversos sistemas dos desenvolvedores infectados, acessando uma grande quantidade de dados confidenciais, como chaves de carteiras de criptomoedas, tokens do npm e do GitHub, chaves SSH, chaves de API e muito mais.<\/p>\n<p>Curiosamente, os invasores usaram ferramentas de IA instaladas localmente, como Claude Code, Gemini CLI e Amazon Q, para detectar os segredos nas m\u00e1quinas das v\u00edtimas. Tudo o que eles encontraram foi publicado nos reposit\u00f3rios p\u00fablicos do GitHub criados em nome das v\u00edtimas, usando os t\u00edtulos \u201cs1ngularity-repository\u201d, \u201cs1ngularity-repository-0\u201d e \u201cs1ngularity-repository-1\u201d. Como voc\u00ea deve ter adivinhado, \u00e9 da\u00ed que vem o nome do ataque.<\/p>\n<p>Consequentemente, os dados privados de centenas de desenvolvedores acabaram ficando \u00e0 vista de todos e poderiam ser acessados n\u00e3o apenas pelos invasores, mas por absolutamente qualquer pessoa com uma conex\u00e3o com a Internet.<\/p>\n<h2>Setembro de 2025: um stealer de criptomoedas ataca pacotes npm que t\u00eam 2,6 bilh\u00f5es de downloads semanais<\/h2>\n<p>A tend\u00eancia de comprometimentos de pacotes npm seguiu at\u00e9 setembro. Ap\u00f3s uma nova campanha de phishing direcionada a desenvolvedores de JavaScript, os invasores conseguiram injetar c\u00f3digo malicioso em algumas dezenas de projetos de alto n\u00edvel. Alguns deles, especificamente \u201cchalk\u201d e \u201cdebug\u201d, tiveram <em>centenas de milh\u00f5es<\/em> de downloads semanais; coletivamente, os pacotes infectados estavam acumulando <a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">mais de 2,6 bilh\u00f5es de downloads por semana<\/a> no momento da viola\u00e7\u00e3o, e eles se tornaram mais populares desde ent\u00e3o.<\/p>\n<p>A carga era um stealer de criptomoedas: um malware projetado para interceptar transa\u00e7\u00f5es de criptomoeda e redirecion\u00e1-las para as carteiras dos invasores. Felizmente, apesar de infectar com sucesso alguns dos projetos mais populares do mundo, os invasores acabaram falhando no est\u00e1gio final da opera\u00e7\u00e3o. No final, eles ficaram com <a href=\"https:\/\/www.thereregister.com\/2025\/09\/09\/npm_supply_chain_attack\/\" target=\"_blank\" rel=\"noopener nofollow\">m\u00edseros USD\u00a0925<\/a>.<\/p>\n<p>Apenas uma semana depois, outro grande incidente ocorreu: <a href=\"https:\/\/www.kaspersky.com\/blog\/tinycolor-shai-hulud-supply-chain-attack\/54315\/\" target=\"_blank\" rel=\"noopener nofollow\">a primeira onda do malware autopropag\u00e1vel Shai-Hulud<\/a>, que infectou cerca de 150 pacotes npm, incluindo projetos da CrowdStrike. No entanto, a segunda onda, que ocorreu v\u00e1rios meses depois, provou ser muito mais destrutiva. Vamos analisar o Great Worm em mais detalhes a seguir.<\/p>\n<h2>Outubro de 2025: o GlassWorm infecta o ecossistema do Visual Studio Code<\/h2>\n<p>Cerca de um m\u00eas ap\u00f3s o ataque do Shai-Hulud, <a href=\"https:\/\/thehackernews.com\/2025\/10\/self-spreading-glassworm-infects-vs.html\" target=\"_blank\" rel=\"noopener nofollow\">um malware autopropag\u00e1vel semelhante denominado GlassWorm<\/a> come\u00e7ou a infectar extens\u00f5es do Visual Studio Code no Open VSX Registry e no Microsoft Extension Marketplace. Os invasores estavam procurando contas do GitHub, Git, npm e Open VSX, bem como chaves de carteiras de criptomoedas.<\/p>\n<p>Os criadores do GlassWorm adotaram uma abordagem altamente criativa para sua infraestrutura de comando e controle: eles usaram uma carteira de criptomoedas no blockchain Solana como seu C2 principal, com o Google Agenda servindo como um canal de comunica\u00e7\u00e3o de backup.<\/p>\n<p>Al\u00e9m de esvaziar as carteiras de criptomoedas das v\u00edtimas e sequestrar suas contas para espalhar o worm ainda mais, os invasores tamb\u00e9m injetaram um RAT chamado Zombi nos dispositivos infectados, obtendo controle total sobre os sistemas comprometidos.<\/p>\n<h2>Novembro de 2025: a campanha IndonesianFoods e 150 mil pacotes de spam no npm<\/h2>\n<p>Em novembro, um novo inc\u00f4modo <a href=\"https:\/\/www.kaspersky.com\/blog\/indonesianfoods-npm-spam-campaign\/55453\/\" target=\"_blank\" rel=\"noopener nofollow\">emergiu<\/a> do reposit\u00f3rio do npm. Uma campanha maliciosa coordenada apelidada de IndonesianFoods fez os invasores inundarem o reposit\u00f3rio com dezenas de milhares de pacotes in\u00fateis.<\/p>\n<p>O objetivo principal era jogar com o sistema para inflar as m\u00e9tricas e os tokens de farm no tea.xyz, uma plataforma de blockchain projetada para recompensar os desenvolvedores de c\u00f3digo aberto. Para conseguir isso, os invasores constru\u00edram uma enorme rede de projetos interdependentes com nomes que fazem refer\u00eancia \u00e0 culin\u00e1ria indon\u00e9sia, como zul-<a href=\"https:\/\/en.wikipedia.org\/wiki\/Tapai\" target=\"_blank\" rel=\"noopener nofollow\">tapai<\/a>9-kyuki e andi-<a href=\"https:\/\/pt.wikipedia.org\/wiki\/Rendang\" target=\"_blank\" rel=\"noopener nofollow\">rendang<\/a>23-breki.<\/p>\n<p>Os criadores da campanha n\u00e3o se deram ao trabalho de invadir contas. Estritamente falando, os pacotes de spam nem sequer continham um cont\u00eainer malicioso, a menos que voc\u00ea considere um script projetado para gerar automaticamente novos cont\u00eaineres a cada sete segundos. No entanto, o incidente serviu como um lembrete de como a infraestrutura npm \u00e9 vulner\u00e1vel a campanhas de spam em larga escala.<\/p>\n<h2>Dezembro de 2025: Shai-Hulud 2.0 e o vazamento de 400 mil segredos de desenvolvedores<\/h2>\n<p>O destaque absoluto do ano, n\u00e3o apenas de ataques a cadeias de suprimentos, mas provavelmente para todo o campo de seguran\u00e7a cibern\u00e9tica, foi o malware autopropag\u00e1vel <a href=\"https:\/\/securelist.com\/shai-hulud-worm-infects-500-npm-packages-in-a-supply-chain-attack\/117547\/\" target=\"_blank\" rel=\"noopener\">Shai-Hulud<\/a> (tamb\u00e9m conhecido como Sha1-Hulud) contra desenvolvedores.<\/p>\n<p>Esse malware foi a evolu\u00e7\u00e3o l\u00f3gica do ataque s1ngularity mencionado anteriormente: ele tamb\u00e9m vasculhou os sistemas em busca de todos os tipos de segredos e os publicou em reposit\u00f3rios GitHub abertos. No entanto, o Shai-Hulud adicionou um mecanismo de autopropaga\u00e7\u00e3o \u00e0 linha de base: o worm infectou projetos controlados por desenvolvedores j\u00e1 comprometidos usando as credenciais roubadas.<\/p>\n<p>A primeira onda do Shai-Hulud ocorreu em setembro, infectando v\u00e1rias centenas de pacotes npm. No final do ano, a segunda onda chegou e foi batizada como <a href=\"https:\/\/securelist.com\/shai-hulud-2-0\/118214\/\" target=\"_blank\" rel=\"noopener\">Shai-Hulud 2.0<\/a>.<\/p>\n<p>Dessa vez, o worm foi atualizado com a funcionalidade de wiper. Se o malware n\u00e3o encontrasse tokens npm ou GitHub v\u00e1lidos em um sistema infectado, ele acionava uma carga destrutiva que apagava os arquivos do usu\u00e1rios.<\/p>\n<p><a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/shai-hulud-20-npm-malware-attack-exposed-up-to-400-000-dev-secrets\/\" target=\"_blank\" rel=\"noopener nofollow\">Aproximadamente 400 mil segredos<\/a> foram vazados no total como resultado do ataque. Vale a pena notar que, assim como no s1ngularity, todos os dados confidenciais acabaram publicados em reposit\u00f3rios p\u00fablicos, onde poderiam ser baixados n\u00e3o apenas pelos invasores, mas por qualquer outra pessoa. E \u00e9 altamente prov\u00e1vel que as consequ\u00eancias desse ataque ainda sejam sentidas por um longo tempo.<\/p>\n<p>Um dos primeiros casos confirmados de uma explora\u00e7\u00e3o usando segredos vazados pelo Shai-Hulud foi um roubo de criptomoeda visando v\u00e1rios milhares de usu\u00e1rios da Trust Wallet. Os invasores usaram esses segredos na v\u00e9spera de Natal para carregar uma vers\u00e3o maliciosa da extens\u00e3o Trust Wallet com um <a href=\"https:\/\/www.kaspersky.com.br\/blog\/what-is-a-crypto-wallet-drainer\/22224\/\" target=\"_blank\" rel=\"noopener\">drenador de criptomoedas<\/a> integrado para a Chrome Web Store. No final, eles conseguiram se safar com USD\u00a08,5\u00a0milh\u00f5es em criptomoedas.<\/p>\n<h2>Como se proteger contra ataques a cadeias de suprimentos<\/h2>\n<p>Ao elaborar <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2024\/52965\/\" target=\"_blank\" rel=\"noopener nofollow\">uma retrospectiva semelhante para 2024<\/a>, descobrimos que manter uma estrutura de \u201cum m\u00eas, uma amea\u00e7a\u201d \u00e9 bastante f\u00e1cil. Para 2025, no entanto, o caso foi muito mais grave. Houve tantos ataques maci\u00e7os a cadeias de suprimentos no ano passado, que n\u00e3o conseguimos encaix\u00e1-los em uma vis\u00e3o geral.<\/p>\n<p>O ano de 2026 est\u00e1 se mostrando igualmente intenso, por isso recomendamos verificar nossa postagem sobre a <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-what-are-they-and-how-to-manage-the-risk\/52852\/\" target=\"_blank\" rel=\"noopener nofollow\">preven\u00e7\u00e3o de ataques a cadeias de suprimentos<\/a>. Enquanto isso, aqui est\u00e3o as conclus\u00f5es mais importantes:<\/p>\n<ul>\n<li>Avalie minuciosamente seus fornecedores e fa\u00e7a uma auditoria cuidadosa do c\u00f3digo que voc\u00ea integra em seus projetos.<\/li>\n<li>Implemente requisitos de seguran\u00e7a r\u00edgidos diretamente em seus contratos de servi\u00e7o.<\/li>\n<li>Desenvolva um plano abrangente de resposta a incidentes.<\/li>\n<li>Monitore atividades suspeitas em sua infraestrutura corporativa usando uma <a href=\"https:\/\/www.kaspersky.com.br\/next-xdr-optimum?icid=br_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team___knext____ff384cd30f463289\" target=\"_blank\" rel=\"noopener\">solu\u00e7\u00e3o de XDR<\/a>.<\/li>\n<li>Se a sua equipe de seguran\u00e7a interna estiver sobrecarregada, procure um <a href=\"https:\/\/www.kaspersky.com.br\/enterprise-security\/managed-detection-and-response?icid=br_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">servi\u00e7o externo de identifica\u00e7\u00e3o proativa de amea\u00e7as e resposta r\u00e1pida<\/a>.<\/li>\n<\/ul>\n<p>Se quiser saber mais detalhes sobre os ataques a cadeias de suprimentos, confira o nosso relat\u00f3rio anal\u00edtico <a href=\"https:\/\/kas.pr\/k8rs\" target=\"_blank\" rel=\"noopener\">Supply chain reaction: securing the global digital ecosystem in an age of interdependence<\/a> (Rea\u00e7\u00e3o em cadeia de suprimentos: prote\u00e7\u00e3o ao ecossistema digital global em uma era de interdepend\u00eancia). Ele se baseia em insights de especialistas t\u00e9cnicos e revela com que frequ\u00eancia as organiza\u00e7\u00f5es enfrentam riscos relacionados \u00e0 cadeia de suprimentos e a rela\u00e7\u00f5es de confian\u00e7a, onde ainda existem lacunas de prote\u00e7\u00e3o e quais estrat\u00e9gias adotar para aumentar a resili\u00eancia contra esse tipo de amea\u00e7a.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kaspersky-next\">\n","protected":false},"excerpt":{"rendered":"<p>Em 2025, assim como no ano anterior, os ataques a cadeias de suprimentos continuaram sendo uma das amea\u00e7as mais graves enfrentadas pelas organiza\u00e7\u00f5es. Vamos analisar em detalhes os incidentes mais not\u00e1veis do ano passado.<\/p>\n","protected":false},"author":2726,"featured_media":24865,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1119,1655,1656],"tags":[218,3424,3425,28,1321,1935,2114,2842,2566,935,776,2028,267],"class_list":{"0":"post-24864","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-ameacas","11":"tag-ataque-a-cadeia-de-suprimentos","12":"tag-ataque-a-cadeias-de-suprimentos","13":"tag-ataques","14":"tag-backdoors","15":"tag-cadeia-de-suprimentos","16":"tag-codigo-aberto","17":"tag-desenvolvimento","18":"tag-devops","19":"tag-negocios","20":"tag-riscos","21":"tag-stealers","22":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/supply-chain-attacks-in-2025\/24864\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/supply-chain-attacks-in-2025\/41594\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/supply-chain-attacks-in-2025\/14440\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2025\/55522\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/supply-chain-attacks-in-2025\/30458\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.br\/blog\/tag\/ataque-a-cadeia-de-suprimentos\/","name":"ataque \u00e0 cadeia de suprimentos"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24864","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/users\/2726"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/comments?post=24864"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24864\/revisions"}],"predecessor-version":[{"id":24867,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24864\/revisions\/24867"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/24865"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=24864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=24864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=24864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}