Analysing Suspicious File "Outstanding Payment.jar" - Part 2
How to use static analysis for cracking the encryption used by the author of the malware, and what information can be revealed about the author? The second part of an article on the analysis of a suspicious Java file out of three describes the penetration of another protective layer and partially uncovers the attacker.
In the previous part of the article, I started analysing the suspicious file "Outstanding Payment.jar". I managed to crack the first layer of protection against detection, largely due to the de-obfuscation of text strings, and the revelation of a state machine forming the core of the program.
The extracted directory structure contained several Java classes (.class) and 6 binary files:
Layer II – Encrypted Files
Names of the classes (manintheskymaninthesky..., iiiiiii...) once again, indicated obfuscation. Also the file drop.box, mega.download and sky.drive looked suspicious.
After some searching, I discovered the tool AdWindDectyptor (https://github.com/mhelwig/adwind-decryptor), which confirmed my assumption that I was really dealing with the jRAT malware.
It turned out that the file sky.drive is an RSA key to the mega.download file, which is an encrypted AES key to the final file drop.box.
So, I took the AdWindDecryptor, modified it a bit, and decoded the contents of the drop.box file:
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"><properties><comment>Support: https://jrat.io</comment><entrykey="SERVER_PATH">/h/TaL/D.qy</entry><entrykey="PASSWORD_CRYPTED">/N/fcp/w.q</entry><entrykey="PRIVATE_PASSWORD">/hZL/ycm/gi.U</entry></properties>
It contains configuration metadata describing the next layer of encryption. The defined variables and similar file sizes indicated that this could be the case of the same scheme as in the previous step. So I used the AdWindDecryptor tool again, while in this case, the RSA key was the file /hZL/ycm/gi.U, the AES key was the file /N/fcp/w.q and the data was stored in the file /h/TaL/D.qy.
A JAR archive was the result of the deciphering:
├──com │├──DataProtector.class │├──key ││├──amd64.dll ││└──x86.dll │├──protector ││├──amd64.dll ││└──x86.dll │├──Protector.class │├──ProtectorException.class │├──Title.class │└──TitleManager.class ├──META-INF │└──MANIFEST.MF ├──module │├──api.json │└──Server.class ├──org │└──json │├──CDL.class │├──JSONArray.class │├──... ├──server │├──b ││├──iiiiiiIiiI.class ││├──... │├──m ││├──iiiIiiIIIi.class ││├──... │├──main ││└──Start.class │├──resources ││├──config.json ││├──Key1.json ││└──Key2.json │├──t ││├──iiiiiiIiiI.class ││├──... │└──y │├──iiiiiiIiiI.class │├──... └──util ├──generic │├──Base64.class │├──Compress.class │├──Copy.class │├──Random.class │├──RandomRange.class │├──Reader.class │├──RunFile.class │├──RunJarFile.class │├──Shell.class │└──Sleep.class ├──mac │└──MacPermission.class └──windows ├──Regedit.class └──WscriptProcess.class
In addition, it turned out that the file /operational/iiiiiiiiii.class is not a Java class, but yet another JAR/ZIP archive. When unpacked, it looked almost exactly like the D.qy archive, except for a few bytes.
Layer III – Malware Core
This was probably the core of the jRAT malware itself. Some of the files were still obfuscated (iiiiiiIiiI.class, iiiIiiIIIi.class, ...), but different helper classes could be recognized intended for work with JSON, Base64, and ZIP formats, for executing system commands (Shell.class) or scripts in the VBS language (WscriptProcess.class).
Still a question remained – where is this malware connecting to, where does it come from? The server/resources folder contained the configuration file config.json, but it was encrypted. The same scheme (Key1, Key2) was applied 3 times already, so I decided to use the AdWindDecryptor tool again, which revealed the malware configuration:
{"DELAY_CONNECT":2,"DELAY_INSTALL":2,"ENCRYPT_KEY":"pxWReJbgtOOKlnnJxQbpVjaFh","INSTALL":true,"JAR_EXTENSION":"txt","JAR_FOLDER":"wert","JAR_NAME":"wert","JAR_REGISTRY":"wert","JRE_FOLDER":"koliy","MODULE_PATH":"Xmk/gVv/M.bZU","NETWORK":[{"DNS":"maquicantro.duckdns.org","PORT":7790},{"DNS":"ldouab.ddns.net","PORT":7790}],"NICKNAME":"New","PLUGIN_EXTENSION":"txt","PLUGIN_FOLDER":"awetuh","VBOX":false,"VMWARE":false,"WEBSITE_PROJECT":"https://jrat.io"}
In case of the second discovered archive iiiiiiiiii.class, a different configuration file appeared after applying the same procedure:
{"DELAY_CONNECT":2,"DELAY_INSTALL":2,"ENCRYPT_KEY":"cPFjgddXIBcXBCIseEuXTZjwi","INSTALL":false,"JAR_EXTENSION":"Vybgol","JAR_FOLDER":"fUTkALeaTxM","JAR_NAME":"uiylKSALYJr","JAR_REGISTRY":"WLyQyhWoosi","JRE_FOLDER":"HSIROD","MODULE_PATH":"zS/lq/BTk.GI","NETWORK":[{"DNS":"127.0.0.1","PORT":7777}],"NICKNAME":"User","PLUGIN_EXTENSION":"DhjWU","PLUGIN_FOLDER":"DdWDtpinxpf","VBOX":false,"VMWARE":false,"WEBSITE_PROJECT":"https://jrat.io"}
The iiiiiiiiii.class archive configuration contained only its own IP address 127.0.0.1 – this could be a local server listening on port 7777.
Much more interesting information was offered by the configuration of the D.qy archive. The obtained domain names were successfully translated into IP addresses and the countries of origin were located:
maquicantro.duckdns.org:
- 197.211.224.186
- Zimbabwe
ldouab.ddns.net:
- 188.53.34.50
- Saudská Arábia
I probably managed to find the IP addresses of the servers the malware is connecting to and from which it gets commands, or, respectively, to which it is sending stolen information. This was also confirmed by the search results:
Unfortunately, none of the IP addresses responded. Port scanning failed as well – all ports appeared to be filtered. It is possible that the servers have been shut down in the meantime – either by the attacker himself or as a result of a counterattack.
There was also another possibility, i.e. that the servers are filtering requests and allowing in only some IP addresses, or that there is a more advanced scheme in the game, e.g. port knocking.
Anyway, I was able to crack the second encryption layer and to uncover the malware configuration containing the addresses that the program likely communicates with.
All that was left was the program code itself, contained in the obfuscated classes in the server/ folder. I will be writing about this last stage in the final part of the article.
![[]](/static/images/article-icon--blue.929eff9893d6.png){kind=icon}