HoneyMyte actualiza CoolClient con un driver de kernel firmado para ocultar procesos y proteger el canal C2

Kaspersky ha publicado un análisis que atribuye al actor conocido como HoneyMyte (también Mustang Panda) una versión actualizada del backdoor CoolClient que incorpora un componente de kernel firmado capaz de ocultar y proteger procesos, archivos, entradas del registro y la información relacionada con el canal de mando y control (C2). Hecho confirmado: la firma del driver aparece a nombre de Nanjing Ranyi Technology Co., Ltd. y el paquete malicioso fue observado en ataques contra organizaciones en Myanmar, Mongolia, Pakistán y Rusia, incluyendo entidades gubernamentales, según la firma de seguridad.

Desde el punto de vista técnico, la muestra documentada por Kaspersky muestra una arquitectura en varias etapas: un cargador inicial (usualmente PlugX en las campañas observadas) entrega una cadena que abusa de DLL sideloading y tareas programadas para alcanzar persistencia en SYSTEM; una segunda etapa llamada loadcert.ini se ocupa de elevar privilegios, desplegar el driver de kernel (msagent.sys) cuando el proceso dispone de acceso al Service Control Manager y del privilegio SeTcbPrivilege, y finalmente se carga el backdoor cert.ini que mantiene la comunicación con los servidores C2. Hecho confirmado: el driver se instala como servicio (msagent) y se comunica con el componente en espacio de usuario mediante llamadas IOCTL.

El rootkit de kernel extiende la capacidad de evasión de CoolClient de varias maneras: registra procesos como “confiables” para permitirles acceso privilegiado a objetos protegidos; inyecta su código en procesos como synchost.exe y reduce permisos al abrir handles sobre procesos protegidos para bloquear terminación o inyección; oculta entradas de la lista activa de procesos; filtra la información de red para eliminar direcciones C2 de respuestas a consultas en espacio de usuario; y emplea un minifiltro de sistema de archivos y callbacks de registro para impedir inspección o borrado de artefactos. Kaspersky identificó tres IOCTL usados en la ejecución normal (0x222120, 0x2221E0, 0x2220F0) pero el driver contiene 33 manejadores en total, lo que sugiere funcionalidad adicional disponible aunque no observada en esa muestra concreta.

Consecuencias prácticas: la presencia de un driver firmado y diseñado para proteger componentes maliciosos complica la detección y la remediación. Un actor con acceso a SCM y privilegios de alto nivel puede instalar y arrancar un driver que restaura o bloquea la eliminación de malware, oculta rastros de exfiltración y garantiza persistencia entre reinicios. Para organizaciones gubernamentales y redes críticas, esto aumenta el riesgo de campañas de espionaje sostenido y robo de credenciales y datos, además de dificultar la respuesta forense.

Hay aspectos confirmados y otros que siguen siendo estimaciones o sujetos a verificación. Confirmado: Kaspersky publicó hashes, rutas y dominios C2 asociados y documentó la cadena de ejecución en al menos una campaña en Myanmar donde PlugX actúa como punto de entrada y se crea una falsa carpeta de Windows Defender para evadir escaneo. Estimado o incierto: el vínculo entre drivers antiguos firmados con el mismo certificado (compilados alrededor de 2013) y la actividad actual no está probado; Kaspersky no halló evidencias directas que conecten esos binarios antiguos con las operaciones recientes, aunque la reutilización del certificado plantea preguntas sobre compromiso histórico o uso de firmas robadas.

Si usted administra sistemas Windows o forma parte del equipo de seguridad, hay medidas concretas y verificables que debe tomar ahora mismo. Primero, detecte indicadores de compromiso: verifique la presencia de msagent.sys y los hashes publicados por Kaspersky, examine servicios nuevos con nombres sospechosos (por ejemplo msagent o media_updaten), y busque tareas programadas y exclusiones en Microsoft Defender que apunten a directorios inusuales. Use herramientas de Microsoft y Sysinternals para auditar controladores y servicios (por ejemplo sc query, driverquery, fltmc, Autoruns y Process Explorer). Un comando útil para revisar exclusiones de Defender desde PowerShell es Get-MpPreference, que muestra exclusiones configuradas.

Segundo, limite las capacidades de instalación de drivers y creación de servicios: aplique políticas de control de dispositivos y firmar drivers en modo kernel (Windows impone requisitos estrictos, ver más en la documentación de Microsoft sobre firma de código para drivers), y restrinja el privilegio SeTcbPrivilege a las cuentas que verdaderamente lo requieren. La política de firma de drivers y la administración del Service Control Manager (documentación de SCM) son recursos útiles para configurar defensas técnicas y revisar configuraciones.

Tercero, si detecta indicios de compromiso: aísle el equipo afectado de la red, preserve memoria y volcado de disco para análisis forense antes de reiniciar, y coordine con un equipo de respuesta a incidentes. Remover un driver malicioso que implementa protecciones puede requerir técnicas avanzadas (por ejemplo, arranque en modo seguro o desde un entorno externo) y la supervisión de callbacks de kernel y minifiltros. Si no dispone de experiencia interna, contacte a proveedores de respuesta a incidentes o a su proveedor de antivirus para asistencia especializada.

Finalmente, adopte medidas preventivas: aplique con rigor parches y actualizaciones, minimice el uso de privilegios administrativos permanentes, controle la instalación de software con integridad/whitelisting y revise las herramientas de seguridad para detectar exclusiones sospechosas o renombradas. Kaspersky ya publicó IoC y hashes que deberían incorporarse a listas de bloqueo y a procesos de búsqueda en su organización; hacer búsquedas retroactivas en telemetry ayudará a detectar posibles compromisos previos.

En resumen, la novedad principal que documenta Kaspersky es la incorporación de un driver de kernel firmado que amplía las capacidades de ocultación y protección de CoolClient, lo que complica la detección y remediación. Mientras las evidencias apuntan a campañas específicas en Asia y Rusia y a un patrón consistente de despliegue tras PlugX, quedan incógnitas sobre el historial del certificado y el uso completo de las 33 IOCTLs implementadas. Las organizaciones deben tratar esta variante como una amenaza seria para la persistencia y la exfiltración, y priorizar detección basada en IoC, limitación de privilegios y procedimientos de respuesta forense para mitigarla.