The Malware Analysts Cookbook has some great information, I have been working through it but took a break to learn some python.  But the book does go over a number of tools you can use for various aspects of Malware analysis including some reverse engineering tools.  It does help a bit I suppose if you can reverse engineer so you can utilize some of the bad guys tools to your advantage but to be successful at RE, you may have to stick full time to it and ignore the pen testing.

I think to be successful at Penetration Testing, you need to have some decent background in a number of areas.  So having a bit of background in malware analysis could lead to understanding how to utilize some of your pentesting tools better.

Both HP and Cisco have some great management utilities built in to determine the port location of a source MAC address.  Takes less than a minute to find the source.  Now lets say your wireless closet is a frickin mess and it will take you more time to locate the patch panel number hunting through spaghetti, well then you can go to DHCP and search for the MAC/IP record and match it to the host, some folks can easily find a host if they know their staff well enough.  If you are in the 1000s, well it might be more difficult.  Keeping good network documentation is key. 

We should just start telling people that everyday you leave NT, 2000 and XP running, a kitten is killed.  oo or maybe a boy in a third world country is sent to college to prep for that C level position.

Where do you want to remove them from?  The mobile devices themselves?  At this time most of the major browser have released updates to their trusted root certificates/providers so the Diginotar is no longer a major threat.  Not to mention the company is not doing much since they had to declare bankruptcy. 

I understand what you want to do, but it may not be worth the time and effort.

Which is what separates us from the pros.  You can use scripts, but you gotta write them yourself

By default Windows firewall blocks all incoming unless the user adds it as an exception.  So unless you made changes to the XP firewall configuration, you will probably not be successful with the attack.  And even a client-side attack might prove difficult since user interaction may be required to OK the outgoing traffic.  Then again if the user is local admin, you may be able to sneak in the OK through the payload.

It is a lot to take in, which is why you don't typically see too many testers that don't already have a strong background in some facet of IT.  I am nowhere near the level to be a full pen tester, but I know enough background due to my years configuring firewalls, sniffers, servers, workstations etc, to understand what I am looking at and how to defend against it.    And its tough when you want to play in the arena with tools like metasploit or create scripts to assist you with gaining shell access (Shell is basically command line access to a system).  But you sometimes need to step back and realize to be good at some of these fun projects, you need to fill up on some background requirements so they are useful.  If you want a good challenge, try to crack something without the use of a tool using only what you have.  Remember someone had written these tools to make their life easier and we all benefit immensely from it.

Also many of the modules in metasploit have been added by the community.  Don't focus on popping shell on everything, although that is what you want to try and get in most cases, it is not necessarily the keys you are looking for.  Popping shell on one system may be the first step in gaining a foothold in the environment as well as doing additional recon to discover your true target. 

The reason why one would want to exploit the applications is because the bug/exploit available for them will pop shell.  For instance metasploit has a number of modules for Adobe Reader.  Some will help you created a bogus PDF or web link that will exploit a bug in older versions of reader and allow the attacker to get a reverse shell using Metepreter. 

In most cases you will see MS say the bug "could" allow remote code execution.  This does not necessarily mean you will gain remote access, but you can use the exploit to drop code that will allow you remote access.

Like cd1zz says, sometimes you need to take a step back and look at things as a whole.  An excellent book to take a look at is Professional Penetration Testing.  It goes into a bit about some tools but what it ultimately provides is great insight on the pen testing process.  It also has a number of challenges that use WebGoat, De-Ice vms and Hackedermia. 

yeah you lost me.  Lets back track...

You have an XP SP3 VM that you want to exploit correct?

But you can't find any modules in Metasploit that work right?

What is the patch status of your XP VM?  SP3 fixed a good amount of security holes, so review the dates.  Also some of those MS Security notices may require other services/applications to be fully exploited which is why I suggested installing a few other apps on the victim XP system.  Old versions of Adobe Reader, Java etc...

Well keep in mind, any "affordable" hardware firewall solution for you will really only be forwarding ports, so finding the vulns on the outside, is really not going to be much different than finding them from the inside.  You have specific services running on the systems and you will pick those up doing some network mapping and enumeration.  Then its just about finding ways to exploit those vulns.  If you want to simulate a more advanced firewall then you can setup a software based one on the host system and use it to route your lab traffic through.  You should be able to do this with some of the networking options that Virtualbox or vmware workstation provide.

I would also setup the lab at your home, mainly because that is a network you control.  The school's network may not always provide the ability to remote into your lab, they may block that sort of traffic and they also may block the traffic from your attacks.  An OpenVPN setup may give you better performance/access than logmein.  Or you can just setup your attacking system on the lab and connect to it over VPN over SSH.   Like impelse suggested, opening that system to the Internet, may not be wise.  Just as something like Backtrack is used to pen test, people know how to crack it just as well and take over the system for their own means.

Do you want to simulate attacking a network from outside, or just have access to this lab while not at school?

Simulating an attack from outside isn't too difficult.  You would be looking for exposed services, figure out what vulnerabilities exist and proceed.  That can be done without requiring a firewall.  Most of those hack OSes have what they need exposed to complete the exercise.

If you just want to access the lab when you are not at school well I wouldn't suggest SSHing into your backtrack system directly, I would setup a separate SSH server and then jump from there to your lab network, maybe configure SSH only use keyfiles so that not anyone can just try to hop on for added security.  Alternatively you can setup OpenVPN which I think allows up to 2 free VPN connections before you have to get the paid version.  That then gives you a nice VPN connection into your network and you can then freely connect to whatever you need to and even run attacks from your laptop.

Though this all depends on what you ultimately want to accomplish.

Nah install them on your virtual XP box, should be able to do that without a problem.  Why can't you get into your XP box on your VM?  You installed it right?  Why don't you have access to it?

Based on systems I've seen, a little of both.  I have yet to see a full implementation of app whitelisting and I've been in some places that use a completely flat network topology even though they have the ability to properly segment.  The reasons I have seen for both these factors have been typically due to impatience and lack of training.

So ok we have this nifty layer 3 core switch with all these lesser switches.  Cool lets set up VLANs so we can better secure our servers... 6 months later the ACLs have been all but removed because there are too many problems with traffic being blocked and rather figure out how to resolve, someone in upper management makes them turn off the rule that is blocking it.

We install a nifty enterprise level client side security suite.  We run all the pieces (firewall, heuristics and regular AV).  We figure cool lets use Application and device controls!  Rather than follow the vendor provided whitepapers and set the system to logging only on your test group, you decide to just add MS Office apps but then nothing else is working...  Rather than figure it out, you turn it off and only use blacklisting.

One more on Apps, patching...  Well we use WSUS so all our problems are solved!! 
"Ok so what about Java and Adobe patches?"
....
We don't patch those.
"How bout MS Office?"
Well WSUS does that right?
"No your WSUS is configured with default settings, you are only downloading Windows OS patches, you don't have Office checked off."

So with all that, your apps are not properly patched, your network is no longer segmented and your client-side endpoint protection is about as good as free AVG.  I won't even get started on the unused IDS/IPS appliance

Most companies who don't invest in talented individuals to run their networks tend to have all the shiny tools but none of them are configured properly or at all.  Back in the day, you would have to try very hard to crack the shell, but now you just need to compromise the human piece and then make your way back out of the shell.  Our traditional methods of detection no longer work unless you utilize the added pieces and start whitelisting the network.  Do not allow the unknown to run!

Or I am completely full of crap but that is for others to decide. 

VPS - Virtual Private Server.  Lots of services out there that offer it up for a reasonable fee.  Amazon Web Services might be a good place to start.

Understandable, though if you think about it, there are very few times where you will find a plain jane install of XP w/ SP3 and have no other applications installed in a production environment.  Like I had mentioned, start tossing on unpatched office, SQL Express or Adobe Reader and work at exploiting those rather than attacking the workstation directly.