CosmicStrand: Rootkit UEFI en Firmware de Placas ASUS y Gigabyte con Chipset H81
Analisis tecnico de CosmicStrand, rootkit UEFI que modifica CSMCORE DXE en placas ASUS y Gigabyte H81. Atribuido a actor chino. Cadena boot completa en memoria.
Un rootkit de firmware con una decada de historia operacional
En julio de 2022, el equipo GReAT de Kaspersky publico el analisis de CosmicStrand, un rootkit UEFI que llevaba operando silenciosamente desde al menos 2016. No era un descubrimiento completamente nuevo. En 2017, la empresa china Qihoo360 habia documentado una variante anterior bajo un nombre diferente, aunque con menor detalle tecnico. Lo que Kaspersky revelo fue la escala temporal y la sofisticacion de la cadena de infeccion completa.
CosmicStrand no afecta a cualquier placa base. Sus objetivos son especificos: placas ASUS y Gigabyte equipadas con el chipset Intel H81. Esta especificidad no es casual. El rootkit modifica el driver CSMCORE DXE, un componente del Compatibility Support Module que permite arrancar sistemas operativos legacy en hardware UEFI. La implementacion del CSM varia entre fabricantes y chipsets, lo que obliga al atacante a desarrollar variantes adaptadas a cada combinacion de hardware.
La atribucion apunta a un actor de amenazas de habla china, basandose en la infraestructura C2, la distribucion geografica de las victimas (China, Iran, Vietnam y Rusia) y similitudes de codigo con malware previamente atribuido a actores de ese origen.
El Compatibility Support Module como superficie de ataque
Para entender por que CosmicStrand elige CSMCORE DXE como objetivo, es necesario comprender el papel del CSM en la arquitectura UEFI.
Que es el CSM
El Compatibility Support Module es un componente del firmware UEFI que proporciona compatibilidad con el modo de arranque legacy (BIOS). Su funcion principal es emular los servicios de interrupcion del BIOS clasico (INT 10h, INT 13h, INT 15h) para que sistemas operativos antiguos o herramientas que dependen del modo legacy puedan funcionar en hardware UEFI moderno.
CSMCORE DXE es el driver principal del CSM. Se ejecuta durante la fase DXE (Driver Execution Environment) del arranque UEFI, antes de que el sistema operativo tome el control. Tiene acceso completo a los servicios de arranque UEFI (EFI_BOOT_SERVICES) y se carga desde la flash SPI de la placa base.
Por que el chipset H81
El chipset Intel H81, lanzado en 2013 para la plataforma LGA 1150 (4a generacion Haswell), fue uno de los chipsets de gama de entrada mas populares en mercados de consumo y corporativos de bajo coste. Dos factores lo hacen relevante:
- Volumen de despliegue: millones de placas H81 en circulacion, muchas en entornos corporativos con ciclos de renovacion lentos
- Proteccion de firmware limitada: las implementaciones H81 de ASUS y Gigabyte de esa epoca tenian protecciones de escritura en flash SPI menos robustas que generaciones posteriores. Intel Boot Guard no estaba habilitado por defecto en muchas de estas placas
La combinacion de volumen, proteccion debil y CSM habilitado por defecto creo una superficie de ataque amplia y persistente.
Cadena de infeccion: del firmware al shellcode en modo usuario
La cadena de CosmicStrand es notable por su precision quirurgica. Cada etapa hookea exactamente una funcion para escalar al siguiente nivel del arranque, y toda la operacion ocurre en memoria sin escribir un solo archivo en disco.
Etapa 1: CSMCORE DXE modificado en flash SPI
El atacante escribe una version parcheada de CSMCORE DXE en la flash SPI de la placa base. El vector de acceso inicial para lograr esta escritura no fue documentado con certeza. Las hipotesis incluyen acceso fisico, explotacion de vulnerabilidades en el firmware de gestion, o el uso de un driver de kernel con privilegios de escritura en la flash SPI.
El CSMCORE modificado conserva toda su funcionalidad original. La modificacion anade un hook en la funcion HandleProtocol de EFI_BOOT_SERVICES. Esta funcion es invocada repetidamente durante el arranque por cada componente que necesita acceder a una interfaz de protocolo UEFI.
CSMCORE DXE (modificado en flash SPI)
└── Hook: EFI_BOOT_SERVICES.HandleProtocol
└── Condicion: espera a que se cargue el Windows Boot Manager
Etapa 2: parcheo del Windows Boot Manager
El hook en HandleProtocol monitoriza cada invocacion buscando un patron especifico. Cuando detecta que el Windows Boot Manager (bootmgfw.efi) esta siendo cargado, intercepta el proceso y parchea el binario en memoria.
El parche es minimo: modifica una funcion del Boot Manager para que, cuando se cargue el siguiente componente de la cadena de arranque (winload.efi, el OS loader), aplique una segunda modificacion.
Windows Boot Manager (bootmgfw.efi) — parcheado en memoria
└── Hook: funcion de carga del OS loader
└── Accion: parchear winload.efi cuando se cargue
Etapa 3: parcheo del OS loader
El Boot Manager parcheado modifica winload.efi (el OS loader de Windows) cuando este se carga en memoria. El parche en el OS loader tiene un objetivo preciso: modificar el kernel de Windows (ntoskrnl.exe) durante su carga.
OS Loader (winload.efi) — parcheado en memoria
└── Hook: funcion de carga del kernel
└── Accion: parchear ntoskrnl.exe cuando se cargue
Etapa 4: parcheo del kernel y shellcode en modo usuario
El OS loader parcheado modifica ntoskrnl.exe en memoria durante su carga. El codigo inyectado en el kernel se ejecuta durante la inicializacion de Windows y realiza una operacion especifica: copia shellcode a una direccion de memoria conocida y predeterminada, y despliega un componente en modo usuario que se conecta a los servidores C2 del atacante.
Kernel de Windows (ntoskrnl.exe) — parcheado en memoria
└── Shellcode en direccion de memoria conocida
└── Componente modo usuario → conexion HTTP a C2
La cadena completa opera sin escribir ningun archivo en disco. Cada etapa parchea la siguiente en memoria. Al reiniciar, la cadena se reestablece desde el firmware.
Comunicacion C2: simplicidad deliberada
El componente de modo usuario desplegado por CosmicStrand utiliza un protocolo C2 sorprendentemente simple. La comunicacion se realiza por HTTP plano hacia dominios hardcodeados en el binario del shellcode.
Esta simplicidad contrasta con la sofisticacion de la cadena de arranque. Rootkits como MoonBounce despliegan backdoors modulares complejos (ScrambleCross/SideWalk) con cifrado y carga dinamica de plugins. CosmicStrand opta por un implante minimalista cuya unica funcion es mantener la comunicacion con el operador.
La razon probable es operacional: un C2 simple tiene menos puntos de fallo, deja menos trazas en el sistema y es mas facil de mantener a lo largo de los anos. Considerando que CosmicStrand lleva operando desde al menos 2016, la durabilidad del implante parece haber sido prioritaria sobre la funcionalidad avanzada.
Los dominios C2 fueron hardcodeados, sin mecanismo de generacion de dominios (DGA) ni infraestructura de fallback documentada. Esto sugiere que el operador mantiene control directo sobre la infraestructura y la renueva manualmente cuando es necesario.
Historial operacional: muestras desde 2016
Uno de los hallazgos mas significativos de la investigacion es la antiguedad de CosmicStrand. Kaspersky identifico muestras que datan de finales de 2016, y la variante documentada por Qihoo360 en 2017 confirma que el rootkit llevaba al menos un ano operando antes de ser detectado publicamente por primera vez.
Esto situa a CosmicStrand como contemporaneo de LoJax en terminos de desarrollo, aunque LoJax no fue descubierto hasta 2018. La cronologia sugiere que los rootkits UEFI no fueron un fenomeno aislado de un unico actor, sino una capacidad desarrollada en paralelo por multiples grupos de amenazas avanzados durante la segunda mitad de la decada de 2010.
Las victimas identificadas se distribuyen en China, Iran, Vietnam y Rusia. El perfil no encaja con un patron de espionaje dirigido a un sector especifico, sino con una campaña amplia de recopilacion de inteligencia.
Comparativa con otros rootkits UEFI
La siguiente tabla posiciona a CosmicStrand en el contexto de los rootkits UEFI documentados in-the-wild.
| Caracteristica | LoJax (2018) | MosaicRegressor (2020) | MoonBounce (2022) | CosmicStrand (2022) |
|---|---|---|---|---|
| Descubridor | ESET | Kaspersky GReAT | Kaspersky GReAT | Kaspersky GReAT / Qihoo360 |
| Atribucion | APT28 (Rusia) | Actor chino | APT41/Winnti (China) | Actor de habla china |
| Hardware objetivo | Generico | Generico | Generico | ASUS/Gigabyte H81 |
| Componente modificado | Nuevo driver DXE | Nuevos drivers DXE | CORE_DXE existente | CSMCORE DXE existente |
| Cadena en memoria | Parcial (escribe en disco) | Parcial (escribe en disco) | Completa | Completa |
| Protocolo C2 | HTTP simple | Diversos | HTTPS (ScrambleCross) | HTTP a dominios hardcodeados |
| Muestras mas antiguas | 2017 | 2019 | 2021 | 2016 |
| Complejidad de cadena | Baja | Media | Muy Alta | Alta |
| Especificidad de hardware | Baja | Baja | Baja | Alta (chipset H81) |
Dos observaciones relevantes. CosmicStrand y MoonBounce comparten la tecnica de modificar un driver DXE existente en lugar de anadir uno nuevo, pero fueron desarrollados por actores diferentes (aunque ambos de origen chino). CosmicStrand es probablemente el mas antiguo de los cuatro en terminos de fecha de primera muestra conocida.
Atribucion: evidencias del actor de habla china
La atribucion de CosmicStrand a un actor de habla china se sustenta en multiples lineas de evidencia convergentes:
Infraestructura C2. Los dominios y servidores utilizados para la comunicacion muestran patrones de registro y hosting consistentes con operaciones de actores chinos documentados en investigaciones anteriores.
Distribucion geografica de victimas. China, Iran, Vietnam y Rusia. Este patron no se alinea con los objetivos tipicos de actores rusos (Europa occidental, OTAN) ni norcoreanos (sector financiero, criptomonedas). Es compatible con operaciones de recopilacion de inteligencia de actores chinos que incluyen vigilancia domestica.
Variante temprana de Qihoo360. El hecho de que un vendor de seguridad chino documentara la primera variante en 2017 sugiere que el rootkit fue detectado inicialmente en el ecosistema de amenazas chino, posiblemente afectando a objetivos dentro de China.
Similitudes de codigo. Kaspersky identifico coincidencias con malware previamente atribuido a actores de habla china, aunque no realizo una atribucion a un grupo especifico (como APT41 o APT31).
La atribucion es de confianza media. No hay suficiente evidencia publica para vincular CosmicStrand a un grupo APT especifico con nombre y MITRE ID asignado.
Deteccion y remediacion
Deteccion mediante volcado de firmware
El metodo mas fiable para detectar CosmicStrand es volcar el contenido de la flash SPI y verificar la integridad de CSMCORE DXE.
Herramientas de volcado:
- CHIPSEC (Intel): python chipsec_util.py spi dump firmware.bin
- Flashrom: flashrom -p internal -r firmware_dump.bin
- UEFITool: analisis visual de la estructura de volumenes
Verificacion:
1. Extraer CSMCORE DXE del volcado
2. Comparar hash SHA256 contra la imagen de firmware original del fabricante
3. Si no coincide → posible modificacion no autorizada
4. Analizar con UEFITool en busca de hooks en HandleProtocol
Deteccion en el sistema operativo
Aunque la cadena es in-memory, el componente de modo usuario genera actividad de red detectable:
- Conexiones HTTP a dominios conocidos asociados a CosmicStrand
- Patrones anomalos de trafico durante los primeros minutos tras el arranque
- Procesos con inyeccion de codigo que inician comunicaciones de red inmediatamente despues del boot
Remediacion
La unica forma de eliminar CosmicStrand es reflashear el firmware UEFI con una imagen limpia del fabricante:
- Obtener la imagen de firmware correcta para el modelo exacto de placa base desde el sitio oficial de ASUS o Gigabyte
- Verificar el hash de la imagen descargada contra los valores publicados por el fabricante
- Reflashear usando la herramienta oficial del fabricante o un programador SPI externo
- Verificar el reflasheo con un segundo volcado y comparacion de hashes
- Reinstalar el sistema operativo desde cero (el kernel pudo haber sido comprometido)
Deshabilitar el CSM en la configuracion UEFI despues del reflasheo elimina el componente que CosmicStrand parasita. Si el sistema operativo soporta arranque UEFI nativo (Windows 8 o posterior con GPT), el CSM no es necesario.
Mapeo MITRE ATT&CK
| Tactica | Tecnica | ID | Descripcion en contexto CosmicStrand |
|---|---|---|---|
| Persistence | Pre-OS Boot: System Firmware | T1542.001 | Modificacion de CSMCORE DXE en flash SPI |
| Execution | Native API | T1106 | Uso de EFI_BOOT_SERVICES.HandleProtocol para inyeccion |
| Defense Evasion | Rootkit | T1014 | Cadena completa en memoria, sin artefactos en disco |
| Defense Evasion | Modify System Image | T1601.001 | Parcheo del driver DXE existente en firmware |
| Defense Evasion | Hijack Execution Flow | T1574 | Hooks sucesivos en Boot Manager, OS loader y kernel |
| Command and Control | Application Layer Protocol: Web Protocols | T1071.001 | HTTP a dominios C2 hardcodeados |
| Defense Evasion | Obfuscated Files or Information | T1027 | Shellcode desplegado desde direccion de memoria predeterminada |
La tecnica T1542.001 (System Firmware) es la fundamental. CosmicStrand demuestra una implementacion madura de esta tecnica con una cadena de hooks en cascada que atraviesa cuatro niveles del proceso de arranque.
Implicaciones defensivas
Para organizaciones con hardware H81. Si la organizacion tiene placas ASUS o Gigabyte con chipset H81 en su inventario, debe considerarlas en riesgo. Un volcado de firmware y verificacion de integridad de CSMCORE DXE es la accion inmediata recomendada. Si el CSM no es necesario (Windows 10/11 con arranque UEFI nativo), deshabilitarlo reduce la superficie de ataque.
Para fabricantes de hardware. CosmicStrand refuerza la necesidad de protecciones de escritura robustas en la flash SPI y de habilitar Intel Boot Guard por defecto. Las placas de gama de entrada no deben sacrificar seguridad de firmware por coste.
Para equipos de respuesta a incidentes. La antiguedad de CosmicStrand (muestras desde 2016) implica que rootkits UEFI pueden haber estado presentes en entornos comprometidos durante anos sin ser detectados. La verificacion de firmware debe formar parte del proceso forense en investigaciones de actores avanzados, especialmente cuando el hardware del objetivo incluye placas de generaciones anteriores con protecciones limitadas.
Para la industria de seguridad. La especificidad de hardware de CosmicStrand (solo H81 de ASUS y Gigabyte) indica que los atacantes invierten en desarrollar variantes por chipset y fabricante. Es razonable asumir que existen variantes no documentadas para otros chipsets y marcas.
Fuentes y referencias
- Kaspersky GReAT. "CosmicStrand: the discovery of a sophisticated UEFI firmware rootkit." Julio 2022. securelist.com
- Qihoo360. Analisis de variante temprana de rootkit UEFI en placas H81. 2017
- MITRE ATT&CK. Pre-OS Boot: System Firmware (T1542.001). attack.mitre.org
- Matrosov, A., Rodionov, E., Bratus, S. "Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats." No Starch Press, 2019
- ESET Research. "LoJax: First UEFI rootkit found in the wild." Septiembre 2018
- Kaspersky GReAT. "MoonBounce: the dark side of UEFI firmware." Enero 2022. securelist.com
- Intel Corporation. "Intel Boot Guard" technology overview
- CHIPSEC: Platform Security Assessment Framework. github.com/chipsec/chipsec
Articulo con fines exclusivamente defensivos. MalwareIntel documenta amenazas para ayudar a equipos de seguridad a detectar y mitigar rootkits de firmware. No se proporcionan binarios, exploits ni instrucciones de replicacion.
Preguntas frecuentes
Libros recomendados
Artículos relacionados
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.