Vea Ya Sharp: A Loader's Tale


Introducción

Se sabe que el cargador CyaX-Sharp basado en DotNet, también conocido como ReZer0, propaga malware de productos básicos, como AgentTesla. En los últimos años, se ha hecho referencia a este cargador en numerosas ocasiones, ya que se utilizó en campañas en todo el mundo. La historia de CyaX-Sharp es interesante, ya que las conclusiones brindan información sobre la forma en que los actores prefieren usar el cargador. Además, ilumina un punto que a menudo se deja iluminado: el funcionamiento interno de los cargadores.

Este blog se divide en varios segmentos, comenzando con un breve prefacio sobre la cobertura de los cargadores en los informes. Después de eso, se explora el origen del nombre del cargador. A continuación, se analizan las capacidades del cargador, así como la extracción automática de la carga útil incorporada del cargador. Por último, se discute el análisis masivo de 513 muestras únicas de cargadores.

Cargadores y su cobertura en blogs

Para ocultar el malware, los actores suelen utilizar un cargador. El propósito de un cargador es, como su nombre lo indica, cargar y lanzar su carga útil, iniciando así la siguiente etapa del proceso. Puede haber varios cargadores que se ejecutan secuencialmente, como una muñeca rusa Matryoshka en la que la muñeca más pequeña, que está escondida dentro de muchas otras, es la carga útil final. La "muñeca más pequeña" generalmente contiene las principales capacidades del malware, como robar credenciales, cifrar archivos o proporcionar acceso remoto al actor.

Si bien hay mucha investigación sobre las acciones de la carga útil final, las etapas anteriores son igualmente interesantes y relevantes. Aunque las etapas anteriores no contienen las capacidades del malware que finalmente se carga, brindan información sobre los pasos que se toman para ocultar el malware. Los blogs generalmente mencionan las capacidades de un cargador brevemente, si es que lo hacen. La desventaja aquí radica en las posibles reglas de detección que otros pueden crear con el blog, ya que la atención se centra en el paso final del proceso, mientras que la detección debe comenzar lo antes posible.

Según las mejores prácticas de seguridad, las organizaciones deben protegerse a sí mismas en cada paso del camino, en lugar de centrarse solo en el perímetro exterior. Estos modelos de amenaza a menudo se denominan, respectivamente, modelo de cebolla y huevo. La dura cáscara del huevo es difícil de romper, pero una vez dentro, el atacante tiene libertad de movimiento. El modelo de cebolla se opone al atacante en cada paso del camino, debido a su enfoque en capas. Conocer el comportamiento de la carga útil final es útil para detectar y bloquear el malware aunque, idealmente, el malware se detectaría lo antes posible.

Este blog se centra en una familia de cargadores específica, pero las conclusiones son válidas en un sentido más amplio. Las configuraciones preferidas de los actores son útiles para comprender cómo se pueden usar los cargadores en una variedad de ataques.

Nombres de familia confusos

Un reciente Blog de Karsten Hahn de G Data proporciona una mirada más profunda a los esquemas de nomenclatura ambiguos de las familias de malware. El nombre de este cargador también es ambiguo, ya que se le conoce por varios nombres. Las muestras a menudo se nombran en función de las características distintivas de ellas. El nombre CyaX-Sharp se basa en la cadena recurrente en las muestras. Sin embargo, esta es exactamente la razón por la que también se llamó ReZer0.

Al mirar los nombres más usados ​​dentro de las 513 muestras obtenidas, 92 usan CyaX-Sharp, mientras que 215 usan ReZer0. Esto haría probable que el cargador se denomine ReZer0, en lugar de CyaX-Sharp. Sin embargo, al observar los nombres de las muestras a lo largo del tiempo, como se puede ver en el gráfico a continuación, la razón por la que se eligió CyaX-Sharp se hace evidente: el nombre ReZer0 solo se introdujo 8 meses después de que se descubrió la primera muestra de CyaX-Sharp. Basado en esto, McAfee se refiere a este cargador como CyaX-Sharp.

Dentro de la configuración, uno encontrará V2 o V4. Esta no es una referencia de la versión del cargador, sino más bien la versión objetivo de DotNet Framework. Dentro del conjunto de muestras, el 62% de las muestras se compilan para ejecutarse en V4, dejando el 38% para ejecutarse en V2.

Capacidades del cargador

Cada versión del cargador contiene todas las capacidades principales, que pueden o no ejecutarse durante el tiempo de ejecución, según la configuración del cargador. Las configuraciones sin procesar se almacenan en una cadena, utilizando dos conductos como valor delimitador. Luego, la cadena se convierte en una matriz de cadenas utilizando dicho delimitador. Según los valores de índices específicos, se habilitan ciertas capacidades. Las capturas de pantalla siguientes muestran, respectivamente, el valor de configuración sin procesar y algunos de los índices usados ​​en una muestra (SHA-256: a15be1bd758d3cb61928ced6cdb1b9fa39643d2db272909037d5426748f3e7a4).

El cargador puede retrasar su ejecución durmiendo durante un cierto número de segundos, usar un mutex para asegurarse de que no se esté ejecutando, mostrar un cuadro de mensaje con un mensaje personalizado, persistir como una tarea programada y / o ejecutar una carga útil determinada en varias formas. La carga útil se puede descargar desde una ubicación externa, después de lo cual se inicia. Alternativamente, o adicionalmente, se puede lanzar la carga útil incorporada dentro del cargador. Esto se puede hacer directamente desde la memoria del cargador con la ayuda de llamadas reflexivas o vaciando un proceso recién creado. El siguiente diagrama de flujo visualiza el proceso. Tenga en cuenta que la línea de puntos significa que el paso vinculado se puede omitir, según la configuración del cargador.

Proceso de vaciado

El proceso recién creado es uno de los siguientes: MSBuild.exe, vbc.exe, RegSvcs.exe o una nueva instancia del cargador. El segmento de código hueco del proceso parece estar tomado de NYAN-x-CATGitHub, como el bucle for para iniciar el proceso, el método de vaciado está presente tanto en el cargador como en el repositorio vinculado. La forma en que se maneja un error no es un método estandarizado, lo que hace que el vínculo entre el código disponible públicamente sea muy probable. La primera imagen a continuación muestra el código original del repositorio, mientras que la segunda imagen muestra el código del cargador (SHA-256: a15be1bd758d3cb61928ced6cdb1b9fa39643d2db272909037d5426748f3e7a4)

El bucle llama a la función de vaciado del proceso varias veces para manejar más fácilmente las excepciones. En el caso de una excepción durante el proceso de vaciado, el proceso objetivo se mata y la función regresa. Para intentarlo varias veces, se utiliza un bucle.

Cambios a lo largo del tiempo

Aunque el cargador ha cambiado con el tiempo, mantuvo la misma estructura central. Las versiones posteriores introdujeron cambios menores en las funciones existentes. A continuación, se describirán diferentes versiones del cargador, donde la longitud de la matriz de cadenas que contiene la configuración del cargador se usa para identificar diferentes versiones. El gráfico muestra la subida y bajada de cada una de las versiones.

Hay dos diferencias notables en las versiones en las que el tamaño de la matriz de configuración es superior a 29. Algunas muestras específicas tienen un código ligeramente diferente en comparación con otras, pero no consideré estas diferencias lo suficientemente importantes como para justificar una nueva versión.

En primer lugar, la capacidad de habilitar o deshabilitar la ejecución retrasada de una muestra. Si está habilitado, la ejecución se retrasa durmiendo durante un número predefinido de segundos. En config_29, la funcionalidad de retardo siempre está habilitada. La duración del retraso se basa en la System.Random objeto, que se crea una instancia utilizando la semilla predeterminada. Los límites inferior y superior dados son 45.000 y 60.000, lo que da como resultado un valor entre estos límites, que equivale al número de milisegundos que se debe retrasar la ejecución.

En segundo lugar, se ha agregado la función para mostrar un mensaje personalizado en un mensaje. El archivo de configuración contiene el título, el texto, el estilo del botón y el estilo del icono del cuadro de mensaje. Las indicaciones se pueden utilizar para mostrar un mensaje de error falso a la víctima, que parecerá ser legítimo, p. Ej. 43d334c125968f73b71f3e9f15f96911a94e590c80955e0612a297c4a792ca07, que usa "No tiene el software adecuado para ver este documento" como mensaje.

Extracción de carga útil y configuración

Para extraer automáticamente la carga útil y la configuración de un cargador determinado, se puede recrear el mecanismo de descifrado en el idioma que se elija, obtener los datos cifrados del cargador y descifrarlos. La desventaja aquí es la necesidad de una copia exacta del mecanismo de descifrado. Si la clave cambiara o si se usara un algoritmo ligeramente diferente, la copia también debería reflejar esos cambios. Para evitar tener que lidiar con el método de descifrado, se puede tomar un enfoque diferente.

Este cargador utiliza por error variables estáticas para almacenar la carga útil descifrada y la configuración. En resumen, estas variables se inicializan antes de la ejecución de la función principal del cargador. Como tal, es posible obtener de forma reflexiva el valor de las dos variables en cuestión. Puede encontrar una guía detallada de cómo hacerlo en mi Sitio web personal. Los datos que se extrajeron de las 513 muestras del conjunto se analizan en la siguiente sección.

Resultados de análisis a granel

El conjunto completo consta de 513 muestras, todas las cuales se encontraron utilizando un solo Regla de Yara. La regla se centra en el recurso integrado que se utiliza para conservar el cargador como una tarea programada en el sistema de la víctima. En algunos casos, la regla de Yara no coincidirá con una muestra, ya que el recurso incrustado se ofusca mediante ConfuserEx (un ejemplo es SHA-256 0427ebb4d26dfc456351aab28040a244c883077145b7b529b93621636663a812). Para desofuscar, uno puede usar ViRb3's de4dot-cex tenedor de de4dot. La regla de Yara coincidirá con el binario desofuscado. El siguiente gráfico muestra la cantidad de muestras únicas a lo largo del tiempo.

Las fechas se basan en la fecha de la primera visita de VirusTotal. Por supuesto, esta fecha no necesita representar el día en que se distribuyó por primera vez el malware. Sin embargo, cuando se habla de malware básico que se distribuye a granel, la fecha es lo suficientemente confiable.

El conjunto de muestra que se utilizó es más pequeño que la cantidad total de cargadores que se han utilizado en la naturaleza. Este cargador a menudo no es la primera etapa, sino más bien una etapa en memoria iniciada por otro cargador. Prácticamente, el conjunto de muestras es lo suficientemente grande para esta investigación, pero debe tenerse en cuenta que hay más muestras de cargadores únicos en la naturaleza para el rango de fechas dado que las que se utilizan en este informe.

Es útil saber cuáles son las capacidades de una sola muestra, pero el área principal de interés de esta investigación se basa en el análisis de todas las muestras del conjunto. Se discutirán varias características, junto con ideas sobre ellas. En esta sección, todos los porcentajes se refieren al total de 513 a menos que se especifique lo contrario.

Uso generalizado

El uso del cargador es generalizado, sin una correlación directa con un grupo o región geográfica específicos. Aunque algunos informes mencionan a un actor específico que usa o crea este cargador, el hecho de que se haya filtrado al menos un constructor dificulta la atribución a uno o más actores. Junto con la amplia variedad de industrias objetivo, así como las amplias áreas geográficas objetivo, parece que varios actores utilizan este cargador. El objetivo de esta investigación no es profundizar en los actores que utilizan este cargador, sino más bien observar el conjunto de muestra en general. El Apéndice A proporciona una lista no exhaustiva de artículos públicos que (al menos) mencionan este cargador, en orden cronológico descendente.

Métodos de ejecución

Las dos opciones para lanzar una carga útil, ya sea de forma reflectante o mediante vaciado de proceso, tienen un uso muy diferente: el 90% de todos los cargadores utiliza el vaciado de proceso, mientras que solo el 10% de las muestras se lanzan mediante reflexión. Las versiones anteriores del cargador a veces se usaban para cargar de manera reflexiva un escalonador descifrado de los recursos del cargador, que luego lanzaba la carga útil del cargador a través del proceso de vaciado. Las métricas a continuación no reflejan esto, lo que significa que el porcentaje real de lanzamientos directos puede ser ligeramente más bajo de lo que se indica actualmente. Los detalles se pueden ver en el gráfico a continuación.

Tenga en cuenta que el mecanismo de carga reflectante utilizará por defecto el proceso de vaciado de una nueva instancia del cargador si se lanza alguna excepción. Solo los archivos basados ​​en DotNet se pueden cargar de forma reflexiva, lo que significa que otros archivos que se ejecutan de esta manera se cargarán utilizando una instancia hueca del cargador.

Persistencia y muttex

El método de persistencia, que utiliza una tarea programada para iniciar el cargador una vez que se inicia la computadora, es utilizado por el 54% de los cargadores. Esto no significa que el otro 46% de las muestras no se conserven en la máquina de la víctima, ya que una etapa diferente también podría proporcionar persistencia. Es notable la fecha dentro de la tarea programada, que es igual a 2014-10-25T14: 27: 44.8929027. Esta fecha es, en el momento de escribir este artículo, hace casi 2500 días. Si alguno de los sistemas de una organización encuentra una solicitud programada con esta fecha exacta, es aconsejable verificar su origen, así como el ejecutable al que apunta.

Un tercio de todos los cargadores están configurados para evitar la ejecución cuando una instancia ya está activa mediante un mutex. De manera similar al mecanismo de persistencia, un mutex podría estar presente en una etapa diferente, aunque este no es necesariamente el caso. Los mutex observados parecen consistir solo en letras alfabéticas sin acento, o (a-zA-Z)+ cuando se escribe como una expresión regular.

Ejecución retrasada

La ejecución retrasada es utilizada por casi el 37% de las muestras, aproximadamente la mitad de las cuales son config_29, lo que significa que esta configuración no se pudo configurar al crear la muestra. Las muestras donde la ejecución diferida fue configurable, equivalen a casi el 19% del total. En promedio, se usa un retraso de 4 segundos. El retraso más alto observado es de 600 segundos. El siguiente gráfico muestra la duración del retraso y la frecuencia.

Tenga en cuenta que un cargador se configuró para tener un retraso de 0 segundos, esencialmente sin retrasar la ejecución. En la mayoría de los casos, el tiempo de retraso es un valor que se puede dividir por cinco, que los humanos a menudo ven como un número redondo.

Advertencia ambiental

Antes de lanzar la carga útil, el cargador puede realizar varias comprobaciones. Se puede detectar un entorno virtual, así como una caja de arena. Aproximadamente el 10% de las muestras verifican la presencia de una máquina virtual, mientras que aproximadamente el 11% verifica si se ejecuta en una caja de arena. Aproximadamente el 8% de las 513 muestras verifican la presencia de ambos, antes de continuar con su ejecución. En otras palabras, el 88% de las muestras que intentan detectar una máquina virtual, también intentaron detectar un sandbox. Viceversa, el 74% de las muestras que intentaron detectar el sandbox, intentaron detectar si se ejecutaron en una máquina virtual.

La opción para deshabilitar Windows Defender estaba presente principalmente en las muestras anteriores, por lo que solo el 15% del conjunto intenta deshabilitarlo.

Familias de carga útil

El objetivo final del cargador es ejecutar la siguiente etapa en la máquina de la víctima. Saber qué tipo de familias de malware se eliminan a menudo puede ayudar a encontrar los mayores puntos débiles en las medidas defensivas adicionales de su organización. El cuadro a continuación proporciona información sobre las familias que más se observaron. El segmento llamado otro contiene todas las muestras que de otro modo saturarían la vista general debido a las pocas ocurrencias por familia, como el ladrón de RedLine, Azorult, o el menos conocido keylogger MrFireMan.

Los porcentajes en el gráfico se basan en 447 cargas útiles totales, ya que 66 cargas útiles fueron duplicadas. En otras palabras, 66 de los cargadores únicos dejaron caer una carga útil no única. De todas las familias, AgentTesla es la más notable, tanto en términos de frecuencia como en términos de recuento de duplicados. De los 66 duplicados, 48 ​​estaban relacionados con AgentTesla.

Capacidades apenas utilizadas

Dos funciones del cargador que apenas se utilizan son el cuadro de mensaje y la descarga de una carga útil remota. El uso de ambos es, respectivamente, 1,3% y 0,8%. Todas las cargas útiles remotas también contenían una carga útil incorporada, aunque uno de los cuatro cargadores de recuperación remota no contiene una URL para descargar la carga útil remota. El archivo externo se puede usar como un módulo adicional para una siguiente etapa, una carga útil maliciosa separada, o se puede usar para deshabilitar ciertos mecanismos de defensa en el dispositivo de la víctima.

Conclusión

Las empresas que utilizan el modelo de seguridad de cebolla antes mencionado se benefician enormemente de la disección de dicho cargador, ya que sus reglas de detección internas se pueden mejorar con los detalles proporcionados. Esto detiene la ejecución del malware en seco, como se muestra en el diagrama secuencial de detección de McAfee a continuación.

Las técnicas que utiliza este cargador se abusa comúnmente, lo que significa que la detección de una técnica como el vaciado de procesos también evitará la ejecución exitosa de muchas otras familias de malware. Endpoint Security (ENS) y Endpoint Detection & Response (EDR) de McAfee detectan el cargador CyaX-Sharp en cada paso del camino, incluidas las técnicas comunes que utiliza. Como tal, los clientes están protegidos contra una multitud de familias según la heurística de un programa.

Apéndice A – Menciones de CyaX-Sharp y ReZer0

A continuación, se proporciona una lista descendente cronológicamente no exhaustiva de artículos relevantes. Algunos artículos contienen información sobre las industrias objetivo y / o el área geográfica objetivo.

  • El 12th de enero de 2021, ESET mencionado el cargador en su blog Operation Spalax
  • El 7th de diciembre de 2020, ProofPoint escribió sobre los mecanismos de descifrado de varios empaquetadores conocidos basados ​​en .NET
  • En el 5th de noviembre de 2020, Morphisec mencionado un empacador que se parece mucho a este cargador
  • En el 6th de octubre de 2020, G Data mencionado el empacador (o una versión modificada)
  • El 29th de septiembre de 2020, ZScaler mencionado el empacador
  • El 17th de septiembre de 2020, escribió sobre la carga útil automática y la extracción de configuración del cargador
  • El 16th de septiembre de 2020, el CERT taiwanés mencionado el cargador en un estudio de caso de amenaza COVID-19 digital
  • El 23rd de julio de 2020, ClamAV mencionado el cargador en un blog
  • El 14th de mayo de 2020, Firma de seguridad 360TotalSecurity Enlaces el cargador al actor de amenazas Vendetta
  • El 21S t de abril de 2020, Fortinet proporcionó conocimiento en el funcionamiento interno del cargador
  • En el 1S t de marzo de 2020, RVSEC0N mencionado el cargador
  • En el 4th de diciembre de 2019, Trend Micro previsto una historia de fondo de CyaX-Sharp
  • El 22Dakota del Norte de marzo de 2019, 360TotalSecurity dio conocimiento en algunas de las funciones del cargador

Apéndice B – Hashes

Los hash que se mencionan en este blog se enumeran a continuación, en orden de aparición. También se incluyen los hashes SHA-1 y SSDeep. Se puede encontrar una lista completa de hashes para las 513 muestras y sus cargas útiles aquí.

Muestra 1

SHA-256: a15be1bd758d3cb61928ced6cdb1b9fa39643d2db272909037d5426748f3e7a4

SHA-1: 14b1a50c94c2751901f0584ec9953277c91c8fff

SS Profundo: 12288: sT2BzlxlBrB7d1THL1KEZ0M4p + b6m0yn1MX8Xs1ax + XdjD3ka: O2zBrB7dlHxv0M4p + b50yn6MXsSovUa

Muestra 2

SHA-256: 43d334c125968f73b71f3e9f15f96911a94e590c80955e0612a297c4a792ca07

SHA-1: d6dae3588a2a6ff124f693d9e23393c1c6bcef05

SSDeep: 24576: EyOxMKD09DLjhXKCfJIS7fGVZsjUDoX4h / Xh6EkRlVMd3P4eEL8PrZzgo0AqKx / 6: EyycPJvTGVijUDlhfEEIUvEL8PrZx0AQ

Muestra 3

SHA-256: 0427ebb4d26dfc456351aab28040a244c883077145b7b529b93621636663a812

SHA-1: 8d0bfb0026505e551a1d9e7409d01f42e7c8bf40

SSDeep: 12288: pOIcEfbJ4Fg9ELYTd24xkODnya1QFHWV5zSVPjgXSGHmI: EEj9E / va





Enlace a la noticia original