Uma vulnerabilidade de alta gravidade no Zimbra Collaboration (ZCS) está sendo explorada ativamente por invasores para executar comandos remotamente em servidores vulneráveis sem necessidade de autenticação, segundo um alerta do CERT Polska. A falha, identificada como CVE-2026-73570, recebeu pontuação 8,9 no CVSS e é classificada como uma vulnerabilidade de injeção de comandos que pode resultar em execução remota de código (RCE). O problema afeta versões do Zimbra Collaboration anteriores à 10.1.20 em ambientes onde o pacote opcional zimbra-snmp está instalado e as notificações SNMP estão habilitadas. Segundo a descrição publicada no National Vulnerability Database (NVD), a vulnerabilidade é causada pela sanitização inadequada de dados não confiáveis durante o processamento das notificações SNMP. Ataque pode começar por uma requisição SMTP Um invasor não autenticado pode enviar requisições SMTP especialmente preparadas ao servidor vulnerável. A entrada maliciosa pode chegar ao processamento das notificações SNMP e resultar na execução arbitrária de comandos do sistema operacional com os privilégios do usuário Zimbra. Isso significa que o atacante não precisa possuir previamente credenciais válidas de uma conta do Zimbra para tentar explorar a vulnerabilidade. A Zimbra corrigiu o problema no mês passado com o lançamento do Zimbra Collaboration 10.1.20. Organizações que utilizam versões anteriores e possuem o zimbra-snmp com notificações SNMP habilitadas devem atualizar os servidores. CERT Polska confirma exploração ativa Em um alerta publicado nesta semana, o CERT Polska informou ter identificado tentativas de exploração da CVE-2026-73570 e recomendou que administradores procurem possíveis sinais de comprometimento. Entre as verificações recomendadas está a análise do arquivo: /var/log/zimbra.log Os administradores devem procurar reinicializações suspeitas dos serviços do Zimbra e verificar arquivos criados nos últimos 30 dias nos seguintes diretórios: /opt/zimbra/jetty/webapps/ /opt/zimbra/jetty_base/webapps/ /tmp/ Arquivos inesperados nesses locais podem ajudar as equipes de segurança a identificar atividades relacionadas à exploração ou etapas posteriores de um comprometimento. A Cybersecurity and Infrastructure Security Agency (CISA) dos Estados Unidos adicionou a CVE-2026-73570 ao catálogo Known Exploited Vulnerabilities (KEV) em 21 de agosto, confirmando que existem evidências de exploração da vulnerabilidade. Com a inclusão no catálogo, órgãos civis do Poder Executivo Federal dos Estados Unidos foram obrigados a aplicar as correções até 24 de agosto de 2026. A entrada no KEV aumenta a prioridade para organizações que ainda operam instalações vulneráveis do Zimbra, principalmente servidores de e-mail expostos à internet. Servidores Zimbra continuam na mira de hackers A CVE-2026-73570 é mais um caso recente de vulnerabilidades no Zimbra utilizadas em ataques reais. No mês passado, o governo dos Estados Unidos divulgou detalhes de uma campanha de phishing atribuída ao grupo ligado à Rússia Laundry Bear, também rastreado como CL-STA-1114, TA488, UNK_PitStop e Void Blizzard. A operação vinha mirando servidores Zimbra pertencentes a organizações governamentais e comerciais ocidentais desde pelo menos julho de 2025. Nesse caso, os invasores exploraram a CVE-2025-66376, uma vulnerabilidade de cross-site scripting (XSS) armazenado na interface Classic do Zimbra. A falha foi utilizada para entregar um payload JavaScript chamado ZimReaper, desenvolvido para coletar comunicações por e-mail e outros dados sensíveis. Com a CVE-2026-73570 agora sob exploração ativa, administradores devem priorizar a atualização para uma versão corrigida e revisar os servidores em busca de indicadores de comprometimento, especialmente quando o pacote zimbra-snmp estiver instalado e as notificações SNMP estiverem habilitadas.

Um ataque investigado pela Huntress mostrou como hackers podem explorar funcionalidades legítimas de bancos de dados Oracle para executar código e roubar credenciais, mesmo em ambientes que estivessem com todas as atualizações de segurança disponíveis instaladas. O caso chama atenção porque ocorreu no mesmo período em que a Oracle publicou uma atualização com 1.449 patches de segurança. Segundo Craig Savage, líder de cibersegurança da Spinnaker Support, nenhuma dessas correções teria impedido o ataque descrito pela Huntress, já que a invasão não dependia de uma vulnerabilidade corrigida pela fabricante. A atividade foi identificada em julho, após a Huntress receber um alerta relacionado ao roubo de credenciais. O acesso inicial ocorreu por meio de uma vulnerabilidade de SQL Injection em uma aplicação web pública de uma organização não identificada. Depois de obter acesso, os invasores adotaram uma técnica menos comum. Eles implantaram um toolkit de pós-exploração chamado khunt por meio de código Java carregado diretamente dentro do banco de dados Oracle. A técnica é possível porque o Oracle Database possui uma Java Virtual Machine (JVM) integrada e permite armazenar código-fonte Java como um objeto do banco. No incidente, os invasores enviaram comandos CREATE JAVA SOURCE a partir de um servidor Tomcat, utilizando a conexão existente com o banco de dados. O código malicioso foi então compilado diretamente dentro do Oracle Database e armazenado como um objeto de esquema. Segundo a Huntress, abordagens semelhantes já haviam sido descritas anteriormente, inclusive por meio de uma técnica conhecida como oraexec, mas seu uso documentado em ataques reais permanece incomum. Savage destacou que a capacidade de criar e executar programas Java dentro do banco é uma funcionalidade legítima da plataforma Oracle, mas não deveria estar disponível para um servidor web em um ambiente de produção. Segundo o especialista, a execução de Java deveria ser restrita ao usuário DBA, enquanto a capacidade de compilar código deveria permanecer desabilitada em servidores de produção e ser habilitada apenas durante períodos controlados de desenvolvimento ou manutenção. Nesse cenário, mesmo que os invasores conseguissem enviar o código Java ao banco, o ambiente não estaria configurado para compilá-lo. Savage classificou o ambiente atacado como mal configurado e inadequadamente protegido, ressaltando que o incidente não representa uma violação da infraestrutura da Oracle. O ataque também indica uma mudança relevante nas técnicas adotadas por grupos de cibercrime. Em vez de depender exclusivamente da exploração de vulnerabilidades de software, os invasores estão aprendendo como produtos corporativos funcionam e identificando funcionalidades legítimas que podem ser abusadas quando permanecem habilitadas ou configuradas de forma insegura. O caso mostra que a aplicação de patches continua sendo uma medida essencial, mas não elimina riscos relacionados à configuração e ao controle de privilégios. No incidente investigado pela Huntress, restringir a execução e compilação de código Java no banco poderia ter interrompido a cadeia de ataque.

A atualização cumulativa do .NET Framework lançada pela Microsoft em agosto de 2026 está causando falhas de impressão e na geração de arquivos PDF e XPS em alguns aplicativos baseados no Windows Presentation Foundation (WPF). Segundo a Microsoft, após a instalação da atualização de agosto, determinados aplicativos WPF podem apresentar uma exceção System.IO.FileFormatException ao imprimir ou gerar conteúdo PDF/XPS que utilize algumas fontes específicas, incluindo a Calibri, tradicionalmente usada como fonte padrão em versões do Microsoft Word. O problema está relacionado à atualização cumulativa do .NET Framework disponibilizada em 11 de agosto. Além das correções incluídas no pacote, a instalação pode afetar sistemas clientes com Windows 10 e Windows 11, assim como servidores executando versões do Windows Server de 2012 a 2025. Como solução temporária, a Microsoft orienta administradores e desenvolvedores a modificar o arquivo de configuração do aplicativo para habilitar a opção Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection. A própria empresa, no entanto, alerta que a medida desativa proteções de segurança introduzidas pela atualização de agosto de 2026 e pode aumentar a exposição às vulnerabilidades corrigidas pelo pacote. Por esse motivo, a recomendação é utilizar o procedimento apenas temporariamente e quando ele for necessário para restaurar a funcionalidade afetada. A Microsoft continua investigando a falha. As informações disponíveis indicam que o problema está relacionado ao processamento de determinadas fontes durante a impressão ou geração de documentos XPS e PDF por aplicações WPF. O incidente se soma a outro problema provocado pelas atualizações de agosto. A atualização de segurança do Windows de 11 de agosto também causou falhas em alguns jogos executados no sistema operacional. Nesse segundo caso, a Microsoft avalia uma possível relação com periféricos ou componentes internos que utilizam iluminação RGB. A empresa disponibilizou como alternativa uma alteração no Registro do Windows para desabilitar o driver inpoutx64, apontado como possível responsável pelas falhas, embora mudanças no Registro também envolvam riscos. A Microsoft informou que continua investigando a interação entre os componentes relacionados a RGB e os jogos afetados e deve divulgar novas informações conforme a análise avançar. Para os problemas de impressão associados à atualização do .NET Framework, porém, a alternativa disponível até o momento envolve desabilitar temporariamente as novas proteções de segurança quando aplicativos afetados precisarem imprimir ou gerar documentos em sistemas atualizados.

A Agência Nacional de Proteção de Dados (ANPD) aplicou uma multa de R$ 153,7 milhões à ByteDance, controladora do TikTok, após identificar irregularidades no tratamento de dados pessoais de crianças e adolescentes no Brasil. A decisão também determina a exclusão de informações coletadas de forma irregular e a implementação de medidas para adequar a plataforma à Lei Geral de Proteção de Dados (LGPD). A sanção foi publicada no Diário Oficial da União nesta terça-feira (25) e é resultado de um Processo Administrativo Sancionador conduzido após uma fiscalização da ANPD. Segundo a agência, foram encontradas irregularidades tanto na experiência do TikTok disponível sem criação de conta quanto no acesso realizado por usuários cadastrados. A investigação analisou duas modalidades: o chamado "feed sem cadastro", que permite utilizar parte da plataforma sem criar uma conta, e o "feed com cadastro", associado a um perfil registrado. De acordo com a Superintendência de Fiscalização da ANPD, nas duas modalidades houve tratamento de dados pessoais de crianças e adolescentes sem hipótese legal adequada prevista na LGPD. A multa está relacionada a cinco violações dos artigos 6º e 7º da legislação. No feed sem cadastro, a ANPD concluiu que o TikTok tratou dados de crianças e adolescentes sem uma base legal válida e não adotou medidas suficientes para impedir que informações desse público fossem processadas. No acesso com cadastro, a fiscalização apontou tratamento de dados de crianças e adolescentes durante a criação de contas sem hipótese legal válida, além da ausência de mecanismos considerados eficazes para impedir o cadastro desse público. A ANPD também concluiu que, nas duas modalidades, a ByteDance não conseguiu demonstrar a existência de medidas suficientemente eficazes para comprovar o cumprimento das normas brasileiras de proteção de dados. Segundo a área técnica da agência, os mecanismos implementados pela empresa não foram suficientes para evitar, desde a origem, o tratamento indevido de informações de crianças e adolescentes. Também teriam faltado evidências concretas sobre a efetividade dos controles técnicos e organizacionais utilizados para garantir conformidade com a LGPD. A penalidade está relacionada às condutas identificadas durante o período analisado. A ByteDance pode recorrer da decisão ao Conselho Diretor da ANPD em até dez dias úteis contados a partir da notificação da penalidade, realizada na segunda-feira (24). TikTok terá de adotar plano de conformidade Além da multa, a ByteDance se comprometeu a implementar um plano de conformidade destinado a ampliar a proteção de crianças e adolescentes no TikTok. Entre as medidas previstas está a aplicação automática das configurações de privacidade mais restritivas para contas pertencentes a menores de 16 anos. Alterações nessas configurações dependerão de autorização dos responsáveis. A plataforma também deverá fortalecer os mecanismos de supervisão parental e implementar filtros de conteúdo mais rigorosos. Mudanças significativas também serão aplicadas à experiência sem cadastro. No Brasil, o TikTok deverá suspender completamente a exibição de anúncios nesse modo, limitar o conteúdo disponibilizado a materiais adequados para todas as idades e reduzir a quantidade de dados pessoais processados. O feed sem cadastro terá utilização limitada a 12 horas e não permitirá criar conteúdo, comentar, enviar mensagens diretas ou realizar outras interações sociais. Também não será possível seguir usuários, receber seguidores, publicar ou assistir a transmissões ao vivo. A personalização de conteúdo será significativamente limitada. A coleta de informações deverá ficar restrita a dados mínimos, como idioma e região para relevância do conteúdo, informações básicas do dispositivo utilizadas na prevenção de fraudes e dados necessários ao desempenho do aplicativo. Verificação de idade também entra nas exigências Em outra decisão publicada nesta terça-feira, o Conselho Diretor da ANPD aprovou, em grau recursal, o plano de conformidade apresentado pela ByteDance, mas determinou que a empresa também deverá cumprir as exigências de aferição de idade estabelecidas pelo Estatuto Digital da Criança e do Adolescente, o ECA Digital. A implementação deverá seguir o cronograma definido pelo Conselho Diretor e as futuras orientações do Guia Orientativo de Mecanismos de Aferição de Idade. Enquanto o documento definitivo não é publicado, plataformas digitais devem observar as orientações preliminares já disponibilizadas. Segundo a ANPD, as medidas assumidas pela ByteDance reduzem riscos anteriormente identificados para crianças e adolescentes, incluindo a suspensão integral de publicidade e a desativação de transmissões ao vivo e mensagens diretas na experiência do TikTok sem cadastro.

Pesquisadores da Oasis Security divulgaram uma vulnerabilidade no NVIDIA NemoClaw que pode permitir que uma página controlada por um invasor assuma, sem autenticação, o controle de uma instância local do Ollama usada por um agente de inteligência artificial e insira instruções ocultas diretamente no modelo. A falha foi reportada previamente ao Product Security Incident Response Team (PSIRT) da NVIDIA e, até 25 de agosto de 2026, não recebeu um identificador CVE. Também não há relatos de exploração ativa. Segundo Elad Luz, chefe de pesquisa da Oasis Security, o NemoClaw v0.0.35 corrigiu o problema no macOS e Linux. O caminho utilizado no Windows e Windows Subsystem for Linux (WSL), porém, permanece sem uma correção equivalente. A versão 0.0.34 adicionou suporte à instalação no Windows acompanhado de um aviso sobre a configuração. O NemoClaw é uma stack de referência de código aberto da NVIDIA para executar agentes, como o OpenClaw, dentro de sandboxes OpenShell. Entre os mecanismos suportados para execução local dos modelos está o Ollama. Ollama exposto abre caminho para o ataque A pesquisa descreve uma configuração na qual o NemoClaw inicia o Ollama com OLLAMA_HOST=0.0.0.0:11434. Em vez de restringir o serviço ao próprio computador, essa configuração faz com que o servidor do modelo escute em todas as interfaces de rede. O comportamento varia de acordo com a plataforma. Em sistemas que não utilizam WSL, o Ollama permanece em 127.0.0.1:11434 e é colocado atrás de um proxy reverso protegido por token na porta 11435. No Windows com Docker Desktop e WSL, a arquitetura é diferente. O proxy pode ser ignorado para permitir que containers alcancem o serviço do host por meio de host.docker.internal. No caminho em que o Ollama é executado diretamente no Windows, a configuração utiliza 0.0.0.0:11434, sem exigir autenticação na API exposta nessa porta. O risco não está limitado a um invasor tentando acessar diretamente o serviço pela rede. A cadeia descrita pelos pesquisadores utiliza uma página maliciosa aberta no navegador da própria vítima. DNS rebinding permite alcançar o serviço local A API do Ollama na porta 11434 não utiliza autenticação e depende de verificações relacionadas aos cabeçalhos Host e Origin para limitar requisições provenientes de navegadores. Segundo a análise, quando o serviço não está restrito ao endereço de loopback, a validação do cabeçalho Host pode ser ignorada. O controle de Cross-Origin Resource Sharing (CORS) também pode aceitar a requisição quando Origin e Host correspondem ao domínio controlado pelo atacante. A etapa seguinte utiliza uma técnica conhecida como DNS rebinding. Nela, o domínio do invasor inicialmente aponta para o servidor malicioso e depois passa a resolver para 127.0.0.1, endereço que representa o próprio computador da vítima. O navegador, entretanto, continua tratando as requisições como pertencentes à mesma origem. Luz afirmou que a cadeia completa foi testada no macOS com Firefox contra uma versão vulnerável do NemoClaw. Ataques de DNS rebinding contra a API do Ollama já haviam sido documentados anteriormente. O Ollama lançou uma correção na versão 0.1.29, em março de 2024, para a vulnerabilidade CVE-2024-28224, relacionada à validação inadequada do cabeçalho Host. De acordo com Luz, o problema reaparece neste cenário porque o Ollama deixa de aplicar essa validação quando está associado a um endereço que não seja loopback — justamente o comportamento provocado pela configuração com 0.0.0.0. Invasor pode inserir instruções persistentes no modelo Após alcançar a API, a cadeia apresentada pela Oasis Security utiliza o endpoint /api/create para gravar um template de chat modificado. O template determina como mensagens estruturadas são convertidas em texto antes de serem processadas pelo modelo. Ao alterar esse componente, um atacante pode acrescentar instruções próprias às mensagens de sistema durante cada inferência. Segundo os pesquisadores, essas instruções permanecem nas conversas posteriores e continuam sendo aplicadas mesmo quando o agente fornece seu próprio system prompt. Isso torna o comprometimento particularmente relevante para agentes de IA. O usuário ou aplicação que consome o modelo pela API pode não perceber a alteração porque o template é uma propriedade do próprio modelo e não fica diretamente visível para o cliente. Na prática, o sandbox continua protegendo determinados recursos do endpoint, mas um agente comprometido pode utilizar as ferramentas e permissões que já possui dentro dos limites concedidos ao ambiente. Proteções atuais não cobrem todos os cenários Uma análise do repositório do NemoClaw realizada pelo The Hacker News em 25 de agosto encontrou uma proteção adicional introduzida como padrão na versão 0.0.106, em 10 de agosto. O proxy local do Ollama passou a se recusar a iniciar quando detecta que o backend está associado a uma interface que não seja loopback. O objetivo é impedir que uma instância acessível externamente contorne a autenticação por token fornecida pelo proxy. Essa proteção, entretanto, pode ser desativada por meio da variável NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1. Além disso, o mecanismo está dentro do próprio proxy, que não é iniciado em determinados caminhos envolvendo WSL e Windows. A análise também não encontrou no repositório um mecanismo destinado especificamente a verificar a integridade dos templates de chat dos modelos. A documentação da NVIDIA recomenda que usuários da configuração para Windows não exponham a porta 11434 à rede local ou à internet. Essa medida reduz o acesso direto pela rede, mas não necessariamente impede o cenário de DNS rebinding descrito pelos pesquisadores, pois as requisições são realizadas pelo navegador executado no próprio computador. A técnica de modificar templates para inserir instruções persistentes em modelos já foi descrita em pesquisas anteriores como "poisoned chat templates". A Oasis Security também documentou abordagens semelhantes envolvendo o Paperclip e agentes locais OpenClaw.

Pesquisadores da McAfee Labs identificaram vários sites que continuam distribuindo o malware Weedhack para jogadores ao se passarem por clientes, mods e outras ferramentas relacionadas ao Minecraft. A campanha utiliza técnicas de SEO poisoning para posicionar páginas falsas nos mecanismos de busca e induzir usuários a instalar arquivos maliciosos. A McAfee afirma ter detectado e bloqueado mais de 6.300 tentativas de acesso aos sites envolvidos. As páginas são desenvolvidas para reproduzir projetos legítimos, incluindo identidade visual, listas de recursos, perguntas frequentes, instruções de instalação, créditos de desenvolvedores e até links para repositórios reais no GitHub. Um dos sites identificados foi construído com o Lovable, ferramenta de criação de sites baseada em inteligência artificial. Segundo os pesquisadores, o caso demonstra como ferramentas amplamente disponíveis podem reduzir o esforço necessário para produzir rapidamente páginas falsas com aparência convincente. Weedhack rouba dados e altera configurações do Microsoft Defender O Weedhack foi documentado inicialmente pela McAfee em junho de 2026. A campanha combina SEO poisoning e vídeos no YouTube para direcionar potenciais vítimas a domínios fraudulentos. Quando o usuário instala o suposto cliente ou mod, uma cadeia de ataque em vários estágios termina na execução de arquivos JAR maliciosos. Os payloads podem coletar informações do sistema, criar exclusões no Microsoft Defender e roubar dados sensíveis do computador comprometido. A distribuição não depende apenas dos sites falsificados. De acordo com a análise, 49,6% das URLs maliciosas identificadas apontavam para o Discord, enquanto 23,4% estavam relacionadas ao MediaFire e 8,2% ao GitHub. Os invasores também utilizam links divulgados por Discord, Reddit e outros canais de comunicação. Arquivos JAR relacionados à campanha foram encontrados ainda no Planet Minecraft e EndMods, plataformas legítimas utilizadas pela comunidade para distribuir ferramentas e modificações do jogo. Sites falsos aparecem antes das fontes oficiais nas buscas Entre os domínios identificados estão páginas que imitam projetos como Glazed Client, Radium Client, SeedCrackerX, Meteor Client, Krypton Client, Nova Client e Xenon Client. Algumas reproduzem projetos gratuitos e de código aberto, enquanto outras oferecem versões supostamente gratuitas ou modificadas de ferramentas originalmente pagas. Um dos pontos mais preocupantes da campanha é a capacidade de páginas fraudulentas aparecerem em posições de destaque nos resultados de busca. Segundo a McAfee, sites falsos relacionados ao Xenon Client e Nova Client foram encontrados no topo das pesquisas em mecanismos como Google, Microsoft Bing, Brave Search e DuckDuckGo. No caso analisado, o cliente legítimo estava disponível no GitHub e no Modrinth, mas os responsáveis pela campanha criaram um site falsificado e utilizaram SEO poisoning para superar as fontes oficiais nos resultados de pesquisa. Essa técnica manipula mecanismos de otimização para mecanismos de busca (SEO) para aumentar artificialmente a visibilidade de páginas controladas pelos invasores. Dessa forma, uma vítima que procura por uma ferramenta legítima pode acessar primeiro o site malicioso e acreditar que está diante da página oficial. Plataformas legítimas também são usadas na distribuição A campanha mostra que verificar apenas a aparência do site ou reconhecer a plataforma utilizada para hospedar um arquivo não é suficiente para determinar se um download é confiável. Serviços populares como Discord, GitHub e MediaFire aparecem na infraestrutura utilizada para distribuir ou direcionar usuários aos arquivos maliciosos. A McAfee recomenda manter os dispositivos atualizados, obter mods e clientes somente de fontes confiáveis e verificar os arquivos antes da execução. Usuários também devem desconfiar de ferramentas que solicitem a desativação do antivírus ou de outras proteções antes da instalação. Campanhas de SEO poisoning para distribuição de malware não estão restritas ao ecossistema do Minecraft. Em junho de 2026, a Check Point identificou uma operação em larga escala que imitava projetos de código aberto e softwares gratuitos para direcionar usuários por meio de um Traffic Distribution System (TDS) e distribuir ameaças como Remus Stealer, AnimateClipper e o framework SessionGate.

O Linux completa 35 anos nesta terça-feira, 25 de agosto de 2026. O projeto que começou como um hobby do então estudante finlandês Linus Torvalds tornou-se uma das tecnologias mais importantes da computação, presente atualmente em servidores, infraestrutura de nuvem, smartphones, supercomputadores, sistemas embarcados e plataformas utilizadas para inteligência artificial e cibersegurança. A data remete a 25 de agosto de 1991, quando Torvalds, então com 21 anos e estudante da Universidade de Helsinque, publicou uma mensagem no grupo comp.os.minix, da Usenet, perguntando aos usuários quais recursos eles gostariam de encontrar em um sistema operacional. Na mensagem que ficaria marcada na história da tecnologia, Torvalds explicou que estava desenvolvendo um sistema operacional gratuito para computadores equipados com processadores Intel 386 e 486. O programador descreveu o trabalho como “apenas um hobby” e afirmou que ele não seria “grande e profissional como o GNU”. O projeto já vinha sendo desenvolvido desde abril daquele ano. No anúncio, Torvalds informou que havia conseguido portar o Bash 1.08 e o compilador GCC 1.40 e pediu sugestões à comunidade sobre funcionalidades que poderiam ser incorporadas ao sistema. Ele também esclareceu que o projeto não continha código do Minix. Poucas semanas depois, em 17 de setembro de 1991, a versão 0.01 do Linux foi disponibilizada. Nos meses seguintes, outros desenvolvedores começaram a contribuir com código e correções, dando início ao modelo colaborativo que se tornaria uma das características fundamentais do projeto. Em 1992, o kernel passou a utilizar a licença GNU General Public License (GPL), permitindo sua modificação e redistribuição sob os termos da licença. De hobby a infraestrutura global Ao longo das décadas seguintes, o Linux deixou de ser um sistema experimental para computadores pessoais e passou a ocupar uma posição central na infraestrutura tecnológica mundial. O kernel está na base de distribuições utilizadas em servidores e data centers e sustenta tecnologias relacionadas a computação em nuvem, dispositivos embarcados e supercomputação. O Android também utiliza o kernel Linux, levando a tecnologia indiretamente a bilhões de dispositivos móveis. A Linux Foundation destaca que o projeto ultrapassou 40 milhões de linhas de código e hoje está relacionado a áreas como infraestrutura de nuvem, inteligência artificial, segurança, sistemas críticos e dispositivos embarcados. A evolução também transformou o Linux em uma peça relevante para a cibersegurança. O sistema está presente tanto na infraestrutura que precisa ser protegida — servidores, workloads em nuvem, containers e equipamentos de rede — quanto no conjunto de ferramentas utilizadas por profissionais de segurança para análise, monitoramento, testes de intrusão, resposta a incidentes e pesquisa de vulnerabilidades. Desenvolvimento continua 35 anos depois Mesmo depois de três décadas e meia, Linux permanece em desenvolvimento ativo por uma comunidade global formada por desenvolvedores independentes e profissionais ligados a diversas empresas de tecnologia. A Linux Foundation está celebrando oficialmente os 35 anos do projeto em 2026 e também levará o aniversário ao Open Source Summit + Embedded Linux Conference Europe, marcado para ocorrer entre 7 e 9 de outubro, em Praga. O evento terá participação de Linus Torvalds e discussões sobre inteligência artificial aberta, segurança, cloud native, sistemas críticos e Linux embarcado. A dimensão alcançada pelo projeto contrasta com a previsão feita pelo próprio Torvalds em 1991. O sistema que ele acreditava que provavelmente ficaria restrito aos computadores que possuía na época tornou-se, 35 anos depois, uma das principais fundações de software da infraestrutura digital mundial.

O WhatsApp anunciou novos recursos de segurança para contas, incluindo suporte a múltiplas passkeys vinculadas ao mesmo perfil. A mudança permite que usuários com dispositivos Android e iOS utilizem diferentes chaves de acesso para entrar na mesma conta, ampliando o uso de um método de autenticação resistente a phishing. Segundo a Meta, mais de 1 bilhão de pessoas já utilizam passkeys para acessar o WhatsApp. O recurso começou a ser disponibilizado no Android em outubro de 2023 e chegou ao iOS no início de 2024. Em junho de 2025, a empresa também levou a tecnologia aos logins do Facebook. As passkeys substituem ou complementam métodos tradicionais de autenticação utilizando credenciais criptográficas armazenadas no dispositivo. Na prática, o usuário pode confirmar sua identidade por mecanismos como biometria ou PIN do aparelho, reduzindo a dependência de senhas que podem ser roubadas por páginas falsas e campanhas de phishing. Com o suporte a múltiplas passkeys, uma mesma conta poderá manter credenciais associadas a diferentes dispositivos. As chaves cadastradas podem ser administradas pelo caminho Configurações > Conta > Passkeys no WhatsApp. Outra mudança envolve a verificação em duas etapas. Até agora, o WhatsApp utilizava um PIN de seis dígitos como camada adicional de proteção. A plataforma passa a oferecer uma senha completa, que pode ser mais longa e combinar letras, números e caracteres especiais. De acordo com o WhatsApp, essa proteção adicional ajuda a impedir a tomada de uma conta mesmo quando um invasor consegue obter o código de uso único da vítima. A alteração busca tornar a credencial adicional mais difícil de adivinhar do que um PIN numérico simples. O WhatsApp também está ampliando as informações apresentadas aos usuários Android quando recebem chamadas de números que não estão salvos nos contatos. A interface poderá mostrar dados como a origem da chamada, se o número já está na lista de contatos e se as duas pessoas participam de algum grupo em comum. A medida procura oferecer mais contexto antes que o usuário atenda uma ligação desconhecida, especialmente diante de golpes baseados em engenharia social que exploram urgência para induzir vítimas a tomar decisões rapidamente.

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.