Campanha explorou drivers derivados do Zemana Anti-Malware SDK, incluindo amsdk.sys assinado pela Microsoft, para encerrar processos protegidos e carregar o backdoor ValleyRAT em sistemas Windows.
| Componente | Drivers de modo núcleo derivados do Zemana Anti-Malware SDK, principalmente amsdk.sys versão 1.0.600 do WatchDog Antimalware e ZAM.exe versão 3.0.0.000. |
| Vetor | Loader all-in-one em Windows entrega driver vulnerável conforme a versão do sistema, carrega o serviço de kernel Amsdk_Service e usa IOCTLs para encerrar processos de segurança. |
| Impacto | Desativação de EDR e antivírus, inclusive processos sob PP/PPL, seguida de injeção do downloader do ValleyRAT em memória e comunicação com C2. |
| Prioridade | Bloquear drivers vulneráveis e variantes assinadas alteradas, monitorar carregamento de serviços de kernel não esperados e investigar hosts com C:\Program Files\RunTime ou serviço Termaintor. |
| Versões | amsdk.sys 1.0.600, wamsdk.sys 1.1.100, ZAM.exe 3.0.0.000; Windows 7 recebe o driver legado, enquanto Windows 10/11 recebe o driver WatchDog. |
| Artefatos | RuntimeBroker.exe, Amsdk_Service.sys, serviço Termaintor, serviço Amsdk_Service, dispositivo amsdk, seção .rdata, DLL 上线模块.dll, exportações load e run. |
| IoCs | Configurações citadas incluem 156.234.58.194:52110 e 156.234.58.194:52111; o downloader usa XOR com chave 363636003797e4383a36. |
| Mitigação | Aplicar controles de bloqueio por certificado, política de driver e comportamento, porque alteração de um byte no campo de timestamp não autenticado manteve a assinatura Authenticode válida e mudou o hash do arquivo. |
A campanha atribuída ao grupo Silver Fox APT usa uma técnica de evasão em baixo nível contra Windows: em vez de tentar contornar EDR e antivírus apenas em modo usuário, o loader instala e aciona drivers de modo núcleo com capacidade de encerrar processos arbitrários. O ponto operacional é a combinação de um binário all-in-one, drivers incorporados, lógica de seleção por versão do sistema operacional, rotinas anti-análise, persistência por serviço e um downloader que recupera o backdoor ValleyRAT, também conhecido como Winos. O abuso do driver permite neutralizar processos de segurança antes da fase final de execução do malware, reduzindo a chance de inspeção comportamental no momento em que o backdoor é carregado.
O componente mais crítico observado é o driver amsdk.sys versão 1.0.600, associado ao WatchDog Antimalware. Ele compartilha base técnica com componentes derivados do Zemana Anti-Malware SDK, mas não estava classificado publicamente como vulnerável no momento da atividade descrita. O driver era assinado pela Microsoft e não estava coberto pela Microsoft Vulnerable Driver Blocklist nem por catálogos comunitários conhecidos de drivers abusáveis. Essa condição criou uma lacuna prática: em sistemas Windows 10 e Windows 11 atualizados, a confiança na assinatura permitia o carregamento do driver, enquanto a exploração da interface exposta pelo dispositivo possibilitava encerrar processos que deveriam resistir a manipulação por código não privilegiado.
A campanha também manteve compatibilidade com ambientes antigos usando ZAM.exe versão 3.0.0.000, um driver de Advanced Malware Protection já conhecido e bloqueado em listas de drivers vulneráveis. Essa escolha indica que o loader não depende de um único caminho de execução. Em Windows 7, o driver legado atende ao objetivo de matar processos de segurança; em Windows modernos, o driver WatchDog reduz atrito com controles baseados em listas estáticas. O resultado é um fluxo de ataque que adapta o componente de kernel ao alvo local antes de avançar para o downloader do ValleyRAT.
A entrega observada ocorre com frequência por arquivos .rar contendo um executável único ou uma DLL carregada por side-loading através de uma aplicação legítima. O vetor inicial exato não foi identificado, mas os artefatos analisados mostram loaders autocontidos com drivers, payloads codificados e lógica de evasão no mesmo binário. Em aproximadamente três quartos das amostras citadas, o loader não estava empacotado; em algumas variantes, foi usado UPX sem modificações. Um exemplo analisado era um PE de 64 bits empacotado com UPX, com nome interno Runtime Broker e timestamp de compilação 2025-06-03 06:38:30 UTC.
Na execução, o loader realiza verificações anti-VM, anti-sandbox e detecção de hipervisor. Se as verificações indicarem ambiente de análise, a execução é interrompida e uma mensagem falsa de erro é exibida. Há uma exceção explícita para nomes de computador DESKTOP-T3N3M3Q, DESKTOP-03AMF90 e WIN-VMHH95J6C26, permitindo que o programa continue nesses sistemas. Essa exceção é compatível com ambientes usados no desenvolvimento ou teste operacional do malware, porque evita que as próprias condições anti-análise bloqueiem a execução em máquinas controladas pelo operador.
Algumas amostras consultam http://ip-api.com/json para obter metadados do endereço IP público, incluindo os campos ISP e ORG. Quando esses campos batem com uma lista interna de organizações ou provedores, o processo termina e apresenta a mensagem The program does not support your configuration.. Esse comportamento deve ser tratado como controle de execução condicional: ele reduz exposição em redes de análise, fornecedores de segurança ou ambientes que os operadores desejam evitar, mas não prova sozinho o alvo geográfico de uma infecção específica.
Para persistência, o loader cria C:\Program Files\RunTime e grava uma cópia com o nome RuntimeBroker.exe. Também deposita o driver selecionado como Amsdk_Service.sys. O serviço Termaintor mantém a execução do loader na inicialização do sistema, enquanto Amsdk_Service fornece a configuração de registro necessária para carregar o driver vulnerável. A grafia Termaintor é um indicador útil porque se aproxima do nome de uma ferramenta pública conhecida por abusar driver vulnerável da Zemana para encerrar processos.
Os payloads incorporados ficam codificados na seção .rdata. Strings globais usam Base64, enquanto os payloads combinam hexadecimal e Base64. Após decodificação, o módulo downloader do ValleyRAT surge como DLL de 64 bits empacotada com UPX, convertida em shellcode e carregada de forma reflexiva em memória. A injeção ocorre tipicamente em um processo svchost.exe já em execução. A DLL preserva o nome interno 上线模块.dll no diretório de exportação e expõe funções load e run, que oferecem pontos alternativos de entrada para acionar a mesma lógica principal do DllMain.
A rotina de eliminação de EDR e antivírus usa o driver escolhido para falar com o dispositivo amsdk. A configuração do serviço de kernel é criada com RegCreateKeyW e RegSetValueExW, seguida de carregamento por NtLoadDriver. Em seguida, a função KillEDRMain percorre uma lista Base64 com 192 nomes únicos de processos de segurança. Para cada processo encontrado, o loader envia a sequência de IOCTLs 0x80002010 (IOCTL_REGISTER_PROCESS) e 0x80002048 (IOCTL_TERMINATE_PROCESS) via DeviceIoControl. Como a ação é executada por um driver de modo núcleo, processos com proteções PP/PPL também podem ser encerrados.
A superfície principal é composta por estáções e servidores Windows nos quais um atacante consiga executar o loader com condições suficientes para criar serviço de driver e carregar código de modo núcleo. A campanha diferencia sistemas antigos e modernos: Windows 7 recebe o driver ZAM.exe versão 3.0.0.000, já conhecido como vulnerável; Windows 10 e Windows 11 recebem amsdk.sys versão 1.0.600, que era assinado e não estava presente nas listas de bloqueio citadas. Ambientes que dependem apenas de hash conhecido ou de presença em blocklist ficam expostos a variantes assinadas ainda não catalogadas.
A atualização do fornecedor para wamsdk.sys versão 1.1.100 mitigou caminhos de elevação local de privilégio, mas a capacidade de encerramento arbitrário de processos permaneceu descrita como não totalmente resolvida. Depois disso, foi observada uma amostra com versão modificada do driver corrigido. A alteração de um único byte no campo de timestamp não autenticado da assinatura Authenticode produziu um hash diferente sem invalidar a assinatura. Isso é relevante para defesa porque políticas baseadas exclusivamente em hash podem falhar contra variações mínimas que continuam confiáveis para o Windows.
- Hosts Windows com criação de
C:\Program Files\RunTime,RuntimeBroker.exeeAmsdk_Service.sysdevem ser investigados como comprometidos até prova contrária. - Serviços
TermaintoreAmsdk_Serviceindicam persistência do loader e tentativa de carregar driver de modo núcleo. - Processos de segurança encerrados em sequência curta, especialmente antes de execução de DLL injetada em
svchost.exe, indicam uso da rotina de kill. - Sistemas que aceitam drivers assinados sem política adicional de controle de aplicação ficam mais dependentes da velocidade de atualização de blocklists.
- Ambientes com telemetria limitada de
NtLoadDriver, criação deSERVICE_KERNEL_DRIVEReDeviceIoControltêm menor visibilidade sobre a fase decisiva da evasão.
A busca deve começar por eventos de criação de serviço e carregamento de driver. Em Windows, a sequência de registro para serviço de kernel, seguida por NtLoadDriver, é mais discriminante que a presença isolada de um arquivo em disco. O nome Amsdk_Service e o tipo SERVICE_KERNEL_DRIVER são sinais diretos no fluxo descrito. Também vale correlacionar criação de Termaintor com gravação de RuntimeBroker.exe em C:\Program Files\RunTime, porque essa combinação une persistência do loader e componente de kernel usado para desativar defesas.
No endpoint, procure encerramentos anômalos de processos de EDR, antivírus e ferramentas de proteção. A campanha usa uma lista interna com 192 nomes de processos, com foco em produtos comuns no mercado asiático, especialmente na China. Mesmo quando a organização não usa esses produtos, tentativas repetidas de abrir handles, enumerar processos e emitir IOCTLs para um dispositivo de driver recém-carregado podem deixar rastros em EDR, Sysmon, ETW, logs de proteção de kernel ou telemetria de controle de aplicação.
Na rede, o downloader do ValleyRAT usa C2 configurado no payload, com endereços IP e portas armazenados em ordem reversa. Foram citados 156.234.58.194:52110 e 156.234.58.194:52111. O tráfego é cifrado com XOR usando a chave 363636003797e4383a36. Antes da comunicação final, algumas variantes podem consultar http://ip-api.com/json para obter ISP e ORG; essa requisição não é maliciosa por si só, mas, quando aparece próxima da execução de binário recém-extraído de .rar, criação de serviços e término de ferramentas de segurança, ela aumenta a confiança da detecção.
- Criação de pasta
C:\Program Files\RunTimeseguida por gravação deRuntimeBroker.exeeAmsdk_Service.sys. - Registro ou início dos serviços
TermaintoreAmsdk_Service, principalmente quando o segundo é do tipoSERVICE_KERNEL_DRIVER. - Carregamento de drivers
amsdk.sys,wamsdk.sys,ZAM.exeou arquivos renomeados com metadados compatíveis e assinatura válida. - Chamadas
DeviceIoControlpara o dispositivoamsdkusando IOCTLs0x80002010e0x80002048. - Encerramento coordenado de múltiplos processos de segurança, inclusive processos protegidos por PP/PPL.
- Injeção de shellcode ou DLL refletiva em
svchost.exeapós a etapa de desativação de proteção. - Consulta para
http://ip-api.com/jsonimediatamente antes de decisão de continuidade ou encerramento do loader. - Conexões para
156.234.58.194nas portas52110ou52111, quando presentes na telemetria local.
A mitigação deve priorizar o bloqueio de carregamento de drivers vulneráveis e variantes confiáveis apenas por assinatura. A campanha mostra que assinatura válida não equivale a comportamento seguro: um driver assinado pode expor primitivas perigosas de kernel, como encerramento de processos arbitrários. Organizações devem revisar políticas de controle de aplicação, Windows Defender Application Control, regras de bloqueio de drivers e allowlists internas para exigir confiança contextual, necessidade operacional e integridade de versão, não apenas validade Authenticode.
Controles baseados em hash continuam úteis, mas precisam ser acompanhados por detecção comportamental. A alteração de um byte em campo de timestamp não autenticado preservou a assinatura e mudou o hash, contornando bloqueios estáticos. Para reduzir esse risco, a defesa deve considerar publisher, cadeia de assinatura, caminho de instalação, nome de serviço, tipo de serviço, dispositivo exposto, versão do arquivo, reputação interna e comportamento do processo que solicita o carregamento. Drivers de produtos de segurança antigos ou não utilizados devem ser removidos de imagens, caches de instalação e repositórios de software corporativo.
Na resposta a incidente, um host com serviço Termaintor, pasta RunTime suspeita ou driver Amsdk_Service.sys deve ser isolado antes de tentativa de limpeza, porque a rotina de kernel pode derrubar agentes de proteção durante a coleta. A contenção deve preservar memória, lista de drivers carregados, chaves de serviço, arquivos em disco, eventos de criação de processo e conexões de rede. Depois da remoção do loader e dos serviços, é necessário validar reinicialização limpa, ausência de driver carregado, funcionamento dos agentes de segurança e inexistência de conexões residuais para a infraestrutura configurada.
- Ativar e manter política de bloqueio de drivers vulneráveis, complementada por regras próprias para
amsdk.sys,wamsdk.sys,ZAM.exee variantes renomeadas. - Monitorar criação de
SERVICE_KERNEL_DRIVERfora de janelas de manutenção e exigir justificativa operacional para novos serviços de kernel. - Bloquear execução a partir de
C:\Program Files\RunTimequando esse caminho não fizer parte do inventário aprovado. - Criar regras para
Termaintor,Amsdk_Service,RuntimeBroker.exefora do caminho legítimo esperado eAmsdk_Service.sys. - Investigar qualquer sequência de encerramento de processos de segurança seguida por injeção em
svchost.exe. - Rotacionar credenciais expostas no host comprometido somente após isolamento e remoção da persistência, para evitar captura durante a fase ativa do backdoor.
- Revisar imagens, golden images e pacotes corporativos para remover drivers antigos derivados do
Zemana Anti-Malware SDKque não sejam necessários. - Validar que EDR, antivírus e logging de kernel continuam operacionais após reinicialização e que não há novo serviço de driver registrado.
0 Comentários