En esta entrada de blog examinamos el funcionamiento de AceCryptor, documentado originalmente por Avast. Este criptor existe desde 2016 y debido a que, a lo largo de su existencia, se ha utilizado para empaquetar decenas de familias de malware, ya se han descrito muchas partes técnicas de este malware. Es posible que ya haya leído acerca de este cifrador, que se conoce de diversas formas como la ofuscación DJVU, Etapa 1 de SmokeLoader, Etapa 1, 2 y 3 del ladrón de RedLine, empacador simple y popular, y así sucesivamente... Muchas (pero no todas) las publicaciones de blog publicadas ni siquiera reconocen este criptor como una familia de malware separada, así que permítanos conectar todos los puntos para usted, brindando no solo un análisis técnico de sus variantes sino también un descripción general de las familias de malware que se pueden encontrar empaquetadas y qué tan frecuente es AceCryptor en la naturaleza.

Para los autores de malware, proteger sus creaciones contra la detección es una tarea desafiante. Los criptógrafos son la primera capa de defensa contra el malware que se distribuye. Aunque los actores de amenazas pueden crear y mantener sus propios criptos personalizados, para los actores de amenazas de crimeware a menudo puede ser una tarea técnicamente difícil o que requiere mucho tiempo mantener su cripto en el llamado estado FUD (totalmente indetectable). La demanda de dicha protección ha creado múltiples criptor-como–un servicio (CaaS) opciones que empaquetan malware. Estos criptos pueden incluir múltiples técnicas anti-VM, anti-depuración y anti-análisis combinadas para lograr el ocultamiento de la carga útil.

Resumen de estadísticas y familias empaquetadas

Desde las primeras apariciones conocidas de AceCryptor allá por 2016, muchos autores de malware han utilizado los servicios de este encriptador, incluso el crimeware más conocido como Emotet, cuando no usaba su propio encriptador. Durante 2021–2022, ESET detectó más de 80,000 XNUMX muestras únicas de AceCryptor. Debido a la gran cantidad de diferentes familias de malware incluidas, asumimos que AceCryptor se vende en algún lugar como CaaS. Si tenemos en cuenta la cantidad de archivos únicos detectados: aunque no sabemos el precio exacto de este servicio, asumimos que las ganancias para los autores de AceCryptor no son despreciables.

Debido al alto volumen de muestras en los últimos años, las siguientes estadísticas se basan solo en muestras detectadas durante 2021 y 2022. Como se puede ver en la Figura 1, los aciertos de detección se distribuyeron de manera bastante uniforme a lo largo de estos dos años, lo cual es de esperar de malware utilizado por una gran cantidad de actores de amenazas que no sincronizan sus campañas.

Figura 1. Número de detecciones de AceCryptor durante los años 2021 y 2022 (promedio móvil de 7 días)

Después de analizar el malware empaquetado por AceCryptor, encontramos más de 200 nombres de detección de ESET. Ahora, por supuesto, una familia de malware puede tener varios nombres de detección en las variantes individuales, debido a actualizaciones o cambios en la ofuscación; por ejemplo, MSIL/Spy.RedLine.A y MSIL/Spy.RedLine.B son detecciones para el malware RedLine Stealer. . Los nombres de detección de otros programas maliciosos no son por familia, sino por clase (p. ej., ClipBanker o Agent), porque muchas muestras de malware desempaquetadas son ladrones de portapapeles genéricos, troyanos, etc., que no están tan extendidos o son solo levemente variantes modificadas de otro malware conocido publicado en varios repositorios públicos. Después de la agrupación, podemos concluir que después del desempaquetado, entre las familias de malware encontradas se encuentran SmokeLoader, RedLine Stealer, RanumBot, Raccoon Stealer, STOP ransomware, Amadey, Fareit, Pitou, Tofsee, Taurus, Phobos, Formbook, Danabot, Warzone y muchas más. … La Figura 2 muestra una descripción general de las cantidades de muestras pertenecientes a algunas de las familias de malware conocidas y predominantes empaquetadas por AceCryptor.

Figura 2. Familias de malware empaquetadas dentro de AceCryptor durante 2021 y 2022

El monitoreo de las actividades de los proveedores de CaaS como AceCryptor es útil para monitorear el malware que utiliza sus servicios. Como ejemplo, considere un RedLine Stealer que se vio por primera vez en el primer trimestre de 1. Como se puede ver en la Figura 2022, los distribuidores de RedLine Stealer usaron AceCryptor desde el comienzo de la existencia de RedLine Stealer y aún continúan haciéndolo. Por lo tanto, ser capaz de detectar de manera confiable AceCryptor (y otros CaaS) no solo nos ayuda con la visibilidad de nuevas amenazas emergentes, sino también con el monitoreo de las actividades de los actores de amenazas.

Figura 3. Incidentes de RedLine Stealer en muestras de AceCryptor (promedios de 7 días)

Victimologia

Como cabría esperar de la variedad de malware incluido en AceCryptor y la diversidad de intereses de los diferentes autores de malware, AceCryptor se ve en todo el mundo. Durante 2021 y 2022, la telemetría de ESET detectó más de 240,000 hits de detección de este malware, lo que equivale a más de 10,000 hits cada mes. En la Figura 4 se pueden ver los países con mayor número de detecciones durante 2021 y 2022.

Figura 4. Mapa de calor de los países afectados por AceCryptor según la telemetría de ESET

Durante 2021 y 2022, los productos de ESET detectaron y bloquearon variantes de malware empaquetadas por AceCryptor en las computadoras de más de 80,000 80,000 clientes. También descubrimos más de XNUMX XNUMX muestras únicas de AceCryptor. Ahora, por supuesto que cualquier muestra podría detectarse en varias computadoras o una computadora fue protegida varias veces por el software de ESET, pero la cantidad de hashes únicos solo muestra cuán activamente trabajan los autores de AceCryptor en su ofuscación y evasión de detección. Profundizaremos en los detalles técnicos de las ofuscaciones de AceCryptor en el El análisis técnico parte de esta entrada de blog.

Lo que vale la pena mencionar aquí es que, aunque la cantidad de muestras únicas de AceCryptor es muy alta, la cantidad de muestras únicas empaquetadas en el interior es inferior a 7,000. Esto muestra el grado en que muchos autores de malware confían en los servicios de un criptor y lo conveniente que les resulta pagar por este tipo de servicio en lugar de invertir su tiempo y recursos para implementar su propia solución de criptografía.

Distribución

Debido a que AceCryptor es utilizado por múltiples actores de amenazas, el malware empaquetado por él también se distribuye de múltiples maneras diferentes. Según la telemetría de ESET, los dispositivos estuvieron expuestos al malware empaquetado con AceCryptor principalmente a través de instaladores troyanos de software pirateado o correos electrónicos no deseados que contenían archivos adjuntos maliciosos.

Otra forma en que alguien puede estar expuesto al malware empaquetado con AceCryptor es a través de otro malware que descargó nuevo malware protegido por AceCryptor. Un ejemplo es la botnet Amadey, que hemos observado descargando un RedLine Stealer lleno de AceCryptor.

Nos gustaría señalar que esto funciona en ambos sentidos y que algunas de las familias de malware protegidas por AceCryptor también pueden descargar malware adicional nuevo.

El análisis técnico

Actualmente, AceCryptor utiliza una arquitectura de tres capas y varias etapas. Hay dos versiones conocidas de la primera capa que están actualmente en uso: una versión que usa TEA (Algoritmo de cifrado diminuto) para descifrar la segunda capa y una versión que utiliza un generador lineal congruente (LCG) de Microsoft Visual/Quick/C++ para descifrar la segunda capa. La segunda capa es un código shell que realiza trucos defensivos, luego descifra y lanza la tercera capa. Finalmente, la tercera capa es más código de shell que también realiza algunos trucos anti-investigación, y su tarea es lanzar la carga útil. Hay dos versiones conocidas de la tercera capa: una versión realiza el vaciado del proceso, mientras que la otra usa un cargador reflectante y sobrescribe su propia imagen con el PE de la carga útil final.

Figura 5. Arquitectura de AceCryptor

Capa 1

Aunque hay dos versiones de la Capa 1, funcionan de manera muy similar. Sus principales tareas se pueden resumir de la siguiente manera:

1. Cargue la capa 2 cifrada en la memoria asignada.
2. Descifrar la capa 2.
3. Llame o salte a la Capa 2.

La parte más importante de esta etapa son las ofuscaciones. A lo largo de los años, se han agregado nuevas ofuscaciones, hasta el punto en que casi todas las partes del binario están aleatorias y ofuscadas de alguna manera. Esto causará grandes problemas para alguien que intente crear reglas YARA o detecciones estáticas.

bucles

Los autores aprovechan los bucles para múltiples ofuscaciones. La primera y más sencilla técnica es usar bucles con código basura solo para dificultar el análisis. Hemos visto el uso de código basura desde 2016 cuando registramos las primeras muestras de AceCryptor. Estos bucles están llenos de muchas llamadas a la API que no solo ralentizan a los analistas que no saben lo que está sucediendo, sino que también abruman los registros de los espacios aislados que enganchan las llamadas a la API, haciéndolos así inútiles. Los bucles pueden contener muchas instrucciones MOV y operaciones matemáticas, nuevamente solo para confundir a los analistas y, por lo tanto, alargar el tiempo de análisis.

Figura 6. Ofuscaciones de AceCryptor con bucles y ocultando partes importantes del código

El segundo uso de los bucles es para lograr retraso. Hemos observado que algunas versiones de AceCryptor lanzan la capa 2 casi de inmediato, pero otras contienen bucles que requieren tanto tiempo que pueden ralentizar la ejecución incluso durante decenas de minutos: retrasar la ejecución de algunas partes del malware es una técnica conocida, pero el uso de llamadas API como Sleep ya puede generar algunas banderas. Incluso si no, algunas cajas de arena como Sandbox de cuco implemente técnicas para saltarse el sueño para evitar el retraso y proceda a las partes interesantes. La implementación de retrasos a través de bucles y la ejecución de código basura también es una complicación durante el análisis dinámico, porque el analista tiene que identificar qué bucles son bucles basura y, por lo tanto, se pueden omitir.

Una tercera técnica de ofuscación mediante bucles consiste en ocultar en ellos operaciones importantes. Entre los bucles basura, hay algunos que esperan una determinada iteración y justo durante esa iteración sucede algo. Por lo general, una API se carga usando GetProcAddress, que luego se usa o se desenmascara alguna constante como el desplazamiento de los datos cifrados. Si esa iteración particular de un bucle no ocurre, la muestra se bloqueará más tarde. Esto, en combinación con el código basura, significa que para analizar dinámicamente el malware, primero hay que analizar qué bucles o iteraciones de bucles se pueden omitir y cuáles no. Esto significa que el analista puede dedicar tiempo a analizar el código basura o esperar hasta que se ejecute todo el código basura. En la Figura 6 puede ver dos bucles donde el primero contiene una operación importante para la ejecución posterior y el otro está lleno de código basura. Por supuesto, esto puede no ser (y no lo es en la mayoría de las muestras) tan fácilmente visible entre todos los bucles, especialmente si los bucles con las operaciones importantes también contienen código basura.

Aleatorización: no harás YARA

Otra parte importante de la primera capa es la aleatorización. El código basura y los bucles mencionados anteriormente se aleatorizan en cada muestra, de tal forma que:

• el número de iteraciones cambia,
• Cambio de llamadas API,
• el número de llamadas API cambia, y
• cambio de aritmética basura o instrucciones MOV.

Toda esta aleatorización también puede complicar bastante la identificación del algoritmo y las claves de descifrado. En la Figura 7 y la Figura 8 puede ver la versión original, no ofuscada y ofuscada del algoritmo TEA. En la versión ofuscada, no solo hay instrucciones aritméticas basura, sino que también algunas partes del algoritmo se describen en subrutinas y las constantes conocidas (suma y delta en la Figura 7) están enmascaradas, solo para hacer que la identificación correcta del algoritmo sea poco probable o ciertamente más difícil. .

Figura 7. Función de descifrado de TEA: no ofuscada

Figura 8. Función de descifrado de TEA: ofuscada

El código no es lo único que es aleatorio. La capa 2 cifrada y su clave de descifrado se almacenan normalmente en el .text or .datos sección, pero se ocultan mediante algunos desplazamientos que cambian entre las muestras. Además, después de descifrar con éxito la Capa 2: en algunas muestras, el código de la Capa 2 está al principio de los datos descifrados, pero hay muestras en las que termina con un bloque de datos aleatorios al principio y necesita saber el desplazamiento correcto. para encontrar el comienzo del código de la Capa 2.

Los autores de AceCryptor también aleatorizan las siguientes características:

• La ruta PDB siempre comienza con C:, pero el resto de la ruta es aleatoria.
• Recursos con nombres y contenido aleatorios, como se puede ver en la Figura 9. Los autores de AceCryptor llenan muestras con recursos generados aleatoriamente que contienen datos generados aleatoriamente. Suponemos que esto se hace para que las muestras sean menos sospechosas y dificultar la localización de los datos cifrados reales. Los recursos pueden contener:
  • Mesas de cuerdas
  • Menús
  • Mapas de bits
  • Datos binarios
• Cadenas utilizadas en el código.
• Íconos: aunque los íconos que se usan en muchas muestras se ven similares, solo se modifican o aleatorizan ligeramente para que sean únicos.
• Nombres aleatorios de secciones ficticias.
• Funciones de asignación de memoria para datos de capa 2: Globalalloc, Alloc localy Virtualalloc.
• Uso de algunas API importantes para la ejecución del código: pueden importarse estáticamente u obtenerse a través de ObtenerModuleHandleA y GetProcAddress.

Figura 9. Los recursos de AceCryptor se generan aleatoriamente con contenidos generados aleatoriamente para que las muestras sean menos sospechosas

Figura 10. Cadenas aleatorias de AceCryptor en recursos

Versión anterior

A lo largo de los años, los autores de AceCryptor se volvieron más competentes en el desarrollo de malware y el cifrador cambió y evolucionó. Aunque hubo muchos cambios, actualizaciones y mejoras menores, algunas de las características interesantes de las versiones anteriores de la Capa 1 incluían lo siguiente:

• Durante 2016 AceCryptor utilizó una versión de Capa 1 con algoritmo de encriptación XTEA.
• Durante 2017–2018, AceCryptor usó una versión más de Capa 1, donde el algoritmo de cifrado utilizado fue RC4.
• Las primeras versiones (X)TEA y LCG de la capa 1 aparecieron en 2016. A diferencia de la versión LCG, la versión XTEA cayó rápidamente en desuso y fue reemplazada por la versión TEA.
• En versiones anteriores, la capa 2 cifrada estaba en los recursos ocultos en una imagen BMP. Esta imagen se generó aleatoriamente con ancho y alto aleatorios, y la mitad de la imagen se cortó y se reemplazó con datos encriptados. Los datos debían encontrarse en el desplazamiento correcto.

Capa 2

La Capa 2 de AceCryptor apareció en 2019. Hasta entonces, AceCryptor lanzaba la Capa 3 directamente desde la Capa 1. Esta capa sirve como encriptación y protección adicional de la Capa 3 y, como ilustra la Figura 11, consta de tres partes:

• código independiente de la posición,
• una estructura personalizada que nombramos L2_INFO_STRUCT, que contiene información sobre la capa 3, y
• los datos de la capa 3

Figura 11. Estructura de capa 2 de AceCryptor

Como primer paso, AceCryptor usa una técnica común para obtener algunas direcciones de funciones API. Resuelve el GetProcAddress y LoadLibraryA funciones mediante el uso de PEB_LDR_DATA para atravesar módulos cargados y comparando los valores hash de sus nombres de exportación con valores codificados. Como una función de suma de verificación, AceCryptor usa un shl1_añadir función, ya implementada en hashDB, que puede agilizar la identificación de las API resueltas.

Figura 12. shl1_añadir hachís implementado en Python

Entonces AceCryptor obtiene un identificador para kernel32.dll usando LoadLibraryA y usa eso y GetProcAddress para resolver más API.

Para los siguientes pasos, AceCryptor usa información de su estructura personalizada L2_INFO_STRUCT (que se muestra en la Figura 13), que se puede encontrar justo al final del código independiente de la posición, como se puede ver en la Figura 11.

Figura 13. Vista general de la L2_INFO_STRUCT de la capa 2

En los siguientes pasos, AceCryptor descifra la capa 3, que se cifra mediante LCG de Microsoft Visual/QuickC/C++. El descifrado ocurre en su lugar. Si el bandera de compresión está configurado, AceCryptor asigna memoria con el Virtualalloc API y descomprime los datos descifrados con el algoritmo de descompresión LZO_1Z. Después de esto, la ejecución salta a la Capa 3 descifrada y opcionalmente descomprimida.

Capa 3 – Proceso de vaciado

Como primer paso, AceCryptor obtiene las direcciones de LoadLibraryA y GetProcAddress API de la misma manera que en ` 2: recorrer módulos cargados, recorrer exportaciones y usar shl1_añadir sumas de verificación Luego, AceCryptor obtiene varias direcciones de función API y identificadores de DLL.

Figura 14. Estructura de la capa 3 de AceCryptor: vaciado del proceso

En el siguiente paso, AceCryptor usa la API Obtener Atributos de Archivo A y comprueba los atributos del sistema de archivos de un archivo llamado apfHQ. Los atributos se comparan con un combinación inexistente de banderas 0x637ADF y si son iguales, el programa terminará en un bucle infinito. Debido a que esto se usa en la última capa, que ya está bien oculta, y debido a que este no es el único truco aquí, asumimos que esta no es otra técnica de ofuscación, sino más bien un truco anti-sandbox/anti-emulador no documentado contra un desconocido pero sandbox/emulador específico que devuelve este valor.

Si el programa continúa con éxito, hay otra verificación anti-sandbox/anti-emulador. Ahora AceCryptor usa la API RegistroClaseExA para registrar una clase con el nombre de la clase saodkfnosa9uin. Luego intenta crear una ventana con el nombre mfoaskdfnoa usando el CrearVentanaExA API. En el último paso de esta verificación, AceCryptor intenta usar las API PublicarMensajeA y ObtenerMensajeA para pasar un mensaje. Debido a que estas API no se usan con tanta frecuencia, esta verificación ayuda a esquivar entornos limitados/emuladores que no han implementado estas API o donde las API emuladas no funcionan correctamente.

Figura 15. Truco anti-VM/anti-emulador

Después de pasar estas comprobaciones con éxito, AceCryptor utiliza el técnica de proceso de vaciado donde crea una nueva instancia del proceso actual (ObtenerLíneaDeComandoA, CrearProcesoA), asigna la carga útil final al proceso recién creado y lo inicia.

Versión anterior

Truco anti-investigación usando RegistroClaseExA, CrearVentanaExA, PublicarMensajeA, ObtenerMensajeA estaba en versiones anteriores (por ejemplo, SHA-1: 01906C1B73ECFFD72F98E729D8EDEDD8A716B7E3) visto utilizado en la Capa 1 y más tarde (cuando se probó y evolucionó la arquitectura de la criptografía) se movió a la Capa 3.

Capa 3: cargador reflectante

La primera capa de stephis, similar a Capa 2 y Capa 3 – Proceso de vaciado, obtiene las direcciones de los GetProcAddress y LoadLibraryA Funciones API. La diferencia es que esta vez, por alguna razón, los autores no usaron el shl1_añadir función de suma de comprobación, pero obtienen primero la GetProcAddress atravesando módulos cargados, atravesando exportaciones y comparando cadenas. Luego usando GetProcAddress ellos obtienen el LoadLibraryA función. Usando esas dos API, AceCryptor carga direcciones de algunas funciones API más y un identificador para kernel32.dll.

Figura 16. Estructura del cargador reflectante de Capa 3

En el código, hay un truco (que se muestra en la Figura 17) donde AceCryptor mezcla código con datos. AceCryptor controla un valor que está en la dirección de retorno después de una llamada. Este valor se establece de forma predeterminada en cero y luego AceCryptor escribe allí una dirección del punto de entrada de la carga útil final. Si el programa se parchea y el valor se establece en un valor distinto de cero, el programa saltará a la dirección a la que apunta ese valor y se bloqueará.

Figura 17. Mezclando código con datos

En el siguiente paso, AceCryptor realiza un conocido anti-VM comprobar dirigido contra Cuckoo sandbox, IDA Pro+Bochs y Norman SandBox. En la figura 19 se puede observar que la bandera SEM_NOALIGNMENTFAULTEXCEPT con el valor 0x04 siempre lo establece el sandbox de Cuckoo, y debido a eso, la segunda llamada de SetErrorMode en el código de la Figura 18 no devolverá el mismo valor que el establecido por la llamada anterior.

Figura 18. Truco anti-VM

Figura 19. código de Sandbox de cuco

En los últimos pasos, AceCryptor primero verifica si la carga útil final ha sido comprimida (nuevamente) y, de ser así, usa la descompresión LZO_1Z. Similar a la capa 2, el cargador reflexivo de la capa 3 usa una estructura personalizada, que llamamos ENCRYPTED_DATA_INFO_STRUCT (Figura 16), que se puede encontrar justo entre el código independiente de la posición y la carga útil final, que contiene información como el indicador de compresión, el número de secciones de la carga útil, el tamaño (des)comprimido de la carga útil, la dirección del punto de entrada, las direcciones de algunos directorios, la imagen dirección de la tabla de reubicación, etc. AceCryptor utiliza esta información (a diferencia de Capa 3 – Proceso de vaciado, que analiza el PE de la carga útil final) para realizar una técnica de carga de código reflexivo en la que reasigna (secciones de mapa, imagen de rebase, …) su propia imagen con la imagen de la carga útil final y lanza la carga llamando a su punto de entrada.

Conclusión

AceCryptor es un criptomalware prevalente y de larga duración, distribuido en todo el mundo. Esperamos que se venda en algún lugar de la web oscura/foros clandestinos como CaaS. Los servicios de este malware han sido utilizados por decenas de diferentes familias de malware y muchas de ellas confían en este criptor como su principal protección contra las detecciones estáticas.

Dado que el malware es utilizado por muchos actores de amenazas, cualquiera puede verse afectado. Debido a la diversidad de paquetes de malware, es difícil estimar la gravedad de las consecuencias para una víctima comprometida. AceCryptor puede haber sido eliminado por otro malware, que ya se está ejecutando en la máquina de la víctima, o si la víctima se vio afectada directamente, por ejemplo, al abrir un archivo adjunto de correo electrónico malicioso, cualquier malware interno podría haber descargado malware adicional; por lo tanto, puede ser muy difícil limpiar la máquina comprometida.

Aunque por ahora no es posible atribuir AceCryptor a un actor de amenazas en particular y esperamos que AceCryptor continúe siendo ampliamente utilizado, un monitoreo más cercano ayudará con la prevención y el descubrimiento de nuevas campañas de familias de malware empaquetadas con este cifrador.

IOCs

archivos

Nota: los archivos enumerados son una selección razonable de muestras a lo largo del tiempo, que cubren diferentes versiones de AceCryptor o empaquetan diferentes programas maliciosos.

Objetos nombrados

Técnicas MITRE ATT & CK

Esta tabla fue construida usando Versión 12 de las técnicas empresariales MITRE ATT&CK.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoAiStream. Inteligencia de datos Web3. Conocimiento amplificado. Accede Aquí.
• Acuñando el futuro con Adryenn Ashley. Accede Aquí.
• Compra y Vende Acciones en Empresas PRE-IPO con PREIPO®. Accede Aquí.
• Fuente: https://www.welivesecurity.com/2023/05/25/shedding-light-acecryptor-operation/