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 a sua equipe de segurança interna estiver sobrecarregada, procure um serviço externo de identificação proativa de ameaças e resposta rápida.

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.

Para implementar programas eficazes de cibersegurança e manter a equipe de segurança profundamente integrada a todos os processos de negócios, o CISO precisa demonstrar regularmente o valor desse trabalho para a alta administração. Isso requer fluência na linguagem dos negócios, porém, uma armadilha perigosa espreita os mais desavisados.  Profissionais de segurança e executivos geralmente usam as mesmas palavras, mas para coisas totalmente diferentes. Às vezes, vários termos semelhantes são usados de forma intercambiável. Assim, talvez não fique muito claro para a alta administração quais são as ameaças que a equipe de segurança está tentando mitigar, qual é o nível real de ciber-resiliência da empresa ou onde o orçamento e os recursos estão sendo alocados. Portanto, antes de apresentar painéis elegantes ou calcular o ROI dos programas de segurança, vale a pena esclarecer essas importantes nuances terminológicas.

Ao esclarecer esses termos e construir um vocabulário compartilhado, o CISO e o conselho de administração podem melhorar significativamente a comunicação e, em última análise, fortalecer a postura de segurança geral da organização.

Por que o vocabulário de cibersegurança é importante para a gestão

As interpretações variadas dos termos representam mais do que uma simples inconveniência, e as consequências podem ser bastante significativas. A falta de clareza em relação aos detalhes pode levar a:

• Investimentos mal alocados. A administração pode aprovar a compra de uma solução de confiança zero sem perceber que, na prática, isso é apenas parte de um programa mais abrangente, de longo prazo e com um orçamento significativamente maior. O dinheiro é gasto, mas os resultados esperados pela equipe gestora nunca são alcançados. Da mesma forma, em relação à migração para a nuvem, a equipe gestora pode supor, num primeiro momento, que essa solução transfere automaticamente toda a responsabilidade de segurança ao provedor e, então, num segundo momento, o orçamento de segurança da nuvem é rejeitado.
• Aceitação cega do risco. As lideranças das unidades de negócios podem aceitar os riscos de cibersegurança sem ter uma compreensão completa do impacto potencial.
• Falta de governança. Sem entender a terminologia, a administração não pode fazer as perguntas certas, ou mesmo as mais difíceis, ou ainda, atribuir as áreas de responsabilidade de forma eficaz. Quando ocorre um incidente, muitas vezes os proprietários de negócios acreditam que a segurança estava inteiramente sob responsabilidade do CISO, enquanto o CISO, na verdade, não tinha autoridade para influenciar os processos de negócios.

Ciber-risco x risco de TI

Muitos executivos acreditam que a cibersegurança é uma questão puramente técnica que pode ser repassada à equipe de TI. Embora a importância da cibersegurança para os negócios seja indiscutível e os incidentes cibernéticos tenham sido classificados como um dos principais riscos para os negócios, pesquisas mostram que muitas organizações ainda não conseguem envolver as lideranças sem perfil técnico nas discussões sobre cibersegurança.

Os riscos de segurança da informação geralmente são tratados de maneira conjunta com as preocupações de TI, como tempo de atividade e disponibilidade do serviço.  Na realidade, o ciber-risco é um risco estratégico de negócios, ligado à continuidade, às perdas financeiras e aos danos à reputação.

Por outro lado, os riscos de TI geralmente são de natureza operacional, afetando a eficiência, a confiabilidade e o gerenciamento de custos. Em linhas gerais, a resposta a incidentes de TI é tratada inteiramente pela equipe de TI. Os principais incidentes de cibersegurança, no entanto, têm um escopo muito mais amplo: exigem o envolvimento de quase todos os departamentos e têm um impacto de longo prazo na organização sob vários aspectos, inclusive no que diz respeito à reputação, conformidade regulatória, relacionamento com o cliente e saúde financeira geral.

Conformidade x segurança

A cibersegurança está integrada aos requisitos regulatórios em todos os níveis, isto é, desde as diretivas internacionais, como NIS2 e GDPR, até as diretrizes do setor para transferência de dados além das fronteiras, como PCI DSS, além de imposições departamentais específicas. Assim, a equipe gestora da empresa geralmente percebe as medidas de cibersegurança como caixas de seleção de conformidade, acreditando que, uma vez que os requisitos regulatórios sejam atendidos, os problemas de cibersegurança poderão ser considerados resolvidos. Essa mentalidade pode ser fruto de um esforço consciente para minimizar os gastos com segurança (a administração acredita que não precisa fazer mais do que o necessário) ou advir de um mal-entendido sincero (a empresa está passando por uma auditoria ISO 27001, por isso não acredita que haja possibilidade de ser hackeada).

Na realidade, a conformidade está atendendo aos requisitos mínimos de auditores e reguladores governamentais em um momento específico. Infelizmente, o histórico de ciberataques em larga escala em grandes organizações prova que os requisitos “mínimos” são chamados assim por um motivo. Para uma proteção real contra ciberameaças modernas, as empresas devem melhorar continuamente suas estratégias e medidas de segurança de acordo com as necessidades específicas de um determinado setor.

Ameaça, vulnerabilidade e risco

Esses três termos são frequentemente usados como sinônimos, o que leva a conclusões errôneas feitas pela equipe gestora. Eis o raciocínio: “Há uma vulnerabilidade crítica no nosso servidor? Isso significa que se trata de um risco crítico!” Para evitar o pânico ou, inversamente, a inércia, é essencial usar esses termos com precisão e entender como eles se relacionam entre si.

Uma vulnerabilidade é uma fraqueza, ou seja, uma “porta aberta”. Isso significa que pode haver uma falha no código do software, um servidor configurado incorretamente, uma sala de servidores desbloqueada ou um funcionário que abre todos os anexos de e-mail.

Uma ameaça é algo que pode causar um incidente. A causa pode ser um agente malicioso, um malware ou até mesmo um desastre natural. Uma ameaça é o fator que pode “atravessar aquela porta aberta”.

O risco é a possível perda. É a avaliação cumulativa da probabilidade de um ataque bem-sucedido e o que a organização pode perder como resultado disso (o impacto).

As conexões entre esses elementos são melhor explicadas por meio de uma fórmula simples:

Risco = (ameaça × vulnerabilidade) × impacto

Isso pode ser ilustrado da seguinte forma. Imagine que uma vulnerabilidade crítica com uma classificação de gravidade máxima seja descoberta em um sistema desatualizado. No entanto, esse sistema está desconectado de todas as redes, fica em uma sala isolada e está sendo gerenciado por apenas três profissionais competentes. A probabilidade de um invasor alcançar o sistema é próxima de zero. Por outro lado, a falta de autenticação de dois fatores nos sistemas de contabilidade cria um risco real e elevado, resultante de uma alta probabilidade de ataque e de um possível dano significativo.

Resposta a incidentes, recuperação de desastres e continuidade dos negócios

A percepção da equipe gestora sobre as crises de segurança muitas vezes é simplista. Eis o raciocínio: “Se formos atingidos por um ransomware, bastará ativar o plano de recuperação de desastres de TI e fazer a restauração por meio do backup”. No entanto, combinar esses conceitos e também os processos é extremamente perigoso.

A resposta a incidentes (IR) é de responsabilidade da equipe de segurança ou de contratados especializados. O trabalho dessas equipes é localizar a ameaça, expulsar o invasor da rede e impedir que o ataque se espalhe.

A recuperação de desastres (DR) é uma tarefa de engenharia de TI. É o processo de restauração de servidores e dados de backups após a conclusão da resposta ao incidente.

A continuidade dos negócios (BC) é uma tarefa estratégica para a alta administração. Ela consiste em um plano, ou seja, a maneira como a empresa continuará atendendo clientes, enviando mercadorias, pagando compensações e mantendo o diálogo com a imprensa enquanto os sistemas principais ainda estiverem off-line.

Se a equipe gestora se concentrar apenas na recuperação, a empresa não terá um plano de ação para o período mais crítico de tempo de inatividade.

Conscientização sobre segurança x cultura de segurança

As lideranças em todos os níveis supõem algumas vezes que a simples realização de treinamentos de segurança garante resultados. Eis o raciocínio: “Os funcionários passaram no teste anual, então, agora, eles não clicarão em um link de phishing”. Infelizmente, contar apenas com treinamentos organizados pelas equipes de RH e de TI não será o suficiente. A eficácia requer a mudança de comportamento da equipe, o que é impossível sem o envolvimento da equipe gestora do negócio.

Conscientização é conhecimento. Um profissional sabe o que é phishing e entende a importância de senhas complexas.

A cultura de segurança tem a ver com padrões comportamentais. É aquilo que um funcionário faz em uma situação estressante ou quando ninguém está olhando. A cultura não é moldada por testes, mas por um ambiente onde o relato de erros é seguro, e a identificação e a prevenção de situações possivelmente perigosas são práticas comuns. Se um profissional teme a punição, ele ocultará um incidente. Em uma cultura saudável, um e-mail suspeito será encaminhado para o SOC, ou ainda, alguém que esquece de bloquear o computador receberá um toque do colega, o que acaba gerando um vínculo ativo na cadeia de defesa.

Detecção x prevenção

As lideranças empresariais muitas vezes pensam de forma ultrapassada, como uma “muralha da fortaleza”: “Compramos sistemas de proteção caros, portanto, não deve haver nenhuma maneira de sermos hackeados. Se ocorrer um incidente, isso significa que o CISO falhou”. Na prática, impedir 100% dos ataques é tecnicamente impossível e inviável do ponto de vista econômico. A estratégia moderna é construída sobre um equilíbrio entre a cibersegurança e a eficácia dos negócios. Em um sistema equilibrado, os componentes focados na detecção e prevenção de ameaças funcionam em conjunto.

A prevenção desvia ataques automatizados em massa.

O Detection and Response ajuda a identificar e neutralizar ataques mais profissionais e direcionados que conseguem contornar as ferramentas de prevenção ou explorar vulnerabilidades.

Atualmente, o principal objetivo da equipe de cibersegurança não é garantir a invulnerabilidade total, mas detectar um ataque em um estágio inicial e minimizar o impacto nos negócios. Para mensurar o sucesso aqui, o setor normalmente usa métricas, como tempo médio de detecção (MTTD) e tempo médio de resposta (MTTR).

Filosofia de confiança zero x produtos de confiança zero

O conceito de confiança zero, que implica “nunca confiar, sempre verificar” para todos os componentes da infraestrutura de TI, há muito tempo é reconhecido como relevante e eficaz para a segurança corporativa. Ele requer a verificação constante de identidade (contas de usuário, dispositivos e serviços) e contexto para cada solicitação de acesso de acordo com a suposição de que a rede já foi comprometida.

No entanto, a presença de “confiança zero” no nome de uma solução de segurança não significa que uma organização pode adotar essa abordagem da noite para o dia simplesmente comprando o produto.
A confiança zero não é um produto que se pode “ativar”, mas sim uma estratégia arquitetônica e uma jornada de transformação de longo prazo. A implementação da confiança zero requer a reestruturação dos processos de acesso e o refinamento dos sistemas de TI para garantir a verificação contínua da identidade e dos dispositivos. Comprar software sem alterar os processos não terá um efeito significativo.

Segurança da nuvem x segurança na nuvem

Ao migrar os serviços de TI para a infraestrutura em nuvem, como AWS ou Azure, muitas vezes existe a ilusão de que ocorrerá uma transferência de risco total. Eis o raciocínio: “Pagamos ao provedor, então, agora, a segurança será uma dor de cabeça para eles”. Esse raciocínio é equivocado e perigoso, pois se trata de uma interpretação errônea daquilo que é conhecido como o Modelo de responsabilidade compartilhada.

A segurança da nuvem é responsabilidade do provedor. Ele protege os data centers, os servidores físicos e o cabeamento.

A segurança na nuvem é responsabilidade do cliente.

As discussões sobre orçamentos para projetos em nuvem e seus aspectos de segurança devem ser acompanhadas por exemplos da vida real. O provedor protege o banco de dados contra acesso não autorizado de acordo com as configurações feitas pelos funcionários do cliente. Se os funcionários deixarem um banco de dados aberto ou usarem senhas fracas, ou ainda, se a autenticação de dois fatores não estiver ativada para o painel do administrador, o provedor não poderá impedir que indivíduos não autorizados baixem as informações: um tipo de notícia muito comum. Portanto, o orçamento para esses projetos deve levar em conta as ferramentas de segurança em nuvem e o gerenciamento de configuração feito pela empresa.

Verificação de vulnerabilidades x teste de penetração

As lideranças geralmente confundem as verificações automatizadas, que se enquadram na higiene cibernética, com a avaliação de ativos de TI quanto à resiliência contra ataques sofisticados. Eis o raciocínio: “Por que pagar aos hackers por um teste de penetração quando executamos o verificador toda semana?”

A verificação de vulnerabilidades analisa uma lista específica de ativos de TI com o objetivo de encontrar vulnerabilidades conhecidas. Para simplificar, é como se um segurança estivesse fazendo a ronda para verificar se as janelas e portas do escritório estão trancadas.

O teste de penetração (pentesting) é uma avaliação manual para avaliar a possibilidade de uma violação no mundo real, explorando vulnerabilidades. Para continuar a analogia, é como contratar um ladrão experiente para tentar invadir o escritório.

Um não substitui o outro, e para entender sua verdadeira postura de segurança, uma empresa precisa das duas ferramentas.

Ativos gerenciados x superfície de ataque

Um equívoco comum e perigoso diz respeito ao escopo da proteção e à visibilidade geral mantida pelas equipes de TI e de segurança. Eis um chavão comum nas reuniões: “A lista de inventário do nosso hardware é precisa. Estamos protegendo tudo o que possuímos”.

Os ativos gerenciados de TI são os itens que o departamento de TI comprou, configurou e consegue visualizar em seus relatórios.

Uma superfície de ataque é qualquer coisa acessível aos invasores: qualquer possível ponto de entrada na empresa. Isso inclui Shadow IT (serviços em nuvem, aplicativos de mensagens pessoais, servidores de teste, etc.), que, basicamente, é qualquer método que os funcionários usam para burlar os protocolos oficiais a fim de acelerar ou simplificar o trabalho. Muitas vezes, são esses os ativos “invisíveis” que se tornam o ponto de entrada para um ataque, pois a equipe de segurança não pode proteger aquilo que desconhece.

Invasores frequentemente exploram contas de teste desatualizadas e sem uso ou acabam encontrando armazenamentos em nuvem acessíveis publicamente que contêm dados críticos, já um pouco “empoeirados”. Em alguns casos, um ataque explora uma vulnerabilidade em um componente de aplicativo que, na verdade, havia recebido um patch, digamos, há dois anos. Ao ler relatórios de violações de segurança, um padrão comum se repete: os ataques se apoiam em algo desatualizado: um serviço, um servidor, uma conta de usuário… Elementos da infraestrutura corporativa de TI que, por vezes, saem do radar das equipes de TI e de segurança. Na prática, tornam-se ativos não gerenciados, inúteis ou simplesmente esquecidos. Esses “zumbis da TI” geram riscos à segurança da informação, à conformidade regulatória e resultam em custos operacionais desnecessários. Em geral, trata-se de um elemento da TI invisível com uma diferença fundamental: ninguém quer, conhece ou se beneficia desses ativos.

Neste artigo, buscamos identificar quais ativos exigem atenção imediata, como reconhecê-los e como deve ser estruturada a resposta.

Servidores físicos e virtuais

Prioridade: alta. Servidores vulneráveis funcionam como pontos de entrada para ataques cibernéticos e continuam consumindo recursos, ao mesmo tempo que geram riscos de conformidade regulatória.

Prevalência: alta. Servidores físicos e virtuais costumam ficar órfãos em grandes infraestruturas após projetos de migração ou depois de processos de fusões e aquisições. Servidores de teste que deixam de ser usados após a entrada em produção de projetos de TI, assim como servidores Web de projetos obsoletos operando sem domínio associado, também são frequentemente esquecidos. A dimensão do problema é ilustrada por estatísticas da autoridade certificadora Let’s Encrypt: em 2024, metade das solicitações de renovação de domínio partiu de dispositivos que já não estavam associados ao domínio solicitado. Estima-se que existam cerca de um milhão de dispositivos como esses no mundo.

Detecção: o departamento de TI precisa implementar um processo automatizado de Descoberta e Reconciliação (Automated Discovery and Reconciliation – AD&R), que combine resultados de varreduras de rede e inventários em nuvem com dados da Base de Dados de Gerenciamento de Configuração (Configuration Management Database – CMDB). Esse processo permite a identificação oportuna de informações desatualizadas ou conflitantes sobre ativos de TI e ajuda a localizar os próprios ativos esquecidos.

Esses dados devem ser complementados por verificações de vulnerabilidades externas que abranjam todos os endereços IP públicos da organização.

Resposta: estabelecer um processo formal e documentado para a retirada de operação ou descontinuação de servidores. Esse processo deve incluir a verificação da migração completa dos dados e a posterior destruição comprovada das informações armazenadas no servidor. Após essas etapas, o servidor pode ser desligado, reciclado ou reaproveitado. Até que todos os procedimentos sejam concluídos, o servidor deve ser movido para uma sub-rede isolada e em quarentena.

Para mitigar esse problema em ambientes de teste, implemente um processo automatizado para sua criação e retirada de operação. Um ambiente de teste deve ser criado no início de um projeto e desmontado após um período predefinido ou depois de um certo tempo de inatividade. Reforce a segurança dos ambientes de teste, garantindo seu isolamento rigoroso em relação ao ambiente principal (de produção) e proibindo o uso de dados reais de negócios não anonimizado nos testes.

Contas de usuários, serviços e dispositivos esquecidos

Prioridade: crítica. Contas inativas e com privilégios elevados são alvos preferenciais de invasores que buscam estabelecer persistência na rede ou ampliar seu acesso dentro da infraestrutura.

Prevalência: muito alta. Contas técnicas de serviços, contas de prestadores de serviço e contas não personalizadas estão entre as mais frequentemente esquecidas.

Detecção: realizar análises regulares do diretório de usuários (Active Directory, na maioria das organizações) para identificar todos os tipos de contas que não apresentaram atividade por um período definido (um mês, um trimestre ou um ano). Paralelamente, recomenda-se revisar as permissões atribuídas a cada conta e remover aquelas excessivas ou desnecessárias.

Resposta: após validação com o responsável pelo serviço na área de negócio ou com o gestor do colaborador, contas desatualizadas devem ser simplesmente desativadas ou excluídas. Um sistema abrangente de Identity and Access Management (IAM) oferece uma solução escalável para esse desafio. Nesse modelo, a criação, exclusão e atribuição de permissões às contas são fortemente integradas aos processos de RH.

No caso de contas de serviço, também é essencial revisar regularmente tanto a robustez das senhas quanto as datas de expiração dos tokens de acesso, realizando a rotação quando necessário.

Repositórios de dados esquecidos

Prioridade: crítica. Dados mal controlados em bancos de dados acessíveis externamente, armazenamentos em nuvem e lixeiras, bem como em serviços corporativos de compartilhamento de arquivos, inclusive os considerados “seguros”, foram uma das principais fontes de grandes vazamentos em 2024–2025. Os dados expostos nesses incidentes frequentemente incluem digitalizações de documentos, prontuários médicos e informações pessoais. Como consequência, esses incidentes de segurança também resultam em penalidades por não conformidade com regulamentações como a HIPAA, o GDPR e outros marcos de proteção de dados que regem o tratamento de informações pessoais e confidenciais.

Prevalência: alta. Dados de arquivo, cópias de dados mantidas por prestadores de serviço e versões legadas de bancos de dados de migrações de sistemas anteriores costumam permanecer fora de controle e acessíveis por anos, ou até décadas, em muitas organizações.

Detecção: dada a enorme variedade de tipos de dados e métodos de armazenamento, é essencial utilizar uma combinação de ferramentas para a descoberta:

• Subsistemas nativos de auditoria das principais plataformas de fornecedores, como AWS Macie e Microsoft Purview
• Soluções especializadas de Data Discovery e de Gerenciamento da Postura de Segurança de Dados
• Análise automatizada de logs de inventário, como o S3 Inventory

Infelizmente, essas ferramentas têm utilidade limitada quando um prestador de serviços cria um repositório de dados dentro de sua própria infraestrutura. O controle dessa situação exige cláusulas contratuais que concedam à equipe de segurança da organização acesso aos armazenamentos relevantes do fornecedor, complementadas por serviços de inteligência de ameaças capazes de detectar conjuntos de dados expostos publicamente ou roubados associados à marca da empresa.

Resposta: analisar os logs de acesso e integrar os armazenamentos identificados às ferramentas de DLP e CASB para monitorar seu uso, ou confirmar que estão de fato abandonados. Utilizar os recursos disponíveis para isolar com segurança o acesso a esses repositórios. Se necessário, criar um backup seguro e, em seguida, excluir os dados. No nível das políticas organizacionais, é fundamental estabelecer prazos de retenção para diferentes tipos de dados, determinando seu arquivamento automático e exclusão ao término do período definido. As políticas também devem definir procedimentos para o registro de novos sistemas de armazenamento e proibir explicitamente a existência de dados sem responsável que estejam acessíveis sem restrições, senhas ou criptografia.

Aplicativos e serviços não utilizados em servidores

Prioridade: média. Vulnerabilidades nesses serviços aumentam o risco de ataques cibernéticos bem-sucedidos, dificultam os esforços de aplicação de patches e desperdiçam recursos.

Prevalência: muito alta. Os serviços geralmente são ativados por padrão durante a instalação de servidores, permanecem após os testes e as etapas de configuração, continuam em execução muito tempo depois que o processo de negócios que eles apoiavam ter se tornado obsoleto.

Detecção: por meio de auditorias regulares das configurações de software. Para que a auditoria seja eficaz, os servidores devem seguir um modelo baseado em funções, no qual cada função de servidor tenha uma lista correspondente de softwares. Além da CMDB, um amplo conjunto de ferramentas auxilia nesse processo, como ferramentas focadas em conformidade de políticas e endurecimento de sistemas, a exemplo do OpenSCAP e do Lynis; ferramentas multifuncionais como o OSQuery; scanners de vulnerabilidades como o OpenVAS; e analisadores de tráfego de rede.

Resposta: realizar revisões periódicas das funções dos servidores em conjunto com seus responsáveis de negócio. Quaisquer aplicações ou serviços desnecessários identificados em execução devem ser desativados. Para minimizar esse tipo de ocorrência, implemente o princípio do menor privilégio em toda a organização e utilize imagens base endurecidas ou templates de servidores para construções padrão. Isso garante que nenhum software supérfluo seja instalado ou habilitado por padrão.

APIs desatualizadas

Prioridade: alta. APIs são frequentemente exploradas por invasores para exfiltrar grandes volumes de dados sensíveis e para obter acesso inicial à organização. Em 2024, o número de ataques relacionados a APIs aumentou 41%, com invasores mirando especificamente APIs desatualizadas, já que elas costumam disponibilizar dados com menos verificações e restrições. Um exemplo disso foi o vazamento de 200 milhões de registros do X/Twitter.

Prevalência: alta. Quando um serviço migra para uma nova versão de API, a versão antiga frequentemente permanece operacional por um longo período, sobretudo se ainda for utilizada por clientes ou parceiros. Essas versões obsoletas geralmente deixam de ser mantidas, o que faz com que falhas de segurança e vulnerabilidades em seus componentes não recebam patches.

Detecção: no nível de WAF ou NGFW, é essencial monitorar o tráfego direcionado a APIs específicas. Isso ajuda a detectar anomalias que podem indicar exploração ou exfiltração de dados e também identificar APIs que obtêm tráfego mínimo.

Resposta: para APIs identificadas com baixo nível de atividade, colaborar com as partes interessadas do negócio para desenvolver um plano de retirada de operação e migrar os usuários remanescentes para versões mais recentes.

Em organizações com um grande portfólio de serviços, esse desafio é melhor enfrentado com o uso de uma plataforma de gerenciamento de APIs, aliada a uma política formalmente aprovada de ciclo de vida de APIs. Essa política deve incluir critérios bem definidos para a descontinuação e aposentadoria de interfaces de software desatualizadas.

Software com dependências e bibliotecas desatualizadas

Prioridade: alta. É nesse ponto que se escondem vulnerabilidades críticas de grande escala, como a Log4Shell, capazes de comprometer toda a organização e gerar problemas de conformidade regulatória.

Prevalência: muito alta, especialmente em sistemas corporativos de gestão em larga escala, sistemas de automação industrial e softwares desenvolvidos sob medida.

Detecção: utilizar uma combinação de sistemas de gerenciamento de vulnerabilidades (VM/CTEM) e ferramentas de análise de composição de software (SCA). No desenvolvimento interno, é obrigatório empregar scanners e sistemas de segurança abrangentes integrados ao pipeline de CI/CD, a fim de evitar que o software seja construído com componentes desatualizados.

Resposta: as políticas da empresa devem exigir que as equipes de TI e de desenvolvimento atualizem sistematicamente as dependências de software. No desenvolvimento de soluções internas, a análise de dependências deve fazer parte do processo de revisão de código. No caso de softwares de terceiros, é fundamental auditar regularmente o estado e a antiguidade das dependências.

Para fornecedores externos de software, a atualização de dependências deve ser um requisito contratual, com impacto direto nos prazos de suporte e nos orçamentos dos projetos. Para viabilizar essas exigências, é essencial manter uma lista de materiais de software (SBOM) sempre atualizada.

Você pode ler mais sobre práticas de remediação de vulnerabilidades eficazes e oportunas em um post separado no blog.

Sites esquecidos

Prioridade: média. Ativos Web esquecidos podem ser explorados por invasores para campanhas de phishing, hospedagem de malware ou aplicação de golpes usando a marca da organização, causando danos reputacionais. Em casos mais graves, podem resultar em vazamentos de dados ou servir como ponto de partida para ataques direcionados à própria empresa. Um subconjunto específico desse problema envolve domínios esquecidos que foram usados para atividades pontuais, expiraram e não foram renovados, tornando-se disponíveis para compra por terceiros.

Prevalência: alta, especialmente no caso de sites lançados para campanhas de curta duração ou atividades internas pontuais.

Detecção: o departamento de TI deve manter um registro centralizado de todos os sites públicos e domínios, validando o status de cada um junto aos respectivos responsáveis em base mensal ou trimestral. Além disso, scanners ou ferramentas de monitoramento de DNS podem ser utilizados para rastrear domínios associados à infraestrutura de TI da empresa. Uma camada adicional de proteção é oferecida por serviços de inteligência de ameaças, capazes de identificar de forma independente quaisquer sites associados à marca da organização.

Resposta: estabelecer uma política de desligamento programado de sites após um período fixo ao término de seu uso ativo. Implementar um sistema automatizado de registro e renovação de DNS para evitar a perda de controle sobre os domínios da empresa.

Dispositivos de rede não utilizados

Prioridade: alta. Roteadores, firewalls, câmeras de vigilância e dispositivos de armazenamento em rede que permanecem conectados, mas sem gerenciamento e sem patches aplicados, constituem uma plataforma ideal para o lançamento de ataques. Esses dispositivos esquecidos frequentemente abrigam vulnerabilidades e quase nunca contam com monitoramento adequado (não há integração com EDR ou SIEM), ao mesmo tempo em que ocupam uma posição privilegiada na rede, oferecendo aos invasores um caminho facilitado para escalar ataques contra servidores e estações de trabalho.

Prevalência: média. Dispositivos costumam ser deixados para trás durante mudanças de escritório, atualizações da infraestrutura de rede ou a criação de espaços de trabalho temporários.

Detecção: utilizar as mesmas ferramentas de inventário de rede mencionadas na seção sobre servidores esquecidos, além de auditorias físicas regulares para comparar os resultados das verificações de rede com os equipamentos efetivamente conectados. A verificação ativa da rede pode revelar segmentos inteiros não mapeados e conexões externas inesperadas.

Resposta: dispositivos sem responsável definido geralmente podem ser desconectados da rede de forma imediata. No entanto, é preciso cautela: a higienização desses equipamentos exige o mesmo nível de cuidado aplicado à desativação de servidores, a fim de evitar vazamentos de configurações de rede, senhas, gravações de vídeo corporativas e informações semelhantes.

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.
• Implemente um sistema de segurança abrangente dentro da organização, incluindo a instalação de EDR em todos os computadores e servidores, um firewall moderno e monitoramento de rede abrangente baseado em um Sistema SIEM.

Fonte

Fonte

Fonte

Fonte

Fonte

Fonte