Um novo trojan bancário brasileiro, identificado como TCLBANKER, foi descoberto por pesquisadores da Elastic Security Labs em uma campanha capaz de atingir 59 plataformas financeiras, incluindo bancos, fintechs e serviços de criptomoedas. A atividade está sendo rastreada sob o nome REF3076 e, segundo a análise, representa uma grande atualização da família Maverick, conhecida por utilizar o worm SORVEPOTEL para se espalhar pelo WhatsApp Web entre contatos das vítimas. A campanha anterior associada ao Maverick já havia sido atribuída pela Trend Micro ao grupo Water Saci. A nova operação chama atenção por combinar um trojan bancário completo com mecanismos de propagação automatizada via WhatsApp e Microsoft Outlook. Na prática, os invasores abusam de contas legítimas das próprias vítimas para enviar mensagens e e-mails maliciosos a contatos conhecidos, aumentando a chance de confiança e dificultando a detecção por filtros tradicionais de reputação e gateways de e-mail. De acordo com os pesquisadores Jia Yu Chan, Daniel Stepanic, Seth Goodwin e Terrance DeJesus, a cadeia de infecção observada começa com um arquivo ZIP contendo um instalador MSI malicioso. Esse instalador abusa de um programa legítimo e assinado da Logitech, chamado Logi AI Prompt Builder, para executar a ameaça por meio de uma técnica conhecida como DLL side-loading. Essa abordagem permite que um arquivo malicioso seja carregado por um software confiável, reduzindo suspeitas durante a execução. O componente malicioso, identificado como “screen_retriever_plugin.dll”, atua como loader e possui recursos avançados contra análise. Ele verifica continuamente a presença de ferramentas de depuração, sandboxes, disassemblers, soluções antivírus, ferramentas de instrumentação e outros mecanismos usados por pesquisadores e produtos de segurança. O objetivo é impedir que o malware seja estudado ou executado em ambientes controlados. A DLL só continua sua execução se for carregada pelo “logiaipromptbuilder.exe”, o programa legítimo da Logitech, ou pelo “tclloader.exe”, que parece ser um executável usado em testes. O malware também remove hooks em modo de usuário inseridos por soluções de segurança na biblioteca “ntdll.dll” e desativa a telemetria do Event Tracing for Windows, conhecido como ETW, reduzindo a visibilidade das ferramentas de monitoramento. Outro ponto relevante é o uso de três impressões digitais do ambiente infectado. O TCLBANKER realiza checagens anti-debugging e anti-virtualização, coleta informações do disco do sistema e verifica o idioma configurado no dispositivo. Esses dados são usados para gerar um hash do ambiente, necessário para descriptografar o payload embutido. Caso um depurador esteja presente, por exemplo, o hash gerado será incorreto, impedindo a descriptografia correta do malware e interrompendo sua execução. A verificação de idioma também restringe a operação a sistemas configurados em português do Brasil, indicando foco claro no mercado brasileiro. Após passar por essas validações, o componente principal do trojan bancário confirma novamente se está sendo executado em um ambiente brasileiro e cria persistência por meio de uma tarefa agendada no Windows. Em seguida, ele se comunica com um servidor externo via requisição HTTP POST, enviando informações básicas do sistema comprometido. O TCLBANKER possui ainda um mecanismo de autoatualização e um monitor de URLs capaz de extrair o endereço acessado no navegador em primeiro plano usando UI Automation. A técnica permite acompanhar a navegação da vítima em navegadores populares, como Google Chrome, Mozilla Firefox, Microsoft Edge, Brave, Opera e Vivaldi. Quando a URL acessada corresponde a uma instituição financeira presente em uma lista codificada no malware, o trojan estabelece uma conexão WebSocket com um servidor remoto e entra em um ciclo de recebimento de comandos. A partir daí, os operadores podem executar comandos no sistema, capturar telas, iniciar ou interromper streaming da tela, manipular a área de transferência, ativar keylogger, controlar mouse e teclado remotamente, gerenciar arquivos e processos, enumerar processos em execução, listar janelas visíveis e exibir sobreposições falsas para roubo de credenciais. Para conduzir o roubo de dados, o TCLBANKER usa uma estrutura de sobreposição em tela cheia baseada em Windows Presentation Foundation, tecnologia conhecida como WPF. Essas telas falsas são usadas em ações de engenharia social, incluindo prompts para coleta de credenciais, telas de espera associadas a vishing, barras de progresso falsas e falsas atualizações do Windows. O malware também tenta ocultar essas sobreposições de ferramentas de captura de tela, dificultando a análise e a resposta ao incidente. Além do roubo direto de credenciais e do controle remoto, a campanha inclui um módulo de propagação em larga escala. O loader aciona um componente de worm que explora duas frentes: um worm para WhatsApp Web, capaz de sequestrar sessões autenticadas no navegador, e um bot de e-mail que abusa do Microsoft Outlook instalado no computador da vítima para enviar mensagens de phishing a partir da conta legítima comprometida. No caso do WhatsApp, a abordagem lembra a usada pelo SORVEPOTEL. O worm obtém um modelo de mensagem a partir do servidor dos invasores e usa o projeto open source WPPConnect para automatizar o envio de mensagens. O componente também filtra grupos, listas de transmissão e números que não sejam brasileiros, reforçando o foco geográfico da campanha. Já o agente de Outlook funciona como um spambot. Ele utiliza o próprio aplicativo Microsoft Outlook instalado no dispositivo para enviar e-mails falsos a partir do endereço da vítima. Essa técnica aumenta a credibilidade da mensagem, já que o conteúdo chega a partir de uma conta conhecida, e pode contornar defesas baseadas em reputação de remetente ou infraestrutura. Segundo um porta-voz da Elastic ouvido pelo The Hacker News, o TCLBANKER pode sequestrar sessões do WhatsApp e contas do Outlook para enviar o instalador trojanizado a até 3 mil contatos. A distribuição ocorre por contas legítimas, contatos reais e infraestrutura confiável, o que reduz a eficácia de defesas tradicionais baseadas apenas em reputação. A análise também indica que a operação REF3076 ainda pode estar em estágio inicial. Os pesquisadores encontraram caminhos de debug, nomes de processos usados em testes e um site de phishing incompleto no código. Esses sinais sugerem que a campanha ainda está em desenvolvimento e pode ganhar novos recursos ou ajustes operacionais com o tempo. Para a Elastic, o TCLBANKER reflete um amadurecimento mais amplo no ecossistema brasileiro de trojans bancários. Técnicas antes associadas a invasores mais sofisticados, como descriptografia condicionada ao ambiente, geração direta de syscalls, orquestração de engenharia social em tempo real via WebSocket e abuso de canais legítimos de comunicação, estão sendo incorporadas a ferramentas de cibercrime mais acessíveis. O caso também mostra uma mudança relevante no modelo de distribuição de malware bancário. Em vez de depender apenas de domínios suspeitos, campanhas massivas de spam ou anexos enviados por remetentes desconhecidos, os operadores do TCLBANKER exploram a confiança já existente entre vítima e contatos. Isso torna o ataque mais difícil de identificar, especialmente em ambientes onde WhatsApp e Outlook são usados diariamente para comunicação pessoal e profissional.

Ramon Risuenho, consultor de cibersegurança especializado em Cloud Security, Security Operations e Google Cloud Platform, anunciou nesta semana a criação de um projeto educacional voltado a pessoas que desejam aprender comandos Linux, mas não possuem todos os recursos necessários para montar um ambiente virtualizado de estudos em casa. A iniciativa foi desenvolvida com apoio de inteligência artificial e tem como objetivo facilitar o acesso ao aprendizado prático do terminal Linux, uma habilidade considerada essencial para quem atua ou deseja ingressar em áreas como segurança da informação, infraestrutura, cloud, DevOps, SOC e resposta a incidentes. Segundo Ramon, o projeto foi pensado para ensinar os 30 comandos mais utilizados em ambientes Linux. A proposta inclui desde comandos básicos, usados para navegação no sistema de arquivos, cópia e manipulação de arquivos, até atividades um pouco mais avançadas, como leitura de arquivos de log e identificação de processos ocultos. A principal diferença da iniciativa está no fato de o ambiente funcionar diretamente pelo navegador. Isso reduz a barreira de entrada para estudantes que não têm computador com boa capacidade de processamento, não conseguem configurar máquinas virtuais ou ainda não estão familiarizados com ferramentas como VirtualBox, VMware, WSL ou laboratórios em nuvem. Em treinamentos de cibersegurança, o uso de ambientes Linux costuma ser uma etapa importante, mas também pode se tornar um obstáculo inicial. Muitos estudantes precisam instalar uma distribuição Linux, configurar uma máquina virtual, reservar memória e armazenamento, lidar com erros de rede ou permissões e, só depois disso, começar a praticar os comandos básicos. O projeto busca simplificar esse caminho ao oferecer uma experiência acessível diretamente no browser. Além do aprendizado guiado, Ramon também implementou um pequeno CTF, sigla para Capture The Flag, um formato de desafio muito usado na comunidade de segurança cibernética. Nesse tipo de exercício, os participantes resolvem tarefas técnicas e encontram “flags”, que funcionam como provas de que determinada etapa foi concluída corretamente. No contexto do projeto, o CTF serve como forma de incentivar a prática e transformar o estudo em uma experiência mais interativa. A abordagem pode beneficiar tanto iniciantes que ainda estão aprendendo a usar o terminal quanto profissionais que já conhecem Linux, mas estão há algum tempo sem praticar e querem recuperar familiaridade com os comandos. Entre as funcionalidades destacadas estão a interface responsiva, o aprendizado guiado, o sistema de pontuação e a possibilidade de executar os exercícios diretamente pelo navegador. Esses elementos aproximam o projeto de uma experiência de laboratório educacional, com foco em simplicidade, prática e acessibilidade. A interface responsiva permite que o conteúdo se adapte a diferentes tamanhos de tela, facilitando o acesso por computadores, notebooks e, dependendo da experiência oferecida, até dispositivos móveis. Já o sistema de pontuação adiciona um elemento de gamificação, ajudando o usuário a acompanhar sua evolução conforme avança pelos desafios. A iniciativa também acompanha uma tendência maior no ensino de tecnologia: a criação de laboratórios práticos mais leves, acessíveis e orientados por desafios. Em cibersegurança, esse modelo é especialmente relevante, pois muitos conceitos só se tornam claros quando o aluno interage com comandos, arquivos, logs, permissões, processos e cenários próximos da prática real. O domínio de comandos Linux é uma habilidade recorrente em diversas funções técnicas. Analistas de SOC usam o terminal para investigar logs e eventos. Profissionais de cloud interagem com servidores, containers e ferramentas de automação. Equipes de resposta a incidentes analisam processos, arquivos suspeitos e rastros de execução. Já estudantes de segurança ofensiva e defensiva dependem do Linux para trabalhar com ferramentas, scripts e ambientes de teste. Embora o projeto tenha sido descrito como simples, ele atende a uma necessidade comum entre iniciantes: começar a praticar sem depender de infraestrutura complexa. Para quem está dando os primeiros passos, conseguir executar comandos básicos, entender a estrutura de diretórios, listar arquivos, ler conteúdos e observar processos já representa uma base importante para estudos mais avançados. Ramon também abriu espaço para que usuários deixem feedbacks nos comentários, indicando que o projeto pode evoluir a partir da experiência da comunidade. Esse tipo de retorno pode ajudar a expandir os desafios, ajustar a dificuldade, incluir novos comandos e tornar o laboratório mais útil para diferentes níveis de conhecimento. O projeto está disponível no link divulgado pelo próprio autor e foi apresentado como uma contribuição para democratizar o acesso ao aprendizado prático em Linux. Em um mercado que exige cada vez mais conhecimento técnico, iniciativas desse tipo ajudam a reduzir barreiras e aproximar novos profissionais de habilidades fundamentais para a área de tecnologia e cibersegurança.

Um site falso que imita a página do Claude AI está sendo usado para distribuir um instalador malicioso chamado Claude-Pro Relay, que instala uma backdoor para Windows até então não documentada, batizada de Beagle por pesquisadores da Sophos. A campanha tenta se aproveitar da popularidade do Claude, modelo de linguagem e assistente de inteligência artificial da Anthropic, para enganar desenvolvedores e usuários interessados em ferramentas relacionadas ao Claude-Code. No site fraudulento, os hackers promovem o suposto Claude-Pro como um “serviço de relay de alta performance desenvolvido especificamente para desenvolvedores Claude-Code”. A página falsa, hospedada em claude-pro[.]com, tenta reproduzir visualmente o site legítimo, usando cores e fontes semelhantes. Ainda assim, a imitação é relativamente simples. De acordo com a Sophos, os links do site não levam a páginas funcionais e apenas redirecionam o visitante para a página inicial, deixando praticamente uma única ação disponível: clicar em um grande botão de download. Esse botão baixa um arquivo de 505 MB chamado Claude-Pro-windows-x64.zip, que contém um instalador MSI supostamente relacionado ao produto Claude-Pro Relay. Para usuários que não percebem os sinais de fraude, o arquivo pode parecer uma ferramenta legítima, especialmente por usar a marca Claude e se apresentar como uma solução voltada a desenvolvedores. Ao executar o binário, o instalador adiciona três arquivos à pasta de inicialização do Windows: NOVupdate.exe, NOVupdate.exe.dat e avk.dll. Essa localização é relevante porque itens colocados na pasta Startup podem ser executados automaticamente quando o usuário inicia a sessão no sistema, funcionando como um mecanismo simples de persistência. A campanha foi inicialmente identificada pela Malwarebytes. Segundo os pesquisadores da empresa, o instalador “Pro” é uma cópia trojanizada do Claude: a aplicação funciona como esperado, mas executa uma cadeia de malware PlugX em segundo plano, permitindo que os invasores obtenham acesso remoto ao sistema comprometido. Em uma análise mais aprofundada, a Sophos identificou que o primeiro estágio da infecção envolve o DonutLoader, um injetor em memória de código aberto. Ele é usado para carregar uma backdoor relativamente simples, chamada pelos pesquisadores de Beagle. O malware possui um conjunto limitado de comandos, incluindo desinstalar o agente, executar comandos, enviar e baixar arquivos, criar diretórios, renomear arquivos, listar conteúdo de pastas e remover arquivos. A Sophos destaca que essa backdoor Beagle não deve ser confundida com o worm Beagle, também conhecido como Bagle, escrito em Delphi e documentado em 2004. Apesar do nome semelhante, trata-se de uma ameaça distinta. A cadeia de ataque observada explora uma técnica conhecida como DLL sideloading. Nesse caso, o arquivo NOVupdate.exe é um atualizador assinado de soluções de segurança da G Data. Os hackers abusam desse executável legítimo para carregar a DLL maliciosa avk.dll e o arquivo criptografado NOVupdate.exe.dat. O uso de um executável assinado por um fornecedor legítimo ajuda a dar aparência de confiabilidade à execução e pode dificultar a detecção por algumas soluções de segurança. Segundo a Sophos, o sideloading da DLL AVK junto com um arquivo criptografado por meio de um executável assinado da G Data já foi associado anteriormente a atividades envolvendo PlugX. Na prática, a função da DLL maliciosa é descriptografar e executar em memória o conteúdo armazenado em NOVupdate.exe.dat. Esse conteúdo é o DonutLoader, que por sua vez carrega a carga final: a backdoor Beagle. A execução em memória é uma técnica comum para reduzir rastros no disco e tentar escapar de mecanismos tradicionais de detecção. A Sophos afirma já ter observado o DonutLoader em ataques de 2024 contra organizações governamentais no Sudeste Asiático. Nesta campanha, o carregador é usado para implantar o Beagle diretamente na memória do sistema, reforçando a tentativa dos operadores de reduzir a visibilidade da infecção. Após a instalação, a backdoor se comunica com o servidor de comando e controle, conhecido como C2, em license[.]claude-pro[.]com. A comunicação ocorre por TCP na porta 443 e/ou por UDP na porta 8080. As trocas de dados são protegidas por uma chave AES embutida no malware. A infraestrutura de C2 foi associada ao endereço IP 8.217.190[.]58. Segundo a Malwarebytes, esse IP pertence a uma faixa relacionada ao serviço Alibaba Cloud. A presença de infraestrutura em provedores de nuvem não é incomum em campanhas maliciosas, já que esses ambientes podem ser usados para hospedar rapidamente servidores de controle, páginas falsas e recursos de distribuição. A investigação da Sophos também encontrou amostras adicionais relacionadas ao Beagle enviadas ao VirusTotal entre fevereiro e abril deste ano. Essas amostras usavam a mesma chave XOR para descriptografia, sugerindo algum grau de reutilização de componentes ou de infraestrutura pelos responsáveis. Apesar da relação técnica com Beagle, essas outras amostras chegaram às máquinas por cadeias de ataque diferentes. Entre os elementos observados estavam binários do Microsoft Defender, shellcode do AdaptixC2, um PDF usado como isca e páginas falsas que imitavam sites de atualização de fornecedores de segurança, incluindo CrowdStrike, SentinelOne e Trellix. Embora a Sophos não tenha atribuído a campanha com confiança a um grupo específico, os pesquisadores levantam a possibilidade de que os mesmos operadores associados ao PlugX estejam experimentando uma nova carga maliciosa. PlugX é uma família de malware historicamente usada em campanhas de acesso remoto e espionagem, frequentemente associada a operações direcionadas. A recomendação para reduzir o risco é baixar o Claude apenas pelo portal oficial e evitar resultados patrocinados em mecanismos de busca, especialmente quando promovem instaladores, ferramentas auxiliares ou versões “Pro” não verificadas. A Sophos também aponta que a presença de arquivos com o nome NOVupdate em um sistema pode ser um forte indicativo de comprometimento. Para equipes de segurança, a campanha reforça a necessidade de monitorar execuções suspeitas na pasta Startup, uso anômalo de executáveis assinados, carregamento incomum de DLLs, conexões para domínios recém-criados e comunicação com infraestrutura externa nas portas 443 e 8080. Em ambientes corporativos, controles de allowlist, verificação de origem de instaladores e bloqueio de sites falsos podem ajudar a reduzir a exposição a esse tipo de ameaça.

Uma vulnerabilidade crítica na biblioteca vm2, usada para executar código JavaScript não confiável em ambientes isolados no Node.js, permite que invasores escapem do sandbox e executem comandos arbitrários no sistema host. A falha foi registrada como CVE-2026-26956 e teve código de prova de conceito, conhecido como PoC, publicado publicamente. O problema foi confirmado na versão 3.10.4 do vm2, embora versões anteriores também possam estar vulneráveis. Segundo o aviso de segurança divulgado pelo mantenedor, a vulnerabilidade afeta ambientes com Node.js 25, com confirmação no Node.js 25.6.1, quando estão habilitados os recursos WebAssembly exception handling e JSTag support. O vm2 é uma biblioteca open source bastante utilizada no ecossistema Node.js para executar scripts JavaScript fornecidos por usuários dentro de um ambiente restrito. Esse tipo de recurso é comum em plataformas de programação online, ferramentas de automação, aplicações SaaS e serviços que permitem a execução controlada de código enviado por terceiros. A proposta do vm2 é isolar o código executado no sandbox e impedir que ele acesse APIs sensíveis do Node.js, como o objeto process e o sistema de arquivos. Na prática, isso significa bloquear a interação direta entre o código não confiável e recursos internos do servidor, reduzindo o risco de execução indevida de comandos, leitura de arquivos ou manipulação do ambiente de hospedagem. A biblioteca tem ampla adoção, com mais de 1,3 milhão de downloads semanais no npm, o gerenciador de pacotes padrão do Node.js. Esse volume de uso aumenta a relevância da falha, especialmente para empresas que dependem de sandboxes JavaScript em produtos expostos à internet ou em fluxos automatizados de execução de código. A CVE-2026-26956 está relacionada ao tratamento incorreto de exceções que atravessam a fronteira entre o ambiente isolado e o sistema host. De acordo com o aviso de segurança, o vm2 normalmente depende de proteções implementadas no nível do JavaScript para impedir que erros originados no host sejam expostos ao sandbox sem controle. A biblioteca também utiliza proxies de ponte, conhecidos como bridge Proxies, para encapsular objetos que cruzam diferentes contextos de execução. O ponto crítico está no comportamento do WebAssembly exception handling. Esse recurso consegue interceptar erros JavaScript em uma camada mais baixa dentro do motor V8, usado pelo Node.js e pelo Google Chrome. Com isso, determinadas exceções podem contornar as defesas implementadas pelo vm2 no nível da linguagem JavaScript. A exploração descrita no aviso envolve a geração de um TypeError especialmente construído por meio da conversão de Symbol para string. Esse processo pode fazer com que um objeto de erro originado no host seja vazado de volta para dentro do sandbox sem passar pela sanitização esperada pelo vm2. Uma vez que esse objeto vem do ambiente host, o invasor pode abusar de sua cadeia de construtores para recuperar acesso a componentes internos do Node.js, incluindo o objeto process. A partir desse acesso, torna-se possível alcançar a execução arbitrária de comandos no sistema subjacente, comprometendo diretamente a segurança do servidor. O aviso de segurança do mantenedor inclui uma prova de conceito que demonstra a execução remota de código na máquina host. A publicação de um PoC aumenta a urgência da correção, já que reduz a barreira técnica para que a falha seja testada ou incorporada em ataques reais, especialmente contra aplicações que executam código JavaScript fornecido por usuários. A recomendação para administradores e desenvolvedores é atualizar o vm2 para a versão 3.10.5 ou superior o quanto antes. Segundo o texto original, a versão mais recente disponível é a 3.11.2. Organizações que usam Node.js 25 com os recursos afetados habilitados devem priorizar a atualização e revisar se seus serviços permitem a execução de scripts externos ou enviados por usuários. A falha também se soma a um histórico recente de vulnerabilidades críticas envolvendo escape de sandbox no vm2. No início de 2026, a biblioteca já havia sido impactada por outra falha crítica, rastreada como CVE-2026-22709, também com potencial para execução arbitrária de código no host. Casos anteriores incluem as vulnerabilidades CVE-2023-30547, CVE-2023-29017 e CVE-2022-36067. A recorrência desse tipo de problema evidencia a dificuldade técnica de isolar código não confiável em ambientes JavaScript, especialmente quando a segurança depende da separação entre contextos, tratamento seguro de exceções e bloqueio de acesso a objetos internos do runtime. Para equipes de segurança, o risco é mais relevante em aplicações que oferecem execução dinâmica de código, automações com scripts customizados, ambientes de avaliação online, sistemas de plugins e plataformas SaaS com lógica programável pelo usuário. Nesses cenários, uma falha de sandbox pode transformar um recurso legítimo da aplicação em um caminho para controle do servidor. Além da atualização da biblioteca, é recomendável revisar a exposição desses ambientes, restringir permissões do processo Node.js, aplicar controles de isolamento adicionais no sistema operacional ou em containers, monitorar tentativas de exploração e auditar dependências que utilizem vm2 de forma direta ou indireta.

Pesquisadores divulgaram detalhes de um novo backdoor para Linux chamado PamDOORa, anunciado no fórum russo de cibercrime Rehub por US$ 1.600 por um invasor identificado como “darkworm”. A ferramenta foi apresentada como um kit de pós-exploração baseado em módulos PAM, com foco em persistência via SSH e roubo de credenciais de usuários legítimos. O PamDOORa foi projetado para funcionar como um Pluggable Authentication Module, ou PAM, uma estrutura usada em sistemas Unix e Linux para integrar mecanismos de autenticação de forma modular. Na prática, o PAM permite que administradores adicionem ou alterem métodos de autenticação, como senhas, tokens ou biometria, sem reescrever aplicações já existentes. De acordo com Assaf Morag, pesquisador da Flare.io, o PamDOORa atua como um backdoor pós-exploração para autenticação em servidores via OpenSSH. A ferramenta supostamente mantém persistência em sistemas Linux x86_64 e permite que o invasor acesse o ambiente comprometido por meio de uma combinação específica de senha “mágica” e porta TCP. Esse tipo de mecanismo cria uma porta de entrada secreta no processo de autenticação. Mesmo que o serviço SSH continue funcionando aparentemente de forma normal para usuários legítimos, o módulo malicioso pode reconhecer uma senha especial e permitir o acesso do invasor, contornando os fluxos tradicionais de autenticação. Além da persistência, o PamDOORa também foi desenvolvido para capturar credenciais. Quando usuários legítimos se autenticam no sistema comprometido, o módulo pode coletar os dados informados durante o processo de login. Como o PAM participa diretamente da autenticação, um módulo malicioso posicionado nesse fluxo pode ter acesso a informações sensíveis antes que elas sejam validadas ou descartadas pelo sistema. A ameaça chama atenção porque os módulos PAM normalmente são executados com privilégios elevados, muitas vezes como root. Isso significa que um módulo comprometido, mal configurado ou criado com finalidade maliciosa pode representar um risco significativo, permitindo roubo de credenciais, acesso não autorizado e controle persistente do host. O PamDOORa é apontado como o segundo backdoor Linux conhecido a mirar diretamente a pilha PAM, após o Plague. Embora o PAM seja uma estrutura poderosa e amplamente utilizada, sua modularidade também amplia a superfície de ataque quando arquivos de configuração ou módulos são manipulados por invasores. A Group-IB já havia alertado, em setembro de 2024, que modificações maliciosas em módulos PAM podem criar backdoors ou roubar credenciais de usuários. O risco é agravado pelo fato de que o PAM não armazena senhas, mas pode transmitir valores em texto claro durante determinados fluxos de autenticação, dependendo da implementação e do módulo utilizado. Um dos pontos citados por pesquisadores é o abuso do módulo pam_exec, que permite executar comandos externos durante processos de autenticação. Quando manipulado por invasores, esse recurso pode ser usado para injetar scripts maliciosos em arquivos de configuração do PAM, obter um shell privilegiado e manter persistência de forma discreta no sistema. No caso do PamDOORa, a análise da Flare.io indica que a ferramenta vai além de backdoors PAM mais simples encontrados em repositórios públicos. Além de roubar credenciais e permitir acesso persistente via SSH, o malware incorpora capacidades antiforenses para adulterar logs de autenticação e apagar rastros da atividade maliciosa. Essa manipulação de registros é relevante porque logs de autenticação estão entre os principais artefatos usados por equipes de segurança para identificar acessos suspeitos, tentativas de login, uso indevido de contas e movimentações anômalas. Ao alterar metodicamente esses registros, o backdoor pode dificultar investigações e atrasar a resposta a incidentes. Até o momento, não há evidências de que o PamDOORa tenha sido usado em ataques reais. Ainda assim, a cadeia de infecção mais provável envolveria um invasor obtendo previamente acesso root ao sistema por outro meio, como exploração de vulnerabilidade, credenciais comprometidas ou configuração insegura. Depois disso, o módulo PAM malicioso seria implantado para capturar credenciais e garantir acesso persistente via SSH. Esse ponto é importante: o PamDOORa não parece ser descrito como uma ferramenta de acesso inicial. Ele se encaixa melhor em uma fase posterior da invasão, quando o invasor já comprometeu o host e busca manter presença, ampliar acesso e coletar credenciais de outros usuários que utilizam o sistema. A dinâmica comercial da ferramenta também foi observada pelos pesquisadores. O PamDOORa foi inicialmente anunciado por US$ 1.600 em 17 de março de 2026. Em 9 de abril, o preço havia sido reduzido para US$ 900, uma queda de quase 50%. Essa mudança pode indicar baixa demanda entre compradores ou uma tentativa do operador “darkworm” de acelerar a venda. Para Morag, o PamDOORa representa uma evolução em relação aos backdoors PAM open source existentes. Embora técnicas como hooks em PAM, captura de credenciais e adulteração de logs já sejam conhecidas, a integração desses recursos em um implante modular, com mecanismos anti-debugging, gatilhos baseados em rede e pipeline de builder, aproxima a ferramenta de um nível mais operacional. Esse tipo de desenvolvimento mostra como recursos tradicionalmente associados a provas de conceito podem ser reorganizados em ferramentas mais completas para uso por operadores de intrusão. Em vez de scripts isolados e rudimentares, o PamDOORa aparece como um pacote mais coeso, voltado para persistência, furtividade e coleta de credenciais em ambientes Linux. Para equipes de segurança, a descoberta reforça a necessidade de monitorar alterações em módulos e arquivos de configuração do PAM, especialmente em servidores expostos ou críticos. Mudanças inesperadas em diretórios como /etc/pam.d/, presença de módulos desconhecidos, alterações em fluxos de autenticação SSH e inconsistências em logs devem ser tratadas como sinais relevantes de possível comprometimento. Também é importante revisar permissões, integridade de arquivos sensíveis, histórico de autenticação, uso de contas privilegiadas e eventos relacionados ao OpenSSH. Em ambientes corporativos, controles como gestão rigorosa de acesso administrativo, hardening de servidores Linux, auditoria de integridade e monitoramento centralizado de logs podem ajudar a reduzir o impacto de backdoors desse tipo.

A Palo Alto Networks informou que hackers podem ter tentado explorar, ainda em 9 de abril de 2026, uma vulnerabilidade crítica recém-divulgada no PAN-OS, sistema operacional usado em seus firewalls e appliances de segurança de rede. A falha, identificada como CVE-2026-0300, recebeu pontuação CVSS de 9.3/8.7 e já foi associada a atividades limitadas de exploração em ambiente real. A vulnerabilidade é um buffer overflow no serviço User-ID Authentication Portal do PAN-OS. Na prática, esse tipo de falha ocorre quando um sistema grava mais dados do que o espaço de memória reservado consegue suportar, abrindo caminho para corrupção de memória e possível execução de código. Segundo a Palo Alto Networks, um invasor não autenticado poderia explorar o problema enviando pacotes especialmente criados para executar código arbitrário com privilégios de root. As correções para a CVE-2026-0300 estavam previstas para começar a ser disponibilizadas em 13 de maio de 2026. Até a aplicação dos patches, a empresa recomendou que os clientes restrinjam o acesso ao PAN-OS User-ID Authentication Portal apenas a zonas confiáveis ou desativem completamente o recurso caso ele não esteja em uso. Como medida adicional de mitigação, a Palo Alto Networks orientou as organizações a desativarem Response Pages no Interface Management Profile para qualquer interface L3 que possa receber tráfego não confiável ou vindo da internet. Clientes que utilizam Advanced Threat Prevention também podem bloquear tentativas de exploração ativando o Threat ID 510019 a partir da versão 9097-10022 do conteúdo Applications and Threats. Em um comunicado publicado na quarta-feira, a empresa afirmou estar ciente de exploração limitada da falha. A atividade está sendo rastreada como CL-STA-1132, um cluster de ameaça suspeito de ligação estatal, mas ainda sem origem atribuída publicamente. De acordo com a Unit 42, equipe de inteligência de ameaças da Palo Alto Networks, os invasores exploraram a CVE-2026-0300 para obter execução remota de código não autenticada no PAN-OS. Após o sucesso da exploração, os responsáveis pela atividade conseguiram injetar shellcode em um processo worker do nginx. A análise aponta que as primeiras tentativas malsucedidas de exploração contra um dispositivo PAN-OS foram observadas em 9 de abril de 2026. Cerca de uma semana depois, os hackers conseguiram alcançar execução remota de código contra o appliance e realizar a injeção de shellcode, indicando uma evolução na exploração ao longo do tempo. Após obter acesso inicial, os invasores executaram ações para reduzir rastros da atividade. Entre os procedimentos observados estavam a limpeza de mensagens de crash do kernel, a exclusão de entradas e registros de falhas do nginx e a remoção de arquivos de core dump gerados por crashes. Esse comportamento sugere uma preocupação operacional em dificultar a análise forense e atrasar a detecção. As atividades pós-exploração incluíram enumeração de Active Directory, uma etapa comum em invasões mais amplas, usada para mapear usuários, grupos, permissões, sistemas e possíveis caminhos de movimentação lateral. Em 29 de abril de 2026, os invasores também implantaram payloads adicionais em um segundo dispositivo, incluindo EarthWorm e ReverseSocks5. Essas ferramentas são associadas a túneis, proxies e comunicação reversa, recursos frequentemente usados para manter acesso, redirecionar tráfego e viabilizar movimentação dentro de redes comprometidas. EarthWorm e ReverseSocks5 já foram observadas anteriormente em operações de diferentes grupos hackers ligados à China, embora a Palo Alto Networks não tenha atribuído publicamente a campanha CL-STA-1132 a um país ou grupo específico. A Unit 42 destacou que, nos últimos cinco anos, hackers envolvidos em espionagem cibernética patrocinada por Estados têm direcionado cada vez mais seus esforços contra ativos de borda de rede. Esse conjunto inclui firewalls, roteadores, dispositivos IoT, hipervisores e soluções de VPN, justamente porque esses sistemas costumam ter privilégios elevados e, muitas vezes, menos visibilidade de segurança do que endpoints tradicionais. Esse foco em dispositivos de borda cria um desafio importante para equipes de segurança. Diferentemente de estações de trabalho e servidores, que normalmente contam com agentes de EDR, telemetria detalhada e controles de monitoramento mais consolidados, appliances de rede podem ter registros limitados, baixa cobertura de detecção e menor frequência de análise operacional. Outro ponto relevante na campanha é o uso de ferramentas open source em vez de malware proprietário. Segundo a Unit 42, essa escolha ajuda os invasores a reduzir a eficácia de detecções baseadas em assinatura e facilita a integração das ferramentas ao ambiente comprometido. Em outras palavras, o uso de ferramentas conhecidas e disponíveis publicamente pode dificultar a separação entre atividade administrativa legítima e comportamento malicioso. A empresa também observou que os operadores da campanha adotaram um ritmo operacional disciplinado, com sessões interativas intermitentes ao longo de várias semanas. Esse padrão de atuação, menos ruidoso e mais espaçado, pode permanecer abaixo dos limites comportamentais usados por muitos sistemas automatizados de alerta. Para organizações que utilizam PAN-OS, a prioridade deve ser revisar a exposição do User-ID Authentication Portal, validar se interfaces L3 estão recebendo tráfego não confiável, aplicar as mitigações recomendadas e acompanhar a liberação dos patches. Também é importante revisar logs disponíveis, indicadores de crash, registros do nginx, sinais de alteração em dispositivos de borda e evidências de enumeração interna, especialmente em ambientes integrados ao Active Directory.

Uma nova vulnerabilidade zero-day no Linux, chamada Dirty Frag, permite que invasores locais elevem privilégios e obtenham acesso root em grande parte das principais distribuições Linux. A falha foi divulgada pelo pesquisador Hyunwoo Kim, que também publicou uma prova de conceito do exploit após a quebra do embargo de divulgação pública. Segundo Kim, a vulnerabilidade foi introduzida há cerca de nove anos no kernel Linux, mais especificamente na interface de algoritmo criptográfico algif_aead. A exploração permite que um usuário local modifique arquivos protegidos do sistema diretamente na memória, sem autorização, e alcance privilégios administrativos com um único comando. O Dirty Frag funciona por meio do encadeamento de duas falhas distintas no kernel: a vulnerabilidade xfrm-ESP Page-Cache Write e a vulnerabilidade RxRPC Page-Cache Write. Juntas, elas permitem alterações não autorizadas em arquivos protegidos carregados em cache, abrindo caminho para a escalada de privilégios. A falha pertence à mesma classe de vulnerabilidades de Dirty Pipe e Copy Fail, ambas também associadas à manipulação indevida de dados em cache de páginas do kernel. No entanto, o Dirty Frag explora o campo de fragmento de uma estrutura de dados diferente do kernel, ampliando a superfície técnica desse tipo de problema. De acordo com Kim, assim como ocorreu com a vulnerabilidade Copy Fail, o Dirty Frag permite escalada imediata de privilégios para root em grandes distribuições Linux e também depende do encadeamento de duas vulnerabilidades separadas. O pesquisador destacou que a falha é um bug lógico determinístico, ou seja, não depende de uma janela de tempo específica para funcionar. Essa característica torna o Dirty Frag particularmente relevante do ponto de vista defensivo. Como a exploração não exige uma condição de corrida, o exploit não depende de precisão temporal para ter sucesso. Além disso, segundo o pesquisador, o kernel não entra em pânico quando a tentativa falha, e a taxa de sucesso é considerada muito alta. Até o momento descrito na divulgação, a vulnerabilidade ainda não havia recebido um identificador CVE para identificação. Também não havia patches disponíveis para várias distribuições afetadas, incluindo Ubuntu, Red Hat Enterprise Linux, CentOS Stream, AlmaLinux, openSUSE Tumbleweed e Fedora. A documentação completa e a prova de conceito foram publicadas após a quebra do embargo em 7 de maio de 2026. Segundo Kim, um terceiro não relacionado publicou o exploit de forma independente, antecipando a divulgação pública. Após consulta aos mantenedores por meio da lista linux-distros@vs.openwall.org, o pesquisador afirmou que a publicação do documento foi feita a pedido dos responsáveis pela coordenação. Como medida temporária de mitigação, usuários Linux podem remover os módulos vulneráveis esp4, esp6 e rxrpc do kernel. No entanto, essa ação pode afetar funcionalidades importantes, já que a desativação desses componentes pode interromper VPNs IPsec e sistemas de arquivos distribuídos AFS. O comando indicado para mitigação cria uma configuração em /etc/modprobe.d/dirtyfrag.conf para impedir o carregamento dos módulos esp4, esp6 e rxrpc, além de tentar removê-los da sessão atual. A aplicação dessa medida deve ser avaliada com cautela por administradores, especialmente em ambientes corporativos que dependem de conectividade VPN ou recursos distribuídos de rede. A divulgação do Dirty Frag ocorre enquanto mantenedores de distribuições Linux ainda trabalham na distribuição de correções para a Copy Fail, outra falha de escalada de privilégios para root que já estaria sendo explorada ativamente em ataques. A CISA adicionou a Copy Fail ao catálogo Known Exploited Vulnerabilities, conhecido como KEV, e determinou que agências federais dos Estados Unidos protejam seus dispositivos Linux até 15 de maio. Na ocasião, a agência norte-americana alertou que esse tipo de vulnerabilidade é um vetor frequente usado por hackers e representa riscos significativos para ambientes federais. A recomendação foi aplicar as mitigações conforme orientação dos fornecedores, seguir as diretrizes aplicáveis para serviços em nuvem ou interromper o uso do produto caso não haja mitigação disponível. O caso também se soma a outra falha corrigida em abril pelas distribuições Linux: a Pack2TheRoot, uma vulnerabilidade de escalada de privilégios encontrada no daemon PackageKit após permanecer cerca de uma década presente no sistema. A sequência de descobertas mostra como bugs antigos em componentes fundamentais do ecossistema Linux ainda podem gerar impacto relevante quando explorados em ambientes modernos.

A Securities and Exchange Board of India, órgão regulador do mercado de valores mobiliários da Índia, emitiu um alerta para que participantes do setor financeiro revisem imediatamente seus sistemas e práticas de segurança da informação diante do risco de que ferramentas de inteligência artificial voltadas à descoberta de vulnerabilidades, como o Claude Mythos, possam impulsionar uma nova onda de ataques cibernéticos. O órgão indiano, equivalente à Securities and Exchange Commission dos Estados Unidos e à Financial Conduct Authority do Reino Unido, publicou um comunicado orientando entidades reguladas a tratarem o avanço de modelos de IA para identificação de falhas como um novo vetor de risco. A preocupação central é que esse tipo de tecnologia possa permitir a localização e possível exploração de vulnerabilidades em escala e velocidade muito superiores às abordagens tradicionais. Segundo o regulador, a rápida evolução de tecnologias emergentes, incluindo ferramentas de identificação de vulnerabilidades conduzidas por IA, introduziu novas dimensões de risco para entidades reguladas. O comunicado cita explicitamente o Claude Mythos como exemplo e alerta que esses modelos podem ampliar a exposição das organizações ao permitir a descoberta rápida de falhas existentes. A autoridade também apontou preocupações relacionadas à confidencialidade dos dados, integridade das aplicações e confiabilidade dos resultados produzidos por sistemas de IA. Em resposta ao cenário, a Securities and Exchange Board criou uma força-tarefa para examinar os riscos associados a modelos como o Mythos. O grupo deverá compartilhar inteligência de ameaças, reportar incidentes e iniciar uma revisão da segurança cibernética de fornecedores terceirizados de software que atendem tanto o regulador quanto as entidades sob sua supervisão. A orientação também reforça medidas básicas de segurança da informação, mas com caráter de urgência. Entre as recomendações estão manter sistemas corrigidos com patches atualizados, realizar auditorias para identificar vulnerabilidades, manter inventários de APIs e protegê-las adequadamente, operar um Centro de Operações de Segurança com capacidade efetiva de monitoramento e resposta, além de adotar princípios como redes zero trust e redução da superfície de ataque por meio da execução apenas de serviços essenciais. O foco em APIs chama atenção porque essas interfaces costumam ser pontos críticos em ambientes financeiros, conectando sistemas internos, plataformas digitais, parceiros, corretoras, serviços de autenticação, dados de clientes e operações transacionais. Em um cenário em que modelos de IA podem acelerar a identificação de falhas, APIs mal documentadas, expostas ou configuradas de forma inadequada tendem a se tornar alvos ainda mais atrativos. O regulador também orientou os participantes do mercado acionário indiano a acionar seus comitês de TI para emitir diretrizes específicas sobre como mitigar riscos criados por modelos de detecção de vulnerabilidades conduzidos por IA. Além disso, essas entidades devem desenvolver planos para incorporar a própria inteligência artificial como parte de sua estratégia de defesa cibernética. O comunicado recomenda medidas adicionais, como recalibrar avaliações de risco para ameaças aceleradas por IA, transformar os SOCs com recursos aumentados por inteligência artificial e adotar gestão contínua de vulnerabilidades com o apoio de ferramentas de IA. A lógica é que, se os ataques podem ganhar velocidade e escala com modelos automatizados, a defesa também precisa evoluir para reduzir o tempo entre descoberta, priorização e correção de falhas. As orientações foram direcionadas a 19 classes diferentes de organizações reguladas, incluindo fundos de venture capital, bancos de investimento, fundos mútuos, bolsas de valores e fornecedores especializados, como agências responsáveis pelo armazenamento de informações de Know Your Customer, processo usado para verificação e identificação de clientes. A preocupação da Índia acompanha movimentos semelhantes de outros reguladores ao redor do mundo. Nos Estados Unidos, o secretário do Tesouro, Scott Bessent, convocou uma reunião emergencial com bancos do país algumas semanas antes. Reguladores de Singapura adotaram uma postura parecida, enquanto autoridades australianas enviaram aos bancos locais um lembrete firme sobre a necessidade de desenvolver estratégias de IA que considerem os riscos criados pela própria tecnologia. Em Hong Kong, a Autoridade Monetária trabalha em novas orientações de segurança da informação para um cenário influenciado por ferramentas como o Mythos. A abordagem indiana, no entanto, se destaca por tratar o risco como uma ameaça iminente e ordenar que entidades reguladas adotem medidas preventivas. Em vez de apenas reconhecer os riscos associados à IA, o regulador exigiu ação prática, incluindo revisão de controles, fortalecimento de fornecedores, uso de inteligência de ameaças e atualização da estratégia de defesa. O alerta reflete uma mudança importante no ambiente de segurança cibernética do setor financeiro. Ferramentas de IA capazes de encontrar vulnerabilidades podem ter aplicações legítimas em testes de segurança, auditorias e gestão de risco. Ao mesmo tempo, quando essas capacidades são acessíveis ou replicáveis por invasores, a janela entre a existência de uma falha e sua exploração pode diminuir significativamente. Para bancos, corretoras, bolsas, fundos e demais participantes do mercado financeiro, o desafio passa a ser duplo: proteger seus próprios ambientes contra falhas conhecidas e emergentes, e avaliar a cadeia de fornecedores que sustenta aplicações, integrações e serviços críticos. Em mercados altamente regulados, uma vulnerabilidade explorada em um terceiro pode gerar impactos operacionais, financeiros, regulatórios e reputacionais para várias instituições ao mesmo tempo.

Três conselhos locais do Reino Unido enfrentaram falhas e atrasos após a migração de sistemas de planejamento urbano e buscas de terrenos para uma nova plataforma de software como serviço, fornecida pela Arcus Global. Os problemas afetaram serviços públicos considerados sensíveis para cidadãos e empresas, incluindo processamento de pedidos de planejamento, consultas imobiliárias e registros usados em transações de compra e venda de propriedades. Segundo informações publicadas pelo The Register, moradores e compradores foram impactados por atrasos e inconsistências nos sistemas. Entre as consequências relatadas estão a interrupção da venda de uma casa avaliada em mais de £1 milhão, centenas de buscas de imóveis paralisadas e a aprovação indevida da instalação de uma antena 5G em uma área de conservação ligada a um clube de críquete. O caso envolve implementações da Arcus Global em pelo menos três autoridades locais: Havant Borough Council, Bracknell Forest Council e London Borough of Haringey. A empresa fornece soluções em nuvem para governos locais e afirmou que atua com mais de 60 clientes do setor público desde 2017, após processos de licitação aberta. Denis Kaminskiy, fundador e diretor da Arcus Global, declarou que a empresa oferece software robusto e de alta qualidade, baseado em tecnologias líderes de computação em nuvem. Ele também afirmou que a companhia frequentemente substitui sistemas legados complexos, com dados que podem ter até 30 anos, e que trabalha rapidamente com os clientes quando problemas são identificados. No caso do Havant Borough Council, localizado na costa sul da Inglaterra, o contrato com a Arcus Global foi assinado em 2024 para substituir um arranjo de hospedagem com a Capita que estava previsto para ser encerrado. A nova solução deveria atender áreas como planejamento urbano e encargos territoriais, mas, após a implementação, moradores relataram corrupção de dados em processos de planejamento, incluindo comentários em pedidos e arquivos perdidos. Um documento apresentado ao Comitê de Visão Geral e Fiscalização do conselho em fevereiro de 2026 reconheceu “uma série de problemas pós-implementação”, incluindo inconsistências de integridade de dados, limitações de relatórios e desafios na interface de usuário. O documento também apontou que o módulo de Land Charges, usado para buscas e registros relacionados a imóveis, não estava funcionando conforme o esperado e exigia uma reformulação significativa. Diante da instabilidade, o conselho decidiu envolver diretamente a fornecedora para realizar uma reconfiguração completa e uma nova migração de dados. A avaliação interna indicou que esse seria o caminho mais rápido e eficaz para recuperar a estabilidade operacional. O Havant Borough Council não respondeu ao pedido de posicionamento feito pelo The Register. Em Bracknell Forest Council, outra implementação da Arcus também enfrentou dificuldades. O problema resultou em atrasos em cerca de 500 transações imobiliárias, causados por um acúmulo de buscas de terrenos pendentes. De acordo com a BBC, a autoridade local informou que havia 695 solicitações de busca em aberto em meados de abril, sendo 480 buscas pessoais e 215 buscas oficiais da autoridade local. Durante uma reunião do conselho, um membro do gabinete afirmou que o sistema “entrou em operação no momento exigido”, mas não entregou o nível esperado de prontidão, resiliência e confiabilidade. Peter Dewsbury, CEO da Arcus Global, disse à BBC que a empresa estava ciente da interrupção no serviço de land charges em Bracknell Forest e que sua equipe trabalhava de forma construtiva com o conselho para restaurar o serviço completo o mais rapidamente possível. Em 16 de abril, o conselho e a fornecedora emitiram um pedido de desculpas conjunto. A declaração informou que problemas de dados inesperados e significativos impediram o serviço de retornar resultados completos e precisos, o que foi classificado como inaceitável para pessoas envolvidas na compra e venda de imóveis na região. O terceiro caso citado ocorreu em Haringey, em Londres. Em 2024, o conselho admitiu ter aprovado por engano uma aplicação de planejamento controversa para instalação de uma antena de telefonia 5G em uma área de conservação no Hornsey Cricket Club, em Crouch End. A proposta era considerada visualmente intrusiva e havia recebido objeções de moradores e do próprio clube. O conselho pretendia rejeitar a solicitação, mas a recusa foi registrada um dia depois do prazo previsto pelas regras aplicáveis. Uma integrante do gabinete pediu desculpas pelo erro e atribuiu a falha a um comportamento imprevisto no sistema de TI da equipe de planejamento. A Arcus Global havia anunciado a conquista do contrato com o Haringey Council em 2022. Em resposta, um porta-voz do conselho afirmou que a autoridade assumiu responsabilidade pelo erro na época e pediu desculpas. Segundo o posicionamento, o problema foi resolvido ainda em 2024, e salvaguardas robustas foram implementadas para reduzir significativamente a possibilidade de recorrência. O conselho também destacou que sua equipe de planejamento processa mais de 2 mil aplicações por ano e que erros são raros. Embora os casos envolvam serviços administrativos locais, os impactos mostram como migrações para plataformas SaaS podem gerar riscos operacionais relevantes quando sistemas legados, bases históricas e processos regulados são transferidos sem validação suficiente de dados, testes funcionais e planos de contingência. Em contextos como planejamento urbano e buscas imobiliárias, inconsistências de dados não afetam apenas a eficiência interna: podem atrasar transações, comprometer decisões administrativas e gerar prejuízos diretos para cidadãos. O episódio também coloca em evidência um desafio recorrente em modernizações de TI no setor público. A substituição de sistemas antigos por soluções em nuvem pode trazer ganhos de escalabilidade, integração e manutenção, mas exige governança rigorosa de migração, reconciliação de dados, validação de módulos críticos, treinamento de usuários e monitoramento pós-implantação. Quando esses pontos falham, a tecnologia que deveria acelerar serviços públicos pode se tornar um fator de interrupção operacional.

Um estudante universitário de Taiwan foi liberado sob fiança após ser acusado de interferir nos sinais usados pela rede ferroviária de alta velocidade do país, provocando a paralisação temporária de trens-bala. O caso mobilizou investigadores por semanas, depois que uma interrupção de 48 minutos afetou três trens em 5 de abril. De acordo com a Taiwan High Speed Rail, a THSR, a falha operacional foi causada por um sinal irregular de “General Alarm”, um tipo de alerta normalmente acionado por equipamentos especializados utilizados por funcionários das estações. O sinal foi transmitido por meio de um dispositivo TETRA, sigla para Terrestrial Trunked Radio, na estação de Taichung. O TETRA é uma tecnologia de comunicação por rádio bastante usada em ambientes críticos, como transporte público, segurança, serviços de emergência e operações industriais. Na prática, esses dispositivos funcionam de maneira semelhante a rádios comunicadores, mas são projetados para redes profissionais, permitindo comunicação entre equipes de estação, operadores e condutores. Quando o sinal de alarme geral foi detectado, os funcionários seguiram o protocolo estabelecido e ativaram os planos de resposta emergencial. Como parte desse procedimento, os trens receberam instruções para parar manualmente, o que levou à interrupção do serviço. Como esses equipamentos costumam ser utilizados por funcionários da própria estação, as autoridades inicialmente consideraram a possibilidade de envolvimento interno. A investigação passou a ser conduzida pela polícia ferroviária e por especialistas em telecomunicações, depois que a equipe da sala de controle descartou a hipótese de que equipamentos oficiais tivessem sido roubados ou usados indevidamente por colaboradores. Em 13 de abril, a Unidade de Grandes Casos Criminais de Taiwan entrou na investigação após o promotor-chefe Chang Chun-hui considerar o incidente uma ameaça à segurança do transporte. A partir daí, os investigadores passaram cerca de duas semanas analisando como o sinal havia sido enviado e quem poderia ter capacidade técnica para reproduzi-lo. A apuração levou ao nome de um estudante de 23 anos, identificado apenas pelo sobrenome Lin, descrito como entusiasta de rádio. Segundo declarações reportadas pela imprensa local, as autoridades acreditam que ele explorou uma vulnerabilidade na rede de comunicação TETRA e acionou remotamente o sinal de General Alarm usando equipamentos eletromagnéticos não especificados. Durante buscas realizadas na residência e no local de trabalho do suspeito, a polícia apreendeu sete dispositivos de rádio, um notebook, dois smartphones e o que aparentava ser um filtro de rádio definido por software, conhecido como SDR. Esse tipo de equipamento pode ser usado para captar, analisar e manipular sinais de rádio, dependendo da configuração e do conhecimento técnico do operador. Os investigadores afirmaram acreditar que o método usado para disparar o alerta foi rudimentar, baseado na clonagem de sinais com equipamentos comprados pela internet. De acordo com a suspeita policial, Lin teria conectado um rádio ao notebook por meio de um filtro SDR, capturado o sinal usado pela THSR e configurado seu próprio dispositivo para transmitir o mesmo padrão. Com isso, ele teria conseguido acionar o General Alarm de uma forma que aparentava vir de um funcionário da estação. Embora o texto original não detalhe a vulnerabilidade técnica explorada, a descrição aponta para um possível abuso de autenticação, validação ou controle de transmissão dentro do ambiente de rádio usado pela ferrovia. A prisão de Lin ocorreu em 28 de abril. Após interrogatório no dia seguinte, as autoridades concluíram que ele era, provavelmente, o responsável pela interrupção. Apesar da gravidade operacional do caso, ele foi liberado sob fiança de NT$100 mil, aproximadamente US$3.183, após os investigadores entenderem que não havia necessidade de mantê-lo detido. O caso chama atenção porque mostra como sistemas físicos críticos, como ferrovias, podem ser impactados por falhas ou abusos em canais de comunicação operacional. Mesmo sem invasão direta a servidores ou sistemas corporativos tradicionais, a manipulação de sinais de rádio pode provocar efeitos imediatos no mundo real, especialmente quando esses sinais estão ligados a protocolos de segurança. Para operadores de infraestrutura crítica, o incidente reforça a necessidade de controles rigorosos sobre redes de comunicação, autenticação de dispositivos, monitoramento de sinais anômalos e testes constantes de resiliência. Em ambientes ferroviários, aeroportuários, industriais ou de emergência, a confiança no canal de comunicação é parte central da segurança operacional.

Um novo cenário de risco começa a preocupar especialistas em segurança: smartphones modernos já são capazes de ler, copiar e até emular cartões baseados na tecnologia MIFARE Classic, amplamente utilizada em sistemas de transporte público e controle de acesso. A descoberta acende um alerta para cidades e empresas que ainda utilizam essa tecnologia considerada obsoleta e vulnerável. De acordo com a análise, modelos recentes de smartphones — especialmente de fabricantes chineses — já conseguem interagir diretamente com cartões RFID do tipo MIFARE 1.0. Isso significa que, sem a necessidade de hardware especializado, um usuário pode ler os dados de um cartão, replicá-los e utilizar o próprio celular como se fosse o cartão original. A cadeia de ataque não é nova, mas se tornou significativamente mais acessível. Historicamente, a clonagem desses cartões exigia dispositivos específicos, como leitores RFID dedicados e cartões regraváveis adquiridos no mercado paralelo. Agora, com a evolução dos smartphones e o suporte a tecnologias NFC mais avançadas, todo esse processo pode ser realizado em poucos minutos diretamente pelo celular. O problema central está na própria arquitetura do MIFARE Classic. Desenvolvido originalmente para aplicações simples, como identificação de produtos, o padrão não foi projetado com foco em segurança robusta. Ele utiliza mecanismos de criptografia considerados fracos, com chaves pequenas e facilmente quebráveis — uma limitação já conhecida há mais de duas décadas. Na prática, isso abre espaço para fraudes. Um atacante pode, por exemplo, copiar um cartão de transporte com saldo carregado e replicá-lo em outro dispositivo. Isso permite a utilização simultânea de múltiplas cópias do mesmo cartão, gerando prejuízos diretos para operadores de transporte. Embora sistemas de bilhetagem consigam detectar inconsistências posteriormente — como o uso simultâneo do mesmo cartão em locais diferentes —, a fraude pode ser explorada por horas antes do bloqueio. Além do transporte público, o impacto se estende a outros setores. Cartões de acesso utilizados em hotéis, empresas e sistemas de controle físico também podem ser afetados, já que muitos utilizam a mesma tecnologia RFID com níveis de segurança similares. Outro fator agravante é o modelo de operação offline desses sistemas. Em muitos casos, especialmente em transporte público, a validação do saldo e das transações ocorre localmente, sem comunicação em tempo real com servidores centrais. Isso dificulta a detecção imediata de fraudes e amplia a janela de exploração. Especialistas alertam que a vulnerabilidade do MIFARE Classic não é uma novidade. Desde os anos 2000 já existem recomendações para migração para padrões mais seguros, como o MIFARE DESFire (2.0), que incorpora criptografia mais robusta e mecanismos avançados de autenticação. No entanto, o alto custo de substituição de infraestrutura — incluindo leitores e validadores — tem retardado essa transição em diversas cidades. Com a popularização dessa nova capacidade em smartphones, o risco deixa de ser restrito a grupos técnicos especializados e passa a ser acessível a um público muito mais amplo, elevando o potencial de fraude em larga escala. O cenário reforça uma tendência crítica na cibersegurança: vulnerabilidades antigas podem se tornar ameaças reais novamente quando novas tecnologias reduzem a barreira de exploração. Nesse caso, o avanço dos smartphones está transformando um ataque antes complexo em algo trivial — com impactos diretos no mundo físico e financeiro.

Uma nova campanha de ciberespionagem identificada por pesquisadores da Kaspersky revelou que hackers estão mirando organizações governamentais e empresas da indústria de aviação na Rússia com o objetivo de roubar dados altamente sensíveis — especialmente informações geoespaciais utilizadas em sistemas de navegação, satélites e infraestrutura crítica. O grupo, identificado como HeartlessSoul, está ativo desde pelo menos setembro de 2025 e conduz ataques direcionados com foco em dados de GIS (Geographic Information Systems). Esses arquivos contêm informações detalhadas sobre terrenos, redes de engenharia, infraestrutura e, potencialmente, instalações estratégicas — dados críticos para operações militares, planejamento logístico e inteligência. A cadeia de ataque segue um padrão bem estruturado. O vetor inicial é predominantemente phishing, com envio de e-mails contendo arquivos compactados maliciosos. Ao abrir esses arquivos, a vítima executa inadvertidamente o malware, iniciando o comprometimento do sistema. Paralelamente, os invasores também utilizam campanhas de malvertising — anúncios falsos que simulam sites legítimos — para distribuir softwares adulterados relacionados à aviação. Em uma etapa mais sofisticada, os hackers registram domínios falsos que imitam plataformas legítimas do setor aeronáutico. Esses sites hospedam instaladores maliciosos disfarçados de ferramentas confiáveis. Ao executar o download, o usuário inicia automaticamente o processo de infecção, permitindo que o malware estabeleça persistência no dispositivo comprometido. Um dos pontos mais relevantes da campanha é o uso indevido de plataformas legítimas, como o SourceForge, para distribuição de malware. Os invasores publicaram versões falsas de softwares populares, como o GearUP, originalmente utilizado para otimizar conexões em jogos online. Usuários que buscavam a ferramenta acabavam instalando spyware sem perceber. Uma vez dentro do ambiente da vítima, o malware executa uma série de atividades de coleta de dados. Entre as capacidades identificadas estão captura de screenshots, registro de teclas digitadas (keylogging), coleta de dados de navegação, exfiltração de arquivos locais e roubo de credenciais — incluindo acesso a contas do Telegram. O malware também consegue identificar a localização do dispositivo, o que pode ampliar o valor estratégico das informações coletadas. A análise também revelou possíveis conexões com outro grupo hacker, conhecido como Goffee, que já havia conduzido ataques semelhantes, incluindo campanhas focadas na extração de dados a partir de dispositivos removíveis, como pen drives. Essa sobreposição sugere possível colaboração ou compartilhamento de infraestrutura entre grupos. Embora o foco principal da campanha seja o setor de aviação, há indícios de que o alcance pode ser ainda maior. Segundo análises independentes, o malware também foi distribuído por meio de arquivos que simulavam simuladores de drones FPV e ferramentas para contornar restrições do serviço de internet via satélite Starlink. Esse detalhe amplia o escopo dos alvos, podendo incluir operadores de drones, especialistas em comunicação e até perfis com ligação militar. Do ponto de vista estratégico, esse tipo de ataque reforça uma tendência crescente no cenário de ameaças: o foco em dados geoespaciais e inteligência operacional. Em conflitos modernos, informações de localização, mapeamento e infraestrutura são tão valiosas quanto dados financeiros ou credenciais — pois podem impactar diretamente operações militares e decisões táticas. A campanha também evidencia a evolução das técnicas de distribuição de malware, com uso combinado de engenharia social, plataformas legítimas e spoofing de domínios — dificultando a detecção e aumentando a taxa de sucesso dos ataques.