Repositórios da Microsoft no GitHub foram afetados por uma nova etapa da campanha Miasma, um ataque autorreplicante contra a cadeia de suprimentos de software que vem se espalhando por projetos open source e ambientes de desenvolvimento. Segundo a OpenSourceMalware, o incidente impactou 73 repositórios da Microsoft distribuídos em quatro organizações no GitHub: Azure, Azure-Samples, Microsoft e MicrosoftDocs. Após a identificação da atividade, o GitHub desabilitou o acesso aos repositórios afetados. Ao tentar acessar o repositório “Azure/azure-functions-host”, por exemplo, a plataforma passou a exibir uma mensagem informando que o acesso havia sido bloqueado pela equipe do GitHub por violação dos termos de serviço. Entre os repositórios impactados, a OpenSourceMalware citou projetos como azure-search-openai-demo-purviewdatasecurity, Connectors-NET-LSP, Connectors-NET-SDK, durabletask, durabletask-dotnet, durabletask-go, durabletask-js, durabletask-mssql, functions-container-action, homebrew-functions, llm-fine-tuning e windows-driver-docs. Um dos pontos mais relevantes do caso é a nova exposição do pacote “durabletask” no PyPI, que já havia sido comprometido no mês anterior pelo grupo TeamPCP para entregar um malware de roubo de informações em sistemas Linux. Para o pesquisador Paul McCarty, conhecido como 6mile, o fato de o repositório ligado ao comprometimento anterior aparecer novamente no centro da nova onda de remoções indica uma continuidade preocupante. Segundo McCarty, não apenas o repositório Azure/durabletask deixou de estar acessível, mas também diversos projetos relacionados ao ecossistema Durable Task, incluindo implementações em .NET, Go, Java, JavaScript, MSSQL, Netherite e protobuf, além do monitor do Durable Functions. Para ele, quando o repositório na origem do comprometimento anterior se torna o ponto central da nova derrubada, isso sugere que a falha inicial pode não ter sido totalmente contida. A campanha Miasma é avaliada como uma variante do worm Mini Shai-Hulud, divulgado publicamente pelo TeamPCP em meados de maio de 2026. Desde então, o malware continuou evoluindo, refinando suas táticas e infectando novos pacotes ao longo dos últimos dias. Parte da operação envolve a criação de repositórios públicos que armazenam segredos roubados, usando descrições como “Miasma: The Spreading Blight”, “Miasma : The Spreading Blight”, “Miasma - The Spreading Blight” e “Hades - The End for the Damned”. No momento descrito pelo relatório, havia 13 repositórios com a descrição “Hades - The End for the Damned” e 82 repositórios usando os três padrões restantes relacionados ao nome Miasma. Esse comportamento reforça a natureza autorreplicante da campanha, na qual credenciais, chaves e segredos expostos podem ser reutilizados para comprometer novos projetos e ampliar a propagação. A atividade também foi observada fora do fluxo tradicional de envenenamento de pacotes em registries como o npm. Em vez de publicar pacotes maliciosos no registro, os invasores inseriram código diretamente no repositório “icflorescu/mantine-datatable” e em quatro projetos relacionados: “mantine-contextmenu”, “next-server-actions-parallel”, “mantine-datatable-v6” e “mantine-contextmenu-v6”. De acordo com a SafeDep, o commit malicioso não adicionou novas dependências. Em vez disso, implantou um executor de payload de 4,3 MB e o configurou para execução automática por meio de cinco ferramentas usadas por desenvolvedores: Claude Code, Gemini CLI, Cursor, VS Code e o script de teste do npm. Na prática, o ataque é acionado quando um desenvolvedor clona um dos repositórios afetados e o abre em um agente de codificação com inteligência artificial. A SafeDep afirmou que o dropper usado nessa etapa é o mesmo loader Bun em estágios, agora adaptado para persistência diretamente em repositórios de código-fonte no GitHub, em vez de envenenamento de registries de pacotes. Essa mudança amplia a superfície de ataque, pois explora o fluxo de trabalho cotidiano de desenvolvedores que utilizam IDEs, agentes de IA e automações locais para revisar, testar ou modificar código. O caso evidencia fragilidades estruturais no modelo de confiança que sustenta a entrega de software em ecossistemas open source. Em vez de explorar uma vulnerabilidade específica no GitHub ou no npm, a campanha abusa de credenciais válidas, mantenedores autenticados e processos legítimos de publicação ou alteração de código. Isso dificulta a detecção, já que a atividade maliciosa pode parecer, do ponto de vista das plataformas, uma atualização regular feita por um usuário autorizado. A FalconFeeds.io observou que a força do worm está justamente em operar por canais legítimos. Segundo a análise, ele não explora uma falha técnica no npm ou no GitHub, mas sim o modelo de confiança dessas plataformas, baseado na premissa de que um pacote assinado por uma chave válida e publicado por um mantenedor autenticado é seguro. No caso do Shai-Hulud e de suas variantes, como o Miasma, o ataque compromete a chave e o mantenedor para agir como um publicador legítimo. Assim, cada publicação maliciosa pode se confundir com uma atualização de rotina, tornando defesas convencionais menos eficazes contra uma campanha que se propaga por meio da própria infraestrutura confiável do ecossistema de desenvolvimento. A recorrência envolvendo o ecossistema Durable Task também chama atenção para a dificuldade de erradicar totalmente incidentes de cadeia de suprimentos quando credenciais, tokens, chaves de publicação ou acessos de mantenedores permanecem válidos após o primeiro comprometimento. Em ataques desse tipo, a contenção exige mais do que remover pacotes maliciosos: é necessário revisar credenciais, rotacionar segredos, auditar permissões, verificar histórico de commits e avaliar possíveis comprometimentos em projetos downstream. Com a adoção crescente de agentes de IA no desenvolvimento de software, a campanha também aponta para um vetor emergente: o abuso de ferramentas que executam, analisam ou interagem com código automaticamente. Quando um repositório malicioso é aberto em um ambiente integrado a assistentes de codificação, scripts e extensões podem se tornar parte da cadeia de execução, reduzindo a distância entre o simples ato de clonar um projeto e a ativação de um payload.

A OpenAI começou a liberar um novo recurso de segurança chamado Lockdown Mode para o ChatGPT, com o objetivo de reduzir o risco de exfiltração de dados causada por ataques de prompt injection. A funcionalidade é opcional e foi criada para usuários e organizações que lidam com informações sensíveis e precisam de garantias mais rígidas de proteção ao usar recursos conectados à web ou a serviços externos. O Lockdown Mode está disponível para usuários logados em contas pessoais Free, Go, Plus e Pro, além de planos self-service do ChatGPT Business. Segundo a OpenAI, o recurso funciona como uma configuração avançada de segurança que limita várias ferramentas e capacidades dos produtos da empresa capazes de se conectar à internet ou interagir com serviços externos. A proposta do novo modo não é impedir que ataques de prompt injection aconteçam. Esse tipo de ataque ocorre quando uma instrução maliciosa é inserida em um conteúdo processado pelo modelo, como uma página da web, documento ou outro material analisado pela IA, com o objetivo de alterar seu comportamento. Em vez disso, o Lockdown Mode busca bloquear caminhos que poderiam ser usados para enviar dados sensíveis para infraestrutura controlada por invasores. Na prática, a proteção atua principalmente sobre solicitações de rede de saída. Em um cenário de prompt injection, um conteúdo malicioso poderia tentar induzir o modelo a acessar uma URL, carregar uma imagem remota, acionar uma ferramenta conectada ou transmitir informações por algum canal externo. Ao limitar essas capacidades, o Lockdown Mode reduz a superfície disponível para exfiltração de dados. A OpenAI afirma que o recurso se apoia em mecanismos de sandboxing e controles já existentes para combater técnicas de exfiltração baseadas em URLs. A ideia é restringir requisições externas que poderiam transportar dados confidenciais para servidores de terceiros. Esse tipo de controle é especialmente relevante em fluxos nos quais o usuário trabalha com documentos internos, informações corporativas, credenciais, dados regulados ou conteúdos sensíveis. Quando ativado, o Lockdown Mode desabilita ou limita recursos importantes do ChatGPT. A navegação web ao vivo passa a ser restrita ao acesso a conteúdo em cache. O suporte a imagens em respostas comuns ou obtidas da web também é limitado. Recursos como Deep Research, Agent Mode, rede no Canvas e download de arquivos para análise de dados são desativados ou bloqueados. No caso do Canvas, a restrição impede que usuários aprovem códigos gerados nesse ambiente para acessar a rede. Já nos downloads de arquivos, o modo bloqueia a obtenção de arquivos usados em análise de dados. Essas limitações podem reduzir conveniência e produtividade em alguns fluxos de trabalho, mas foram projetadas para diminuir o risco de que dados sejam enviados para fora da conversa por meio de funcionalidades conectadas. A empresa destaca que o Lockdown Mode não altera o funcionamento da memória, dos uploads de arquivos nem da opção de compartilhar conversas. Isso significa que a configuração é focada nos canais de saída e nas capacidades conectadas, e não em todas as formas de interação com o ChatGPT. Por esse motivo, a OpenAI também alerta que o recurso não deve ser interpretado como uma proteção absoluta contra todos os efeitos de prompt injection. Um arquivo malicioso enviado pelo usuário, por exemplo, ainda poderia conter instruções ocultas capazes de influenciar o comportamento do ChatGPT e levar a uma resposta incorreta. Nessa situação, o Lockdown Mode pode reduzir a chance de vazamento por canais externos, mas não elimina a possibilidade de manipulação da resposta do modelo. Essa distinção é importante para empresas que pretendem usar a funcionalidade como parte de uma estratégia de governança de IA. A OpenAI também informou que o Lockdown Mode e o Developer Mode não podem ser utilizados ao mesmo tempo. Ao ativar um deles, o outro é desabilitado. Essa separação reflete objetivos distintos: enquanto o Developer Mode tende a ampliar capacidades de personalização e desenvolvimento, o Lockdown Mode reduz funcionalidades para priorizar segurança. O recurso não é destinado a todos os usuários. A própria OpenAI afirma que ele foi pensado para pessoas e organizações que exigem um nível mais elevado de proteção, mesmo que isso signifique abrir mão de recursos úteis. Em ambientes corporativos, a funcionalidade tende a ser mais relevante para executivos, equipes jurídicas, áreas de segurança, profissionais que lidam com propriedade intelectual, times de pesquisa, organizações reguladas e empresas que processam dados confidenciais no ChatGPT. O lançamento ocorre em um momento em que ataques de prompt injection continuam sendo um desafio relevante para grandes modelos de linguagem. Como LLMs podem processar conteúdos não confiáveis, como páginas web, documentos recebidos de terceiros ou dados extraídos de sistemas conectados, há risco de que instruções maliciosas sejam interpretadas pelo modelo durante uma tarefa legítima. Quando essas instruções conseguem acionar ferramentas externas, o impacto pode incluir vazamento de dados, execução indevida de ações ou respostas manipuladas. Apesar das proteções, a OpenAI ressalta que o Lockdown Mode não garante que a exfiltração de dados seja impossível. Riscos ainda podem permanecer por meio de aplicativos habilitados, combinações imprevistas de capacidades ou novas técnicas descobertas por invasores. Isso reforça que o recurso deve ser tratado como uma camada adicional de defesa, e não como substituto para políticas internas de segurança, classificação de dados, revisão de permissões e controles de uso de IA. Além do Lockdown Mode, a OpenAI também lançou um novo recurso de gerenciamento de contas que permite aos usuários revisar sessões ativas do ChatGPT e encerrar sessões individuais ou todas as sessões em caso de suspeita de atividade não autorizada. A lista de sessões inclui informações como dispositivo, aplicativo utilizado, localização aproximada, data e horário de login, se o dispositivo é confiável e se a sessão atual está em uso. Esse controle de sessões complementa a estratégia de segurança ao dar mais visibilidade sobre acessos à conta. Em organizações, esse tipo de recurso pode ajudar investigações internas, resposta a incidentes e ações rápidas quando há suspeita de comprometimento de credenciais. Para usuários individuais, a funcionalidade também facilita identificar acessos incomuns e encerrar conexões que não deveriam permanecer ativas. O novo Lockdown Mode representa uma tentativa de endurecer o uso de IA generativa em contextos de maior sensibilidade. Ao limitar recursos conectados à rede, a OpenAI busca reduzir uma das principais rotas de exploração associadas a prompt injection: a capacidade de transformar uma instrução maliciosa escondida em um conteúdo aparentemente legítimo em um canal para envio de dados para fora do ambiente controlado. Para empresas que já usam ChatGPT em processos internos, o recurso pode ser útil em fluxos que envolvem análise de documentos confidenciais, revisão de contratos, investigação de incidentes, tratamento de dados corporativos ou apoio a decisões estratégicas. Ainda assim, sua adoção deve vir acompanhada de orientação aos usuários, revisão de permissões, boas práticas de classificação da informação e monitoramento contínuo dos riscos associados ao uso de IA.

O ecossistema npm voltou a ser alvo de ataques contra a cadeia de suprimentos de software, desta vez envolvendo tanto pacotes maliciosos quanto versões adulteradas de pacotes legítimos. Segundo análises da JFrog, Endor Labs, StepSecurity, Microsoft, Red Hat e OX Security, os invasores comprometeram dezenas de pacotes para distribuir um ladrão de informações escrito em Rust e uma nova variante de worm capaz de se espalhar automaticamente entre projetos, repositórios e ambientes de desenvolvimento. A primeira campanha foi associada a um malware chamado IronWorm, identificado pela JFrog. De acordo com a empresa, o malware foi projetado para coletar segredos armazenados nas máquinas dos desenvolvedores, ocultar sua atividade por meio de um rootkit de kernel baseado em eBPF e se comunicar com seus operadores pela rede Tor. A combinação de roubo de credenciais, ocultação em nível de sistema e propagação por pacotes npm torna a ameaça especialmente perigosa para ambientes de desenvolvimento e integração contínua. O IronWorm foi distribuído por meio de versões trojanizadas de pacotes publicados no registro npm. A atividade foi rastreada até uma conta npm comprometida chamada “asteroiddao”, usada para publicar versões de pacotes contendo um binário ELF em Rust. Esse binário era executado por meio de um hook de preinstall, mecanismo que permite rodar código automaticamente durante a instalação de um pacote. A cadeia de ataque segue um padrão típico de comprometimento de supply chain. Primeiro, os invasores obtêm acesso a uma conta legítima ou confiável dentro do ecossistema de desenvolvimento. Em seguida, publicam uma versão adulterada de um pacote npm. Quando outro desenvolvedor instala o pacote, o hook de instalação executa o binário malicioso. A partir daí, o malware coleta credenciais, modifica projetos, injeta código malicioso em repositórios acessíveis e tenta se propagar para novos pacotes e organizações no GitHub. A JFrog afirmou que o IronWorm tem semelhanças com o worm Shai-Hulud, justamente pelo uso de credenciais roubadas como mecanismo de propagação. Na prática, isso significa que a ameaça não se limita a infectar uma única estação de trabalho. Ao capturar tokens e chaves de acesso, o malware pode alcançar repositórios, pipelines, pacotes e ambientes de publicação, ampliando o impacto para outros desenvolvedores e organizações que dependem desses componentes. O malware mira 86 variáveis de ambiente e diversos arquivos que podem conter credenciais relacionadas a OpenAI Codex, Anthropic, Claude, Google Gemini, Cursor, Amazon Web Services, Docker, Kubernetes, npm, configurações de vault e arquivos da carteira de criptomoedas Exodus. Esse conjunto de alvos mostra que os invasores buscam não apenas credenciais tradicionais de infraestrutura e cloud, mas também configurações associadas a assistentes de programação baseados em inteligência artificial. Um detalhe incomum observado pela JFrog é que o componente de roubo de carteira possui uma lógica para ignorar a própria carteira do invasor. Até o momento da análise, essa carteira estava vazia e não apresentava transações registradas. A empresa descreveu o IronWorm como uma arma de cadeia de suprimentos criada para encontrar segredos, modificar projetos e injetar código malicioso com o objetivo de se autopropagar pelo GitHub. Os commits maliciosos foram identificados em nove organizações do GitHub e apareceram com o autor “claude”, usando o endereço “claude@users.noreply.github.com”, em uma tentativa de se passar pelo chatbot de inteligência artificial da Anthropic. Segundo a JFrog, a conta npm “asteroiddao” está ligada à organização GitHub “asteroid-dao”. Um usuário identificado como “ocrybit” era membro dessa organização e também de organizações relacionadas ao Arweave. A análise indica que o malware roubou as credenciais desse usuário e as utilizou para enviar commits maliciosos em repositórios aos quais ele tinha acesso. Esses commits inseriam malware em outros pacotes, que poderiam ser publicados posteriormente e infectar novos desenvolvedores. Além disso, o payload tinha capacidade de substituir workflows existentes do GitHub Actions por um novo fluxo capaz de coletar segredos, gravá-los em um arquivo aparentemente inofensivo e enviá-los como artefato de build. Essa técnica reduz a necessidade de um servidor externo de comando e controle, já que o próprio ambiente de CI/CD passa a ser usado como meio de exfiltração. Em ambientes de integração contínua, o IronWorm também abusa do fluxo de Trusted Publishing do npm para obter tokens de curta duração e publicar versões contaminadas no registro. Esse ponto é relevante porque explora mecanismos legítimos criados para dar mais segurança e rastreabilidade à publicação de pacotes, transformando-os em parte da cadeia de propagação. Outro componente técnico importante é o uso de eBPF como rootkit em nível de kernel. O eBPF é uma tecnologia legítima do Linux usada para observabilidade, rede e segurança, mas pode ser abusada por malware para ocultar processos, conexões e atividades. No caso do IronWorm, o payload tenta esconder processos e dificultar a análise. No entanto, em sistemas com kernel lockdown habilitado, as técnicas de ocultação falham e os processos e sockets passam a ficar visíveis novamente. Paralelamente ao IronWorm, pesquisadores da Endor Labs e da StepSecurity revelaram uma campanha distinta envolvendo uma nova variante do worm Miasma. A campanha comprometeu 57 pacotes npm em mais de 286 versões maliciosas. Essa nova onda ocorre depois de uma atividade anterior do Miasma que infectou 32 pacotes em mais de 90 versões sob o namespace @redhat-cloud-services em apenas 72 segundos. Entre os pacotes afetados citados estão ai-sdk-ollama, autotel, awaitly, effect-analyzer, eslint-plugin-awaitly, executable-stories-cypress, http-uploader-dev, mountly, node-env-resolver e node-env-resolver-aws. Os dados roubados pelo malware eram exfiltrados para uma conta do GitHub chamada “liuende501”, atualmente inacessível. Segundo as informações divulgadas, até 236 repositórios foram preparados nessa conta. Ainda não está claro se a conta foi removida pelo GitHub ou apagada pelo próprio invasor. A StepSecurity destacou uma técnica chamada “Phantom Gyp”. Em vez de usar scripts tradicionais de ciclo de vida, como preinstall ou postinstall, que normalmente são monitorados por ferramentas de segurança, o invasor abusa de um arquivo binding.gyp de apenas 157 bytes para acionar a execução de código durante o npm install. Com isso, a campanha consegue contornar grande parte das verificações focadas em scripts de instalação. A cadeia do Miasma foi projetada para baixar e instalar o runtime JavaScript Bun, usado para carregar um coletor abrangente de credenciais. O malware busca segredos relacionados a AWS, Google Cloud, Microsoft Azure, HashiCorp Vault, Docker, Kubernetes, GitHub Actions, npm, RubyGems, PyPI, SSH, gerenciadores de senha e assistentes de IA. Um dos aspectos mais preocupantes dessa variante é o foco em configurações de assistentes de programação com IA. Segundo os pesquisadores, o malware injeta arquivos persistentes de backdoor em repositórios de projetos, que são executados sempre que um desenvolvedor abre o projeto em uma IDE assistida por IA. Esse comportamento mostra uma mudança importante no cenário de ameaças: ferramentas de desenvolvimento baseadas em inteligência artificial estão se tornando parte da superfície de ataque. A Red Hat informou que a causa provável do incidente envolvendo Miasma foi o comprometimento de uma conta do GitHub usada para enviar commits não autorizados a repositórios da organização RedHatInsights. A Microsoft acrescentou que o payload operava em Linux, macOS e Windows, baixando dinamicamente a versão correta do Bun para cada plataforma, embora runners Linux de CI/CD pareçam ter sido o alvo principal. De acordo com a Microsoft, em máquinas de desenvolvedores o malware roubava chaves SSH, credenciais de linha de comando, dados de navegadores e carteiras. Em ambientes de CI/CD, o Miasma extraía segredos da memória de runners do GitHub Actions, escalava privilégios usando sudo sem senha e republicava pacotes adulterados com proveniência SLSA falsificada para continuar a propagação downstream. A nova variante do Miasma é avaliada como derivada do worm Shai-Hulud, usado por TeamPCP em campanhas recentes. Embora tenha mudanças consideradas em grande parte cosméticas, a funcionalidade central permanece semelhante. Ainda assim, a atribuição dos ataques mais recentes continua incerta, já que o código do Shai-Hulud foi publicado publicamente pelo próprio TeamPCP. A OX Security identificou estágios adicionais na cadeia de ataque do Miasma. Entre eles está a busca por commits no GitHub contendo a string “firedalazer”, usada para recuperar outro payload. Esse mecanismo substitui a string “FIRESCALE”, anteriormente sinalizada como dead drop. O novo payload é um arquivo JavaScript chamado “index.js”, que contém uma versão alternativa do worm Shai-Hulud e transforma a infecção em um ciclo contínuo. Nesse caso, os dados roubados são exfiltrados para repositórios públicos do GitHub com descrições como “Miasma : The Spreading Blight” ou “Miasma - The Spreading Blight”. A diferença sutil na formatação da descrição, incluindo o espaço entre “Miasma” e os dois-pontos, foi citada como um detalhe relevante. Atualmente, existem 82 repositórios desse tipo criados nas contas “0tabek16” e “windy629”. Pesquisadores da OX Security alertaram que o invasor pode alterar dinamicamente os commits “firedalazer” no GitHub, criando novas versões do malware de forma mais adaptável. Com isso, o GitHub deixa de funcionar apenas como um ponto morto de entrega de payload e passa a atuar como um comando e controle adaptativo, aproveitando uma plataforma confiável e amplamente permitida em ambientes corporativos. Essa abordagem dificulta a detecção em nível de rede, já que muitas ferramentas de segurança não tratam o tráfego para o GitHub como suspeito. As recomendações para desenvolvedores que instalaram versões afetadas incluem rotação imediata de credenciais, desativação de scripts de instalação e rebuilds nativos por padrão, além da fixação de pacotes com hashes de integridade. Para empresas, o incidente reforça a necessidade de monitorar contas de publicação, revisar permissões em organizações GitHub, aplicar controles em pipelines de CI/CD, proteger tokens de curta duração e tratar ferramentas de IA e IDEs assistidas como parte da superfície de risco. Os ataques envolvendo IronWorm e Miasma demonstram como o ecossistema de desenvolvimento se tornou um alvo estratégico para grupos de cibercrime e operadores de campanhas avançadas. Ao comprometer pacotes usados por desenvolvedores, os invasores conseguem transformar dependências legítimas em veículos de espionagem, roubo de credenciais e propagação automática. O impacto pode alcançar ambientes cloud, repositórios privados, pipelines de build, registros de pacotes e organizações inteiras que dependem de componentes open source.

Usuários de língua árabe estão sendo alvo de um novo spyware para Android identificado como Asin, segundo descobertas da ESET. A empresa eslovaca de cibersegurança informou que detectou o malware pela primeira vez no início de 2025, distribuído por meio de múltiplas campanhas que utilizavam sites falsos para simular ferramentas úteis, atualizações sobre conflitos armados e fontes de notícias governamentais. De acordo com a análise, cada onda de ataque usou uma abordagem diferente para atrair vítimas. Entre os domínios identificados estão govlens[.]net, registrado em 27 de maio de 2025, que se passava por uma fonte de notícias governamental; pdf-reader[.]help, registrado em 29 de maio de 2025, que imitava um editor seguro de PDF; e live-war-map[.]com, registrado em 20 de janeiro de 2025, que prometia atualizações sobre incidentes militares. Dois desses sites, govlens[.]net e live-war-map[.]com, também foram promovidos por contas dedicadas em redes sociais, incluindo Facebook e Telegram. Entre os perfis citados estão www.facebook[.]com/GovLens e o canal t[.]me/liveuamap_ar. Segundo a ESET, cada um desses sites distribuía um aplicativo malicioso que combinava funcionalidades aparentemente legítimas com recursos de spyware executados de forma discreta. A escolha dos temas usados como isca chama atenção. O canal no Telegram, por exemplo, parece ter sido inspirado no nome do Live Universal Awareness Map, conhecido como Liveuamap, uma plataforma legítima usada para mapear conflitos em andamento, violações de direitos humanos, desastres naturais e eventos geopolíticos ao redor do mundo. Essa semelhança pode ter sido usada para aumentar a credibilidade da campanha entre pessoas interessadas em acompanhar guerras, crises regionais e informações de fonte aberta. A investigação também identificou múltiplos artefatos associados ao Asin. Um deles foi enviado ao VirusTotal a partir da Turquia em outubro de 2025. Outro APK foi baixado em dezembro de 2025 a partir do domínio c-pdf[.]net por um usuário utilizando um Xiaomi Redmi Note 13 Pro com Android 15. Um terceiro exemplo foi detectado por volta de meados de janeiro de 2026 em dispositivos Xiaomi Redmi Note 13 Pro+ 5G com Android 15, disfarçado como “Syria Defense Map”. Neste último caso, o aplicativo teria sido baixado a partir do site syriadefensemap[.]com. A ESET observou que a infecção exige interação do usuário: a vítima precisa instalar manualmente o APK e conceder as permissões necessárias para que o spyware consiga atingir seus objetivos. Esse ponto é relevante porque demonstra uma cadeia de ataque baseada em engenharia social e instalação fora das lojas oficiais, em vez de exploração automática de uma vulnerabilidade do sistema Android. A cadeia de ataque descrita pelos pesquisadores segue um padrão comum em campanhas de espionagem móvel. Primeiro, os operadores criam sites falsos com aparência funcional e temática alinhada ao interesse do público-alvo. Em seguida, divulgam esses sites por canais sociais ou por links diretos. A vítima baixa o APK acreditando se tratar de uma ferramenta legítima, instala o aplicativo manualmente e concede permissões solicitadas durante o uso. A partir desse ponto, o app passa a combinar funções legítimas com capacidades ocultas de spyware. Embora o relatório não detalhe todas as permissões exploradas pelo Asin nem os tipos específicos de dados coletados, o uso do termo spyware indica uma finalidade voltada à vigilância, coleta de informações ou monitoramento do dispositivo infectado. Em campanhas desse tipo, os riscos costumam envolver exposição de comunicações, metadados, arquivos, localização ou outras informações sensíveis, dependendo das permissões concedidas e das capacidades implementadas no malware. A atividade permanece sem atribuição. Até o momento, a ESET não associou o Asin a um país, grupo hacker ou operação conhecida. Também não está claro qual é o objetivo principal das campanhas. Ainda assim, os temas usados como isca sugerem um possível interesse em jornalistas, pesquisadores de inteligência de fontes abertas, conhecidos como OSINT, e usuários de regiões árabes que acompanham conflitos militares e acontecimentos geopolíticos. A própria ESET destacou que três dos cinco aplicativos fraudulentos encontrados — GovLens, WarMap e Syria Defense Map — parecem ter sido criados principalmente para pessoas interessadas em investigação de fontes abertas. Por isso, a empresa avalia que parte da atividade pode ter sido direcionada a jornalistas de língua árabe ou profissionais e pesquisadores que trabalham com OSINT. O caso também se conecta a uma tendência mais ampla de uso de aplicativos falsos para operações de espionagem móvel. Em vez de depender apenas de vulnerabilidades técnicas, os invasores exploram temas sensíveis, urgentes ou politicamente relevantes para convencer usuários a instalar apps fora de canais confiáveis. Em regiões afetadas por conflitos, plataformas de mapas, alertas de guerra e fontes de notícias podem se tornar iscas particularmente eficazes, especialmente quando o público busca informações rápidas e atualizadas. Para usuários Android, o principal risco está na instalação de APKs obtidos fora de lojas oficiais ou de fontes verificadas. Mesmo quando um aplicativo parece oferecer uma função útil, como leitura de PDF, notícias governamentais ou monitoramento de conflitos, a concessão de permissões excessivas pode abrir caminho para espionagem. Organizações de mídia, pesquisadores independentes, analistas de OSINT e defensores de direitos humanos devem redobrar a atenção com aplicativos distribuídos por links em redes sociais, grupos de mensagens e sites recém-criados.

A OpenAI passou a oferecer novos controles de sessão no ChatGPT, ampliando a visibilidade de usuários e administradores sobre acessos ativos à plataforma. A novidade, chamada Active sessions, permite revisar sessões abertas, identificar dispositivos conectados e encerrar acessos específicos ou todos os acessos ativos. Embora o recurso represente um avanço em segurança operacional, especialistas avaliam que ele não resolve o problema maior enfrentado pelas empresas: a governança contínua de modelos de IA que mudam rapidamente. A governança de inteligência artificial tem se tornado um processo permanente de adaptação para organizações. Modelos, recursos e comportamentos são atualizados em ciclos cada vez mais curtos, muitas vezes antes que frameworks internos de risco, compliance e segurança tenham sido plenamente testados. Nesse contexto, a visibilidade sobre sessões é importante, mas representa apenas uma parte de uma discussão mais ampla sobre controle, auditoria e mudança de comportamento em sistemas de IA. O recurso Active sessions está disponível para contas do ChatGPT e diferentes tipos de workspace, incluindo contas pessoais e ambientes gerenciados. Segundo a documentação da OpenAI, a funcionalidade permite acessar “Settings”, depois “Security” e “Active sessions”, para revisar sessões conhecidas e encerrar sessões individuais ou todas as sessões ativas. A própria OpenAI informa que o encerramento de todas as sessões pode levar até 30 minutos para ser concluído. Para Ensar Seker, CISO da SOCRadar, o recurso melhora um ponto que historicamente limitava a governança em ambientes corporativos: a falta de visibilidade granular sobre onde usuários estavam logados. Antes, muitas organizações dependiam de redefinições de senha ou ações amplas de conta para forçar nova autenticação. Com o controle por sessão, torna-se possível agir de forma mais precisa e menos disruptiva. Do ponto de vista de governança, a transparência sobre sessões melhora a responsabilização e apoia investigações internas. Administradores e usuários podem identificar acessos não reconhecidos, encerrar sessões antigas e reduzir o risco de uma conta comprometida permanecer ativa sem detecção. Uma visão mais clara das sessões ativas O Active sessions permite visualizar sessões conhecidas de navegador e aplicativo associadas ao ChatGPT, Codex e API Platform. Entre os dados exibidos estão informações de dispositivo e navegador, localização aproximada, data e horário de login, indicação de dispositivo confiável e identificação da sessão atual. A funcionalidade permite encerrar sessões específicas e remover dispositivos da lista de serviços confiáveis. Também há a opção de sair de todas as sessões, encerrando acessos em diferentes dispositivos. Essa ação, no entanto, pode não ser imediata em todos os casos, já que a OpenAI informa que o processo pode levar até 30 minutos. Apesar do avanço, a própria OpenAI destaca limitações. Os detalhes de sessão podem ser aproximados ou incompletos, e o recurso não gerencia todos os tipos de acesso. A funcionalidade não cobre aplicativos conectados ou sessões de terceiros, logins realizados por serviços externos, sessões do Codex CLI ou sessões encerradas recentemente. Além disso, o Active sessions não está disponível para contas vinculadas ao SSO de uma organização, incluindo autenticação via SAML ou OIDC. Melhor tarde do que nunca Especialistas consideram o Active sessions um desenvolvimento positivo, mas também observam que esse tipo de controle é básico e já esperado em plataformas SaaS há anos. David Shipley, da Beauceron Security, afirmou que a capacidade de administradores encerrarem sessões ativas no ChatGPT é algo presente em muitas plataformas e que a OpenAI deveria ter oferecido esse recurso antes. Para Shipley, a chegada da funcionalidade é bem-vinda, mas não elimina outras preocupações de segurança associadas ao uso corporativo de IA. Ele também avalia que a OpenAI poderia avançar em mecanismos para impedir o uso indevido do ChatGPT por agentes de ameaça, inclusive em cenários envolvendo hospedagem ou apoio a campanhas maliciosas. Seker, da SOCRadar, segue linha semelhante ao afirmar que visibilidade e controle de sessão são recursos há muito esperados por empresas em plataformas SaaS. Na prática, esse tipo de mecanismo ajuda administradores e usuários a detectar acessos indevidos, encerrar sessões obsoletas e reduzir a persistência de comprometimentos de conta. Atualizações constantes ampliam o desafio de governança O ponto central, porém, está além do controle de sessão. Mesmo com ferramentas como Active sessions, empresas continuam enfrentando dificuldades para governar modelos de IA que mudam de forma contínua. Atualizações iterativas podem alterar estilo de resposta, qualidade, comportamento e desempenho prático dos modelos, impactando fluxos de trabalho previamente avaliados por times de segurança, compliance e negócio. A OpenAI atualizou recentemente o GPT-5.5 Instant no ChatGPT e na API para melhorar estilo e qualidade das respostas. Segundo a empresa, o modelo passou a entregar respostas mais fáceis de ler, mais naturais em conversas cotidianas, com melhor ritmo em tarefas práticas e menos tendência a produzir respostas excessivamente longas ou carregadas de listas. A atualização ocorreu após o lançamento do GPT-5.5 Instant como sucessor do GPT-5.3 Instant, descrito pela OpenAI como mais inteligente e menos propenso a alucinações. Para empresas, esse tipo de evolução gera uma dificuldade específica. Muitas organizações realizam testes de segurança, compliance e validação de negócio antes de aprovar um modelo para uso em produção. No entanto, quando o comportamento do modelo muda dentro da mesma família de versão, pressupostos documentados anteriormente podem deixar de refletir o desempenho real. Segundo Seker, o maior desafio de governança em IA não é a adoção do modelo, mas a mudança do modelo. Avaliar uma solução uma vez é viável para muitas organizações. O problema é manter uma avaliação contínua de como essa solução evolui ao longo do tempo. Esse ponto é especialmente relevante para setores regulados, nos quais auditabilidade, repetibilidade e gestão de mudanças são requisitos críticos. Mesmo melhorias benéficas podem criar preocupações de governança quando empresas não têm clareza suficiente sobre o que mudou, quando mudou e qual impacto a alteração pode ter sobre processos, decisões e controles existentes. Governança em um serviço que não para de mudar Valence Howden, advisory fellow da Info-Tech Research Group, observa que muitas organizações não conseguem avaliar adequadamente as implicações de cada iteração dos modelos em relação aos seus próprios limites internos. Em alguns casos, sequer sabem que mudanças relevantes ocorreram. No início da adoção corporativa de IA, a principal preocupação estava em saber qual modelo era usado, o que ele fazia e quem era responsável por sua operação. Com atualizações frequentes, essa visibilidade se torna mais difícil. As empresas passam a depender mais das práticas de terceiros e de ferramentas externas que nem sempre conseguem auditar em profundidade. Para Howden, quando empresas não têm a capacidade de optar por não receber uma atualização antes de sua incorporação, acabam testando as mudanças diretamente junto com seus clientes. Essa dinâmica aumenta o risco de que alterações de comportamento sejam descobertas somente após impacto em processos reais. Seker afirma que equipes de segurança já estão no limite porque precisam gerenciar modelos em rápida evolução, novos recursos e mudanças de comportamento sem abrir mão de compliance, gestão de risco e continuidade de negócios. A dificuldade é que as organizações não estão mais avaliando um produto estático. Elas estão gerenciando um serviço em evolução contínua, no qual capacidades, integrações e comportamentos de usuários podem mudar mais rapidamente do que os ciclos tradicionais de revisão de segurança. Howden acrescenta que muitas empresas ainda têm práticas frágeis de governança e accountability. Se a organização já enfrenta dificuldades para gerenciar riscos tradicionais, torna-se ainda mais difícil aplicar disciplina de governança em uma tecnologia que evolui rapidamente e é incentivada por velocidade e inovação. Como as empresas devem responder Especialistas defendem que organizações passem a tratar modelos de IA como sistemas vivos, e não como versões fixas de software. Isso significa substituir aprovações únicas por validação contínua, monitoramento recorrente e reavaliações periódicas. Programas de segurança e governança devem incluir testes regulares de comportamento, análise de impacto sobre processos críticos, revisão de permissões, monitoramento de uso, gestão de integrações e documentação de mudanças relevantes. Também é necessário estabelecer expectativas claras com fornecedores sobre gestão de mudanças, incluindo transparência sobre atualizações de modelo, alterações comportamentais e possíveis impactos sobre fluxos já existentes. O Active sessions melhora a camada de controle de acesso e investigação, mas não substitui governança de modelo. Para ambientes corporativos, a questão central passa a ser a capacidade de enxergar mudanças, avaliar consequências e ajustar controles de forma contínua. A evolução da IA corporativa torna insuficiente uma abordagem baseada apenas em inventário, autorização inicial e políticas estáticas. A governança efetiva depende cada vez mais da visibilidade sobre mudanças, e não apenas da visibilidade sobre riscos conhecidos. Em um cenário no qual modelos, recursos e integrações são atualizados rapidamente, empresas precisarão construir processos capazes de acompanhar essa velocidade sem comprometer segurança, conformidade e continuidade operacional.

Uma falha no Claude Code GitHub Action, da Anthropic, permitia que um invasor assumisse o controle de repositórios públicos vulneráveis apenas abrindo uma issue maliciosa no GitHub. O problema, descoberto pelo pesquisador RyotaK, da GMO Flatt Security, expôs riscos relevantes para pipelines de CI/CD que integram agentes de IA com permissões amplas sobre código, issues, pull requests e workflows. O caso é especialmente sensível porque o próprio repositório da action da Anthropic utilizava o mesmo fluxo vulnerável. Em um cenário de exploração bem-sucedida, um invasor poderia inserir código malicioso na própria action e afetar projetos downstream que dependem dela, ampliando o impacto para uma cadeia de suprimentos de software. RyotaK reportou o bypass principal à Anthropic em janeiro. A empresa corrigiu a falha em quatro dias e continuou reforçando a segurança da ferramenta ao longo dos meses seguintes. As correções estão disponíveis a partir da versão claude-code-action v1.0.94. A Anthropic classificou os problemas com pontuação 7.8 no CVSS v4.0 e pagou uma recompensa por meio de seu programa de bug bounty. O Claude Code GitHub Actions permite inserir o Claude em pipelines de CI/CD para tarefas como triagem de issues, aplicação de labels, revisão de pull requests e execução de comandos por meio de slash commands. Por padrão, o workflow pode receber permissões de leitura e escrita sobre código, issues, pull requests, discussões e arquivos de workflow do repositório. Essa combinação torna o controle de acionamento um ponto crítico. Como a action pode operar com permissões amplas, ela deveria aceitar comandos apenas de usuários confiáveis, normalmente aqueles com permissão de escrita no repositório. O problema identificado estava justamente nessa verificação. A lógica de autorização aceitava qualquer ator cujo nome terminasse em “[bot]”, partindo da premissa de que GitHub Apps seriam entidades confiáveis instaladas por administradores. No entanto, qualquer pessoa pode registrar um GitHub App, instalá-lo em um repositório próprio e usar seu token para abrir uma issue ou pull request em qualquer repositório público. A action interpretava essa atividade como proveniente de um bot confiável e permitia que o conteúdo malicioso fosse processado. A falha afetava de forma particular o modo agent. No modo tag, havia uma verificação adicional para confirmar se o ator era um usuário humano real. No modo agent, esse controle não existia, deixando a action exposta à exploração. A partir desse ponto, o ataque dependia de prompt injection indireto. Essa técnica consiste em inserir instruções maliciosas em um conteúdo que será lido por um sistema de IA, levando o modelo a seguir comandos escondidos em vez de cumprir apenas a tarefa original. No caso demonstrado, RyotaK criou uma issue cujo corpo simulava uma mensagem de erro e ajustou o prompt até fazer o Claude “recuperar” a execução rodando comandos embutidos no texto. O alvo era o arquivo /proc/self/environ, em sistemas Linux, que armazena variáveis de ambiente do processo, incluindo possíveis segredos. Embora o Claude Code bloqueasse leituras diretas desse arquivo, o pesquisador conseguiu contornar a proteção e induzir o agente a escrever os valores de volta na própria issue. Com isso, o invasor poderia acessar os dados vazados. Entre essas variáveis, o ativo mais importante era o par de credenciais usado pelo GitHub Actions para solicitar um token OIDC. Esse token assinado comprova que determinado workflow está sendo executado em determinado repositório. O Claude Code troca esse token com o backend da Anthropic para obter um token de instalação do Claude GitHub App com acesso de escrita. Na prática, se um invasor roubasse essas credenciais e repetisse a troca, poderia obter acesso de escrita ao código, às issues e aos workflows do repositório alvo. Caso o ataque fosse direcionado ao repositório da própria claude-code-action, haveria possibilidade de comprometer a action consumida por outros projetos, criando um risco de supply chain. RyotaK também identificou uma rota mais simples, que dispensava o truque envolvendo bots. Um exemplo de workflow de triagem de issues da própria Anthropic utilizava a configuração allowed_non_write_users: "*", permitindo que qualquer usuário acionasse a action. A documentação da Anthropic já tratava essa configuração como arriscada, mas muitos repositórios copiaram o exemplo e herdaram a exposição. Outro agravante era o fato de o Claude publicar resumos de tarefas no painel público de execução do workflow. Esse comportamento criava um canal direto para vazamento de informações, já que dados sensíveis poderiam ser exibidos em uma área visível publicamente. Também havia um caminho de exploração para um invasor sem permissão para acionar o Claude diretamente, mas com capacidade de editar issues. Nesse caso, bastaria alterar uma issue criada por um usuário confiável depois que o workflow fosse disparado, mas antes de o Claude ler o conteúdo. O payload malicioso passaria a ser tratado como entrada confiável. A recomendação principal é atualizar o Claude Code GitHub Action para a versão v1.0.94 ou posterior. Além disso, organizações devem revisar workflows que permitem acionamento por usuários sem permissão de escrita ou por bots. Se a action processar entrada não confiável, ela não deve ter acesso a segredos além do Anthropic API Key e do GITHUB_TOKEN estritamente necessários. Também é recomendável remover ferramentas e permissões que possam ser usadas para exfiltração de dados. O caso reforça um risco recorrente em agentes de IA integrados a ambientes de desenvolvimento: prompt injection não é apenas um problema teórico quando o agente possui ferramentas reais, permissões reais e acesso a tokens. A extensão do impacto depende diretamente do que o agente consegue executar dentro do ambiente. Esse tipo de cadeia de ataque já teve consequências práticas. Em fevereiro, uma issue com título manipulado por prompt injection contra o workflow de triagem do Cline, baseado no claude-code-action, permitiu que invasores roubassem um token de publicação npm e enviassem uma versão não autorizada, cline@2.3.0. A versão maliciosa forçava a instalação de um agente de IA separado, não malicioso, e foi removida cerca de oito horas depois. Ainda assim, a mesma cadeia poderia ter sido usada para distribuir malware real a todos os usuários que atualizassem o pacote. No fim de fevereiro, o bot autônomo “HackerBot-Claw” também passou a sondar configurações incorretas em GitHub Actions de organizações como Microsoft, Datadog, projetos da CNCF e outras. Em uma das tentativas, o bot tentou manipular um revisor baseado em Claude por meio de um arquivo de configuração envenenado, mas o Claude identificou a tentativa e recusou a execução. Não há indicação pública de que o caminho específico capaz de comprometer a action da própria Anthropic tenha sido usado contra um alvo real. RyotaK demonstrou a técnica apenas em repositórios de teste próprios e separou esse cenário das variantes que chegaram a ser exploradas em ambientes reais. O pesquisador afirmou já ter reportado cerca de 50 formas diferentes de contornar o sistema de permissões do Claude Code e executar comandos. O volume de descobertas aponta para um desafio mais amplo em agentes de codificação baseados em IA: quando esses sistemas são conectados a pipelines de desenvolvimento, repositórios e credenciais, falhas de prompt injection podem se transformar em problemas reais de segurança de aplicação, CI/CD e cadeia de suprimentos. Para equipes de segurança, a principal lição é que agentes de IA devem ser tratados como componentes privilegiados dentro do ambiente de desenvolvimento. Isso exige princípio do menor privilégio, segregação de tokens, revisão de permissões, controle rigoroso de quem pode acionar workflows, bloqueio de entradas não confiáveis, logs auditáveis e mecanismos de contenção para impedir que uma instrução maliciosa em uma issue se transforme em acesso de escrita ao repositório.

Pesquisadores da WithSecure identificaram um grupo até então não documentado, alinhado a interesses russos, que vem usando modelos de linguagem de grande porte em diferentes etapas de ataques contra organizações privadas, governamentais e militares na Ucrânia. O grupo, batizado de Greyvibe, utiliza IA generativa para criar iscas de spear phishing, scripts maliciosos, malware personalizado e infraestrutura de backend, em operações voltadas à coleta de inteligência no contexto da guerra em andamento. A análise aponta que o Greyvibe faz uso sistemático de inteligência artificial ao longo de suas campanhas, não apenas em tarefas isoladas. Segundo os pesquisadores, as atividades observadas se alinham a interesses do Estado russo, mas alguns indicadores sugerem vínculos com o ecossistema mais amplo do cibercrime, incluindo a possível participação de agentes com histórico atual ou anterior em atividades criminosas. A primeira campanha atribuída ao grupo foi lançada em agosto de 2025, com e-mails de spear phishing que simulavam comunicações de autoridades e órgãos governamentais ucranianos. Entre as entidades usadas como isca estavam a cidade de Kyiv, a Diretoria Principal do Serviço Estatal de Emergência e o Serviço Estatal de Comunicações Especiais e Proteção da Informação da Ucrânia. Essas mensagens continham links para arquivos ZIP e RAR hospedados no Google Drive e em um serviço chamado 4sync. Dentro dos arquivos estavam loaders de malware escritos em Python e JavaScript. O payload final era um malware personalizado desenvolvido pelo próprio grupo, chamado PhantomRelay pelos pesquisadores da WithSecure. Em outubro, o Greyvibe passou a experimentar ataques no estilo ClickFix, usando páginas falsas de CAPTCHA da Cloudflare. Nesse tipo de abordagem, a vítima é induzida a abrir a janela “Executar” do Windows e colar comandos maliciosos. A técnica tem sido usada por diferentes grupos para contornar barreiras tradicionais de segurança, explorando a confiança do usuário em instruções aparentemente legítimas exibidas no navegador. O grupo também criou sites falsos de clubes adultos em ucraniano e páginas fraudulentas de instituições de caridade que alegavam apoiar as forças militares ucranianas com drones FPV e UAVs. Essas páginas foram usadas para distribuir diferentes famílias de malware, incluindo FallSpy para dispositivos Android e PhantomRelay e LegionRelay para sistemas Windows. A WithSecure também rastreou um site em russo que, segundo os pesquisadores, pode ter feito parte das operações do grupo. A página mencionava números de centrais telefônicas codificados de forma fixa, associados a telecomunicações seguras normalmente usadas pelas forças militares russas. A vitimologia pretendida dessa atividade ainda não está clara, mas a hipótese mais plausível é que a isca tentava enganar militares ucranianos ao simular acesso a um terminal militar russo. Malwares personalizados com apoio de IA O PhantomRelay é um trojan de acesso remoto, ou RAT, escrito em PowerShell. Ele permite executar scripts personalizados recebidos de um servidor de comando e controle, conhecido como C2. Embora variantes desse malware tenham sido vistas em atividades possivelmente não relacionadas ao Greyvibe, o grupo reescreveu completamente a ferramenta e criou uma versão usada exclusivamente em suas próprias operações. O LegionRelay é outro RAT baseado em PowerShell. Assim como o PhantomRelay, ele pode executar comandos e scripts enviados pelo servidor C2. A ferramenta foi usada para enumeração de arquivos, exfiltração de dados, captura de screenshots, roubo de dados de navegadores, coleta de informações do Telegram e WhatsApp, configuração de acesso via RDP e outras ações pós-comprometimento. Já o FallSpy é um spyware para Android projetado para coletar uma ampla variedade de informações do dispositivo infectado. Entre os dados visados estão contatos, registros de chamadas, lista de aplicativos instalados, números de telefone vinculados ao SIM, informações do aparelho e da rede, SSID de Wi-Fi, última localização conhecida, endereço IP público e arquivos de mídia. Além dessas famílias principais, os pesquisadores observaram scripts personalizados usados para ofuscação e carregamento de malware. Entre eles estão LOOKVALPS, escrito em PowerShell; LOOKVALJS, em JavaScript; DAYLIGHT, também em PowerShell; e TEASOUP, em JavaScript. A WithSecure avaliou, com confiança moderada, que várias dessas ferramentas personalizadas foram desenvolvidas com auxílio de modelos de linguagem. O LegionRelay, em particular, assim como a infraestrutura de backend usada para operá-lo, apresentou fortes indicadores de geração por IA. Os pesquisadores acreditam que algumas das plataformas usadas pelos invasores incluem Ideogram AI, ChatGPT e Google Gemini. O uso de IA pelo Greyvibe não parece limitado à criação de textos de phishing ou à geração de pequenos trechos de código. De acordo com a análise, o grupo emprega inteligência artificial em múltiplas fases operacionais, incluindo desenvolvimento de malware, criação de scripts, montagem de infraestrutura e preparação de iscas voltadas a públicos específicos. Essa abordagem pode permitir que o grupo compense lacunas técnicas, acelere ciclos de desenvolvimento e reduza vínculos históricos com atividades anteriores. Em outras palavras, ao usar IA generativa para criar ou reescrever ferramentas, os operadores podem diversificar seu conjunto de técnicas e dificultar a detecção, o rastreamento e a atribuição das campanhas. A descoberta também reforça uma mudança importante no cenário de ameaças: grupos alinhados a interesses estatais ou híbridos, com possíveis conexões com o cibercrime, estão incorporando IA não apenas como recurso auxiliar, mas como parte do processo operacional. Isso pode aumentar a velocidade de adaptação, a variedade das campanhas e a complexidade das investigações. No caso do Greyvibe, os alvos observados indicam foco em coleta de inteligência relacionada à Ucrânia. As campanhas envolveram organizações privadas, órgãos governamentais e entidades militares, com iscas cuidadosamente adaptadas ao contexto local, incluindo mensagens em ucraniano, referências a instituições oficiais e páginas fraudulentas ligadas a temas sensíveis da guerra. Para equipes de segurança, o caso mostra a importância de monitorar não apenas indicadores tradicionais de malware, mas também padrões de comportamento em campanhas que combinam phishing, abuso de serviços legítimos de hospedagem, scripts ofuscados, execução via PowerShell, roubo de dados de mensageiros e tentativa de acesso remoto. A presença de ferramentas como PhantomRelay, LegionRelay e FallSpy indica uma cadeia de ataque voltada à persistência, coleta de informações e exfiltração de dados. Já o uso de ClickFix, sites falsos e arquivos hospedados em plataformas conhecidas mostra uma tentativa de reduzir suspeitas e explorar a confiança do usuário em serviços amplamente utilizados. A WithSecure avalia que o tradecraft do Greyvibe deve continuar evoluindo e se diversificando. Com o uso intensivo de modelos de linguagem e ferramentas generativas, o grupo pode modificar rapidamente sua infraestrutura, alterar scripts, criar novas iscas e adaptar malwares conforme a resposta dos defensores. O caso amplia o debate sobre o impacto da IA generativa em operações ofensivas. Embora modelos de linguagem não substituam completamente conhecimento técnico, eles podem reduzir barreiras de entrada, acelerar tarefas repetitivas e permitir que grupos com capacidades intermediárias desenvolvam ferramentas mais sofisticadas em menos tempo. Para organizações em setores sensíveis, especialmente em países envolvidos em conflitos geopolíticos ou próximos a temas estratégicos, a investigação reforça a necessidade de defesa em profundidade. Isso inclui treinamento contra phishing, bloqueio e monitoramento de execução de scripts, análise de comportamento em endpoints, proteção de dispositivos móveis, inspeção de tráfego C2, controle de acesso remoto e detecção de exfiltração em aplicativos como navegadores, mensageiros e serviços de armazenamento.

O RoqueOS surge como uma proposta brasileira para repensar a forma como usuários interagem com dispositivos, aplicações e ambientes de infraestrutura. A plataforma funciona como um sistema operacional baseado em navegador, recriando a experiência de um desktop completo em qualquer dispositivo com suporte a browsers modernos, sem depender diretamente do sistema operacional original da máquina. A ideia central é transformar smart TVs, tablets, smartphones, notebooks, servidores e até assistentes inteligentes com tela em pontos de acesso para um mesmo ambiente visual, unificado e responsivo. Em vez de exigir instalações complexas ou limitar o usuário às capacidades de cada dispositivo, o RoqueOS opera como uma camada universal capaz de integrar aplicações, infraestrutura, automação e desenvolvimento em uma única interface. A proposta parte de um problema comum no cenário atual: a fragmentação entre dispositivos e ecossistemas. Embora muitos equipamentos tenham hardware cada vez mais potente, suas interfaces e sistemas embarcados costumam ser limitados, pouco flexíveis e isolados. Smart TVs, por exemplo, podem ter bom poder computacional, mas geralmente oferecem poucas possibilidades de personalização, desenvolvimento ou integração com serviços externos. O mesmo desafio aparece em ambientes de desenvolvimento, automação residencial e servidores pessoais. Usuários técnicos frequentemente precisam alternar entre múltiplas interfaces, terminais, painéis web, ferramentas de acesso remoto, aplicações de monitoramento e sistemas de gerenciamento de containers. O RoqueOS tenta reduzir essa dispersão ao concentrar tudo em um ambiente acessível pelo navegador. Diferentemente de painéis administrativos tradicionais ou soluções simples de desktop remoto, o RoqueOS foi projetado para entregar a sensação de um sistema operacional completo dentro do browser. A interface inclui gerenciamento de janelas, multitarefa, sistema de arquivos visual, aplicativos integrados e navegação adaptada tanto para telas grandes quanto para dispositivos móveis. Além da camada visual, o projeto atua como um orquestrador de infraestrutura. Em seu modo servidor, a plataforma pode se conectar a serviços reais executados localmente ou em servidores, incluindo containers Docker, terminais Linux, IDEs web, acesso remoto via SSH, RDP e VNC, além de integrações com sistemas de automação residencial, como o Home Assistant. Essa arquitetura permite que o navegador deixe de ser apenas uma porta de acesso a aplicações web e passe a funcionar como uma interface central para computação pessoal, desenvolvimento, administração de sistemas e automação. Na prática, o processamento, os serviços e os ambientes de trabalho podem estar centralizados em um servidor, enquanto o usuário acessa tudo a partir de qualquer dispositivo compatível. O RoqueOS também foi concebido como uma plataforma em evolução contínua. Por ser baseado em tecnologias web, novas funcionalidades, ajustes de interface e melhorias de desempenho podem ser entregues com maior velocidade do que em sistemas tradicionais. A proposta é manter o ambiente em atualização constante, acompanhando avanços em containers, aplicações web e inteligência artificial. No estágio atual, o projeto é voltado principalmente para profissionais de tecnologia, desenvolvedores, entusiastas de homelab, makers e usuários com familiaridade em servidores, containers e administração de sistemas. A instalação e operação em modo servidor exigem conhecimentos técnicos básicos, uma escolha alinhada ao foco inicial do RoqueOS em estabilidade, flexibilidade e controle do ambiente. Entre os principais contextos de uso estão homelabs, infraestrutura pessoal, desenvolvimento de software no navegador, ambientes de ensino remoto, laboratórios virtuais, quiosques, painéis interativos, pontos de venda, testes de QA, DevOps, automação residencial e execução leve de aplicações ou ambientes legados. Para usuários com equipamentos de baixo desempenho, o RoqueOS pode funcionar como uma alternativa para centralizar aplicações e processamento em um servidor, permitindo que notebooks antigos, tablets simples, smart TVs ou dispositivos compartilhados acessem uma experiência mais completa apenas pelo navegador. Esse modelo reduz a dependência do hardware local e amplia as possibilidades de reutilização de dispositivos. No desenvolvimento de software, a plataforma pode combinar terminal Linux real, VS Code no navegador, containers isolados e integração com repositórios de código. Com isso, desenvolvedores podem acessar ambientes prontos de qualquer lugar, sem depender de configurações locais complexas em cada máquina utilizada. Em ambientes educacionais, o RoqueOS pode ser aplicado para disponibilizar laboratórios virtuais de programação, infraestrutura, automação ou robótica. Cada aluno pode acessar seu próprio ambiente isolado via browser, reduzindo a necessidade de instalações individuais nos computadores e simplificando a padronização dos ambientes de aula. Já em automação residencial e Internet das Coisas, o sistema pode atuar como um painel central para integrar ferramentas como Home Assistant, scripts personalizados, monitoramento de dispositivos e acesso remoto seguro. A proposta é reunir o controle da casa inteligente em uma interface única, acessível de diferentes telas. O modelo atual de acesso prevê uso gratuito em modo auto-hospedado, voltado a servidores próprios, homelabs e infraestrutura dedicada. Segundo o material do projeto, não há cobrança de licenciamento para uso do sistema nesse formato, preservando o controle do usuário sobre dados, aplicações e ambiente. Para o futuro, estão sendo estudados modelos opcionais de monetização, especialmente para conveniência e uso profissional. Entre as possibilidades estão serviços gerenciados, simplificação de deploy, recursos avançados e suporte especializado. A proposta, no entanto, é que essas opções coexistam com a versão auto-hospedada gratuita, sem substituí-la. O RoqueOS pode ser utilizado de duas formas principais. No modo standalone, o usuário acessa o site oficial em um navegador moderno e utiliza a interface de desktop, aplicativos web integrados e recursos básicos, sem instalação local. Já o modo servidor libera o potencial completo da plataforma, com instalação baseada em Docker e recursos como terminal Linux isolado por usuário, sistema de arquivos persistente, gerenciamento de aplicações via App Store, IDEs no navegador, browser remoto, conexões SSH, RDP e VNC, além de monitoramento de recursos e logs. A origem do projeto remonta a 2009, quando Roque Ribeiro, criador do RoqueOS, desenvolveu um protótipo experimental de sistema operacional rodando no navegador. Na época, a ideia era integrar dispositivos móveis e computadores sem o uso de cabos, mas as limitações tecnológicas impediram que o conceito evoluísse para um produto mais maduro. Com o avanço das tecnologias web, dos containers e da inteligência artificial, o projeto foi retomado e ganhou uma nova arquitetura. Mais do que uma interface web, o RoqueOS propõe uma mudança na relação entre usuário e dispositivo. Em vez de adaptar a rotina às limitações de cada sistema, a plataforma busca adaptar diferentes telas a um mesmo ambiente computacional. Essa visão posiciona o projeto como uma alternativa para quem procura mais controle, portabilidade e integração entre computação pessoal, desenvolvimento e automação.

Empresas adotam agentes que criam, revisam e otimizam códigos, enquanto profissionais assumem funções mais estratégicas e de governança A criação de soluções em inteligência artificial demanda, historicamente, desenvolvedores de softwares. Mas, e quando a própria IA passa a escrever códigos e criar sistemas sozinha? Uma pesquisa da Universidade Cornell, em Nova York, revelou que a IA não apenas cria código, mas também o aprimora de forma ativa. O estudo mostrou que a refatoração - isto é, a melhoria estrutural - ocorre de maneira intencional, com os agentes alterando, de forma autônoma, 1 a cada 4 códigos (26,1% dos commits), principalmente para aumentar a manutenibilidade (52,5%) e a legibilidade (28,1%) dos sistemas. Esse conceito é intitulado de agentic engineering, metodologia de trabalho em que a inteligência artificial deixa de apenas responder comandos e passa a atuar como um agente ativo, capaz de planejar tarefas, tomar decisões e executar ações sem a intervenção humana. Um estudo da multinacional Jellyfish mostrou que, no início de 2025, 51% das empresas já utilizavam IA com agentes; poucos meses depois, esse número saltou para 82%. No mesmo período, houve redução no tempo de revisão de código (1,16 vezes) e um aumento significativo no uso de fluxos em que a própria IA cria, confirma ou abre revisões de código. Um relatório da Codeminer42, boutique brasileira de desenvolvimento de softwares, indicou ganho de produtividade de três a quatro vezes. O estudo de caso, realizado entre fevereiro e março deste ano, baseou-se nas atividades de um desenvolvedor sênior, que produziu e entregou seis produtos de software em nível de produção. Em um deles, foi desenvolvida uma solução com inteligência artificial pela Codeminer42 para um cliente externo - um agente de IA para veterinários. Com a adoção do agentic engineering, a produtividade chegou a ser até três vezes maior, conforme apurado no relatório final de produção. Além da quantidade, há ganho de qualidade. Em outro caso estudado para o mesmo relatório, em menos tempo (20,5 horas, contra até 41 horas que seriam demandadas para o projeto em questão) foi possível fazer mais: nove funcionalidades concluídas e implantadas, seis melhorias adicionais não solicitadas pelo cliente, 134 verificações automatizadas de qualidade e nenhum defeito constatado após implantação. Mas, e como ficam os profissionais responsáveis pela engenharia e construção dessas tecnologias, se a IA já possui tais capacidades? Para o developer relations da Codeminer42, Edy Silva, esse contexto de ganhos não elimina o desenvolvedor - ao contrário, redefine seu papel. "Em vez de executar tarefas operacionais, ele passa a atuar de forma mais estratégica, coordenando e supervisionando diferentes agentes de IA ao longo do processo". Ele explica que essa nova dinâmica exige um domínio técnico ainda mais sólido, já que a qualidade dos resultados depende da capacidade de orientar a IA com precisão. Na prática, saber estruturar bons comandos se torna essencial para extrair o máximo de desempenho, agilidade e assertividade dessas tecnologias. “Se for um profissional competente, experiente, o uso da IA pode duplicar ou até triplicar sua produtividade. Então, não estamos falando de substituir o humano pela tecnologia. Trata-se de o humano saber como aproveitar os recursos de IA para entregar um trabalho de melhor qualidade, com mais agilidade e menos sujeito a erros – até porque a inteligência artificial não é infalível. Ela erra”, afirma Silva. Por isso, avalia o especialista, a engenharia orientada a agentes autônomos (agentic engineering) representa a ressignificação do papel e do valor profissional de engenheiros e desenvolvedores de softwares. “O profissional deixa de ser um mero ‘escritor de códigos’ para se tornar um orquestrador, um maestro de agentes de IA aplicáveis ao desenvolvimento de soluções tecnológicas”, frisa. A lógica da atribuição do desenvolvedor deixa de estar centrada em “programar cada passo” e migra para o papel de “ensinar o sistema a decidir”, nas palavras de Edy Silva. “Nosso trabalho não é digitar código. É pensar em problemas, tomar decisões, projetar soluções. A inteligência artificial libera o profissional do operacional para atuar no estratégico". Edy Silva ilustra esse avanço com um exemplo prático: “Já desenvolvi projetos inteiros com apoio de IA. Em um deles, foram 12 mil linhas de código, tudo implantado em produção em cinco dias, algo que antes levaria pelo menos um mês. Não escrevi uma única linha manualmente, mas fui responsável por todas as decisões ao longo do processo.” Silva complementa que, à medida que sistemas baseados em IA ganham autonomia, cresce também a necessidade de estabelecer regras claras, critérios de validação e mecanismos de controle sobre as decisões automatizadas. Nesse cenário, o profissional assume um papel central na definição de diretrizes, na garantia de conformidade e na supervisão das operações, assegurando que os resultados estejam alinhados aos objetivos do negócio e a padrões éticos. “É importante sempre enfatizar: as boas práticas (agile, eXtreme programming) são ainda mais valiosas com IA. Existe um jeito errado e um jeito certo de fazer. Fazer ativamente e com boas práticas é o jeito certo”, afirma o especialista, que conclui: “o desenvolvedor atua como um verdadeiro arquiteto desse processo, estruturando regras de governança, definindo limites e garantindo que as decisões executadas pelos agentes de IA sigam critérios confiáveis e auditáveis”.

Hackers estão mirando usuários do Signal em uma nova campanha de phishing criada para roubar chaves de recuperação usadas no acesso a backups de conversas. A tentativa de ataque busca convencer as vítimas a entregar uma informação sensível que pode permitir o acesso a arquivos antigos armazenados no recurso Secure Backups, lançado pelo aplicativo no ano passado. O alerta ganhou visibilidade após Josh Rogin, analista do Washington Post, publicar uma captura de tela mostrando uma mensagem fraudulenta enviada a usuários do Signal. No golpe, os invasores se passam pela equipe de suporte do aplicativo e afirmam que conversas e mídias salvas em backup estariam “em risco de perda permanente devido a um problema de sincronização”. Para evitar a suposta perda dos dados, a mensagem orienta a vítima a compartilhar, diretamente no chat, a chave de recuperação usada para acessar os backups online. O texto malicioso afirma que essa ação “vincula o backup existente à conta” e que a falha em realizar o procedimento poderia resultar na perda de acesso à conta e aos dados armazenados. Segundo Rogin, vários ativistas contrários ao Partido Comunista Chinês receberam a mensagem fraudulenta. No entanto, Mohammed Al-Maskati, diretor da Digital Security Helpline da Access Now, afirmou que duas outras pessoas também compartilharam mensagens semelhantes com ele, e que elas não eram ativistas chinesas. Isso indica que a campanha pode ser mais ampla, mirando outras comunidades, ou que diferentes grupos estejam usando a mesma estratégia. Ainda não está claro o nível de sucesso da campanha. Al-Maskati explicou que obter a chave de recuperação dos backups é apenas uma etapa do ataque, já que os hackers ainda precisariam assumir o controle da conta da vítima para tentar restaurar os dados em outro dispositivo. A presidente do Signal, Meredith Whittaker, disse que a empresa está trabalhando em medidas de mitigação e monitorando a atividade. O ataque explora uma técnica clássica de phishing: enganar a vítima para que ela entregue voluntariamente uma informação privada. Neste caso, os invasores abusam da confiança dos usuários no Signal ao se passarem pelo suporte oficial da plataforma. O próprio Signal afirma que nunca entra em contato primeiro com usuários e nunca solicita código de registro, PIN ou chave de recuperação. Portanto, qualquer conversa que se apresente como “Signal Support” deve ser tratada como maliciosa. A organização já havia alertado publicamente, no mês passado, sobre esse tipo de tentativa de golpe. A novidade desta campanha está no foco específico nos backups. Em ataques anteriores contra usuários do Signal, os invasores tentavam sequestrar a conta da vítima para se passar por ela, acessar contatos ou iniciar conversas em seu nome. Nesses casos, os hackers não conseguiam acessar mensagens antigas, porque o ataque geralmente envolvia registrar a conta da vítima em um novo dispositivo controlado pelos criminosos. Pela arquitetura do Signal, mensagens antigas não aparecem automaticamente no novo aparelho. Uma forma de tentar acessar esse histórico seria obter o backup online da vítima. Para isso, os invasores precisam da chave de recuperação, que é justamente o alvo da nova campanha. O Secure Backups é um recurso opcional que permite aos usuários enviar o conteúdo da conta para servidores do Signal de forma criptografada. Segundo a empresa, a chave de recuperação nunca é compartilhada com os servidores do Signal e nunca deixa o dispositivo do usuário. A recomendação é que essa chave seja guardada com segurança, em um caderno físico ou em um gerenciador de senhas. Sem essa chave única, ninguém, nem mesmo o Signal, consegue ler, descriptografar ou restaurar os dados do arquivo de backup. Isso significa que o acesso ao conteúdo exige três elementos: o registro da conta em um novo telefone, o download do backup criptografado e a chave de recuperação correta para descriptografar os dados. O caso mostra como recursos avançados de segurança também podem ser explorados por campanhas de engenharia social quando os usuários são induzidos a entregar credenciais, PINs ou chaves privadas. A proteção técnica do backup permanece vinculada ao sigilo da chave de recuperação.

Nenhuma organização está completamente protegida contra ataques cibernéticos, e os próprios líderes de segurança reconhecem que muitas estruturas ainda estão abaixo do nível necessário para acompanhar a velocidade atual das ameaças. A pressão sobre os CISOs cresce em um cenário no qual invasores adotam automação, inteligência artificial e exploração acelerada de vulnerabilidades, enquanto empresas ainda convivem com limitações de orçamento, equipes reduzidas, tecnologias legadas e dificuldades para transformar segurança em resiliência de negócio. Segundo o relatório Proofpoint 2025 Voice of the CISO, um terço dos CISOs entrevistados afirmou que os dados dentro de suas organizações não estão adequadamente protegidos. Além disso, 58% disseram que suas empresas não estavam preparadas para responder a um ataque cibernético, enquanto apenas 67% acreditavam contar com orçamento, equipe e ferramentas suficientes para atingir seus objetivos de segurança. Esses números indicam que lacunas críticas continuam presentes em muitas organizações. Algumas são estratégicas, ligadas à forma como a segurança é percebida pela liderança. Outras são operacionais, relacionadas à velocidade de resposta, qualificação das equipes, governança de inteligência artificial e modernização de ambientes legados. Para especialistas e líderes de segurança consultados pela CSO, seis pontos devem estar no topo da agenda dos CISOs. A lacuna de percepção: segurança ainda é tratada como problema de TI A primeira lacuna está na percepção do papel da segurança. Embora muitos CISOs tenham se aproximado mais das áreas de negócio nos últimos anos, parte deles ainda enxerga sua principal missão como proteger sistemas digitais, quando deveria considerar a segurança como um elemento essencial para garantir resiliência operacional. Errol Weiss, CSO da Health-ISAC, afirma que muitos CISOs ainda interpretam um incidente a partir da perspectiva de TI, tratando segurança como um problema técnico. Para ele, é necessário mudar o foco: em vez de proteger sistemas a qualquer custo, a prioridade deve ser entender os impactos em cadeia quando algo falha e preparar a organização para manter suas operações mesmo diante de um ataque. Essa mudança de visão é importante porque a continuidade de negócios, tradicionalmente conduzida por outros executivos, passa a depender cada vez mais da segurança cibernética. Quando o CISO avalia como uma ameaça digital pode afetar receita, atendimento, cadeia de suprimentos, reputação, obrigações regulatórias e continuidade operacional, a organização ganha uma visão mais precisa do risco real e do chamado raio de impacto de um incidente. O ataque contra a Change Healthcare em 2024 é citado como exemplo dessa necessidade. A interrupção não afetou apenas uma empresa, mas provocou consequências em toda a indústria de saúde. Casos desse tipo mostram que o impacto de um ataque pode ultrapassar a infraestrutura de TI e atingir serviços essenciais, parceiros, clientes e processos críticos. A lacuna de velocidade: invasores exploram falhas mais rápido do que as defesas reagem A segunda lacuna está na diferença de velocidade entre invasores e equipes de segurança. O relatório 2025 Year in Review, da Cisco Talos, apontou uma aceleração sem precedentes na exploração de vulnerabilidades, com agentes de ameaça transformando falhas recém-divulgadas, como React2Shell e ToolShell, em armas quase imediatamente após a exposição pública. Para Buck Bell, diretor de estratégia de segurança da CDW, muitas organizações ainda operam com uma mentalidade herdada de períodos anteriores, baseada em controles estáticos e ciclos lentos de correção. Práticas como testes de invasão mensais e janelas tradicionais de patching, embora ainda úteis em determinados contextos, não são suficientes para um ambiente em que a exploração pode ocorrer em horas ou dias. O problema, segundo Bell, é principalmente de execução. As organizações precisam operar com maior velocidade, ajustando controles quase em tempo real e reduzindo o intervalo entre descoberta, priorização e correção. CISOs mais maduros têm buscado acelerar suas operações com automação, inteligência artificial e práticas como Continuous Threat Exposure Management, ou CTEM, abordagem voltada ao monitoramento contínuo da exposição a ameaças. A lacuna entre segurança e negócio: a empresa acelera, mas a proteção nem sempre acompanha A terceira lacuna envolve a velocidade do próprio negócio. À medida que empresas adotam inteligência artificial, computação em nuvem, automação, integração de sistemas e novos modelos digitais, a segurança precisa acompanhar esse ritmo sem se tornar um obstáculo. O relatório PwC 2026 CISO Outlook descreve o papel do CISO como estando em um momento decisivo, pressionado por tecnologias emergentes, riscos mais complexos e expectativas crescentes da liderança. Chirag Shah, global information security officer e data protection officer da Model N, afirma que, se o negócio quer avançar mais rápido, segurança e compliance precisam correr junto. O desafio é que muitas equipes ainda trabalham em modo reativo, tentando se adaptar depois que projetos estratégicos já foram definidos ou implementados. Para reduzir essa distância, Shah investiu na capacitação de profissionais de segurança em inteligência artificial, preparando a equipe para atuar junto às áreas de negócio em iniciativas prioritárias. Chris Cochran, field CISO e vice-presidente de segurança em IA do SANS Institute, também defende o uso de frameworks, padrões e colaboração entre pares como formas de acelerar a adoção de práticas já testadas, escaláveis e alinhadas às mudanças do negócio. A lacuna de habilidades: o problema já não é apenas quantidade de profissionais, mas competências atualizadas A quarta lacuna está nas competências disponíveis. Durante anos, o debate sobre força de trabalho em cibersegurança esteve concentrado na falta de profissionais. Agora, o problema passou a incluir também a defasagem entre as habilidades existentes e as competências necessárias para lidar com novas tecnologias, novos modelos regulatórios e novos tipos de ameaça. O SANS 2026 Cybersecurity Workforce Research Report afirma que a força de trabalho em cibersegurança passa por uma transformação fundamental. A inteligência artificial está alterando pontos tradicionais de entrada na carreira, enquanto exigências regulatórias criam novas demandas de validação de habilidades. Como resultado, cresce a distância entre o que as organizações têm hoje e o que precisam para operar com maturidade. Segundo o relatório, a necessidade de especialistas em novas funções quase dobrou em relação ao ano anterior, enquanto a demanda por contratação adicional em competências já existentes também aumentou. Entre líderes de segurança, 60% apontaram a lacuna de habilidades como o principal desafio de força de trabalho em 2026, acima dos 52% registrados no ano anterior. O índice supera os 40% que citaram a falta de pessoal como principal problema. Beth Miller, global field CISO da Mimecast, observa que a lacuna não está apenas dentro das equipes de segurança. Mesmo uma equipe técnica bem qualificada não elimina o risco se as áreas de negócio não tiverem conhecimentos básicos de segurança. Para ela, a resposta passa por investir na camada humana em toda a organização, criando uma cultura de aprendizagem contínua, conscientização e responsabilidade compartilhada. A lacuna na governança de IA: adoção avança antes dos controles de segurança A quinta lacuna está na proteção de implantações de inteligência artificial. A adoção de IA tem avançado mais rápido do que a capacidade de governança de muitas organizações. Em alguns casos, a liderança anuncia iniciativas estratégicas de IA e, em poucas semanas, áreas de negócio já começam a desenvolver ferramentas, conectar dados e integrar modelos a sistemas existentes. Muitas vezes, os CISOs só descobrem essas iniciativas durante ou depois da implementação. Além da adoção formal, há o avanço da chamada shadow AI, quando colaboradores ou áreas internas usam ferramentas de IA sem conhecimento ou aprovação das equipes de segurança, tecnologia ou governança. Para Chirag Shah, esse fenômeno ocorre em todo o mercado. Identificar essas iniciativas posteriormente não resolve automaticamente os riscos criados no processo. O desafio é duplo. Primeiro, as empresas precisam desenvolver controles de segurança adequados para uma tecnologia que continua evoluindo rapidamente. Segundo, precisam garantir que áreas de negócio, tecnologia, jurídico e compliance aceitem e sigam esses controles. Beth Miller resume o problema como uma lacuna de governança disfarçada de problema de TI. O relatório do SANS identificou que apenas 54% das organizações pesquisadas tinham políticas de segurança para IA em vigor, e somente 20% possuíam frameworks abrangentes de governança prontos. Cerca de 75% ainda estavam implementando ou construindo suas estruturas de governança. Para especialistas, isso mostra que a segurança em IA ainda está em estágio inicial em muitas empresas. Para reduzir essa lacuna, CISOs precisarão combinar ferramentas de observabilidade, influência executiva, treinamentos específicos sobre riscos de IA, boas práticas emergentes e frameworks de governança. A proteção de dados, a validação de modelos, o controle de acessos, a rastreabilidade das decisões e a revisão de integrações passam a ser pontos essenciais em qualquer estratégia de IA segura. A lacuna dos ambientes legados: sistemas antigos limitam a defesa moderna A sexta lacuna envolve ambientes legados. Jason Lish, CISO global da Cisco, afirma que muitos líderes de negócio ainda adotam uma mentalidade de “configurar e esquecer” em relação à tecnologia. Enquanto sistemas continuam funcionando e não são percebidos como diferenciais competitivos, há resistência para modernizá-los. Essa postura cria desafios para CIOs, que precisam integrar IA e novas tecnologias a sistemas antigos, e também para CISOs, que tentam aplicar práticas modernas de segurança em ambientes que muitas vezes não suportam controles atuais. O problema se agrava à medida que invasores usam IA para explorar sistemas fora de suporte e tecnologias legadas incapazes de receber proteções mais avançadas. Um estudo de 2026 da National Association of State CIOs com a Deloitte & Touche indicou que CISOs apontam infraestrutura legada como uma das três principais barreiras para enfrentar desafios de cibersegurança, ao lado do aumento da sofisticação das ameaças e do financiamento insuficiente para segurança. Para Lish, o caminho deve ser baseado em risco. O CISO precisa levar ao conselho ou à alta liderança uma priorização clara, indicando quais equipamentos, sistemas ou dispositivos legados são mais críticos e precisam ser substituídos primeiro. A discussão não deve se limitar ao custo de modernização, mas incluir o risco de manter tecnologias antigas em operação. As seis lacunas apontam para uma conclusão comum: a função do CISO deixou de ser restrita à defesa técnica da infraestrutura. Hoje, segurança precisa acompanhar a velocidade do negócio, antecipar o movimento dos invasores, desenvolver competências novas, governar o uso de IA, reduzir dependências legadas e traduzir riscos cibernéticos em impactos operacionais compreensíveis para a liderança. Para organizações que ainda tratam cibersegurança como um conjunto de ferramentas isoladas, o desafio será maior. A pressão atual exige execução rápida, visão de negócio, resiliência, governança e capacidade de adaptação contínua. Em um ambiente no qual ataques evoluem com automação e inteligência artificial, as lacunas que permanecem abertas tendem a ser exploradas com cada vez menos intervalo entre a descoberta do risco e o impacto real.

A diretora da agência britânica de inteligência cibernética e de sinais, Anne Keast-Butler, fez um alerta contundente sobre a crescente atividade híbrida da Rússia contra o Reino Unido e seus aliados europeus. Segundo a chefe do GCHQ, Moscou conduz ataques diariamente em múltiplas frentes, desde infraestruturas submarinas críticas até operações avançadas no ciberespaço. O discurso foi realizado em Bletchley Park, local histórico considerado o berço da computação moderna e da própria inteligência britânica de sinais. A escolha do local teve como objetivo traçar um paralelo entre os desafios enfrentados durante a Segunda Guerra Mundial e o atual cenário geopolítico, marcado por conflitos híbridos, espionagem digital e operações de influência. De acordo com Keast-Butler, os ataques russos não se limitam a sistemas governamentais. As operações estariam mirando infraestruturas críticas, processos democráticos, cadeias de suprimentos e a confiança pública, utilizando métodos que permanecem abaixo do limiar de uma guerra convencional, mas que possuem potencial significativo de causar impactos econômicos e sociais. A executiva afirmou que o Reino Unido tem intensificado suas ações defensivas e ofensivas para conter essas ameaças. Entre as iniciativas estão a proteção de cabos submarinos e dutos de energia localizados em águas britânicas, além de operações destinadas a interromper redes utilizadas para o contrabando de tecnologias sujeitas a sanções internacionais. O alerta surge poucas semanas após autoridades britânicas divulgarem que monitoraram e forçaram a retirada de uma operação submarina russa próxima a infraestruturas estratégicas localizadas no leito marinho. Segundo o governo, os envolvidos não conseguiram concluir a missão de forma sigilosa. Em paralelo, diversos indivíduos acusados de espionagem e sabotagem ligados ao Kremlin foram identificados e presos em território britânico. Keast-Butler destacou ainda o papel da National Cyber Force, unidade de operações cibernéticas ofensivas criada em parceria com as Forças Armadas britânicas e outras agências de inteligência. Segundo ela, a organização realiza operações de alto impacto diariamente contra ameaças estatais, grupos terroristas e organizações criminosas. Durante o discurso, a diretora do GCHQ enfatizou que o risco de erros de cálculo entre grandes potências está entre os mais elevados que ela já observou. Para a executiva, governos, empresas e instituições precisam tratar a segurança cibernética com um nível de urgência muito superior ao adotado atualmente. A preocupação britânica não se restringe à Rússia. A dirigente também citou o crescimento das capacidades ofensivas da China no ambiente digital. Segundo ela, Pequim se consolidou como uma superpotência tecnológica com recursos avançados de inteligência, operações cibernéticas e capacidades militares. O posicionamento acompanha avaliações recentes divulgadas por serviços de inteligência europeus que apontam que a China alcançou um patamar semelhante ao dos Estados Unidos em determinadas capacidades de ataque cibernético. Documentos analisados por autoridades ocidentais também indicariam investimentos chineses em inteligência artificial voltada para operações ofensivas contra infraestruturas críticas. A inteligência artificial foi outro tema central da apresentação. O GCHQ revelou estar estudando uma nova capacidade nacional de defesa cibernética baseada em agentes autônomos de IA capazes de identificar e responder a ataques em velocidades superiores às alcançadas por operadores humanos. Embora o projeto ainda esteja em fase conceitual, a expectativa é que a iniciativa seja conduzida pelo National Cyber Security Centre e permita aos defensores acompanhar a velocidade crescente das ameaças impulsionadas pela automação e pela inteligência artificial. Outro tema abordado foi a computação quântica. Keast-Butler alertou que a tecnologia representa um desafio estratégico de longo prazo para governos e empresas, pois sistemas quânticos suficientemente avançados poderão quebrar mecanismos criptográficos amplamente utilizados atualmente para proteger comunicações governamentais, sistemas financeiros e operações militares. Por esse motivo, a executiva recomendou que organizações iniciem desde já a migração para algoritmos resistentes à computação quântica. Segundo ela, a preparação antecipada será fundamental para reduzir riscos futuros associados à chamada era pós-quântica. A chefe do GCHQ também reforçou a importância das alianças internacionais, citando a colaboração histórica entre Reino Unido e Estados Unidos que deu origem à aliança de inteligência Five Eyes. Para ela, a cooperação entre países continua sendo um dos ativos mais importantes para enfrentar ameaças provenientes da Rússia, da China e de outros atores estatais.