Três grupos de ciberespionagem suspeitos de ligação com a Rússia estão utilizando recursos legítimos de autenticação do Google, Microsoft e WhatsApp em campanhas de phishing direcionadas a acadêmicos, diplomatas, profissionais dos setores aeroespacial e de defesa, governos e integrantes de think tanks nos Estados Unidos e na Europa. As operações foram associadas pelo Google Threat Intelligence Group (GTIG) aos clusters UNC6293, UNC7005 e UNC5976. Em vez de depender exclusivamente de páginas falsas para roubar senhas, os hackers manipulam processos legítimos como OAuth, senhas de aplicativos, códigos de dispositivos e vinculação do WhatsApp para obter acesso às contas das vítimas. Segundo os pesquisadores Gabby Roncone e Wesley Shields, os três grupos conduzem campanhas persistentes e adaptáveis, empregando engenharia social para comprometer contas pessoais em diferentes plataformas. UNC6293 explora autenticação legítima do Google O UNC6293 foi detalhado inicialmente pelo Google e pelo Citizen Lab em junho de 2025 e é considerado um subgrupo do Ice Relic, anteriormente conhecido como APT29 e também rastreado pelos nomes Cozy Bear e Midnight Blizzard. O grupo já havia sido associado a ataques que exploravam as chamadas senhas de aplicativos do Google para assumir contas das vítimas. Desde então, continuou realizando campanhas de phishing altamente direcionadas, geralmente contra menos de cinco usuários por vez. Os hackers chegaram a se passar por funcionários do Departamento de Estado dos Estados Unidos, utilizando temas diplomáticos, conferências e reuniões como isca. Em junho de 2026, o Google observou uma mudança na estratégia. O UNC6293 passou a utilizar phishing envolvendo OAuth, solicitando que as vítimas realizassem um login legítimo em um provedor externo e posteriormente compartilhassem a URL completa ou o código de verificação gerado durante o processo. Com o código em mãos, os hackers podiam obter acesso à conta da vítima. UNC5976 cria páginas falsas para roubar tokens OAuth O segundo grupo, UNC5976, está ativo pelo menos desde março de 2026 e também utiliza phishing baseado em OAuth, além de infraestrutura em nuvem para automatizar a coleta de tokens de autenticação. Para conduzir os ataques, o grupo registrava domínios geralmente relacionados a serviços de compartilhamento de arquivos e criava projetos de nuvem associados a esses endereços. Os sites apresentavam páginas falsas de compartilhamento de arquivos. Após alguns segundos, a vítima visualizava uma janela com o botão “Continue with Google”. Ao clicar, o usuário era direcionado para a página legítima de autenticação OAuth do Google. Após realizar o login, entretanto, acabava direcionado para um projeto malicioso na nuvem contendo scripts desenvolvidos para capturar o token de autenticação presente na URL. O Google estima que o UNC5976 tenha criado pelo menos 12 novos domínios e infraestruturas relacionadas desde março. Esses recursos foram posteriormente desativados, levando o grupo a migrar parte de suas páginas de phishing para outros provedores. O UNC5976 também utilizou um plugin malicioso para Excel chamado HEADRUSH, empregado para entregar um arquivo HTA. O malware foi identificado em abril de 2026 e distribuído através de um domínio falso que imitava um instituto de pesquisa ucraniano. Há indícios de que a campanha possa ter sido utilizada contra uma empresa ucraniana dos setores aeroespacial e de imagens, embora o alcance completo da operação ainda seja desconhecido. Segundo o Google, o UNC5976 concentra suas atividades principalmente nos setores militar, aeroespacial, base industrial de defesa, organizações não governamentais e think tanks, com grande parte dos alvos localizada na Ucrânia e na Armênia. UNC7005 usa Google, Microsoft e WhatsApp O UNC7005, também rastreado como Storm-2945, tornou-se o principal foco da investigação do GTIG. Identificado em fevereiro de 2026, o grupo tem como principais alvos profissionais acadêmicos, diplomáticos e integrantes de organizações sem fins lucrativos na Ucrânia, Europa Ocidental e Estados Unidos. O Google acredita que UNC7005 e UNC6293 estejam relacionados a uma estrutura dentro do Ice Relic especializada em operações de acesso inicial. Além de campanhas envolvendo senhas de aplicativos, o UNC7005 utiliza phishing baseado em códigos de dispositivos para comprometer contas da Microsoft e do WhatsApp. No caso da Microsoft, os hackers enviavam convites falsos para conferências e eventos diplomáticos. Os links direcionavam para sites controlados pelo grupo, que coletavam informações sobre o visitante e solicitavam a confirmação da participação no evento, incluindo preferências de prato principal e vinho. Iscas relacionadas a vinho não são novas nas operações atribuídas ao Ice Relic. Campanhas com características semelhantes são observadas desde abril de 2023. WhatsApp é vinculado ao dispositivo dos hackers Entre maio e junho de 2026, o UNC7005 também realizou operações de engenharia social imitando recursos do WhatsApp. As páginas de phishing tentavam convencer as vítimas de que era necessário vincular suas contas a outro dispositivo para participar de uma chamada segura, acessar um chat criptografado ou visualizar um documento. Primeiro, a vítima informava seu número de telefone. Os hackers utilizavam esse número para iniciar uma solicitação legítima de vinculação do WhatsApp em um dispositivo sob seu controle. A página então apresentava à vítima o QR Code e o código legítimos de vinculação, acompanhados de instruções para concluir o processo. Caso o usuário seguisse as instruções, sua conta do WhatsApp passava a ficar vinculada também ao dispositivo controlado pelos hackers. Depois disso, a página apresentava novas opções, como participar de uma chamada de voz, entrar em um chat criptografado ou baixar um arquivo. Segundo o Google, caso a vítima selecionasse a chamada, códigos JavaScript eram executados para gravar áudio e vídeo e transmitir o material para um servidor de comando e controle. Na opção de chat criptografado, a vítima era orientada a copiar credenciais apresentadas na página e utilizá-las em uma segunda URL. A natureza exata do arquivo oferecido para download não foi determinada. Grupo também utiliza infostealers contra Windows e macOS Por volta de maio de 2026, o UNC7005 ampliou suas operações utilizando malwares conhecidos para roubo de informações, como Vidar e Atomic, também chamado de AMOS. Os ataques atingiram sistemas Windows e macOS e tiveram como alvos acadêmicos, diplomatas e pesquisadores dos Estados Unidos especializados em Rússia e antigos países soviéticos. As vítimas recebiam mensagens contendo links para uma página falsa de uma conferência relacionada a uma “resolução em apoio à Ucrânia”. O site orientava o usuário a baixar um suposto aplicativo complementar do evento para consultar o documento completo. No início de agosto, o grupo também começou a realizar ataques de phishing OAuth contra contas Google utilizando infraestrutura em nuvem. A partir de 31 de julho, o UNC7005 registrou domínios que imitavam o Finnish Operations Center (FOC), organização que apoia empresas finlandesas nos mercados de defesa e segurança, particularmente em atividades relacionadas à OTAN. Entre 6 e 13 de agosto, e-mails direcionados foram enviados para pessoas ligadas à indústria de defesa europeia. Ao acessar os domínios maliciosos, as vítimas eram encaminhadas para uma página legítima de login OAuth do Google. Após a autenticação, porém, eram redirecionadas para um projeto em nuvem não verificado e controlado pelos hackers, permitindo o roubo dos tokens e o sequestro das contas. Campanha CaptiveCrunch compromete redes Wi-Fi As atividades também apresentam conexões com a campanha CaptiveCrunch, documentada pela ReliaQuest e pela Microsoft. Essa operação tem como alvo portais cativos de redes Wi-Fi em locais como hotéis, centros de conferências e aeroportos nos Estados Unidos e em outros países. Os hackers obtêm acesso administrativo aos gateways Wi-Fi e modificam suas configuraurações. Técnicas de DNS poisoning são então utilizadas para redirecionar o tráfego legítimo para infraestrutura controlada pelo grupo. Segundo a Microsoft, esse tipo de manipulação de tráfego ocorre pelo menos desde o início de maio de 2026. Parte da operação utiliza domínios que imitam serviços online da Microsoft para realizar ataques adversary-in-the-middle (AitM) e abusar do fluxo de autenticação por código de dispositivo do Microsoft Entra ID. A posição privilegiada na rede também permite distribuir malware disfarçado de atualizações de navegador ou sistema operacional. CornFlake RAT e ChocoShell são distribuídos nos ataques Os redirecionamentos podem levar à instalação do CornFlake RAT, um trojan de acesso remoto desenvolvido em Go, ou do ChocoShell, um payload PowerShell distribuído através da técnica de engenharia social ClickFix. O CornFlake RAT possui recursos para enumerar sistemas, coletar arquivos e teclas digitadas, roubar credenciais e tokens de sessão, realizar vigilância por áudio e vídeo, monitorar mídias removíveis e abrir um shell remoto nos computadores infectados. Já o ChocoShell é um infostealer baseado em PowerShell capaz de roubar cookies de sessão de navegadores, senhas armazenadas, tokens de Single Sign-On do Microsoft 365 e credenciais de redes Wi-Fi. A análise indica que o código do ChocoShell provavelmente foi gerado com auxílio de um modelo de linguagem de grande porte (LLM). Toda a operação é administrada através de um painel centralizado de comando e controle chamado FruitStone. A ferramenta utiliza a marca “CloudSync Console” e se apresenta como associada à “Acuity Systems, Inc.”, aparentemente para parecer um software legítimo de gerenciamento em nuvem. Segundo a Microsoft, o FruitStone permite gerenciar dispositivos comprometidos, criar e distribuir novos payloads e consultar dados roubados, incluindo capturas de tela, teclas digitadas e credenciais de navegadores. Possível ataque à cadeia de suprimentos Uma investigação paralela da Lumen Black Lotus Labs levantou a possibilidade de que os responsáveis pela CaptiveCrunch tenham comprometido vários Managed Service Providers (MSPs) e posteriormente utilizado a relação de confiança dessas empresas com seus clientes para alcançar redes Wi-Fi administradas por elas. Segundo a Lumen, o acesso aos MSPs pode ter permitido que os hackers chegassem aos gateways Wi-Fi de hotéis e outros estabelecimentos e configurassem o sequestro de DNS para selecionar quais usuários seriam redirecionados para a infraestrutura de phishing. Os dados de telemetria da empresa identificaram aproximadamente 70 endereços IP de vítimas. Desses, 40 enviaram consultas DNS para servidores de comando e controle associados à CaptiveCrunch. Outros 30 endereços IP se comunicaram com a infraestrutura AitM utilizada para capturar tokens de autenticação, enquanto um único IP foi observado interagindo com o servidor C2 do ChocoShell. Segundo o GTIG, as diferentes campanhas mostram que os grupos russos estão explorando vários mecanismos legítimos de autenticação, desde senhas de aplicativos e OAuth até códigos de dispositivos e vinculação de contas. A utilização de processos reais de autenticação dificulta a distinção entre acessos legítimos e maliciosos. Além de permitir o roubo rápido de informações, contas já comprometidas podem ser utilizadas posteriormente para realizar novas campanhas de phishing contra outros alvos de interesse.

A Red Hat e o projeto Keycloak lançaram atualizações para corrigir uma vulnerabilidade crítica no servidor de código aberto de gerenciamento de identidade e acesso que pode permitir que um atacante remoto e sem autenticação assuma contas de usuários ao manipular o processo de redefinição de senha. Identificada como CVE-2026-18963, a vulnerabilidade recebeu pontuação 9,1 no CVSS e foi classificada pela Red Hat como um mecanismo fraco de recuperação de senhas esquecidas (CWE-640). Usuários do Keycloak devem atualizar para a versão 26.7.2, lançada em 19 de agosto de 2026. Clientes do Red Hat build of Keycloak (RHBK) devem instalar as correções disponibilizadas para as versões 26.4.15 e 26.6.6. Até 24 de agosto, não havia evidências de exploração da vulnerabilidade em ataques reais nem um exploit público verificado. Falha permite ignorar etapa de verificação De acordo com o alerta da Red Hat, a causa da CVE-2026-18963 está em uma validação inadequada de estado no fluxo reset-credentials, utilizado pelo Keycloak quando um usuário solicita a recuperação de sua senha. Normalmente, esse processo exige que o usuário valide sua identidade por meio de um token enviado por e-mail antes de definir uma nova senha. A vulnerabilidade permite que um atacante envie uma requisição especialmente criada para o endpoint responsável pela recuperação das credenciais. Com isso, a sessão de autenticação pode avançar diretamente para a etapa de atualização da senha, sem exigir o token que deveria ter sido enviado ao proprietário da conta. A exploração bem-sucedida pode resultar no comprometimento completo da conta por meio da definição de uma nova senha. Segundo a Red Hat, o problema pode atingir qualquer usuário, incluindo contas administrativas. A falha também não exige interação da vítima, um dos fatores que contribuíram para sua classificação como crítica. O impacto é particularmente relevante porque o Keycloak é utilizado como plataforma centralizada de Identity and Access Management (IAM), fornecendo autenticação e controle de acesso para aplicações e serviços. Dessa forma, o comprometimento de uma conta pode permitir acesso aos recursos protegidos pelas permissões associadas àquela identidade. Red Hat e Keycloak disponibilizam correções A Red Hat publicou quatro alertas de segurança em 18 de agosto — RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523 e RHSA-2026:56524 — cobrindo pacotes do servidor independente e imagens de contêiner das duas versões afetadas do RHBK. No Red Hat build of Keycloak 26.4, o problema está corrigido a partir do operator bundle 26.4.15-1. As imagens rhbk/keycloak-rhel9 e rhbk/keycloak-rhel9-operator receberam a correção na versão 26.4-23. Para o RHBK 26.6, a correção está disponível no operator bundle 26.6.6-1 e nos contêineres do Keycloak e do operador a partir da versão 26.6-12. No projeto upstream, a vulnerabilidade foi corrigida no Keycloak 26.7.2. Algumas informações sobre produtos relacionados permanecem indefinidas. O registro inicial da CVE apontava o Red Hat Single Sign-On 7 como não afetado e o Red Hat JBoss Enterprise Application Platform Expansion Pack como afetado. Uma revisão posterior modificou a relação de produtos, e as fontes publicadas não estabelecem claramente o status atual dessas plataformas. Também não está claro se todos os realms com a função de recuperação de senha habilitada podem ser explorados ou se determinadas configurações do fluxo reset-credentials são necessárias. Desativar “Forgot password” reduz o risco temporariamente Para organizações que não conseguem atualizar imediatamente, a Red Hat disponibilizou uma mitigação temporária: desabilitar a funcionalidade “Forgot password” em todos os realms. No console administrativo do RHBK, a opção pode ser encontrada em Realm settings, depois Login e Forgot password. A configuração precisa ser aplicada individualmente a todos os realms. A Red Hat ressalta, porém, que a medida é temporária e recomenda a instalação das versões corrigidas assim que possível. A CVE-2026-18963 está entre oito vulnerabilidades listadas como corrigidas no Keycloak 26.7.2. A mesma atualização solucionou a CVE-2026-15571, relacionada a um hash previsível no processo de vinculação de contas que pode permitir account takeover por meio de um cliente OpenID Connect (OIDC) malicioso. Duas semanas antes, em 5 de agosto, o Keycloak 26.7.1 já havia corrigido outras 12 CVEs. Entre os problemas estavam uma falha envolvendo login iniciado por um provedor de identidade SAML e uma política padrão de registro dinâmico de clientes que poderia permitir falsificação de funções por meio de mapeadores de propriedades de usuários. Separadamente, a Univention informou que sua plataforma Nubus não é afetada pela CVE-2026-18963 porque a funcionalidade de recuperação de senha não está habilitada em suas implementações do Keycloak. A Red Hat creditou James Paremain pela descoberta e comunicação da vulnerabilidade. As fontes publicadas até o momento não detalham se condições específicas de configuração são necessárias para a exploração nem apresentam uma avaliação independente sobre a eficácia completa da correção.

Pesquisadores da Kaspersky identificaram uma nova família de malware criada especificamente para infectar centrais multimídia automotivas baseadas em Android que utilizam firmware desenvolvido pela DoFun. A ameaça se espalhava pelo próprio mecanismo de atualização integrado aos dispositivos. Descoberta em junho de 2026, a campanha utiliza uma cadeia de múltiplos estágios para instalar malware capaz de executar fraude publicitária e transformar os dispositivos comprometidos em nós de uma botnet de proxy. “O malware se espalhou por meio dos atualizadores integrados ao firmware de centrais automotivas baseadas em Android”, explicou Dmitry Kalinin, pesquisador da Kaspersky. Segundo ele, este é o primeiro caso documentado de malware encontrado em uma central veicular utilizando uma cadeia de infecção criada especificamente para esse tipo de equipamento. A atividade foi atribuída com alta confiança ao MoYu Group, grupo anteriormente associado pela equipe Satori Threat Intelligence and Research, da HUMAN, à operação BADBOX, uma infraestrutura utilizada para fraude publicitária e criação de redes de proxies residenciais. Em julho de 2025, o Google entrou com uma ação judicial contra 25 indivíduos ou entidades não identificadas na China, acusados de operar a botnet BADBOX e sua infraestrutura. Centrais Android tornam-se novo alvo As centrais multimídia automotivas funcionam como hubs que combinam recursos de entretenimento, navegação e, dependendo do veículo, algum nível de integração com outras funções do automóvel. Esses dispositivos podem vir instalados de fábrica ou ser adicionados posteriormente em veículos mais antigos. Como muitas centrais utilizam Android, aplicativos originalmente desenvolvidos para smartphones e tablets podem ser executados nesses equipamentos — e o mesmo vale para códigos maliciosos compatíveis com a plataforma. Outro fator relevante é que alguns modelos possuem slot para cartão SIM e conexão própria com a internet, utilizada para navegação, serviços online e atualizações de software. De acordo com Kalinin, os métodos utilizados para distribuir malware nesse ecossistema estão se tornando cada vez mais variados, incluindo desde backdoors pré-instalados até aplicativos de IPTV comprometidos. No caso analisado pela Kaspersky, porém, os responsáveis pela campanha utilizaram um método mais sofisticado: o abuso da funcionalidade legítima de atualização de um aplicativo de sistema. A distribuição ocorreu através de mecanismos presentes no firmware de diferentes modelos de centrais Android equipadas com software da DoFun. Após a divulgação responsável, segundo a Kaspersky, o problema que permitia o abuso do mecanismo de distribuição foi corrigido. Aplicativo legítimo foi usado para distribuir o malware A cadeia de ataque começa em um aplicativo legítimo do sistema chamado TWCore, identificado pelo pacote com.tw.core. O software é responsável por coletar informações analíticas e atualizar os programas instalados na central multimídia. Para isso, recebe instruções através de um broker MQTT hospedado em um subdomínio de cardoor[.]cn e baixa arquivos APK destinados à instalação. Os arquivos recebidos são armazenados no diretório de cache externo do TWCore, dentro do caminho push/apk/. Segundo a investigação, os operadores da campanha conseguiram utilizar esse canal legítimo de atualização para enviar malware diretamente aos dispositivos. O primeiro componente malicioso identificado foi um dropper chamado JarService, desenvolvido para iniciar um loader e manter a cadeia de infecção em andamento enquanto tenta reduzir as chances de detecção. Depois de executado, o loader envia informações sobre o dispositivo comprometido para um servidor controlado pelos hackers através de uma requisição HTTP POST. O servidor responde fornecendo o endereço para o download da próxima etapa do ataque. Uma das URLs observadas apontava para 144.217.243[.]201/vr34der34/dex3.68.png. O nome do payload contém uma referência à sua versão, como dex3.68. Explorando essa característica, os pesquisadores conseguiram recuperar sete variantes diferentes do malware, incluindo versões anteriores a partir da 3.57. Malware funciona silenciosamente em segundo plano A cadeia termina com a instalação do malware como um aplicativo Android comum. No entanto, o programa não possui interface gráfica visível para o usuário e permanece funcionando silenciosamente em segundo plano. Por padrão, o malware envia uma requisição POST para o endpoint de comando e controle /cpc/api/task a cada 90 minutos, transmitindo informações sobre o dispositivo infectado e a versão atual de sua configuração. Caso a configuração esteja desatualizada, o servidor C2 responde fornecendo novos endereços de infraestrutura e caminhos utilizados nas futuras requisições HTTP. Se nenhuma atualização for necessária, o servidor envia identificadores numéricos de comandos, chamados pelos próprios operadores da campanha de productId. O trojan associa cada identificador às instruções correspondentes e armazena essas informações como objetos JSON serializados usando a API SharedPreferences do Android. Malware pode exibir anúncios e baixar novos códigos A ameaça possui suporte a nove comandos diferentes, utilizados para exibir anúncios indesejados, realizar fraude publicitária, interagir com recursos do sistema e baixar módulos maliciosos adicionais. O malware também coleta informações detalhadas sobre o dispositivo, incluindo resolução da tela, modelo da central, identificador da rede Wi-Fi conectada e endereço MAC. Entre os comandos identificados estão return, utilizado para recuperar valores armazenados no SharedPreferences, e copy, capaz de modificar o conteúdo da área de transferência. O comando http permite realizar requisições GET ou POST para recursos determinados pelos operadores, enquanto web abre endereços dentro de um WebView e permite executar código JavaScript arbitrário. Também foram identificados os comandos loadlib, loadlib2 e loadlib3. Alguns deles ainda não estavam totalmente implementados nas amostras analisadas, mas o loadlib2 permite baixar e executar código arbitrário a partir de uma URL. Outras funcionalidades incluem deeplink, para abrir URLs no navegador, e traceroute, utilizado para verificar a disponibilidade de recursos através de ICMP. Centrais infectadas podem integrar botnet de proxy Os pesquisadores observaram os operadores utilizando principalmente os comandos loadlib2 e http para baixar um módulo chamado zhima. Esse componente funciona como um proxy reverso e havia sido documentado anteriormente pela equipe Deepfield Emergency Response Team, da Nokia. O mesmo módulo foi identificado sendo distribuído seletivamente através de aplicativos de IPTV instalados em dispositivos Android TV de baixo custo. Com o proxy instalado, a conexão de internet do dispositivo comprometido pode ser utilizada como ponto de saída para tráfego de terceiros, permitindo que os operadores utilizem os equipamentos infectados como parte de uma infraestrutura de proxies residenciais. Esse tipo de rede pode ser explorado para mascarar a origem de diferentes atividades online, fazendo com que o tráfego pareça partir dos endereços IP legítimos dos próprios dispositivos infectados. Segundo a Kaspersky, a operação está relacionada à infraestrutura BADBOX, que já havia sido associada à infecção de diversos tipos de dispositivos Android conectados à internet. “Apesar dos esforços de especialistas em cibersegurança e autoridades para derrubar a botnet BADBOX, atores individuais associados a ela continuam suas atividades maliciosas, infectando dispositivos em todo o mundo”, afirmou Kalinin. Para o pesquisador, o caso representa um marco por demonstrar uma cadeia de infecção criada especificamente para centrais multimídia automotivas. A descoberta também amplia o conjunto de dispositivos Android utilizados por operações de fraude e botnets, mostrando que equipamentos instalados em veículos podem se tornar alvos quando possuem conectividade permanente, executam aplicativos comuns da plataforma e dependem de mecanismos remotos de atualização.

Pesquisadores da Check Point Research demonstraram uma técnica capaz de transformar um driver legítimo e assinado do Microsoft Defender em uma ferramenta para excluir arquivos, alterar o Registro do Windows e até remover componentes de segurança antes que o sistema operacional conclua sua inicialização. A técnica utiliza o BTR.sys, sigla para Boot Time Removal Tool, um driver empregado pelo próprio Defender para finalizar a remoção de ameaças após uma reinicialização. Segundo os pesquisadores, o método funciona em sistemas que vão do Windows 7 ao Windows 11 25H2, sem explorar uma vulnerabilidade tradicional e sem importar um driver malicioso ou vulnerável de terceiros. O pesquisador Jiří Vinopal, da Check Point Research, apresentou o trabalho durante a Black Hat USA 2026 e a DEF CON 34, em Las Vegas. O estudo e uma ferramenta de prova de conceito chamada BTR_CLI foram publicados em 20 de agosto de 2026. Até o momento, a Check Point afirma não ter encontrado evidências de que a técnica tenha sido utilizada em ataques reais. “Durante nossa análise de todas as amostras coletadas e fontes de telemetria, não observamos evidências de abuso do BTR.sys da maneira demonstrada nesta pesquisa”, informou a empresa. Segundo os pesquisadores, isso pode permitir que organizações desenvolvam mecanismos de detecção antes que a técnica eventualmente seja adotada por hackers. Driver legítimo do Defender pode executar operações no kernel O BTR.sys é incorporado ao arquivo MpEngine.dll do Microsoft Defender e utilizado quando o antivírus precisa excluir arquivos ou entradas de Registro que permanecem bloqueados enquanto o Windows está em execução. Ao analisar o funcionamento do driver, Vinopal identificou um protocolo proprietário e não documentado usado para enviar instruções ao BTR.sys. As configurações são protegidas com RC4 utilizando uma chave de 256 bytes armazenada diretamente no próprio driver. A pesquisa verificou que a mesma chave permaneceu inalterada em 18 versões diferentes de 64 bits analisadas desde o Windows 7. A ferramenta BTR_CLI localiza o MpEngine.dll dentro das atualizações de definições do Defender, extrai o BTR.sys incorporado e cria uma transação criptografada compatível com o formato esperado pelo driver. Em seguida, o código pode registrar o BTR.sys diretamente no Registro do Windows como um serviço de inicialização, sem utilizar o Service Control Manager. Segundo a pesquisa, esse procedimento também evita a geração do Windows Event ID 7045, normalmente associado à instalação de novos serviços. Depois de carregado, o driver executa as operações no Ring 0, nível mais privilegiado do sistema operacional, com a atividade atribuída ao processo System, de PID 4. Entre as ações demonstradas estão a exclusão de arquivos e diretórios bloqueados, movimentação de arquivos para caminhos como System32\drivers, remoção de chaves e valores do Registro e criação de novos valores de diferentes tipos. As operações também podem ser programadas para acontecer durante a próxima reinicialização. Defender pode ser removido antes de iniciar Um dos principais riscos está no momento em que o BTR.sys é executado durante o boot. Vinopal descreve esse período como uma “janela de ouro”: o sistema de arquivos já pode ser modificado, mas os serviços do Microsoft Defender em modo de usuário ainda não foram iniciados. Nesse intervalo, o driver pode excluir componentes de segurança antes que eles sejam carregados e bloqueados pelo próprio Windows. Durante uma demonstração na Black Hat, o BTR_CLI foi utilizado para remover a pilha do Defender de um computador totalmente atualizado com Windows 11 25H2, mesmo com o recurso Tamper Protection habilitado. Entre os componentes que podem ser atingidos estão arquivos como WdFilter.sys e MsMpEng.exe. A exploração, porém, exige que o atacante já possua uma conta administrativa com o privilégio SeLoadDriverPrivilege, necessário para carregar drivers no sistema. A ferramenta de prova de conceito apenas habilita automaticamente esse privilégio quando a conta já possui autorização para utilizá-lo. Técnica é diferente de ataques BYOVD O método se diferencia dos ataques conhecidos como Bring Your Own Vulnerable Driver, ou BYOVD, nos quais invasores carregam drivers legítimos, porém vulneráveis, de terceiros para executar operações privilegiadas no kernel. Esses drivers podem posteriormente ser adicionados a listas de bloqueio da Microsoft. No caso do BTR.sys, essa abordagem é mais complicada porque o componente faz parte do funcionamento legítimo do Microsoft Defender. Bloqueá-lo por meio da Microsoft Vulnerable Driver Blocklist ou do Windows Defender Application Control poderia interferir no próprio antivírus. A Check Point chama a técnica de “BTR Reforged” e destaca que o problema não representa uma vulnerabilidade convencional. Segundo a empresa, trata-se de uma fronteira de confiança arquitetural que pode ser ultrapassada quando um invasor já conquistou privilégios administrativos. Após a divulgação responsável, o Microsoft Security Response Center (MSRC) informou aos pesquisadores que o comportamento não atende aos critérios para uma correção imediata, justamente porque depende da existência prévia de privilégios administrativos, incluindo SeLoadDriverPrivilege. O repositório do BTR_CLI afirma que não existe correção planejada, mas a Microsoft não confirmou publicamente essa informação. BTR.sys já teve outra vulnerabilidade corrigida O driver do Defender já havia sido analisado anteriormente por pesquisadores de segurança. Em fevereiro de 2021, Kasif Dekel, da SentinelLabs, divulgou a CVE-2021-24092, uma vulnerabilidade de escalonamento de privilégios que permitia que um usuário local sem privilégios administrativos sobrescrevesse arquivos arbitrários utilizando um hard link no caminho de log empregado pelo driver. A Microsoft corrigiu a falha em 9 de fevereiro de 2021. Na ocasião, a SentinelLabs explicou que o BTR.sys era difícil de analisar porque normalmente não permanece armazenado de forma permanente no disco. O Defender instala e ativa o componente quando necessário, frequentemente com um nome aleatório, e depois o remove. O uso de drivers nativos do Windows como mecanismo ofensivo também já apareceu em outras campanhas. O grupo FIN7, por exemplo, utilizou o driver ProcLaunchMon.sys em conjunto com um driver do Process Explorer em uma ferramenta conhecida como AvNeutralizer para interferir em softwares de proteção de endpoints. Pesquisa começou durante resposta a incidente Segundo a Check Point, a investigação sobre o BTR.sys surgiu durante uma resposta a incidente em um sistema comprometido. Alguns eventos de telemetria inicialmente pareciam indicar comportamento malicioso, mas acabaram sendo relacionados a atividades legítimas de remediação do Microsoft Defender. A análise levou os pesquisadores a estudar de forma mais detalhada o mecanismo de operação do driver. A empresa também publicou indicadores que podem ajudar equipes de segurança a identificar possíveis abusos. Entre eles estão eventos do Sysmon relacionados à criação do fluxo alternativo .sys:changelist, utilizado para armazenar a configuração criptografada, e alterações no Registro criando serviços com referências a :changelist e ao grupo Boot Bus Extender, especialmente quando não existe um Windows Event ID 7045 correspondente. Outros sinais incluem a criação e exclusão rápida do arquivo \SystemRoot\Temp\BootClean.log pelo processo System, eventos de carregamento de driver seguidos imediatamente pela exclusão de arquivos e operações realizadas pelo PID 4. Como principal medida de proteção, a Check Point recomenda restringir ao máximo quais contas possuem o privilégio SeLoadDriverPrivilege. A ferramenta BTR_CLI foi disponibilizada publicamente no GitHub sob licença MIT, incluindo versões compiladas para arquiteturas x64 e x86.

A OpenAI anunciou o Private Safety Processing, um mecanismo desenvolvido para analisar automaticamente interações com seus modelos em busca de riscos de segurança sem comprometer os acordos de Zero Data Retention (ZDR), nos quais os dados dos clientes não são retidos pela empresa. A novidade é especialmente relevante para organizações que utilizam inteligência artificial com informações corporativas sensíveis e precisam limitar o armazenamento e o acesso humano aos prompts e respostas processados pelos modelos. Segundo a OpenAI, em implementações com ZDR, os clientes podem controlar sua própria infraestrutura ou optar pelo armazenamento na infraestrutura da empresa, que deverá oferecer também chaves de criptografia controladas pelo cliente. Nos dois casos, sistemas automatizados podem identificar possíveis usos indevidos e produzir sinais limitados de segurança sem expor os prompts ou respostas subjacentes aos funcionários da OpenAI. O Private Safety Processing amplia as proteções automatizadas já utilizadas em ambientes compatíveis com ZDR. Enquanto os mecanismos existentes analisam individualmente as interações, a nova tecnologia consegue avaliar padrões existentes entre interações relacionadas sem permitir que funcionários da empresa tenham acesso ao conteúdo retido dos clientes. Esse ponto pode indicar uma análise mais ampla do contexto das atividades realizadas pelos modelos, potencialmente envolvendo não apenas prompts e respostas, mas também interações com ferramentas e sinais relacionados à rede. A abordagem cria uma diferença em relação à política atualmente adotada pela Anthropic em alguns de seus modelos mais avançados. Segundo a empresa, clientes comerciais com ZDR que utilizam os modelos cobertos por sua política de segurança estão sujeitos à retenção de prompts e respostas por 30 dias para atividades relacionadas à segurança. De maneira geral, as duas empresas também possuem políticas de retenção para clientes comerciais fora dessas condições específicas. A Anthropic informa que entradas e saídas da API são normalmente excluídas de seus sistemas em até 30 dias, com algumas exceções. No ChatGPT Business, administradores podem controlar por quanto tempo os dados permanecem armazenados. Conversas excluídas ou não salvas são removidas dos sistemas da OpenAI em até 30 dias, salvo quando uma retenção maior for exigida por lei ou considerada necessária para proteger os serviços ou terceiros. Uma política semelhante de 30 dias é aplicada à API na maioria dos casos. Outra diferença está na possibilidade de revisão humana. A Anthropic informa que, por padrão, seus funcionários não podem ler conversas retidas, mas conteúdos sinalizados por sistemas automatizados de segurança podem passar por revisão humana através de um processo de acesso controlado. No modelo apresentado pela OpenAI para o Private Safety Processing, a intervenção humana é mais restrita. A empresa aponta como exceção situações envolvendo a detecção de material relacionado à exploração sexual infantil. A OpenAI afirma que divulgará mais detalhes técnicos sobre o funcionamento do Private Safety Processing no próximo mês. Até lá, aspectos específicos sobre a arquitetura e as proteções utilizadas pelo mecanismo ainda não foram detalhados. A preocupação com a privacidade no processamento de IA também aparece em iniciativas de outras grandes empresas de tecnologia. Apple, Google, Nvidia e Meta vêm desenvolvendo mecanismos destinados a proteger informações durante cargas de trabalho de inteligência artificial, enquanto a execução local de modelos também cresce como alternativa para organizações que não desejam enviar determinados dados para provedores externos. Ainda assim, mecanismos de processamento privado não eliminam todos os riscos. Matthew Green, professor associado de ciência da computação da Universidade Johns Hopkins, observa que agentes de IA conectados a ferramentas podem acessar informações sensíveis e executar ações externas. Nesse cenário, proteger apenas a inferência não necessariamente protege todo o fluxo de dados utilizado pelo agente.

Um pesquisador de segurança de 22 anos, conhecido como “Zerotistic”, conseguiu registrar um computador Linux na rede Find My da Apple e receber dados de localização em tempo real de pessoas que já haviam compartilhado sua posição com a conta utilizada no experimento. A técnica chama atenção porque os recursos completos do Find My são normalmente restritos a dispositivos da Apple, como iPhones e Macs. Pelo site do iCloud, a empresa oferece o Find Devices para localizar aparelhos, mas sem o recurso do Find My que permite visualizar a localização compartilhada por outras pessoas. O método desenvolvido por Zerotistic não permite rastrear arbitrariamente qualquer usuário da Apple. Para obter as informações, a pessoa precisa ter compartilhado previamente sua localização com o proprietário da conta Apple utilizada no dispositivo Linux. O principal desafio foi fazer os serviços da Apple reconhecerem a máquina Linux como um dispositivo autorizado e capaz de receber essas informações pelo Apple Push Notification service (APNs). Primeiro, o pesquisador vinculou o computador à sua conta Apple utilizando o protocolo de autenticação GrandSlam. Depois, buscou obter um certificado de dispositivo do Apple Identity Services (IDS), responsável por associar o aparelho a uma conta. Para isso, Zerotistic criou uma solicitação personalizada de assinatura de certificado (CSR). Após diversas tentativas, descobriu que precisava utilizar o formato PKCS#10, uma chave RSA de 2.048 bits e uma assinatura SHA-1. Os dados foram incorporados a um arquivo XML compactado e enviados ao endpoint legado authenticateDS da Apple. A Apple assinou a solicitação e forneceu ao computador Linux o certificado IDS necessário para registrar sua chave pública na conta. Segundo o pesquisador, a exigência de SHA-1 e da codificação XML provavelmente está relacionada ao fato de o authenticateDS utilizar padrões mais antigos. Registrar o computador, entretanto, não era suficiente para fazê-lo funcionar como um dispositivo compatível com o Find My. O pesquisador descobriu que a solicitação precisava assinar seis subserviços diferentes, informar os mecanismos de criptografia suportados e fornecer chaves públicas utilizadas no sistema de comunicação entre dispositivos da Apple. A solicitação também precisava ser assinada com certificados IDS e APNs obtidos durante a configuração inicial. Com essas etapas concluídas, a máquina Linux conseguiu manter uma conexão TLS binária persistente com os servidores privados de APNs da Apple e passou a ser reconhecida como capaz de receber dados do Find My. Mesmo assim, as localizações previamente compartilhadas não apareceram automaticamente. Zerotistic então enviou uma solicitação chamada SubscribeAndFetch, fazendo com que o dispositivo de um amigo enviasse uma chave de localização criptografada para a máquina Linux recém-registrada. O último desafio foi interpretar as informações recebidas pelo serviço SearchParty da Apple. Como não havia um aplicativo gráfico do Find My sendo executado no Linux, o pesquisador precisou desenvolver um script capaz de processar o formato de mensagens da Apple, extrair a chave compartilhada e descriptografar os dados. Após a descriptografia, foi possível acessar informações como coordenadas geográficas, horário do registro e precisão da localização. O script também conseguiu buscar e decodificar atualizações posteriores referentes ao compartilhamento já autorizado. Segundo Zerotistic, todo o processo de pesquisa e desenvolvimento da técnica levou menos de uma semana. A descoberta demonstra que, apesar das restrições oficiais do Find My, um dispositivo que não pertence ao ecossistema Apple pode ser configurado para interagir com os protocolos utilizados pelo serviço. Até a publicação da reportagem original, a Apple não havia informado se pretende realizar alterações em resposta à pesquisa.

O Thunderbird passará a receber novas versões a cada duas semanas a partir de setembro, acompanhando a aceleração do ciclo de atualizações do Firefox. A mudança reduz pela metade o intervalo atual de quatro semanas entre os lançamentos regulares do cliente de e-mail. Mozilla e sua subsidiária MZLA lançaram nesta semana o Firefox 154 e o Thunderbird 154. Para usuários e empresas que preferem maior estabilidade e menos atualizações, as versões 153 permanecem como as atuais edições ESR (Extended Support Release), com suporte prolongado pelo próximo ano. O novo cronograma acompanha a decisão da Mozilla de atualizar o Firefox quinzenalmente. Segundo Corey Bryant, da MZLA, o Thunderbird seguirá a mesma cadência a partir de setembro. Além da mudança no calendário, o Thunderbird 154 recebeu novos recursos importantes, principalmente para ambientes corporativos. Entre eles está o suporte ao Microsoft Graph para contas do Microsoft 365, permitindo que o cliente utilize a API da Microsoft para interagir com os serviços da plataforma. A integração ganha relevância diante da descontinuação do Exchange Web Services (EWS) nos serviços em nuvem da Microsoft. O EWS continuará disponível para organizações que mantêm seus próprios servidores Exchange, mas o Graph passa a ser uma alternativa importante para usuários do Microsoft 365. O Thunderbird 154 também melhora o tratamento de mensagens criptografadas com Cryptographic Message Syntax (CMS), além das funções de arrastar e soltar e de copiar mensagens e anexos por meio do menu de contexto. No macOS, a visualização de anexos também foi aprimorada. Outra mudança permite minimizar o Thunderbird para a bandeja do sistema quando sua última janela é fechada, nos ambientes de desktop que oferecem esse recurso. A versão também melhora o comportamento durante interrupções de conexão em grandes operações IMAP. Isso pode ser especialmente útil durante a transferência ou o backup de grandes quantidades de mensagens, reduzindo problemas quando a conexão com a internet é interrompida durante o processo. Na área de segurança, a atualização inclui mais de 50 correções, além de mais de 30 ajustes para outros bugs. Como um cliente de e-mail diretamente exposto a conteúdos recebidos pela internet, manter as correções de segurança atualizadas é particularmente importante. Com a adoção de lançamentos quinzenais, usuários da versão regular do Thunderbird receberão recursos, correções de bugs e atualizações de segurança com maior frequência. Quem busca um ciclo mais previsível poderá continuar utilizando a edição ESR.

O US Bank está investigando alegações do grupo de ransomware LockBit de que hackers teriam invadido a instituição financeira e roubado dados. O grupo estabeleceu 3 de setembro como prazo para o pagamento de um resgate e ameaça publicar as informações caso sua exigência não seja atendida. Até o momento, porém, o suposto ataque não foi confirmado pelo banco. Lee Henderson, vice-presidente de relações públicas do US Bank, afirmou que a instituição está ciente das alegações envolvendo um possível incidente de cibersegurança. “Até o momento, não há indicação de que nossos sistemas internos tenham sido afetados e não há evidências de acesso não autorizado à nossa rede”, informou Henderson. O banco disse que continua investigando e monitorando as alegações. O US Bank não respondeu a perguntas específicas sobre o caso, incluindo se manteve contato com os responsáveis pela extorsão ou qual seria o valor do resgate exigido. O LockBit adicionou o banco ao seu site de vazamentos na noite de quarta-feira e concedeu um prazo de 14 dias para o pagamento. A publicação do grupo não informa quantos arquivos teriam sido roubados nem qual seria o conteúdo dos supostos dados em sua posse. Mesmo quando uma vítima paga o resgate, não há garantia de que os dados roubados sejam realmente apagados. Em 2024, durante uma operação internacional contra a infraestrutura do LockBit, autoridades encontraram evidências de que o grupo havia mantido informações de vítimas mesmo após o pagamento das exigências de extorsão. A operação realizada em fevereiro de 2024 apreendeu servidores, domínios e chaves de descriptografia utilizados pelo LockBit. Em maio daquele ano, autoridades identificaram o russo Dmitry Yuryevich Khoroshev como LockBitSupp, apontado como uma das principais figuras por trás da operação. Ele permanece foragido. Apesar das ações policiais, o LockBit voltou a aparecer em setembro de 2025 com a variante LockBit 5.0 de seu ransomware. A nova alegação ocorre após outros incidentes envolvendo dados de clientes do US Bank por meio de terceiros. Um escritório de advocacia avalia uma possível ação coletiva relacionada a um incidente que teria atingido a instituição por meio da fornecedora Fidelity National Information Services. O US Bank teria tomado conhecimento desse incidente em 7 de maio e começou, em junho, a notificar 537 clientes de Massachusetts. Nomes, endereços postais e números de cartões de crédito podem ter sido comprometidos. Segundo as informações divulgadas, números de Seguro Social, credenciais de internet banking e saldos das contas não foram acessados. Outro incidente, ocorrido em 2022, afetou aproximadamente 11 mil clientes depois que um fornecedor compartilhou acidentalmente um arquivo relacionado a contas de cartões de crédito já encerradas. O documento continha informações como nomes, endereços, números de Seguro Social, datas de nascimento, números de contas encerradas e saldos pendentes.

O papel do Chief Information Security Officer (CISO) deve passar por uma transformação significativa nos próximos anos. Até 2029, executivos de segurança tendem a assumir responsabilidades mais amplas sobre riscos corporativos, inteligência artificial e inovação, deixando de atuar apenas como responsáveis pela defesa tecnológica para participar diretamente das decisões estratégicas das organizações. Wolfgang Goerlich, CISO do setor público e membro do corpo docente da IANS Research, acredita que esses profissionais serão cada vez mais responsáveis por orientar empresas sobre como assumir riscos tecnológicos de maneira calculada, incluindo aqueles relacionados à adoção de IA. Para Goerlich, essa mudança representa mais uma etapa na evolução de uma função que existe desde 1995. O CISO deixou de representar o chamado “departamento do não”, passou pela fase de tentar desacelerar iniciativas consideradas arriscadas e agora começa a assumir uma posição na qual ajuda a organização a entender e administrar riscos para avançar com novos projetos. Essa perspectiva também aparece em um relatório da KPMG de 2026, segundo o qual o papel do CISO está sendo redefinido à medida que plataformas digitais, inteligência artificial e ecossistemas de terceiros aceleram as mudanças tecnológicas. Além de proteger os ambientes corporativos, os líderes de segurança passam a responder cada vez mais por riscos em nível empresarial. Nesse cenário, o CISO deve evoluir de um especialista predominantemente técnico para um líder capaz de traduzir ameaças complexas em riscos e impactos para os negócios. A expectativa é que ele funcione como um facilitador da inovação segura, permitindo que empresas adotem novas tecnologias com maior velocidade sem ignorar os riscos envolvidos. Goerlich afirma que essa transformação já está acontecendo. Em sua atuação atual, ele recebeu a responsabilidade de estruturar uma equipe de inovação formada por profissionais de arquitetura, engenharia e segurança. Segundo ele, CEOs e conselhos de administração começam a perceber que envolver segurança na liderança das iniciativas pode acelerar a inovação, em vez de simplesmente criar obstáculos. Até 2029, alguns CISOs também poderão assumir responsabilidades sobre riscos corporativos de maneira mais ampla, além dos riscos estritamente cibernéticos. Essa evolução, entretanto, não deverá ocorrer de forma uniforme: algumas organizações continuarão mantendo CISOs mais técnicos e operacionais, enquanto outras ampliarão sua participação nas decisões estratégicas. Diana Kelley, CISO da Noma Security, observa uma mudança semelhante. Para ela, os CISOs estão deixando de atuar principalmente como responsáveis por defesa e conformidade para se tornarem facilitadores da estratégia empresarial, ajudando a aumentar a resiliência das organizações. Ao mesmo tempo, o avanço da IA exigirá conhecimento técnico suficiente para questionar decisões de arquitetura e compreender como novas tecnologias estão sendo implementadas. Isso não significa que o CISO precisará atuar diretamente na operação dos sistemas, mas deverá ser capaz de avaliar tecnicamente como aplicações e infraestruturas podem ser governadas e protegidas durante sua execução. Kelley considera ainda a possibilidade de organizações adotarem dois perfis diferentes de liderança em segurança: um mais concentrado nas defesas tecnológicas e outro dedicado a risco e resiliência. A ampliação das responsabilidades também pode alterar os próprios cargos. Edna Conway, ex-CSO e ex-chief security and risk officer da infraestrutura do Azure na Microsoft, defende que CISOs avancem além dos riscos de segurança da informação e assumam uma visão de risco empresarial. Nesse modelo, títulos como chief security and trust officer ou chief security and risk officer poderiam se tornar mais comuns, embora Conway não tenha certeza de que essa transformação estará consolidada já em 2029. Outro fator será a velocidade das mudanças. Ali Waezzadah, CISO da iCOUNTER, aponta que transformações na infraestrutura de TI, geopolítica, economia, regulamentação e estratégias corporativas estão tornando o ambiente cada vez mais dinâmico. Novas tecnologias são implantadas mais rapidamente, enquanto invasores desenvolvem continuamente novas técnicas. Isso exigirá líderes mais ágeis e flexíveis, capazes de acompanhar simultaneamente mudanças tecnológicas, regulatórias e empresariais. Até 2029, segundo Waezzadah, os CISOs terão mais elementos para monitorar e um ambiente de proteção muito mais dinâmico. A inteligência artificial deverá acelerar ainda mais essa transformação. John White, field CISO da Torq, acredita que os departamentos de segurança precisarão operar em velocidades maiores à medida que empresas e adversários ampliem o uso de IA. Nesse modelo, agentes de IA poderão executar parte das atividades enquanto profissionais humanos definem objetivos, supervisionam operações e tomam decisões. O CISO passaria a administrar equipes compostas por pessoas e sistemas automatizados, aproximando a segurança de um modelo orientado a produtos e resultados empresariais. Andrew Obadiaru, CISO da Cobalt, também prevê que o cargo será mais empresarial do que técnico até 2029. Entre as principais responsabilidades estarão permitir a adoção segura de IA, administrar riscos da cadeia de fornecimento de software e validar continuamente a postura de segurança da organização. Para Obadiaru, três prioridades devem ganhar destaque: validação contínua da exposição da empresa, adoção segura de IA e aceleração da correção de vulnerabilidades e outros riscos identificados. Com ataques e descobertas de vulnerabilidades acontecendo cada vez mais rapidamente, CISOs também deverão dedicar menos tempo à análise individual de achados técnicos e mais à criação de processos automatizados de decisão, práticas de engenharia resilientes e modelos de governança capazes de responder na velocidade das máquinas. Apesar das transformações, a missão central permanece: compreender riscos, comunicá-los de maneira eficiente e ajudar a organização a tomar decisões informadas para preservar sua capacidade de operar. Tecnologias e modelos de segurança podem mudar, mas liderança, confiança, julgamento e comunicação continuarão sendo competências essenciais para o CISO.

Imagem meramente ilustrativa A Microsoft ampliou as funções do Gerenciador de Tarefas do Windows para oferecer mais visibilidade sobre workloads de inteligência artificial. A ferramenta agora pode mostrar a utilização da NPU (Unidade de Processamento Neural) por processo em computadores compatíveis, permitindo identificar quais aplicativos estão utilizando hardware dedicado à execução de tarefas de IA. Até então, a aba Processos não apresentava individualmente a atividade da NPU nem do mecanismo neural da GPU. Com a atualização, essas informações passam a aparecer ao lado de métricas tradicionais, como utilização de CPU e GPU. Já a aba Desempenho permite acompanhar o uso geral desses componentes. A novidade é voltada principalmente para computadores mais recentes equipados com NPUs, chips especializados na aceleração de operações de inteligência artificial. Esse tipo de hardware ganhou espaço nos chamados AI PCs e pode executar determinadas cargas de IA localmente com maior eficiência energética do que processadores convencionais. Segundo a Microsoft, à medida que aplicações de IA se tornam mais comuns no Windows, acompanhar o uso da NPU e dos mecanismos neurais das GPUs pode ajudar usuários e desenvolvedores a tomar decisões mais informadas sobre o funcionamento do sistema. As novas métricas também podem ser úteis para investigar problemas de desempenho e consumo de energia. Em notebooks, por exemplo, identificar qual processo está utilizando intensivamente uma NPU, GPU ou CPU pode ajudar a descobrir aplicações responsáveis por consumo elevado de recursos ou redução da autonomia da bateria. Com isso, o Gerenciador de Tarefas passa a reunir informações sobre processamento de IA com os indicadores já disponíveis de CPU, memória, armazenamento, rede e GPU, oferecendo uma visão mais detalhada sobre como os recursos de hardware estão sendo utilizados. A ampliação, porém, também levanta questionamentos sobre o aumento da complexidade de uma ferramenta historicamente conhecida por sua rapidez e simplicidade. Funções mais avançadas de análise do sistema tradicionalmente ficam concentradas em ferramentas como o Monitor de Desempenho do Windows. O movimento lembra a evolução de outros aplicativos tradicionais do sistema. O Bloco de Notas, originalmente desenvolvido como um editor extremamente simples, recebeu diversos recursos ao longo dos anos e mais recentemente ganhou funcionalidades baseadas em inteligência artificial. Para desenvolvedores e profissionais que trabalham com aplicações de IA, a possibilidade de visualizar o consumo da NPU por processo pode ser particularmente útil. Para os demais usuários, o benefício dependerá de a Microsoft conseguir ampliar as informações disponíveis sem comprometer a simplicidade que tornou o Gerenciador de Tarefas uma das ferramentas mais utilizadas para diagnóstico do Windows.

Pesquisadores de segurança da Cycode identificaram uma cadeia de vulnerabilidades no AIT-GUI, console web utilizado pelo AMMOS Instrument Toolkit (AIT), projeto de código aberto da NASA/JPL para construção de sistemas terrestres de suporte a instrumentos e espaçonaves. As falhas podem permitir que um atacante com acesso ao serviço envie comandos arbitrários sem autenticação. A cadeia foi registrada como GHSA-p9r8-2q67-fp86, recebeu pontuação 9,4 no CVSS v3.1 e, segundo o alerta publicado em 13 de agosto de 2026, afeta o AIT-GUI 2.5.1 e versões anteriores. A versão 2.5.2 foi apresentada como correção, embora análises posteriores tenham identificado limitações nessa mitigação. O AMMOS Instrument Toolkit fornece componentes para sistemas terrestres responsáveis por enviar comandos a instrumentos e espaçonaves e processar a telemetria recebida. O AIT-GUI funciona como console de operação, com endpoints capazes de encaminhar instruções diretamente ao barramento de comandos. Segundo a Cycode, o servidor web do AIT-GUI ignorava o endereço de host configurado e, por padrão, escutava em 0.0.0.0 na porta 8080, ficando acessível por todas as interfaces de rede. Ao mesmo tempo, rotas capazes de alterar o estado do sistema eram expostas sem autenticação, autorização ou proteção contra Cross-Site Request Forgery (CSRF). Duas dessas rotas também construíam caminhos no sistema de arquivos a partir de entradas sem validação adequada. Os problemas foram classificados como CWE-306, referente à ausência de autenticação para uma função crítica; CWE-352, relacionada a CSRF; e CWE-22, associada a path traversal. De acordo com o alerta, um atacante não autenticado capaz de alcançar a porta poderia enviar comandos para instrumentos e espaçonaves por meio de POST /cmd, executar scripts no servidor através de POST /script/run e iniciar sequências de comandos usando POST /seq. Em determinadas versões, o path traversal também permitiria referenciar arquivos fora dos diretórios previstos. O risco não se limita necessariamente a consoles diretamente expostos à internet. Como as rotas aceitam requisições application/x-www-form-urlencoded, consideradas solicitações simples pelos navegadores, uma página controlada por um atacante poderia enviar uma requisição cross-origin sem a verificação preliminar CORS conhecida como preflight. Na prática, isso significa que mesmo uma implantação restrita à rede local ou protegida por firewall poderia ser atacada caso um operador com acesso ao console visitasse uma página maliciosa. A Cycode afirma ter confirmado em tráfego real de navegador que as requisições POST eram entregues e processadas sem uma solicitação OPTIONS anterior. O AIT-GUI 2.5.2 foi lançado em 12 de agosto com mudanças destinadas a reduzir a superfície de ataque. A versão passou a respeitar o host configurado, usando localhost como padrão, adicionou verificações de mesma origem para requisições POST, PUT, DELETE e PATCH e restringiu os caminhos utilizados pelas funções /script/run e /seq aos diretórios configurados. No entanto, uma análise do código da versão 2.5.2 feita pelo The Hacker News encontrou uma limitação importante: a atualização não adiciona autenticação propriamente dita aos endpoints de comandos, scripts e sequências. A rota principal ainda chama Sessions.create() e fornece um cookie de sessão sem verificar credenciais, enquanto a rota de comandos aceita requisições que apresentem esse cookie. Assim, a versão 2.5.2 restringe onde o console fica disponível e bloqueia ataques cross-origin originados de navegadores, mas não implementa uma camada de autenticação para essas funções críticas. Também há divergências sobre quais versões estão corrigidas. Uma vulnerabilidade relacionada ao mesmo problema de ausência de autenticação já havia sido registrada como CVE-2026-60112, com pontuação 9,3 no CVSS v4. O registro afirma que versões anteriores à 2.5.1 são vulneráveis e aponta uma correção específica, enquanto a análise da Cycode inclui a própria 2.5.1 entre as versões afetadas e considera a 2.5.2 como corrigida. A inspeção do repositório indica, porém, que a criação de sessões sem autenticação permanece presente tanto na 2.5.1 quanto na 2.5.2. Também existem diferenças relacionadas ao path traversal: embora o alerta da Cycode indique que a versão 2.5.1 foi usada para validar as descobertas, o código dessa versão já contém uma verificação para restringir caminhos utilizados por /script/run; o problema sem essa restrição permanece em /seq. Outro ponto de atenção envolve a distribuição pelo PyPI. Em 20 de agosto, a versão mais recente do pacote ait-gui disponível na plataforma ainda era a 2.4.1, publicada em julho de 2023. As versões 2.5.0, 2.5.1 e 2.5.2 não apareciam no histórico de releases. O código da 2.4.1 contém tanto o bind em 0.0.0.0 quanto a construção de caminhos sem as restrições posteriores. A correção associada à pesquisa foi criada em julho pelo pesquisador Yuval Elbar e adicionou 18 testes de regressão. O commit também registra o uso do Claude Opus 4.8, da Anthropic, como coautor, e a Cycode afirma que a descoberta resultou de uma investigação humana apoiada por análise de código com inteligência artificial. Apesar da gravidade potencial, não há evidências apresentadas de exploração das vulnerabilidades em ataques reais. Os registros também não identificam nenhuma missão espacial específica utilizando uma implantação vulnerável do software. O AIT possui ainda outros registros de segurança. Entre eles está a CVE-2024-35058, vulnerabilidade crítica de execução remota de código na função API wait do NASA AIT-Core, publicada em 2024 e indicada como afetando versões até a 2.5.2, sem uma versão corrigida registrada atualmente no GitHub Advisory Database.

Pesquisadores de segurança da Hunt.io identificaram uma campanha que teria comprometido mais de 14.530 dispositivos Dahua entre 17 de junho e 22 de julho de 2026. Batizada de Operation CameraSwarm, a operação combinou ataques contra credenciais, exploração de duas vulnerabilidades de bypass de autenticação e uma técnica de conexão peer-to-peer (P2P). A investigação foi reconstruída a partir de um diretório de trabalho de 407 MB que ficou exposto e continha 2.616 arquivos distribuídos em 234 subdiretórios. O material incluía ferramentas, logs, histórico de comandos e registros da campanha. Segundo a Hunt.io, os comprometimentos confirmados estavam concentrados principalmente na Ucrânia e na Rússia. Os pesquisadores afirmam que 1.923 câmeras receberam uma conta persistente durante a operação, enquanto outras 283 foram alcançadas por meio do mecanismo P2P. No entanto, esses números são atribuídos à Hunt.io e não foram confirmados de forma independente por Dahua, ITRES Labs ou por um órgão público de resposta a incidentes. De acordo com a análise, os mais de 14,5 mil dispositivos foram identificados por três caminhos de ataque. O maior deles envolveu ataques contra credenciais, com 12.324 endereços IP únicos encontrados em 13.229 registros da campanha. Outros 1.923 dispositivos teriam sido acessados por meio das vulnerabilidades CVE-2021-33044 e CVE-2021-33045, enquanto 283 câmeras foram identificadas pelo número de série e alcançadas pelo mecanismo P2P, inclusive equipamentos posicionados atrás de NAT. As CVE-2021-33044 e CVE-2021-33045 são falhas de bypass de autenticação divulgadas em 2021 que afetam câmeras e outros produtos da Dahua. A fabricante atribui pontuação CVSS 8,1 às vulnerabilidades, enquanto o National Vulnerability Database (NVD) dos Estados Unidos atualmente classifica ambas com nota 9,8. Segundo a Dahua, as vulnerabilidades permitem contornar a autenticação de identidade do dispositivo por meio da construção de pacotes de dados maliciosos. A CVE-2021-33044 pode ser acionada durante a autenticação com um cliente do tipo NetKeyboard, enquanto a CVE-2021-33045 envolve uma solicitação de login em loopback utilizando o endereço 127.0.0.1. Até 19 de agosto de 2026, as duas falhas continuavam presentes no catálogo Known Exploited Vulnerabilities (KEV), da agência americana CISA. A recomendação é aplicar as medidas de mitigação disponibilizadas pelo fornecedor ou interromper o uso dos produtos caso não existam correções disponíveis. A campanha também chama atenção pelo uso da infraestrutura P2P da Dahua para alcançar equipamentos que não estavam diretamente expostos à internet. Uma investigação anterior da ITRES Labs mostrou que, em firmwares anteriores a meados de 2024, um número de série válido poderia ser utilizado para estabelecer uma rota pelo Easy4IP antes de o próprio dispositivo realizar a verificação de credenciais. Esse mecanismo permite tornar acessíveis câmeras ou gravadores de vídeo localizados atrás de NAT por meio da infraestrutura de relay da fabricante. Isso, porém, não significa necessariamente acesso autenticado ao equipamento: depois que o túnel é estabelecido, o dispositivo ainda pode exigir credenciais válidas. A Hunt.io afirma que o código recuperado dos operadores registrou que 89,4% dos números de série ativos testados retornaram um canal aberto sem autenticação. Esse percentual também deve ser tratado como um dado específico da campanha, já que não foi reproduzido independentemente pela ITRES Labs, Dahua ou por um CERT público até 19 de agosto. Os pesquisadores ressaltam ainda que o comportamento P2P não deve ser confundido com as vulnerabilidades CVE-2021-33044 e CVE-2021-33045. Da mesma forma, outras duas CVEs encontradas nas ferramentas recuperadas não descrevem esse mecanismo: a CVE-2024-39943 corresponde a uma falha de injeção de comandos no Rejetto HFS, enquanto a CVE-2025-31702 é descrita pela Dahua como uma vulnerabilidade de escalonamento de privilégios que exige credenciais previamente obtidas de um usuário comum. A ITRES Labs classificou a exposição relacionada ao relay por número de série como um problema sem CVE e informou que seus testes apontaram reforços no mecanismo P2P em firmwares lançados após meados de 2024. Como medidas de proteção, administradores devem atualizar os dispositivos com firmware disponibilizado pela Dahua, desabilitar o P2P quando o recurso não for necessário, restringir a conectividade Easy4IP quando apropriado, utilizar credenciais fortes e exclusivas, remover contas sem uso e manter os sistemas de videomonitoramento segmentados da infraestrutura corporativa. A Hunt.io também encontrou artefatos em russo no diretório recuperado e descreveu o operador como falante do idioma. A campanha, porém, não foi atribuída a um grupo hacker conhecido, ao governo russo ou a qualquer outra organização específica. Com confiança moderada, os pesquisadores avaliam que partes das ferramentas podem ter sido desenvolvidas para transferir o acesso às câmeras para terceiros. Até 19 de agosto, os números de mais de 14.530 dispositivos comprometidos, 1.923 contas persistentes, 283 acessos via P2P e a taxa de 89,4% de canais abertos permaneciam atribuídos à investigação da Hunt.io. Fontes públicas corroboram a existência das duas vulnerabilidades antigas de autenticação e o funcionamento do mecanismo P2P baseado em números de série, mas não confirmam de forma independente os totais associados à Operation CameraSwarm.