Recently, David Litchfield asked me to help him out a bit with a research project he was working on by having me set up a network capture in my DMZ to log SQL Slammer attacks. I don't publish any services here at my Santa Cruz facility (meaning there are no required inbound protocols and no references in DNS anywhere) so I figured it would be nice "quiet" circuit to use for testing. I basically port-forwarded UDP 1434 to a laptop in my DMZ running NetMon3 also filtering for UDP 1434. After about 4 days of running NetMon, I had captured almost 30 (verified) random SQL Slammer attacks. What I found interesting was that every single one of them was sourced in China (all from different addresses).
Now, it's not my intent to start some geopolitical debate here, but I've long heard about how some people would block entire countries at the border in order to obviate issues with malicious traffic. There are obviously some issues with this (both from a technical and potential customer standpoint) so I set out to do a bit of research on my own. First thing I found out was that if one does decide to block entire countries, that it's going to be a bit of work from a rule standpoint. Sure, if I wanted to block all of China I could block APNIC, but that would block WAY more than I would want. So I set about finding a good resource for country-by-country IP ranges. Fortunately, Wade Alcorn, one of my colleagues at NGSSoftware turned me on to one that seemed pretty decent (there are a few around, though). But finding the resource was just the beginning... The list I got included 234 countries, comprised by almost 100,000 records of IP ranges.
Making a firewall rule to block China, for instance, would require entering in almost 600 IP ranges - so the "manual" route was clearly out. The thing is, I just didn't want to block countries without more research, so I needed a way to gather some statistics first. Enter ISA Server - as many of you know, I'm a big fan of ISA - it's a true enterprise security product with great scripting capabilities, so I set to work creating an automated method by which to create computer sets in ISA for each country. Basically, I created a SQL database and loaded all the records into it - I then wrote a little COM app to reach out and grab the data by countries, create the sets in ISA, and loop through the different ranges of IP's to add them to the set. It worked great.
This accomplished two things - one, I now have full detailed computer sets for each country to do with as I please. Secondly, I have an excellent way of producing detailed reports for traffic analysis in ISA- this was key. With data collection points set up at different places around the world, I was able to capture 3.1 million inbound connection attempts. The results were quite interesting. While China still led with connection attempts overall, it was interesting to see that Canada was a close second. However, while China's traffic consisted of SQL Slammer, HTTP, SMTP, probes for GhostProxy, etc, almost all of Canada's traffic was MESSENGER spam (UDP 1026,1027,1208). The world leader for HTTP was Brazil, strangely enough. Now, all of this will change based on who and where you are, and the types of services being offered. For example, I only got 5 SMTP connection attempts to my cable modem in a week, but my ISP in BM got hundreds of thousands (understandably) in the same time period. I'll whip up some cool reports for what I found and post them once I get some more data in from different collection points, but the valuable outcome of the project was the creation of these individual country-by-country Computer Sets for ISA.
Beforehand, I had no real way of easily and effectively reporting on traffic patterns by source country. Whether you can or can't block entire countries is your business, but at least this affords someone an easy way of doing research. You may not be able to (or even want) to block HTTP from China, but you very well may want to block SMTP - with ISA and computer sets, you can easily do this. Even if you don't block anything at all, you can use the sets to get rich reports of what kind of traffic your are getting from a particular country. While the validity of the practice of blocking entire countries (or particular protocols for that matter) may be up for debate, you now at least have the option to make your own decision based on factual information - to be sure, you've always been able to do this obviously, it's just been my experience that maintaining rule lists by country/protocol has been quite difficult and time consuming. I've exported every countries entire list to ISA 2006 .XML format, and have posted them on the HoG site for community use. Since I've automated the Set creation process, I'll be updating the sets each month or so to ensure that changes are processed correctly. I would like to thank NGSSoftware for purchasing the required business services to receive the updates - their donation makes it possible for me to give you updated sets for free.
The first file is a zip of all countries is you want that one. Go nuts!
Some have asked for the source of this data. It was dervied from free, open sources on the internet such as: http://ip.ludost.net
http://www.iana.org/assignments/ipv4-address-space
ftp://ftp.rfc-editor.org/in-notes/rfc3330.txt
http://www.cymru.com/gillsr/documents/golden-networks
http://www.cymru.com/Documents/bogon-list.html
http://www.cymru.com/Documents/bogon-bn-agg.txt
ftp://ftp.ripe.net/pub/stats/arin/delegated-arin-latest
ftp://ftp.ripe.net/pub/stats/lacnic/delegated-lacnic-latest
ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-latest
ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest
ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz

What people are saying about "ExtraOutlook":
Slava - "This tool is just AWESOME!!!! Thanks again..."
Erin - "That. Is. Pimp."
Greg - "Life just got alot better. Thanks heaps!"
Greg's Mom - "Do me Thor! Do me!"


As long as Outlook has been around, people have been trying to get two instances running at the same time. Not multiple profiles that you can load when starting Outlook, but two separate instances running concurrently, each with their own associated profile. After all, Outlook (even 2007) only lets you connect to a single Exchange server per profile... And that sucks.
What would be great is to have one instance connected up to your "business" Exchange Server, and another connected up to your "personal" Exchange Server (and of course, to other people's Exchange servers who don't you know have an account on their box ;).
If you've tried to do this, you've found that no matter what you do, you can't run two (or more) Outlooks at the same time, even if you try renaming .exe's, using command-line profile specifications, or any other tricks.
However, while futzing around one day trying to get two Outlooks running, I had what I thought was a great idea -- I'd configure a separate profile for Outlook under a different user account, and then use "RunAs" to launch Outlook as that user, and all of my dreams would come true. Boy, was I excited.
Well, it didn't work. In fact, it didn't work so well that it scared me.
When Outlook was launched via "RunAs" (no matter whether I executed Outlook.exe in a secondary "RunAs" command prompt or directly from the the interactive session), what happened was that a separate instance of Outlook did indeed launch, but it displayed the "concurrent" user's folders and NOT those of the user used to RunAs - no matter how you launched it! If during this time you viewed Task Manager, you would find that even though you saw two differnt windows running, and though you could interact with them individually (meaning, you could open different sets of folders in each separately, but they were for the same user) you only saw one instance of the .exe running. The first thing I thought was "Voodoo!!" I then said to myself, "Self, even though you launched it in a completely different user context, it hopped out of that user's space and hijacked your concurrent logon's files! WTF?"
During last year's Microsoft Ninjitsu training at Black Hat Vegas, I brought it up to my class and we all concurred that voodoo was afoot - even some Microsoft guys (who shall remain nameless) thought so and told me to STFU and to contact MSRC before talking about it anymore since it looked like Outlook was actually crossing user context borders.
True to "responsible disclosure," I called upon the skillz of Jason Geffner, a "reverse engineer" I work with at NGSSoftware. Jason is one of those irritatingly smart people that can do anything, so I knew he'd help me out (Actually, we've got lots of people like that at NGS ;). As it turns out, Outlook is doing nothing close to what I feared. Basically, the second instance sees that another Outlook window is running in the same interactive logon space, and when it starts, it just calls another popup in the previous Outlook space and then terminates itself (that's close enough, anyway). The good news is that there is no "user hopping" or "boundary crossing" here. A more detailed explanation of the actual technical process is available on Jason's site. The really good news is that Jason was able to intercept the exit process and patch the FindWindowA call to a NULL value, which started a completely separate Outlook instance and allowed a different profile to be selected on load! W00t! So, without further adieu, we are proud to present you with our "ExtraOutlook" tool that allows you to launch as many Outlook instances as you want. All you have to do is configure the profiles you want, and then type: ExtraOutlook.exe "C:\Program Files\Microsoft Office\Office12\OUTLOOK.EXE" (after you download it, of course).
Attendees of past Microsoft Ninjitsu classes have been using it for some time now (as all attendees get special access to the Hammer of God Member's Site) and we've not heard of any catastrophic failures (you know, like having all mailbox data destroyed without any hope of recovery).
Of course, use it at your own risk, and all standard warnings and disclaimers apply. Go nuts.
Ver 1.0 - Rel 1/11/08 - Public Release
Ver 1.1 - Rel 1/12/08 - Fixed error on XP
ver 1.2 - Rel 2/09/08 - Added support for Outlook 2003
Ver 1.3 - Rel 5/19/08 - Added support for command-line parameters

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 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.

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.

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!

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 is the first production Terminal Server brute force tool, and is now in release 2. 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.
TSGringer is a "dictionary" based attack tool, but it does have some interesting features like "l337" conversion, and supports multiple attack windows from a single dictionary file.  It supports multiple password attempts in the same connection, and allows you to specify how many times to try a username/password combination within a particular connection.
Note that the tool requires the Microsoft Simulated Terminal Server Client tool, "roboclient," which may be found here:

ftp://ftp.microsoft.com/ResKit/win2000/roboclient.zip

There are still a couple of bugs we are working out- for instance, we've got a problem with using "l337" conversion with more than 2 threads open. There have also been requests to support standard brute-force-via-character-iteration attacks, and we will get to this when we can.  In the meantime, enjoy the tool, and let me know how it works for you. For those interested in the Blackhat presentation Ryan Russell and I made in Vegas, you can find that here:

http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-mullen.pdf

Go nuts!

SQueaL is my new rogue 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.

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.)

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!