Trojan Horse Uploaded Part 2: Malware Analysis

Coming up in this blog post: trojan horse receives commands from a Chinese C&C server and sends DDoS attacks to a Malaysian online casino website.

I'll be analysing the malware to determine what it does and also update you on the rest of the project as it's been a while since my last blog post.

My last post was back on the 14th December 2013 and since then I've been buried in revision for exams in January, along with post-graduate applications and graduate scheme applications.

This means there's not been a huge amount of progress on the project, but I'm aiming to get straight back into focusing on it now. I'm also eager to share some insights into the "disknyp" malware which came to light back in December.

Before I get started with the malware analysis, there have been a number of other blog posts discussing the malware. Thanks to the authors of the following articles for sharing their research on the "disknyp" binary:

• Unixfreaxjp's Malware Must Die post: Let's be more serious about (mitigating) DNS Amp ELF hack attack
• Andre M. DiMino's Another look at a cross-platform DDoS botnet
• Futex's Analysis of a Linux Malware covers a basic reverse engineer of the malware
• Cert Polska's A quick look at a (new?) cross-platform DDoS botnet
• Craig Valli, Priya Rabadia and Andrew Woodward Patterns and Patter - An Investigation into SSH Activity Using Kippo Honeypots

Analysing Malware

One of my previous blog posts (Trojan Horse Uploaded) describes an attacker that uploaded malware to the honeypot. In that post I described some basic research I carried out to conclude that the uploaded malware was a trojan horse.

Since writing that previous blog post, Dr. Gareth Owen from the University of Portsmouth has been in touch to share some early results from a similar research project that is analysing the same malware.

A big thank you to Gareth and his student Rich for getting in touch. Thanks to their help I now have a much better understanding of exactly what the malware does which I'll be explaining now.

Gareth sent over the strace (system call trace) output from the malware running on a Linux virtual machine along with a network pcap (packet capture) file. A sample of these files is shown below: (as usual, I've masked IP and MAC addresses to keep identities anonymous.

First, let's look at a snippet from the strace (system call trace) output where a connection to the C&C server is established:

[80642e1] connect(5, {sa_family=AF_INET, sin_port=htons(6009), sin_addr=inet_addr("198.40.**.***")}, 16) = -1 EINPROGRESS (Operation now in progress)

Here we can see that a connection on port 6009 is made to the IP address 198.40.**.*** (the C&C server).

Now let's look at the pcap (packet capture) file produced from the malware:

In the above pcap file; the malware sends and receives packets from the C&C server at 198.40.*.***. Presumably these packets communicate to the C&C server that the malware is connected and ready to receive commands.

In the next pcap file, the malware receives instructions from the C&C server (198.40.*.***) to carry out a DDoS attack. The actual DDoS attack packets are then captured from packet number 13:

As we can see from the above pcap data, the IP address 199.83.***.** is the unfortunate recipient of this DDoS attack and the sender is 148.***.**.***.

It's important to stress at this point that the outgoing packets are being blocked - i.e. the recipient of the DDoS attack isn't actually being attacked. The malware is running inside a virtual machine whereby only C&C traffic is being sent.

But this data does highlight how easy it is for a malicious file to send DDoS attacks from an infected machine without the owner of the infected machine knowing about it.

It's also worth pointing out that I've tried running the "disknyp" malware on a VM and was unable to connect to the C&C server. So it looks like the C&C server has either moved on or shut down.

I did some searching around to determine who is behind these IP addresses. It turns out the C&C server sending the commands (198.40.*.***) is located in China and that the IP address being attacked (199.83.***.**) is an online casino website based in Malaysia.

Further Malware Analysis Resources

Thank you to Gareth for recommending these resources. I'm aiming to start reading Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software by Michael Sikorski and Andrew Honig (No Starch Press, 2012).

I've also registered an account over at Virus Share, they're a "repository of malware samples to provide security researchers, incident responders, forensic analysts, and the morbidly curious access to samples of malicious code".

Other project updates

Thanks to Matthew from Mercer University (Georgia, US) for getting in touch. He's working on a similar project using Kippo honeypot to research SSH cyber attacks. We're planning to join forces and collaborate our data to compare SSH cyber attacks across the pond.

I'm also currently in the process of planning data collaboration with Rich from the University of Portsmouth (here in the UK), again to compare our data and see what conclusions we can draw from the comparisons.

Image credit: "Dengue virus infection" by Sanofi Pasteur, flickr.com/photos/sanofi-pasteur/7413644166

About the author

Simon Bell is an award-winning Cyber Security Researcher, Software Engineer, and Web Security Specialist. Simon's research papers have been published internationally, and his findings have featured in Ars Technica, The Hacker News, PC World, among others. He founded Secure Honey, an open-source honeypot and threat intelligence project, in 2013. He has a PhD in Cyber Security from Royal Holloway's world-leading Information Security Group.

Follow Simon on Twitter: @SimonByte