Initial Analysis & Outside Research
Not much is known about this malware or at least not much research has been done on it. Looking it up online did little to help be analyzed further and when I started to analysis it as well I could understand why. This malware for one is a GUI so automated running of it can’t allow for complete knowledge of its functionality. Also, it appears this malware needs specific criteria to even run properly or at all. These criteria I was not able to fully check but I was able to determine that it is what the malware needs.
This might have been malware which attacked the DNC but it is also part of a family of malware and this was not clear.
Static Analysis
Initially, like always, I check the executable for its type and its data directories and settings. This was a 32-bit PE stripped executable. It had a resource section that was not relevant to this malware and used PE explorer and PEID. There showed to be no indication that this malware was commercially packed.
Checking the imports tables, I came across something interesting. A TLS alloc function was weird because there was no TLS section or Table in this PE executable. I will look at this later.
In the strings window I found the following:
As I stated before, this binary doesn’t appear to be packed in anyway so this was clearly unusual. XREFing it with its sub routine of sub_40CA00.
This sub_routine does two things. It starts up this so-called unpack200.exe executable, and it DEBUGS. Upon further review, I noticed that this executable uses the EXE4J_LOG and ISNTALL4J_LOG environment names to record that data about the program. This program uses Java libraries to run specific commands and operations. I believe this was done to hide its initial functionality as these JRE functions do not show up on the Import Table.
Although everything is being recorded in the current directory of the name error, which isn’t even hidden, it’s hard to understand their intentions. The debugging is done in sub_routine 406FF4. I will call this sub_routine DEBUG In subroutine sub_40CC20 I see that the sub_routine ( 40CA00) is being called. 40CC20 gives 40CA000 an argument of jar files.
For those who do not know, Jar files are an archive format. This unpack200.exe “appears” to be unpacking these jar files and using the files inside them for some purpose.
I was able to find command-line arguments. It seems as though the command line arguments console can be used, although this had no noticeable effect on the program’s execution. From here, I just decided to jump right into dynamic analysis. I want to see what exactly is going on.
Autoruns
A software known as xtunnel2 was found as a new registry key for a file currently not on my system called PortMapClient -min.exe. This opens the door for what this malware could be. There is a family of Xtunnel malware.
Through static analysis, I was able to find an IP address: 45.114.10.45. I did an IP lookup, and it was a Chinese hostname, but at the same time, since this malware was rather old, this could be misleading seeing how someone else could have been using this IP.
I now have a method of capturing network traffic. Using the IP, I created a host-only network, redirected all network traffic to me, and sent data back using Interim. This didn’t lead to much except for the fact that every second that this program was trying to connect to an IP even when no buttons were being pressed. This was very suspicious. I will post the captured packet below.
This malware also can’t have two instances of itself open simultaneously. While that usually indicates a mutex that didn’t appear to be the case as I couldn’t find one.
💬 Comment: