Ryan Linn is back with another video for your learning pleasure. This time he gives a video tutorial of an existing toolset, the Pass-The-Hash Toolkit by Core Security. Core describes it as, "The Pass-The-Hash Toolkit contains utilities to manipulate the Windows Logon Sessions mantained by the LSA (Local Security Authority) component. These tools allow you to list the current logon sessions with its corresponding NTLM credentials (e.g.: users remotely logged in thru Remote Desktop/Terminal Services), and also change in runtime the current username, domain name, and NTLM hashes (YES, PASS-THE-HASH on Windows!)."

So what does all that mean? As with his other videos, Ryan tackles this topic in a very easy to follow process. So watch along as he integrates the PTH Toolkit in a makeshift penetration test, and shows how an attacker can utilize credentials without ever having to crack a single password. Oh by the way, he cracks them, too. This way he can impersonate a legitimate user without knowing their password, and then again while knowing their password. Ryan then goes one step further with his talk at ChicagoCon 2009s on May 9 with fellow EH-Net Columnists, Brian Wilson, when they team up for Cain BeEF Hash: Snagging Passwords without Popping Boxes. They not only show you some of their cutting-edge research results, but also perform it in a live demo! Click for Conference Details.

Let us know what you think and/or what else you'd like to see from Ryan,Don

Nice one Linn, just finished watching it. Couldn't expect anything less then another excellent tool from core. Keep up the good work, I'd also like to see those demos Jhaddix mentioned when whoever has time! -Coughs- Gates -Coughs- joking...

I posted this question in a different thread but, following advice, I split the post and here's the question about which I'm confused:

There's an administrator logged on locally and don is logged onto the domain (how can this occur on the same XP SP3 PC?). I'm not sure how it's possible to do the Pass the Hash attack. I didn't hear specifically how the network was set up (I assume it was a domain in VMWare). It appears that hashes are retrieved from the local SAM (I realise that a user logged on locally has the hashes stored there, so how would that help in gaining access to the DC? As far as I understand, when the user logs onto the domain, the username and password are checked against the DC and the local SAM is of no relevance. Are don's hashes retrieved from RAM using the utilities in the toolkit?

Sorry if my misunderstanding spreads to others, but maybe it's my interpretation of what you (Ryan) said.

Let me setup a slightly different scenario that may help this make more sense.

You are at your workstation, and you are logged in via your domain account. You have a patch missing on your machine, and while I am on your network performing a pen test, I scan your machine and notice that it is vulnerable. By exploiting that vulnerability, I am able to get a session that has the privilege of SYSTEM. At this point, you are logged into your workstation with your credentials and I am logged on via SYSTEM. Because windows helps you by ensuring you don't have to enter your password each time you access a resource, I can take your domain credentials, which are stored in memory, and assign them to my session as SYSTEM using iam.exe. Once I have taken your in-memory credentials, I can present them as my own without having to know your password at all.

Once I have your credentials and can impersonate you, then I would use them to go to other machines on the network. If you were a Domain Admin for example, I could use them to perform actions on the domain controllers, or if you had access to a machine that a domain admin was logged in on, then I might move to that machine and perform the same attack again to gain the Domain Admin's credentials.

All of this happens outside the SAM, and for clarity when you log into a machine, your credentials many times are stored locally however. The cached credential feature of windows allows for disconnected use of machines, but also allows for your domain credentials to be stored locally on machines that you have logged into. These credentials can also be attacked and cracked even when you are not on the machine.

Thank you Ryan - that's crystal clear now. My confusion was about the terminology. When you mentioned logged in, I interpreted "logged into the PC" as if it were standalone and not connected to the domain (hence my mentioning SAM). I appreciate now that I (as the victim of your attack) am actually logged onto the domain via the PC on my desk. I realise that you are somewhere else on the network and compromise my system. I was unaware that my domain credentials would be stored in RAM and that Windows uses them every time that I access a resource. When you've explained it as clearly as you have, it all makes perfect sense and it would be a real pain to have an annoying username/password dialogue every time I wanted to access something!