Hola a todos! En previsión del inicio de una nueva secuencia en el curso de
ingeniería inversa, compartimos con usted una traducción de un material muy interesante. Disfruta leyendo
Los últimos dos años se pueden llamar años de hackers de ransomware. El ransomware ha sido, sin duda, el tipo de malware más popular. Sin embargo, a fines de los últimos años, comenzamos a observar su declive en popularidad y su aumento a favor de los mineros. Es posible que en 2018 esta tendencia solo crezca.
Desde el punto de vista de la víctima, esto es un alivio, ya que los mineros no son tan peligrosos como el ransomware. Sí, ralentizan el sistema, pero tan pronto como los elimine, puede continuar usando su computadora como antes. Sus datos no son robados ni perdidos, como es el caso del virus ransomware.
Desde la perspectiva de un investigador de malware, los mineros son decepcionantes. No proporcionan suficiente material nuevo para un análisis más profundo, principalmente porque se basan en componentes de código abierto bien conocidos con poca o ninguna confusión o sigilo.
Sin embargo, de vez en cuando encontramos mineros que usan trucos interesantes. Recientemente vimos una técnica llamada "Heaven's Gate", que permite inyecciones en procesos de 64 bits desde cargadores de arranque de 32 bits. Esta idea no es nueva, su primera implementación se remonta a 2009, pero es interesante ver cómo se implementó en una nueva forma, obtenida directamente "de la naturaleza".
Los principiantes en el análisis de virus pueden leer una guía sobre qué es Heaven's Gate y cómo abordar su análisis.
Materiales para analisis
Este patrón se encontró en la continuación de la campaña de
Ngay (más sobre esto
aquí ). Verificar la biografía de tales muestras me llevó al
artículo @_qaz_qaz , que describe una campaña anterior con una muestra similar. Sin embargo, su análisis no incluyó la tecnología Heaven's Gate.
Análisis de comportamiento.
Para ver la inyección mencionada, debemos ejecutar la muestra en un sistema de 64 bits. Vemos que lanza la esencia del portátil, con los parámetros específicos de la minería de criptomonedas:
Mirando las líneas en la memoria en ProcessExplorer, vemos que este no es un cuaderno real, sino el
minero XMRig Monero.
Entonces, por el momento, estamos seguros de que la imagen de la computadora portátil en la memoria probablemente fue reemplazada por el método RunPE (Process Hollowing).
El cuentagotas principal es de 32 bits, pero cambia la carga útil a un portátil de 64 bits:
Lo más interesante es que este tipo de inyección no es compatible con la API oficial de Windows. Podemos leer / escribir en la memoria de procesos de 32 bits desde una aplicación de 64 bits (usando la API WoW64), pero no al revés.
Sin embargo, hay algunas soluciones no oficiales, como una técnica llamada "Puerta del cielo".
Revisión de la puerta del cielo
La técnica Heaven's Gate fue descrita por primera vez en 2009 por un hacker con el apodo de Roy G. Biv. Más tarde, se crearon muchas implementaciones, por ejemplo, la biblioteca
Wow64ext o, en base a ella,
W64oWoW64 . En su blog en 2015, Alex Ionescu describió
medidas para combatir esta técnica .
Veamos cómo funciona.
Ejecución de procesos de 32 bits en Windows de 64 bits
Cada proceso de 32 bits que se ejecuta en una versión de Windows de 64 bits se ejecuta en un subsistema especial
WoW64 que emula un entorno de 32 bits. Puede dibujar una analogía con un sandbox de 32 bits que se crea dentro de un proceso de 64 bits. Primero, se crea un entorno de proceso de 64 bits. Y ya dentro de él se crea un entorno de 32 bits. La aplicación se ejecuta en este entorno de 32 bits, pero no tiene acceso a su parte de 64 bits.
Si escaneamos un proceso de 32 bits desde el exterior usando un escáner de 64 bits, veremos que dentro tiene DLL de 32 y 64 bits. Lo más importante, tiene dos versiones de NTDLL: 32 bits (cargado desde el directorio SysWow64) y 64 bits (cargado desde el directorio System32):
Sin embargo, el proceso de 32 bits en sí no ve la parte de 64 bits y se limita al uso de archivos DLL de 32 bits. Para inyectar en un proceso de 64 bits, debe usar las versiones de 64 bits de las funciones correspondientes.
Segmentos de código
Para obtener acceso a la parte restringida del entorno, debemos comprender cómo se realiza el aislamiento. Resulta que todo es bastante simple. La ejecución de código de 32 bits y 64 bits está disponible a través de una dirección de segmento de código diferente: 32 bits - 0x23 y 64 bits - 0x33.
Si llamamos a la dirección de la manera habitual, entonces el modo que se utiliza para interpretarlo se establece de manera predeterminada. Sin embargo, podemos solicitar explícitamente un cambio utilizando el código de ensamblaje.
Dentro del minero: implementación de Heaven's Gate
No realizaré un análisis completo de este minero, como ya se ha descrito
aquí . Vayamos directamente al lugar donde comienza la diversión. El programa malicioso verifica su entorno, y si detecta que se está ejecutando en un sistema de 64 bits, utiliza una forma diferente de inyectar en el proceso de 64 bits:
Después de algunas comprobaciones anti-análisis, crea un nuevo proceso suspendido de 64 bits (en este caso, un bloc de notas):
Este es el objetivo en el que se implementará la carga maliciosa.
Como aprendimos anteriormente, para integrar la carga útil en un proceso de 64 bits, necesitamos usar las funciones apropiadas de 64 bits.
Primero, el gestor de arranque pasa el procesamiento NTDLL de 64 bits:
Lo que sucede dentro de la función
get_ntdll requiere una explicación más detallada. Como explicación, también podemos echar un vistazo a un
código similar en la biblioteca ReWolf.
Para acceder a la parte de 64 bits del entorno del proceso, necesitamos trabajar con selectores de segmento. Veamos cómo el malware ingresa al modo de 64 bits.
Parece que este código se copió directamente de la biblioteca abierta:
https://github.com/rwfpl/rewolf-wow64ext/blob/master/src/internal.h#L26El selector de segmento 0x33 se empuja a la pila. Luego, el malware llama a la siguiente línea: (de esta manera, la dirección de la siguiente línea también se inserta en la pila).
La dirección que se
retf pila se fija agregando 5 bytes y se establece después de
retf :
Al final, se llama a la declaración RETF. RETF es un "retorno lejano" y, a diferencia del RET normal, le permite especificar no solo la dirección desde la que desea continuar la ejecución, sino también un segmento. Como argumentos, toma dos DWORD de la pila. Por lo tanto, cuando se ejecuta RETF, la dirección de devolución se convierte en:
0x33: 0x402A50Gracias al segmento modificado, el código que comienza en la dirección especificada se interpreta como 64 bits. Entonces, el código que ve el depurador es de 32 bits ...
... en realidad de 64 bits.
Para cambiar de vista rápidamente, utilizo la función PE-bear:
Y así es como se ve este código si se interpreta como 64 bits:
Por lo tanto, el código que se ejecuta aquí es responsable de mover el contenido del registro R12 a una variable en la pila, y luego vuelve al modo de 32 bits. Esto se hace para obtener el
Bloque de información de subprocesos de 64 bits
(TEB) , del cual obtenemos el
Bloque de entorno de proceso (PEB) de 64 bits
desde aquí : observamos un
código similar .
Un PEB de 64 bits se utiliza como punto de partida para encontrar una versión de NTDLL de 64 bits. Esta parte se implementa de manera bastante
trivial (
aquí se puede encontrar una implementación "vainilla" de este método), utilizando un puntero a las bibliotecas cargadas, que son uno de los campos en la estructura PEB. Entonces, de PEB obtenemos un campo llamado
Ldr :
Ldr es una estructura de tipo
_PEB_LDR_DATA . Contiene una entrada llamada
InMemoryOrderModuleList :
Esta lista contiene todas las bibliotecas cargadas que están presentes en la memoria del proceso en estudio. Examinamos la lista hasta encontrar la biblioteca que nos interesa, en nuestro caso es NTDLL. Esto es exactamente lo que hace la función
get_ntdll anterior. Para encontrar un nombre adecuado, llama a la siguiente función, designada como
is_ntdll_lib , que comprueba el nombre de la biblioteca con ntdll.dll por caracteres. Resulta el equivalente de
este código.
Si los nombres coinciden, la dirección de la biblioteca se devuelve a un par de registros:
Una vez que encontramos NTDLL, solo necesitamos obtener las direcciones de las funciones correspondientes. Podemos hacer esto mirando la tabla de exportación de la biblioteca:
Se recuperan las siguientes funciones:
- NttUnmapViewOfSection
- NtGetContextThread
- NtAllocateVirtualMemory
- NtReadVirtualMemory
- NtWriteVirtualMemory
- NtSetContextThread.
Como sabemos, estas funciones son típicas de la técnica RunPE. Primero, NtUnmapViewOfSection se usa para desasignar el archivo PE original. Luego, en el proceso remoto, se asigna memoria y se escribe un nuevo PE. Al final, el contexto del proceso cambia para que la ejecución comience desde el módulo incorporado.
Las direcciones de función se almacenan y luego se llaman (similar a
este código) para controlar el proceso remoto.
Conclusión
Hasta ahora, los autores de los mineros no han mostrado mucha creatividad. Alcanzan sus objetivos confiando en componentes de código abierto. El caso descrito refleja bien esta tendencia, ya que se utilizó una implementación preparada.
Heaven's Gate ha existido por varios años. Algunos programas maliciosos lo usan para aumentar el
sigilo . Pero en el caso de este minero, los autores probablemente buscaron maximizar el rendimiento utilizando la carga útil que mejor se adapta a la arquitectura de destino.
Eso es todo. Puede encontrar más información sobre nuestro curso
aquí .