DESMANTELANDO BLACKENERGY, PARTE 2 – «LA MARCA»

No voy a hacer un discurso sobre qué es un marco de BlackEnergy ya que se ha escrito mucho sobre ello y sin mí, sin embargo, quiero referirme a la información de este particular revisión:

¡Todos, conozcan al Flashplayer!

Durante la investigación del ataque a nuestra infraestructura hemos detectado varias muestras de malware y entre ellas Flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/)Básicamente, flashplayerapp extrae main_light.dll en su propio espacio de memoria y transfiere el control a él. Esta biblioteca es una versión ligera de BlackEnergy y se utiliza para la comunicación C&C para descargar la carga útil principal con funcionalidad dependiendo de los objetivos perseguidos por el atacante. Crea un archivo: C:UsersuserAppdataAdobecache.datMientras está cifrado este archivo contiene varias informaciones incluyendo la versión de construcción (como 2015lstb), dirección del centro de comando y control desde el cual puede recuperar varias cargas útiles (como hxxps://188.40.8.72/l7vogLG/BVZ99/rt170v/solocVI/eegL7p.php) etc. Mientras examinaba esta muestra, cambié el enfoque del C&C ya que una parte particular del código llamó mi atención, ya que era una señal obvia de usar una técnica llamada permutación de código. Permítanme traducir una cita de esta fuente http://hacks.clan.su/publ/11-1-0-481:

Así es como se veía el fragmento de código (las instrucciones añadidas por el motor de permutación se destacan en rojo y no afectan en absoluto a la funcionalidad, solo hacen que el código sea más difícil de entender):Al eliminar las cadenas innecesarias, obtenemos un mecanismo que procesa todos los nombres de funciones en kernel32.dllconvirtiéndolos (nombres) en alguna forma de hash que luego compara con algún valor:Recreemos este mecanismo usando C como ejemplo. Como resultado, recibimos una utilidad que puede producir para nosotros un “diccionario” que contiene los nombres de todas las funciones en la biblioteca kernel32.dll y los valores hash de estos nombres. Intentemos buscar los valores hash que obtuvimos durante el análisis inverso del código en nuestro “diccionario” nuevo. Primero, buscamos el valor del registro EAX (0x5147F60F), y luego lo comparamos con el valor de referencia:Nuestra teoría está funcionando: nuestra muestra ha procesado el nombre de la primera función, ha creado el hash y ahora lo está comparando con el valor de referencia que está contenido en el búfer (0xC8AC8026). Buscamos este valor y he aquí… ¡obtenemos la función LoadLibraryA!Para saltar otro ejemplo de muro de texto, solo mencionaré que nuestra “muestra” utiliza el mismo enfoque para buscar otra función llamada GetProcAdress.Usando estas dos funciones nuestra “muestra” puede cargar otras bibliotecas y extraer las direcciones para las funciones que requiere.

Las huellas dejadas por el Motor

La técnica de hacer difícil el análisis de código estático a través de llamadas de función basadas en algún valor hash en lugar de su nombre no es nueva. Sin embargo, me llevó al siguiente pensamiento: a pesar de cómo se procesa el código malicioso, conocemos el algoritmo de hash de los nombres de funciones y así podemos buscar con confianza estas dos funciones (LoadLibraryA y GetProcAdress) en el código. Así que comencé a buscarlas en internet por las menciones de este hash (0xC8AC8026) para ver si alguien ha utilizado el mismo motor de nuestro ejemplo antes y, para mi sorpresa, encontré algo:Este hash se menciona por primera vez durante 2006 (el artículo solo se puede encontrar en archive.org): https://web.archive.org/web/20060614030412/http://osix.net/modules/article/?id=789

Más tarde, en 2008, un posible autor del algoritmo hace su aparición en el foro:https://exelab.ru/f/index.php?action=vthread&forum=6&topic=11845

Después, en 2009 se publica un artículo de análisis sobre shellcode MS08-067 en blogs.technet.com:  http://blogs.technet.com/b/srd/archive/2009/06/05/shellcode-analysis-via-msec-debugger-extensions.aspx

Luego, en 2013, la revista “XAKEP” (uno de los medios más importantes de Rusia sobre tecnología de la información y seguridad de la información) publica un artículo https://xakep.ru/2011/06/23/55780/ donde mencionan exactamente el mismo algoritmo que crea el mismo hash (!):Espera un segundo, la situación aquí es que el mismo algoritmo que genera los mismos valores hash está en uso durante más de 10 años y ¿nadie ha notado esto? Si no fuera así, entonces para que flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/) sea el mismo de la forma en que parece ahora, sería imposible que pasara desapercibido por las soluciones antivirus mientras ya vivimos en el año 2016:Hay una “marca” clara que queda por este motor de permutación concreto que se utilizó en nuestra muestra analizada y me parece una firma válida. Además, es bastante fácil de rastrear directamente en el texto claro:Bueno, tenemos nuestras suposiciones y la teoría está aclarada, así que procedamos a la práctica y tratemos de transformar nuestras conclusiones en una firma/regla para Yara:

rule API_Hash

{meta: description = «Hash of LoadLibrary that is {26 80 ac c8} y GetProcAddres {ee ea c0 1f}»

strings:

$a = {26 80 ac c8}

$b = {ee ea c0 1f}

condition: $a and $b

}

Lo único que queda por hacer ahora es probarlo contra múltiples muestras varias (por ejemplo de un laboratorio antivirus) para averiguar exactamente cuánto código malicioso fue empaquetado por este motor en realidad?
En este punto, solo puedo afirmar que fue posible para mí llevar a cabo el experimento en una cantidad muy pequeña de muestras en una de las compañías antivirus, ¡pero los resultados valen la pena! Entre las muestras capturadas, tenemos:Win32/Spy.Bebloh (troyano bancario) — http://www.virusradar.com/en/Win32_Spy.Bebloh/detailWin32/PSW.Fareit (Troyano para robar contraseñas) — http://www.virusradar.com/en/Win32_PSW.Fareit/detailWin32/Rustock (puerta trasera) — http://www.virusradar.com/en/Win32_Rustock/detailWin32/TrojanDownloader.Carberp (Descargador que instala el troyano bancario Carberp) — http://www.virusradar.com/en/Win32_TrojanDownloader.Carberp/detailWin32/Kelihos (emisor de spam) — http://www.virusradar.com/en/Win32_Kelihos/detailEsta lista contiene solo familias bien conocidas. Estos dos valores hash también aparecen en otras familias de malware, incluyendo Ransomware / cifradores de archivos (Win32/Filecoder.HydraCrypt), un minero de Bitcoin (CoinMiner.LC), un WinLocker (LockScreen.AQT) y otros.

Hasta ahora, también puedo agregar que esta regla Yara, que parece bastante simple, no ha dado lugar a un solo falso positivo hasta la fecha, pero la prueba se realizó solo en unas pocas docenas de computadoras. Por lo tanto, realmente expreso mis esperanzas de que después de la publicación de esta investigación, ¡Tú (!) y los que han leído hasta aquí compartirán sus comentarios, que serán lo suficientemente grandes para demostrar o refutar la precisión de esta regla! Por supuesto, usar solo ocho bytes para una firma es excepcionalmente pequeño y la regla probablemente atrapará algunos archivos “legítimos”. Sin embargo, esta regla Yara ligera puede vivir en una sandbox como parte de una lógica de análisis más compleja.

Conclusiones

El objetivo de este artículo no es la ingeniería inversa del malware BlackEnergy, sino que quiero destacar el hecho de que las herramientas utilizadas durante el ensamblaje de un código de malware u otro dejan sus rastros y pueden dar lugar a la aparición de indicadores útiles que pueden ser utilizados para la defensa. Y esos indicadores pueden permanecer sin ser notados durante bastante tiempo…

Traducido del original por Andrii Bezverkhyi | CEO SOC Prime