Siloed planning slows decisions and hides risk. Integrated business planning connects finance, demand, supply, and strategy into a single disciplined cycle.
Nossos especialistas descobriram um ataque à cadeia de suprimentos em grande escala via DAEMON Tools – software para emulação de unidades ópticas. Os invasores conseguiram injetar código malicioso nos instaladores do software, e todos os arquivos executáveis trojanizados estão assinados com uma assinatura digital válida da AVB Disc Soft – a desenvolvedora do DAEMON Tools. A versão maliciosa do programa está em circulação desde 8 de abril de 2026. No momento da redação deste artigo, o ataque ainda está em andamento. Os pesquisadores da Kaspersky acreditam que se trata de um ataque direcionado.
Quais são os riscos de instalar a versão maliciosa do DAEMON Tools?
Depois que o software infectado com trojan é instalado no computador da vítima, um arquivo malicioso é executado toda vez que o sistema é inicializado – enviando uma solicitação a um servidor de comando e controle. Em resposta, o servidor pode enviar um comando para baixar e executar cargas maliciosas adicionais.
Primeiro, os invasores implantam um coletor de informações que reúne o endereço MAC, o nome do host, o nome de domínio DNS, listas de processos em execução e de softwares instalados, além das configurações de idioma. O malware então envia essas informações para o servidor de comando e controle.
Em alguns casos, em resposta às informações coletadas, o servidor de comando envia um backdoor minimalista para a máquina da vítima. Ele é capaz de baixar cargas maliciosas adicionais, executar comandos de shell e rodar módulos de shellcode na memória.
O backdoor pode ser usado para implantar um implantado mais sofisticado chamado QUIC RAT. Ele suporta vários protocolos de comunicação com o servidor de comando e controle e é capaz de injetar cargas maliciosas nos processos notepad.exe e conhost.exe.
Desde o início de abril, foram detectadas várias milhares de tentativas de instalar cargas maliciosas adicionais por meio do software DAEMON Tools infectado. A maioria dos dispositivos infectados pertencia a usuários domésticos, mas aproximadamente 10% das tentativas de instalação foram detectadas em sistemas em execução em organizações. Geograficamente, as vítimas estavam espalhadas por cerca de cem países e territórios diferentes. A maioria das vítimas estava localizada na Rússia, Brasil, Turquia, Espanha, Alemanha, França, Itália e China.
Na maioria das vezes, o ataque se limitava à instalação de um coletor de informações. O backdoor infectou apenas uma dúzia de máquinas em organizações governamentais, científicas e de manufatura, bem como em empresas de varejo na Rússia, Bielorrússia e Tailândia.
O que exatamente foi infectado
O código malicioso foi detectado nas versões do DAEMON Tools que vão da 12.5.0.2421 à 12.5.0.2434. Os invasores comprometeram os arquivos DTHelper.exe, DiscSoftBusServiceLite.exe e DTShellHlp.exe, que estão instalados no diretório principal do DAEMON Tools.
Como se proteger?
Se o software DAEMON Tools for utilizado no seu computador (ou em qualquer outro local da sua organização), nossos especialistas recomendam verificar minuciosamente os computadores nos quais ele está instalado em busca de qualquer atividade incomum a partir de 8 de abril.
Além disso, recomendamos o uso de soluções de segurança confiáveis em todos os computadores domésticos e corporativos usados para acessar a internet. Nossas soluções protegem com sucesso os usuários contra todos os malwares usados no ataque à cadeia de suprimentos via DAEMON Tools.
Your prices could be going up because of a little something that one group has started calling the “cyber tax.”
Not a “tax” in any regulatory sense of the word, this newly named “cyber tax” is instead a consequence of the growing number of cyberattacks on small businesses. According to the latest research from the Identity Theft Resource Center, 81% of small- and medium-sized businesses suffered a data breach, a security breach, or both, within the past year. And of those businesses, more than 50% of lost more than $250,000.
According to the most recent data from the US Federal Reserve, the median American family has just $8,000 in savings, meaning that a hit of $250,000 could bankrupt a family and turn their lives upside down. But there’s an interesting layer within this data—the median American family is quite similar to the median American business. In fact, they’re often the exact same person.
The local grocer, the nearby HVAC repair service, the avid cyclist who just opened a bike shop, and the tax professional, and physical therapist helping out neighbors are everyday individuals and family members. They do not have multimillion dollar corporations at their backs, supporting them with legal teams, insurance policies, and dedicated IT support teams.
A loss of $250,000, then, is a potential loss of their business. And to stay afloat, the Identity Theft Resource Center found, for the first time ever, that 38% decided to raise their prices.
“It was near 40% said ‘We actually had to raise prices—we had to pass this cost onto our customers,’” said Eva Velasquez, CEO of the Identity Theft Resource Center. “We’re now really seeing the long-term downstream effects of cyberattacks.”
As frustrating as the cyber tax can be, small businesses themselves are also facing a new wave of cyberattacks, from AI-powered phishing emails so convincing that small business owners can’t tell the legitimate from the illegitimate, to deepfake calls that impersonate the CEO of a three-person company, to supply-chain attacks that target small companies as a way to reach bigger ones.
Today, on the Lock and Code podcast with host David Ruiz, we speak with Velasquez about cybercrime’s impact on small businesses, the new threats being deployed because of AI, and what is necessary to protect business owners and their consumers.
“Great businesses with great protocols in place can still have a vulnerability exploited because this is what the cyber bad guys are doing all day long. They only have to be right once, whereas small business owners have to be right 100% of the time.”
There’s a lot to security that isn’t necessarily “cyber.” It’s not all hackers or complex network attacks.
Alongside traditional cyberattacks that deploy malware or exploit known software vulnerabilities, there are also less technical—yet equally devastating—forms of theft.
This doesn’t mean that well-known cybersecurity best practices don’t apply. Every small business owner should still use unique passwords for every account, turn on multi-factor authentication, keep their software and operating systems updated, and run always-on cybersecurity software.
But for the everyday small business owner juggling dozens of accounts, networks, devices, and the reams of data being created, stored, and shared across text messages, emails, and online portals, this advice is for you.
For National Small Business Week in the US, here are three ways to protect your business that require little technical prowess.
Don’t use your Social Security Number as your tax ID
In the US, the Internal Revenue Service (IRS) allows small business owners to use their personal Social Security Number (SSN) as the Federal Tax ID. It’s a small grace meant to simplify annual record-keeping for sole proprietors and owner-employees, but for cybercriminals, it’s a basic oversight they’d like every small business to make.
Using your Social Security Number as your Federal Tax ID means putting your Social Security Number in an ever-increasing number of hands. That’s because small business taxes are different from taxes for everyday salaried employees.
Whenever a small business takes on a new client or a contractor who pays for services costing at least $600, that small business has to share and receive what is called a W-9 form. This exact form isn’t filed with the IRS, but it is used to track payments for later filings.
What’s more important, though, is that this form asks for an owner’s name, address, and tax ID number.
This means that as a small business grows, its vulnerability to identity theft increases in tandem. Every W-9 filed that uses an owner’s SSN as their tax ID number is another opportunity for that SSN to be stolen. After just one year of operation, a small business owner’s SSN could end up in the inboxes, filing cabinets, and cloud drives of a dozen different people and companies.
This is exactly what cybercriminals want.
Equipped with a W-9 form about your business, a cybercriminal could impersonate you or your business. They could open a business credit line, file fraudulent returns that claim your small business income, or scam your clients.
How to stay safe:
Apply for a free Employer Identification Number (EIN) at IRS.gov. It’s quick to do and it separates your business tax identity from your personal tax identity. After that, put the EIN on W-9s, 1099s, and all other business paperwork instead of your SSN.
Keep your personal cloud storage personal
The most popular cloud storage for most small business owners is the cloud storage they already have—their personal Google Drive or iCloud.
Built to make memory archival as easy as possible, these tools can automatically back up and secure nearly every single moment that happens through your device, from the vacation photos you snapped last summer, to your kid’s first steps recorded on video, to the texts you sent, the notes you made, and the calendar appointments you managed.
But this type of automatic archival poses a threat to any non-personal information that you view, send, markup, or sign when using your personal smartphone. Suddenly, and often without thinking about it, your cloud storage has backups of signed contracts, tax returns, client intake forms, invoices, business financial statements, and photos of physical paperwork.
Above, we warned about using your SSN as your tax ID because it creates a risk if anyone in your business network is breached. But storing client information in your personal cloud storage creates a different problem: it puts that risk directly on you.
Compounding the threat here is the fact that many personal cloud storage accounts are shared with family members. More people accessing the same account means more exposure and more chances for mistakes, even if everyone has good intentions.
How to stay safe:
Go through the cloud backup settings on both your phone and your computer and manage what data is being synced. Move sensitive business files to a dedicated business storage account with proper access controls, sharing permissions, and audit logs—something that can tell you who opened a file and when.
If anything business-related has to live in a personal cloud account, give that account a strong, unique password, turn on multi-factor authentication, and don’t share access with anyone who isn’t you.
Protect device and account access in the home
Devices have a funny way of moving around. Your smartphone goes into your spouse’s hands as they override your music choices in the car. Your tablet ends most nights in your kid’s bedroom as they watch TV. And your laptop gets tugged around from couch to counter to kitchen table—each time fully opened and logged in, a portal to the web.
You trust everyone in your home to act safely online, but the path to online safety is full of mistakes.
A single errant click on a fake ad, a malicious search result, or a disguised download is all it takes to compromise your device today, along with all your small business records.
Aside from the threat of malware, someone using your device could make purchases, accidentally delete files, and overwrite important documents.
Remember, an “insider threat” doesn’t need to be malicious to cause damage—they just need to be inside your network (which in this, is your home).
How to stay safe:
Treat your devices that you use for work as work devices. That means requiring a passcode or password for device entry, along with multi-factor authentication for important business accounts.
Also, to ensure that any wrong click doesn’t lead to a malicious PDF download or a wayward malware installation, use always-on antimalware protection software, like Malwarebytes for Teams.
Secure your success
It’s easy to get overwhelmed with modern cybersecurity advice. Every week there are new vulnerabilities to patch, emerging scams to avoid, and novel viruses and pieces of malware that can seemingly take over your device, your data, and your business.
Thankfully, there are important steps you can take today that don’t require you to fiddle with internal settings or take a class on network engineering. Some of the most effective protections are simple: Limit how widely you share sensitive information, keep business and personal data separate, and control who can access your devices.
For everything else, try Malwarebytes for Teams to receive 24/7, always-on antimalware protection to shut out viruses, block malware attacks, and keep hackers out of your business.
As empresas atuam de forma sistemática para reduzir a superfície de ataque. Eles segmentam redes, gerenciam vulnerabilidades, implementam EDR/XDR e buscam automatizar as respostas a incidentes. Por mais paradoxal que pareça, muitas vezes ignoram um ponto crucial: a segurança das próprias ferramentas que gerenciam todo o sistema de defesa.
Isso pode acontecer por um ponto cego de percepção. É comum presumir que, por ter implementado todas as soluções de segurança necessárias, a organização já está protegida. Na prática, qualquer software adicional, inclusive de segurança, amplia a superfície de ataque. Isso significa que essas ferramentas também precisam ser protegidas, começando por um ajuste adequado das configurações.
Por que a violação de um console de segurança é um cenário crítico?
As ferramentas de segurança são tão robustas quanto o ambiente em que operam. Se um invasor conseguir acessar a infraestrutura e assumir o controle do console de gerenciamento, ele passa a ter controle total do ambiente. É como uma chave mestra, que dá acesso direto ao gerenciamento centralizado de políticas, monitoramento de endpoints, integrações de API e outros recursos.
Nesse cenário, o invasor não precisa perder tempo para buscar formas sofisticadas de contornar defesas, basta alterar as configurações. Com acesso ao console, o invasor elimina as etapas mais difíceis de um ataque:
não precisa mapear a rede, pois o console oferece uma visão completa da infraestrutura e da arquitetura de segurança de forma imediata.
não precisa ocultar atividades maliciosas, podendo apenas ajustar políticas, desativar ferramentas ou silenciar alertas.
em vez de distribuir cargas maliciosas de forma discreta, pode usar os próprios recursos do console para instalar softwares e atualizações em massa.
Por isso o comprometimento da camada de controle é tão perigoso. Uma abordagem proativa de cibersegurança não depende da quantidade de ferramentas, mas da resiliência da arquitetura de segurança. Se a camada de controle for o ponto fraco, nenhum software avançado diminuirá esse risco.
Como proteger o console de segurança
Em teoria, a maioria dos sistemas de gerenciamento já conta com os recursos necessários para reforçar a proteção. Qual é o problema? Essas medidas, até as mais básicas como autenticação em dois fatores, costumam estar disponíveis, mas não são obrigatórias. As recomendações de segurança são publicadas, mas nem sempre aplicadas de uma maneira consistente. Em alguns casos, são simplesmente ignoradas. Pior ainda, configurações críticas ativadas por padrão podem ser desativadas com um clique, afetando todos os usuários imediatamente. Sejamos honestos: muitas vezes esses recursos são desativados por conveniência.
No mundo real, isso faz com que a segurança acabe dependendo da disciplina individual do administrador. Porém, a disciplina não substitui um mecanismo estrutural de defesa.
A abordagem moderna prioriza o modelo seguro por padrão na proteção da camada de controle. Nesse modelo, as proteções críticas estão integradas à configuração básica, com restrições na capacidade de desativação global. Assim, a segurança deixa de ser opcional.
O objetivo é eliminar incertezas em termos de segurança das ferramentas defensivas e reduzir a superfície de ataque no nível de gerenciamento.
Como implementamos essa abordagem no Kaspersky Security Center Linux
Nossos produtos estão evoluindo de forma consistente para um modelo em que mecanismos críticos fazem parte da arquitetura básica, e não são opcionais. Lançamos recentemente a versão 16.1 do Kaspersky Security Center Linux, que incorpora essa mudança ao reforçar o controle de acesso ao console. Agora, a autenticação de dois fatores está ativada por padrão, e a possibilidade de desativação global foi removida. Antes de atualizar, é necessário garantir que todos os usuários utilizem autenticação de dois fatores (2FA), incluindo acessos pelo Web Console e automações com OpenAPI.
Isso estabelece uma proteção essencial para acessos privilegiados ao console. Reduz o risco de comprometimento de contas administrativas, protege canais de automação, diminui a probabilidade de uso indevido de APIs e elimina vulnerabilidades decorrentes de configurações opcionais. Dessa forma, a superfície de ataque é reduzida especificamente no gerenciamento da camada de controle.
No entanto, como já mencionado, o problema geralmente não é a falta de recursos, mas a ausência de controle sistemático sobre seu uso. Por exemplo, é comum haver administradores com privilégios excessivos ou configurações inseguras de conexão ao servidor. Já disponibilizamos um guia de reforço da proteção para o Kaspersky Security Center que aborda esses pontos em detalhe, mas, infelizmente, nem todos dedicam tempo para ler manuais técnicos extensos.
Para garantir que nada seja ignorado, reunimos uma lista de verificação estruturada para reforçar a segurança do Kaspersky Security Center Linux, versão 16.1. Esta lista de verificação:
permite verificar se autenticação e acessos estão configurados corretamente
ajuda a identificar usuários e funções com privilégios excessivos
orienta sobre como restringir o acesso de rede ao console
reforça a proteção de APIs
fortalece os requisitos de criptografia
garante a correta configuração de auditoria e logs
reduz o risco de falhas de configuração
Essencialmente, é uma ferramenta de auditoria sistemática da camada de controle. Ela evita que o console se torne um ponto de entrada ou facilite a movimentação lateral de invasores. Quanto menos configurações críticas dependerem do usuário, menor o risco de erro ou comprometimento.
Autenticação reforçada e reforço estruturado do console não são ajustes pontuais, mas uma abordagem mais robusta de gestão de segurança. A proposta é evoluir essa camada de forma contínua, reduzindo a superfície de ataque não só nos endpoints, mas também no próprio sistema de gerenciamento. Saiba mais sobre o Kaspersky Security Center na página do console e acesse a lista de verificação de proteção disponível no site de suporte técnico.
Founders can access liquidity without exiting by selling shares via secondary deals, reducing financial pressure while staying focused on long-term growth.
Como já comentamos em uma postagem anterior, o desenvolvimento de produtos de software modernos é praticamente impossível sem o uso de componentes de código aberto. Mas, nos últimos anos, os riscos associados a isso tornaram-se cada vez mais diversos, complexos e numerosos. Devemos considerar que, primeiro, as vulnerabilidades afetam a infraestrutura e o código de uma empresa mais rapidamente do que são corrigidas; segundo, os dados são incompletos e pouco confiáveis; e, terceiro, malware pode estar escondido em componentes populares. Portanto, não basta simplesmente verificar os números de versão e solicitar que a equipe de TI corrija os problemas. O gerenciamento de vulnerabilidades deve ser expandido para abranger políticas de download de software, proteções para assistentes de IA e todo o pipeline de criação de software.
Um conjunto confiável de componentes de código aberto
A principal característica de uma solução é impedir o uso de código vulnerável e malicioso. As seguintes medidas devem ser implementadas:
Ter um repositório interno de artefatos. A fonte única de componentes para desenvolvimento interno precisa ser um repositório unificado no qual os componentes são admitidos somente após uma série de verificações.
Fazer uma triagem rigorosa dos componentes. Isso inclui verificações de versões conhecidas do componente, versões vulneráveis e maliciosas conhecidas, data de publicação, histórico de atividades e reputação do pacote e de seus autores. É obrigatório verificar todo o conteúdo do pacote, incluindo instruções de compilação, casos de teste e outros dados auxiliares. Para filtrar o registro durante a ingestão, use verificadores de código aberto especializados ou uma solução de segurança abrangente de carga de trabalho na nuvem.
Fixar versões de dependências. Os processos de compilação, as ferramentas de IA e os desenvolvedores não devem usar modelos (como “o mais recente”) ao especificar versões. As compilações do projeto precisam ser baseadas em versões verificadas. Ao mesmo tempo, as dependências com versões fixas devem ser atualizadas com frequência para as versões verificadas mais recentes que mantêm a compatibilidade e não contêm vulnerabilidades conhecidas. Isso reduz significativamente o risco de ataques à cadeia de suprimentos por meio do comprometimento de um pacote conhecido.
Aperfeiçoamento dos dados de vulnerabilidades
Para identificar vulnerabilidades com mais eficácia e priorizá-las de forma adequada, uma organização precisa estabelecer vários processos de TI e segurança:
Enriquecimento de dados de vulnerabilidade. Dependendo das necessidades da organização, isso é necessário para enriquecer as informações combinando dados do NVD, EUVD, BDU, GitHub Advisory Database e osv.dev, ou para comprar um feed de inteligência de vulnerabilidades comercial no qual os dados já estão agregados e enriquecidos. Em ambos os casos, também vale a pena monitorar os feeds de inteligência de ameaças para rastrear tendências de exploração reais e obter um entendimento do perfil dos invasores que visam vulnerabilidades específicas. A Kaspersky fornece um feed de dados especializado especificamente focado em componentes de código aberto.
Análise detalhada da composição do software. As ferramentas especializadas de análise de composição de software (SCA) permitem o mapeamento correto da cadeia de dependências no código-fonte aberto para realizar o inventário completo das bibliotecas que estão sendo usadas e descobrir componentes desatualizados ou sem suporte. Os dados sobre componentes íntegros também são úteis para enriquecer o registro de artefatos.
Identificação do abandonware. Mesmo que um componente não apresente vulnerabilidades formais e o encerramento do suporte ainda não tenha sido declarado oficialmente, o processo de verificação deve sinalizar os componentes que não receberam atualizações há mais de um ano. Isso garante uma análise separada e uma possível substituição, assim como ocorre com os componentes em EOL (fim da vida útil).
Proteção do código e dos agentes de IA
As atividades dos sistemas de IA usados na codificação devem ser agrupadas em um conjunto abrangente de medidas de segurança: desde a filtragem de dados de entrada até o treinamento do usuário:
Restrições de recomendações de dependências. Configure o ambiente de desenvolvimento para garantir que os agentes e assistentes de IA consultem apenas componentes e bibliotecas do registro de artefatos confiável. Se eles não contiverem as ferramentas corretas, o modelo deve acionar uma solicitação para incluir a dependência no registro em vez de extrair algo do PyPI que apenas corresponda à descrição.
Filtragem das saídas do modelo. Apesar dessas restrições, tudo o que for gerado pelo modelo também deve ser verificado para garantir que o código de IA não contenha dependências desatualizadas, sem suporte, vulneráveis ou inventadas. Essa verificação deve ser integrada diretamente no processo de aceitação do código ou no estágio de preparação da compilação. Ela não substitui o processo de análise estática tradicional: as ferramentas SAST ainda devem ser incorporadas no pipeline de CI/CD.
Treinamento do desenvolvedor. As equipes de TI e de segurança devem estar extremamente familiarizadas com as características dos sistemas de IA, seus princípios operacionais e erros comuns. Para conseguir isso, os funcionários devem completar um curso de treinamento especializado, adaptados às suas funções específicas.
Remoção sistemática de componentes em EOL
Se os sistemas de uma empresa utilizarem componentes de código aberto desatualizados, deve-se adotar uma abordagem sistemática e consistente para lidar com as vulnerabilidades. Existem três métodos principais para fazer isso:
Migração. Este é o método mais complexo e caro para uma organização, pois envolve a substituição total de um componente, seguida pela adaptação, reescrita ou substituição dos aplicativos construídos sobre ele. Decidir sobre uma migração é muito mais difícil quando se exige uma revisão geral de todo o código interno. Isso costuma afetar os componentes principais: é impossível migrar facilmente do Node.js 14 ou do Python 2.
Suporte de longo prazo (LTS). Existe um mercado de serviços de suporte dedicado para projetos legados de larga escala. Às vezes, isso envolve uma bifurcação do sistema legado mantido por desenvolvedores de terceiros; em outros casos, equipes especializadas fazem o backport de patches que corrigem vulnerabilidades específicas em versões mais antigas e sem suporte. A transição para o LTS geralmente exige custos de suporte contínuos, mas, em muitos casos, isso ainda pode ser mais econômico do que uma migração completa.
Os departamentos de segurança, TI e negócios devem trabalhar juntos para escolher um desses três métodos para cada componente abandonado ou com EOL documentado e refletir a escolha feita nos registros de ativos e SBOMs da empresa.
Gerenciamento de vulnerabilidades de código aberto baseado em risco
Todos os métodos listados acima reduzem o volume de softwares e componentes vulneráveis que entram na organização, o que simplifica a detecção e a correção de falhas. Apesar disso, é impossível eliminar todos os defeitos: o número de aplicativos e componentes está crescendo muito rápido.
A ramificação do código vulnerável é realmente executada no ambiente da organização? Deve-se realizar uma análise de acessibilidade das vulnerabilidades descobertas. Muitos snippets de código defeituosos nunca são realmente executados na implementação específica da organização, fazendo com que seja impossível explorar a vulnerabilidade. Certas soluções de SCA podem realizar esta análise. Esse mesmo processo permite avaliar um cenário alternativo: o que acontece se os procedimentos ou componentes vulneráveis forem removidos completamente do projeto? Às vezes, esse método de remediação é surpreendentemente indolor.
O defeito está sendo explorado em ataques reais? Há um PoC disponível? As respostas a essas perguntas fazem parte de estruturas de priorização padrão, como EPSS, mas o rastreamento deve ser realizado em um conjunto muito mais amplo de fontes de inteligência.
A atividade de criminosos cibernéticos foi relatada nesse registro de dependência ou em componentes relacionados e semelhantes? Estes são fatores adicionais para a priorização.
A consideração desses fatores permite que a equipe aloque recursos de forma eficaz e corrija os defeitos mais perigosos primeiro.
A transparência nunca sai de moda
O padrão de segurança para softwares de código aberto só vai continuar subindo. As empresas que desenvolvem aplicativos, mesmo que para uso interno, enfrentarão pressões regulatórias que exigem segurança cibernética documentada e verificável nos seus sistemas. De acordo com as estimativas dos especialistas da Sonatype, 90% das empresas em todo o mundo já se enquadram em um ou mais requisitos que as obrigam a fornecer provas da confiabilidade do software que usam. Portanto, os especialistas consideram a transparência “o pilar fundamental da segurança da cadeia de suprimento de software”.
Ao controlar o uso de componentes e aplicativos de código aberto, enriquecer a inteligência contra ameaças e fazer o monitoramento rigoroso dos sistemas de desenvolvimento orientados por IA, as organizações podem introduzir as inovações que tanto desejam, ao mesmo tempo em que atingem o padrão elevado definido por reguladores e clientes.
Até bem pouco tempo, somente as empresas especializadas em software e as gigantes em tecnologia precisavam se preocupar com as vulnerabilidades de código aberto e os ataques direcionados contra a cadeia de suprimentos. Porém, os tempos mudaram. Hoje, até mesmo as pequenas empresas estão mantendo suas próprias lojas de desenvolvimento, e isso torna o problema significativo para todo mundo. De maneira ininterrupta, as equipes internas de TI das empresas estão ocupadas escrevendo código, configurando integrações e automatizando fluxos de trabalho, mesmo que o negócio principal não tenha absolutamente nada a ver com software. É o que a eficiência empresarial moderna exige. No entanto, como consequência disso, surge uma nova geração de vulnerabilidades de software, o tipo muito mais complicado de corrigir do que apenas instalar a atualização mais recente do Windows.
O desenvolvimento de software moderno é inseparável dos componentes de código aberto. Porém, os riscos associados proliferaram nos últimos anos, além de terem aumentado em variedade e sofisticação. Estamos testemunhado a injeção de código malicioso em repositórios populares, dados de vulnerabilidade fragmentados e com falhas, o uso sistemático de componentes desatualizados e vulneráveis e as cadeias de dependência cada vez mais complexas.
A escassez de dados de vulnerabilidade para código aberto
Mesmo que sua organização tenha um processo de gerenciamento de vulnerabilidades sólido para software comercial de terceiros, é possível constatar que o código aberto requer uma revisão completa desse processo. Os bancos de dados públicos mais usados geralmente são incompletos, imprecisos ou simplesmente lentos para obter atualizações quando se trata de código aberto. Isso transforma a priorização de vulnerabilidades em um jogo de adivinhação. Por mais automação que possa existir, ela será inútil se os dados de referência estiverem cheios de falhas.
De acordo com os dados da Sonatype, cerca de 65% das vulnerabilidades de código aberto atribuídas a um CVE ID não possuem uma pontuação de vulnerabilidade (CVSS) no NVD, a base de conhecimento de vulnerabilidades mais usada. Dessas vulnerabilidades não pontuadas, quase 46% seriam classificadas como alta, se analisadas adequadamente.
Mesmo quando uma pontuação CVSS está disponível, fontes diferentes estão de acordo apenas no que se refere à gravidade em cerca de 55% das vezes. Um banco de dados pode sinalizar uma vulnerabilidade como crítica, enquanto outro recebe uma pontuação média para ela. Metadados mais detalhados, como as versões de pacotes afetadas, também costumam estar repletos de erros e inconsistências. Seus verificadores de vulnerabilidades que comparam versões de software acabam gerando falsos positivos ou fornecendo falsamente um atestado de integridade.
O déficit nos dados de vulnerabilidade está crescendo e o processo de geração de relatórios está ficando mais lento. Nos últimos cinco anos, o número total de CVEs dobrou, mas o número de CVEs sem uma pontuação de gravidade explodiu por um fator de 37. De acordo com a Tenable, até 2025, o código de exploração de prova de conceito (PoC) esteve normalmente disponível dentro de uma semana após a descoberta de uma vulnerabilidade, mas obter a mesma vulnerabilidade listada no NVD levou em média 15 dias. Os processos de aprimoramento, como atribuir uma pontuação CVSS, são ainda mais lentos, a Sonatype no mesmo estudo estima que o tempo médio para atribuir uma pontuação CVSS é de 41 dias, com alguns defeitos permanecendo sem classificação por até um ano.
O problema do código aberto legado
Bibliotecas, aplicativos e serviços que não são mais mantidos, que foram abandonados ou que atingiram seu fim de vida útil (EOL), podem ser encontrados em 5 a 15% dos projetos corporativos, de acordo com a HeroDevs. Em cinco registros populares de código aberto, há pelo menos 81 mil pacotes que contêm vulnerabilidades conhecidas, mas pertencem a versões desatualizadas e sem suporte. Esses pacotes nunca verão os patches oficiais. Essa “bagagem legada” é responsável por cerca de 10% dos pacotes no Maven Central e no PyPI, e impressionantes 25% no npm.
Usar esse tipo de código aberto quebra o ciclo de vida padrão do gerenciamento de patches: não é possível atualizar, automática ou manualmente, uma dependência que não é mais compatível. Além disso, quando as versões EOL são omitidas dos boletins de vulnerabilidades oficiais, os verificadores de segurança podem categorizá-las como “não afetadas” por um defeito e ignorá-las.
Um excelente exemplo disso é o Log4Shell, a vulnerabilidade crítica (CVSS 10) na popular biblioteca Log4j descoberta em 2021. A versão vulnerável foi responsável por 40 milhões dos 300 milhões de downloads do Log4j em 2025. É importante ressaltar que estamos falando de uma das vulnerabilidades mais infames e amplamente relatadas da história, uma que foi ativamente explorada, corrigida pelo desenvolvedor e tratada em todos os principais produtos derivados. A situação para os defeitos menos divulgados é significativamente pior.
Para agravar esse problema, existe a lacuna de visibilidade. Muitas organizações não têm as ferramentas necessárias para mapear uma árvore de dependências completa ou obter visibilidade total dos pacotes e versões específicos integrados em sua pilha de software. Desse modo, os componentes desatualizados geralmente permanecem invisíveis e nunca entram na fila de correção.
Malware em registros de código aberto
Os ataques que envolvem pacotes de código aberto infectados ou inerentemente maliciosos se tornaram uma das ameaças de crescimento mais rápida para a cadeia de fornecimento de software. De acordo com pesquisadores da Kaspersky, aproximadamente 14 mil pacotes maliciosos foram descobertos em registros populares até o final de 2024, um aumento de 48% a cada ano. A Sonatype relatou um aumento ainda mais explosivo ao longo de 2025 e detectou mais de 450 mil pacotes maliciosos.
A motivação por trás desses ataques varia muito: roubo de criptomoedas, coleta de credenciais de desenvolvedor, espionagem industrial, obtenção de acesso à infraestrutura por meio de pipelines de CI/CD ou comprometimento de servidores públicos para hospedar campanhas de spam e phishing. Essas táticas são empregadas tanto por grupos APT de espionagem quanto por criminosos virtuais motivados financeiramente. É cada vez mais comum a violação de um pacote de código aberto ser apenas o primeiro passo de uma violação corporativa em vários estágios.
Cenários de ataque comuns incluem comprometer as credenciais de um mantenedor de pacote de código aberto legítimo, publicar uma biblioteca “útil” com código malicioso integrado ou publicar uma biblioteca maliciosa com um nome quase idêntico a um popular. Uma tendência particularmente alarmante em 2025 foi o aumento de ataques automatizados semelhantes a worms. O exemplo mais notório é a campanha Shai-Hulud. Nesse caso, o código malicioso roubou os tokens do GitHub e npm e continuou infectando novos pacotes, eventualmente se espalhando para mais de 700 pacotes npm e dezenas de milhares de repositórios. Ele vazou segredos de CI/CD e chaves de acesso à nuvem para o domínio público no processo.
Embora esse cenário não esteja tecnicamente relacionado a vulnerabilidades, as ferramentas de segurança e as políticas necessárias para seu gerenciamento são as mesmas usadas para o gerenciamento de vulnerabilidades.
Como os agentes de IA aumentam os riscos do uso de código aberto
A integração apressada e onipresente de agentes de IA no desenvolvimento de software aumenta significativamente a velocidade do desenvolvedor, mas também amplifica qualquer erro. Sem supervisão rigorosa e proteções claramente definidas, o código gerado por IA fica excepcionalmente vulnerável. A pesquisa mostra que 45% do código gerado por IA contém falhas da lista OWASP Top 10, enquanto 20% dos aplicativos orientados por IA implementados abrigam erros de configuração perigosos. Isso acontece porque os modelos de IA são treinados em grandes conjuntos de dados que incluem grandes volumes de código desatualizado, demonstrativo ou puramente educacional. Esses problemas sistêmicos ressurgem quando um modelo de IA decide quais componentes de código aberto devem ser incluídos em um projeto. O modelo costuma não saber quais versões do pacote existem no momento, nem quais foram sinalizadas como vulneráveis. Em vez disso, ele sugere uma versão de dependência extraída de seus dados de treinamento, que, provavelmente, estará obsoleta. Em alguns casos, os modelos tentam chamar versões inexistentes ou bibliotecas totalmente alucinadas. Isso abre a porta para ataques de confusão de dependência.
Em 2025, mesmo os principais LLMs recomendaram versões de dependência incorretas, simplesmente inventando uma resposta, em 27% dos casos.
A IA pode simplesmente corrigir tudo?
É uma ideia simples e tentadora: basta apontar um agente de IA para sua base de código para que ele procure e corrija todas as vulnerabilidades. Infelizmente, a IA não pode resolver totalmente esse problema. Os obstáculos fundamentais que discutimos prejudicam os agentes de IA tanto quanto os desenvolvedores humanos. Se os dados de vulnerabilidade estiverem ausentes ou não forem confiáveis, em vez de encontrar vulnerabilidades conhecidas, será necessário redescobrir tudo do zero. Esse processo consome muitos recursos e requer conhecimento de nicho que permanece fora do alcance da maioria das empresas.
Além disso, se uma vulnerabilidade for descoberta em um componente obsoleto ou sem suporte, um agente de IA não poderá “corrigir automaticamente” a vulnerabilidade. Ainda será preciso desenvolver patches personalizados ou executar uma migração complexa. Se uma falha estiver profundamente oculta em uma cadeia de dependências, é provável que a IA ignore isso completamente.
O que fazer?
Para minimizar os riscos descritos acima, será necessário expandir o processo de gerenciamento de vulnerabilidades para incluir políticas de download de pacotes de código aberto, regras operacionais do assistente de IA e o processo de compilação do software. Isso inclui:
VPNs help secure remote server access by encrypting traffic, restricting entry to authorized users, and reducing exposure of critical systems to the internet.
Alerts this report is based on reports of data breaches and the sale of initial access rights posted on deep web-dark web forums. some parts of the report contain information that cannot be fully verified as factual due to the nature of the source. Major Issues Multiple breach claims by ShinyHunters. a wide range of […]
Undisclosed number of names and contact and reservation details accessed in latest cybercrime attempt
The accommodation reservation website Booking.com has suffered a data breach with “unauthorised parties” gaining access to customers’ details.
The platform said it “noticed some suspicious activity involving unauthorised third parties being able to access some of our guests’ booking information”.
OpenAI has rolled out a new Pro subscription that costs $100 and is in line with Claude's pricing, which also has a $100 subscription, in addition to the $200 Max monthly plan. [...]
느린 헬프데스크 지원을 포함한 IT 비효율로 인해 많은 기업이 매년 수백만 달러의 비용을 부담하고 있으며, 다수의 직원과 IT 리더가 매주 여러 시간의 업무 시간을 잃고 있는 것으로 나타났다. AI 기반 헬프데스크 제공업체 아테라(Atera)의 설문조사 결과에서 확인된 내용이다.
헬프데스크 지연과 기타 IT 비효율이 흔하고 비용 부담이 크다는 점은 이미 알려져 있었지만, AI 기반 헬프데스크 제공업체 아테라(Atera)를 위해 실시된 이번 조사는 이러한 문제를 수치로 구체화했다.
조사에 따르면 직원의 3분의 2 이상이 프로세스 탐색, 이슈 재등록, 기술적 문제 해결 등 이른바 ‘메타 업무’에 하루 근무 시간의 최소 10%를 사용하고 있는 것으로 나타났다. 또한 약 3분의 2는 IT 시스템 지연으로 하루 최소 10분을 잃고 있으며, 이러한 지연은 직원 1인당 주당 100달러 이상의 비용을 기업에 발생시키는 경우가 많았다.
수천 명의 직원을 보유한 대기업의 경우 이러한 비용은 빠르게 누적될 수 있다.
IT 리더 역시 이러한 문제에서 자유롭지 않았다. 응답자의 약 4분의 3은 접근 권한 문제, 느린 시스템, 승인 지연, IT 문제 해결 지연 등으로 인해 매주 평균 최소 1시간을 잃고 있다고 밝혔다.
아테라의 설립자이자 최고경영자인 길 페켈만은 헬프데스크 요청 이후 직원 1명이 평균 약 3시간 30분의 업무 시간을 잃는다고 설명했다. 그는 “티켓을 생성한 시점부터 담당자의 응답을 받을 때까지의 시간, 문제 해결에 소요되는 시간, 그리고 업무 전환에 따른 비용이 모두 포함된다”며 “직원이 기존에 하던 업무를 중단하고 다른 일을 처리한 뒤 다시 원래 업무로 돌아오는 과정에서도 추가적인 시간이 소요된다”고 말했다.
간과된 비용
아테라는 자사의 AI 기반 헬프데스크 솔루션 홍보를 위해 이번 조사를 의뢰했지만, 다른 IT 전문가들은 조사 수치가 오히려 보수적일 수 있다고 평가했다. 애플리케이션 보안 기업 블랙덕 소프트웨어(Black Duck Software)의 수석 디렉터이자 기술 전문가인 콜린 호그-스피어스는 대부분의 조직이 IT 비효율로 인한 비용을 과소평가하고 있다고 지적했다.
호그-스피어스는 많은 대기업이 운영 비효율과 업무 지연으로 대표되는 이른바 ‘IT 마찰(friction)’로 인해 200명 이상의 인력에 해당하는 생산성 손실을 떠안고 있지만, 이러한 비용이 단일 예산 항목으로는 드러나지 않는다고 설명했다. 그는 “이번 연구의 수치는 실제 기업 환경에서 목격하는 상황과 일치한다”며 “진정한 문제는 마찰이 존재한다는 점이 아니라, 대부분의 재무팀이 이를 검토하도록 요청받은 적이 없다는 데 있다”고 말했다.
이어 IT 리더가 디지털 경험 측정 도구를 도입하고 분기별 검토를 수행해야 한다고 권고했다. 호그-스피어스는 “CFO가 분기마다 인력 규모는 검토하면서도 마찰 지표를 본 적이 없다면, 기업은 ‘유령 인력’에 비용을 지출하고 이를 간접비로 처리하고 있는 셈”이라며 “IT 마찰은 단순한 비용 센터가 아니라 보이지 않는 인력 손실”이라고 표현했다.
또한 일부 IT 마찰은 불가피하며, 기업 규모가 클수록 문제가 더욱 심화된다고 덧붙였다. 규정 준수 요구사항, 멀티클라우드 환경, 복잡한 배포 구조 등이 이러한 문제를 가중시킨다는 설명이다. 그는 “유능한 CIO는 이 부담을 줄일 수는 있지만 완전히 없앨 수는 없다”며 “우수한 디지털 경험을 제공하는 조직은 그렇지 않은 조직보다 생산성 손실이 현저히 적으며, 이는 리더십의 중요성을 입증한다”고 분석했다.
완벽함의 신화
디지털 전환 컨설팅 기업 콘트라코(contraco)의 최고경영자 프랭크 멜트케는 일부 IT 비효율은 불가피하다고 설명했다. 그는 “마찰이 전혀 없는 IT 환경은 환상에 가깝다”며 “완전히 마찰이 없는 환경이 존재한다면, 그것은 보안이 취약하거나 비용이 지나치게 높은 경우일 것”이라고 말했다.
멜트케는 강력한 보안 프로토콜과 규정 준수 요구사항이 일정 수준의 메타 업무를 유발한다고 설명하며, “이번 연구는 실제 마찰을 측정했지만, 필요한 마찰과 불필요한 마찰을 구분하지는 않았다”고 지적했다. 이어 “성공적인 IT 리더의 목표는 모든 마찰을 제거하는 것이 아니라, 조직을 보호하기 위해 필요한 프로세스가 적절히 작동하도록 하는 것”이라고 전했다.
일부 IT 마찰이 불가피하더라도, 이러한 문제는 특히 중소기업(SMB)에 더 큰 영향을 미친다고 멜트케는 분석했다. 이번 아테라 설문조사는 미국 내 직원 1,000명 이상의 기업을 대상으로 정규직 직원 1,000명과 C-레벨 및 고위 리더 500명을 포함해 진행됐지만, 더 작은 조직을 조사할 경우 문제가 더욱 심각하게 나타날 수 있다는 설명이다.
그는 “대기업 직원이 헬프데스크 티켓을 기다리며 45분을 잃는다면, 중소기업 직원은 문제를 직접 해결하려다 그보다 더 많은 시간을 잃을 수 있다”고 말했다.
1인 기업의 경우 상황은 더욱 심각하다. 멜트케는 “대표이자 실행 인력이며 IT 부서 역할까지 모두 수행해야 한다”며 “문서 서식 지정, 이메일 통합 문제 해결, 작업 수동 태깅 등에 소비되는 모든 시간은 곧바로 매출 창출 기회를 잠식한다”고 설명했다.
이에 따라 멜트케는 중소 조직이 IT 환경을 단순화할 것을 권장했다. 그는 “지속적인 유지보수와 수작업 데이터 입력이 필요한 저가 단일 기능 애플리케이션을 여러 개 조합하기보다, 소수의 강력하고 신뢰할 수 있는 도구에 집중해야 한다”며 “CRM, 청구, 일정 관리를 통합 제공하는 단일 프리미엄 플랫폼이 무료 도구 다섯 개를 조합한 분산형 스택보다 훨씬 뛰어난 성과를 낼 것”이라고 조언했다.
AI, 해결사가 될 수 있을까?
일부 전문가들은 AI 기반 헬프데스크 서비스가 응답 속도를 높이고 직원들이 보다 신속하게 생산성을 회복하는 데 도움을 줄 수 있다고 보고 있다. 프랭크 멜트케는 AI가 아직 거버넌스 관련 마찰을 해소하는 데에는 한계가 있지만, 헬프데스크의 일부 기능을 자동화하는 데는 효과적이라고 설명했다.
그는 “자동화된 헬프데스크 도구는 반복적인 1차 지원 이슈, 비밀번호 재설정, 접근 권한 요청, 그리고 이미 알려진 오류 패턴을 매우 효율적으로 처리하며, 어떤 인력 기반 대기열보다 빠르게 대응할 수 있다”며 “대량의 반복 티켓을 처리하는 조직에게 이는 실질적이고 측정 가능한 성과로 이어진다”고 말했다.
아테라의 설립자이자 최고경영자인 길 페켈만 역시 AI 기반 헬프데스크의 필요성을 강조하며, 해당 서비스가 응답 시간을 수 시간에서 수 분 단위로 단축할 수 있다고 밝혔다. 또한 AI는 숙련된 IT 인력을 확보하는 데 어려움을 겪는 기업에도 실질적인 도움이 될 수 있다고 설명했다.
그는 “현재 시장에서는 우수한 IT 인력이 매우 부족한 상황”이라며 “AI를 활용하면 기존 인력이 이전에는 수행하지 못했던, 기업에 매우 중요한 프로젝트에 집중할 수 있게 된다”고 말했다. dl-ciokorea@foundryco.com
Os ataques a cadeias de suprimentos têm sido uma das categorias mais perigosas de incidentes de cibersegurança há anos. Se o ano de 2025 nos ensinou alguma coisa, é que os cibercriminosos estão aumentando sua capacidade de ataque. Nesta análise detalhada, veremos ataques a cadeias de suprimentos realizados em 2025 que, embora não sejam os que causaram maiores prejuízos financeiros, certamente foram os mais incomuns e chamaram a atenção do setor.
Janeiro de 2025: um RAT encontrado no repositório do GitHub do DogWifTools
Como um “aquecimento” após o fim de ano, os cibercriminosos realizaram inúmeros ataques de backdoor a várias versões do DogWifTools. Trata-se de um utilitário projetado para lançar e promover vigorosamente moedas de meme baseadas em Solana no Pump.fun. Depois de comprometer o repositório privado do GitHub para o DogWifTools, os invasores esperaram os desenvolvedores carregarem uma nova versão do utilitário, injetaram um RAT nela e trocaram o programa legítimo por uma versão maliciosa apenas algumas horas depois. De acordo com os desenvolvedores, os agentes de ameaças instalaram com êxito as versões 1.6.3 a 1.6.6 do DogWifTools para Windows.
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ítimas. As vítimas estimaram o total de mais de USD 10 milhões em criptomoedas, mas os invasores contestaram esse número, embora não tenham revelado exatamente o valor total roubado.
Fevereiro de 2025: roubo de USD 1,5 bilhão do Bybit
Se janeiro foi só o aquecimento, o mês de fevereiro foi um colapso total. A invasão da plataforma de câmbio de criptomoedas Bybit superou completamente os incidentes anteriores, tornando-se o maior roubo de criptomoedas da história. Os invasores conseguiram comprometer o software Safe{Wallet}, a solução de armazenamento a frio de múltiplas assinaturas na qual a empresa confiava para gerenciar os seus ativos.
Os funcionários da Bybit pensaram que estavam assinando uma transação 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árias centenas de endereços controlados pelo invasor. A transferência final ultrapassou 400 mil ETH/stETH, com um impressionante valor total de aproximadamente… USD 1,5 bilhão!
Março de 2025: Coinbase é alvo de comprometimento em cascata do GitHub Actions
O ano de 2025 seguiu com um ataque sofisticado que usou o comprometimento de vários GitHub Actions, os padrões de fluxo de trabalho usados para automatizar tarefas de DevOps padrão, como seu principal mecanismo de entrega. Tudo começou com o roubo de um token de acesso pessoal pertencente a um mantenedor da ferramenta de análise 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ém estava envolvido no projeto.
A partir daí, eles comprometeram uma dependência, 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ível que pareça, o script gravou tudo o que encontrou diretamente nos registros de compilação acessíveis ao público em geral. Isso significa que os dados vazados não estavam disponíveis apenas para os invasores, mas também para qualquer pessoa experiente o suficiente para acessá-los.
O alvo original dessa operação era um repositório pertencente à plataforma de câmbio de criptomoedas Coinbase. Felizmente, os desenvolvedores detectaram a ameaça 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órios em risco de vazamento de segredos. No final, várias centenas desses repositórios realmente tiveram suas credenciais confidenciais expostas ao público.
Abril de 2025: um backdoor em 21 extensões do Magento
Em abril, uma infecção foi descoberta em um amplo conjunto de extensões do Magento, uma das plataformas mais populares para a criação de lojas on-line. O backdoor foi incorporado em 21 módulos desenvolvidos por três fornecedores: Tigren, Meetanshi e MGS. As extensões faziam parte da infraestrutura de várias centenas de empresas de comércio eletrônico, incluindo pelo menos uma corporação multinacional.
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ção incorporada nas extensões que executava um código arbitrário extraído de um arquivo de licença.
Por ironia, os módulos infectados incluíam o MGS GDPR e o Meetanshi CookieNotice. Como os nomes sugerem, essas extensões foram projetadas para ajudar os sites a cumprir os regulamentos de privacidade e processamento de dados dos usuários. Por fim, em vez de garantir a privacidade, o uso deles provavelmente levou ao roubo de dados e ativos financeiros do usuário por meio de skimming digital.
Maio de 2025: ransomware distribuído por meio de um MSP comprometido
Em maio, os agentes de ransomware da gangue DragonForce obtiveram acesso à infraestrutura de um provedor de serviços gerenciados (MSP) não identificado e a usaram para distribuir um ransomware e roubar dados das organizações clientes do MSP.
Ao que tudo indica, os invasores exploraram várias vulnerabilidades (incluindo uma falha crítica) no SimpleHelp, a ferramenta de monitoramento e gerenciamento remoto usada pelo MSP. Essas vulnerabilidades foram descobertas em 2024 e divulgadas publicamente e corrigidas em janeiro de 2025. Infelizmente, ficou claro que o MSP optou por não acelerar o processo de atualização, um atraso que a gangue do ransomware ficou mais do que feliz em explorar.
Junho de 2025: um backdoor em mais de uma dúzia de pacotes npm populares
No início do verão, os invasores invadiram a conta de um dos mantenedores da biblioteca Glustack e usaram um token de acesso roubado para injetar backdoors em 17 pacotes npm. 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ão.
O que é particularmente interessante nesse caso são as etapas que os desenvolvedores do Glustack seguiram após o incidente: primeiro, eles restringiram o acesso ao repositório GitHub para contribuidores secundários; segundo, eles ativaram a autenticação de dois fatores (2FA) para publicar novas versões; e terceiro, eles prometeram implementar práticas de desenvolvimento seguras, como fluxo de trabalho baseado em pull requests, revisões sistemáticas de código, registro de auditorias e assim por diante. Em outras palavras, antes do incidente, um projeto com centenas de milhares de downloads semanais não tinha tais medidas em vigor.
Julho de 2025: pacotes npm populares infectados por meio de um ataque de phishing
Em julho, os pacotes npm foram novamente as estrelas do show, incluindo o pacote amplamente usado chamado “is”, que possui 2,7 milhões de downloads semanais. Essa biblioteca de utilitários JavaScript fornece uma ampla variedade de funções de verificação de tipo e validação de valor. Para realizar um ataque de phishing contra um dos proprietários do projeto, os invasores utilizaram com êxito um truque antigo: o typosquatting (usar o domínio npnjs.com em vez de npmjs.com) e um clone do site oficial do npm.
Em seguida, eles usaram a conta comprometida para publicar várias das suas próprias versões do pacote com um backdoor incorporado. A infecção passou desapercebida por seis horas: tempo suficiente para um grande número de desenvolvedores baixarem os pacotes npm maliciosos.
A mesma tática de phishing foi usada contra outros desenvolvedores. Os invasores aproveitaram várias contas de desenvolvedores comprometidas para distribuir diferentes variantes de sua carga maliciosa. Há também uma forte suspeita de que eles podem ter guardado parte dessa carga para ataques futuros.
Agosto de 2025: o ataque s1ngularity e o vazamento de centenas de segredos dos desenvolvedores
No final de agosto, um incidente apelidado de “s1ngularity” continuou a tendência de atingir desenvolvedores de JavaScript. Os invasores comprometeram o Nx, um sistema de compilação popular e uma ferramenta de otimização de pipeline de CI/CD. O código 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.
Curiosamente, os invasores usaram ferramentas de IA instaladas localmente, como Claude Code, Gemini CLI e Amazon Q, para detectar os segredos nas máquinas das vítimas. Tudo o que eles encontraram foi publicado nos repositórios públicos do GitHub criados em nome das vítimas, usando os títulos “s1ngularity-repository”, “s1ngularity-repository-0” e “s1ngularity-repository-1”. Como você deve ter adivinhado, é daí que vem o nome do ataque.
Consequentemente, os dados privados de centenas de desenvolvedores acabaram ficando à vista de todos e poderiam ser acessados não apenas pelos invasores, mas por absolutamente qualquer pessoa com uma conexão com a Internet.
Setembro de 2025: um stealer de criptomoedas ataca pacotes npm que têm 2,6 bilhões de downloads semanais
A tendência de comprometimentos de pacotes npm seguiu até setembro. Após uma nova campanha de phishing direcionada a desenvolvedores de JavaScript, os invasores conseguiram injetar código malicioso em algumas dezenas de projetos de alto nível. Alguns deles, especificamente “chalk” e “debug”, tiveram centenas de milhões de downloads semanais; coletivamente, os pacotes infectados estavam acumulando mais de 2,6 bilhões de downloads por semana no momento da violação, e eles se tornaram mais populares desde então.
A carga era um stealer de criptomoedas: um malware projetado para interceptar transações de criptomoeda e redirecioná-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ágio final da operação. No final, eles ficaram com míseros USD 925.
Apenas uma semana depois, outro grande incidente ocorreu: a primeira onda do malware autopropagável Shai-Hulud, que infectou cerca de 150 pacotes npm, incluindo projetos da CrowdStrike. No entanto, a segunda onda, que ocorreu vários meses depois, provou ser muito mais destrutiva. Vamos analisar o Great Worm em mais detalhes a seguir.
Outubro de 2025: o GlassWorm infecta o ecossistema do Visual Studio Code
Cerca de um mês após o ataque do Shai-Hulud, um malware autopropagável semelhante denominado GlassWorm começou a infectar extensões 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.
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ção de backup.
Além de esvaziar as carteiras de criptomoedas das vítimas e sequestrar suas contas para espalhar o worm ainda mais, os invasores também injetaram um RAT chamado Zombi nos dispositivos infectados, obtendo controle total sobre os sistemas comprometidos.
Novembro de 2025: a campanha IndonesianFoods e 150 mil pacotes de spam no npm
Em novembro, um novo incômodo emergiu do repositório do npm. Uma campanha maliciosa coordenada apelidada de IndonesianFoods fez os invasores inundarem o repositório com dezenas de milhares de pacotes inúteis.
O objetivo principal era jogar com o sistema para inflar as métricas e os tokens de farm no tea.xyz, uma plataforma de blockchain projetada para recompensar os desenvolvedores de código aberto. Para conseguir isso, os invasores construíram uma enorme rede de projetos interdependentes com nomes que fazem referência à culinária indonésia, como zul-tapai9-kyuki e andi-rendang23-breki.
Os criadores da campanha não se deram ao trabalho de invadir contas. Estritamente falando, os pacotes de spam nem sequer continham um contêiner malicioso, a menos que você considere um script projetado para gerar automaticamente novos contêineres a cada sete segundos. No entanto, o incidente serviu como um lembrete de como a infraestrutura npm é vulnerável a campanhas de spam em larga escala.
Dezembro de 2025: Shai-Hulud 2.0 e o vazamento de 400 mil segredos de desenvolvedores
O destaque absoluto do ano, não apenas de ataques a cadeias de suprimentos, mas provavelmente para todo o campo de segurança cibernética, foi o malware autopropagável Shai-Hulud (também conhecido como Sha1-Hulud) contra desenvolvedores.
Esse malware foi a evolução lógica do ataque s1ngularity mencionado anteriormente: ele também vasculhou os sistemas em busca de todos os tipos de segredos e os publicou em repositórios GitHub abertos. No entanto, o Shai-Hulud adicionou um mecanismo de autopropagação à linha de base: o worm infectou projetos controlados por desenvolvedores já comprometidos usando as credenciais roubadas.
A primeira onda do Shai-Hulud ocorreu em setembro, infectando várias centenas de pacotes npm. No final do ano, a segunda onda chegou e foi batizada como Shai-Hulud 2.0.
Dessa vez, o worm foi atualizado com a funcionalidade de wiper. Se o malware não encontrasse tokens npm ou GitHub válidos em um sistema infectado, ele acionava uma carga destrutiva que apagava os arquivos do usuários.
Aproximadamente 400 mil segredos 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órios públicos, onde poderiam ser baixados não apenas pelos invasores, mas por qualquer outra pessoa. E é altamente provável que as consequências desse ataque ainda sejam sentidas por um longo tempo.
Um dos primeiros casos confirmados de uma exploração usando segredos vazados pelo Shai-Hulud foi um roubo de criptomoeda visando vários milhares de usuários da Trust Wallet. Os invasores usaram esses segredos na véspera de Natal para carregar uma versão maliciosa da extensão Trust Wallet com um drenador de criptomoedas integrado para a Chrome Web Store. No final, eles conseguiram se safar com USD 8,5 milhões em criptomoedas.
Como se proteger contra ataques a cadeias de suprimentos
Ao elaborar uma retrospectiva semelhante para 2024, descobrimos que manter uma estrutura de “um mês, uma ameaça” é bastante fácil. Para 2025, no entanto, o caso foi muito mais grave. Houve tantos ataques maciços a cadeias de suprimentos no ano passado, que não conseguimos encaixá-los em uma visão geral.
O ano de 2026 está se mostrando igualmente intenso, por isso recomendamos verificar nossa postagem sobre a prevenção de ataques a cadeias de suprimentos. Enquanto isso, aqui estão as conclusões mais importantes:
Avalie minuciosamente seus fornecedores e faça uma auditoria cuidadosa do código que você integra em seus projetos.
Implemente requisitos de segurança rígidos diretamente em seus contratos de serviço.
Desenvolva um plano abrangente de resposta a incidentes.
Monitore atividades suspeitas em sua infraestrutura corporativa usando uma solução de XDR.
Se quiser saber mais detalhes sobre os ataques a cadeias de suprimentos, confira o nosso relatório analítico Supply chain reaction: securing the global digital ecosystem in an age of interdependence (Reação em cadeia de suprimentos: proteção ao ecossistema digital global em uma era de interdependência). Ele se baseia em insights de especialistas técnicos e revela com que frequência as organizações enfrentam riscos relacionados à cadeia de suprimentos e a relações de confiança, onde ainda existem lacunas de proteção e quais estratégias adotar para aumentar a resiliência contra esse tipo de ameaça.
O que as palavras bakso, sate e rendang trazem à mente? Para muitos, a resposta é “nada”; os amantes da gastronomia as reconhecerão como alimentos básicos da Indonésia. Já aqueles que seguem as notícias de segurança cibernética se lembrarão de um ataque ao ecossistema Node Package Manager (npm), a ferramenta que permite que os desenvolvedores usem bibliotecas pré-formatadas em vez de escrever cada linha de código do zero.
Em meados de novembro, o pesquisador de segurança Paul McCarty relatou a descoberta de uma campanha de spam destinada a sobrecarregar o repositório do npm. É claro que pacotes sem sentido já apareceram no repositório antes, mas, neste caso, dezenas de milhares de módulos foram encontrados sem nenhuma utilidade. O único objetivo deles era injetar dependências completamente desnecessárias em projetos.
Os nomes dos pacotes apresentavam nomes de pratos indonésios e termos culinários inseridos de forma aleatória, como bakso, sate e rendang, o que levou a campanha a receber o apelido “IndonesianFoods”. A escala foi impressionante: no momento da descoberta, aproximadamente 86 mil pacotes haviam sido identificados.
Abaixo, veremos como isso aconteceu e o que os invasores estavam realmente procurando.
Dentro da IndonesianFoods
À primeira vista, os pacotes da IndonesianFoods não pareciam lixo óbvio. Eles apresentavam estruturas padrão, arquivos de configuração válidos e até mesmo documentação bem formatada. De acordo com pesquisadores do Endor Labs, essa camuflagem permitiu que os pacotes permanecessem no repositório do npm por quase dois anos.
Não é como se os invasores tentassem a todo custo inserir suas criações em projetos externos. Em vez disso, eles simplesmente inundaram o ecossistema com um código de aparência legítima, esperando que alguém cometesse um erro de digitação ou selecionasse por engano sua biblioteca nos resultados da pesquisa. Não está claro exatamente o que alguém precisaria estar procurando para confundir um nome de pacote com um prato indonésio, mas a pesquisa original observa que pelo menos 11 projetos de alguma forma incluíram esses pacotes em suas compilações.
Uma pequena parte desses pacotes inúteis tinha um mecanismo de autorreplicação incorporado: uma vez instalados, eles criariam e publicariam novos pacotes no repositório do npm a cada sete segundos. Esses novos módulos apresentavam nomes aleatórios (também relacionados à culinária indonésia) e números de versão. Todos publicados, como seria de esperar, usando as credenciais da vítima.
Outros pacotes maliciosos integrados à plataforma blockchain TEA. O projeto TEA foi concebido para recompensar criadores de código aberto com tokens em proporção à popularidade e ao uso de suas criações, teoricamente operando em um modelo de “prova de contribuição”.
Uma parte significativa desses pacotes não continha funcionalidade real, mas muitas vezes carregavam uma dúzia de dependências que, como você pode imaginar, apontavam para outros projetos de spam dentro da mesma campanha. Assim, se uma vítima incluir por engano um desses pacotes maliciosos, ele carregará consigo diversos outros, alguns dos quais terão suas próprias dependências. O resultado é um projeto final com uma enorme quantidade de código redundante.
O que os invasores ganham com isso?
Há duas teorias principais. O mais óbvio é que toda essa elaborada campanha de spam foi projetada para explorar o protocolo TEA mencionado acima. Essencialmente, sem fazer nenhuma contribuição útil para a comunidade de código aberto, os invasores ganham tokens TEA, ou seja, ativos digitais padrão que podem ser trocados por outras criptomoedas em plataformas de negociação. Usando uma rede de dependências e mecanismos de autorreplicação, os invasores se passam por desenvolvedores de código aberto legítimos para inflar artificialmente a significância e as métricas de uso de seus pacotes. Nos arquivos README de determinados pacotes, os invasores até se gabam de seus ganhos.
No entanto, há uma teoria mais assustadora. Por exemplo, o pesquisador Garrett Calpouzos sugere que o que estamos vendo é apenas uma prova de conceito. A campanha da IndonesianFoods pode estar testando um novo método de entrega de malware destinado a ser vendido posteriormente a outros agentes de ameaças.
Por que você não quer lixo em seus projetos
À primeira vista, o perigo para as organizações de desenvolvimento de software pode não ser óbvio: com certeza, a IndonesianFoods desordena o ecossistema, mas não parece carregar uma ameaça imediata, como ransomware ou violações de dados. No entanto, as dependências redundantes sobrecarregam o código e desperdiçam recursos no sistema do desenvolvedor. Além disso, pacotes inúteis publicados sob o nome de sua organização podem prejudicar seriamente sua reputação dentro da comunidade de desenvolvedores.
Também não podemos descartar a teoria de Calpouzos. Se esses pacotes de spam incorporados ao seu software receberem uma atualização que introduza uma funcionalidade realmente maliciosa, eles podem se tornar uma ameaça não apenas para a sua organização, mas também para seus usuários, evoluindo para um ataque completo à cadeia de suprimentos.
Como proteger sua organização
Os pacotes de spam não entram em um projeto sozinhos; sua instalação ocorre em um momento de distração do desenvolvedor. Portanto, recomendamos conscientizar regularmente os funcionários, mesmo os mais experientes, sobre as ameaças cibernéticas modernas. Nossa plataforma interativa de treinamento, a KASAP (Kaspersky Automated Security Awareness Platform), pode ajudar.
Além disso, você pode impedir a infecção usando uma solução especializada para proteger ambientes conteinerizados. Ela faz a verificação de imagens e dependências de terceiros, integra-se ao processo de compilação e monitora contêineres durante o tempo de execução.
Se quiser saber mais detalhes sobre os ataques contra a cadeia de suprimentos, deixamos aqui o nosso convite para consultar o relatório analítico Supply chain reaction: securing the global digital ecosystem in an age of interdependence (Reação em cadeia de suprimentos: proteção do ecossistema digital global em uma era de interdependência). Ele é baseado em insights de especialistas técnicos e revela com que frequência as organizações enfrentam riscos de cadeia de suprimentos e de relacionamento confiável e como estes são percebidos.
Preparing for an Initial Public Offering (IPO) is a significant phase that requires careful planning across financial, legal, and operational areas. However, one critical factor that is often underestimated is cybersecurity. In the IPO journey, companies handle highly sensitive financial data, intellectual property, and regulatory disclosures, making them prime targets for cyber threats. A weak […]
Major AI labs are investigating a security incident that impacted Mercor, a leading data vendor. The incident could have exposed key data about how they train AI models.
Entrar
