Zero-day no RasMan expõe dilema de patching no Windows
Falha que derruba o serviço de conexões remotas ganhou “micropatch” gratuito da 0patch e reacendeu alerta sobre cadeias de exploração locais e disponibilidade
Uma nova vulnerabilidade zero-day no Remote Access Connection Manager (RasMan), serviço do Windows que gerencia conexões remotas como VPN e PPPoE, colocou equipes de segurança diante de um problema que vai além de “aplicar atualização e seguir em frente”. O ponto central é que a falha permite a qualquer usuário sem privilégios derrubar o serviço, provocando negação de serviço local e potencial indisponibilidade de recursos que dependem dessas conexões. A gravidade operacional cresce porque o RasMan não é um componente periférico: ele roda com privilégios de nível SYSTEM e, em muitos ambientes corporativos, é parte do caminho crítico para trabalho remoto, acesso a redes privadas e conectividade de ponta.
O caso ganhou destaque porque, antes de existir correção oficial da Microsoft, a ACROS Security liberou correções “não oficiais” via 0patch, no modelo de micropatching. Na prática, trata-se de um patch pequeno aplicado em memória pelo agente da 0patch, sem exigir reinicialização do sistema, e oferecido gratuitamente até que o fornecedor publique uma correção oficial. Esse tipo de mitigação costuma aparecer quando a janela de exposição é sensível e o mercado precisa de resposta imediata, sobretudo em ambientes que não conseguem esperar o próximo ciclo de atualização ou que ainda operam versões antigas do Windows.
O que torna essa zero-day particularmente relevante é o contexto em que foi descoberta. A 0patch encontrou o problema enquanto analisava o CVE-2025-59230, uma vulnerabilidade de elevação de privilégio no RasMan que a Microsoft corrigiu em outubro de 2025. Segundo a explicação técnica publicada, a exploração do CVE-2025-59230 dependia de uma condição específica: o RasMan não podia estar em execução. Isso porque, quando o serviço não está rodando, um processo não privilegiado pode se passar por ele ao registrar o mesmo endpoint RPC e induzir serviços privilegiados a confiarem nessas respostas, abrindo espaço para execução de código em cenário de escalada local. A descoberta “não óbvia” foi justamente que, para tornar esse ataque viável no mundo real, o atacante precisa conseguir parar o RasMan no momento certo, e a nova falha de negação de serviço fornece esse “gatilho” ao permitir derrubar o serviço sob demanda.
A raiz do problema, conforme detalhado pela 0patch e reproduzido pela imprensa especializada, está em um erro de lógica ao percorrer uma lista encadeada circular. Quando o código se depara com um ponteiro nulo durante a travessia, ele deveria interromper o loop com segurança, mas continua a execução e tenta acessar memória a partir desse ponteiro nulo, o que causa violação de acesso e derruba o serviço. Esse detalhe é importante porque, apesar de parecer um “crash local”, ele se conecta ao risco maior de cadeias de ataque: disponibilidade degradada, ruído operacional e, em combinações específicas, facilitação de técnicas de escalada e persistência.
Do ponto de vista de resposta do fornecedor, a Microsoft afirmou estar ciente do problema de negação de serviço e que irá endereçá-lo em uma correção futura. Ao mesmo tempo, a empresa declarou que clientes que aplicaram os patches de outubro para o CVE-2025-59230 estariam protegidos contra a exploração de elevação de privilégio relacionada a esse CVE. Na prática, isso sugere um cenário bifurcado: em ambientes atualizados, o risco mais imediato tende a ser a indisponibilidade local do RasMan; já em ambientes desatualizados ou legados, a presença do crash como “peça faltante” pode voltar a preocupar por viabilizar cadeias locais mais perigosas, além de ampliar a superfície para ataques oportunistas em endpoints com controle fraco de execução e privilégios.
Para operações de MSS e SOC, a lição é menos sobre uma falha isolada e mais sobre governança de patching e postura: inventariar versões do Windows e servidores, validar quem recebeu correções de outubro, e monitorar sinais de instabilidade do RasMan que possam indicar abuso, principalmente em máquinas expostas a usuários não confiáveis ou com histórico de infecção por malware. Em paralelo, a decisão de usar micropatch deve ser guiada por risco e criticidade, com validação em ambiente de teste, aplicação controlada e plano de rollback, porque embora seja um recurso valioso em janelas de exposição, ele não substitui a correção oficial e o ciclo formal de atualização.
Falha no WinRAR vira arma em massa e expõe fragilidade de inventário nas empresas
O alerta que ganhou força nesta semana no Brasil não é apenas mais um CVE “barulhento” na mídia. A CVE-2025-6218, que afeta o WinRAR e componentes relacionados no Windows, entrou no radar por evidências de exploração ativa e, principalmente, por estar sendo reutilizada por mais de um ator. Isso muda a dinâmica do risco: quando uma falha passa a ser disputada por múltiplos grupos, ela deixa de ser um problema pontual e vira uma infraestrutura de ataque. O motivo é simples: ferramentas de compactação estão em milhares de endpoints, inclusive em estações fora de gerenciamento rígido, o que cria um terreno fértil para campanhas oportunistas.
Tecnicamente, a falha é do tipo directory traversal ou path traversal. Em termos práticos, o arquivo compactado pode conter caminhos manipulados que fazem o WinRAR gravar arquivos fora do diretório que o usuário escolheu para extrair. Em versões vulneráveis, um invasor consegue “escapar” da pasta de extração e plantar arquivos em locais sensíveis do sistema. Um exemplo clássico citado por pesquisadores e pela própria WinRAR é a pasta de Inicialização do Windows, onde qualquer executável ali depositado pode ser carregado no próximo logon, transformando uma simples extração em persistência. O NVD descreve o impacto como execução de código no contexto do usuário atual, o que significa que privilégios e acessos do usuário determinam até onde a intrusão pode ir.
A exploração tende a seguir uma cadeia conhecida do SOC, mas com um detalhe que a torna “eficiente”: a etapa inicial exige pouca sofisticação. O atacante precisa de interação do usuário, como abrir um arquivo malicioso ou visitar uma página que entregue o pacote, o que combina perfeitamente com engenharia social via e-mail, mensageria e até trocas internas de arquivos. A partir daí, o arquivo compactado vira um “contêiner” para droppers e loaders. Em campanhas descritas na imprensa especializada, a mesma falha foi vinculada a diferentes grupos, com variações de payload e objetivos, indo de espionagem a infecção por trojans com roubo de dados. Esse efeito de reutilização é o que pressiona ambientes corporativos: não basta “monitorar”, é preciso reduzir a superfície rapidamente.
Um ponto que pesa no risco operacional é a natureza do WinRAR no parque. Em muitas empresas, ele aparece como software de usuário, instalado manualmente, às vezes em versões antigas, e frequentemente fora do catálogo de aplicativos gerenciados. Isso cria um problema clássico para MSS e TI: corrigir é fácil no papel, mas difícil na execução quando o inventário não está completo e quando endpoints ficam fora do domínio, do MDM ou do EDR com capacidade de remediação. A cobertura também é enganosa: não é só “WinRAR”. A correção mencionada nos avisos inclui RAR, UnRAR, UnRAR.dll e o código portátil do UnRAR para Windows, ampliando o escopo do que precisa ser identificado e atualizado.
Do lado do fornecedor, a linha do tempo é clara e ajuda a orientar compliance. A vulnerabilidade foi reportada de forma responsável via Zero Day Initiative, recebeu o identificador CVE-2025-6218 e teve correção disponibilizada ainda em junho de 2025, com o WinRAR 7.12 e, antes disso, no 7.12 Beta 1. O release note oficial descreve justamente o comportamento explorado: durante a extração, versões anteriores podiam ser enganadas para usar um caminho definido no arquivo malicioso em vez do caminho escolhido pelo usuário, permitindo escrita em local inesperado. Em dezembro de 2025, o tema voltou com força porque surgiram sinais de exploração ativa por diferentes atores e a vulnerabilidade ganhou nova onda de atenção pública.
Para ambientes brasileiros, o que muda no jogo é a combinação entre alta presença da ferramenta, cultura de troca de arquivos e heterogeneidade de endpoints. O risco não é teórico: mesmo quando a execução ocorre “no contexto do usuário”, isso pode ser suficiente para roubar credenciais, capturar dados locais, escalar a intrusão por engenharia social interna e preparar o terreno para ações mais destrutivas. Para SOCs e MSSPs, o valor prático desse alerta está em priorizar atualização para WinRAR 7.12 ou superior, varrer versões vulneráveis no parque e tratar arquivos compactados como vetor de alta probabilidade no funil de triagem. A notícia, aqui, é menos sobre um bug específico e mais sobre uma lição recorrente: o atacante escolhe o que é comum, barato e difícil de governar.
NANOREMOTE transforma o Google Drive em canal “invisível” de comando e roubo de dados
O caso do NANOREMOTE chama atenção menos pelo “nome do malware” e mais pela estratégia por trás da operação. Em vez de depender de infraestrutura própria de comando e controle, o backdoor usa a API do Google Drive como trilha principal para trocar informações com o operador, exfiltrar dados e preparar novos artefatos para execução, de forma que a movimentação pareça um uso cotidiano de nuvem. A Elastic Security Labs registrou a descoberta em telemetria em outubro de 2025 e descreveu o implante como um backdoor completo para Windows, com foco em espionagem e capacidades típicas de pós-comprometimento, incluindo execução de comandos, enumeração e transferência de arquivos.
Na prática, o “truque” é transformar um serviço amplamente confiável em canal operacional. O NANOREMOTE implementa um sistema de gerenciamento de tarefas voltado a file transfer, com suporte a enfileirar uploads e downloads, pausar e retomar transferências, cancelar operações e até gerar e reutilizar refresh tokens para manter acesso contínuo ao Drive. Isso complica a vida do SOC por dois motivos: primeiro, porque a reputação do domínio e da plataforma não ajuda a filtrar o tráfego; segundo, porque a diferença entre o legítimo e o malicioso passa a depender muito mais de contexto comportamental (qual processo acessou a API, em que volume, em que horários, e com que padrão) do que de indicadores tradicionais baseados em IP e domínio.
A cadeia de infecção observada pela Elastic inclui um loader chamado WMLOADER, que se disfarça como componente de programa de segurança, usando o nome BDReinit.exe, e prepara o processo para carregar shellcode e iniciar o backdoor. O vetor inicial de acesso não foi confirmado, o que é comum em malware de espionagem quando a visibilidade se concentra no estágio pós-execução. Ainda assim, a anatomia do implante é clara: o NANOREMOTE é um executável 64-bit, escrito em C++ e, segundo a análise, não depende de ofuscação pesada para operar, apostando mais na “camuflagem” do tráfego via Drive do que em esconder o binário.
O que ele consegue fazer depois de instalado é exatamente o que preocupa operações de defesa: reconhecimento de host, manipulação de arquivos e diretórios, execução de comandos e programas e controle de fluxo para roubo de dados. A reportagem brasileira reforça que a amostra analisada possui um conjunto de 22 comandos e mantém múltiplas configurações de clientes OAuth, com Client ID, Client Secret e Refresh Token, além de um fallback que permite receber credenciais via variável de ambiente (NR_GOOGLE_ACCOUNTS). Em termos operacionais, isso significa que o atacante tem flexibilidade para trocar “contas” e credenciais de acesso à API, mantendo o canal vivo mesmo se parte das chaves for revogada. Em paralelo, a Elastic documenta que o implante incorpora bibliotecas e projetos open source como Microsoft Detours e libPeConv, reforçando um padrão comum em tooling avançado: acelerar desenvolvimento reutilizando componentes confiáveis e estáveis.
Há também um componente de atribuição e continuidade que eleva a criticidade do caso. A Elastic indica que o NANOREMOTE compartilha características com a atividade descrita como REF7707 e é similar ao implante FINALDRAFT. Já a cobertura internacional associa o cluster REF7707 a uma atividade suspeita vinculada à China, com histórico de alvos em setores como governo, defesa, telecomunicações, educação e aviação, e menciona que o FINALDRAFT usa a Microsoft Graph API como canal de C2, sugerindo uma “família” de implantes que explora APIs corporativas e plataformas populares como trilha de comando e exfiltração. Mesmo sem cravar autoria, o padrão é consistente: reduzir indicadores óbvios de C2 e misturar-se ao ruído normal de SaaS e cloud.
Para empresas e provedores de MSS no Brasil, o impacto mais prático é que detecção baseada apenas em bloqueio de domínio e reputação vira insuficiente. O controle passa por três eixos: visibilidade de endpoint para entender qual processo faz chamadas ao Drive e em que sequência; governança de nuvem para auditar acessos, tokens e fluxos atípicos; e políticas de egress e identidade para reduzir a chance de um malware “se comportar” como um usuário comum sem disparar alertas. A mensagem do caso é direta: quando o atacante usa infraestrutura legítima, a defesa precisa elevar o nível de contexto e correlação, porque o tráfego “parece normal” por definição.
Extensões “adormecidas” viram spyware e escancaram o ponto cego do Chrome e do Edge
O caso revelado nesta semana expõe uma fragilidade estrutural do ecossistema de extensões: o que passa na revisão inicial pode mudar radicalmente depois, por meio de atualizações que chegam automaticamente a milhões de navegadores. A empresa Koi Security atribui a operação a um ator chamado ShadyPanda, que teria mantido uma estratégia de longo prazo ao publicar extensões “legítimas”, acumular base instalada, conquistar selos de confiança e, apenas mais tarde, inserir comportamento malicioso. O impacto estimado alcança 4,3 milhões de usuários em Chrome e Edge, com extensões capazes de vigiar navegação e até habilitar execução de código dentro do browser, algo especialmente sensível porque é no navegador que ficam sessões, cookies, tokens de SaaS e grande parte da atividade diária corporativa.
O relatório da Koi descreve a campanha como uma evolução em fases, o que ajuda a entender por que ela foi difícil de detectar cedo. Em 2023, o grupo teria espalhado um grande conjunto de extensões com aparência inofensiva para fraude de afiliados, injetando códigos de rastreamento quando a vítima clicava em links de e-commerce e, ao mesmo tempo, usando telemetria para “monetizar” padrões de navegação. Em 2024, a operação teria subido um degrau ao partir para sequestro de buscas, exemplificado por uma extensão de “produtividade” que redirecionava pesquisas e coletava consultas em nível de digitação. A leitura defensiva aqui é importante: campanhas desse tipo frequentemente começam com monetização “menos barulhenta”, testam limites do marketplace e, quando validam que updates passam com baixa fricção, migram para espionagem e controle do navegador.
O que torna o episódio realmente grave é o uso de extensões “dormentes” por anos e, depois, a ativação de um framework de backdoor. Segundo a Koi e análises repercutidas por veículos especializados, algumas extensões teriam sido “weaponizadas” em meados de 2024 e passaram a executar, em ciclos regulares, lógica de comando e controle: consultavam infraestrutura remota, baixavam JavaScript arbitrário e executavam com acesso às APIs do navegador, o que abre caminho para interceptação de tráfego, coleta de dados e manipulação de páginas. Entre os dados potencialmente capturados estão URLs visitadas, histórico, referenciadores, timestamps, identificadores persistentes, fingerprint do navegador (idioma, plataforma, resolução, fuso), além de acesso a storage e cookies, dependendo das permissões concedidas. O relatório também descreve mecanismos de evasão e a possibilidade de o operador alterar a “função” do malware a qualquer momento via atualização ou instruções remotas, transformando uma extensão popular em vetor para roubo de sessão, phishing in-browser e outras ações de alto impacto.
Outro ponto crítico é a diferença entre “remover da loja” e “remover do endpoint”. Mesmo quando Google e Microsoft retiram a extensão do marketplace, ela permanece instalada no navegador do usuário até desinstalação manual, e em alguns cenários ainda pode continuar ativa por conta de sincronização de perfil e permissões já concedidas. O próprio noticiário destacou extensões como WeTab e Clean Master no centro do caso, com milhões de instalações, além do risco de que parte do ecossistema demore mais a reagir no Edge por causa da dinâmica do marketplace. Para empresas e MSSPs, isso vira um checklist imediato: inventariar extensões instaladas (não apenas “aplicativos”), impor allowlist corporativa, bloquear instalação fora de catálogo aprovado, revisar permissões “ler e alterar dados em todos os sites”, e orientar o time a remover extensões suspeitas diretamente em chrome://extensions ou edge://extensions. Em paralelo, é prudente revogar sessões e rotacionar senhas de contas críticas (principalmente SaaS), porque a hipótese de roubo de cookies e token de sessão muda a natureza do incidente: não é só privacidade, é risco de account takeover.
Para acompanhar todo lançamento do Eskudo News, nos siga no Linkedin do Eskudo e também no da 2R Datatel!
Leia outras edições do Eskudo News
Eskudo News | O seu jornal semanal de tecnologia.