Wow, fun week for me to be gone.  vg12, PM me on this if you need more help.  I've spent more time in this arena than I care to remember.  In the short run, the advice you've people have posted here is a very good start.  The basic logic is that if the availability of those systems are more important to your business than tracking down someone to punish, then nuke the hard drive and drop a fresh OS onto the system.  Be very, very careful using backups to reinstall unless you can pinpoint when you were infected and can get a backup from before that point.  Also, don't trust the data on your system.  Just because you put a shiny new OS onto the box doesn't mean you are safe to copy data files or third party apps from the infected system.  I've seen people do that a million times.  When you are trying to figure out where this stuff came from, don't forget to look outside the infected system.  Check firewall and router logs that would show traffic to that box.  More often than not that will give you hints as to how they got onto your system, and they are more trustworthy than the logs on the compromised system.  Your first issue should be to identify the infection source, and it is usually going to fall into 3 areas:  infected file executed on the system, a host based attack aimed at the OS, or an application level attack.  If it was an infected file of some type, you are going to have to try and find evidence in the system logs.  You might also find evidence in your router or firewall logs of the tools trying to "call home" after the infection occurred.  If it was a host based attack your efforts will fall evenly between system and network logs.  This is where you'll see someone or something launching attacks against specific to a certain OS.  Application level attacks are similar in that they might go to certain ports, but the big focus here should be anything over your http ports (80, 8080, etc).  This is where you will usually see people throwing "the kitchen sink" at the web applications.  It is pretty common to see hundreds of attacks within a couple of minutes, usually SQL/CRLS/LDAP/etc injections and cross site scripting as well as IIS and Apache attacks.  All that being said, the safest thing to do is nuke that hard drive, install a new OS, and rebuild your data.

My immediate reaction was to simply agree with dean.  If it is your AP, why can't you just check the resource allocation table?  Any system with a full connection has to have registered with the AP to get an IP.  That seems to be the short and safe answer.  From a networking point of view you also need to ask yourself if the OS has any third party software that would block your ICMP requests (several software firewalls will do this).  In regards to Rogue Scanner, you need to take into account that the tools uses far more techniques than just a simple ping sweep.  It was initially created as a network mapping tool, and it uses several methods to identify devices.  When your ping sweep hits a windows box with a firewall, it probably just gets killed and you get no response.  Rogue Scanner won't stop there as it will hit open ports and read the ARP table of any reachable switches as well.  It will then try to ID the device based on the profile of open ports (similar to nmap -O), examine the format of the data packets that are returned (each OS typically makes minor changes that help in identification), or it reads the ARP table and tries to identify a manufacturer based off the MAC address.  The other level you need to consider here is that since this is a wireless AP you are going to have other problems.  I don't have to register with a network in order to simply throw my wireless card into sniffer mode and grab your radio signal out of the air.  The machines doing this are not going to get assigned an IP.  You will also have trouble if someone is performing man in the middle attacks (ie. they grab signals from valid users, run them through their box so they can read the traffic, then reroute the traffic to your AP).

I can't say that I'm mad about this.  When they moved the date they gave me access to another two day session and my company gets to send another person along at half price.  That means I get double the h@x0r time and a drinking buddy at the same time!

I'm back, and I managed to only check my emails with my treo in the airport on the way home.

To be honest, having one of the SANS/ISACA/ISC2 certs listed after your name will be more of a help than you think.  For your name at the top of the resume I wouldn't list more than 2 because it looks kinda crowded.  (ie.  Bender Roboto, CISSP, CEH is ok, Bender Roboto, CISSP, CEH, CISM, CISA, CFE, HMFIC, Esq. is not ok)  Still include a certs section at the very top of the resume that will list everything you have.  Honestly, the only rationale for this is that many companies now have handed over their hiring to recruiters (in house or out sourced) and experience says that some of these folks have the attention span of a fruit fly.  Having the cert in your title will catch their eye instantly.  If you don't catch their eye then there is a chance that the people who are doing the actual hiring will never see your resume because it never makes it out of HR hell.

I'm not.  We're taking hers...

Thanks all, but before everyone gets a head of steam on this, my wife and I got married over the summer but we had to put off the honeymoon because she's a teacher.  We got married on a Saturday and she started school that Monday.  Anyway, I can still send out the list of where we were registered if anyone is interested...

rance, I can try to get into specifics but it'll have to wait at least a week.  I'm leaving for my honeymoon tonight.  The short version of the story is that we consistently kept getting false positives on a type of DOS attack that used operating system response times as part of the signature, and we were getting random false positives on some windows xp/200/2003 buffer overflow attacks.  For the second set, this only happened when we tested servers that had the same 3 third party apps installed on them.  (an IBM app and two custom apps) The really shitty part is that we couldn't consistently replicate the problem.  We'd scan the same box 10 times in a row and it would come back clean 6 of the 10 times, and not clean the other 4.  This all happened after the customer challenged our findings so it was pretty embarrassing to have to backtrack and go through it again.  After I found out my staff was using a VM to do the testing I told them to boot from an image I'd burned onto a hard drive.  No more problems.  Systems were clean 10 out of 10 times, and we later got admin rights to the boxes and manually confirmed that the vulnerability wasn't present.  After we were done I reached out to some friends in other pen testing shops and got the same story.  "Testing from a VM will work just fine 95% of the time, but expect that last 5% to bite you in the ass."

Within some of the major IT organizations a bonus for the CISSP can run from $500 to $3000.  Anyone wanting to do major league consulting should consider the CISSP almost a requirement unless you have other heavy duty experience or certs that can take its place.  Having one does not mean you know what the hell you are doing, but more and more often we are seeing clients request staff with a CISSP.  As previously mentioned, it is also big within the government realm in order to cover recent regulations.

Good point to bring up.  Most of the auditing firms have to operate under VERY strict rules of independence, so if the audit is done by any of the major firms they are probably going to have to do some major background work to make sure they are not in violations of any laws.  This is especially true if your audit is "material" to any of their financial systems.  Basically, if I am going to touch a system that is has any impact on their publicly reported financial statements I first have to formally show that I am fully independent and have no vested interest in the results.  However, if this is an audit done by the company for the sole use of the company then you will often see these types of issues pop up.

I'll toss in my 2 cents again.  Like Chris I've got over a decade of .mil experience.  In addition I actually worked or on some of the teams that are now included in this command.  Everyone just needs to realize that you need to look at the issue from a variety of angles.  As for the training, yes, these guys are starting to get beefier and more complete training than they did in the past.  However, it is still a government and military organization so it will only work as well as it is lead/managed/targeted/directed/whatever.  The military is like any other organization in that it will have some major wins and some major flops.  Getting units like this stood up in the past has been a marginal success at best, but they did have some very strong "wins" here and there (no, I won't give examples) that had more to do with good planning and execution rather than technical ability.  Everyone also needs to consider how these teams have to face legal issues whenever they try to do what it is they are paid to do.  They truly need to be thought of as a weapons system, just like you would consider a bomber a weapons system.  You can't just decide you're pissed off at someone, fly a B-1 over their country, and start carpet bombing.  (Place George Bush joke of your choice here)  In that same regard, there are going to be constraints in that you can just wind up your team of "cyber warriors" and have them go take down stock exchanges and power grids.  To boil it down: The AF is the chartered service for electronic warfare and they are finally formalizing their approach, no matter how they put the teams together they won't work well unless they are managed well, and no matter what you see in the movies these guys are not just going to go pwn every IP on the intergoogle that pisses them off.

It was rigged! I demand a recount!  I did not have sexual relations with that woman!  Mission accomplished!  What?  Have you seen my baseball?

I'd suggest putting VMWare Server on your win 2003 server for the simple reason that it has the most heavy duty hardware.  Then start pulling down or building the virtual machines you plan to use.  For very simple training you couple simply have two VMs running on the same system, one with your target OS and one with your testing OS (BT3 or similar).  A better setup would be to run your target OS in a VM on your win 2003 machine, and then boot a live CD (or real install from another hard drive) on one of your laptops.  Make sure the VM is getting its own IP and is not being NAT'ed through the IP of the win 2003 machine.  Once you do that you should be able to hack from your laptop into the VM as if it were a real machine on the network.  Once you start getting your hands dirty you can also start setting up a virtual network.  Basically you will take the target OS, give it an extra virtual NIC, and link it to another VM running on that same system.  That way you have to hack the first VM to be able to see the second VM.  This is fairly realistic in what you'd see in real pen tests.  Often you need to pop an external system and then use that as a "hop" to attack systems further into the network.

I am in major agreement with Kev.  Before you go drop any level of cash pull down all of the free resources you can get.  BackTrack, Helix, Knoppix, etc for your tool sets.  Then grab VMWare Server (now free) and load up on different operating systems.  You can drop a full library on an external hard drive.  Don't forget to have different versions of the same OS so you can take shots at systems of different patch levels. One warning, don't expect to use the same setup for real testing.  It is well known that pen testing out of a virtual machine will result in slightly different results than testing "from the iron".  (ie.  you actually booted the OS and are using it live)  I got kicked in the pills over this just a short while ago.  One of the guys that worked for me forgot to bring our testing image (we boot off of external hard drives) to a client site so he used BT3 in a virtual machine to do some of his testing.  After we turned over our reports our client wanted to challenge one of the major findings. It turns out some of their admins followed behind us and used their own tools to validate our work, and they found one issue that they could not replicate.  It turns out that by using the VM the tester basically got a false positive on a fairly critical vulnerability.  This occurs because there is some level of abstraction occuring by your traffic having to pass our of a virtual network stack, into the real network stack, to the target, back to your real network stack, then back to your virtual stack.  It isn't common, but it can cause some odd behavior.  Morale of the story:  training with VMs is good, real world testing with VMs is not so good.

Just to play a bit of devil's advocate, internal audits and pen testing are going to have a lot of attention in the near future.  Organizations are starting to figure out that ignoring the internal aspect of security is going to cost them some money.  It got pushed into the forefront by the French trader that cost his bank $7 Billion and almost took out the global stock markets.  He wouldn't have been able to do 90% of his activities if he hadn't bypassed very week controls and popped a few systems and email accounts.  After that news hit the wires our firm got a lot of "feelers" from clients looking into someone coming in and doing a "checkup" on their internal systems.