UserInfo v1.5
UserInfo is a little functiod that retrieves all available information about any know user from any NT/Win2k system that you can hit 139 on. Specifically calling the NetUserGetInfo api call at Level 3, UserInfo returns standard info like SID, Primary group, logon restrictions, etc., but it also dumps special group information, pw expiration info, pw age, smartcard requirements, and lots of other stuff. This guy works as a null user, even if the system has RA set to 1 to specifically deny anonymous enumeration.
UserDump v1.11
UserDump is UserInfo with a twist. It combines LookupAccountSID and LookupAccountName with UserInfo's NetGetUserInfo calls, resulting in a SID Walker that can dump every user in a domain in a single command line. It gives you all the information that UserInfo does, but it lets you specify the number of users you want to walk. Pretty cool. Also runs as a null user, even with RA set to 1.
ProbeTS v1.0
Seeing Erik Birkholz and Clinton Mugge easily redirect terminal server requests to different ports at Blackhat scared me. If you change the default Terminal Server port from 3389 to something else, it is basically undetectable unless you physically try each port. This means that one of your admin people could easily hide a Terminal Server somewhere on your network that you would have no way of finding... and that ain't good. ProbeTS gives you a leg up. Though it takes a back door approach, ProbeTS will scan a full C-Class for you to determine if terminal services are being offered up regardless of what port is actually being used. There is no magic here... You have to be able to hit the boxes with RPC, and you have to be an authenticated TS user on the target machine. This would typically limit its use to Domain Admins, but it is more than you had to begin with. Don't expect it to be too fast either- What you gain in being able to identify an any-port terminal server, you give up in speed. Specifically, it loops through your C-Class, and asks every IP address for a terminal server handle. If it gets one, it knows it is a TServer. Simple, but effective.
TSEnum Beta v0.91
This guy goes about things a little differently than ProbeTS does. There is certainly a place for ProbeTS in the LAN, but TSEnum has proven to be a bit more powerful- that is, if I can figure out why I am getting different results when I run it. Feel free to email me with any idiosyncrasies in its operation.
TSEnum (Terminal Server Enum) is actually a lot more than that- it is an EVERYTHING enumeration tool. Again, my goal was to find a good way to quickly scan the network for rouge Terminal Servers ala Erik and Clinton's hiding techniques. When a server/workstation joins the domain, it registers itself with the master browser. Part of this registration includes the server type, which can be retrieved via the NetServerEnum function. This is basically a remote API call that gets the target box to query its master browser for everything that it can see, and asks it to dump it all back to you. Cool stuff. What I need help with is the testing in different environments. I have been able to successfully enumerate all the servers in other domains with no credentials, and without having to do an anonymous net use first... But, sometimes it errors out on me, even when it worked previously. Go figure. So, give it a shot and let me know what you come up with. Thanks!
TransportEnum v1.0
When I was doing research for my RestrictAnonymous stuff, I basically went through lots of different Net API calls to see what I could do as an anonymous user. I was particularly interested in calls that could made as NULL even when RA was set to 1. The NetServerTransport Enum call is one such call that supports and SERVER_TRANSPORT_INFO_0 level structure return in such circumstances. It basically allows you to get the transport names (devices) in use on a box. With NT4, the protocol name usually contains the adapter type as well as the protocol, so it was pretty easy to see stuff like modems, net cards, etc in a dump... i.e. a box running TCP/IP on an Intel card would dump something like:
Transport: \Device\NetBT_E100B1
Address: 00a0c9740202
This was really useful to enumerate all the transport information, modems included, on a box/domain. However, in Win2k/XP, the transport name has changed to a Unicode character string that contains the device name, and what looks to be a CSID or something as in:
Transport: \Device\NetBT_Tcpip_{CE081110-126E-4BD1-88B0-2FF8C1D83D10}
Address: 00c0f06cdf7a
You get the protocol name still, but it is hard (for me without doing other research) to see if the device is a modem or not without finding out what that CSID is. So, hopefully, someone out there will come across this and have to time to contribute to the tool in regard to mapping out what the CSID means. Please let me know if you find anything interesting.
TSGrinder [Under Development]
TSGrinder will be the first production Terminal Server brute force tool, unless you read this and beat me to it while I'm still working on the damn thing. The main idea here is that the Administrator account, since it cannot be locked out for local logons, can be brute forced. And having an encrypted channel to the TS logon process sure helps to keep IDS from catching the attempts! I am cheating, and using the TS ActiveX web client to do the hard stuff for me. The tool is taking 2 paths: 1) C++ development, in which case I am accessing the non-scriptable methods of the tool via vtable binding (thanks to Dave Russell for pointing me in the right direction here). This still proves to be the fastest as most powerful method. However, Junaid Khursheed pointed me to a Q article (Q281417) detailing how to access the same functions via VB, which all the docs in the Web Client download say you can' do. Go figure. Anyway, the VB app seems to only work if the TServer itself has been specifically configured to not "Always prompt for a password", which is NOT by default, so that obviously is not the best choice. I'm still figuring out how to get the C++ stuff to work.
On an aside, I found that setting a "logon banner" on your Terminal Server, causing a notification message to be displayed and acknowledged* before the logon screen is presented, is a pretty good way to mitigate automated attack methods like TSGrinder. You can still run the tool, but you would have to sit there and click-through to the logon banner "OK" button each time you attempted to push the credentials through to the server. No one is going to go through the trouble.
* Note that Win2k Pre-SP2 configurations have a logic bug in the "logon banner" setting, which actually makes it cancel itself after 2 minutes if you don't hit OK. So, even though you have a logon banner set, it will go away all by itself after 120 seconds of no activity, and present you with the logon prompt. TSGrinder will patiently wait for this screen to disappear (since I can't figure out how to test for its existence and programmatically hit "OK" for you). If you have a Terminal Server, set a Logon Banner. Also, rename the Administrator account. Hopefully your Internet-facing TS boxes are locked down hard enough that null enumeration will not reveal the 'real' administrator account. The first thing we would try is to brute force the "Administrator" account name, so just rename it to be on the safe side.
* 9/19/01 There have been some really cool developments with TSGrinder brought about by some information passed along to me by .sozni regarding some .dll's that can do things I could not previously do. There has been alot of interest in this guy because of the increased deployment of Terminal Services, and of course, because of the profiling of TSGrinder and my other tools in Hacking Exposed Windows 2000 (which is a great book that I highly recommend.) I'm still trying to figure out some of the multi-thread usage required to make this guy work, so please be patient. Your calls will be answered by the next available operator!
* 3/7/02 I've been hanging out at Halvar's dissassembly talks and Blackhat and think I may be able to pull this one off now. .sozni has pointed me in the right direction with the sclient (simulated client) dll's from MS, but they have no docs to speak of. I've been using LoadLibrary() to try to figure out how to make the channel commands work, but it has been difficult. I'm hoping to have it all finished for Blackhat Vegas. We'll see how it turns out.
SQueaL v1.0
SQueaL is my new rouge SQL2000 server impersonator written under Linux using DilDog's most excellent TalkNTLM C++ code (the Telnet Server exploit) as a basis. Though the packet structures and NTLM negotiation between an MS client and SQL200 are completely different than the standard NTLM authentication, and most parts of the code had to be completely rewritten for this to work, I must give credit to DilDog for making his code available. DBNETLIB supports NTLM authentication, and as shown in my presentations at Blackhat and Defcon (though my demo hosed up on me! Damn White Russians!) you can 'force' an MS client with DBNETLIB loaded (and guess what, it is on XP by default <bfg> ) to authenticate to you over port 1433. This guy will wait for a connection, negotiate NTLM authentication and parse out the plain-text username and domain, along with the NTLM response hash for your cracking pleasure. At some point, if I don't run out of Vodka, I'll try to duplicate SMBRelay-esk functionality to use the response to authenticate back to the client if 139/445 is open. I don't know how to do that yet, so I may be full of crap.
* 3/7/02 OK- Here it is. I have had mixed results in different environments with the tool. Sometimes it works, sometimes it doesn't. Here is the source, so you can all hack away at it and see how well you do. PLease let me know if you find something I need to know or if you have any ideas. Thanks.
Mutex v0.02
Blaine Kubesh reported on a Security Focus list the fact that Nimba's execution relied upon a named mutex (MUTually EXclusive object) to run. Running a program that creates this named mutex first causes Nimda's load to fail (reportedly- I actually do not have the means to test it). Here it is; It is a simple console program that opens, creates the named mutex, and keeps running until you hit 'q' to close the handle and exit the program (leaving you exposed again). Note that this is ver 0.02, which fixed a problem where I named the handle, but did not actually name the mutex (Doh! Thanks to Jason Anderssen for bringing that to my attention.) Source code included (what little there is.)
URLScan DTS package v0.01
Microsoft's URLScan utility for IIS is great, but the urlscan.log file is pretty basic-
URLScan only lets you log to a text file in a simple one-after-another appended manner, and only
to a single file (no multiple files to break out week/month entries as IIS does).
This makes monitoring the entries in the log file difficult, which is a shame because it is good to
see what attempted URLs get filters for incident response. To help with this, I have created a DTS package
that runs on SQL2000 to automatically do the following:
1) FTP the urlscan.log file to a temp dir on the SQLServer (this way, you don't have to stop IIS).
2) Parse out the date,time, IP address (if available) and the URL that was filtered and post to
a temp table.
3) Select only the entries for the previous day, and post those to the warehouse table.
The urlscan.log file just keeps getting bigger and bigger, so at some point, you'll want to stop IIS and
delete that guy. The nice thing about loading it into a temp table first is that you can ensure that only
the day-by-day entries get posted into the warehouse table.
For each server you want to pull data from, just add another package and schedule execution appropriately- the current setup is designed for sequential downloads from multiple servers; in other words, you should only do one at a time, and give adequate time between schedules for each to execute- make sure you execute them after midnight so that all the entries for the day will be included.
If you want to pull multiple server asynchronously, you can customize each package to use a different temp file name and then all at the same time... Whatever you want to do. I am making the assumption that you have some idea how to use and configure DTS packages.
You only need to do 2 things to the package for it to work with your server:
1) Change the properties of the FTP task to point to your web server, and make sure you select the
urlscan.log file to get downloaded. The default dir on the server is C:\TEMP.
2) In the last SQL Task that posts data from the tmpURLScan table to the real URLScan table, change the
text string from 'SERVER' to the name of your server.
Note that this assumes you have a DB named IISLogs; you can change it to whatever you want, but know that you need to check for that in the data pump tasks.
This way, you end up with a great way to sort, retrieve, group and report on data in the log files.
A note about FTP server setup:
On the web server that you want to pull data from, just create a new FTP site that points to the directory containing the urlscan.log file. For security purposes, it should be read only, and limited to your internal IP addresses. I created a new user specifically for this purpose that only has read permissions to the URLSCAN.LOG file, with specific deny permissions on the rest of the files- you can never be too safe- the real reason I deny access on the other files is that would not want someone internally to be able to sniff the creds, FTP in, and look at my URLSCAN.INI file to see exactly what I had configured.
Good luck!
Reply With Quote
holes - everybody\'s got\'em.
