Hacking a Windows 7/8/10 machine remotely (stealing saved passwords and more!)

A really short run through on a real life example of total remote password and session cookie theft from a *locked* windows 7/8/10 computer.

Involves:
Cracking windows password remotely
Stealing all of chrome login data and cookies

Step 1 – Find the machine

nbtscan.

nbtscan 10.0.0.0/24

 

Step 2 – Find SMB Shares

smbclient.

smbclient -L -N 10.0.0.x

 

Step 3 –  Launch Responder

And capture some NTLMv2 hashes by sending poisoned responses to the windows machine.  I beleive the command is something like:

python Responder.py -I eth0

(You might need a few extra parameters).  It’s just a matter of waiting long enough to capture those oh so special hashes.  I’ve seen these hashes sent from my personal laptop on a network I marked as “public” before.  It seems like windows just gives my hashes out…

Step 4 – Crack the Hash

Throw the NTLMv2 hashes into john the ripper and try a few wordlists as well as john’s basic guessing functionality to try and get their password.  What I love about cracking NTLMv2 hashes is that it’s so fast!  I can get 2 million+ hashes per second!

>Assuming password is password

Step 5 – Log in

Now the we (hopefully) got their SMB login information, let’s run a unix mount.cifs command to mount their computer share locally.  Thankfully most default windows shares (especially on local/home networks) share the Users directory by default (/by design?).

It should be noted that the user is already basically totally pwned because we can steal all their files in their Users directory.  But we can go farther..

mount.cifs //10.0.0.x/Users ./mnt -o user=username,pass=password

Step 6 – Gimme Gimme

Lets take a few things.

  1. CREDHIST File
  2. SMI Identifier folder with all SMI identifiers
  3. Chrome Cookies file
  4. Chrome Saved Passwords file

Step 7 – What did we get? – analysis

Open those Chrome Cookies and Saved Passwords in a sqlite3 database browser and have a look around.  Usernames, site names, other data, and a bunch of random HEX for the password?? It’s all encrypted – as it should be.  So close yet so far…

Step 8 – We’re not done yet! – Plain text passwords time

But wait, there’s more.  The first thing that comes to mind is the Microsoft Data Protection Application Programming Interface (DPAPI) data Blob Decryption!  Rudimentary of course.

But actually, chrome uses the DPAPI to encrypt the passwords and cookies.  The DPAPI depends on the strength of the user’s password, which at this point we have assumed already to be cracked.

At the time of writing, to actually perform the decryption there are very limited options.  I found one program called “Windows Password Recovery” that can actually do the encryption of another computer’s DPAPI using the CREDHIST and SMI identifier.

Let’s plug in our cracked password, CREDHIST file, appropriate SMI Identifier for DPAPI Blob, actual exported DPAPI Blob hex data, and hit go!

Bam, plaintext passwords/session cookies.

Now it’s just a matter of gathering needed session cookies (better yet, persistent cookies like for facebook), formating them into javascript code, injecting them into a incognito browser window at facebook.com and logging in as the user!

Step 9 – Mitigation

It’s pretty easy to prevent this:

  1. Make your LAN/internal windows network SECURE
    1. this means secure wireless passwords, ethernet physical security, trusted users only, guest networks, network segretation/VLANs, etc.
  2. Use a strong windows login password (duh)
    1. It may seem useless to use a huge password (have to type it in every time, disk isn’t encrypted anyway so if someone wanted to they really could read your files) – not true!  Microsoft DPAPI uses your password to encrypt important information!  The more secure your password, the less likely someone can decrypt your saved passwords, or crack your NTLMv2 hash!

Conclusion

Looking back, I’m torn between if this attack was too easy, or really not a problem.  In reality, most computers do not share the Users directory on public networks, and rightfully so.  The attacker would need access to a home network or otherwise “private” marked network by a windows laptop to execute the above steps.

I suppose the biggest surprise was how the CREDHIST and SMI identifier are shared in the Users directory by default.  I’d imagine the files to be rather sensitive, but I’m not familiar with all the idiosyncrasies of windows.

  1. Don’t underestimate weak passwords – stay strong.
  2. This is actually kinda simple overall.
  3. Secure your wireless network, please.
  4. Just because it’s [insert current year] doesn’t mean your stuff is automatically secure, half the battle is securing YOU!
  5. Did I mention the use of strong passwords?
  6. Thanks for reading! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *