MosaicRegressor: El Framework UEFI Modular Basado en Codigo Filtrado de HackingTeam

El segundo bootkit UEFI in-the-wild

En octubre de 2020, el equipo GReAT (Global Research and Analysis Team) de Kaspersky publico un informe que detallaba el descubrimiento de MosaicRegressor, un framework de implantes UEFI encontrado en equipos de organizaciones diplomaticas y ONG en Africa, Asia y Europa. Hasta ese momento, solo existia un caso documentado de bootkit UEFI utilizado en ataques reales: LoJax, descubierto por ESET en 2018 y atribuido a APT28 (Fancy Bear).

MosaicRegressor represento un salto cualitativo respecto a LoJax. Donde LoJax era un implante unico con funcionalidad limitada (un downloader persistente), MosaicRegressor era un framework modular completo: multiples drivers DXE, una cadena de boot multi-etapa y una variedad de payloads finales que incluian downloaders y backdoors. El nivel de sofisticacion sugeria un equipo de desarrollo con experiencia en programacion de firmware, no un actor oportunista.

Lo mas llamativo del analisis fue el origen del codigo. Los investigadores de Kaspersky identificaron que el componente UEFI de MosaicRegressor estaba basado en VectorEDK, un bootkit UEFI desarrollado por HackingTeam, la empresa italiana de vigilancia cuyo codigo fuente completo fue filtrado publicamente en julio de 2015. Los atacantes habian tomado un arma de vigilancia comercial, la habian adaptado y desplegado en operaciones reales de espionaje.

HackingTeam y el codigo fuente de VectorEDK

La filtracion de 2015

En julio de 2015, un atacante anonimo filtro mas de 400 GB de datos internos de HackingTeam, incluyendo codigo fuente de todas sus herramientas de vigilancia, correos electronicos, facturas a clientes gubernamentales y documentacion interna. Entre las herramientas filtradas se encontraba VectorEDK, un toolkit para implantar persistencia en firmware UEFI.

VectorEDK estaba disenado como una herramienta de acceso fisico: un operador con acceso al equipo objetivo podia arrancar desde un USB, re-flashear el firmware UEFI con una version modificada que incluia un modulo DXE malicioso, y garantizar que el implante de vigilancia sobreviviria a cualquier reinstalacion del sistema operativo.

Estructura original de VectorEDK

El codigo de VectorEDK incluia:

• Modulo DXE: un driver UEFI que se ejecutaba durante la fase DXE (Driver Execution Environment) del arranque, antes de que el sistema operativo cargara
• Dropper NTFS: funcionalidad para escribir un archivo ejecutable en la particion NTFS de Windows durante el proceso de boot
• Herramienta de flasheo: utilidad para modificar la imagen del firmware SPI y anadir el modulo DXE malicioso al firmware volume
• Documentacion: instrucciones para operadores sobre como utilizar la herramienta con acceso fisico

El codigo original era funcional pero limitado. Soportaba un unico payload, no tenia mecanismos de actualizacion remota y dependia de acceso fisico para la instalacion. Los creadores de MosaicRegressor tomaron esta base y la transformaron en algo considerablemente mas elaborado.

Arquitectura tecnica de MosaicRegressor

Componente UEFI: modificacion de la SPI flash

El implante UEFI de MosaicRegressor residia en la memoria flash SPI (Serial Peripheral Interface) de la placa base, el chip que almacena el firmware UEFI. La modificacion consistia en anadir uno o mas drivers DXE maliciosos al firmware volume existente.

La SPI flash tipica tiene la siguiente estructura:

+----------------------------+
| Descriptor Region          |  <- Configuracion del chip flash
+----------------------------+
| BIOS/UEFI Region           |  <- Firmware volumes (FV)
|   +----------------------+ |
|   | FV Recovery          | |
|   +----------------------+ |
|   | FV Main              | |  <- DXE drivers legitimos del fabricante
|   |   [DXE driver 1]    | |
|   |   [DXE driver 2]    | |
|   |   [DXE driver N]    | |
|   |   [DXE MALICIOSO]   | |  <- MosaicRegressor inyecta aqui
|   +----------------------+ |
+----------------------------+
| ME Region (Intel ME)       |
+----------------------------+
| GbE Region (Ethernet)      |
+----------------------------+

El driver DXE malicioso se insertaba como un modulo adicional dentro del firmware volume principal. Desde la perspectiva del firmware UEFI, era un driver mas que se cargaba durante la fase DXE del arranque, ejecutandose con privilegios totales sobre el hardware antes de que cualquier medida de seguridad del sistema operativo estuviera activa.

Cadena de boot: de firmware a payload

La secuencia de ejecucion de MosaicRegressor seguia un flujo de varias etapas:

Etapa 1: DXE driver malicioso (firmware)

Durante la fase DXE del arranque UEFI, el driver malicioso se cargaba como cualquier otro modulo del firmware. Su funcion principal era registrar un callback que se ejecutaria justo antes de transferir el control al bootloader del sistema operativo (evento BDS, Boot Device Selection).

Etapa 2: escritura en NTFS (transicion firmware a disco)

Cuando el callback se activaba, el driver accedia directamente al disco duro usando los protocolos de bloque UEFI (EFI_BLOCK_IO_PROTOCOL). Localizaba la particion NTFS de Windows, parseaba las estructuras NTFS a nivel de firmware y escribia un archivo ejecutable en una ruta predeterminada, tipicamente dentro de C:\Windows\Temp\ o similar.

Este paso es critico: el firmware UEFI tiene acceso directo al hardware de almacenamiento sin ninguna restriccion del sistema operativo. No existe antivirus, no hay control de acceso, no hay logging. El archivo simplemente aparece en disco antes de que Windows arranque.

Etapa 3: servicio de Windows (sistema operativo)

Una vez Windows arrancaba, un componente registrado como servicio del sistema (instalado en una infeccion previa o por el propio dropper) detectaba el archivo depositado por el DXE driver y lo ejecutaba. Si el archivo habia sido eliminado por un antivirus o por una reinstalacion, el DXE driver lo reescribia en el siguiente arranque, garantizando persistencia.

Etapa 4: payloads finales

Los payloads finales descargados incluian multiples variantes:

• BitsProxy: un downloader que abusaba del servicio BITS (Background Intelligent Transfer Service) de Windows para descargar payloads adicionales, camuflando el trafico como transferencias legitimas de actualizaciones
• Downloaders HTTP/HTTPS: modulos que contactaban servidores de C&C para recibir instrucciones y payloads actualizados
• Backdoors de recopilacion: herramientas de exfiltracion que recopilaban documentos, credenciales y metadata del sistema

Modularidad del framework

A diferencia de LoJax (un unico implante con un unico proposito), MosaicRegressor funcionaba como un framework con componentes intercambiables:

Componente	Funcion	Variantes observadas
DXE driver	Persistencia en firmware, dropper	Al menos 2 variantes
Dropper NTFS	Escritura de archivo en disco	Multiples rutas objetivo
Loader de primera etapa	Carga en memoria del payload final	Servicio Windows, DLL injection
Payload final	Espionaje, exfiltracion, descarga	BitsProxy, HTTP downloader, backdoor

Esta modularidad permitia a los operadores adaptar la cadena de ataque segun el objetivo. Un mismo implante UEFI podia desplegar diferentes payloads finales dependiendo del perfil de la victima.

Comparacion con LoJax

La comparacion entre MosaicRegressor y LoJax ilustra la evolucion de las amenazas UEFI en un periodo de dos anos:

Caracteristica	LoJax (2018)	MosaicRegressor (2020)
Descubierto por	ESET	Kaspersky GReAT
Atribucion	APT28 (Rusia, confianza alta)	Posible nexo chino (confianza media)
Arquitectura	Implante unico	Framework modular
Drivers DXE	1	Multiples
Payloads finales	Downloader (XAgent/Seduploader)	BitsProxy, HTTP downloaders, backdoors
Origen del codigo	Reutilizacion de LoJack/Computrace	Reutilizacion de VectorEDK (HackingTeam)
Metodo de instalacion	Software userland (rw_everything)	Acceso fisico o supply chain (probable)
Persistencia	SPI flash	SPI flash
Complejidad de parseo NTFS	Basica	Avanzada (multiples rutas)
Actualizacion remota	No documentada	Si (via C&C)

LoJax fue la prueba de concepto que demostro que los bootkits UEFI eran viables in-the-wild. MosaicRegressor fue la confirmacion de que la tecnica estaba madurando hacia frameworks reutilizables y operacionalmente flexibles.

Atribucion: posible nexo chino

Kaspersky evaluo que MosaicRegressor tenia un posible nexo con actores de amenaza de habla china, basandose en varios indicadores:

• Infraestructura compartida: los servidores de C&C utilizados por los payloads de MosaicRegressor se solapaban con infraestructura previamente asociada a campanas de grupos APT chinos
• Perfil de victimas: organizaciones diplomaticas y ONG involucradas en relaciones con paises de interes estrategico para China
• Horarios de actividad: patrones de operacion consistentes con la zona horaria UTC+8
• Codigo no atribuido previamente: los payloads finales (BitsProxy y otros) no coincidian exactamente con herramientas conocidas de un grupo especifico, lo que sugiere un equipo con capacidad de desarrollo independiente

Kaspersky fue deliberadamente cauteloso con la atribucion, clasificandola como "posible nexo" y no como atribucion firme. El uso de codigo filtrado de HackingTeam anade complejidad: cualquier actor con acceso al leak de 2015 (publicamente disponible) podria haber construido un implante similar.

Vector de instalacion

El metodo exacto de instalacion del implante UEFI no fue determinado con certeza por Kaspersky. Las hipotesis principales son:

Acceso fisico: consistente con el diseno original de VectorEDK, que requeria arrancar desde un USB para re-flashear el firmware. Un agente con acceso fisico temporal al equipo podria completar el proceso en minutos.

Supply chain compromise: modificacion del firmware durante la cadena de suministro, antes de que el equipo llegara a la victima. Esta hipotesis explicaria como se infectaron equipos en multiples paises sin necesidad de acceso fisico repetido.

Explotacion remota del firmware: aunque teoricamente posible (vulnerabilidades en el proceso de actualizacion del firmware), no se encontraron evidencias de este vector en la investigacion.

La ausencia de un vector de instalacion remoto confirmado es significativa. Indica que el atacante tenia recursos operativos para obtener acceso fisico a los equipos objetivo o comprometer la cadena de suministro, lo que apunta a un actor estatal con capacidades HUMINT.

Deteccion y mitigacion

Verificacion del firmware con CHIPSEC

CHIPSEC (framework open-source de Intel para analisis de seguridad de firmware) es la herramienta principal para detectar modificaciones no autorizadas en la SPI flash:

# Extraer la imagen del firmware SPI
python chipsec_util.py spi dump firmware_dump.bin

# Verificar la whitelist de modulos DXE conocidos
python chipsec_main.py -m tools.uefi.whitelist -a check,firmware_dump.bin,whitelist.json

# Buscar modulos DXE desconocidos
python chipsec_main.py -m tools.uefi.scan_blocked

# Verificar protecciones de escritura de la SPI flash
python chipsec_main.py -m common.spi_lock

La verificacion compara los modulos DXE presentes en el firmware con una lista de modulos legitimos del fabricante. Cualquier modulo no reconocido es un indicador de compromiso.

Secure Boot

Secure Boot, cuando esta correctamente configurado, previene la carga de drivers DXE no firmados por una autoridad de confianza. Sin embargo, MosaicRegressor se encontro en equipos donde Secure Boot estaba deshabilitado o mal configurado.

Requisitos para que Secure Boot sea efectivo contra este tipo de amenaza:

• Activado en modo "Custom" con claves propias de la organizacion (no solo las claves por defecto de Microsoft)
• Firmware actualizado a la ultima version del fabricante
• Proteccion de escritura de la SPI flash habilitada (SPI Write Protection, BIOS Lock)
• Monitorizacion periodica de la integridad del firmware

Intel Boot Guard

Intel Boot Guard proporciona una cadena de confianza basada en hardware que verifica la integridad del firmware antes de ejecutarlo. A diferencia de Secure Boot (que verifica el bootloader), Boot Guard verifica el propio firmware UEFI. Si el firmware ha sido modificado, el sistema se niega a arrancar.

Esta tecnologia, disponible en procesadores Intel de quinta generacion en adelante, habria prevenido la ejecucion del implante de MosaicRegressor si hubiera estado habilitada y configurada por el fabricante del equipo.

Indicadores a nivel de sistema operativo

Aunque la deteccion optima ocurre a nivel de firmware, existen indicadores observables desde el sistema operativo:

• Archivos que reaparecen en C:\Windows\Temp\ o rutas similares tras ser eliminados o tras reinstalaciones
• Servicios de Windows desconocidos que se instalan automaticamente al arrancar
• Trafico BITS (Background Intelligent Transfer Service) hacia dominios no relacionados con actualizaciones de Microsoft
• Procesos que establecen conexiones de red inmediatamente despues del primer login

Mapeo MITRE ATT&CK

Tactica	Tecnica	ID	Descripcion en contexto MosaicRegressor
Persistence	Pre-OS Boot: UEFI Firmware	T1542.001	Driver DXE malicioso en SPI flash, persiste tras reinstalacion
Persistence	Boot or Logon Autostart Execution	T1547	Servicio Windows carga payload depositado por DXE driver
Defense Evasion	Pre-OS Boot	T1542	Ejecucion anterior al sistema operativo evita toda deteccion basada en OS
Defense Evasion	Rootkit	T1014	Persistencia a nivel de firmware, invisible para herramientas de seguridad convencionales
Defense Evasion	Masquerading	T1036	BitsProxy camufla trafico malicioso como transferencias BITS legitimas
Execution	System Services: Service Execution	T1569.002	Payload ejecutado como servicio de Windows
Command and Control	Application Layer Protocol: Web Protocols	T1071.001	Comunicacion C&C via HTTP/HTTPS
Command and Control	Ingress Tool Transfer	T1105	Descarga de payloads adicionales desde C&C
Collection	Data from Local System	T1005	Recopilacion de documentos y credenciales del sistema victima
Exfiltration	Exfiltration Over C2 Channel	T1041	Exfiltracion de datos a traves del canal de C&C existente
Resource Development	Obtain Capabilities: Tool	T1588.002	Reutilizacion de codigo VectorEDK de HackingTeam (leak 2015)

Implicaciones para la seguridad del firmware

MosaicRegressor confirmo varias tendencias que la comunidad de seguridad anticipaba pero que carecian de evidencia in-the-wild:

El codigo filtrado se convierte en arma. La filtracion de HackingTeam en 2015 no fue solo un escandalo de privacidad. Cinco anos despues, el codigo de VectorEDK estaba siendo reutilizado en operaciones de espionaje reales. Las filtraciones de herramientas ofensivas (HackingTeam, Shadow Brokers, Vault 7) no desaparecen: se reciclan.

La barrera de entrada se reduce. Desarrollar un bootkit UEFI desde cero requiere conocimiento profundo de programacion de firmware, especificaciones UEFI y hardware especifico. Reutilizar codigo filtrado reduce esa barrera significativamente. MosaicRegressor demostro que un actor con capacidad de desarrollo intermedia podia construir un implante UEFI funcional partiendo de codigo publico.

El firmware es una superficie de ataque activa. Tras LoJax y MosaicRegressor, la lista crecio con ESPecter (2021), CosmicStrand (2022), BlackLotus (2023) y otros. El firmware dejo de ser un vector teorico para convertirse en un campo de batalla real.

La deteccion sigue siendo insuficiente. La mayoria de organizaciones no monitorizan la integridad de su firmware. No tienen imagenes de referencia, no ejecutan CHIPSEC periodicamente y no verifican que Secure Boot este correctamente configurado. Un implante como MosaicRegressor puede permanecer activo durante anos sin ser detectado.

Fuentes y referencias

• Legezo, D. (2020). MosaicRegressor: Lurking in the Shadows of UEFI. Kaspersky GReAT, Securelist.
• Kaspersky GReAT (2020). MosaicRegressor Technical Report. Virus Bulletin 2020 presentation.
• HackingTeam Leaked Source Code (2015). VectorEDK UEFI persistence toolkit. Repositorio publico post-filtracion.
• Matrosov, A., Rodionov, E. & Bratus, S. (2019). Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats. No Starch Press.
• ESET Research (2018). LoJax: First UEFI rootkit found in the wild. White paper (referencia comparativa).
• Intel Corporation. CHIPSEC: Platform Security Assessment Framework. Repositorio GitHub.
• NIST SP 800-147B (2014). BIOS Protection Guidelines for Servers.
• MITRE ATT&CK: Technique T1542.001 (Pre-OS Boot: UEFI Firmware).