Caught on the honeypot

A while ago, I have found a new malware in my honeypot, that virus total failed to recognize. I have resubmitted it a couple of hours ago,  and found out that the big AV companies still do not recognize the malware – 15 / 46 detection rate.


While analyzing the PE header for anomalies, I have found that the .data section has Read, Write and Execute permissions, which hints that the malware modifies it`s code during execution.


This piece of malware has a lot of interesting strings. I prefer to look for strings using IDA because it makes it easier to find what each string has to do with the Malware:

The first thing I have found is a long list of common passwords. Arround 110 passwords like super,temp123,test123,secret,qwerty,password, etc…

PasswordStringsThe next one is Software\Microsoft\Windows\CurrentVersion\Run – The famous way of malware to achieve persistence. While looking for a reference to the string, I have found another string from the list: PHIME2008 which is the name of the value created in that key. The malware author did not bother itself, and the data (The name of the file to execute in startup) is the path from which the file was executed, appedend with the parameter /sync

REGwithParamI Have also found an IP Address, and a couple of strings that look like URLs. The IP Address had two cross-references:

IP-XrefsThe first one (sub_401C40) seemed to send some information to the destination IP. (Language, country, computer name and username)

senddata2This function has a lot of arguments, therefor the easiest way to understand what this Malware is trying to send, is using ApateDNS and netcat, and capturing the traffic. 

The malware tried to download a file from the path:  /updata/ACCl3.jpg in the IP I have found before. But that server does not exist anymore.  iNetSim does not  disappoint, and hands the Malware a jpg file just like it wanted.

DownloadingTheJpgIDA GettingTheJpgThat JPG the malware tried to download, apparently is not a JPG (The server is down, so we can only assume). The JPG is downloaded in the function sub_401EB0. The function tries to check if the file named msupd.exe at the system directory exists, and if it does not, it tries to download it. Now we can say for sure that this is not a JPG. The malware downloaded the supossed picture file from the internet, and placed it in system32:



The fact that it saved it as with exe extension, proves the Malware intended to download an executable.

The next string I have noticed is GET /updata/TPDA.jpg. After looking for cross references in IDA, I have found some parameters appended to the HTTP request before it is sent. Again using iNetSim, I have managed to get easily which data is sent over the network.





The malware sends to its control server the time-stamp, country, internal IP, computer name and username.

Next post will cover the interesting network behavior of this malware (hint: password guessing) by using a higher interaction honeypot than iNetSim.