Recentemente recebemos um report de um cliente onde havia recebido um e-mail originado da Polícia Civil do Amapá.
O remetente referência uma pessoa chamda Nashya Ribeiro com o e-mail: nashyaribeiro@policiacivil[.]ap[.]gov[.]br.
O e-mail gera urgência determinando um prazo de 1 dia informando que os detalhes da solicitação se encontram no PDF
Passando por uma pesquisa rápida o domínio policiacivil[.]ap[.]gov[.]br é realmente utilizado pela ´Polícia Civil do Amapa – hxxps[://]policiacivil[.]portal[.]ap[.]gov[.]br/pagina/unidades-policiais/especializadas
Dentro do PDF tem um link no botão instalar certificado que aponta para um endereço que atualmente quando acessado, já se apresenta fora do ar. hxxps[://]195[.]177[.]94[.]193/[.]certificados[.]ap[.]gov[.]br
O link estava hospedado em um datacenter localizado nos Estados Unidos denominado STELLARGROUP aparentemente de origem Ucraniana.
Identificamos através de fontes externas que a campanha ainda continua ativa seguindo o mesmo padrão de e-mails e anexos.
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.
Em 4 de dezembro de 2025, a Cybersecurity and Infrastructure Security Agency (CISA), a National Security Agency (NSA) e o Canadian Centre for Cyber Security publicaram um comunicado conjunto alertando sobre uma nova e altamente sofisticada campanha de malware denominada BRICKSTORM.
Mais do que um backdoor convencional, o BRICKSTORM representa uma ameaça sistêmica a ambientes de virtualização, infraestrutura de identidade e operações corporativas críticas, explorando exatamente os pontos onde a visibilidade de segurança costuma ser limitada ou inexistente.
O relatório técnico AR25-338A, atualizado em 19 de dezembro de 2025, descreve em detalhes as capacidades avançadas do malware e disponibiliza indicadores de comprometimento destinados a apoiar equipes de defesa. Investigações conduzidas em resposta a incidentes revelam um dado alarmante, o tempo médio de permanência não detectada nos ambientes comprometidos chega a 393 dias, evidenciando o nível de evasão operacional alcançado pelos atores responsáveis.
A campanha é atribuída a atores patrocinados pelo Estado da República Popular da China, com foco em acesso persistente, coleta de credenciais privilegiadas e exploração silenciosa de infraestruturas críticas.
1. Visão Geral Técnica
O BRICKSTORM é um backdoor modular desenvolvido para ambientes VMware vSphere, incluindo vCenter e ESXi, além de sistemas Windows. Até o momento, foram identificadas pelo menos oito amostras distintas, coletadas a partir de ambientes reais de vítimas, incluindo organizações atendidas diretamente pela CISA em operações de resposta a incidentes.
O malware foi desenvolvido em linguagem Go, uma escolha arquitetural estratégica que permite portabilidade entre plataformas Linux, BSD e Windows. Esse fator é especialmente relevante porque possibilita a implantação do BRICKSTORM em appliances de perímetro e componentes de infraestrutura que normalmente não contam com EDRs ou agentes de segurança tradicionais, reduzindo drasticamente a superfície de detecção.
1.1. Vetores de Infecção e Acesso Inicial
A análise de múltiplos incidentes revela um padrão recorrente nos vetores de ataque utilizados. O acesso inicial ocorre, predominantemente, por meio da exploração de vulnerabilidades em dispositivos de perímetro e sistemas de acesso remoto , incluindo appliances de rede expostos à Internet (veja esss outra postagem sobre as vulnerabilidades associadas ao ataque inicial).
Em pelo menos um dos casos documentados, os atores exploraram vulnerabilidades zero-day, indicando acesso a capacidades avançadas de desenvolvimento e manutenção de exploits.
Após o comprometimento inicial, geralmente por meio de web shells implantadas em servidores na DMZ, os atores realizam movimento lateral utilizando protocolos amplamente disponíveis como RDP e SMB. Durante esse processo, credenciais são sistematicamente coletadas e reutilizadas para acessar sistemas críticos, incluindo controladores de domínio e servidores ADFS.
Em um incidente investigado pela CISA, os atacantes mantiveram acesso persistente desde abril de 2024. A partir de uma web shell em um servidor web da DMZ, o grupo avançou lateralmente até o vCenter, onde implantou o BRICKSTORM como mecanismo de persistência de longo prazo.
Esse padrão reforça um ponto crítico, a campanha não depende de exploração ruidosa, mas sim de progressão metódica e silenciosa dentro da rede.
1.2. Persistência e Mecanismos de Autoproteção
O BRICKSTORM implementa mecanismos robustos de persistência, projetados para resistir a tentativas de remoção parcial ou reinicializações do sistema. Um dos componentes mais relevantes é sua função de auto-vigilância, que monitora continuamente o próprio processo e o reinicia automaticamente caso seja interrompido.
Em sistemas Linux e Unix, o malware é implantado em diretórios sensíveis, como /etc/sysconfig/, e integrado aos scripts de inicialização do sistema. Em ambientes VMware, modificações são realizadas diretamente nos arquivos de inicialização do hypervisor, garantindo carregamento precoce durante o boot.
As amostras analisadas indicam desenvolvimento ativo, com uso de obfuscação por ferramentas como Garble e versões customizadas de bibliotecas. Algumas variantes incluem timers programados para atrasar a comunicação com o C2, aguardando datas específicas, um indicativo claro de planejamento operacional e tentativa de evitar correlação temporal com o incidente inicial.
2. Capacidades Técnicas Avançadas
2.1. Comunicação de Comando e Controle
O canal de comando e controle do BRICKSTORM foi projetado para dificultar ao máximo a inspeção e correlação por SOCs tradicionais. O malware combina múltiplas camadas de comunicação e criptografia:
HTTPS como camada de transporte básica.
WebSockets para multiplexação de sessões.
TLS aninhado na camada de aplicação.
DNS-over-HTTPS (DoH) para ocultar resolução de nomes.
Na prática, essa combinação quebra modelos clássicos de detecção baseados em DNS, proxy e inspeção de tráfego, especialmente em ambientes onde appliances de perímetro são tratados como “caixas pretas” do ponto de vista de segurança.
A infraestrutura de C2 observada inclui uso de Cloudflare Workers, aplicações Heroku e serviços de DNS dinâmico como sslip.io e nip.io. Um aspecto particularmente relevante é a ausência de reutilização de domínios C2 entre vítimas, indicando operações altamente compartimentalizadas e orientadas à evasão.
2.2. Funcionalidades de Controle Remoto
Uma vez estabelecida a comunicação, o BRICKSTORM oferece aos operadores um conjunto completo de capacidades de controle remoto:
Shell interativo para execução de comandos arbitrários.
Gerenciamento completo de arquivos.
Proxy SOCKS para facilitação de movimento lateral.
API HTTP para operações administrativas.
Suporte a VSOCK, permitindo comunicação inter-VM em ambientes virtualizados.
Essas funcionalidades transformam o sistema comprometido em um ponto de apoio operacional, capaz de sustentar operações de espionagem de longo prazo.
3.3. Escalação de Privilégios em Ambientes vCenter
Um dos aspectos mais sofisticados da campanha é a implantação de um Servlet Filter malicioso, rastreado como BRICKSTEAL, no Apache Tomcat que hospeda a interface web do vCenter.
Esse componente intercepta requisições HTTP relacionadas à autenticação SAML2, decodificando headers que podem conter credenciais em texto claro. Considerando que muitas organizações integram o vCenter ao Active Directory, o impacto potencial é elevado.
Com credenciais administrativas em mãos, os atores exploram recursos legítimos do vCenter para clonar máquinas virtuais críticas, como controladores de domínio. Essas clones permitem a extração offline de artefatos sensíveis, incluindo o banco ntds.dit, sem disparar alertas nos sistemas originais.
Esse método ilustra um ponto essencial, a virtualização deixa de ser apenas alvo e passa a ser ferramenta do ataque.
3. Indicadores de Comprometimento e Detecção
A CISA disponibilizou um conjunto abrangente de indicadores técnicos, incluindo nomes de arquivos, diretórios, variáveis de ambiente, padrões de tráfego e modificações em sistemas.
Apesar da utilidade desses IoCs, o próprio perfil da campanha indica que a detecção eficaz depende muito mais de hunting ativo, análise comportamental e baseline de ambientes virtualizados do que de simples correspondência por assinatura.
Regras YARA e Sigma, hashes conhecidos e análise forense de logs devem ser tratados como ponto de partida, não como solução definitiva.
4. Contexto de Ameaça e Atores
A atividade foi atribuída ao grupo UNC5221, associado a operações patrocinadas pela China, conforme documentado pelo Google Threat Intelligence Group e pela Mandiant.
Os setores-alvo incluem governo, TI, serviços jurídicos, SaaS e BPOs, organizações que frequentemente operam como nós intermediários de acesso a dados, identidades e infraestrutura crítica.
O longo tempo de permanência e a baixa geração de telemetria indicam que os operadores monitoram ativamente os ambientes comprometidos e adaptam suas técnicas diante de sinais de investigação, reforçando o caráter persistente da ameaça.
5. Recomendações de Mitigação
As recomendações das agências incluem:
Hunting ativo em vCenter, ESXi e appliances de perímetro
Implementação rigorosa de MFA para acessos administrativos
Segmentação entre DMZ e infraestrutura crítica
Revisão contínua de logs de autenticação e alterações em ambientes virtualizados
Aplicação tempestiva de patches de segurança em plataformas VMware
Organizações que identifiquem indícios de comprometimento devem acionar a CISA e considerar engajamento imediato de equipes especializadas em resposta a incidentes.
6. Conclusão
O BRICKSTORM não é apenas mais um backdoor sofisticado. Ele representa uma mudança clara na forma como atores patrocinados por Estados exploram virtualização, identidade e confiança operacional.
Ao operar quase invisivelmente em camadas tradicionalmente pouco monitoradas, essa campanha desafia modelos clássicos de defesa e reforça a necessidade de visibilidade real sobre infraestrutura, não apenas sobre endpoints.
Para SOCs, MSPs e organizações que operam ambientes híbridos e virtualizados, a lição é inequívoca, virtualização deixou de ser apenas plataforma, passou a ser superfície de ataque crítica.
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.
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].
O valor do EPSS saltou de 13,9% em 08/12/2025 para 76,01% HOJE 11/12/2025.
Com um valor de CVSS 10,0 é fundamental que sejam aplicadas as medidas de resolução imediatamente.
1. Introdução
No início de dezembro de 2025, uma vulnerabilidade de severidade crítica, apelidada de React2Shell, emergiu, abalando a comunidade de desenvolvimento web.
Identificada oficialmente como CVE-2025-55182, trata-se de uma falha de Execução Remota de Código Não Autenticada ou Unauthenticated Remote Code Execution (Unauthenticated RCE) e recebeu a pontuação máxima de 10.0 no Common Vulnerability Scoring System (CVSS), sinalizando um risco extremo para uma vasta gama de aplicações modernas.
Uma Execução Remota de Código Não Autenticada é uma vulnerabilidade que permite a um atacante executar comandos ou código arbitrário em um servidor remoto sem necessidade de possuir credenciais válidas ou autenticação prévia.
Diferentemente de vulnerabilidades que exigem que o invasor esteja logado ou tenha acesso autorizado ao sistema, uma Unauthenticated RCEpode ser explorada por qualquer pessoa com acesso à rede (geralmente a internet), tornando-a extremamente perigosa.
A vulnerabilidade reside no coração dos React Server Components (RSC), uma tecnologia cada vez mais adotada em frameworks populares como Next.js, afetando potencialmente mais de 40% dos principais websites da Internet.
Este artigo oferece uma análise técnica aprofundada da React2Shell, detalhando seu mecanismo de exploração, o impacto que pode causar e as medidas essenciais que as equipes de segurança e desenvolvimento devem tomar para mitigar esta ameaça iminente.
2. O Mecanismo da Exploração: Desserialização Insegura
A React2Shell NÃO é uma vulnerabilidade comum. Sua periculosidade reside na simplicidade de sua exploração.
Um atacante, sem qualquer tipo de autenticação, pode comprometer completamente um servidor vulnerável através de uma única requisição HTTP POST maliciosamente elaborada.
A raiz do problema está na forma como os React Server Components lidam com a desserialização de dados.
Quando um cliente envia uma requisição para um endpoint que utiliza Server Functions, o React transforma os dados recebidos em chamadas de função do lado do servidor.
Durante este processo, a vulnerabilidade permite que um payload manipulado seja desserializado sem as devidas validações de segurança. Isso cria um caminho direto para que o atacante injete e execute código arbitrário com os mesmos privilégios do processo do servidor Node.js, abrindo as portas para um comprometimento total do sistema.
2. Análise de Impacto: As Consequências de uma Exploração Bem-Sucedida
Uma vulnerabilidade de RCE pré-autenticação é o ativo mais cobiçado no arsenal de um agente malicioso. No caso da React2Shell, as consequências de uma exploração bem-sucedida são catastróficas e podem se manifestar de várias formas:
Comprometimento Total da Infraestrutura: O atacante obtém controle total sobre o servidor, permitindo acesso irrestrito ao sistema de arquivos, roubo de credenciais e a instalação de backdoors para acesso persistente.
Exfiltração de Dados Sensíveis: Uma vez dentro do sistema, o invasor pode acessar e exfiltrar informações críticas, como bancos de dados de clientes, segredos de aplicação (chaves de API, tokens), propriedade intelectual e lógica de negócios.
Movimento Lateral na Rede: O servidor comprometido torna-se um ponto de pivô, a partir do qual o atacante pode lançar novas ofensivas contra outros sistemas internos, bancos de dados e recursos na nuvem, expandindo o alcance do ataque por toda a organização.
Ataques de Ransomware e Interrupção de Negócios: Com controle total, os atacantes podem implantar ransomware, criptografando dados vitais e exigindo um resgate, ou simplesmente interromper as operações, causando perdas financeiras e danos à reputação.
2. Descrição Técnica
A vulnerabilidade decorre de desserialização insegura no protocolo Flight, mecanismo responsável por transportar estruturas dos Server Components entre cliente e servidor.
Ao receber um payload malicioso, o servidor interpreta dados arbitrários como referências de função, o que permite execução remota de código com privilégios equivalentes ao processo Node.js.
Condições de exploração
Não exige autenticação;
Não exige cookie, API key ou token;
Pode ser explorada por qualquer atacante com acesso ao endpoint RSC;
Vetor principal: HTTP POST com conteúdo Flight manipulado.
Impacto técnico
Execução remota de código (RCE);
Execução arbitrária de processos no host ou container;
Exfiltração de dados sensíveis;
Movimento lateral;
Possível comprometimento total de infraestrutura (quando mal configurada).
3. Sistemas Afetados
3.1 React e bibliotecas centrais
Conforme registros do NVD:
Pacote
Versões vulneráveis
Versões corrigidas
react-server-dom-webpack
19.0.0 a 19.2.0
19.0.1+, 19.1.2+, 19.2.1+
react-server-dom-parcel
19.0.0 a 19.2.0
19.0.1+, 19.1.2+, 19.2.1+
react-server-dom-turbopack
19.0.0 a 19.2.0
19.0.1+, 19.1.2+, 19.2.1+
3.2 Frameworks afetados
Next.js versões 15.x e 16.x; Associado adicionalmente ao CVE-2025-66478, conforme documentação CISA/NVD.
React Router com RSC;
Expo;
RedwoodJS;
Waku;
Plugins de integração RSC para Vite, Parcel e Turbopack.
4. Vetor de Ataque e Indicadores de Exploração
4.1 Vetor primário
POST /<endpoint-rsc>
Content-Type: application/json
Payload malformado contendo blocos Flight manipulados
4.2 Indicadores observáveis
Logs de erro do Flight referentes a parsing inesperado;
Picos súbitos de CPU em processos Node.js;
Tentativas de criação de processos via child_process.spawn/exec;
Comunicação egressa para hosts desconhecidos
Criação de artefatos suspeitos em /tmp em containers Linux
Comprometimento de clusters Kubernetes negligentemente isolados;
Uso da vulnerabilidade para implantação de webshells e reverse shells.
5. Mitigação
5.1 Patching obrigatório
Aplicar imediatamente as versões corrigidas dos pacotes React RSC e atualizar aplicações Next.js para releases não vulneráveis.
5.2 Controles compensatórios (temporários)
Regras de WAF para bloquear payloads suspeitos do protocolo Flight;
Monitoramento agressivo de tráfego de egressão;
Habilitar logs completos de chamadas RSC;
Bloquear criação de processos filho por Node.js quando possível;
Reforçar políticas noexec em diretórios temporários.
5.3 Defesa em profundidade
Execução do Node.js com mínimo privilégio;
Isolamento adequado de containers e namespaces;
Mecanismos RASP como camada adicional;
6. Avaliação de Risco
A vulnerabilidade é considerada Crítica, nível máximo no CVSS 10.0, devido a:
Exploração ativa confirmada globalmente
Ausência de barreiras de autenticação
Impacto direto em aplicações amplamente adotadas (React/Next.js)
Possibilidade de comprometimento total do ambiente
É altamente recomendável priorizar a correção em ambientes expostos à internet.
6.1. Sobre o EPSS e CVVS Score para React2Shel
Métrica
Valor
Score Inicial
0.46%
Score Atual
13.86% (8 de dezembro de 2025) 76,01% (atualizado em 11/12/2025)
Percentil
Em atualização contínua
O Problema: Uma Discrepância Crítica
Existe uma divergência significativa entre o CVSS (10.0 – Crítico) e o EPSS (13.86%), que revela uma limitação importante dos sistemas de scoring automatizados.
É importante entender que o EPSS é um “indicador retardado” (lagging indicator).
Embora tenha subido de 0.46% para 13.86% desde o início da publicação do CVE, ainda está muito abaixo do que os níveis reais de exploração justificariam, porque:
Exploração Ativa em Andamento: Grupos de ameaças vinculados à China já foram observados explorando a vulnerabilidade (AWS)
Liderança em Bug Bounty: É o #1 CVE mais explorado na plataforma HackerOne
Remediação Acelerada: Organizações estão remediando em menos de um dia em média
Escala Massiva: Mais de 12 milhões de sites potencialmente vulneráveis.
O Que Isso Significa
O EPSS demonstra que sistemas de scoring automatizados podem não acompanhar o ritmo de exploração em tempo real. Isso ressalta a importância de:
Não depender apenas de scores automatizados para priorização de vulnerabilidades críticas.
Usar feedback em tempo real de comunidades de segurança (bug bounty, threat intelligence).
Considerar o contexto operacional além dos scores numéricos
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.
Nessa manhã de 18 de novembro de 2025, uma instabilidade global no serviço da Cloudflare causou interrupções generalizadas, afetando o acesso a grandes plataformas como o ChatGPT, X (antigo Twitter) e Canva [2]. Usuários no Brasil e no mundo relataram dificuldades de acesso e mensagens de erro, como a notificação “Please unblock challenges.cloudflare.com to proceed”.
Não há evidências de que a instabilidade da Cloudflare em 18 de novembro de 2025 tenha sido causada por um ataque cibernético. Com base nas declarações oficiais da empresa e nas análises de especialistas, o incidente parece estar relacionado a problemas internos de infraestrutura.
A falha, que começou por volta das 8h da manhã no horário de Brasília, foi atribuída pela Cloudflare a um “pico de tráfego incomum” em sua rede [1].
Se você receber a mensagem “Please unblock challenges.cloudflare.com to proceed“, não é necessário fazer nada. Esta é uma mensagem de erro relacionada à instabilidade interna da Cloudflare, e não um problema de bloqueio no seu dispositivo ou rede.
Veja no final dessa postagem, há um timeline a respeito dessa instabilidade.
Entretanto, este cenário evidencia a profunda dependência da internet global em um número restrito de provedores de infraestrutura. A Cloudflare, que gerencia aproximadamente 20% de todo o tráfego da web, atua como uma camada essencial de segurança e desempenho para milhões de sites [2]. Uma falha em seus sistemas, mesmo que temporária, tem um efeito cascata imediato e visível para usuários em todo o mundo.
O Ataque Recorde à Azure e a Ameaça Crescente das Botnets
Coincidentemente, a instabilidade da Cloudflare ocorreu no dia seguinte à divulgação, pela Microsoft, de detalhes sobre um ataque de negação de serviço (DDoS) de escala recorde que sua plataforma Azure sofreu. Em 24 de outubro de 2025, a infraestrutura da Azure mitigou com sucesso um ataque que atingiu um pico de 15.72 Tbps, originado pela botnet Aisuru [3].
Ainda que alguns veículos estejam especulando que esses eventos estão relacionados, ainda não, até o momento da escrita desse post, nenhuma evidência ou confirmação disso.
Este ataque massivo envolveu mais de 500.000 dispositivos IoT comprometidos, como roteadores e câmeras, e destaca o poder destrutivo que as botnets modernas podem alcançar. Embora a Microsoft tenha conseguido neutralizar a ameaça sem impacto para seus clientes, o episódio serve como um forte indicativo da crescente sofisticação e escala dos ataques cibernéticos contra a infraestrutura de nuvem 3.
Confusão com o Ataque à Azure
Uma fonte significativa de confusão é que duas grandes notícias de cibersegurança foram divulgadas quase simultaneamente:
Notícia 1: Instabilidade da Cloudflare (18 de novembro de 2025)
• Evento atual, em andamento.
• Causa: Pico de tráfego incomum, origem desconhecida.
• Impacto: Interrupção de serviços globais.
Notícia 2: Ataque DDoS à Azure (divulgado em 17-18 de novembro de 2025)
• Evento ocorrido em 24 de outubro de 2025.
• Causa: Ataque DDoS da botnet Aisuru.
• Resultado: Microsoft mitigou com sucesso, sem impacto aos clientes
Importante: O ataque à Azure ocorreu há quase um mês e foi mitigado com sucesso. A Microsoft apenas divulgou os detalhes técnicos do ataque nesta semana. Não há conexão entre o ataque à Azure e a instabilidade da Cloudflare.
Um Alerta para a Infraestrutura Crítica da Internet
Como dito, embora não haja, até o momento, nenhuma evidência que conecte a instabilidade da Cloudflare ao ataque contra a Azure, a ocorrência de dois eventos de tão grande magnitude em um curto espaço de tempo é um alerta contundente. Ambos os incidentes, cada um à sua maneira, expõem as vulnerabilidades inerentes à arquitetura centralizada da internet moderna.
A dependência de poucos grandes players, como Cloudflare, AWS e Azure, significa que uma falha técnica ou um ataque bem-sucedido pode ter consequências globais. A resiliência da internet depende da capacidade dessas empresas de não apenas inovar em segurança e desempenho, mas também de responder rapidamente a incidentes inevitáveis.
Para empresas e desenvolvedores, a lição é clara: a resiliência digital não pode ser terceirizada por completo. É fundamental adotar práticas de contingência, como arquiteturas multi-cloud, monitoramento proativo e planos de resposta a incidentes, para garantir a continuidade dos negócios diante de um cenário de ameaças e falhas cada vez mais complexo.
13:35 UTC (10:35 AM horário de Brasília): A empresa continua trabalhando na restauração dos serviços para clientes de serviços de aplicação. Alguns serviços já foram restaurados, mas o trabalho de recuperação ainda está em andamento.
13:13 UTC (10:13 AM horário de Brasília): A Cloudflare implementou mudanças que permitiram a recuperação do Cloudflare Access e do WARP. Os níveis de erro para usuários desses serviços retornaram às taxas anteriores ao incidente. O acesso WARP em Londres foi reabilitado.
13:09 UTC (10:09 AM horário de Brasília): O problema foi identificado e uma correção está sendo implementada.
12:21 UTC (9:21 AM horário de Brasília): A empresa reportou que os serviços estavam se recuperando, mas os clientes ainda poderiam observar taxas de erro acima do normal durante os esforços de remediação.
11:48 UTC (8:48 AM horário de Brasília): Início da investigação oficial do problema, confirmando degradação interna do serviço.
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.
Data: 14/11/2025 Severidade: Crítica – CVSS 9.8 Status: Explorada ativamente desde outubro/2025 Produtos afetados: FortiWeb 7.0 a 8.0 (múltiplas versões)
Resumo Executivo
Em 14 de novembro de 2025, a Fortinet e a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) divulgaram um alerta sobre uma vulnerabilidade crítica de Path Traversal (CWE-23) que afeta os produtos FortiWeb, o Web Application Firewall (WAF) da Fortinet. A falha, identificada como CVE-2025-64446, possui uma pontuação CVSSv3 de 9.8 (Crítica) e está sendo ativamente explorada por atacantes desde o início de outubro de 2025 1.
A vulnerabilidade permite que um atacante não autenticado execute comandos administrativos remotos em sistemas vulneráveis, levando a um comprometimento total do dispositivo. A CISA já adicionou esta falha ao seu catálogo de Vulnerabilidades Exploradas Conhecidas (KEV), com um prazo de remediação obrigatório até 21 de novembro de 2025
1. Visão Geral da Vulnerabilidade
A CVE-2025-64446 é uma vulnerabilidade crítica de Path Traversal (CWE-23) combinada com bypass de autenticação, permitindo que um atacante não autenticado execute operações administrativas via CGI (fwbcgi).
Esta é a terceira vulnerabilidade crítica da linha FortiWeb nos últimos 18 meses, reforçando o padrão preocupante de falhas severas na superfície de ataque de dispositivos de borda da Fortinet.
A falha ocorre em dois estágios principais:
Path Traversal no endpoint /api/v2.0/…
Impersonação via header CGIINFO (base64) aceito pela função cgi_auth() sem validação real
O resultado é o comprometimento total do dispositivo FortiWeb, com capacidade de persistência, desvio de políticas de segurança e movimentação lateral na rede.
A falha foi adicionada em 14/11/2025 ao catálogo CISA KEV (Known Exploited Vulnerabilities Catalog) com prazo de mitigação obrigatório até 21/11/2025.
2. Detalhes de Exploração
2.1 Estágio 1 – Path Traversal
No primeiro estágio, o atacante utiliza um endpoint de API válido para escapar do diretório esperado e alcançar o executável administrativo fwbcgi:
POST /api/v2.0/cmd/system/admin%3F/../../../../../cgi-bin/fwbcgi HTTP/1.1
O Path Traversal permite que requisições atinjam o binário fwbcgi, responsável por operações administrativas no dispositivo.
2.2 Estágio 2 – Impersonação via CGIINFO
O binário fwbcgi utiliza a função cgi_auth(), que:
não valida corretamente credenciais de autenticação;
aceita um header HTTP chamado CGIINFO;
confia em informações de identidade fornecidas em JSON, codificadas em Base64.
Exemplo de payload JSON, antes de ser codificado em Base64:
Quando esse payload é aceito, o sistema concede privilégios administrativos completos, permitindo ao atacante criar novas contas, alterar configurações e manter persistência no dispositivo.
3. Impacto Operacional
Um atacante que explore com sucesso a CVE-2025-64446 pode:
Criar usuários administradores persistentes e ocultos;
Modificar políticas, regras e perfis de proteção do WAF;
Desabilitar ou contornar mecanismos de segurança;
Exfiltrar dados inspecionados e registrados pelo WAF;
Realizar movimentação lateral a partir do dispositivo comprometido.
Por se tratar de um WAF de borda, a vulnerabilidade abre um vetor crítico para ataques internos a partir de um equipamento que, normalmente, é considerado parte da camada de proteção.
4. Versões Afetadas (Confirmadas)
Produto
Versões Vulneráveis
FortiWeb 8.0
8.0.0 – 8.0.1
FortiWeb 7.6
7.6.0 – 7.6.4
FortiWeb 7.4
7.4.0 – 7.4.9
FortiWeb 7.2
7.2.0 – 7.2.11
FortiWeb 7.0
7.0.0 – 7.0.11
5. Ação Recomendada (Imediata)
5.1 Atualizar Firmware – Única Remediação Definitiva
Além disso, monitorar requisições contendo o header CGIINFO com conteúdo Base64, principalmente oriundas de IPs externos ou não autorizados.
CGIINFO: <string_base64_suspeita>
IPs com múltiplas tentativas de POSTpara esses caminhos devem ser tratados como suspeitos, com correlação adicional em outros logs.
6.2 Sistema / Configurações
Nos próprios dispositivos FortiWeb, verificar:
Criação de novas contas de administrador, principalmente a partir de outubro de 2025;
Contas com perfil de acesso prof_admin ou super_admin não reconhecidas pela equipe de segurança;
Configurações de trust host definidas como 0.0.0.0/0 ou ::/0 em contas administrativas;
Alterações não autorizadas em políticas, perfis, certificados e regras de inspeção.
7. Procedimentos de Resposta a Incidente
Em caso de suspeita de exploração da CVE-2025-64446, recomenda-se o seguinte fluxo para equipes de Blue Team / CERT / CSIRT:
Isolar o dispositivo: restringir acesso administrativo externo, mantendo apenas o mínimo necessário para análise e operação.
Coletar logs: exportar logs de sistema, eventos, auditoria e administração para um servidor seguro de análise.
Revisar contas de usuário: identificar contas administrativas novas ou modificadas, sobretudo com perfis elevados.
Analisar headers CGIINFO: quando possível, decodificar strings Base64 para determinar tentativas de impersonação de administradores.
Aplicar atualização de firmware para as versões corrigidas recomendadas pela Fortinet.
Revalidar configuração: revisar políticas, objetos, perfis e parâmetros de segurança para identificar alterações maliciosas.
Verificar persistência: buscar scripts, agendamentos, acessos remotos ou configurações suspeitas que indiquem backdoors.
Monitorar pós-correção: manter monitoramento reforçado por pelo menos 72 horas após a atualização e a revisão de segurança.
8. Conclusão
A CVE-2025-64446 representa uma vulnerabilidade de alta criticidade em dispositivos FortiWeb, com exploração ativa e baixo nível de complexidade técnica para o atacante. Dispositivos expostos à Internet, principalmente em ambientes de alta criticidade, estão sob risco significativo.
A atualização para versões corrigidas deve ser tratada como prioridade máxima em planos de resposta a incidentes e gestão de vulnerabilidades, especialmente em:
Provedores de serviços de Internet (ISPs e provedores regionais);
Órgãos públicos e infraestruturas críticas;
Instituições financeiras e meios de pagamento;
Ambientes acadêmicos com grande exposição de aplicações web;
Empresas que utilizam o FortiWeb para proteger aplicações sensíveis.
Equipes de segurança devem tratar essa vulnerabilidade como um incidente de severidade máxima, combinando correção, caça a ameaças (threat hunting) e monitoramento contínuo.
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.
Peguei um caso em que duas pessoas da equipe financeira receberam um e-mail que se passava pelo CEO da empresa. A mensagem autorizava um pagamento de R$ 28.900,00 pelos serviços prestados. A equipe rapidamente identificou que se tratava de uma fraude e reportou o incidente para a área de cibersegurança. Ainda bem!
O atacante criou uma conta @outlook.com utilizando o nome do CEO, tentando conferir legitimidade ao envio (ex.: abc.xyz@outlook.com).
Além disso, ele alterou o campo Display Name da mensagem para o nome completo do executivo e criou uma assinatura com o logo da empresa.
No corpo do e-mail, o fraudador enviava uma chave Pix para a realização do pagamento, sendo essa chave o próprio CNPJ da empresa recebedora.
Até aí tudo comum em um ataque de phishing…
Por curiosidade, busquei informações sobre a empresa fraudadora e, por meio do CNPJ, cheguei até o proprietário. A empresa estava localizada em Arapongas – PR.
Ao analisar o histórico profissional do dono da empresa, encontrei um dado relevante: em 2023, o fraudador havia trabalhado em uma empresa prestadora de serviços para a companhia que agora estava sendo alvo.
Como o ataque foi direcionado, com conhecimento dos e-mails e dos nomes específicos envolvidos no processo de pagamentos, é bem provável que o atacante tenha se apropriado de alguma base contendo dados dos clientes do seu emprego anterior e, agora, estivesse aplicando golpes.
Infelizmente, trata-se de mais um caso típico de falhas de controle em múltiplos processos. A superfície de risco só cresce quando a cadeia de suprimentos não é monitorada de ponta a ponta.
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.
Recentemente tivemos uma rápida disseminação do malware “Sorvepotel”, e agora novamente, nos deparamos com a notícia que me deixou preocupado, noticia está sobre um novo malware bancário chamado “Herodotus” e que vem atacando muitos usuários Android.
O novo malware se utiliza como principal estratégica de propagação através de campanhas de phishing por SMS, onde usuários recebem links fraudulentos que levam a páginas maliciosas onde o malware é baixado e instalado no seu dispositivo mobile. Após instalado, o malware obtém permissões críticas do sistema e utilizando de táticas sofisticadas como sobreposição de tela para roubar credenciais e tornando as sessões legitimas, dificultando a ação dos antivírus tradicionais ou mesmo não detectando o comprometimento do dispositivo.
Precisamos ficar atentos e reforçar a vigilância no mundo digital e começar a nos precaver com medidas de segurança como, baixar aplicativos somente de lojas oficiais(apesar de não ser 100% a prova de falha, ainda é a opção mais segura), suspeitar de SMS com links e fontes desconhecidas, não validar informações pelo SMS, onde mensagens podem ser interceptadas e alteradas, utilizar se de aplicativos autenticadores como Google ou Microsoft Authenticator, não autorizar permissões críticas no seu dispositivos a aplicativos suspeitos .
Precisamos ficar constantemente atentos, pois a sofisticação dos atacantes está sempre um passo à frente. Segurança não é somente ferramental, mas sim um processo.
Acompanhando algumas notícias recentemente a China acusou a NSA de ter realizado um ataque ao serviço de tempo (National Time Service Center) responsável por manter e transmitir o horário de Pequim
Assim como alguns problemas geopolíticos recentes do Brasil com o Estados Unidos, em que surgiu rumores da possibilidade de bloquearem o serviço de GPS, o Time Service poderia ter causado um grande caos para os chineses, parando serviços como comunicação de rede e até sistemas financeiros.
O mais interessante é que tudo começou por um ataque de triangulação de celulares e em seguida o roubo de credenciais.
E várias vezes já pegamos de problemas de autenticação relacionados ao Active Directory em que a causa raiz era os relógios dessincronizados.
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.
É… Eu sobrevivi a frenética contagem regressiva até o timestamp “00-01-01 00:00:01”, virada do ano de 1999 para 2000, onde muitos acreditavam que todos os computadores iam bugar.
Agora os preparados, preocupados ou até “pessimistas” já podem acompanhar mais uma contagem regressiva, agora para um outro timestamp “2038-01-19 03:14:08 UTC”, neste momento em questão milhares de dispositivos, principalmente os OTs terão algum comportamento muito possivelmente problemático, já que o modelo de tempo conhecido como “Unix time” não irá mais caber em um inteiro de 32 bits.
Basicamente o Unix time conta os segundos desde um “timestamp específico”, zero horas de primeiro de janeiro de 1970, 1970-01-01T00:00:00, até o momento então quando um equipamento com este modelo de hora registra um evento ele insere a quantidade de segundos desde “timestamp específico”. Veja o exemplo no print abaixo, onde o ano, mês, dia, hora, minuto e segundo atual em Unix time é representado pelo inteiro “1760410507”.
Se você lida com equipamentos médicos, industriais, automação, etc. precisa começar a contatar os fabricantes, fazer testes e/ou buscar alternativas, mas principalmente acompanhar o projeto “Epochalypse”, https://epochalypse-project.org/, projeto que fiquei conhecendo pelo pessoal do Cert.Br, https://cert.br/, e agora relembrado pelo newsletter do SANS Institute, https://www.sans.org/.
Acompanhe, prepare-se e esteja pronto. O tempo não para, você, também não pode ficar parado! Só assim nossos empregos vão sobreviver a mais esta contagem regressiva!
