A Oracle está se preparando para encerrar a manutenção da versão macOS/x64 do Java Development Kit, o JDK, a partir do JDK 27, previsto para setembro. A mudança afeta Macs com processadores Intel e acompanha o movimento mais amplo do ecossistema de software para reduzir ou encerrar suporte a essa plataforma após a transição da Apple para seus próprios chips Apple Silicon. A decisão aparece na JEP 8386091, uma JDK Enhancement Proposal ainda em estado de rascunho, segundo a qual engenheiros da Oracle deixarão de manter o port macOS/x64 a partir do JDK 27. Poucos dias depois, Mikael Vidstedt, diretor sênior de Java Virtual Machine na Oracle, submeteu uma pull request para implementar a depreciação. Na prática, a mudança significa que a construção do JDK para macOS/x64 passará a exigir a ativação manual de uma flag específica. Mesmo assim, não haverá garantia de que o port será compilado corretamente, muito menos de que funcionará. Ou seja, a plataforma deixa de ser tratada como um alvo mantido ativamente pela Oracle. O impacto recai sobre desenvolvedores e organizações que ainda usam Macs Intel para desenvolvimento Java. Embora esses equipamentos ainda estejam em operação em muitas empresas, a Apple já acelerou o processo de encerramento de suporte. O último Mac baseado em Intel, o Mac Pro de 2019, ainda podia ser comprado até junho de 2023, quando foi descontinuado. Na Worldwide Developers Conference, a WWDC, a Apple confirmou que o macOS 27, chamado “Golden Gate”, não dará suporte a Macs Intel. A empresa também informou que essa será a última versão do sistema a incluir o Rosetta 2, camada de compatibilidade usada para executar aplicativos compilados para Intel em Macs com Apple Silicon. A decisão da Oracle, portanto, não acontece isoladamente. Ela acompanha o fim gradual da relevância do macOS em arquitetura x64 dentro de grandes projetos de linguagem e runtime. À medida que a Apple concentra seus sistemas em chips Arm próprios, manter testes, builds, correções e validações para Intel Macs se torna menos prioritário para fornecedores de plataformas de desenvolvimento. O projeto Rust já havia reduzido o suporte a Macs Intel para Tier 2 a partir do Rust 1.90, lançado em setembro passado. Nesse nível, o compilador e a biblioteca padrão ainda são distribuídos para a plataforma, mas os testes automatizados não têm mais garantia de execução. Isso aumenta o risco de bugs específicos do macOS/x64 passarem despercebidos. O Python também classifica x86_64-apple-darwin como plataforma Tier 2 desde novembro de 2025. No caso do Python, porém, esse nível ainda oferece suporte relativamente forte: falhas podem bloquear lançamentos, e correções precisam ser feitas em até 24 horas. O Node.js seguiu caminho semelhante e rebaixou o macOS x64 para Tier 2 em maio. Pela documentação atual do projeto, a plataforma Intel Mac deve passar a ser considerada experimental a partir do início de 2028. A justificativa é que, a partir desse período, o projeto não terá mais condições de testar mudanças em versões do macOS baseadas em Intel. Ainda assim, o Node.js pretende continuar criando binários universais para versões em suporte, compatíveis tanto com macOS em Apple Silicon quanto com macOS em Intel. A diferença é que, no caso de Intel, esses binários não serão testados, o que reduz a previsibilidade para uso em ambientes críticos. Para desenvolvedores Java, o fim da manutenção ativa no macOS/x64 pode exigir ajustes de planejamento. Uma alternativa é executar Linux em Macs Intel, diretamente ou em uma máquina virtual, e usar versões recentes do JDK nessa plataforma. Outra possibilidade é manter versões anteriores de longo prazo, como o JDK 25 LTS, que devem continuar recebendo atualizações para Intel Macs. O cenário, portanto, não significa que Java deixará de funcionar imediatamente em todos os Macs Intel. O ponto central é que o JDK 27 marca o início do fim do suporte ativo da Oracle para essa combinação específica de sistema operacional e arquitetura. Com isso, novos recursos, correções e garantias de funcionamento passam a se concentrar em plataformas ainda mantidas como prioritárias. Para empresas, a recomendação é mapear estações de desenvolvimento, pipelines de build e ambientes de teste que ainda dependem de macOS/x64. Caso esses ambientes executem Java em produção de software, será importante avaliar migração para Apple Silicon, Linux ou versões LTS compatíveis, evitando que builds futuros fiquem presos a uma plataforma sem garantia de manutenção. A mudança também ilustra o efeito em cadeia da transição da Apple para Arm. O abandono dos Macs Intel não depende apenas da Apple: ele se propaga por linguagens, runtimes, bibliotecas, compiladores, ferramentas de desenvolvimento e plataformas de CI/CD. À medida que esses projetos reduzem testes e manutenção, o custo operacional de permanecer em Intel Mac tende a aumentar

A startup norte-americana Ampera apresentou o que afirma ser o primeiro módulo de reator nuclear produzido por impressão 3D, em uma aposta voltada a fornecer energia escalável e sem emissões diretas para datacenters, aplicações de defesa e locais fora da rede elétrica convencional. A demonstração ocorreu no centro de inovação da empresa em Palm Beach Gardens, na Flórida, durante um evento com mais de 100 participantes, incluindo autoridades locais, líderes empresariais e funcionários. Na ocasião, o fundador e CEO da Ampera, Brian Matthews, revelou um protótipo de microrreator com núcleo e vaso de pressão fabricados integralmente por impressão 3D em carbeto de silício. Segundo Matthews, o núcleo nuclear de próxima geração e o vaso de pressão apresentados pela empresa estabelecem a base para uma energia nuclear produzida em fábrica e em larga escala. O executivo afirmou que o uso de manufatura aditiva e tecnologia avançada demonstra um caminho comercial para acelerar a chegada de novas soluções nucleares ao mercado. A proposta da Ampera é desenvolver um reator nuclear subcrítico, de estado sólido, baseado em tório e construído em fábrica. O termo subcrítico significa que o combustível não consegue sustentar sozinho uma reação nuclear em cadeia. Na prática, isso reduz o risco de uma escalada descontrolada de potência, já que a operação depende de uma fonte externa de nêutrons. A empresa usa a expressão “estado sólido” para descrever um projeto com combustível sólido, e não líquido. O combustível previsto utiliza partículas TRISO, sigla para tristructural isotropic. Essas partículas consistem em um núcleo de combustível contendo tório, envolvido por múltiplas camadas de cerâmica e carbono, projetadas para reter produtos de fissão e aumentar a resistência térmica e estrutural do material. O tório-232, por si só, não é físsil. Após absorver um nêutron, ele passa por um processo de decaimento envolvendo tório-233 e protactínio-233 até se transformar em urânio-233, que é físsil. Por isso, o conceito da Ampera depende de uma fonte separada de nêutrons para iniciar e sustentar a operação do reator. A empresa afirma que seu projeto inclui um “neutron driver” proprietário, ou acionador de nêutrons, responsável por fornecer uma fonte externa estável para o funcionamento do sistema. A Ampera, porém, ainda não revelou publicamente como esses nêutrons são gerados no módulo, mantendo esse detalhe técnico sob sigilo. Em junho, a companhia anunciou a criação de uma subsidiária na Austrália para garantir o fornecimento de tório. A Ampera também afirmou que pretende produzir seus próprios núcleos de combustível TRISO com tório nos Estados Unidos. Segundo Matthews, a produção doméstica desses kernels permitiria garantir acesso ao combustível necessário durante a expansão da empresa e reduzir riscos de volatilidade de preços. Outro elemento central do projeto é o formato do núcleo do reator. A Ampera descreve o componente como uma estrutura esférica monolítica do tipo gyroid. Um gyroid é uma geometria complexa, conhecida por oferecer grande área de superfície em relação ao volume, característica útil para transferência de calor. Esse tipo de forma é difícil de fabricar por métodos convencionais, o que torna a impressão 3D uma opção atraente para esse projeto. O núcleo é impresso em 3D usando carbeto de silício e, segundo a empresa, foi projetado para operar por até 30 anos sem reabastecimento. A Ampera afirma que seus sistemas planejados poderão entregar 15 ou 30 MWe, dependendo da configuração, potência que a companhia considera suficiente para abastecer um datacenter típico. Configurações maiores também estão nos planos. O interesse por esse tipo de solução cresce em um momento de forte expansão da demanda energética dos datacenters. Cargas de trabalho de inteligência artificial, computação em nuvem e processamento intensivo aumentaram a pressão por fontes de energia contínuas, previsíveis e com menor emissão de carbono. Microrreatores nucleares, caso se provem viáveis e aprovados por reguladores, poderiam oferecer uma alternativa para instalações que precisam operar 24 horas por dia com alta densidade energética. Matthews afirmou que a Ampera espera estar entre as primeiras empresas a industrializar energia nuclear construída em fábrica com prazos de implantação próximos. Ao ser questionada pelo The Register sobre disponibilidade, a empresa informou que espera ter a parte de geração de energia do sistema disponível já em 2027, enquanto o módulo nuclear deve chegar aos clientes por volta de 2030, dependendo de aprovação regulatória. Esse ponto é decisivo. Embora a apresentação do protótipo marque um avanço técnico e de marketing para a empresa, a adoção comercial de qualquer reator nuclear depende de avaliações regulatórias, certificações, validação de segurança, cadeia de suprimentos confiável e demonstrações operacionais em condições reais. O uso em datacenters também exigiria integração com sistemas elétricos, resfriamento, proteção física, planos de emergência e normas locais. Além dos datacenters, clientes de defesa aparecem como um mercado provável caso a Ampera consiga entregar reatores funcionais e confiáveis. No início deste ano, o Departamento da Força Aérea dos Estados Unidos anunciou que estava avaliando microrreatores para três de suas instalações, como parte de um programa voltado a melhorar a resiliência energética durante interrupções na rede elétrica. Para aplicações militares e locais remotos, a promessa de um reator compacto, com longa vida útil e sem necessidade frequente de reabastecimento é especialmente atraente. Bases isoladas, instalações críticas e operações fora da rede poderiam reduzir dependência de combustíveis transportados por longas distâncias, que representam custo logístico e risco operacional. Ainda assim, a tecnologia permanece em fase inicial. A Ampera apresentou um módulo protótipo e descreveu sua arquitetura, mas ainda precisa demonstrar desempenho, segurança, fabricabilidade em escala e aprovação regulatória. Também há questões abertas sobre o funcionamento do acionador de nêutrons, a produção do combustível TRISO com tório, os custos finais e o cronograma real de implantação. O anúncio reforça uma tendência mais ampla: a aproximação entre infraestrutura digital e novas soluções energéticas. Com datacenters consumindo volumes crescentes de eletricidade, empresas de tecnologia e fornecedores de energia buscam alternativas que combinem disponibilidade contínua, baixa emissão de carbono e independência parcial da rede. Nesse cenário, microrreatores nucleares entram no debate como uma possibilidade de longo prazo, ainda dependente de comprovação técnica, aceitação regulatória e viabilidade econômica.

Por Leonardo Araújo de Assis, CEO da Biostation A privacidade e a segurança interna tornaram-se o maior diferencial competitivo da nova economia, marcando um ponto de inflexão onde o reconhecimento biométrico deixou de ser apenas uma conveniência para substituir senhas e passou a ser uma prioridade estratégica de gestão de risco. Com a iminência da computação quântica, organizações líderes estão migrando para soluções que unem o que há de mais avançado em hardware e criptografia para proteger a identidade dos usuários. Nesse cenário, a biometria palmar (vascular) surge como o padrão-ouro para o setor corporativo e financeiro, oferecendo uma solução definitiva baseada na impossibilidade de falsificação. Diferente da face ou da impressão digital, o mapa vascular está dentro do corpo, permitindo que o sensor leia o padrão das veias sob a pele e torne o sistema imune a fotos de alta resolução ou moldes de silicone. Além da segurança física do dado, a tecnologia atende às demandas de um mundo pós-pandemia ao oferecer uma experiência touchless (sem contato), o que garante higiene e elimina a resistência dos usuários ao uso de sensores públicos. A precisão é outro fator determinante, uma vez que o padrão vascular é único até para gêmeos idênticos e permanece estável ao longo de toda a vida, reduzindo drasticamente as taxas de erro e fraudes de identidade. No entanto, a blindagem definitiva ocorre quando a biometria palmar é combinada com a Criptografia Totalmente Homomórfica (FHE), garantindo que a informação capturada nunca seja roubada. Esta união redefine a proteção de dados através do processamento cego, onde o mapa das veias nunca precisa ser aberto ou descriptografado para ser validado. O sistema confirma a identidade comparando informações em estado cifrado, funcionando de forma análoga à validação de um documento dentro de um envelope lacrado, sem nunca expor a imagem real da biometria. Ao adotar algoritmos resistentes a computadores quânticos, as empresas asseguram imunidade contra ameaças futuras, garantindo que, mesmo em caso de invasão, qualquer dado vazado seja apenas um ruído matemático indecifrável e sem impacto. Para o alto escalão das empresas, como CEOs, CIOs e DPOs, essa transição não é meramente técnica, mas uma estratégia de mitigação de passivos que garante conformidade total com a LGPD e normas globais. Ao utilizar a palma como um dado interno e privado processado por criptografia pós-quântica, a organização elimina riscos de vazamentos catastróficos e constrói uma jornada do cliente fundamentada em inovação. Em um mercado onde a confiança digital é a moeda mais forte, o próximo salto definitivo é garantir que a segurança seja invisível, interna e matematicamente inquebrável.

A Sysdig afirmou ter identificado o que considera o primeiro ataque de ransomware conduzido de ponta a ponta por um agente de inteligência artificial. Segundo a equipe de pesquisa da empresa, a operação foi atribuída a um operador rastreado como JADEPUFFER e usou um grande modelo de linguagem para automatizar toda a cadeia de ataque: invasão inicial, coleta de credenciais, movimentação no ambiente, comprometimento de serviços internos e destruição de um banco de dados de produção. O caso chama atenção porque o ransomware tradicionalmente depende de algum nível de intervenção humana, seja na operação manual do ataque, seja na criação prévia de scripts e ferramentas que executam ações específicas. No incidente descrito pela Sysdig, porém, o agente teria encadeado etapas sucessivas por conta própria, reduzindo a barreira técnica necessária para executar uma operação destrutiva. Na prática, se esse modelo se repetir, o custo para conduzir ataques pode se aproximar do valor necessário para alugar ou operar um agente de IA. A porta de entrada foi uma vulnerabilidade antiga e já corrigida no Langflow, ferramenta open source usada para criar aplicações de IA e fluxos de agentes. A falha, rastreada como CVE-2025-3248, envolve ausência de autenticação e permite execução remota de código Python por qualquer pessoa capaz de acessar o servidor vulnerável, sem necessidade de login. Servidores Langflow são alvos atrativos porque muitas vezes ficam expostos à internet e armazenam chaves de API, tokens e credenciais em variáveis de ambiente ou integrações com serviços de nuvem e plataformas de IA. A vulnerabilidade foi corrigida no Langflow 1.3.0 e adicionada ao catálogo Known Exploited Vulnerabilities da CISA em maio de 2025, mas a Sysdig observou que muitos ambientes não foram atualizados. Depois de explorar a falha, o agente mapeou rapidamente a máquina comprometida e iniciou uma varredura por segredos. Entre os dados buscados estavam chaves de API para serviços de IA, incluindo OpenAI, Anthropic, DeepSeek e Gemini, além de credenciais de nuvem de provedores como Alibaba, Tencent, AWS, Google Cloud e Azure. O agente também procurou chaves de carteiras de criptomoedas e credenciais de bancos de dados. A operação também comprometeu um servidor MinIO usando as credenciais padrão de fábrica “minioadmin:minioadmin”, que não haviam sido alteradas. Esse ponto reforça um problema recorrente em incidentes de segurança: configurações padrão, quando mantidas em produção, podem transformar serviços internos em alvos de fácil exploração. O agente criou ainda um mecanismo de persistência ao adicionar uma tarefa agendada que se comunicava com o servidor do invasor a cada 30 minutos. Esse tipo de beacon permite que o operador mantenha um canal de retorno com o sistema comprometido, acompanhe o ambiente e envie novas instruções. Em seguida, o ataque avançou para o alvo principal: um servidor separado, exposto à internet, que executava um banco de dados MySQL e o Nacos, plataforma da Alibaba usada para gerenciamento de configurações e descoberta de serviços em ambientes de microsserviços. O agente conseguiu se autenticar no banco de dados como root. A Sysdig informou que não conseguiu determinar a origem das credenciais root usadas no MySQL. A partir desse acesso, o agente comprometeu o Nacos explorando uma falha de bypass de autenticação de 2021, rastreada como CVE-2021-29441, combinada ao uso de uma chave de assinatura padrão que o Nacos distribui sem alteração desde 2020. Com isso, o agente criou sua própria conta administrativa no serviço. A etapa de extorsão teve um detalhe incomum: o agente criptografou todas as 1.342 configurações do Nacos, apagou as tabelas originais e deixou uma nota de resgate exigindo pagamento em Bitcoin, com contato por Proton Mail. No entanto, a chave de criptografia foi gerada aleatoriamente, exibida uma única vez na tela e não foi salva nem enviada para qualquer lugar. Isso significa que, segundo a Sysdig, não havia chave a ser entregue à vítima. Mesmo que o resgate fosse pago, os dados não poderiam ser recuperados por meio da descriptografia. A nota de resgate alegava uso de AES-256, embora a Sysdig tenha observado que a ferramenta usada no ataque utiliza AES-128 por padrão. Em termos práticos, o resultado para a vítima seria o mesmo: perda dos dados criptografados. O agente também apagou bancos de dados inteiros e deixou um comentário no próprio código afirmando que os dados já teriam sido copiados para outro local. A Sysdig, porém, tratou essa afirmação com cautela e disse não ter encontrado evidências de que os dados tenham sido realmente exfiltrados. Nesse caso, a alegação pode ter sido apenas uma saída gerada pelo próprio agente, sem comprovação operacional. Um dos elementos usados pela Sysdig para sustentar a hipótese de automação por IA foi o próprio código dos payloads. Os artefatos continham comentários em linguagem natural explicando por que cada etapa estava sendo executada. Esse tipo de “raciocínio narrado” é incomum em ataques conduzidos manualmente por hackers, mas é típico de modelos de linguagem que documentam ações por padrão. Outro sinal foi a capacidade de correção em alta velocidade. Em um dos momentos analisados, o agente passou de uma tentativa de login malsucedida para uma correção em múltiplas etapas em apenas 31 segundos, diagnosticando a causa do erro em vez de simplesmente repetir a tentativa. No total, a Sysdig contabilizou mais de 600 payloads distintos e intencionais ao longo da operação. Um detalhe ainda não esclarecido envolve o endereço Bitcoin usado na nota de resgate. O endereço é exatamente o mesmo exemplo presente na documentação de desenvolvedores do Bitcoin, amplamente replicado em textos públicos usados para treinamento de modelos. Ao mesmo tempo, trata-se de uma carteira real e ativa, com histórico de pagamentos. A Sysdig não conseguiu determinar se o modelo simplesmente reproduziu um endereço conhecido de seus dados de treinamento ou se o operador escolheu deliberadamente uma carteira real que coincide com o exemplo famoso. O caso JADEPUFFER se soma a uma sequência de pesquisas sobre ataques ofensivos com uso crescente de IA. Em agosto de 2025, pesquisadores da ESET relataram o PromptLock, descrito inicialmente como o primeiro ransomware com IA, mas que depois se revelou um protótipo de laboratório da NYU chamado Ransomware 3.0, e não um ataque real. Na mesma época, a Anthropic relatou uma campanha real de extorsão que usou a ferramenta Claude Code contra ao menos 17 organizações, com demandas superiores a US$ 500 mil. Nesse caso, porém, ainda havia condução humana mais clara na operação. Em novembro de 2025, a Anthropic também descreveu o que chamou de primeiro ataque cibernético amplamente autônomo, envolvendo uma operação de espionagem vinculada à China na qual o Claude teria ajudado a escrever exploits e roubar dados com pouca intervenção humana. Segundo a empresa, a IA também inventou credenciais inexistentes durante a operação, comportamento que lembra a possibilidade de alucinação associada ao endereço Bitcoin usado pelo JADEPUFFER. A conclusão central é que partes importantes de um ataque sofisticado estão sendo automatizadas rapidamente. Vulnerabilidades antigas, servidores expostos e credenciais padrão tornam-se alvos ainda mais acessíveis quando agentes conseguem testar, adaptar comandos e encadear ações em escala. Para organizações com sistemas negligenciados, o risco aumenta porque a exploração de bugs conhecidos pode ser feita de forma barata, repetitiva e quase contínua. A Sysdig recomenda corrigir o Langflow e evitar expor à internet endpoints capazes de executar código. Ferramentas de IA não devem operar com chaves de nuvem, tokens de provedores e credenciais sensíveis disponíveis diretamente no ambiente. Esses segredos devem ser armazenados em gerenciadores apropriados, separados de serviços acessíveis pela web. A empresa também recomenda fortalecer ambientes Nacos, trocando a chave de assinatura padrão, mantendo o serviço fora da internet pública e impedindo que ele se conecte ao banco de dados com privilégios de root. Da mesma forma, contas administrativas de banco de dados não devem ficar expostas à internet, e o tráfego de saída deve ser controlado para impedir que um servidor comprometido se comunique livremente com infraestrutura externa. Para a Sysdig, como agentes automatizados podem transformar novas divulgações de vulnerabilidades em exploração prática em poucas horas, a defesa não pode depender apenas da velocidade de aplicação de patches. Monitoramento de comportamento em tempo de execução, detecção de abuso de credenciais, análise de comandos anômalos e controle de comunicação externa passam a ser camadas essenciais. Os indicadores divulgados pela Sysdig incluem a CVE-2025-3248 como ponto de entrada, o endereço de comando e controle: 45.131.66[.]106, com beacon para hxxp://45.131.66[.]106:4444/beacon a cada 30 minutos, além do servidor de staging alegado 64.20.53[.]230. A nota de resgate usava o endereço Bitcoin 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy, o contato e78393397[@]proton[.]me e uma tabela chamada README_RANSOM. A Sysdig descreve o JADEPUFFER mais como um sinal de alerta do que como uma crise imediata. Nenhuma etapa individual do ataque era especialmente nova ou sofisticada. O que muda é a capacidade de um modelo reunir ações conhecidas em uma cadeia completa contra um servidor negligenciado. À medida que ferramentas agentic amadurecem, qualquer servidor exposto, repositório de configuração ou login administrativo de banco de dados deve ser tratado como algo que será testado por máquinas, não apenas por operadores humanos.

O lançamento do National Cyber Action Plan, nova estratégia do governo britânico para proteger a economia contra ataques cibernéticos de Estados-nação e grupos criminosos, foi novamente adiado em meio à crise de liderança no Partido Trabalhista após a renúncia do primeiro-ministro Keir Starmer. O plano deveria ser publicado na segunda-feira, mas foi postergado diante da incerteza sobre a disputa interna pela liderança do partido, prevista para começar em 9 de julho. Um porta-voz do governo afirmou que o Reino Unido continua comprometido com a publicação do National Cyber Action Plan. Segundo o governo, a proteção da segurança nacional segue como prioridade, com medidas como o Cyber Security and Resilience Bill, o Cyber Resilience Pledge e o apoio técnico prestado pelo National Cyber Security Centre, o NCSC, a organizações em todo o país. Apesar do adiamento do plano principal, uma parte da agenda deve seguir conforme previsto. Empresas do índice FTSE 350 devem assinar o Cyber Resilience Pledge, um compromisso voluntário para melhorar suas defesas digitais. A iniciativa busca elevar a segurança cibernética ao nível do conselho de administração, incentivar a adesão ao serviço Early Warning do NCSC e ampliar a exigência de certificação Cyber Essentials nas cadeias de fornecedores. O National Cyber Action Plan foi originalmente concebido como uma atualização da National Cyber Strategy 2022, estratégia que orienta a política cibernética britânica. O documento havia sido prometido ainda em 2025 por Pat McFadden, então Chancellor of the Duchy of Lancaster, com previsão de publicação antes do fim daquele ano. Em abril de 2026, o prazo já havia sido deslocado para “este verão” pelo ministro da Segurança, Dan Jarvis, e o documento deixou de ser apresentado como uma “estratégia” para ser tratado como um “plano de ação”. A mudança de cronograma ocorre em um momento politicamente sensível. McFadden fez o anúncio inicial em Manchester, cidade cujo então prefeito, Andy Burnham, passou a ser apontado como favorito para suceder Starmer após a eleição suplementar em Makerfield que precedeu a renúncia do primeiro-ministro. Até a publicação da reportagem original, nenhum outro candidato havia se apresentado formalmente para a liderança trabalhista. O atraso do National Cyber Action Plan se soma a uma série de adiamentos em iniciativas cibernéticas do governo britânico, alimentando preocupações de que a segurança digital ainda receba atenção política insuficiente em Westminster. Uma das principais medidas nessa agenda é o Cyber Security and Resilience Bill, projeto criado para atualizar as leis de cibersegurança aplicáveis à infraestrutura crítica do país. Esse projeto levou mais de quatro anos para chegar ao Parlamento e, segundo a reportagem, não deve ser plenamente aplicado antes de 2028. Isso significa que sua entrada em vigor pode ocorrer cerca de uma década depois das NIS Regulations, conjunto normativo que ele pretende substituir. A lentidão preocupa especialistas porque setores essenciais, como energia, saúde, transporte, telecomunicações e serviços digitais, seguem cada vez mais expostos a ataques disruptivos. As principais disposições do Cyber Security and Resilience Bill já haviam sido concluídas em 2022, durante o governo de Rishi Sunak. Ainda assim, o texto não foi incluído no King’s Speech daquele ano, que define a agenda parlamentar do governo, e acabou não sendo apresentado formalmente ao Parlamento. Quando o governo Starmer decidiu retomar o projeto em setembro de 2025, a tramitação foi novamente afetada por uma reforma ministerial. Outra frente atrasada envolve propostas específicas para ransomware. As medidas incluíam notificação obrigatória para todas as vítimas, um regime de licenciamento para pagamentos de extorsão e a proibição de pagamentos de resgate por operadores de infraestrutura crítica. A consulta pública sobre essas propostas deveria ter ocorrido em meados de 2024, mas foi interrompida quando Sunak convocou eleições gerais. A demora ganha peso diante de incidentes recentes que tiveram impacto nacional no Reino Unido. Durante a campanha eleitoral de 2024, um ataque de ransomware contra a fornecedora de serviços de patologia Synnovis, atribuído ao grupo Qilin, ligado à Rússia, levou hospitais de Londres a declarar incidente crítico, com cancelamento de cirurgias e consultas. Apesar da relevância política do caso, os principais partidos não trataram o ataque em profundidade durante a campanha. À época, Jamie MacColl, pesquisador do Royal United Services Institute, afirmou que, até ocorrer um grande incidente, a cibersegurança tende a não receber a cobertura nem a vontade política necessárias. Tim Stevens, líder do grupo de pesquisa em cibersegurança do King’s College London, também avaliou que o tema costuma ser tratado no Reino Unido como uma pauta “despolitizada” e de baixa prioridade. Em setembro de 2025, outro ataque cibernético atingiu a Jaguar Land Rover, uma das maiores fabricantes do Reino Unido e responsável por cerca de 4% das exportações de bens do país. A interrupção paralisou toda a produção de veículos por mais de um mês e foi classificada pelo Cyber Monitoring Centre como o evento cibernético economicamente mais danoso já registrado no Reino Unido. A organização estimou que a paralisação custou £1,9 bilhão à economia britânica, cerca de US$ 2,5 bilhões, e afetou mais de 5 mil organizações na cadeia de fornecedores da Jaguar Land Rover. A própria empresa informou posteriormente um impacto financeiro de £680 milhões, aproximadamente US$ 896 milhões. A crise foi severa o suficiente para levar o governo a garantir um empréstimo de £1,5 bilhão, cerca de US$ 2 bilhões, para ajudar a companhia a apoiar seus fornecedores. O conteúdo completo do National Cyber Action Plan ainda não foi oficialmente divulgado. A Recorded Future News informou, com base em pessoas familiarizadas com o documento, que o plano deve se estruturar em três pilares: Threat, Growth e Resilience, ou ameaça, crescimento e resiliência. Essa divisão sugere uma abordagem que combina defesa contra adversários, estímulo ao setor de cibersegurança e fortalecimento da capacidade de resposta de empresas e infraestruturas. A indicação pública mais clara sobre a direção do plano veio em junho, durante uma palestra de Richard Horne, diretor-executivo do NCSC, no Royal United Services Institute. Horne defendeu uma mobilização ampla nos chamados espaços “near, mid and far” do ciberespaço, enquadramento que deve influenciar a estrutura do plano. Na visão apresentada por Horne, o “near space” corresponde à defesa de organizações individuais. O “far space” envolve ações ofensivas contra adversários. Já o “mid space” abrange a infraestrutura compartilhada de nuvem, tecnologia e telecomunicações, em grande parte controlada pelo setor privado. Essa camada intermediária é especialmente relevante porque muitos ataques modernos exploram provedores, plataformas e interconexões que sustentam múltiplas organizações ao mesmo tempo. Segundo Horne, o governo pretende trabalhar com provedores privados para fortalecer esse “mid space” e interromper atividades de invasores. Ele também afirmou que o NCSC trabalha em direção a uma National Cyber Defense Capability, uma capacidade nacional de defesa cibernética voltada a conectar inteligência e ações nos três espaços em tempo real, especialmente em um mundo marcado por agentes de IA. Entre junho de 2024 e maio de 2026, o NCSC lidou com mais de 200 incidentes que afetaram infraestrutura nacional crítica e sua cadeia de fornecedores, segundo Horne. Cerca de 75% desses casos foram associados a agentes estatais, o que reforça a preocupação do Reino Unido com espionagem, sabotagem, ransomware e operações híbridas contra setores essenciais. O Cyber Resilience Pledge também deve ser uma peça central da agenda. Ministros do governo enviaram cartas a presidentes de conselho e CEOs de centenas de empresas, incluindo todas as companhias do FTSE 350, pedindo adesão ao compromisso. A proposta é transformar a cibersegurança em responsabilidade de alto nível executivo, e não apenas em tema técnico restrito às equipes de TI e segurança. A adesão ao serviço Early Warning do NCSC é outro ponto relevante. O programa usa inteligência britânica para alertar organizações sobre riscos iminentes, incluindo possíveis ataques de ransomware. Ao combinar alertas governamentais, certificações mínimas e exigências em cadeia de fornecedores, o governo busca elevar a maturidade de segurança de empresas que fazem parte da economia digital e da infraestrutura crítica. O adiamento do National Cyber Action Plan, no entanto, mostra como instabilidade política pode afetar diretamente a agenda de segurança cibernética. Em um cenário de ataques frequentes contra hospitais, fabricantes, fornecedores e infraestrutura crítica, atrasos em planos nacionais, leis e consultas públicas podem ampliar a janela de exposição de empresas e serviços essenciais. O caso britânico também serve de alerta para outros países. Estratégias nacionais de cibersegurança dependem não apenas de capacidade técnica, mas de continuidade política, governança, coordenação com o setor privado e mecanismos rápidos de atualização regulatória. Quando esses elementos ficam subordinados a disputas partidárias ou trocas ministeriais, a resposta do Estado tende a ficar atrás da evolução das ameaças.

A 29ª edição do International Obfuscated C Code Contest, conhecido como IOCCC, divulgou os vencedores da competição de 2025 e voltou a mostrar por que a linguagem C ainda é capaz de produzir alguns dos programas mais engenhosos, ilegíveis e surpreendentes da computação. Criado originalmente em 1984, o IOCCC premia códigos escritos em C que abusam da criatividade, da compactação extrema, da formatação visual, de truques de compilação e de técnicas deliberadamente difíceis de entender. A proposta não é escrever código limpo, seguro ou recomendado para produção, mas explorar os limites da linguagem e do compilador de forma artística, técnica e muitas vezes absurda. A edição anterior havia marcado o retorno do concurso após um hiato de quatro anos. Agora, com os resultados de 2025, a competição mostra fôlego renovado. A etapa de julgamento foi concluída algumas semanas antes da publicação, mas os vídeos de demonstração precisaram ser editados em clipes individuais para cada vencedor, já que a gravação completa no YouTube tem quase três horas. Nesta edição, foram 23 entradas vencedoras. Três participantes se destacaram com uma espécie de “hat-trick” triplo: Yusuke Endoh, Nick Craig-Wood e Don Yang venceram em três categorias cada. Como é tradição no IOCCC, os juízes Landon Curt Noll e Leonid A. Broukhis criaram categorias específicas para cada programa vencedor, com títulos que muitas vezes só fazem sentido depois de ver o código e sua execução. Um dos destaques mais curiosos foi a entrada de Adrian Cable, premiada na categoria “Best imaginary emulator”. O projeto implementa um computador Subleq em apenas 366 bytes de C, com uso da biblioteca SDL para exibir gráficos. Mesmo com essa dependência externa, o tamanho e a funcionalidade do programa impressionam. O Subleq é uma arquitetura do tipo One Instruction Set Computer, ou OISC. A ideia leva ao extremo o conceito de RISC, arquitetura de conjunto reduzido de instruções: em vez de poucas instruções, há apenas uma. Nesse caso, a instrução é “subtract and branch if less than or equal to zero”, ou subtrair e desviar se o resultado for menor ou igual a zero. O interesse pelo Subleq não é apenas acadêmico. A arquitetura aparece em iniciativas como a Eternal Software Initiative, que busca preservar software para o futuro por meio de uma arquitetura projetada para ser extremamente simples de emular. A lógica é que, quando o hardware original deixar de existir, ainda será possível reconstruir ambientes executáveis a partir de uma base mínima. A Eternal Software Initiative já implementou o Subleq em software, criou um compilador C voltado para essa arquitetura usando LLVM e portou o Linux para ela, incluindo bibliotecas de runtime C e C++. A partir daí, um emulador simples pode servir como ponto de partida para executar software em arquiteturas futuras ou desconhecidas. A versão vencedora do IOCCC condensa essa ideia em um código de apenas nove linhas. A demonstração mostra o programa gerando um conjunto de Mandelbrot colorido, rodando um jogo de Pong e, depois, executando Linux e alguns aplicativos. Uma versão um pouco mais legível do mesmo código ainda tem apenas 91 linhas. Nick Craig-Wood também teve forte presença na edição. Ele venceu a categoria “Best real emulator” com um emulador funcional do Nintendo Game Boy original em apenas 66 linhas de C, formatado visualmente para se parecer com o console. Outra entrada sua foi premiada como “Best fractional emulator”, combinando um emulador de Commodore 64 com a linguagem FRACTRAN, criada por John Conway. Craig-Wood também ganhou a categoria “Best use of Unicode” com uma implementação de Forth. Dentro do código C, há um programa em Forth capaz de gerar uma animação de zoom em Mandelbrot. O resultado reforça uma característica comum no IOCCC: muitos programas funcionam simultaneamente como código, arte visual, quebra-cabeça técnico e demonstração matemática. Yusuke Endoh, um dos nomes mais conhecidos do concurso, também venceu três vezes. Sua primeira entrada premiada em 2025 foi um simulador de tubo Nixie. Esses tubos eram usados em calculadoras eletrônicas antigas e outros equipamentos para exibir números por meio de filamentos em forma de dígitos, que acendiam individualmente. No caso de Endoh, o código-fonte foi formatado para se parecer com o objeto simulado. Mais do que isso, o próprio programa destaca os dígitos dentro do seu código em cores para simular a saída de um tubo Nixie. Ou seja, o código-fonte também funciona como mecanismo visual de exibição. A segunda entrada de Endoh gera figuras de Lichtenberg em pouquíssimo espaço. Essas figuras são padrões ramificados associados a descargas elétricas, com aparência semelhante a raios ou nervuras. Já sua terceira entrada repetidamente altera o próprio código, reconstrói a si mesma e gera como saída o código-fonte da ferramenta de diff usada no processo. A vitória marcou o 23º prêmio de Endoh no IOCCC, um recorde para o programador japonês. Outro destaque foi Tomoya Ishida, vencedor da categoria “Most soothing”. Em apenas 36 linhas de código contendo a mensagem “RELAX”, o programa gera um arquivo WAV com uma música ambiente de cinco minutos, incluindo sons sintéticos de praia. Em uma competição conhecida por confundir leitores e abusar do compilador, a entrada se destacou justamente pelo efeito relaxante. Jonah Uellenberg venceu com uma das ideias mais inventivas da edição: um jogo de Pong que também é um quine. Um quine é um programa que, quando executado, imprime seu próprio código-fonte. Essa já é uma tarefa difícil, mas o programa de Uellenberg vai além. O código contém, em seus espaços em branco, uma espécie de tela de Pong, com raquetes e bola. Quando compilado e executado, o programa aceita uma tecla para mover uma das raquetes e então imprime uma nova versão de seu próprio código, com a tela atualizada. Para jogar, é preciso recompilar a saída gerada a cada rodada. Cada frame do jogo é uma nova versão do próprio código-fonte. Entre as entradas mais convencionais, embora ainda extremamente compactas, está um roguelike em apenas 54 linhas de código, premiado como “Most likely to teleport”. Para fãs de Doctor Who, um participante identificado como “jingp49”, de Taiwan, criou uma entrada em formato de TARDIS que gera uma animação ASCII inspirada na abertura da série. A edição também trouxe programas matemáticos e jogos diminutos. Gil Dogon venceu a categoria “Consistently constant” com um programa que imprime muitos dígitos da constante de Euler usando apenas uma variável, chamada naturalmente de “e”. Como bônus, tanto os juízes quanto o participante explicaram o programa em versos. Outro vencedor, Anthony C. Howe, recebeu o prêmio “Most likely to invade” por um jogo extremamente pequeno e jogável, lembrando certos games de PC dos anos 1980 feitos para parecerem inocentes o suficiente para serem jogados no trabalho. O IOCCC também mantém uma distinção importante: ele não deve ser confundido com o Underhanded C Contest. Enquanto o IOCCC celebra truques de programação, humor técnico e criatividade inofensiva, o Underhanded C Contest explorava código enganoso com intenções mais traiçoeiras, como esconder comportamentos maliciosos ou vulnerabilidades em implementações aparentemente normais. Apesar do tom divertido, o concurso ajuda a lembrar a complexidade e a flexibilidade da linguagem C. A mesma liberdade que permite criar emuladores, jogos, sintetizadores e programas autorreferenciais em poucas linhas também pode gerar código difícil de auditar, revisar e manter. No contexto do IOCCC, isso é arte. Em sistemas de produção, porém, seria um pesadelo para segurança, manutenção e confiabilidade.

No cenário atual de cibersegurança, onde o fator humano é constantemente apontado como o mais crítico (e o mais vulnerável) da cadeia de defesa, a conscientização deixou de ser um diferencial para se tornar um pilar estratégico. Executivos de segurança da informação já perceberam que investir em awareness e educação é uma decisão inegociável, mas a dúvida que persiste na rotina dos times não é sobre o "porquê" fazer, mas sobre "como" começar sem onerar a equipe ou perder o foco no cotidiano operacional. Um dos desafios mais comuns enfrentados por quem tenta implementar iniciativas de educação continuada é o conflito de prioridades: o orçamento é curto, o tempo é escasso e a criatividade para ações que fujam do padrão corporativo tradicional é drenada pela carga de trabalho. Ainda existem obstáculos como organizar agendas entre departamentos, coordenar as lideranças, projetar iniciativas educacionais que realmente sejam capazes de gerar engajamento… Convenhamos: não é um trabalho fácil. Isto posto, a realização de uma Semana de Segurança da Informação surge como uma das ferramentas mais eficazes para o engajamento massivo. O objetivo vai além de um simples evento — a ideia central deve ser criar um ponto de inflexão no calendário anual para disseminar conhecimento, reforçar políticas de segurança e, principalmente, aproximar o time de SI das demais áreas da organização. Além disso, uma Semana de SI é um excelente ponto de partida para um novo (ou renovado) programa contínuo de awareness. O desafio do planejamento Embora o conceito possa parecer simples à primeira vista, a execução bem-sucedida de uma Semana da Segurança exige uma estruturação que considere diferentes perfis de colaboradores e maturidades digitais. O que funciona em uma startup pode não ter o mesmo impacto em uma empresa de grande porte, e é nessa etapa de planejamento que muitos projetos perdem o fôlego antes mesmo de começar. Para suprir essa necessidade de material técnico e estratégico, a Eskive, solução nacional pioneira em human risk management, disponibilizou recentemente um kit de planejamento, consolidando seus mais de 17 anos de atuação no mercado em um pacote de materiais com estratégias concretas e validadas. A proposta é oferecer um norte para gestores que desejam escalar iniciativas de conscientização. O que compõe o Kit de Planejamento? O Kit de Planejamento de Semana da Segurança da Informação 2026 foi desenvolvido para ser um material "ready to go", focando em três conteúdos diferentes, porém igualmente fundamentais, para quem precisa sair da inércia: Guia Completo de Planejamento: uma cartilha que aborda estratégias de estruturação, ajudando a alinhar expectativas de budget e cronogramas, desde a fase de preparação até o pós-evento. Templates de Cronogramas: modelos editáveis que facilitam a organização da proposta, adaptáveis a diferentes realidades de negócio e prontos para serem apresentados às lideranças. Ideias de Ações Práticas: sugestões que vão além do óbvio, focadas em engajamento real e fixação de conhecimento, permitindo uma abordagem mais lúdica e eficiente. A proposta do kit não é resolver todos os seus problemas, mas sim ser um facilitador, permitindo que a equipe de SI foque no que realmente importa: a construção de uma cultura de segurança robusta. A ideia não é substituir o programa de conscientização contínuo, mas sim oferecer uma "alavanca" que inicie ou turbine a educação dos colaboradores. Para quem busca transformar a teoria em prática e realizar uma Semana da Segurança que gere resultados tangíveis, o material está disponível para download gratuito. Acesse aqui e baixe o Kit de Planejamento de Semana da Segurança 2026.

O grupo hacker ToddyCat foi associado a uma nova ferramenta maliciosa chamada Umbrij, desenvolvida para acessar de forma furtiva comunicações corporativas hospedadas no Gmail por meio da Google API. A campanha foi detalhada pela Kaspersky, que afirma que os invasores concentraram seus esforços no comprometimento de e-mails empresariais usando tokens OAuth como caminho de acesso. Segundo a empresa, o ataque explora o funcionamento do OAuth 2.0, protocolo usado pela Google API para autorizar aplicações a acessar recursos de uma conta. Em vez de roubar diretamente a senha da vítima, o Umbrij busca obter um código de autorização OAuth e trocá-lo por um token de acesso. Com esse token, os invasores conseguem interagir com recursos da conta Google por meio da API, incluindo comunicações de e-mail. A técnica foi batizada pela Kaspersky de Shadow Token via Remote Debug, ou STRD. O método se apoia em uma sessão ativa do Gmail em navegadores baseados em Chromium, como Google Chrome e Microsoft Edge. Na prática, o malware inicia o navegador em modo headless, ou seja, sem interface gráfica visível, conecta-se a ele por uma porta de depuração remota e aproveita uma sessão já autenticada para solicitar acesso aos recursos da conta. Esse detalhe torna a abordagem especialmente relevante para ambientes corporativos. Se o usuário já estiver logado em serviços do Google no navegador, o Umbrij pode usar esse estado de autenticação para avançar no fluxo OAuth, selecionar a conta correta e conceder permissões à aplicação usada no processo. Com isso, os invasores contornam parte das barreiras tradicionais associadas ao roubo de credenciais. A Kaspersky identificou três versões diferentes do Umbrij. Algumas delas incluem funções auxiliares para depuração e recursos para buscar e selecionar contas de usuário dentro do navegador. O malware foi escrito em .NET e ofuscado com ConfuserEx, um ofuscador open source usado para dificultar a análise do código e a detecção por ferramentas de segurança. O ToddyCat é classificado como uma ameaça persistente avançada, ou APT, com histórico de ataques contra organizações na Europa e na Ásia desde pelo menos 2020. Em novembro de 2025, a Kaspersky já havia detalhado o uso, pelo grupo, de uma ferramenta personalizada chamada TCSectorCopy, empregada para coletar dados de e-mail do Microsoft Outlook pertencentes a empresas alvo. O Umbrij foi descoberto durante uma operação de threat hunting da Kaspersky. A investigação identificou uma tarefa agendada que se passava por um componente da própria empresa, usando o nome “KasperskyEndpointSecurityEDRAvp”, para iniciar um arquivo assinado digitalmente. Esse arquivo, por sua vez, abusava de uma técnica conhecida como DLL side-loading para carregar a DLL maliciosa do Umbrij. DLL side-loading ocorre quando um executável legítimo é usado para carregar uma biblioteca maliciosa no lugar de uma DLL esperada ou confiável. Nessa campanha, os invasores abusaram de três binários legítimos vulneráveis a essa técnica: BDSubWiz.exe, componente do Submission Wizard no Bitdefender ConnectAgent; VSTestVideoRecorder.exe, ferramenta de gravação de vídeo usada em testes com o Microsoft Visual Studio; e GoogleDesktop.exe, antigo aplicativo Google Desktop Search usado para indexar arquivos e fazer buscas locais no Windows. Independentemente do executável usado, o resultado era o mesmo: a execução da DLL maliciosa do Umbrij. A ferramenta também pode ser chamada com parâmetros de linha de comando para definir quais navegadores devem ser alvo, como Chrome ou Edge, salvar uma captura do perfil do usuário como arquivo PDF e indicar o nome do usuário do sistema sob o qual o malware deverá operar. Depois de executado em um host Windows comprometido, o Umbrij realiza uma série de etapas preparatórias para acessar a conta Gmail. Primeiro, verifica se a porta destinada à depuração do navegador está disponível. Em seguida, tenta obter o contexto do usuário procurando pelo processo “explorer.exe” e duplicando o token do primeiro processo encontrado. Essa ação permite que o malware preserve os privilégios do usuário logado. Alternativamente, os operadores podem usar o parâmetro “-user” para especificar qual conta local deve ser alvo. Na sequência, o malware constrói o caminho até a pasta do navegador dentro do diretório de dados locais do usuário e analisa o arquivo “Local State” do Chrome ou do Edge para coletar informações sobre os perfis armazenados. Ele enumera esses perfis e procura pelo campo “user_name” contendo um endereço de e-mail. A presença desse endereço indica que o usuário está autenticado em algum serviço do Google. O Umbrij então cria um diretório chamado “BackupFiles” dentro das pastas locais do Chrome e do Edge. Para cada perfil alvo, ele copia arquivos e diretórios como IndexedDB, Local Storage, Network, Login Data, Login Data For Account, Preferences, Secure Preferences e Web Data. Caso algum desses arquivos esteja bloqueado por outros processos, a ferramenta inclui um mecanismo de cópia forçada. Depois disso, o malware busca as pastas de instalação do Chrome e do Edge nos diretórios “Program Files” e “Program Files (x86)”. Em seguida, inicia o navegador em modo headless usando o perfil copiado para a pasta “BackupFiles”. Esse processo faz com que o navegador carregue cookies ativos do usuário, incluindo a sessão autenticada na conta Google, sem exigir uma nova autenticação. Com o navegador em execução, o Umbrij usa o Puppeteer, biblioteca JavaScript usada para controlar navegadores Chromium por meio do Chrome DevTools Protocol. A ferramenta se conecta à porta de depuração remota e envia uma solicitação de código de autorização para uma URL do domínio accounts.google[.]com. Essa solicitação inclui um “client_id” correspondente a uma ferramenta de migração usada para importar arquivos PST locais e dados de contas Microsoft Exchange para uma conta Google Workspace. A requisição HTTP também especifica o conjunto de permissões solicitado pela aplicação. Em seguida, o malware usa JavaScript para emular cliques do mouse, selecionar a conta Google apropriada e conceder as permissões necessárias. Entre os acessos solicitados estão permissões amplas para Gmail, Drive, Contacts, Calendar e Tasks. Após a concessão das permissões, a sessão do navegador é redirecionada para um endereço local definido na solicitação inicial. O Umbrij então extrai o código de autorização OAuth desse redirecionamento. Segundo a Kaspersky, o malware registra suas ações em detalhes e salva tudo em um arquivo de log, incluindo o código de autorização obtido. Posteriormente, o operador exfiltra esse arquivo do host comprometido. Com o código de autorização em mãos, os invasores podem trocá-lo por um token de acesso OAuth. Esse token é então usado para conectar-se à conta Gmail por meio da API, comprometendo as comunicações corporativas sem depender diretamente de uma senha roubada. A técnica mostra uma evolução no foco de grupos APT contra ambientes de e-mail corporativo. Ao abusar de sessões autenticadas, APIs legítimas, OAuth e ferramentas de migração reconhecidas pelo ecossistema Google Workspace, os operadores reduzem a visibilidade do ataque e podem parecer, em determinados estágios, uma aplicação autorizada acessando recursos permitidos. Para mitigar o risco, a Kaspersky recomenda revisar os códigos de autorização concedidos a aplicações na página de conexões da conta Google, em myaccount.google[.]com/connections. As organizações devem procurar por aplicações chamadas “Google Workspace Migration for Microsoft Outlook” ou “Google Workspace Sync for Microsoft Outlook”. Se uma dessas aplicações aparecer e não for usada legitimamente pela organização, o acesso deve ser revogado para invalidar os tokens OAuth associados. Andrey Gunkin, analista sênior de malware da Kaspersky, afirmou que o ToddyCat continua buscando novas formas de comprometer comunicações corporativas por e-mail. Segundo ele, o Umbrij automatiza tentativas de acesso a contas organizacionais, o que aumenta a escala e a frequência dos ataques e demonstra forte motivação e capacidade técnica avançada do grupo.

Pesquisadores da Blackpoint Cyber identificaram um novo framework modular de malware, ainda não documentado anteriormente, chamado Avalon. A ferramenta é distribuída por uma cadeia de phishing em múltiplas etapas e reúne capacidades normalmente vistas em diferentes fases de um ataque, incluindo coleta de credenciais, acesso remoto, movimento lateral, interrupção de mecanismos de recuperação e execução de ransomware. O componente de ransomware do Avalon foi batizado internamente de CrownX. Segundo os pesquisadores Nevan Beal e Sam Decker, a campanha começa com um e-mail falso simulando um documento jurídico. A mensagem direciona a vítima para um arquivo protegido por senha hospedado no Proton Drive, estratégia que ajuda a reduzir a detecção por filtros tradicionais de e-mail. Em vez de anexar diretamente o conteúdo malicioso à mensagem, os invasores o escondem dentro de uma imagem ISO. Essa abordagem dificulta a inspeção no nível do e-mail e permite que o ataque avance apenas quando a vítima abre o arquivo e interage com o conteúdo montado no sistema. Dentro da imagem ISO, há um atalho do Windows com aparência de documento, chamado “Secure Document CA-283505.pdf.lnk”. Caso a vítima execute esse arquivo, o atalho aciona uma sequência em estágios que culmina na implantação do Avalon. O primeiro passo é a execução de um comando que inicia um projeto MSBuild localizado dentro da própria imagem ISO. O projeto MSBuild carrega um assembly .NET incorporado, que interfere no funcionamento normal do Event Tracing for Windows, ou ETW. O ETW é um recurso do Windows usado para telemetria, rastreamento e análise de eventos do sistema. Ao prejudicar esse mecanismo, o malware reduz a visibilidade forense da execução e dificulta a detecção por ferramentas de segurança. Depois disso, o componente baixa uma nova carga maliciosa via HTTPS, responsável por iniciar o Avalon no sistema comprometido. A partir desse ponto, o framework passa a operar com um amplo conjunto de módulos voltados à evasão, coleta de dados, persistência operacional e preparação para extorsão. Um dos pontos centrais do Avalon é seu subsistema de evasão de defesa. De acordo com a Blackpoint Cyber, o framework inclui técnicas específicas para ocultar sua execução de ferramentas associadas a Microsoft Defender, SentinelOne, CrowdStrike, Sophos, Elastic Endpoint, FortiEDR, ESET, McAfee e Bitdefender. Essas capacidades permitem ao malware reduzir telemetria, contornar monitoramento em modo usuário e ajustar seu comportamento conforme os controles defensivos presentes no host. Na prática, isso dá aos operadores mais flexibilidade para executar o ataque em ambientes corporativos com diferentes camadas de proteção. O Avalon também possui funções de roubo de informações. Ele coleta credenciais, cookies, histórico e favoritos de navegadores baseados em Chromium e do Mozilla Firefox. Esse tipo de dado pode permitir acesso indevido a aplicações corporativas, contas pessoais, painéis administrativos e sistemas protegidos por sessões autenticadas. Além dos navegadores, o malware busca dados em carteiras de criptomoedas e aplicações relacionadas, incluindo MetaMask, Phantom, Coinbase Wallet, Exodus, Electrum, Atomic Wallet, Ledger Live e Bitcoin Core. A lista de alvos também inclui Discord, Slack, Microsoft Teams, OpenVPN, WireGuard e Windows Credential Manager, ampliando o impacto potencial sobre ambientes de colaboração, acesso remoto e autenticação. O framework ainda coleta informações sobre hosts conhecidos em SSH, conexões RDP salvas, perfis de Wi-Fi e artefatos “cpassword” de Group Policy Preferences. Esse conjunto de dados pode apoiar movimento lateral, descoberta de ativos e comprometimento de novas máquinas dentro da rede. Após a coleta, os dados são exfiltrados para um servidor remoto associado ao domínio “helloxcherry[.]com”. O Avalon também consulta esse servidor para receber comandos de tarefa, funcionando como um canal de comando e controle. Esse canal permite que os operadores ajustem a operação após o comprometimento inicial, executando ações adicionais de acordo com o ambiente da vítima. Outro recurso importante é a capacidade de reconhecimento. O Avalon pode identificar e priorizar sistemas que ajudem a expandir o alcance da invasão. Isso é relevante em ataques corporativos porque um único endpoint comprometido pode servir como ponto de partida para acessar servidores, credenciais administrativas, compartilhamentos de rede e sistemas críticos. A etapa final de extorsão fica a cargo do CrownX. O componente criptografa arquivos associados a operações de negócio, desenvolvimento de software, engenharia, armazenamento de dados e infraestrutura virtual. Para isso, utiliza a Windows Cryptography API, recurso legítimo do sistema operacional para operações criptográficas. Depois da criptografia, o ransomware entrega uma nota de resgate com instruções de pagamento e temporizadores de prazo, indicando quanto tempo resta antes que o valor exigido seja aumentado. Esse tipo de pressão é comum em campanhas de ransomware, pois busca reduzir o tempo de reação da vítima e forçar uma decisão rápida. A Blackpoint Cyber observa que o dano causado pelo Avalon vai além da criptografia. Antes da exibição da nota de resgate, o framework já pode ter coletado credenciais, estabelecido comunicação com servidores de comando e controle, preparado caminhos para movimento lateral e enfraquecido opções locais de recuperação. Para dificultar a restauração dos sistemas, o Avalon encerra o serviço de cópias de sombra de volume do Windows e apaga shadow copies. Essas cópias normalmente podem ser usadas para recuperar arquivos e estados anteriores do sistema. Ao removê-las, os invasores aumentam a dependência de backups externos e reduzem a capacidade de recuperação rápida. O malware também inclui um subsistema de limpeza anti-forense. Esse recurso remove rastros de artefatos criados durante a execução, complicando o trabalho de resposta a incidentes, análise de causa raiz e reconstrução da cadeia de ataque. Outro comportamento descrito pelos pesquisadores envolve interação direta com estruturas de disco. A avaliação é que o framework pode tentar danificar informações de partição, registros de inicialização ou outras áreas críticas do drive, o que pode tornar o sistema inutilizável. Esse tipo de recurso aproxima a ameaça de operações destrutivas, não apenas de extorsão baseada em criptografia. Segundo a Blackpoint Cyber, o Avalon apresenta indícios de desenvolvimento assistido por inteligência artificial. O framework reúne vários componentes e capacidades complexas, mas com sinais de menor refinamento em tradecraft e segurança operacional. Isso sugere que ferramentas de IA podem ter sido usadas para acelerar a criação do malware, mesmo sem o mesmo nível de maturidade técnica esperado em grupos altamente experientes. A descoberta reforça uma mudança importante no cenário de ameaças. A presença de recursos avançados em um malware já não é, por si só, um indicador confiável de sofisticação operacional do agente. Ferramentas baseadas em IA podem permitir que invasores com menos conhecimento técnico combinem módulos de roubo de dados, evasão, acesso remoto e ransomware em um tempo menor e com menos esforço. A cadeia de ataque descrita pela Blackpoint Cyber mostra como uma isca corporativa comum, como um suposto documento jurídico, pode evoluir para um framework reutilizável e multifuncional. A partir de um único endpoint comprometido, os invasores conseguem colher credenciais, buscar novas cargas diretamente em memória e preparar várias ações subsequentes. O relatório foi divulgado em um momento em que outras pesquisas também apontam para o avanço do uso de IA em operações ofensivas. A Sysdig detalhou o que descreveu como a primeira infecção pública de ransomware agentic, conduzida de ponta a ponta por um grande modelo de linguagem, com capacidade de tentar novamente e ajustar ações em tempo real para completar tarefas. O agente de ameaça por trás dessa operação foi identificado como JADEPUFFER. Segundo a Sysdig, o operador obteve acesso inicial a uma instância Langflow exposta à internet por meio da CVE-2025-3248. Em seguida, executou uma campanha adaptativa e totalmente automatizada, avançando até o alvo pretendido e realizando uma operação destrutiva de extorsão contra o servidor de banco de dados de produção da vítima. Para a Sysdig, o custo e a complexidade de executar ransomware caíram significativamente quando agentes automatizados entram no processo. Se esses agentes operam usando credenciais roubadas e recursos obtidos por LLMjacking, o custo para o invasor pode se aproximar de zero. Outra descoberta recente, atribuída à Palo Alto Networks Unit 42, mostrou um malware baseado em IA que combina um bot do Telegram com uma API pública de modelo de linguagem para conduzir ataques sem exigir que o operador conheça sintaxe de linha de comando. Após ser executado, o implante envia informações básicas do sistema comprometido ao bot do invasor e entra em um loop de comando e controle que consulta a API do Telegram a cada cinco segundos. Nesse caso, cada mensagem enviada pelo operador em linguagem natural é encaminhada para um endpoint público de LLM, “api.groq[.]com/openai/v1/chat/completions”. O modelo transforma a instrução em um comando shell equivalente, que é executado pela máquina da vítima. Os resultados são então exfiltrados pelo mesmo canal. Segundo a Unit 42, o diferencial desse malware é a camada de tradução por LLM, que substitui a necessidade de comandos técnicos por instruções em texto simples. O invasor digita o que deseja fazer no Telegram, o modelo converte a ordem em comando shell e o dispositivo comprometido executa a ação. O artefato analisado foi enviado ao VirusTotal em 11 de março de 2026 e, até a divulgação, permanecia sem detecção por todos os mecanismos. O caso reforça a dificuldade de identificar ameaças que combinam infraestrutura legítima, automação e modelos de linguagem para reduzir a necessidade de código malicioso tradicional. No conjunto, Avalon, JADEPUFFER e o malware com LLM via Telegram indicam uma convergência entre ransomware, automação ofensiva e uso prático de IA em campanhas maliciosas. Para equipes de segurança, isso aumenta a importância de monitorar não apenas arquivos e assinaturas conhecidas, mas também comportamento, abuso de ferramentas legítimas, execução em memória, comunicação com APIs e anomalias em fluxos de autenticação e administração.

A empresa de segurança runZero revelou sete vulnerabilidades no FatFs, uma pequena biblioteca de sistema de arquivos usada para permitir que dispositivos leiam e gravem nos formatos FAT e exFAT, comuns em pendrives USB, cartões SD e mídias de armazenamento removíveis. O problema chama atenção pela ampla presença do FatFs em dispositivos embarcados. A biblioteca é incorporada ao firmware de câmeras de segurança, drones, controladores industriais, carteiras físicas de criptomoedas, equipamentos baseados em sistemas operacionais de tempo real e diversos outros produtos conectados ou especializados. Nos sistemas mais afetados, um invasor que consiga inserir em um dispositivo um pendrive, cartão SD ou arquivo de atualização manipulado pode provocar corrupção de memória e, em determinados cenários, executar código próprio no equipamento. Esse tipo de falha é especialmente preocupante em ambientes embarcados porque muitos desses dispositivos não contam com as mesmas proteções de memória presentes em smartphones, notebooks e desktops modernos. Segundo a runZero, em alguns casos “qualquer acesso físico leva a um jailbreak”. A frase resume o risco de um cenário em que um simples contato com uma porta USB, um slot para cartão SD ou um fluxo de atualização pode ser suficiente para assumir controle indevido de um dispositivo. Em tese, quiosques públicos, câmeras com entrada SD, caixas eletrônicos ou máquinas de votação com porta USB não deveriam permitir comprometimento total após poucos instantes de acesso físico, mas as vulnerabilidades mostram que esse risco pode existir. As sete falhas seguem a mesma lógica geral. O dispositivo tenta ler um volume de armazenamento ou uma imagem de firmware deliberadamente malformada, e o FatFs processa esses dados incorretamente. A runZero classificou o conjunto com pontuações CVSS de severidade média a alta, sem vulnerabilidades críticas. A principal falha é a CVE-2026-6682, com CVSS 7.6 e severidade alta. Trata-se de um integer overflow no código responsável por montar volumes FAT32. Na prática, um erro de cálculo pode gerar um tamanho de arquivo falso, que depois é interpretado por outras partes do código como um tamanho real de leitura. Em hardware real, esse comportamento pode levar à corrupção de memória e possível execução de código. Outra vulnerabilidade de alto impacto é a CVE-2026-6687, também com CVSS 7.6. Ela envolve um campo de rótulo de volume exFAT que pode estourar um buffer pequeno, oferecendo ao invasor um ponto de entrada para corrupção de memória. A CVE-2026-6688, com a mesma pontuação, afeta nomes longos de arquivos e pode explorar falhas no código de integração que muitos projetos adicionam ao redor do FatFs, como o uso de strcpy para copiar fno.fname para buffers fixos. Por esse motivo, a correção não depende apenas do FatFs, mas também de como cada fornecedor implementou a biblioteca. Entre as falhas de severidade média está a CVE-2026-6685, com CVSS 6.1, causada por um erro matemático no tratamento de cache em volumes fragmentados. O problema pode provocar corrupção silenciosa de dados. A CVE-2026-6683, com CVSS 4.6, é uma divisão por zero em exFAT que pode travar o dispositivo e, em fluxos de atualização, até inutilizar o hardware. Essa falha também pode ser explorada por meio de alguns processos de firmware update. A CVE-2026-6686, com CVSS 4.6, permite que um arquivo estendido além de seu fim vaze dados residuais de arquivos apagados anteriormente. Já a CVE-2026-6684, também com CVSS 4.6, envolve uma tabela de partição GPT malformada, capaz de fazer o dispositivo travar durante o processo de montagem. Essa é a única das sete vulnerabilidades que já foi corrigida no projeto original, na versão FatFs R0.16. A parte mais difícil do caso está na cadeia de correção. O FatFs é mantido por um único desenvolvedor em uma estrutura pequena e pouco formalizada. Segundo a runZero, a empresa tentou contato repetidas vezes com o mantenedor e envolveu o JPCERT/CC, centro japonês de coordenação de vulnerabilidades, mas não obteve resposta. De acordo com a runZero, não há correção upstream para as falhas de corrupção de memória, não existe uma lista pública de segurança e não há um processo claro para que os inúmeros produtos que integram o FatFs sejam informados de que estão vulneráveis. Atualizar para a versão mais recente ajuda no caso da falha de travamento envolvendo GPT, mas as demais correções ficam nas mãos dos fornecedores que incorporaram a biblioteca a seus próprios produtos. A empresa citou plataformas afetadas como Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT e SWUpdate. Isso amplia o alcance do problema para dispositivos IoT de consumo, equipamentos industriais, drones, carteiras físicas de criptomoedas e mecanismos de atualização de firmware. Até a divulgação da runZero em 1º de julho, não havia relatos de ataques explorando essas vulnerabilidades, e nenhum caso público foi identificado desde então. Ainda assim, o material de exploração já está disponível. A empresa publicou imagens de disco para prova de conceito, um ambiente de testes e um exemplo funcional de exploração baseado em QEMU em um repositório complementar. Para fabricantes que desenvolvem firmware capaz de interagir com mídias FAT ou exFAT, a recomendação é localizar a cópia do FatFs usada no produto, auditar o código de integração ao redor da biblioteca, revisar com atenção o tratamento de nomes de arquivos e tamanhos de arquivos e planejar correções. Em muitos casos, o risco não estará apenas na biblioteca original, mas na forma como cada projeto usa seus retornos, buffers e estruturas. Para organizações que operam dispositivos potencialmente afetados, portas físicas e canais de atualização devem ser tratados como superfície de ataque. Isso significa limitar quem pode conectar mídias removíveis, controlar o acesso físico a equipamentos expostos, validar processos de atualização de firmware e acompanhar comunicados dos fornecedores. O caso também mostra uma tendência mais ampla na descoberta de vulnerabilidades em bibliotecas C amplamente embarcadas. A runZero havia auditado manualmente o FatFs em 2017 e encontrou pouco material relevante para reporte. Em março de 2026, a equipe retornou ao mesmo código usando uma configuração relativamente comum: Visual Studio Code, GitHub Copilot em modo automático e alguns prompts simples. Com esse apoio, o modelo de linguagem gerou um fuzzer, ferramenta usada para fornecer dados malformados ao código até que algo falhe. Esse processo revelou bugs que a auditoria manual anterior não havia identificado e ajudou a confirmar que eles eram exploráveis. A descoberta se encaixa em um padrão recente. No fim de 2024, o agente Big Sleep, do Google, encontrou uma falha real e explorável de memória no SQLite que havia passado despercebida por fuzzing convencional. Mais recentemente, um agente autônomo de IA revelou 21 bugs de segurança de memória no FFmpeg, outra biblioteca em C amplamente embarcada em produtos e projetos. O argumento da runZero é direto: se uma abordagem relativamente acessível com IA consegue encontrar esse tipo de falha, agentes maliciosos também podem fazer o mesmo. Por isso, manter vulnerabilidades em silêncio não protege os usuários, especialmente quando o código está presente em milhões de dispositivos e a cadeia de correção é lenta ou fragmentada. O desafio de patching tende a ser prolongado. A runZero avalia que as correções downstream podem levar anos, não dias. O precedente citado é o PixieFail, conjunto de nove vulnerabilidades divulgado em 2024 no código de boot de rede do EDK II, firmware usado por diversas marcas de PCs e servidores, cuja correção demorou a chegar a muitos fornecedores. O caso do FatFs tem formato semelhante, mas com um agravante: a ausência de um upstream responsivo para coordenar correções. Até que o mantenedor publique patches ou que grandes plataformas que incorporam a biblioteca adotem mitigação própria, muitos dispositivos em operação provavelmente continuarão lendo mídias não confiáveis com código vulnerável e sem uma correção central disponível.

Um novo relatório do Citizen Lab revelou que Stelios Kouloglou, ex-membro do Parlamento Europeu, teve seu iPhone invadido repetidas vezes pelo spyware Pegasus enquanto integrava uma comissão criada justamente para investigar o uso abusivo de ferramentas comerciais de vigilância na União Europeia. Segundo os pesquisadores John Scott-Railton, Bill Marczak, Bahr Abdul Razzak, Kate Pundyk, Siena Anstis e Ron Deibert, a análise forense do dispositivo indicou que os invasores podem ter acessado documentos confidenciais e deliberações internas da comissão parlamentar. Até o momento, as infecções não foram atribuídas publicamente a um governo específico, e o Citizen Lab afirmou não haver evidências de que o governo da Grécia esteja por trás da atividade. Ainda assim, o laboratório canadense identificou uma sobreposição entre a primeira infecção no aparelho de Kouloglou e uma campanha anterior contra jornalistas e ativistas exilados de língua russa e bielorrussa na Europa. Essa ligação sugere, segundo os pesquisadores, que um cliente do Pegasus com autorização para operar em múltiplos países europeus provavelmente esteve envolvido na operação. Kouloglou integrou o “Committee of Inquiry to investigate the use of Pegasus and equivalent surveillance spyware”, conhecido como Comitê PEGA, entre 24 de março de 2022 e 18 de julho de 2023. A comissão havia sido criada em 10 de março de 2022 para apurar denúncias de uso indevido de spyware comercial sob a legislação da União Europeia, com foco em identificar até que ponto Estados-membros e outros países estavam empregando essas ferramentas de forma incompatível com direitos e liberdades fundamentais da região. A análise forense feita pelo Citizen Lab a partir de artefatos coletados do iPhone de Kouloglou em maio de 2026 concluiu que o aparelho foi comprometido com o Pegasus por volta de 21 de outubro de 2022 e novamente nos dias 6 e 7 de março de 2023. Nas duas ocasiões, o dispositivo executava o iOS 15.5. No primeiro ataque, os pesquisadores observaram uma consulta a um endereço de e-mail associado ao HomeKit, rauharepo888[@]gmail.com. Dois minutos depois, um processo ligado ao Pegasus usou dados móveis no aparelho. A avaliação do Citizen Lab é que os invasores exploraram uma vulnerabilidade zero-click no software de casa inteligente da Apple, identificada pelo codinome PWNYOURHOME, para instalar o spyware sem exigir interação da vítima. A falha foi corrigida pela Apple no iOS 16.3.1. A atividade observada em março de 2023 também teria usado o mesmo exploit. O Citizen Lab informou ainda que Kouloglou recebeu notificações da Apple alertando sobre tentativas de ataque com spyware mercenário em três ocasiões: 2 de março de 2023, 29 de agosto de 2023 e 10 de abril de 2024. O momento das infecções aumenta a gravidade do caso. Durante a primeira invasão, em outubro de 2022, Kouloglou estava internado para uma cirurgia eletiva e havia recebido a visita do jornalista investigativo grego Thanasis Koukakis. Koukakis também foi vítima de spyware, mas com o Predator, ferramenta associada à Intellexa, e havia testemunhado perante o Comitê PEGA um mês antes. A segunda infecção, em março de 2023, coincidiu com discussões intensas sobre a redação final do relatório da comissão e com uma série de audiências do Comitê PEGA. O ataque ocorreu cerca de dois meses antes da adoção do primeiro relatório produzido pela comissão. O caso marca a primeira vez em que um membro do Comitê PEGA é publicamente identificado como vítima do Pegasus enquanto exercia função dentro da própria comissão criada para investigar esse tipo de abuso. Para os pesquisadores, a possibilidade de acesso a documentos internos e discussões confidenciais levanta preocupações diretas sobre espionagem política, interferência institucional e proteção de processos democráticos. A conexão entre o caso de Kouloglou e a campanha contra jornalistas independentes e ativistas de oposição russos e bielorrussos na Europa se baseia no uso do mesmo endereço rauharepo888[@]gmail.com. Segundo o Citizen Lab, dentro da infraestrutura de infecção do Pegasus observada naquele período, esses e-mails parecem ser únicos para operadores específicos. Os pesquisadores, porém, afirmaram não ser possível determinar se a segunda infecção de 2023 foi conduzida pelo mesmo operador ou por outro. Com base no modelo de licenciamento conhecido do NSO Group, desenvolvedor do Pegasus, o Citizen Lab avalia que o caso provavelmente aponta para um cliente com licença capaz de realizar infecções em várias jurisdições da União Europeia. Isso reduz o conjunto de possíveis operadores, embora não permita uma atribuição pública definitiva. As descobertas reacendem preocupações sobre o uso de spyware comercial vendido oficialmente para combater crimes graves, como terrorismo e abuso sexual infantil, mas empregado em diversos casos contra jornalistas, parlamentares, dissidentes, ativistas e críticos de governos. O Pegasus é uma das ferramentas mais conhecidas desse mercado por sua capacidade de comprometer dispositivos móveis, acessar mensagens, arquivos, microfone, câmera e outros dados sensíveis. O relatório também se soma a outras investigações recentes do Citizen Lab sobre ferramentas de vigilância digital. Dias antes, o laboratório havia revelado que autoridades russas usaram ferramentas forenses UFED, da Cellebrite, para acessar o iPhone do ativista de oposição Andrey Pivovarov em junho de 2021. O caso ocorreu três meses depois de a Cellebrite anunciar que deixaria de oferecer produtos e serviços à Rússia e à Bielorrússia. De acordo com o Citizen Lab, as autoridades buscaram nos dispositivos de Pivovarov nomes de organizações, contatos e figuras de destaque da oposição, incluindo Mikhail Khodorkovsky, fundador da Open Russia; Anastasiya Burakova, então advogada de direitos humanos ligada à Open Russia e hoje líder de um grupo antiguerra; e Tatiana Usmanova, ex-coordenadora da Open Russia e parceira de Pivovarov. Algumas dessas pessoas, incluindo Burakova, foram posteriormente alvo de uma campanha de phishing atribuída ao grupo hacker russo COLDRIVER. Para os pesquisadores, isso levanta a possibilidade de que o uso das ferramentas da Cellebrite tenha contribuído para atividades de reconhecimento e facilitado novos alvos de vigilância contra opositores do regime no exterior. Em abril, o Citizen Lab também revelou duas campanhas de espionagem de longa duração que exploravam fraquezas conhecidas na infraestrutura global de telecomunicações para rastrear a localização de pessoas. Diferentemente de ataques com spyware instalado diretamente no aparelho, essas operações não exigiam a implantação de malware, o que as torna mais discretas e difíceis de detectar. Uma das campanhas usava mensagens SMS especiais com comandos ocultos maliciosos para transformar o dispositivo em uma espécie de sinalizador de rastreamento. A outra explorava fragilidades nos protocolos de sinalização SS7 e Diameter, usados por operadoras de telecomunicações, para acompanhar a localização de indivíduos sem acesso direto aos aparelhos. Segundo o Citizen Lab, as campanhas abusaram de três provedores específicos: 019Mobile, Airtel Jersey, parte da Sure Group, e Tango Networks U.K. Essas empresas teriam funcionado como pontos de entrada e trânsito para vigilância dentro do ecossistema de telecomunicações, permitindo que tráfego passasse por interconexões consideradas confiáveis enquanto os operadores ocultavam sua atribuição por trás dessa infraestrutura. Os pesquisadores afirmaram que os operadores usaram ferramentas de vigilância personalizadas para falsificar identidades de operadoras, manipular protocolos de sinalização e direcionar tráfego por rotas específicas de interconexão, com o objetivo de contornar defesas e dificultar atribuição. O conjunto das descobertas mostra como fornecedores comerciais de vigilância e seus clientes exploram diferentes camadas da infraestrutura digital, de smartphones e sistemas operacionais a redes de telecomunicações. No caso de Kouloglou, o impacto é especialmente sensível porque o alvo não era apenas um parlamentar, mas um integrante de uma comissão encarregada de investigar o próprio mercado de spyware e seus abusos na Europa.

Um agente de ameaça até então não documentado, identificado como Armored Likho, foi associado a ataques cibernéticos contra órgãos governamentais e empresas do setor de energia elétrica na Rússia, no Brasil e no Cazaquistão. A atividade foi detalhada pela Kaspersky, que descreve o grupo como um operador híbrido, capaz de combinar campanhas com motivação financeira contra indivíduos com operações direcionadas de espionagem cibernética contra organizações. Segundo a análise técnica da empresa, o arsenal do Armored Likho inclui RATs, infostealers e ferramentas modulares com forte uso de ofuscação, projetadas para dificultar análise dinâmica e reduzir a chance de detecção por soluções de segurança. Entre os recursos observados está o Go2Tunnel, ferramenta usada para acesso remoto e tunelamento de rede, permitindo estabelecer conexões persistentes entre máquinas comprometidas e servidores de comando e controle. A variedade de ferramentas empregadas pelo grupo permite manter acesso contínuo a hosts invadidos, roubar credenciais e dados sensíveis, além de entregar módulos diferentes de acordo com o perfil da vítima. Essa abordagem sugere uma operação flexível, capaz de adaptar a cadeia de ataque conforme o alvo, o ambiente comprometido e os objetivos da campanha. A Kaspersky também identificou possíveis sobreposições entre o Armored Likho e um cluster rastreado pela BI.ZONE como Eagle Werewolf, ativo desde maio de 2023. Esse grupo tem histórico de ataques contra organizações governamentais e do setor de defesa, especialmente entidades ligadas ao desenvolvimento e à fabricação de veículos aéreos não tripulados, os UAVs. As campanhas atribuídas ao Eagle Werewolf já envolveram droppers, trojans de acesso remoto e utilitários para criação de túneis SSH. De acordo com a BI.ZONE, os invasores podem usar canais comprometidos no Telegram para distribuir malware. Embora a principal motivação atribuída ao grupo seja espionagem cibernética, também foram registradas campanhas voltadas ao roubo de dinheiro de vítimas, indicando uma sobreposição entre objetivos de inteligência e ganho financeiro. Em fevereiro de 2026, o Eagle Werewolf foi observado comprometendo um canal do Telegram focado em drones para distribuir o AquilaRAT por meio de um dropper escrito em Rust. O arquivo malicioso se passava por uma lista de verificação para ativação de dispositivos Starlink. Nesses ataques, o Go2Tunnel também foi usado para estabelecer um túnel SSH reverso com um servidor de comando e controle, utilizando uma chave privada. As descobertas mais recentes mostram que o agente também passou a usar um novo infostealer baseado em Python, chamado BusySnake Stealer, voltado a sistemas Windows. Uma das versões analisadas inclui um módulo específico para roubo de cookies de navegadores. As origens exatas do Armored Likho ainda são desconhecidas. A cadeia de ataque começa com e-mails de spear phishing que usam iscas relacionadas a comunicados oficiais do governo ou programas sociais. As mensagens distribuem um arquivo RAR contendo binários EXE, que funcionam como droppers para baixar cargas adicionais a partir de um repositório no GitHub, incluindo o próprio BusySnake Stealer. Após a execução inicial, o dropper cria dois arquivos Visual Basic Script, ou VBScript. Esses scripts são usados para apagar rastros da primeira execução e iniciar o stealer por meio de uma tarefa agendada no Windows. Esse mecanismo ajuda o malware a manter persistência no sistema, permitindo que ele volte a ser executado mesmo após reinicializações. A Kaspersky também observou cadeias alternativas que usam atalhos do Windows, no formato LNK, em vez de executáveis EXE. Nesses casos, os invasores exploram uma vulnerabilidade já corrigida relacionada à forma como o Windows processa esses arquivos. A falha, rastreada como CVE-2025-9491 e também conhecida como ZDI-CAN-25373, foi corrigida pela Microsoft no Patch Tuesday de novembro de 2025. Evidências divulgadas anteriormente pela Trend Micro indicaram que essa vulnerabilidade vinha sendo explorada por uma dúzia de grupos hackers desde 2017. Na cadeia documentada pela Kaspersky, a falha em arquivos de atalho é usada para acionar um comando PowerShell ofuscado. Esse comando inicia um loader responsável por exibir um documento-isca à vítima, ao mesmo tempo em que prepara o ambiente para execução do stealer em Python. Depois disso, o malware estabelece persistência com a mesma combinação de arquivo VBScript e tarefa agendada. O uso de documentos-isca ajuda a reduzir a suspeita do usuário, enquanto a execução real ocorre em segundo plano. O BusySnake implementa diversas técnicas de evasão para dificultar análise estática e contornar mecanismos de detecção. Seu objetivo principal é estabelecer comunicação com o servidor de comando e controle e aguardar instruções. A partir desse canal, os operadores podem acionar diferentes funções conforme o interesse na máquina comprometida. Entre as capacidades do BusySnake estão o roubo de dados da área de transferência, enumeração de arquivos do sistema, registro de metadados em um banco de dados local, envio de documentos do usuário ao servidor de comando e controle, captura de screenshots e preparação dessas imagens em um diretório local. O malware também consegue compactar capturas de tela, remover arquivos previamente criados no disco, impedir que múltiplas instâncias sejam executadas ao mesmo tempo e verificar se sua tarefa agendada ainda existe. Os comandos enviados pelo servidor de comando e controle ampliam o alcance da ameaça. O BusySnake pode capturar telas em intervalos definidos, registrar teclas digitadas, coletar arquivos de carteiras de criptomoedas com extensão JSON, roubar sessões e credenciais do Telegram, criar túneis SSH reversos usando Go2Tunnel, instalar o RustDesk e extrair cookies e senhas de navegadores Mozilla Firefox e baseados em Chromium. O abuso do RustDesk chama atenção porque a ferramenta é legítima e de código aberto, usada para acesso remoto. Quando o RustDesk já está instalado na máquina, o malware o inicia e induz a vítima a inserir suas credenciais. Em seguida, o BusySnake captura uma imagem da tela com essas credenciais e envia o conteúdo ao servidor de comando e controle. Segundo a Kaspersky, o malware descriptografa dinamicamente seu bytecode apenas no momento exato em que uma função é chamada, criptografando os dados novamente logo depois. Além disso, ele roda em segundo plano sem abrir uma janela de console, comportamento indicado pelo uso da extensão PYW em arquivos Python. A empresa também identificou uma versão mais recente do BusySnake que evolui a arquitetura anterior. Essa variante inclui um novo framework de gerenciamento de tarefas para processar comandos vindos do servidor de comando e controle e atribuir estados operacionais às ações, como SCHEDULED, IN_PROGRESS, SUCCEEDED ou FAILED. Esse mecanismo melhora o acompanhamento da execução das tarefas pelos operadores. As possíveis ligações com o Eagle Werewolf aparecem em semelhanças entre o AquilaRAT e o BusySnake Stealer. As duas famílias de malware apresentam paralelos na forma como recebem tarefas do servidor de comando e controle, registram persistência por tarefas agendadas e usam endpoints semelhantes para comunicação com a infraestrutura dos invasores. A Kaspersky também identificou indícios de que cargas iniciais, como loaders e stagers, podem ter sido geradas com auxílio de ferramentas de inteligência artificial. Essa avaliação se baseia na presença de comentários redundantes e blocos de código aparentemente desnecessários, características que podem aparecer em código produzido ou assistido por IA. Para a Kaspersky, a campanha reúne tendências importantes no cenário de ameaças: amadurecimento técnico do Armored Likho, polimorfismo de ferramentas e adoção de esquemas mais complexos para burlar soluções de segurança. A evolução vai desde a ofuscação de código-fonte em Python até a incorporação de mecanismos de rede diretamente no malware. Outro ponto relevante é a integração de funcionalidades antes usadas como ferramentas separadas. O Go2Tunnel, que anteriormente operava como utilitário independente, teve sua função de tunelamento reverso incorporada diretamente ao stealer. Agora, o BusySnake pode receber parâmetros do servidor de comando e controle e criar o túnel como recurso nativo, reduzindo dependências externas e tornando a operação mais integrada. O uso combinado de spear phishing, exploração de vulnerabilidades em atalhos do Windows, malware modular, roubo de credenciais, acesso remoto e tunelamento SSH coloca o Armored Likho em uma posição de risco relevante para ambientes governamentais e infraestruturas críticas. Para organizações do setor elétrico, esse tipo de ameaça pode impactar não apenas dados sensíveis, mas também continuidade operacional, acesso administrativo e visibilidade sobre ativos comprometidos.