HoneyMyte atualiza CoolClient com um driver de kernel assinado para esconder processos e proteger o canal C2

Kaspersky publicou uma análise que atribui ao ator conhecido como HoneyMyte (também Mustang Panda) uma versão atualizada do backdoor CoolClient que incorpora um componente de kernel assinado capaz de esconder e proteger processos, arquivos, entradas do registro e informações relacionadas ao canal de comando e controle (C2). Feito confirmado: a assinatura do driver aparece em nome de Nanjing Ranyi Technology Co., Ltd. e o pacote malicioso foi observado em ataques contra organizações em Mianmar, Mongólia, Paquistão e Rússia, incluindo entidades governamentais, de acordo com a assinatura de segurança.

Do ponto de vista técnico, a amostra documentada pela Kaspersky mostra uma arquitetura em várias etapas: um carregador inicial (usualmente PlugX nas campanhas observadas) entrega uma cadeia que abusa de DLL sideloading e tarefas programadas para alcançar persistência em SYSTEM; uma segunda etapa chamada loadcert.ini ocupa-se de elevar privilégios, implantar o driver do kernel (msagent.sys) quando o processo tem acesso ao Service Control Manager e do privilégio SeTcbPrivilege, e finalmente carrega o backdoor cert.ini que mantém a comunicação com os servidores C2. Feito confirmado: O driver é instalado como serviço (msagent) e comunica com o componente em espaço de usuário através de chamadas IOCTL.

O rootkit de kernel estende a capacidade de evasão de CoolClient de várias maneiras: registra processos como “confiables” para permitir acesso privilegiado a objetos protegidos; injeta seu código em processos como synchost.exe e reduz permissões ao abrir handles sobre processos protegidos para bloquear a terminação ou injeção; esconde entradas da lista ativa de processos; filtra a informação de rede para remover endereços C2 de respostas a consultas em espaço de usuário; e emprega um minifiltro de sistema de arquivos e callbacks de registro para impedir inspeção ou remoção de artefatos. Kaspersky identificou três IOCTL usados na execução normal (0x222120, 0x2221E0, 0x2220F0) mas o driver contém 33 manejadores no total, sugerindo funcionalidade adicional disponível embora não observada nessa amostra concreta.

Consequências práticas: A presença de um driver assinado e projetado para proteger componentes maliciosos complica a detecção e a remediação. Um ator com acesso a SCM e privilégios de alto nível pode instalar e arrancar um driver que restaura ou bloqueia a eliminação de malware, oculta rastros de exfiltração e garante persistência entre reinícios. Para organizações governamentais e redes críticas, isso aumenta o risco de campanhas de espionagem sustentada e roubo de credenciais e dados, além de dificultar a resposta forense.

Há aspectos confirmados e outros que continuam sendo estimativas ou sujeitos a verificação. Confirmado: O Kaspersky publicou hashes, rotas e domínios C2 associados e documentou a cadeia de execução em pelo menos uma campanha em Mianmar onde o PlugX atua como ponto de entrada e cria uma falsa pasta do Windows Defender para evitar a digitalização. Estimado ou incerto: A ligação entre os drivers antigos assinados com o mesmo certificado (compilados em torno de 2013) e a atividade atual não está testada; a Kaspersky não encontrou evidências diretas que liguem esses binários antigos com as operações recentes, embora a reutilização do certificado levanta questões sobre compromisso histórico ou uso de assinaturas roubadas.

Se você gerencia sistemas Windows ou faz parte da equipe de segurança, há medidas concretas e verificáveis que você deve tomar agora mesmo. Primeiro, detecte indicadores de compromisso: verifique a presença de msagent.sys e os hashes publicados pela Kaspersky, examine novos serviços com nomes suspeitos (por exemplo, msagent ou media_updaten), e procure tarefas programadas e exclusões na Microsoft Defender que apontem para pastas invulgares. Use ferramentas Microsoft e Sysinternals para auditar controladores e serviços (por exemplo, sc query, driverquery, fltmc, Autoruns e Process Explorer). Um comando útil para revisar exclusões de Defender desde PowerShell é Get-MpPreference, que mostra exclusões configuradas.

Segundo, limite as capacidades de instalação de drivers e criação de serviços: aplique políticas de controle de dispositivos e assinar drivers em modo kernel (Windows impõe requisitos estritos, ver mais na documentação da Microsoft sobre assinatura de código para drivers), e restrinja o privilégio SeTcbPrivilege às contas que realmente o exigem. A política de assinatura de drivers e administração do Service Control Manager ( documentação do SCM) são recursos úteis para configurar defesas técnicas e rever configurações.

Terceiro, se detectar sinais de compromisso: isole a equipe afetada da rede, preserve memória e voltado de disco para análise forense antes de reiniciar, e coordene com uma equipe de resposta a incidentes. Remover um driver malicioso que implementa proteções pode exigir técnicas avançadas (por exemplo, inicialização em modo seguro ou a partir de um ambiente externo) e supervisão de callbacks de kernel e minifiltros. Se você não tiver experiência interna, contacte fornecedores de resposta a incidentes ou seu provedor de antivírus para assistência especializada.

Finalmente, tome medidas preventivas: aplique com rigor adesivos e atualizações, minimize o uso de privilégios administrativos permanentes, controle a instalação de software com integridade/whitelisting e verifique as ferramentas de segurança para detectar exclusões suspeitas ou renombradas. O Kaspersky já publicou IoC e hashes que deveriam ser incorporados em listas de bloqueio e processos de busca em sua organização; fazer pesquisas retroativas em telemetry ajudará a detectar possíveis compromissos prévios.

Em suma, a novidade principal que documenta a Kaspersky é a incorporação de um driver do kernel assinado que amplia as capacidades de ocultação e proteção de CoolClient, o que complica a detecção e remediação. Enquanto as evidências apontam para campanhas específicas na Ásia e na Rússia e para um padrão consistente de implantação após o PlugX, ficam incógnitas sobre o histórico do certificado e o uso completo das 33 IOCTLs implementadas. As organizações devem tratar esta variante como uma ameaça séria para a persistência e exfiltração, e priorizar detecção baseada no IoC, limitação de privilégios e procedimentos de resposta forense para a mitigar.