Analysis of facebookmessenger malware

In this latest analysis, I will be analyzing a recent piece of malware called the facebook messenger. This piece of malware has received some recent press, which to me makes it even more interesting to evaluate.

I started the analysis of this sample in my XP analysis VM. I began once again by taking a snapshot of the VM and a baseline using Regshot. I then started up Process Hacker and Capture Bat. Process Hacker is similar to Process Explorer but includes a few more advanced features, such as the ability to suspend a process and the ability to look into the memory of the process to see DLL's in use, what file handles are open, and basic network information very similar to TCP View. I will not cover how to run capture bat or take a snapshot as we have covered these items before.

Right away one of the interesting things here is that facebook messenger is less than 100k, yet after being run, it uses well over 20 Mb of RAM. Very Interesting!




What this interesting behavior tells us is that Facebook Messenger is relying on mostly built in Windows functions and DLL's for its capabilities. This a tactic used to make the malware more difficult to detect, as it is using legitimate libraries.

Next I went to the network tab and noticed facebook messenger opening a connection to smtp.mail.ru. At first this would seem to be a standard SMTP communication except that it is connecting to TCP port 8080 which is a standard web proxy or web server port. Using this port is most likely done to allow the malware to bypass firewalls that would normally block non-standard ports. Process hacker also indicated that facebook messenger was sending a TCP SYN, meaning it is expecting a live connection and response. Since the sample could not connect to it's server, the process went into a wait state using a UDP port.




Since I wanted to find out more, I moved on to my Regshot and Capture Bat Analysis. The Capture bat analysis didn't show much of interest, it seems that the activity of this specimen primarily takes place in memory. During this process I tried to terminate the process several times, with task manager which did not work. It's a good thing I have Process Hacker. Process Hacker has an arsenal of ways to terminate processes in Windows, chances are that if you run into process termination protection, that Process Hacker can bypass it.

Interestingly, Facebook Messenger made very few registry changes, this is most likely due to the fact that it is really jsut calling other windows libraries. The changes it made were designed to set facebookmessenger to autrun on bootup.

Next I went back to process hacker and looked at the strings in memory. I found a few interesting things such as what appears to be non-random obfuscated text.

Since this line of questioning was not getting as far as I wanted, I decided to load up REMNux and the HoneyD honeypot to see if I could complete the connection and see what the facebook messenger is sending to smtp.mail.ru.

To get the sample to redirct its traffic to my honeypot, I edited the hosts file (c:\windows\system32\drivers\etc\hosts) to redirect smtp.mail.ru to 192.168.40.120.

The screenshot below shows what I captured with Wireshark.

Next I started Remnux and edited honeyd.conf to set Honeyd to listen to port 8080.
You can edit the honeyd.conf file using your favorite Nix text editor. After editing the .conf file, start honeyd using the command honeyd start

HoneyD doesn't provide services of it's own, just a redirect to another service. As a result, I setup netcat using the command 'nc -l -p 8080' to have netcat listen to port 8080. At this point the conenction completed and the facebook messenger sent out a sting of text. The text appears to be obfuscated and encrypted (shown in the above screenshot). After the connection completed, facebook messener turned itself into a listener and began to listen on a UDP port. Even though I was unable to understand what was being sent, it is fairly easy to determine that this malware is sending system information to a command and control and then setting up to wait for commands to come back.

In this case I am really interested in what this malware is doing, so I will move on to some Brain Surgery/Static Analysis to determine what this malware is doing. Look for my next post in the next couple of weeks (Hopefully!)