Builder público, plugins extraídos e drivers assinados com certificados antigos ampliam a capacidade operacional do backdoor associado a atores chineses.
| Componente | ValleyRAT, também conhecido como Winos ou Winos4.0, com builder, painel C2, plugins principais e Driver Plugin.dll com driver de núcleo embutido. |
| Vetor | Infecção inicial por backdoor que recebe plugins a partir do C2; operadores decidem quais módulos entregar conforme o interesse no host comprometido. |
| Impacto | Execução modular de capacidades pós-comprometimento, instalação de serviço de driver, ocultação, proteção de artefatos e injeção baseada em APC comandada por IOCTL. |
| Prioridade | Inventariar endpoints Windows expostos a drivers legados, caçar serviço kernelquick, revisar carregamento de drivers assinados com certificados expirados e bloquear amostras ValleyRAT. |
| Artefatos | Builder PE de 32 bits compilado em 2025-03-26 04:10:15 UTC; driver de núcleo compilado em 2023-04-23 08:10:50 UTC; chave HKLM\SYSTEM\CurrentControlSet\Services\kernelquick\. |
| Telemetria | Foram identificadas cerca de 6.000 amostras relacionadas ao ValleyRAT entre novembro de 2024 e novembro de 2025, incluindo 30 variantes do builder e 12 variantes do rootkit. |
O ValleyRAT é um backdoor modular associado a operadores chineses e observado como estágio final em operações ligadas ao grupo Silver Fox. A família também aparece pelos nomes Winos e Winos4.0, e sua arquitetura não depende de um único binário monolítico. O implante inicial atua como ponto de entrada para módulos adicionais, mantendo comunicação com infraestrutura C2 e solicitando componentes conforme a decisão do operador. Essa separação dificulta a análise completa, porque ambientes de laboratório ou vítimas de baixo interesse normalmente recebem apenas módulos iniciais, como componentes de presença on-line ou login, sem expor toda a cadeia de funcionalidades.
A análise de builders e artefatos públicos mostrou que o ecossistema do ValleyRAT inclui um builder usado também como painel C2, projetos Visual Studio vinculados ao sistema de plugins e binários compilados incorporados a recursos PE. O builder localizado é um PE de 32 bits compilado em 2025-03-26 04:10:15 UTC e continha os plugins principais em seus recursos. Outra estrutura de desenvolvimento, mais antiga, expunha projetos e soluções relacionados aos plugins, mas sem o código-fonte. A correlação entre nomes de projetos, metadados PE e plugins extraídos permitiu reconstruir a composição operacional do malware sem depender de uma única execução controlada.
O fluxo operacional começa com a instalação do backdoor ValleyRAT no host comprometido. Após o primeiro contato com o C2, módulos iniciais estabelecem presença e permitem que o operador avalie o ambiente. A partir desse ponto, plugins adicionais podem ser enviados sob demanda. Essa entrega seletiva é relevante para defesa porque uma ausência de módulos avançados em uma amostra não significa ausência de capacidade na família; significa apenas que o operador ou a infraestrutura não liberou aqueles componentes naquele caso. Todos os plugins principais analisados possuem capacidade de conexão TCP ou UDP com um host C2 definido e trocam dados serializados específicos do módulo, normalmente protegidos por esquemas customizados baseados em XOR.
A extração dos componentes exigiu validação de binários embutidos dentro do builder e de plugins. Os plugins principais estavam presentes em variantes de 32 e 64 bits, totalizando 19 plugins distintos por arquitetura. A análise também identificou utilitários auxiliares incorporados, como UPX, BoxedApp SDK e biblioteca estendida de logging. A funcionalidade dos plugins auxiliares não pôde ser confirmada por binários, pois eles apareciam apenas como referências na estrutura de desenvolvimento; portanto, qualquer leitura sobre esses módulos deve ser tratada como inferência baseada em nomes de projetos e relações estruturais, não como capacidade comprovada por engenharia reversa de código compilado.
O componente de maior impacto é o Driver Plugin.dll, originalmente associado ao projeto de plugin de driver. Esse DLL atua em modo de usuário como cliente, instalador e controlador de um driver de núcleo embutido. O driver fica armazenado na seção .data do plugin e, após extração preservando a estrutura WIN_CERTIFICATE, pôde ser correlacionado a uma amostra exata em serviços públicos de análise. O binário de núcleo manteve caminho PDB compatível com a estrutura Visual Studio observada e possui timestamp de compilação de 2023-04-23 08:10:50 UTC. Apesar de compilado em 2023, o driver foi assinado com certificado expirado, válido apenas entre 2013 e 2014, o que aponta para uso indevido de certificado antigo ou roubado.
No modo normal de instalação, o cliente chama DropAndInstallRootkit(), grava o driver em disco e registra um serviço de núcleo chamado kernelquick em HKLM\SYSTEM\CurrentControlSet\Services\kernelquick\. O serviço é configurado como SERVICE_KERNEL_DRIVER com inicialização sob demanda. Depois de carregado, o driver funciona como dispositivo de núcleo do Windows, minifiltro de sistema de arquivos, filtro de registro e monitor de processos e threads. O controle em tempo de execução ocorre por requisições IOCTL emitidas pelo cliente em modo de usuário, convertendo comandos do C2 em mudanças de configuração, regras de ocultação, listas de proteção e listas de exclusão.
A superfície exposta envolve endpoints Windows capazes de carregar drivers legados assinados dentro das exceções da política de assinatura de drivers. O comportamento observado é crítico porque alguns drivers com certificados expirados ainda podiam ser carregados em sistemas Windows 11 atualizados quando enquadrados em exceções para certificados de entidade final emitidos antes de 2015-07-29 e encadeados a uma autoridade de certificação cruzada suportada. Durante a investigação, a revogação posterior de um certificado impediu o carregamento de uma amostra específica, mas a telemetria mostrou variantes adicionais do rootkit, algumas ainda assinadas com certificados não revogados no momento da observação.
A presença de 30 variantes do builder e 12 variantes do rootkit indica que a cadeia não deve ser tratada como artefato único. Cerca de 6.000 amostras relacionadas ao ValleyRAT foram identificadas entre novembro de 2024 e novembro de 2025, com aproximadamente 85% das detecções concentradas nos seis meses finais desse intervalo. Esse padrão coincide com a disponibilidade pública do builder e sugere maior adoção por operadores diferentes ou aumento de experimentação com a cadeia modular. Para equipes defensivas, o ponto central é monitorar tanto o backdoor em modo de usuário quanto a camada de driver, porque a remoção de apenas um componente pode deixar persistência ou proteção residual ativa.
O modo furtivo do instalador aumenta a superfície de detecção em processos e rede. Nesse fluxo, rotinas como GetProcID_dwm() e CreateProcessMalseclogon() são usadas junto de uma técnica baseada em MalSeclogon para executar ações sob contexto impersonado e com spoofing de PPID. O instalador também executa comandos como cmd /c start /min ipconfig /release e cmd /c start /min ipconfig /renew, interrompendo e restaurando conectividade durante a instalação. Essa sequência reduz sinais comportamentais diretos no processo do malware e tenta fazer a atividade parecer originada de processo confiável do Windows.
Outro recurso relevante é o suporte a shellcode fornecido pelo operador. O cliente em modo de usuário pode armazenar shellcode em HKLM\SOFTWARE\IpDates; quando comandado, o rootkit recupera esse conteúdo e executa injeção baseada em APC. Esse desenho separa transporte, armazenamento e execução, dificultando a atribuição de um único artefato a toda a atividade maliciosa. A defesa precisa correlacionar escrita em registro, carregamento de driver, criação de serviço, comandos de rede e eventos de injeção para reduzir falsos negativos.
- Endpoints Windows com carregamento de drivers legados e certificados antigos aceitos por exceções de política.
- Hosts comprometidos que receberam o backdoor ValleyRAT e plugins adicionais a partir do C2.
- Sistemas com serviço
kernelquickou chaves de configuração usadas para ocultação, proteção e shellcode.
A caça deve começar por artefatos de driver e serviço. O serviço kernelquick, a chave HKLM\SYSTEM\CurrentControlSet\Services\kernelquick\ e qualquer driver recém-criado com assinatura expirada, certificado antigo ou cadeia de assinatura incomum devem ser priorizados. Em ambientes com EDR, eventos de carregamento de driver no núcleo precisam ser cruzados com reputação do binário, timestamp PE, caminho em disco, editor do certificado e status de revogação. O fato de algumas variantes não estarem em listas de bloqueio de drivers vulneráveis torna insuficiente depender apenas de controles padrão do sistema operacional.
No endpoint, a sequência de instalação furtiva deixa sinais combinados: execução de ipconfig /release e ipconfig /renew a partir de cmd.exe, uso de contexto impersonado por MalSeclogon, árvore de processo com PPID inconsistente e posterior registro de serviço de driver. A ordem desses eventos é mais útil do que qualquer evento isolado. Em redes, conexões TCP ou UDP originadas por plugins para hosts C2 definidos pelo operador devem ser correlacionadas com cargas de dados serializadas e padrões de criptografia customizada baseada em XOR quando a inspeção for possível. A ausência de IoCs públicos no ambiente local não elimina risco, pois operadores podem trocar infraestrutura e nomes de arquivos sem modificar a lógica de plugins.
A telemetria de registro também é importante. Escritas em HKLM\SOFTWARE\IpDates podem indicar armazenamento de shellcode para execução posterior. Alterações em listas de ocultação, proteção ou exclusão usadas pelo driver devem ser tratadas como tentativa de blindar processos, arquivos ou chaves de registro contra enumeração e remoção. Para DFIR, a coleta deve preservar o driver em disco, o plugin que o carregou, as entradas de serviço, eventos de criação de processo, logs de segurança relacionados a impersonação e qualquer tráfego associado ao processo controlador.
- Criação ou modificação de
HKLM\SYSTEM\CurrentControlSet\Services\kernelquick\. - Carregamento de driver de núcleo com certificado expirado, antigo, não revogado ou fora do padrão corporativo.
- Execução de
cmd /c start /min ipconfig /releaseseguida decmd /c start /min ipconfig /renewdurante instalação suspeita. - Escrita de dados em
HKLM\SOFTWARE\IpDatesantes de eventos de injeção por APC. - Conexões TCP ou UDP de plugins ValleyRAT para C2 com dados serializados e proteção baseada em XOR.
A resposta deve tratar o ValleyRAT como cadeia modular com componente de núcleo, não como backdoor simples. O primeiro passo é isolar hosts com indícios de driver carregado, preservar evidências voláteis e coletar artefatos antes da remoção. Em seguida, é necessário identificar o serviço kernelquick, validar o caminho do binário associado, calcular hashes internos, verificar assinatura, consultar revogação de certificado e revisar eventos de carregamento de driver. A remoção deve considerar dependências entre plugin em modo de usuário, serviço de driver e configurações em registro para evitar que um componente reinstale ou reprote outro.
A mitigação preventiva exige endurecimento de política de drivers. Organizações devem habilitar controles de bloqueio de drivers vulneráveis, revisar Microsoft Vulnerable Driver Blocklist, aplicar políticas de controle de aplicação quando disponíveis e criar regras internas para negar drivers assinados por certificados expirados ou por cadeias não utilizadas pela empresa. Como algumas variantes ainda podiam carregar em Windows 11 totalmente atualizado com HVCI e Secure Boot habilitados, a validação local precisa ir além de confiar na configuração nominal do sistema. Testes de carga controlados em laboratório e telemetria de produção devem confirmar se a política realmente bloqueia as amostras conhecidas.
Após contenção, a equipe deve procurar persistência e atividade pós-exploração. Isso inclui revisar chaves de serviço, chaves de registro associadas ao shellcode, processos protegidos ou ocultos, arquivos invisíveis para APIs usuais e conexões históricas com C2. Credenciais usadas no host comprometido devem ser rotacionadas quando houver evidência de interação do operador, porque a arquitetura de plugins permite entrega de capacidades adicionais não vistas no artefato inicial. Por fim, regras de detecção devem cobrir família e comportamento: builder, plugins principais, driver, criação de serviço, IOCTL anômalo, escrita de configuração e tentativa de injeção por APC.
- Isolar hosts com serviço
kernelquick, driver suspeito ou plugin ValleyRAT em execução. - Bloquear carregamento de drivers com certificados expirados, revogados, desconhecidos ou incompatíveis com a política corporativa.
- Criar detecções para
HKLM\SOFTWARE\IpDates, instalação deSERVICE_KERNEL_DRIVERsob demanda e comandosipconfigacionados por processos suspeitos. - Atualizar EDR, listas de bloqueio e regras de controle de aplicação com amostras internas validadas.
- Executar varredura retrospectiva entre novembro de 2024 e novembro de 2025 para identificar hosts que possam ter recebido módulos do ValleyRAT.
0 Comentários