Passing an NTLM Hash to the Browser

In some scenarios, an attacker may have been able to extract Active Directory password hashes but has not been able to successfully crack some or all of them. In this case, it may be possible to perform authentication by merely passing the hash itself, instead of the password. The specific focus of this post, is a pass-the-hash attack on a website which uses NTLM authentication.

(click to zoom)

Under normal circumstances, a user might pull up Internet Explorer and browse to the website which uses NTLM authentication. At that point, if this user is not a domain user, they would typically get a prompt for a username and password. If the user who is logged into the computer is a domain user, they would potentially be automatically logged in using the Windows credentials of the current login session. In the attack, our scenario involves an attacker who has already extracted the victim user's password hash (but not the actual password) and will use it for login. The attacker is logged into Windows with credentials which do not allow them access to the website in question. However, the attacker passes the hash to the current Windows session in order to impersonate the victim user. The attacker then browses to the website using Internet Explorer and is able to automatically authenticate without ever needing the password itself - only the hash. This attack can take place from any computer which is able to access the website. If the website is only accessible internally, as many such NTLM pages are, then the attacker would need to have access to a computer located on the LAN. However, if the website is accessible from the Internet, the attacker could perform the pass-the-hash attack from a remote location outside the network, depending on the individual circumstances. Below are the details on the attack.

TL;DR:
Use wce

Prerequisites:
Extracted hash (extraction process not covered in this post)
Windows computer to perform the attack from
Target website which uses NTLM authentication
Connectivity to the website
wce (Windows Credentials Editor)

wce download link:
https://dl.packetstormsecurity.net/Win/wce_v1_4beta_universal.zip (expect browser/AV blocking)

Tested on:
Windows 7, 64 bit
Internet Explorer 11, 64 bit
wce v1.4beta x64 (Windows Credentials Editor)

Steps:
1. Log onto the Windows computer which will be used for the attack
2. Configure Internet Options:
     a. Security>Custom level for the zone>Automatic logon only in intranet zone
     b. Add website to Local Intranet sites
3. Run wce, give it the hash and tell it to call IE: wce -s <UserName>:<DomainName>:<LMHash>:<NTHash> -c "C:\Program Files\Internet Explorer\iexplore.exe"
4. Browse to the website for the automatic login

As you can see, the attack is very simple. Here are the wce command line switches in use:

-s Changes NTLM credentials of current logon session. Parameters: <UserName>:<DomainName>:<LMHash>:<NTHash>.
-c Run <cmd> in a new session with the specified NTLM credentials.

Hmm...Maybe it's time to re-think that Sharepoint NTLM authentication.

Cracking Microsoft Office File Passwords

The best way to crack the password on a Microsoft Office file is by first extracting the hash of the actual password itself. But how to do that? The script office2john.py is really useful for this. It extracts the password hash and converts it to a format that John the Ripper can handle. This is not a tutorial on John, so you'll have to hit up google for that. But I'll give you the basic commands to get the job done. This should work on files from pretty much any version of Office, including xls and xlsx, etc. (Office 2003-2013).

First, you'll need to download office2john.py. You can get it from github here. Or, you can download a copy I put here.

Depending on your cracking strategy, you will likely also need a dictionary file for the attack. I will be using a dummy dictionary file as PoC, but there are lots out there and I won't go into that as a part of this post.

You'll of course also need John installed (google it) and will need a target Office file. I'm doing this from Kali 2.0 on an Excel 2013 test file which I encrypted with a password from Excel. Here are the files/names I used:

dictionary.lst (dictionary file)
office2john.py (extracts hash)
test-crack.xlsx (target)

Okay, here we go. First, we extract the hash:

./office2john.py test-crack.xlsx > test-crack-hash.txt

(click to zoom)

The hash has now been outputted to test-crack-hash.txt and we can begin cracking. The method I used was a dictionary attack:

john --session=xlsx --rules --wordlist=dictionary.lst test-crack-hash.txt

Here is an explanation of the command line options used:

--session=
An optional identifier for you to manage the John session, in case you have multiple sessions. You can make the string after the equals sign be whatever you want.

--rules
Enables wordlist rules

--wordlist=
The dictionary file to use for the attack.

[filename]
The last parameter is the text file containing the extracted hash.

It should show the password when it completes, if your cracking was successful. You can also run the following to show the cracked password, after it completes: john --show test-crack-hash.txt

Now you should be able to open the Office file using the password you cracked. It goes without saying, that this should only be used for ethical purposes, so don't do evil stuff!

Ciao!

Installing Kali via YUMI

I like to use YUMI to maintain a USB thumb drive with various live operating systems and installers, including Kali. I generally prefer this over the dd image method. From time to time, I run into trouble with operating systems which aren't immediately compatible, but can often find a resolution. This was the case with Kali 2.0. I could boot into the installer, but the installer itself would fail to detect the installation media. This caused the installer to fail completely. Here are the screenshots - you can click to zoom.

Here's the fix I came up with. I went back to the menu and chose Execute a Shell. Using the shell, I deleted /cdrom and created a new symlink to /cdrom from the appropriate directory of the installation media. (Fyi, in this particular chassis, I don't have a CD-ROM drive at all.)

This tricked the installer into thinking the files on the USB thumb drive were located on an installer CD. The issue was immediately resolved and the installer was able to proceed past the point it was stuck at.

Hope this little hack helps someone out!

Ciao!

Kali Broken - "Cleaning up temporary files"

I broke my Kali Linux. I was going wild with Burp Suite while forgetting I was low on disk space. Once I noticed the disk was full, it was too late. The system was too crashy to even use and I had to do a hard boot. Of course, once I did a hard boot it wouldn't come back up. The booting process would get stuck at "Cleaning up temporary files" and then eventually die at a blank screen. :(

I've documented the steps I used to fix it, minus a few wrong turns I took. :) Hope this helps someone:

1. Download Kali Linux in order to boot it live for the repair
2. Create bootable media from the ISO (I like YUMI)
3. Boot the live Kali to the GUI
4. Run the command df from Terminal and leave the results up for now
5. Open Thunar, right click the HDD with the broken Kali install and choose mount
6. Type the encryption password (this gave me an error which I just ignored)
7. Right click the LVM and start the multidisk
8. Wait a moment and then right click again and mount it. Unfortunately, this mounts it read only. No worries...
9. Run df again in order to determine what was mounted and where. Compare the 2 df outputs.
10. Now unmount it with: sudo umount /media/the-place-it-is-mounted
11. Create a new directory for mounting: sudo mkdir /media/hdd
12. Mount it as read/write: sudo mount -o rw /the/path /media/hdd (Replace /the/path with the partition you are trying to mount. You can determine this by comparing the results from the 2 times you ran df.)
13. Use chroot to make the mounted filesystem be treated sorta like you booted into it directly: chroot /media/hdd
14. Delete whatever you can to free up space
15. Clean up the tmp files: rm -r /tmp/*
16. Exit chroot: exit
17. Close Terminal
18. Go back to Thunar, unmount and stop the multidisk.
19. Reboot into the repaired Kali install!

Remember, always keep good backups!!

EDIT: @blackMOREOps just reminded me of something...Don't forget to clean the Trash folder! I did this and forgot to document. Thanks @blackMOREOps!



Repaired OS: Kali Linux 1.0.6, 32 bit
Live OS: Kali Linux 1.1.0a, 32 bit

A Prophesy

I hereby prophesy that on July 8, 2015 Troy Hunt (@troyhunt) will tweet about a weird blog where a guy claims to have prophesied about the Hacking Team compromise. Troy's tweet will look something like this:

I will even predict the URL of his tweet:

https://twitter.com/troyhunt/status/618909553892003840

You're welcome!

Make a Phablet With Free Out/Inbound VoIP Calls

I think we need one last Google Voice hack before Google potentially messes it up by moving it to Hangouts, don't ya think? Okay, how about turning your tablet into a phablet using Google Voice and Talkatone and having free calls in and out? What's a phablet? A hybrid between a tablet and a phone, of course! I just made my Android tablet a phablet by doing these simple steps:

1. Install the Google Voice app on the tablet
2. Install the Talkatone app on the tablet
3. Go to a web browser and add the Talkatone phone number to the Google Voice account

So where does the hacking come in? It's like this: Talktone only let's you receive calls for free, but not dial calls for free. Once your introductory free minutes are gone, you've gotta pay up in order to dial out. Unless you're me or you, that is! You see, we are going to call out by making the Google Voice app call IN to your Talkatone app. Wait, you mean one app will call the other app, all on the same device??? Yup!!!

When you need to dial out, just go to the Google Voice app and dial your friend's number but choose your Talkatone phone number in the dropdown menu. The next thing that will happen is that your Talkatone app will ring. Once you pick it up, it will start ringing your friend's number. Just like my previous Google Voice hack, we are basically dialing out by dialing in! Enjoy free unlimited outbound/inbound VoIP on your phantabulet!!!

Test HDD using smartctl and automate status

I quite often test hard drives using various vendor specific live environments like SeaTools, etc. But what if you want to use a (live) Linux distro? This is quite doable with smartctl which is a part of smartmontools.

Below are steps to do this, complete with a cool way to automate the status of the test appearing on the screen. Without automating the status, you will not receive any stdout notification unless you run a command manually. Remember, on some distros you will need to use sudo. Also, you will need to have smartmontools installed. If you don't know how to install it, there is plenty of info on Google on that. Keep in mind, some drives don't support SMART, which is lame.

1. Start with looking at your disks to get the filename of the disk as it appears in /dev.

fdisk -l

2. Once you've determined the disk you need to check, you can do a basic health status check. This is not authoritative but gives you a basic idea. Be sure to replace [sda] with your disk.

smartctl /dev/[sda] -H


3. If you want to geek out on every last detail of the status/health of your disk which is currently available you can do that, too.

smartctl /dev/[sda] -a


4. Okay, now it's time to start a test. You can run a short test or a long test, etc. but I always like to run a long test because it's more thorough.

smartctl /dev/[sda] --test=long


5. Smartctl has one downside. It doesn't show you a status of the test running in the background unless you run smartctl -a and find the result within that information. To make things easier, I've provided a way to automate the status of the test so that it scrolls down the screen showing the percent complete. It will also display "...completed" when it is finished.

watch -n 1 smartctl /dev/[sda] -a | grep 'execution\|remaining'

(Note the backslash followed by a pipe for OR.)


6. When the test is complete, you will still need to manually check the result of the test to see if there were errors.

smartctl /dev/[sda] -a

7. Near the bottom of the output will be a section that begins with: "SMART Self-test log structure revision number..." Right below that, you will see the result of recent tests with the most recent (yours) listed first. The status will be shown, including the LBA of the first error, if there are any.

8. Here are a couple of other useful commands...

Help (useful in live Linux distros that do not contain man pages): smartctl -h

Abort a test that is currently running: smartctl /dev/[sda] -X


Enjoy!

If this helped you, consider leaving a comment and saying hello!



Tested on...
smartctl: 6.0 2012-10-10 r3643
OS: AVG 2013-08-01 from live USB drive