Vol. 1 No. 20260218-1130 (2025)

ClickFix com DNS Staging distribui malware via PowerShell

Adriano Cansian | adriano.cansian@unesp.br | 18/02/2026

A nova campanha de ataque, que possui como alvo o sistema Windows da Microsoft, caracteriza uma evolução do método de engenharia social ClickFix, na qual consultas DNS realizadas por meio do utilitário nativo nslookup são utilizadas como mecanismo de staging e entrega de código malicioso.

Nesse modelo, respostas DNS são manipuladas para transportar dados codificados que contêm comandos e scripts PowerShell, posteriormente reconstruídos e executados no host comprometido.

A técnica permite o carregamento progressivo de payloads e a instalação de malware em sistemas Windows, incluindo Remote Access Trojans (RATs) e Infostealers, explorando uma abordagem living-off-the-land que utiliza ferramentas legítimas do sistema operacional.

O uso do protocolo DNS como canal de transporte contribui significativamente para evasão de detecção baseada em rede, uma vez que o tráfego se mistura a consultas legítimas e frequentemente não é submetido a inspeção profunda em ambientes corporativos.

A campanha representa uma evolução significativa de ataques baseados em engenharia social, explorando ferramentas legítimas do próprio sistema operacional para contornar mecanismos tradicionais de defesa.


Cadeia de infecção observada

O método conhecido como ClickFix baseia-se em engenharia social. A vítima é induzida a executar manualmente comandos apresentados como soluções para supostos problemas técnicos. Normalmente, o usuário recebe instruções para copiar e executar comandos em terminais do Windows, acreditando estar resolvendo um problema legítimo.

Nesta nova campanha, os atacantes aprimoraram o método ao integrar o uso de consultas DNS como mecanismo de entrega de payload. A cadeia de passos observada tem sido a seguinte:

  • A vítima é levada (por instruções passo a passo em sites, e‑mails ou chats de “suporte”) a abrir o diálogo Executar do Windows (Win+R) ou um terminal e colar um comando aparentemente benigno.
  • Esse comando executa o nslookup apontando NÃO para o resolvedor DNS padrão da máquina, mas para um servidor DNS externo controlado pelo atacante (IP ou domínio hard‑coded no comando).
  • A resposta DNS vem especialmente formatada: o campo “Name:” ou dados de resposta contêm um script PowerShell ou dados codificados que são filtrados e passados diretamente para execução como segundo estágio.
  • O PowerShell então baixa um arquivo ZIP a partir da infraestrutura do atacante, contendo um runtime Python portátil e vários scripts que fazem reconhecimento de host/domínio, instalam persistência e puxam payloads adicionais.

Por que este ataque é preocupante

O uso do DNS como canal de entrega aumenta significativamente a capacidade de evasão, pois:

  • O DNS raramente é bloqueado em ambientes corporativos;
  • Em muitas organizações não inspecionam profundamente consultas DNS;
  • As ferramentas utilizadas são nativas do Windows (living-off-the-land).

Isso reduz a eficácia de soluções tradicionais baseadas apenas em assinaturas ou monitoramento de downloads.


Recomendações de mitigação

Organizações e usuários devem adotar medidas preventivas imediatas:

Para equipes de segurança

  • Monitorar uso incomum de nslookup e PowerShell;
  • Implementar inspeção e logging avançado de tráfego DNS;
  • Detectar consultas DNS com volumes anormais ou respostas longas;
  • Aplicar políticas de execução restrita para PowerShell; e
  • Utilizar EDR/XDR com detecção COMPORTAMENTAL.

Para usuários

  • Nunca executar comandos sugeridos por sites ou pop-ups;
  • Desconfiar de páginas que pedem ações manuais no terminal; e
  • Validar instruções técnicas apenas em fontes oficiais.

Conclusão

A campanha identificada demonstra uma tendência crescente no cenário de ameaças: o abuso de ferramentas legítimas e protocolos essenciais da Internet para contornar mecanismos tradicionais de defesa.

O uso combinado de engenharia social ClickFix e entrega de payload via DNS reforça a necessidade de estratégias de defesa baseadas em comportamento, telemetria e análise contextual, e não apenas em bloqueios convencionais.

Vol. 1 No. 20260210-1126 (2025)

Incidentes cibernéticos no setor energético expondo fragilidades críticas em OT/ICS

Adriano Cansian | adriano.cansian@unesp.br | 10/02/2026

Temos observado, em diferentes regiões, campanhas de ataque em larga escala direcionadas a infraestruturas de tecnologia operacional e automação (OT), sistemas de controle industrial (ICS) e dispositivos IoT empregados em geração e distribuição de energia, especialmente em ativos distribuídos como parques eólicos, usinas solares e subestações remotas.

Nesses eventos invasores exploraram vulnerabilidades antigas sem patchs, falhas de higiene de senhas e exposição indevida de dispositivos de borda, mantendo persistência prolongada na rede. Foram comprometidos endpoints remotos, firewalls e concentradores VPN expostos diretamente à internet, muitos sem autenticação multifator e com credenciais fracas.

Esses ambientes compartilham características que ampliam significativamente a superfície de ataque, incluindo dispositivos de borda expostos à internet, acesso remoto permanente por VPN, credenciais fracas ou reutilizadas, equipamentos legados com baixa cadência de atualização e integração insuficiente entre equipes de TI e automação e operação.

Os impactos mais frequentes não são necessariamente apagões imediatos, mas sim perda de telemetria, indisponibilidade de controle remoto, necessidade de operação manual de campo, substituição de equipamentos e degradação prolongada da capacidade operacional. Em cenários extremos, observa-se uso de malware destrutivo com objetivo de sabotagem e, majoritariamente, sequestro de dados.


Recomendações

Diante desse contexto, recomenda-se que organizações do setor energético e industrial adotem uma postura de defesa em profundidade específica para OT/ICS, contemplando:

1. Medidas técnicas essenciais

  • Autenticação multifator obrigatória para todo acesso remoto;
  • Segmentação rigorosa entre redes IT, OT e IoT, com zonas bem definidas;
  • Eliminação de exposição direta de dispositivos de borda à internet;
    • Gestão contínua de vulnerabilidades e aplicação programada de patches;
  • Inventário completo de ativos OT, incluindo firmware e versões;
  • Monitoramento de integridade de endpoints, PLCs (controladoras lógicas programáveis) e gateways;
  • Detecção de perda de comunicação ou telemetria como indicador de incidente; e
  • Backups offline e planos de rápida reposição de equipamentos críticos.

2. Medidas operacionais e organizacionais

• Estabelecer SOC ou monitoramento dedicado a OT;
• Integrar feeds de threat intelligence setoriais, quando disponíveis;
• Realizar testes periódicos de resposta a incidentes e recuperação operacional;
• Desenvolver playbooks específicos para indisponibilidades;
• Realizar capacitação conjunta de equipes de TI, engenharia e automação; e
• Realizar exercícios de contingência com operação manual.


Vol. 1 No. 20260204-1123 (2025)

Alerta de Segurança: Os Riscos Ocultos do OpenClaw

Adriano Cansian | adriano.cansian@unesp.br | 04/02/2026

Nas últimas semanas, uma ferramenta de assistente de IA de código aberto, conhecida por seus vários nomes — Clawdbot, Moltbot e, mais recentemente, OpenClaw — ganhou imensa popularidade. Prometendo ser um “IA que realmente faz coisas”, o OpenClaw oferece a capacidade de automatizar uma vasta gama de tarefas digitais, desde gerenciar e-mails e mensagens até realizar ações complexas em nome do usuário. No entanto, por trás de sua fachada de produtividade e inovação, esconde-se um pesadelo de segurança.

Este alerta tem como objetivo detalhar os graves riscos de segurança associados ao OpenClaw e recomendar fortemente contra sua instalação em qualquer ambiente de produção ou em sistemas que contenham dados sensíveis.

Se você está usando ou pretende usar isso, recomendamos ler atentamente o alerta a seguir.


O Que é o OpenClaw?

O OpenClaw é um agente de IA autônomo e auto-hospedado que opera localmente na máquina do usuário. Ele se integra a aplicativos de mensagens populares como WhatsApp e iMessage, e pode executar uma variedade de tarefas, como agendar voos, fazer reservas em restaurantes, controlar navegadores e gerenciar arquivos. Sua arquitetura permite a expansão de suas capacidades através de “skills” (habilidades) que a comunidade pode desenvolver e compartilhar. Essa combinação de autonomia, acesso local e extensibilidade é o que o tornou viral, mas também é a fonte de seus profundos problemas de segurança [1][2].


Falhas Arquiteturais e Vetores de Exploração

A arquitetura fundamental do OpenClaw cria uma confluência de riscos que o torna perigoso por padrão, especialmente quando mal configurado ou exposto à internet.

“De uma perspectiva de capacidade, o OpenClaw é inovador. É tudo o que os desenvolvedores de assistentes pessoais de IA sempre quiseram alcançar. De uma perspectiva de segurança, é um pesadelo absoluto.” – Cisco [2]

Os principais problemas de design incluem:

  • Altos Privilégios por Padrão: Para funcionar, o OpenClaw requer acesso de alto nível ao sistema operacional, permitindo-lhe executar comandos de shell, ler e escrever arquivos e executar scripts. Se comprometido, o agente se torna um “superusuário fantasma” nas mãos de um ator mal intencionado [4].
  • Vazamento de Credenciais e Chaves de API: Inúmeros casos de instâncias do OpenClaw mal configuradas foram encontradas expostas na internet, vazando chaves de API em texto plano, tokens de bot do Telegram, credenciais do Slack e históricos de conversas [1].
  • Superfície de Ataque Expandida: A integração com aplicativos de mensagens estende a superfície de ataque, permitindo que invasores enviem prompts maliciosos para induzir comportamentos indesejados [2].

Vulnerabilidades Críticas e Riscos Detalhados

A pesquisa de segurança revelou várias vulnerabilidades e vetores de ataque específicos que tornam o uso do OpenClaw extremamente arriscado.

1. Execução Remota de Código (RCE) com Um Clique (CVE-2026-25253)

Em 01/02/2026 uma vulnerabilidade de alta gravidade (CVSS 8.8) foi identificada, permitindo a execução remota de código mediante um link malicioso. A falha reside na interface de controle (Control UI), que confia na URL do gateway sem validação adequada. Ao clicar em um link criado por um invasor, o token de autenticação do gateway da vítima é enviado para o servidor do invasor. Com este token, o invasor pode se conectar ao gateway da vítima, modificar configurações de segurança (como desativar o sandbox) e executar comandos arbitrários no sistema hospedeiro [3].

“O ataque funciona mesmo quando o gateway está configurado para escutar apenas em loopback, porque o navegador da vítima atua como a ponte.” – Peter Steinberger, criador do OpenClaw [3]

2. Injeção de Prompt (Prompt Injection)

O problema de injeção de prompt, ainda não resolvido no campo da IA, é particularmente perigoso no OpenClaw. Um invasor pode incorporar instruções maliciosas em conteúdo que o agente irá processar (como uma página da web ou um e-mail). O agente pode então ser levado a exfiltrar dados sensíveis, enviar informações para um servidor controlado pelo invasor ou executar comandos perigosos no sistema do usuário [1].

3. “Skills” Maliciosas e Ataques à Cadeia de Suprimentos

A capacidade de estender o OpenClaw com “skills” de terceiros abre um perigoso vetor de ataque de cadeia de suprimentos. Pesquisadores já descobriram “skills” maliciosas que funcionam como malware. Em um exemplo, uma extensão falsa do VS Code para o ClawdBot era, na verdade, um Trojan projetado para vigilância e roubo de dados. Em outro, um pesquisador de segurança criou uma “skill” com backdoor que foi baixada milhares de vezes, demonstrando a facilidade com que a confiança da comunidade pode ser abusada [1][2].

4. Confusão de Identidade e Golpes

A rápida sucessão de mudanças de nome (de Clawdbot para Moltbot e depois para OpenClaw) criou uma janela de oportunidade para golpistas. Repositórios falsos e golpes de criptomoeda surgiram, explorando a confusão. Um token falso de criptomoeda “Clawdbot AI” conseguiu arrecadar $16 milhões antes de seu valor despencar [1][4].


NUNCA Usar o OpenClaw em Produção

Instalar o OpenClaw, MoltBolt ou Clawdbot em um ambiente de produção é um risco inaceitável. As razões são claras:

  • Risco de Violação de Dados: A exposição de credenciais e o potencial para exfiltração de dados via injeção de prompt colocam todos os dados no sistema em risco.
  • Ponto de Entrada para a Rede: Um agente comprometido serve como uma backdoor persistente, permitindo que invasores realizem movimento lateral, escalem privilégios e comprometam toda a rede.
  • Potencial para Ransomware: Com acesso para ler e escrever arquivos, um invasor pode facilmente usar o agente para criptografar dados e exigir um resgate [4].

O uso de OpenClaw, MoltBolt ou Clawdbot em ambientes críticos, tais como áreas de saúde e ambientes industriais e de IoT pode levar a riscos consideráveis a vidas humanas.


Recomendações

Com base na análise técnica das vulnerabilidades e riscos inerentes, nossa recomendação é inequívoca:

  1. NÃO INSTALE O OPENCLAW EM AMBIENTES DE PRODUÇÃO: Nunca, sob nenhuma circunstância, esta ferramenta deve ser usada em sistemas que contenham dados reais, sensíveis ou que estejam conectados a redes corporativas.
  2. USE APENAS EM AMBIENTES TOTALMENTE ISOLADOS: Se você deseja experimentar o OpenClaw por curiosidade, faça-o em uma máquina virtual ou contêiner completamente isolado, sem acesso a dados pessoais, credenciais ou qualquer outra rede.
  3. DESCONFIE DE TODAS AS “SKILLS” DE TERCEIROS: O ecossistema de “skills” não é seguro. Trate cada extensão como um potencial malware.
  4. ENTENDA QUE A ARQUITETURA É INERENTEMENTE INSEGURA: Mesmo com configurações de segurança e firewalls, o design fundamental do OpenClaw, que concede alta autonomia e privilégios a um agente de IA, representa um risco que não pode ser totalmente mitigado no momento.

Palavras finais

O OpenClaw é um experimento fascinante sobre o futuro dos agentes de IA, mas é apenas isso: um experimento.

Sua arquitetura, embora poderosa, ignora princípios de segurança fundamentais, transformando-o em uma ferramenta perigosa nas mãos de usuários desavisados e um alvo valioso para invasores.

A conveniência oferecida não justifica o risco catastrófico que ele representa. No momento de escrita desse alerta, nossa única recomendação possível é que, Até que esses problemas fundamentais de segurança sejam resolvidos, a única abordagem sensata é manter o OpenClaw longe de qualquer sistema importante.


Referências

[1] ZDNET. “OpenClaw is a security nightmare – 5 red flags you shouldn’t ignore (before it’s too late)”. https://www.zdnet.com/article/openclaw-moltbot-clawdbot-5-reasons-viral-ai-agent-security-nightmare/

[2] Cisco Blogs. “Personal AI Agents like OpenClaw Are a Security Nightmare”. https://blogs.cisco.com/ai/personal-ai-agents-like-openclaw-are-a-security-nightmare

[3] The Hacker News. “OpenClaw Bug Enables One-Click Remote Code Execution via Malicious Link”. https://thehackernews.com/2026/02/openclaw-bug-enables-one-click-remote.html [4] Vectra AI. “From Clawdbot to OpenClaw: When Automation Becomes a Digital Backdoor”. https://www.vectra.ai/blog/clawdbot-to-moltbot-to-openclaw-when-automation-becomes-a-digital-backdoor

Vol. 1 No. 20260131-1115 (2025)

Nova fraude – Central de atendimento gov.br

João Fuzinelli | joao@cylo.com.br | 31/01/2026

Recebemos recentemente um caso onde uma conta de WhatsApp For Business se passa por uma Central de atendimento denominada: Central de Atendimento ao Cliente – Rec SS

Percebam que a empresa foi cadastrada há um mês no WhatsApp for Business.

Nesta fraude o golpista (como sempre) tenta persuadir a clicar em um link para verificar a pendência que consta no CPF da vítima.

URL

hxxps[://]consulta[.]situacaoregular[.]ch/consulta[.]html?cpf=<CPF da Vítima>

Em breve uma análise aprofundada do comportamento…

Vol. 1 No. 20260127-1101 (2025)

Atualização de Emergência Microsoft

Adriano Cansian | adriano.cansian@unesp.br | 27/01/2026

Esse é um alerta crítico. A Microsoft lançou no início da noite de ontem (26 de janeiro de 2026) uma atualização de segurança de emergência, para corrigir a vulnerabilidade zero-day CVE-2026-21509, que permite contornar de proteções contra controles inseguros nos aplicativos Microsoft Office, fazendo que um ataque possa acontecer por intermédio de um documento ou arquivo malicioso, possivelmente sem interação do usuário.

A vulnerabilidade atinge aplicações Microsoft Office / 365 tanto no Windows como no macOS (veja comentário sobre o MacOS no final dessa postagem).

Temos notícias de que vulnerabilidade essa está sendo explorada ativamente por atacantes usando documentos maliciosos.

Essa falha afeta todas as versões, tais como Office 2016, 2019, LTSC 2021/2024 e Microsoft 365 Apps Enterprise, bem como Microsoft 365 Standalone ou Famility Edition, tanto no Windows quanto no macOS.


O que fazer, imediatamente

  1. Aplique as atualizações de segurança do Microsoft Office via Microsoft Update ou WSUS.​ 
  2. Reinicie as aplicações Microsoft 365 (muito importante), ou faça um reboot.
  3. Como mitigação temporária, configure o registro do Windows com a chave “Compatibility Flags” = 0x400 em HKEY_CURRENT_USER\Software\Microsoft\Office[version]\Common para reforçar as proteções OLE.
  4. Monitore phishing com anexos Office, dado o uso em campanhas direcionadas.

Nota importante: reinicie a aplicação

Não há um “número de versão/build” específico a partir do qual se esteja seguro, pois a correção é aplicada via service-side change (mudança da regra de proteção COM/OLE nos servidores Microsoft). Assim, Office 2021 e posteriores, que estejam atualizados, ficam protegidos com a versão mais recente que você tenha testado como atualizada em 26/01/2026, e após reinício completo dos aplicativos, sem necessidade de novo patch de instalação ou alteração no número da versão local. Ou seja, se sua versão já estiver atualizada, pode ser que você não veja uma mudança no número de versão.


Severidade CVSS E EPSS

A pontuação CVSS de severidade dessa vulnerabilidade é 7.8 (alta severidade). No momento de escrita desse alerta (27/01/2026 9h43m BRT), ela ainda não possui um score EPSS (Exploit Prediction Scoring System) disponível nos dados públicos recentes, pois foi divulgada há apenas um dia (26 de janeiro de 2026). O EPSS é atualizado diariamente pela FIRST.org com base em dados de exploração real. Como ela está sendo explorada ativamente e listada no catálogo KEV da CISA, espera-se um score EPSS elevado. Verifique em https://www.first.org/epss/search?cve=CVE-2026-21509 para o valor mais atual.


Detalhamento

As proteções contra controles COM/OLE inseguros no Microsoft Office são mecanismos de segurança implementados para bloquear a execução automática de objetos “COM” (Component Object Model) e “OLE” (Object Linking and Embedding) potencialmente maliciosos.

Objetos COM/OLE perigosos são componentes ActiveX ou objetos vinculados, embutidos, anexados ou inseridos em documentos do Microsoft Office (como ícones, gráficos ou mini-aplicativos de outros programas) que podem conter código malicioso.

Eles podem explorar a confiança automática do Office para executar scripts ou payloads sem interação segura do usuário, permitindo roubo de dados, instalação de malware ou controle remoto do sistema, como observado em ataques por meio de macros VBA, arquivos HTA ou streams OLE ofuscados em documentos Word ou Excel.

A Microsoft introduziu mecanismos de mitigação, incluindo kill bits, para reduzir esses riscos, especialmente em cenários de phishing com anexos maliciosos. Em segurança cibernética, chamamos essas proteções de “kill bits“. Esses kill bits são flags de segurança no Registro do Windows que desabilitam a criação ou execução de controles ActiveX específicos no Microsoft Office. A vulnerabilidade zero-day CVE-2026-21509 no Microsoft Office explora uma falha relacionada a essa proteção, permitindo contornar a restrição imposta pelos kill bits.


Apple / macOS

A CVE-2026-21509 afeta sim o Microsoft 365 no macOS, especificamente as Microsoft 365 Apps for Enterprise, Family e Standalone (incluindo Word, Excel, PowerPoint, Outlook), pois as mitigações OLE/COM são aplicadas no cliente Office, não dependentes do Sistema Operacional.

A Microsoft confirma que para Office 2021 e posteriores (incluindo M365), a proteção é via service-side change, requerendo reinício dos apps no macOS após propagação do serviço, similar ao Windows. Verifique atualizações no Microsoft AutoUpdate no macOS e reinicie os apps para ativar a correção emergencial de 26/01/2026.

Apesar da correção ter saído ontem, 26/1/2026, no caso do macOS a versão NÃO vulnerável é a partir de, e incluindo, a Version 16.105.1, de 20/01/2026. Em outras palavras, a instalação em si não muda de número de versão via patch tradicional; o ambiente passa a ficar protegido quando o tenant já recebeu a atualização no serviço e o usuário reinicia Word/Excel/PowerPoint/Outlook, momento em que as novas mitigações OLE/COM entram em vigor.

Caso queira verificar e forçar uma atualização no macOS, os comandos via terminal são os seguintes:

cd "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS"
./msupdate --list  # Lista atualizações disponíveis
./msupdate --install  # Instala todas

Referências

[1] NVD (NIST)https://nvd.nist.gov/vuln/detail/CVE-2026-21509

[2] Microsoft MSRChttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21509

[3] Microsoft – Configurações de segurança para objetos COM no Office.

[4] Microsoft Learn – Como controlar o bloqueio de componentes OLE/COM na Assinatura do Microsoft 365

Vol. 1 No. 20260126-1096 (2025)

O XDR pode errar, o analista não!

Hector Carlos Frigo | hector@cylo.com.br | 26/01/2026

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.

Vol. 1 No. 20260123-1090 (2025)

Atualizou mas não resolveu-FortiGate segue na mira de hackers

João Paulo Gonsales | jgonsales@cylo.com.br | 23/01/2026

Apesar das atualizações, os dispositivos FortiGate permanecem vulneráveis e com explorações ativas.

A Fortinet identificou que o patch para as correções anteriores CVE-2025-59718 e CVE-2025-59719 não foi suficiente para mitigar totalmente o vetor de ataque e que permite o bypass de autenticação sem credenciais validas. Atacantes estão explorando as vulnerabilidades para alterar a configuração do firewall, criar contas maliciosas ou exfiltrar dados sensíveis.

Segue sugestões para a mitigação recomendadas pela Fortinet:

  • Limitar os IPs que podem acessar à interface de gerenciamento do firewall.
  • Restringir acesso administrativo pela internet
  • Desabilitar FortiCloud SSO para administradores

Mais informações:

FortiGate vulnerável mesmo após patches oficiais – CISO Advisor

Vol. 1 No. 20251226-1078 (2025)

Vulnerabilidades Associadas à Campanha BRICKSTORM e aos Atores UNC5221

Adriano Cansian | adriano.cansian@unesp.br | 26/12/2025

Complementando as informações sobre a campanha BRICKSTORM, sobre a qual falamos em postagem anterior.

Atribuída ao grupo UNC5221 (atores patrocinados pela China), BRICKSTORM está associada a múltiplas vulnerabilidades críticas em dispositivos de perímetro e em infraestruturas de acesso remoto. Embora BRICKSTORM em si não seja uma vulnerabilidade específica (ela é um malware do tipo “backdoor“), os atores exploram várias CVEs para obter acesso inicial aos ambientes das vítimas.

A seguir listamos todas as CVEs que apuramos estarem associadas a essa campanha. Nossa recomendação é que o leitor faça a gestão de vulnerabilidades e corrija ou mitigue essas vulnerabilidades, para evitar ser vítima dessa campanha.

Observação: os valores de EPSS foram levantados em 26/12/2025.


CVEs Explorados por UNC5221

1. CVE-2025-0282 e CVE-2025-0283 (Ivanti Connect Secure)

Tipo: Buffer Overflow / Autenticação.

Plataforma: Ivanti Connect Secure (“ICS”) VPN appliances.

Versões Afetadas: 22.7R2.5 e anteriores

Data de Divulgação: 8 de janeiro de 2025.

Severidade: Crítica

EPSS (CVE-2025-0282): 94.11% – Probabilidade muito alta de exploração nos próximos 30 dias.

EPSS (CVE-2025-0283): 22.99% – Probabilidade moderada de exploração nos próximos 30 dias.

Descrição: CVE-2025-0282 é um buffer overflow baseado em stack não autenticado que permite execução remota de código (RCE). Exploração bem-sucedida resulta em acesso não autenticado ao appliance VPN, levando a comprometimento potencial de toda a rede downstream.

Exploração por UNC5221: Zero-day exploitation começou em meados de dezembro de 2024. Após exploração, UNC5221 implanta múltiplas famílias de malware customizado incluindo ZIPLINE, THINSPOOL, LIGHTWIRE e WARPWIRE.

Técnicas Pós-Exploração:

  • Desabilitar SELinux;
  • Bloquear syslog forwarding via iptables;
  • Remontar drive como read-write;
  • Implantar web shells em getComponent.cgi e restAuth.cgi;
  • Usar PHASEJAM dropper para modificações persistentes;
  • Simular atualizações do sistema para evitar detecção.

2. CVE-2025-22457 (Ivanti Connect Secure)

Tipo: Buffer Overflow.

Plataforma: Ivanti Connect Secure VPN appliances.

Versões Afetadas: 22.7R2.5 e anteriores, 9.x (end of life).

Data de Divulgação: 3 de abril de 2025.

Severidade: Crítica.

EPSS: 49.13% – Probabilidade moderada-alta de exploração nos próximos 30 dias

Descrição: Buffer overflow que permite execução remota de código. Exploração bem-sucedida resulta em RCE no appliance VPN.

Exploração por UNC5221: Exploração ativa observada desde março de 2025. Após exploração inicial, UNC5221 implanta BRICKSTORM e outras ferramentas de backdoor para manter acesso persistente.


3. CVE-2023-46805 (Ivanti Connect Secure)

Tipo: Authentication Bypass.

Plataforma: Ivanti Connect Secure VPN.

Data de Descoberta: Dezembro de 2023.

Severidade: Crítica.

EPSS: 94.37% – Probabilidade muito alta de exploração nos próximos 30 dias.

Descrição: Bypass de autenticação que permite acesso não autorizado ao appliance.

Exploração por UNC5221: Explorado desde dezembro de 2023 como parte de campanha de longa duração. Combinado com CVE-2024-21887 para obter acesso inicial.

Malware Implantado: ZIPLINE (passive backdoor), THINSPOOL (dropper), LIGHTWIRE (web shell), WARPWIRE (credential harvester).


4. CVE-2024-21887 (Ivanti Connect Secure)

Tipo: Command Injection.

Plataforma: Ivanti Connect Secure VPN.

Data de Descoberta: 2023-2024.

Severidade: Crítica.

EPSS: 94.41% – Probabilidade muito alta de exploração nos próximos 30 dias.

Descrição: Injeção de comando que permite execução de comandos arbitrários.

Exploração por UNC5221: Explorado em conjunto com CVE-2023-46805 para obter acesso inicial e executar código malicioso.


5. CVE-2023-4966 (Citrix NetScaler ADC/Gateway)

Tipo: Divulgação de Informação Sensível / Buffer Overflow.

Plataforma: Citrix NetScaler ADC e NetScaler Gateway appliances.

Severidade: Crítica.

EPSS: 94.35% – Probabilidade muito alta de exploração nos próximos 30 dias.

Exploração por UNC5221: Zero-day exploitation documentado. Parte do histórico de UNC5221 de exploração de zero-days em dispositivos edge.


Relação com BRICKSTORM

Como já mencionado, BRICKSTORM não é uma vulnerabilidade específica, mas sim um malware backdoor implantado após exploração bem-sucedida de uma das CVEs acima. O fluxo típico de ataque é:

  1. Acesso Inicial: Exploração de CVE em dispositivo edge (Ivanti, NetScaler, etc.).
  2. Implantação de Malware: Após RCE, UNC5221 implanta BRICKSTORM ou outras ferramentas de backdoor.
  3. Persistência: BRICKSTORM estabelece comunicação C2 criptografada e permite movimento lateral.
  4. Movimento Lateral: BRICKSTORM facilita acesso a VMware vCenter, controladores de domínio e outros sistemas críticos.

Ecosistema de Malware Associado

UNC5221 utiliza um ecosistema de malware sofisticado chamado SPAWN, que inclui:

  • SPAWNANT: Installer/loader.
  • SPAWNMOLE: Tunneler para movimento lateral.
  • SPAWNSNAIL: SSH backdoor.
  • SPAWNCHIMERA: Variante adicional
  • ZIPLINE: Passive backdoor.
  • THINSPOOL: Dropper.
  • LIGHTWIRE: Web shell.
  • WARPWIRE: Credential harvester.
  • PHASEJAM: Dropper específico para Ivanti.
  • BRICKSTORM: Backdoor para VMware e Windows.

Padrão Operacional de UNC5221

  1. Foco em Edge Devices: Preferência consistente por exploração de vulnerabilidades em appliances de perímetro (VPN, load balancers, etc.).
  2. Zero-Day Exploitation: Histórico de acesso e exploração de vulnerabilidades zero-day.
  3. Desenvolvimento Ativo: Contínuo desenvolvimento e modificação de malware.
  4. Ofuscação de Origem: Uso de redes de appliances comprometidos (Cyberoam, QNAP, ASUS routers) para mascarar origem real.
  5. Movimento Lateral Sofisticado: Após acesso inicial, movimento lateral para infraestrutura crítica com mínima telemetria
  6. Persistência de Longo Prazo: Tempo médio de permanência não detectada de 393 dias.

O Tempo médio de permanência não detectada do BRICKSTORM é de 393 dias


Recomendações

  1. Manter patches atualizados em todos appliances edge.
  2. Implementar monitoramento especializado em dispositivos VPN e load balancers.
  3. Usar MFA em todos acessos administrativos.
  4. Implementar segmentação de rede adequada.
  5. Monitorar atividades de reconhecimento (requisições sequenciais de versão).
  6. Realizar busca ativa (hunt) por artefatos de BRICKSTORM em VMware vCenter.

Referências

  • Google Threat Intelligence Group. “Ivanti Connect Secure VPN Targeted in New Zero-Day Exploitation.” 8/12/2025
  • Google Threat Intelligence Group. “Suspected China-Nexus Threat Actor Actively Exploiting Critical Ivanti Connect Secure Vulnerability (CVE-2025-22457).” 3/04/2025
  • Mandiant Services. “Another BRICKSTORM: Stealthy Backdoor Enabling Espionage into Tech and Legal Sectors.” 24/09/2025
  • CISA. “BRICKSTORM Backdoor – Malware Analysis Report (AR25-338A).” 19/12/2025

Vol. 1 No. 20251224-1075 (2025)

BRICKSTORM: A sofisticação silenciosa de um backdoor patrocinado por Estado

Adriano Cansian | adriano.cansian@unesp.br | 24/12/2025

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.


Referências

  1. CISA. (2025, December 4). “PRC State-Sponsored Actors Use BRICKSTORM Malware Across Public Sector and Information Technology.https://www.cisa.gov/news-events/alerts/2025/12/04/prc-state-sponsored-actors-use-brickstorm-malware-across-public-sector-and-information-technology
  2. CISA. (2025, December 19 ). “BRICKSTORM Backdoor – Malware Analysis Report (AR25-338A).” https://www.cisa.gov/news-events/analysis-reports/ar25-338a
  3. NSA. (2025, December 4 ). “NSA Joins CISA to Release Guidance on Detecting BRICKSTORM Backdoor Activity.” https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4348338/
  4. Canadian Centre for Cyber Security. (2025, December 4 ). “Joint Malware Analysis Report on Brickstorm Backdoor.https://www.cyber.gc.ca/en/news-events/joint-malware-analysis-report-brickstorm-backdoor
  5. Google Threat Intelligence Group & Mandiant. (2025, September 24 ). “Another BRICKSTORM: Stealthy Backdoor Enabling Espionage into Tech and Legal Sectors.https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign

Vol. 1 No. 20251222-1002 (2025)

Incidente como presente de Natal?

Hector Carlos Frigo | hector@cylo.com.br | 22/12/2025

O período de festas está se aproximando e, com ele, o tão esperado “recesso de fim de ano”, época muito aguardada por trabalhadores que buscam aproveitar esse momento para passar tempo com a família e descansar. Como sempre, nem tudo são flores. Sendo assim, nesta minha abordagem, gostaria de levantar alguns alertas que devem ser considerados e que, caso sejam desprezados, podem resultar no recebimento de uma ligação desesperada do seu gestor às 3:00 da manhã, na madrugada do dia de Natal.

Menor Contingente, maiores riscos!

Neste período do ano, empresas costumam atuar com equipes reduzidas, fato que resulta em um número notavelmente menor de colaboradores ativos e capazes de identificar mudanças ou mau funcionamento dos sistemas utilizados internamente. Os atacantes sabem disso e abusam dessa situação. Afinal, quanto menos olhos voltados para ações disruptivas no sistema, maior a chance de um ataque cibernético passar despercebido.

A diminuição do contingente pode afetar diretamente o tempo de resposta dos potenciais incidentes, fazendo com que alertas se acumulem, investigações sejam postergadas e ações de contenção ocorram de maneira tardia.

Atente-se às promoções relâmpago de fim de ano!

Todo mundo já recebeu aquele e-mail de origem duvidosa informando que está ocorrendo uma promoção “imperdível” do panetone que antes custava R$ 300,00 e que, para você, sortudo(a), está agora custando “APENAS” R$ 29,99. Lembre-se: o barato pode sair caro. O número de casos de golpes, fraudes e phishing aumenta gradativamente em períodos festivos, portanto, fique alerta, desconfie!

Se não for crítico ou essencial; Desative! Desligue! Esconda!

Muitas atividades são pausadas no ambiente corporativo durante o fim do ano, por inúmeros motivos, desde a reformulação de processos internos até transições de ferramentas. Com base nisso, muitos serviços ativos, como páginas publicadas na internet e servidores com portas RDP expostas para o mundo, acabam sendo esquecidos e permanecem em operação sem o devido gerenciamento e cuidado. Lembre-se: serviços ativos esquecidos podem servir como um convite para a ceia de Natal destinada a atores maliciosos.

Aproveite o período de festas de fim de ano com menos preocupações

Seguindo alguns passos simples, é possível reduzir muito sua superfície de ataque. Isso não significa que você não sofrerá um ataque cibernético neste fim de ano, porém, ao seguir essas dicas, garanto que os riscos serão bem menores, e as chances de aproveitar as festas de fim de ano sem maiores problemas são mais favoráveis.

  • Desative contas de serviço que não serão utilizadas nesse período festivo
  • Faça uma revisão na sua rede em busca de serviços não essenciais ativos e expostos para a internet
  • Desconfie de promoções milagrosas, consulte a informação nos sites oficiais
  • Não deixe correções de vulnerabilidades para o ano que vem, pode ser tarde demais!
  • Não ignore os alertas de segurança, eles não são enfeites de árvore de Natal
  • Revise políticas de senhas de usuários e ativação de MFA

Fontes

https://securityleaders.com.br/golpes-ciberneticos-disparam-no-fim-de-ano-afirma-analise

https://exame.com/tecnologia/final-do-ano-se-consolida-como-periodo-de-maior-risco-cibernetico-no-brasil

https://www.tecmundo.com.br/seguranca/409449-cibercriminosos-intensificam-ataques-no-fim-de-ano-com-golpes-de-natal.htm