CosmicStrand: el descubrimiento de un sofisticado rootkit de firmware UEFI

Introducción

Los rootkits son implantes de malware que se entierran en los rincones más profundos del sistema operativo. Aunque en el papel pueden parecer atractivos para los atacantes, crearlos plantea importantes desafíos técnicos y el más mínimo error de programación tiene el potencial de colapsar por completo la máquina víctima. En nuestras predicciones de APT para 2022 , notamos que, a pesar de estos riesgos, esperábamos que más atacantes alcanzaran el nivel de sofisticación necesario para desarrollar dichas herramientas. Uno de los principales atractivos del malware anidado en niveles tan bajos del sistema operativo es que es extremadamente difícil de detectar y, en el caso de los rootkits de firmware, asegurará que una computadora permanezca en un estado infectado incluso si el sistema operativo se reinstala o el usuario reemplaza el disco duro de la máquina por completo.

En este informe, presentamos un rootkit de firmware UEFI que llamamos CosmicStrand y atribuimos a un actor de amenazas desconocido de habla china. Uno de nuestros socios de la industria, Qihoo360, publicó una publicación de blog sobre una variante temprana de esta familia de malware en 2017.

Dispositivos afectados

Aunque no pudimos descubrir cómo se infectaron inicialmente las máquinas víctimas, un análisis de su hardware arroja luz sobre los dispositivos que CosmicStrand puede infectar. El rootkit se encuentra en las imágenes de firmware de las placas base Gigabyte o ASUS, y notamos que todas estas imágenes están relacionadas con diseños que utilizan el chipset H81. Esto sugiere que puede existir una vulnerabilidad común que permitió a los atacantes inyectar su rootkit en la imagen del firmware.

En estas imágenes de firmware, se han introducido modificaciones en el controlador CSMCORE DXE, cuyo punto de entrada se ha parcheado para redirigir al código agregado en la sección .reloc. Este código, ejecutado durante el inicio del sistema, desencadena una larga cadena de ejecución que da como resultado la descarga y el despliegue de un componente malicioso dentro de Windows.

Al observar las diversas imágenes de firmware que pudimos obtener, evaluamos que las modificaciones pueden haberse realizado con un parche automático. De ser así, se deduciría que los atacantes tenían acceso previo al ordenador de la víctima para extraer, modificar y sobrescribir el firmware de la placa base. Esto podría lograrse a través de un implante de malware precursor ya implementado en la computadora o acceso físico (es decir, un escenario de ataque de sirvienta malvada). El informe inicial de Qihoo indica que un comprador podría haber recibido una placa base con puerta trasera después de realizar un pedido a un revendedor de segunda mano. No pudimos confirmar esta información.

Resumen del proceso de infección

Antes de adentrarnos en los diversos componentes que componen este rootkit, nos gustaría ofrecer una visión de alto nivel de lo que intenta lograr. El objetivo de esta cadena de ejecución es implementar un implante a nivel de kernel en un sistema Windows cada vez que se inicia, a partir de un componente UEFI infectado.

Los autores de malware UEFI enfrentan un desafío técnico único: su implante comienza a ejecutarse tan temprano en el proceso de arranque que el sistema operativo (en este caso, Windows) ni siquiera está cargado en la memoria todavía, y para cuando lo esté, el contexto de ejecución de UEFI habrá terminado. terminado. Encontrar una manera de pasar el código malicioso a lo largo de las distintas fases de inicio es la tarea principal que realiza el rootkit.

El flujo de trabajo consiste en establecer ganchos ^[1] en sucesión, lo que permite que el código malicioso persista hasta después de que se haya iniciado el sistema operativo. Los pasos involucrados son:

• El firmware infectado inicial arranca toda la cadena.
• El malware configura un gancho malicioso en el administrador de arranque, lo que le permite modificar el cargador del kernel de Windows antes de que se ejecute.
• Al alterar el cargador del sistema operativo, los atacantes pueden configurar otro gancho en una función del kernel de Windows.
• Cuando esa función se llama más tarde durante el procedimiento de inicio normal del sistema operativo, el malware toma el control del flujo de ejecución por última vez.
• Despliega un shellcode en la memoria y se comunica con el servidor C2 para recuperar la carga útil maliciosa real para ejecutarla en la máquina de la víctima.

Estos pasos se resumen en el siguiente gráfico:

Implante UEFI: análisis detallado

MD5	DDFE44F87FAC7DAEEB1B681DEA3300E9
SHA1	9A7291FC90F56D8C46CC78397A6F36BB23C60F66
SHA256	951F74882C1873BFE56E0BFF225E3CD5D8964AF4F7334182BC1BF0EC9E987A0A
Tiempo de enlace	Miércoles, 12.08.2015 12:17:57 UTC
Tipo de archivo	Controlador DXE del servicio de arranque EFI
Tamaño del archivo	96.84KB
GUID	A062CF1F-8473-4AA3-8793-600BC4FFE9A8 (CSMCORE)

Habiendo establecido lo que intenta lograr el implante de malware, ahora podemos analizar con más detalle cómo se realiza cada uno de estos pasos.

1. Toda la cadena de ejecución comienza con un controlador EFI. Parece ser una versión parcheada de uno legítimo llamado CSMCORE (destinado a facilitar el arranque de la máquina en modo heredado a través del MBR), donde los atacantes han modificado el puntero a la función de servicio de arranque de HandleProtocol. Cada vez que se llama a esta función, la ejecución se redirige al código proporcionado por el atacante que intenta determinar qué componente lo llamó (busca uno específico para infectar: ​​efi). Al examinar los argumentos de la función, así como los bytes ubicados en la dirección de retorno, CosmicStrand puede identificar la «llamada» exacta que está buscando.
2. Se eligió este punto específico de la ejecución porque en esta etapa el administrador de arranque está cargado en la memoria, pero aún no se está ejecutando. CosmicStrand aprovecha esta oportunidad para parchear una cantidad de bytes en su Archpx64TransferTo64BitApplicationAsm
3. Esa función se llama más tarde durante el proceso de inicio normal del sistema operativo, también en un momento estratégico: para entonces, el cargador del sistema operativo Windows también está presente en la memoria y, a su vez, puede modificarse.
4. Cuando se ejecuta, Archpx64TransferTo64BitApplicationAsm localiza una función del cargador del sistema operativo (OslArchTransferToKernel) buscando un patrón de bytes específico. CosmicStrand luego agrega un gancho al final.
5. Se llama a OslArchTransferToKernel justo antes de que la ejecución se transfiera desde el cargador de Windows al kernel de Windows, lo que lo convierte en un punto de enlace tradicional para rootkits de ese tipo.
6. Antes de que el kernel de Windows haya tenido la oportunidad de ejecutarse, CosmicStrand configura otro enlace en ZwCreateSection. El código malicioso se copia ^[2] en la imagen de ntoskrnl.exe en la memoria, y los primeros bytes de ZwCreateSection se sobrescriben para redirigir a él. Notamos que los atacantes tuvieron cuidado de colocar el código malicioso dentro del espacio libre de la sección .text de ntoskrnl.exe, lo que hace que esta redirección sea mucho menos visible a los ojos de los posibles productos de seguridad.En este punto, CosmicStrand aparentemente también intenta deshabilitar PatchGuard , un mecanismo de seguridad introducido para evitar modificaciones en las estructuras clave del kernel de Windows en la memoria. Para ello, localiza la función KiFilterFiberContext ^[3] de ntoskrnl.exe y la modifica para que vuelva sin realizar ningún trabajo. Vale la pena señalar que la localización de esta función, también lograda mediante la búsqueda de patrones codificados, es muy exhaustiva e incluso contiene patrones correspondientes al lanzamiento de Redstone 1 de agosto de 2016.
7. Luego, el kernel de Windows se inicia y termina llamando a la función enganchada ZwCreateSection mientras se ejecuta normalmente. Cuando eso sucede, CosmicStrand recupera el control de la ejecución nuevamente y restaura el código original antes de ejecutar más código malicioso.
8. El propósito principal del enlace ZwCreateSection es recopilar las direcciones de las funciones API proporcionadas por el kernel y crear una especie de tabla de importación para el siguiente componente. Usando las funciones resueltas, también asigna un búfer en el espacio de direcciones del kernel donde mapea un shellcode, antes de llamarlo.

Código de shell del núcleo

Todos los pasos descritos hasta ahora solo sirvieron para propagar la ejecución del código desde UEFI hasta el kernel de Windows. Este shellcode es el primer componente realmente malicioso de la cadena hasta el momento. Establece una rutina de notificación de subprocesos que se invoca cada vez que se crea un nuevo subproceso. CosmicStrand espera hasta que aparece uno en winlogon.exe y luego ejecuta una devolución de llamada en este contexto de privilegios elevados.

Allí, CosmicStrand duerme durante 10 minutos y prueba la conectividad a Internet de la máquina infectada. CosmicStrand no se basa en funciones API de alto nivel para generar tráfico de red, sino que interactúa directamente con la interfaz del dispositivo de transporte : genera los IRP necesarios (paquetes de solicitud de E/S) y los pasa a la pila de red mediante el envío de IOCTL al Objeto de dispositivo TCP o UDP. Las solicitudes de DNS se realizan de esta manera, utilizando el servidor DNS de Google (8.8.8[.]8) o uno personalizado (222.222.67[.]208).

CosmicStrand recupera su carga útil final enviando un paquete UDP (preferiblemente) o TCP específicamente diseñado a su servidor C2, update.bokts[.]com. Se espera que la respuesta regrese en uno o varios paquetes que contengan fragmentos de 528 bytes siguiendo esta estructura:

Desplazamiento (bytes)	Descripción
0-4	número mágico
4-8	Longitud total de la carga útil
8-12	Longitud del trozo actual
12-16	Suma de comprobación CRC32 del fragmento actual
dieciséis-*	Fragmento de carga útil

Los diversos fragmentos se vuelven a ensamblar en una serie de bytes que se asignan al espacio del kernel y se interpretan como un código de shell. Desafortunadamente, no pudimos obtener una copia de los datos provenientes del servidor C2. Sin embargo, encontramos una muestra de modo de usuario en memoria en una de las máquinas infectadas que pudimos estudiar y creemos que está vinculada con CosmicStrand. Esta muestra es un ejecutable que ejecuta líneas de comando para crear un usuario («aaaabbbb») en la máquina de la víctima y agregarlo al grupo de administradores locales.

Podemos inferir de esto que los shellcodes recibidos del servidor C2 podrían ser etapas para los ejecutables PE proporcionados por el atacante, y es muy probable que existan muchos más.

Variantes anteriores de CosmicStrand

Durante el curso de nuestra investigación, también descubrimos versiones anteriores de este rootkit. Presentan el mismo proceso de implementación y sus pequeñas diferencias se relacionan con el shellcode del kernel.

• Intenta secuestrar un hilo de exe en lugar de winlogon.exe.
• El dominio C2 contactado para obtener un shellcode adicional para poder ejecutarse es diferente (erda158[.]to).
• La variante anterior imprimía mensajes de depuración cada vez que se creaba un nuevo proceso en el sistema.

Según nuestro análisis de la infraestructura utilizada para las dos variantes, estimamos que la más antigua se usó entre finales de 2016 y mediados de 2017, y la actual estuvo activa en 2020.

Infraestructura

Conocemos dos servidores C2, uno para cada variante. De acuerdo con los datos de DNS pasivo disponibles para ellos, estos dominios tenían una vida útil prolongada y se resolvieron en direcciones IP durante períodos de tiempo limitados, fuera de los cuales el rootkit no habría estado operativo. Por lo tanto, es interesante señalar que, si bien los atacantes optaron por implementar un implante extremadamente persistente, es posible que la explotación real de las máquinas de las víctimas no haya durado más de unos pocos meses. Sin embargo, es posible que estos dominios se reactivaran ocasionalmente por períodos muy breves y que esta información no haya sido registrada por los sistemas de DNS pasivos.

Dominio	IP	visto por primera vez	Ultima vez visto	ADN
www.erda158[.]arriba	58.84.53[.]194	2016-12-27	2017-04-26	AS48024 (NERONUBE)
115.239.210[.]27	2017-04-30	2017-06-24	AS58461 (RED CHINA)
update.bokts[.]com	23.82.12[.]30	2020-05-03	2020-05-03	AS30633 (Leaseweb EE. UU.)
23.82.12[.]31	2020-07-25	2020-07-25	AS30633 (Leaseweb EE. UU.)
23.82.12[.]32	2020-03-09	2020-07-25	AS30633 (Leaseweb EE. UU.)

Los lectores cuidadosos notarán la brecha de tres años entre los períodos de actividad de los dos dominios. Es posible que durante ese tiempo, los atacantes estuvieran controlando las máquinas de la víctima utilizando componentes de modo de usuario implementados a través de CosmicStrand, o (más probable) que existan otras variantes y servidores C2 que aún no descubrimos en alguna parte.

Víctimas

Pudimos identificar víctimas de CosmicStrand en China, Vietnam, Irán y Rusia. Un punto de interés es que todas las víctimas en nuestra base de usuarios parecen ser personas privadas (es decir, que usan la versión gratuita de nuestro producto) y no pudimos relacionarlos con ninguna organización o incluso industria vertical.

Atribución

Varios puntos de datos nos llevan a creer que CosmicStrand fue desarrollado por un actor de amenazas de habla china o aprovechando los recursos comunes compartidos entre los actores de amenazas de habla china. En concreto, también se observaron varios patrones de código que aparecen en CosmicStrand en otra familia de malware, la botnet MyKings (p. ej., MD5 E31C43DD8CB17E9D68C65E645FB3F6E8 ). Sophos documentó esta botnet, utilizada para implementar criptomineros, en 2020, donde notó la presencia de varios artefactos en idioma chino.

Las similitudes con CosmicStrand incluyen:

• El uso de un rootkit MBR para establecer una persistencia sigilosa en MyKings.
• CosmicStrand y MyKings usan etiquetas idénticas cuando asignan memoria en modo kernel (Proc y GetM).
• Ambas familias generan paquetes de red de la misma manera y aprovechan los objetos de dispositivo UDP y TCP directamente.
• El código hash de API utilizado en los dos es idéntico, como lo demuestra la siguiente captura de pantalla. Hasta donde sabemos, este algoritmo solo se encontró en otros dos rootkits, MoonBounce y xTalker, también vinculados a actores de amenazas de habla china.

Además de esta similitud de código, el hecho de que el servidor DNS alternativo codificado de forma rígida que utiliza CosmicStrand esté ubicado en CHINANET-BACKBONE (AS4134) podría percibirse como una señal de muy baja confianza de que los atacantes son parte del nexo de habla china. Más allá de este vínculo, hemos decidido que no tenemos suficiente información que nos permita vincular CosmicStrand a un clúster existente.

Conclusiones

CosmicStrand es un rootkit de firmware UEFI sofisticado que permite a sus propietarios lograr una persistencia muy duradera: toda la vida útil de la computadora, mientras que al mismo tiempo es extremadamente sigiloso. Parece haber sido utilizado en funcionamiento durante varios años y, sin embargo, quedan muchos misterios. ¿Cuántos implantes y servidores C2 más nos podrían estar eludiendo? ¿Qué cargas útiles de última etapa se entregan a las víctimas? Pero también, ¿es realmente posible que CosmicStrand haya llegado a algunas de sus víctimas a través del paquete de «interdicción» ? En cualquier caso, los múltiples rootkits descubiertos hasta ahora evidencian un punto ciego en nuestra industria que debe abordarse lo antes posible.

El aspecto más llamativo de este informe es que este implante UEFI parece haber sido utilizado desde finales de 2016, mucho antes de que los ataques UEFI comenzaran a describirse públicamente. Este descubrimiento plantea una pregunta final: si esto es lo que los atacantes estaban usando en ese entonces, ¿qué están usando hoy ?

Un gancho es una modificación al flujo normal de ejecución de un programa. Su objetivo es ejecutar código adicional proporcionado por el atacante antes o después de una función determinada. En algunos entornos, el enlace de funciones se proporciona con fines legítimos y se puede configurar fácilmente a través de mecanismos de programación convencionales. En otros casos, donde no se admiten explícitamente, los atacantes aún pueden lograr el enganche sobrescribiendo (y luego restaurando) el código que está a punto de ejecutarse. Ambos casos son aprovechados por este rootkit.

Fuente: https://securelist.com/