Análisis adicional en la puerta trasera de SUNBURST


Resumen Ejecutivo

Se ha prestado una atención considerable a las divulgaciones recientes asociadas con SolarWinds, y si bien el análisis existente sobre la campaña más amplia ha dado como resultado la detección de IoC específicos asociados con el troyano Sunburst, el enfoque dentro del equipo de Investigación de amenazas avanzadas (ATR) ha sido determinar el posibilidad de medidas de persistencia adicionales. Nuestro análisis por la puerta trasera revela que el nivel de acceso se presta a la suposición de que podrían haberse establecido mecanismos de persistencia adicionales y algunas inferencias con respecto a la intención de los adversarios;

  • Una observación interesante fue la verificación de la presencia del ejecutable del cliente de mejora de SolarWinds y su versión "3.0.0.382". ImprovementClient es un programa que puede recopilar información considerable, como el recuento de cuentas de usuario de Orion mediante el método de autenticación y datos sobre dispositivos y aplicaciones monitoreados.
  • La observación de la rutina http fue la búsqueda de ciertas palabras clave en el tráfico http que podrían indicar que el adversario estaba investigando detalles / acceso a la nube y / o redes inalámbricas de sus víctimas.
  • Incluso si una víctima está usando un servidor proxy con nombre de usuario y contraseña, la puerta trasera es capaz de recuperar esa información y usarla para establecer la conexión hacia el C2.

Recursos disponibles

Aunque este análisis se centrará en la premisa de que la puerta trasera respalda la viabilidad de establecer métodos de persistencia adicionales, reconocemos la importancia de brindar seguridad con respecto a la cobertura frente a los indicadores disponibles. Para ello se encuentran disponibles los siguientes recursos:

Los recursos adicionales estarán disponibles a medida que los análisis llevados a cabo por investigadores de McAfee, y la comunidad en general esté disponible.

Análisis de puerta trasera

Existe un excelente análisis de muchos de nuestros pares de la industria sobre el troyano SUNBURST, y la intención aquí no es duplicar los hallazgos, sino proporcionar análisis que no hemos visto anteriormente. El propósito es permitir que las víctimas potenciales comprendan mejor las capacidades de la campaña en un esfuerzo por considerar la posibilidad de que existan mecanismos de persistencia adicionales.

Para los propósitos de este análisis, nuestro enfoque se centró en el archivo "SolarWinds.Orion.Core.BusinessLayer.dll", este archivo en particular, como su nombre indica, está asociado con el paquete de software SolarWinds ORION y se modificó con una clase agregada que contiene el puerta trasera "SunBurst".

Figura 1 Módulo agregado y dependencias

Una inmersión más profunda en la puerta trasera revela que la llamada inicial es a la clase agregada "OrionImprovementBusinessLayer" que tiene las siguientes funciones:

Figura 2 Inicio de la clase insertada

La clase comienza con una verificación para ver si el módulo se está ejecutando y, de lo contrario, iniciará el servicio y luego iniciará un período de inactividad.

Figura 3 Secuencia de sueño de la puerta trasera

Como lo detalló FireEye, este período de sueño puede variar desde minutos hasta dos semanas. El período de inactividad real depende de las comprobaciones que se deben pasar del código, como el hash del proceso de Orion, los tiempos de escritura de los archivos, el proceso en ejecución, etc. Un período de inactividad de este período de tiempo es inusual y habla a un adversario muy paciente.

Las cadenas más importantes dentro de las puertas traseras están codificadas con la clase DeflateStream de la biblioteca de compresión de .NET junto con el codificador base64. Al examinar la lista de bloqueo, descubrimos hallazgos que justifican una inspección adicional. Las primeras entradas son los rangos de direcciones IP locales y las máscaras de red:

  • 10.0.0.0 255.0.0.0
  • 172.16.0.0 255.240.0.0
  • 192.168.0.0 255.255.0.0

Seguido por las direcciones locales IPv6 equivalentes:
fc00 ::, fe00 ::, fec0 ::, ffc0 ::, ff00 ::, ff00 ::

A continuación, hay una lista de direcciones IP y sus máscaras de subred asociadas. Ejecutamos un whois en esos destinatarios IP para tener una idea de a quién podrían pertenecer. No hay ninguna indicación sobre la razón por la que las siguientes direcciones IP se han insertado en la lista de bloqueo, aunque las máscaras de red implementadas en ciertas entradas son "bastante" específicas, por lo que debemos asumir que los atacantes fueron intencionales en su deseo de evitar ciertos objetivos.

Suponiendo que la víctima no está dentro de la lista de bloqueo, la muestra procederá a crear la tubería con nombre 583da945-62af-10e8-4902-a8f205c72b2e. Esto se hace para garantizar que solo se esté ejecutando una instancia de la puerta trasera. Pudimos verificar esto a través de la replicación que llevamos a cabo dentro de nuestro propio entorno.

Figura 4 Ejecución de la puerta trasera

Cuando ejecutamos la puerta trasera, pudimos confirmar que este valor está codificado en el código, y una vez que pasó el período de inactividad, se inicia el servicio y se crea la tubería con nombre. En este punto, la puerta trasera también creará un valor MD5 de UserID único para el sistema en el que está instalado, como se muestra en la figura 5.

Figura 5 Creación de ID de usuario

Esta rutina en particular leerá inicialmente la información del dispositivo del sistema, pero ignorará las interfaces de bucle invertido (parte del código de la rutina ReadDeviceInfo que menciona “Seleccionar * de Win32_NetworkAdapterConfiguration donde IPEnabled = true”). La información del dispositivo se combinará con el nombre de dominio, seguido de un valor de la clave de registro (HKEY_LOCAL_MACHINE SOFTWARE Microsoft Cryptography). Esta información luego se utiliza para crear un valor MD5 de esa cadena.

El módulo iniciará la rutina de "actualización". Esta rutina es un bucle continuo diseñado para la verificación de, por ejemplo, servicios no deseados que podrían usarse para detectar la puerta trasera, como se muestra en la figura 6.

Figura 6 Bucle de actualización

Recopilación de información

La puerta trasera recopila información del sistema. La siguiente información es recopilada por una rutina llamada "CollectSystemDescription", algunos ejemplos incluyen;

  • Versión del sistema operativo, mayor / menor: es de 32 o 64 bits
  • Configuraciones de red, información sobre IP, NetBIOS, IPV6, etc.
  • Host, SID y nombre de usuario y directorio del sistema. En particular, se busca el SID de la cuenta de administrador.

Existen otras subrutinas para recopilar datos adicionales, por ejemplo, enumerando la información de los adaptadores de red, la puerta trasera utiliza la rutina GetNetworkAdapterConfiguration. La rutina está recopilando la siguiente información:

Figura 7 Recopilación de información de la red

Para comprobar si se están ejecutando determinados servicios "no deseados", la puerta trasera enumera los servicios, crea una lista de hash y los compara con un conjunto codificado de estos valores. La rutina de "actualización" se cerrará una vez que se descubra un ID de proceso "en la lista de bloques". La puerta trasera intentará detener estos servicios ingresando un valor en el registro para ese servicio que desactivará ese servicio. La rutina de actualización volverá a comprobar y continuará este proceso hasta que todos los procesos no deseados estén desactivados.
Otra capacidad de la puerta trasera es iniciar / detener tareas:

Figura 8 Rutina de tareas Kill / Run

Otras funcionalidades que observamos en el código son:

  • Fijar tiempo
  • CollectSystemDescription
  • UploadSystemDescription
  • GetProcessByDescription
  • GetFileSystemEntries
  • WriteFile
  • El archivo existe
  • Borrar archivo
  • GetFileHash
  • ReadRegistryValue
  • SetRegistryValue
  • DeleteRegistryValue
  • GetRegistrySubKeyAndValueNames
  • Reiniciar

Una observación interesante fue la verificación de la presencia del ejecutable del cliente de mejora de SolarWinds y su versión "3.0.0.382".

Figura 9 Buscando cliente de mejora

ImprovementClient es un programa que puede recopilar la siguiente información (fuente Vientos solares):

  • El SWID (ID de SolarWinds) asociado con cualquier licencia comercial de SolarWinds instalada
  • La dirección de correo electrónico proporcionada al instalador durante la instalación
  • Identificador único del instalador descargado
  • Versiones de todos los productos Orion instalados
  • Versión del sistema operativo
  • Descripción y recuento de CPU
  • Memoria física instalada y porcentaje utilizado
  • Zona horaria
  • Fechas en las que inició sesión en el sitio web de Orion
  • Información sobre licencias de otros productos SolarWinds Orion instalados localmente
  • Recuento de filas para tablas de base de datos
  • Recuento de nodos monitoreados por protocolo de sondeo
  • Recuento de cuentas de usuario de Orion por método de autenticación
  • Información de programación de descubrimiento de red (no resultados)
  • Datos sobre dispositivos y aplicaciones monitoreados:
    • Vendedor
    • Modelo
    • Versión de SO / Firmware
    • Contar
    • Información de configuración abstracta, como la cantidad de sitios web alojados
  • Datos sobre el producto SolarWinds:
    • Estadísticas de uso de funciones
    • Estadísticas de desempeño
    • Descripción de la plataforma de hardware y sistema operativo

Otra observación de la rutina http fue la búsqueda de ciertas palabras clave en el tráfico http que podrían indicar que el adversario estaba buscando detalles / acceso a la nube y / o redes inalámbricas de sus víctimas utilizando los módulos de SolarWinds que están instalados para monitorear / administrar este tipo de instancias. La gestión de la red con Orion de SolarWinds se ejecuta mediante un navegador y un host local que aloja el servidor web. Leer los valores del certificado y buscar estas palabras clave en el tráfico http habría obtenido esta información.

Figura 10 Búsqueda de palabras clave

Red / DGA

Una vez que hayan pasado todas las comprobaciones y rutinas, la puerta trasera utilizará un algoritmo de generación de dominio (en adelante DGA) para generar un dominio. Ejemplo de la parte del código DGA:

Figura 11 Ejemplo de código DGA

Cuando el dominio se alcanza con éxito, la rutina llamada "Actualizar" contiene una parte que actuará sobre esto y comenzará un nuevo hilo disparando la rutina "HttpHelper.Initialize". En la siguiente captura de pantalla podemos observar ese flujo:

Figura 12 DGA, HttpHelper

El código muestra que cuando dnsrecord es igual al dominio y se puede alcanzar, el nuevo hilo comenzará en segundo plano.

La clase / rutina "HttpHelper" es responsable de todas las comunicaciones C2:

Figura 13 HttpHelp

Incluso si una víctima está usando un servidor proxy con nombre de usuario y contraseña, la puerta trasera es capaz de recuperar esa información y usarla para establecer la conexión hacia el C2. Luego usa una rutina llamada "IWebProxy GetWebProxy" para eso:

Figura 14 Obtención de nombre de usuario y contraseña de proxy

Los C2 generados por DGA son subdominios de: avsvmcloud (.) Com.
Un ejemplo de cómo se verían estos dominios:

  • 02m6hcopd17p6h450gt3.appsync-api.us-west-2.avsvmcloud.com
  • 039n5tnndkhrfn5cun0y0sz02hij0b12.appsync-api.us-west-2.avsvmcloud.com
  • 043o9vacvthf0v95t81l.appsync-api.us-east-2.avsvmcloud.com
  • 04jrge684mgk4eq8m8adfg7.appsync-api.us-east-2.avsvmcloud.com
  • 04r0rndp6aom5fq5g6p1.appsync-api.us-west-2.avsvmcloud.com
  • 04spiistorug1jq5o6o0.appsync-api.us-west-2.avsvmcloud.com

Al inspeccionar los CNAME de los C2 generados por DGA, observamos los siguientes nombres de dominio:

  • freescanonline (.) com
  • deftsecurity (.) com
  • thedoccloud (.) com
  • websitetheme (.) com
  • highdatabase (.) com
  • ingresosupdate (.) com
  • databasegalore (.) com
  • panhardware (.) com
  • Zupertech (.) Com
  • Virtualdataserver (.) Com
  • digitalcollege (.) org

En el código del controlador HTTP mencionado anteriormente, descubrimos rutas que podrían instalarse en el C2 para diferentes funciones:

  • deslizar / subir /
  • swip / Eventos
  • swip / Upload.ashx

Una vez que la puerta trasera está conectada, dependiendo de los objetivos de los adversarios, se pueden ejecutar múltiples acciones, incluido el uso de múltiples cargas útiles que se pueden inyectar en la memoria. En el momento de redactar este artículo, los detalles sobre el "interruptor asesino" contra el dominio anterior evitarán que esta puerta trasera en particular esté operativa, sin embargo, para el propósito de este análisis, demuestra el nivel de acceso que se les brinda a los atacantes. Si bien son dignos de aplaudir los esfuerzos por hundir el dominio, se recomienda encarecidamente a las organizaciones que han podido identificar indicadores de SUNBURST en su entorno a que tomen medidas adicionales para asegurarse de que no se han implementado más mecanismos persistentes.





Enlace a la noticia original