Campanha explora driver legado `Truesight.sys` para encerrar processos de segurança no Windows

A operação usa variantes assinadas do Truesight.sys 2.0.2, tarefas agendadas persistentes, carga protegida por VMProtect e comunicação via DeviceIoControl para desativar componentes de EDR e antivírus.

Componente	driver legado Truesight.sys 2.0.2, o RogueKiller Antirootkit Driver da suíte Adlice, usado por um módulo de EDR/AV killer em Windows
Vetor	amostras iniciais atuam como downloaders disfarçados de aplicações, instaladores ou utilitários; estágios posteriores usam tarefas agendadas persistentes, DLL side-loading e cargas criptografadas para carregar o módulo que aciona o driver
Impacto	encerramento arbitrário de processos por meio do IOCTL 0x22E044, com foco em processos associados a soluções de segurança; o efeito confirmado é redução ou desativação de proteção local antes de fases posteriores da infecção
Prioridade	bloquear o carregamento do Truesight.sys 2.0.2 e de suas variantes, caçar serviços TCLService, tarefas no padrão MicrosoftEdgeUpdateTaskUA Task-S-1-5-18 [A-Za-z0-9]{5} e tráfego para buckets em regiões CN usados para baixar s.dat
Versões	a vulnerabilidade de encerramento arbitrário de processo afeta versões abaixo de 3.4.0; a versão 3.4.0 está corrigida; a campanha observada explora especificamente a versão 2.0.2
Artefatos	Truesight.sys, serviço TCLService, DLL S.dll, exportação CLRCreateInstance, função DeviceIoControl, caminho observado C:\\Windows\\System32\\drivers\\189atohci.sys e URL defangada https[://]22mm[.]oss-cn-hangzhou[.]aliyuncs[.]com/s[.]dat
IoCs	domínio defangado bung486[.]com, amostra inicial indicada como https[://]bung486[.]com/oot.setup.w06.exe e infraestrutura de buckets públicos em regiões CN, com exemplos envolvendo oss-cn-hangzhou
Mitigação	revisar políticas WDAC e a Microsoft Vulnerable Driver Blocklist, adicionar controles próprios por atributos do driver, versão, nome original, certificado e TBS hash, além de remover persistência e validar integridade das soluções de segurança

Resumo técnico

Uma campanha em larga escala está usando o driver legado Truesight.sys 2.0.2 como mecanismo de enfraquecimento de defesas em máquinas Windows. O componente é o RogueKiller Antirootkit Driver, associado à suíte da Adlice, e contém uma vulnerabilidade conhecida de encerramento arbitrário de processos em versões anteriores à 3.4.0. A operação não se limita ao abuso de uma versão já amplamente catalogada: o fluxo observado se concentra na versão 2.0.2, que permaneceu menos visível em mecanismos comuns de bloqueio e detecção, apesar de preservar a capacidade vulnerável usada para matar processos.

O ponto técnico central é o uso de um driver em modo núcleo para contornar as barreiras que protegem processos de segurança no Windows. Componentes de EDR e antivírus podem operar como processos protegidos, o que dificulta o encerramento direto a partir de código em modo usuário. A campanha resolve essa restrição acionando o driver vulnerável e enviando uma requisição de controle que permite encerrar processos escolhidos. O módulo de EDR/AV killer faz isso com DeviceIoControl, usando o IOCTL 0x22E044 contra o dispositivo exposto pelo Truesight.sys.

A escala do abuso é relevante para defesa porque foram observadas mais de 2.500 variantes distintas da mesma versão 2.0.2, com hashes diferentes. A manipulação parece alterar o arquivo apenas o suficiente para produzir identificadores diferentes, mantendo a assinatura digital válida. Essa combinação aumenta o custo de detecção baseada somente em hash e exige políticas que considerem metadados do arquivo, versão, certificado, TBS hash, nome original, comportamento de carregamento e sequência de uso do driver.

A operação também apresenta uma cadeia de execução em múltiplos estágios. Amostras iniciais atuam como downloaders e se disfarçam de aplicações conhecidas, instaladores ou utilitários. Estágios posteriores passam a usar tarefas agendadas persistentes, DLL side-loading contra binários benignos assinados e cargas armazenadas em disco de forma criptografada, com aparência de arquivos comuns como PNG, JPG ou GIF. Quando decifradas em memória, essas cargas resultam em binários PE de 32 bits ou shellcode executado diretamente.

Fluxo técnico

A etapa inicial da infecção é composta por downloaders que não necessariamente mantêm persistência própria. Eles preparam o ambiente para os estágios seguintes e podem baixar componentes adicionais a partir de infraestrutura hospedada em região chinesa de nuvem pública. O material analisado indica uso de buckets em regiões CN para distribuição de payloads e operação de servidores C2. Um exemplo de padrão de download do driver é https[://]22mm[.]oss-cn-hangzhou[.]aliyuncs[.]com/s[.]dat, em que o identificador da região OSS e o nome do bucket podem variar, mas a localização permanece dentro da China.

Nos estágios Stage2 e Stage3, a execução passa a envolver persistência por tarefas agendadas. O padrão observado para o nome das tarefas segue MicrosoftEdgeUpdateTaskUA Task-S-1-5-18 [A-Za-z0-9]{5}, o que imita uma convenção associada a atualização de navegador, mas com sufixo variável. Esses estágios usam DLL side-loading, escolhendo um binário benigno, original e assinado como alvo para carregar a DLL maliciosa colocada no mesmo contexto de execução. O resultado é uma cadeia que mistura componentes confiáveis com cargas escondidas, dificultando análise superficial baseada apenas na reputação do executável principal.

As cargas entregues junto com Stage2 e Stage3 são criptografadas no disco e formatadas para parecer arquivos de imagem. Após a leitura e descriptografia, o conteúdo vira um binário PE de 32 bits carregado reflexivamente ou shellcode executado diretamente na memória. Quando a carga descriptografada é um PE de 32 bits, ela aparece protegida pelo empacotador comercial VMProtect. A escolha por 32 bits e por uma versão recente do protetor eleva a dificuldade de reconstrução, especialmente porque muitas técnicas públicas de reversão para esse protetor são mais maduras em binários de 64 bits ou em versões antigas.

O módulo responsável pelo encerramento de processos aparece no Stage3 como uma DLL de 32 bits chamada S.dll, com uma exportação única denominada CLRCreateInstance. Depois de descriptografada, essa DLL contém a lógica que interage com o driver. O módulo pode depender de uma instalação prévia do Truesight.sys, mas também consegue implantar o driver caso ele ainda não esteja presente. A instalação costuma criar o serviço TCLService, e algumas amostras gravaram o driver em C:\\Windows\\System32\\drivers\\189atohci.sys.

O mecanismo de abuso foi validado pelo tráfego entre o módulo e o driver. A DLL chama DeviceIoControl e envia o IOCTL 0x22E044, associado à capacidade de encerramento arbitrário de processos. O alvo não é escolhido dinamicamente por descoberta ampla; há uma lista codificada de 192 nomes de processos, principalmente relacionados a produtos de segurança. A consequência confirmada é a interrupção de componentes defensivos no host, abrindo espaço operacional para fases posteriores da mesma infecção sem que isso, por si só, comprove roubo de dados, movimento lateral ou outro impacto além do controle local de processos.

A escolha do Truesight.sys 2.0.2 também explora uma condição histórica da validação de assinatura de drivers no Windows. A partir do Windows 10 versão 1607, drivers novos em modo núcleo passaram a depender de assinatura via Developer Portal da Microsoft. O driver 2.0.2 se enquadra em uma exceção: drivers assinados com certificado final emitido antes de 29 de julho de 2015 e encadeados a uma autoridade certificadora cross-signed suportada. Por isso, até versões recentes do Windows 11 podem carregar esse driver legado, desde que outros controles não o bloqueiem.

Superfície afetada

A superfície de risco está em endpoints Windows capazes de carregar o driver legado Truesight.sys 2.0.2 e que não tenham controles eficazes para bloquear essa família de drivers vulneráveis por atributos além do hash. A versão 3.3.0 já era conhecida por abuso e aparecia em listas de bloqueio e projetos de catalogação, mas a campanha explorou a versão 2.0.2, que não era reconhecida da mesma forma em mecanismos comuns no momento da análise. Isso desloca a defesa de um modelo centrado em hashes conhecidos para um modelo de controle de drivers por versão, assinatura, metadados, TBS hash e comportamento.

Os sistemas expostos são aqueles em que um downloader consegue executar, baixar o driver ou suas variantes, instalar serviço em modo núcleo e acionar a interface do driver. A cadeia também depende de execução de tarefas agendadas persistentes e de DLL side-loading em etapas posteriores. Portanto, a superfície prática envolve estáções com permissão suficiente para instalação de driver, ambientes que permitem criação de tarefas sob nomes semelhantes aos de atualizações legítimas e controles de aplicação que não correlacionam binário assinado benigno com DLL inesperada e payload criptografado adjacente.

A distribuição observada inclui iscas ligadas a aplicações, instaladores, utilitários, sites enganosos e canais de phishing em aplicativos de mensagens. Um domínio registrado em 29 de setembro de 2024, bung486[.]com, foi usado para atrair visitantes com ofertas de luxo e redirecionar cliques em ícones de mensageria para canais de phishing. Em 2 de outubro de 2024, a URL https[://]bung486[.]com/oot.setup.w06.exe estava associada a uma das amostras iniciais envolvidas na campanha. Uma das primeiras amostras que implantava o driver legado apareceu em meados de junho de 2024; por volta de julho de 2024, a operação passou do driver original para milhares de variantes.

A telemetria mencionada indica concentração regional: cerca de 75% das vítimas estavam na China, e a maior parte restante em outras regiões da Ásia, como Singapura e Taiwan. A campanha foi associada com confiança média-alta ao ator Silver Fox, com base em vetor de infecção, cadeia de execução, semelhança de amostras iniciais com campanhas atribuídas anteriormente e padrões históricos de alvo. Essa atribuição deve ser tratada como avaliação analítica, não como prova isolada derivada de um único artefato.

• Endpoints Windows nos quais o Truesight.sys 2.0.2 pode ser carregado por exceções históricas de assinatura de driver.
• Ambientes que dependem apenas de hash ou de listas conhecidas e não bloqueiam variantes assinadas do mesmo driver legado.
• Hosts com tarefas agendadas no padrão MicrosoftEdgeUpdateTaskUA Task-S-1-5-18 [A-Za-z0-9]{5} e execução por DLL side-loading.
• Sistemas que apresentam serviço TCLService, arquivo de driver em caminhos como C:\\Windows\\System32\\drivers\\189atohci.sys ou download de s.dat a partir de buckets em regiões CN.

Hunting e telemetria

A investigação deve partir da correlação entre carregamento de driver, criação de serviço, atividade de tarefa agendada e comunicação com buckets externos. O simples aparecimento de um hash conhecido é insuficiente, pois a campanha produziu mais de 2.500 variantes únicas do mesmo Truesight.sys 2.0.2. A caça precisa considerar metadados consistentes entre variantes, como versão de arquivo, nome original, assinatura, certificado, data de compilação preservada e capacidade operacional exposta pelo IOCTL vulnerável.

Em endpoint, procure eventos de instalação ou carregamento de driver associados ao serviço TCLService, principalmente quando o arquivo tiver nome destoante do produto legítimo ou for gravado em C:\\Windows\\System32\\drivers\\189atohci.sys. Também é relevante procurar chamadas de controle de dispositivo para o driver, especialmente quando um processo de usuário invoca DeviceIoControl com 0x22E044 e, em seguida, processos de EDR, antivírus ou componentes de monitoramento deixam de executar. A sequência entre chamada ao driver e término de processo de segurança é um sinal comportamental mais resistente à variação de hash.

Em telemetria de persistência, a prioridade é identificar tarefas agendadas com aparência de atualização legítima, mas que seguem o padrão MicrosoftEdgeUpdateTaskUA Task-S-1-5-18 [A-Za-z0-9]{5}. O comando executado pela tarefa deve ser inspecionado junto com o diretório de trabalho, DLLs no mesmo caminho do binário assinado e arquivos com extensão de imagem que sejam lidos como carga criptografada. Em muitos ambientes, a combinação de binário assinado benigno, DLL inesperada e payload com extensão PNG, JPG ou GIF em diretório temporário ou de usuário já justifica isolamento e análise.

Na rede, monitore conexões para buckets públicos em regiões CN, especialmente quando o caminho final se parece com s.dat e a origem é um processo recém-baixado ou uma cadeia iniciada por instalador não aprovado. O domínio bung486[.]com e a URL https[://]bung486[.]com/oot.setup.w06.exe são artefatos concretos da operação, mas a defesa não deve limitar a detecção a eles. A infraestrutura pode variar em nome de bucket, região OSS e domínio de entrega, mantendo o mesmo objetivo operacional de buscar driver, cargas criptografadas e módulos intermediários.

• Criação do serviço TCLService seguida de carregamento de driver em modo núcleo.
• Presença de Truesight.sys 2.0.2 ou variantes assinadas com hashes distintos e metadados compatíveis.
• Uso de DeviceIoControl com IOCTL 0x22E044 a partir de módulo de usuário, seguido de encerramento de processos de segurança.
• Tarefas agendadas com nome semelhante a MicrosoftEdgeUpdateTaskUA Task-S-1-5-18 [A-Za-z0-9]{5}.
• DLL S.dll com exportação CLRCreateInstance e proteção por VMProtect.
• Arquivos aparentemente PNG, JPG ou GIF que são lidos, descriptografados e convertidos em PE de 32 bits ou shellcode.
• Conexões para oss-cn-hangzhou ou outros buckets de região CN com download de s.dat.

Mitigação

A contenção deve começar pelo bloqueio do driver vulnerável e de suas variantes, sem depender exclusivamente de hash. A Microsoft Vulnerable Driver Blocklist pode bloquear drivers conhecidos por atributos como nome original, intervalo de versão, hash e TBS hash do certificado, mas a campanha demonstrou que versões legadas menos visíveis podem permanecer fora de controles comuns. Ambientes Windows devem revisar WDAC, políticas de bloqueio de drivers e regras internas para impedir carregamento do Truesight.sys 2.0.2, considerando versão, assinatura, cadeia de certificado e propriedades do arquivo.

Em hosts suspeitos, a resposta deve validar se o driver está carregado, se o serviço TCLService existe e se há tarefas agendadas persistentes no padrão observado. A remoção isolada do arquivo pode não ser suficiente se Stage2 ou Stage3 permanecerem com capacidade de baixar e reinstalar o driver. O processo de resposta precisa eliminar tarefas, binários benignos usados para side-loading, DLLs adjacentes, arquivos criptografados que simulam imagens e quaisquer artefatos baixados da infraestrutura em nuvem pública.

Para reduzir recorrência, aplique controles de aplicação que tratem DLL side-loading como comportamento de risco quando um executável assinado carrega biblioteca não esperada em diretório controlado por usuário ou por instalador externo. Também é necessário monitorar a criação de tarefas agendadas com nomes que imitam atualização de navegador, bloquear execução de instaladores não aprovados e registrar eventos de carregamento de driver em modo núcleo. Como a campanha usa VMProtect, a classificação por empacotamento deve ser combinada com comportamento, origem, persistência e relação com processos de segurança terminados.

Depois da contenção, valide a integridade operacional das soluções de segurança. A campanha tem como objetivo confirmado encerrar processos defensivos; portanto, o retorno de EDR e antivírus deve ser verificado por serviço, processo, driver, sensor, política e comunicação com console. Também é recomendável revisar eventos próximos ao encerramento de processos para identificar a fase anterior da cadeia, incluindo o downloader inicial e os canais de entrega. A campanha tem indícios de distribuição por sites enganosos e phishing em mensageria, então a resposta deve incluir bloqueio de artefatos conhecidos e reavaliação de controles de navegação e download.

• Bloquear Truesight.sys 2.0.2 e variantes por versão, assinatura, certificado, TBS hash e nome original, além de hash quando disponível.
• Revisar WDAC e políticas de driver vulnerável para impedir carregamento de drivers legados que preservam capacidade de encerramento arbitrário de processo.
• Remover serviço TCLService, tarefas agendadas suspeitas e arquivos associados a Stage2, Stage3, DLL side-loading e cargas criptografadas.
• Investigar DeviceIoControl com 0x22E044 e correlacionar com parada de processos de EDR ou antivírus.
• Bloquear comunicação para buckets e URLs observados, incluindo https[://]22mm[.]oss-cn-hangzhou[.]aliyuncs[.]com/s[.]dat, quando aplicável ao ambiente.
• Verificar se sensores de segurança voltaram a operar após a contenção, incluindo processos protegidos, serviços, drivers e telemetria para a console.
• Revisar pontos de entrega por phishing, instaladores não aprovados e sites enganosos como bung486[.]com.