Reverse Jar Malware

[Yttrium]

Salut, j'aimerais connaitre votre avis a propos d'un malware reçu ce matin.

Je commence mon histoire en recevant un mail de 'Bitmine Tech' > billing@bitmaintech.com nommé 'Payment Invoice 142' et ayant pour text "Confirmation 142"
Ne comprenant pas du tout la raison de ce message, je me résous a analyser sur VM le fichier invoice_142.jar envoyé en pièce jointe, mais je suis vite bloqué.

Je ne m'y connais pas du tout en reverse de fichier java, et j'ai d'abord utilisé "jd-gui-0.3.6" qui ne me donnais que des fonctions totalement vide
J'ai ensuite essayé JAD158g qui a réussis a me donner plus d'info, mais que j'ai eu beaucoup de mal a comprendre.

Je post maintenant ça ici, en espérant que quelqu'un ai plus de chance et surtout de compétence dans ce domaine que moi


Voici le lien sur lequel j'ai Upload : http://multiupload.biz/nl_cqmib52lo8hu
Si vous avez des problèmes avec ce lien, signalé le moi, je n'ai jamais utilisé ce service.

Merci !

[supersnail]

Well, je regarde ça, et j'essaierai de poster un ptit rapport

[supersnail]

Bon, je poste ici le début de l'analyse (j'updaterai le thread au fur et à mesure des mes découvertes)

On a affaire ici à un .jar (donc on peut suspecter une appli codée en java). Le premier réflexe ici est de sortir jd-gui qui... ne fonctionne pas (c'est ballot). On va donc extraire l'archive (étant donné qu'un .jar n'est en pratique qu'un vulgaire fichier zip), ce qui nous donne une arborescence ressemblant à ceci:

Code :

.
|- META-INF
|    |- MANIFEST.MF
|- plugins
|    |- Server.class
|- stub
|    |- EcryptedWrapper.class
|    |- EncryptedLoader.class  
|    |- EncryptedLoaderOld.class
|    |- stub.dll

On peut apercevoir un "stub.dll", qui ressemble à un module qui va être chargé, sauf que un "file" dessus montre qu'il est visiblement chiffré (aucun header exploitable dedans). On va donc devoir se farcir de l'IL java, et pour cela on va utiliser notre ami Radare2 (je vous sens enthousisastes d'un seul coup :þ).
Plûtot que de prendre un fichier au hasard, on va plûtot repérer la classe principale (il suffit pour cela de lire le MANIFEST.MF) et la désassembler avec radare2.

On se retrouve donc ce code qui ressemble à ceci:

Code :

/ (fcn) sym.stub_EcryptedWrapper.main 35
|          0x0000080e    b20004       getstatic java/lang/System/out Ljava/io/PrintStream;
|          0x00000811    1261         ldc "gekvxgigir|ekztvx~pywdjcmblu{97R\tzekn`gicmr|s}@NLku{djdjq\x7ffhywu{}sztgi`naovx:4Q_wyfhmcdj`nq\x7fp~CMeBv{djdjq\x7ffkzwv{}sytgi`mbou{94R\tyekmcgicnq\x7fp~CMfk_xdjdjq\x7ffkytux}szwgi`malvx94Q\wzfkm`djcnq\x7fp~CMfhvQgjdjq\x7ffhztv{~sztdi`nblux:7Q_tyehn`dj`mq\x7fp~CMfhuxNidjq\x7ffhytux}pywgjcmalv{:4R_wzekm`di`mr|p~CMfhu{g@gjq\x7ffhywu{}sztgi`naovx:4Q_wyfhmcdj`nq\x7fp~CMfhu{diNiq\x10$.,$6:):5:g+9n��#:9n{\x03\x16w\x16$.80'+4!#\x7f&kM]f\x0c\x10\x16\x0bjg@r\x7ffhywu{}sztgi`naovx:4Q_wyfhmcdj`nq\x7fp~CMfhu{dj
|          0x00000813    b80058       invokestatic stub/EncryptedLoader/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/String;)Ljava/lang/String;
|             0x00000000(0x0, 0x0)
|          0x00000816    b60005       invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
|             0x00000000()
|          0x00000819    bb0014       new stub/EcryptedWrapper
|          0x0000081c    59           dup
|          0x0000081d    b70015       invokespecial stub/EcryptedWrapper/<init>()V
|             0x00000000()
|          0x00000820    59           dup
|          0x00000821    4c           astore_1
|          0x00000822    b60016       invokevirtual stub/EcryptedWrapper/load()V
|             0x00000000(0x0)
|          0x00000825    bb0017       new java/lang/Thread
|          0x00000828    59           dup
|          0x00000829    2b           aload_1
|          0x0000082a    b70018       invokespecial java/lang/Thread/<init>(Ljava/lang/Runnable;)V
|             0x00000000(0x0)
|          0x0000082d    b60019       invokevirtual java/lang/Thread/start()V
|             0x00000000()
\          0x00000830    b1           return

On peut donc voir ici ce qui ressemble vraisemblablement au chargement de ce qui va être la clé pour déchiffrer le stub.dll, qui va être passé en argument à la fonction stub/EncryptedLoader/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/StringLjava/lang/String (comprenez String stub.EncryptedLoader.ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe (String whatever)).
On va donc fermer notre classe actuelle pour aller inspecter cette mystérieuse méthode ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe.
On lance donc une analyse de notre classe via "af" puis on se positionne sur notre fonction avec "s sym.stub_EncryptedLoaderOld.ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe" puis on passe en "visual mode" avec "V" parce que ce sera beaucoup plus pratique pour nous pour debugguer (à noter que radare2 affiche des warnings, ce qui laisse supposer des tricks anti-désassembleurs qui font échouer jd-gui ).

Je reposterai donc quand j'aurai (ou si quelqu'un d'autre de plus familier avec l'"assembleur" Jasmin qui traduit le bytecode java) reversé la routine de déchiffrement du bouzin

Edit: cette portion de code ne semble pas décoder la DLL, mais visiblement ça a l'air essentiel pour pouvoir drop la DLL

[Yttrium]

Petite questin, il n'existe pas de "debugger" Java ? On pourrais laisser le programme tournée pour qu'il nous déchiffre directement la dll, et le bloqué avant qu'il ne lance le reste ?

[supersnail]

Y'a bien jdb mais ça a l'air encore plus relou à utiliser que gdb et pas sûr qu'il gère un bin trické de partout

Edit 2: Semblerait que ce soit obfusqué par du "Allatori" (en même temps y'avait qu'à regarder le nom de la fonction, /facepalm), et que la fonction que j'ai trouvé soit simplement une fonction d'obfuscation de strings (qu'il va me falloir reverser pour pouvoir continuer, yipee -_-)

Edit 3: Finalement j'ai réussi à péter la fonction de crypto de strings, et j'ai pondu un petit décodeur en python (celui en java ne fonctionne pas encore pour des raisons assez mystérieuses), dont voici le code ci-dessous:

Code PYTHON :

import sys

if __name__=="__main__":
    if len (sys.argv) != 3:
        print ("Usage: %s <methodClass> <dump file>" % sys.argv[0])
        exit()
    key1 = ((2 ^ 5) << 3) ^ 2
    key2 = ((3 ^ 5) << 3) ^ 4
    classkey = [ord(i) for i in sys.argv[1]]
    f = open (sys.argv[2], 'rb')
    payload = f.read()
    f.close()
    i = len (payload) - 1
    j = len (classkey) - 1
    ret = ""
    while i >= 0:
        ret = chr ((classkey[j] ^ (payload[i] & 0x7f) ^ key1) & 0xff) + ret
        if payload[i] & 0x7f == 0:
            i -= 1
        i -= 1
        if i < 0:
            break
        ret = chr ((classkey[j] ^ (payload[i] & 0x7f) ^ key2) & 0xff) + ret
        # Seems binary skips next bytes when encounters 0x7f, such wtf
        if payload[i] & 0x7f == 0:
            i -= 1
        i -= 1
        j -= 1
        if j < 0:
            j = len (classkey) - 1
    print (ret)

On remarque que le code est chiffré à l'aide de 2 constantes "key1" et "key2", ainsi qu'avec une autre chaîne qui s'avère être le nom de la méthode appelante concaténée avec le nom de la classe (avec le package) à laquelle appartient la méthode.
Ainsi, depuis EcryptedWrapper.main, la clé sera "mainstub.EcryptedWrapper" (étant donné que EryptedWrapper se trouve dans le package stub).
La récupération du nom de la classe se fait via un trick assez dégueu: en effet, la routine crée un objet Exception, puis appelle la méthode getStackTrace(); (qui renvoie un tableau de StackTrace), prend le 2ème élément du tableau (la stack frame de la fonction appelante) puis appelle getClassName ainsi que getMethodName.

Bref c'est tout pour aujourd'hui (et j'en profite pour mv le thread dans "Centre de virologie")

[supersnail]

Bon, des nouvelles du jour (je me suis mis à rebosser dessus):

Après avoir pas mal passé de temps à péter la routine de crypto qui ne servait finalement qu'à déchiffrer la banière du loader utilisé (Allatori ftw), j'ai donc analysé la suite du code, en constatant que le packer instanciait une classe stub.EcryptedWrapper puis appelait la méthode "init" de l'objet fraîchement créé avant de lancer un thread qui va lancer la "vraie" classe.
En regardant de plus près la méthode init de notre objet, on voit ce code-là:

Code :

[0x0000080e]> pdf@sym.stub_EncryptedLoader.load
/ (fcn) sym.stub_EncryptedLoader.load 49
|          0x00000771    bb0002       new stub/EncryptedLoader
|          0x00000774    59           dup
|          0x00000775    b70003       invokespecial stub/EncryptedLoader/<init>()V
|             0x00000000()
|          0x00000778    4c           astore_1
|          0x00000779    b20004       getstatic java/lang/System/out Ljava/io/PrintStream;
|          0x0000077c    125f         ldc "s"
|          0x0000077e    b80057       invokestatic stub/EncryptedLoaderOld/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/String;)Ljava/lang/String;
|             0x00000000(0x0, 0x0, 0x0)
|          0x00000781    b60005       invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
|             0x00000000()
|          0x00000784    2b           aload_1
|          0x00000785    b60006       invokevirtual stub/EncryptedLoader/load()V
|             0x00000000(0x0)
|          0x00000788    bb0007       new stub/EncryptedLoaderOld
|          0x0000078b    2a           aload_0
|          0x0000078c    5a           dup_x1
|          0x0000078d    59           dup
|          0x0000078e    58           pop2
|          0x0000078f    59           dup
|          0x00000790    2b           aload_1
|          0x00000791    b60008       invokevirtual stub/EncryptedLoader/getClasses()Ljava/util/HashMap;
|             0x00000000(0x0, 0x0)
|          0x00000794    2b           aload_1
|          0x00000795    b60009       invokevirtual stub/EncryptedLoader/getResources()Ljava/util/HashMap;
|             0x00000000(0x0)
|          0x00000798    b7000a       invokespecial stub/EncryptedLoaderOld/<init>(Ljava/util/HashMap;Ljava/util/HashMap;)V
|             0x00000000()
|          0x0000079b    b5000b       putfield stub/EcryptedWrapper/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe Lstub/EncryptedLoaderOld;
|          0x0000079e    b1           return
|          0x0000079f    57           pop
|          0x000007a0    4d           astore_2
\          0x000007a1    b1           return

On constate que notre programme va faire appel à la méthode "load" de EncryptedLoader (la classe contenant la routine pétée précédemment), dont le début semble particulièrement intéressant:
[code]/ (fcn) sym.stub_EncryptedLoader.load 228
|           0x00000e74    2a           aload_0
|           0x00000e75    59           dup
|           0x00000e76    b60083       invokevirtual java/lang/Object/getClass()Ljava/lang/Class;
|              0x00000000(0x0, 0x0, 0x0)
|           0x00000e79    120e         ldc "b!g42<u1"
|           0x00000e7b    b8001b       invokestatic stub/EncryptedLoaderOld/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/String;)Ljava/lang/String;
|              0x00000000(0x0)
|           0x00000e7e    b60062       invokevirtual java/lang/Class/getResourceAsStream(Ljava/lang/String;)Ljava/io/InputStream;
|              0x00000000()
|           0x00000e81    b7006c       invokespecial stub/EncryptedLoader/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/io/InputStream;)[B
|              0x00000000()
|           0x00000e84    4c           astore_1
|           0x00000e85    b20065       getstatic java/lang/System/out Ljava/io/PrintStream;
|           0x00000e88    1202         ldc "s"
|           0x00000e8a    b8001b       invokestatic stub/EncryptedLoaderOld/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/String;)Ljava/lang/String;
|              0x00000000(0x0, 0x0, 0x0)
|           0x00000e8d    b600e2       invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
|              0x00000000()
|           0x00000e90    b20065       getstatic java/lang/System/out Ljava/io/PrintStream;
|           0x00000e93    1202         ldc "s"
|           0x00000e95    b8001b       invokestatic stub/EncryptedLoaderOld/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/String;)Ljava/lang/String;
|              0x00000000(0x0, 0x0)
|           0x00000e98    b600e2       invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
|              0x00000000()
|           0x00000e9b    2b           aload_1
|           0x00000e9c    b8004d       invokestatic stub/EncryptedLoader/decrypt([B)[B
|              0x00000000(0x0)
|           0x00000e9f    4c           astore_1
|           0x00000ea0    bb000d       new java/util/jar/JarInputStream
|           0x00000ea3    59           dup
|           0x00000ea4    bb0032       new java/io/ByteArrayInputStream
|           0x00000ea7    59           dup
|           0x00000ea8    2b           aload_1
|           0x00000ea9    b700b9       invokespecial java/io/ByteArrayInputStream/<init>([B)V

Nous sommes ici face au code permettant de déchiffrer notre St-Graal qui se trouve stocké dans le .jar. Cependant le nom du fichier est chiffré, donc le premier réflexe qui nous vient à l'esprit est de lancer la routine de déchiffrement fraîchement analysée ci-dessus et c'est le drame, on obtient de la bouillie d'octets en sortie . Si l'on y regarde plus attentivement, on voit bien un appel de la méthode "ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe", mais de la classe EncryptedLoaderOld et non EncryptedLoader... Fort heureusement pour nous, l'algorithme est identique mis à part les clés key1 et key2 qui changent, et la "master key" qui devient ClassNamemethodName.
Voici donc le 2ème code pour déchiffrer nos strings (qui seront utiles par la suite) avec un hack cra-cra qui évite devoir créer un fichier pour déchiffrer un truc rapidement:

Code PYTHON :

import sys

def cipher_old ():
    key1 = ((2 ^ 5) << 3) ^ 1
    key2 = ((2 ^ 5) << 4) ^ ((3 << 2) ^ 1)# (2 ^ 5) << (3 ^ 1)
    #key2 = (3 ^ 5) << 4 ^ (3 << 2 ^ 1)
    classkey = [ord(i) for i in sys.argv[1]]
    try:
        f = open (sys.argv[2], 'rb')
        payload = f.read()
        f.close()
    except Exception:
        payload = [ord(x) for x in sys.argv[2]]
    i = len (payload) - 1
    j = len (classkey) - 1
    ret = ""
    while i >= 0:
        ret = chr ((payload[i] ^ classkey[j] ^ key1) & 0xff) + ret
        i -= 1
        if i < 0:
            break
        ret = chr((payload[i] ^ classkey[j] ^ key2) & 0xff) + ret
        i -= 1
        j -= 1
        if j < 0:
            j = len (classkey) - 1
    print (ret)

if __name__=="__main__":
    if len (sys.argv) != 3:
        print ("Usage: %s <methodClass> <dump file>" % sys.argv[0])
        exit()
    cipher_old()

Ce code nous permet finalement d'obtenir le nom du fichier qui sera déchiffré, et il s'agit du "stub.dll" situé dans le répertoire stub/ de l'archive.
On va ainsi pouvoir s'attaquer à la fonction decrypt() (la fonction stub/EncryptedLoader/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/io/InputStream[B ne fait que retourner un tableau de byte[] à partir d'un InputStream qu'on lui donne à manger).
On peut donc observer le code de notre fonction:

Code :

/ (fcn) sym.stub_EncryptedLoader.decrypt 73
|          ;-- entry1:
|          0x00001109    bb0023       new java/lang/String
|          0x0000110c    59           dup
|          0x0000110d    1300d9       ldc_w "?\x09-*[.zoAyK8Jp
|          0x00001110    b8001b       invokestatic stub/EncryptedLoaderOld/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/String;)Ljava/lang/String;
|             0x00000000(0x0)
|          0x00001113    b7011c       invokespecial java/lang/String/<init>(Ljava/lang/String;)V
|             0x00000000()
|          0x00001116    b600e8       invokevirtual java/lang/String/getBytes()[B
|             0x00000000()
|          0x00001119    4c           astore_1
|          0x0000111a    bb00e1       new javax/crypto/spec/SecretKeySpec
|          0x0000111d    59           dup
|          0x0000111e    2b           aload_1
|          0x0000111f    1300b6       ldc_w "\x08
|          0x00001122    b8001b       invokestatic stub/EncryptedLoaderOld/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/String;)Ljava/lang/String;
|             0x00000000(0x0, 0x0, 0x0)
|          0x00001125    b700a7       invokespecial javax/crypto/spec/SecretKeySpec/<init>([BLjava/lang/String;)V
|             0x00000000()
|          0x00001128    4d           astore_2
|          0x00001129    b20065       getstatic java/lang/System/out Ljava/io/PrintStream;
|          0x0000112c    130012       ldc_w "c"
|          0x0000112f    b8001b       invokestatic stub/EncryptedLoaderOld/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/String;)Ljava/lang/String;
|             0x00000000(0x0, 0x0, 0x0)
|          0x00001132    b600e2       invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
|             0x00000000()
|          0x00001135    13010c       ldc_w "X\x18KsJ\x08[rH\x17]\
|          0x00001138    b8001b       invokestatic stub/EncryptedLoaderOld/ALLATORIxDEMOxasdqwbymmgfghfghgrertwer23rfe(Ljava/lang/String;)Ljava/lang/String;
|             0x00000000(0x0)
|          0x0000113b    b800e6       invokestatic javax/crypto/Cipher/getInstance(Ljava/lang/String;)Ljavax/crypto/Cipher;
|             0x00000000()
|          0x0000113e    4e           astore_3
|          0x0000113f    2a           aload_0
|          0x00001140    2d           aload_3
|          0x00001141    5a           dup_x1
|          0x00001142    05           iconst_2
|          0x00001143    04           iconst_1
|          0x00001144    59           dup
|          0x00001145    58           pop2
|          0x00001146    2c           aload_2
|          0x00001147    b60118       invokevirtual javax/crypto/Cipher/init(ILjava/security/Key;)V
|             0x00000000(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
|          0x0000114a    b60111       invokevirtual javax/crypto/Cipher/doFinal([B)[B
|             0x00000000()
|          0x0000114d    b0           areturn
|          0x0000114e    57           pop
|          0x0000114f    4c           astore_1
|          0x00001150    2a           aload_0
\          0x00001151    b0           areturn

Comme on peut le constater, ce code fait un usage massif de l'API javax.crypto (ce qui veut dire moins de boulot pour nous \o/) et il suffit juste de filer un coup de script de décodage pour retrouver la clé/paramètres de décodage (attention cependant, il semblerait que la méthode "decrypt" soit appelée par une autre méthode "decrypt", la "master key" de décodage étant stub.EncryptedLoaderdecrypt.

Du coup il ne reste plus qu'à coder un petit prog java qui va déchiffrer notre stub.dll dont voici le code:

Code JAVA :

import javax.crypto.*;
import java.io.*;

public class Decipher {
    public static byte[] readBytes (InputStream is) throws IOException {
        ByteArrayOutputStream buffer = new ByteArrayOutputStream();
        int nRead;
        byte[] data = new byte[0x2000];

        while ((nRead = is.read(data, 0, data.length)) != -1) {
            buffer.write(data, 0, nRead);
        }
        buffer.flush();
        return buffer.toByteArray();
    }

    public static void main (String[] args) {
        if (args.length != 2) {
            System.out.println ("Usage: java Decipher <filename> <outfile>");
        }
        String method = "AES/ECB/PKCS5Padding";
        byte[] key = "0B4wCrd5N2OxG93h".getBytes();
        try {
            InputStream is  = new FileInputStream (args[0]);
            OutputStream os = new FileOutputStream (args[1]);
            Cipher c = Cipher.getInstance ("AES/ECB/PKCS5Padding");
            c.init (Cipher.DECRYPT_MODE, new javax.crypto.spec.SecretKeySpec (key, "AES"));
            byte[] out = c.doFinal (readBytes(is));
            os.write (out);
            os.close();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }
}
 

Et on a un joli .jar tout chaud qui s'ouvre très bien avec jd-gui, et un simple coup d'oeil montre qu'il s'agit d'un RAT multiplateforme, et pour le lol, un ptit dump de la config du machin:

Code :

?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>AlienSpy</comment>
<entry key="registryname">m1ShvIOUVO</entry>
<entry key="install">true</entry>
<entry key="pluginfoldername">Rj3b3ACoYg</entry>
<entry key="extensionname">cvf</entry>
<entry key="dns">hooka.noip.us</entry>
<entry key="prefix">Sooka_bad</entry>
<entry key="jarname">wy92UZ2Mgr</entry>
<entry key="reconnetion_time">3000</entry>
<entry key="install_time">3000</entry>
<entry key="connetion_time">3000</entry>
<entry key="password">da0a1a5d43f9935e5623bdc270d0e0c17a8ed7bf</entry>
<entry key="mutex">TgLmO4gLu1</entry>
<entry key="p2">98</entry>
<entry key="jarfoldername">6803l6FS1Y</entry>
<entry key="p1">97</entry>
</properties>

Pour conclure, nous avons eu affaire ici à un malware peu intéressant techniquement protégé par un packer commercial qui s'est révélé malgré tout amusant à analyser (pour les plus observateurs, vous aurez remarqué que certains prototypes de fonction étaient volontairement erronés, sûrement pour perdre les reversers peu expérimentés/outils de désassemblage). Bref je vous invite à essayer de l'analyser par vous-même et vous documenter sur le langage "d'assemblage" de la JVM pour vous amuser à retrouver les routines de crypto analysées

[ZeR0-@bSoLu]

je poste juste ici pour dire que c'était intéréssant à lire