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]

[supersnail]

[ZeR0-@bSoLu]

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