 Okay, well thanks for coming to our talk, stamp out hash corruption, crack all the things. I'm Ryan Reynolds, I work for Crow, Horwath, I'm a pen tester. I do all types of pen testing, web app pens, internal, external, wireless. Social engineering, physical security assessments, I break stuff. How do I make this work? Oh, if I come from the side it works. My name is Jonathan Claudius, I'm a security researcher at Trussway's spider labs. I spend most of my time focusing on like vulnerability research, exploits, things like that. And I also dabble in coding. I'm kind of a scripter, automator, that kind of thing. And when I originally, we got accepted for this talk, one of my coworkers sent me an email like shortly after, after he found out the guy that I was presenting with. And I don't know if you can see this, but it says, you're doing a presentation with Ryan Reynolds. My girlfriend is so jealous. Get that a lot. Okay, so today we're going to talk about the different ways to extract password hashes from Windows systems. We're going to look at local accounts only, we're not going to work on DCs. So we're going to talk about the different tools that can do it, the different methods that those tools can use. A big bug that we found in tools that will result in extracting the wrong hash, essentially, so you can never crack it. We found a way to fix that bug. We'll talk about how that bug kind of proliferated. And then we'll do a demo for you. And instead of just complaining about something, we fixed some of the tools and we'll release some patches. So, okay, we're going to just kind of level set here for everyone in the room. So we're all on the same page before we start diving in. But in regards to the hashes that are on Windows systems, we have a couple of different types, LM being the land manager of the old type. This had tons of security flaws. One of them was that you couldn't have a password longer than 14 characters. Another thing is that it would uppercase your password. So if you had ponies one with a capital P and then the rest was lowercase, it would uppercase everything. And then it would take that password and it would split it into two seven-character bite chunks. So if you had an 11-character password, you would have a hash that was the first seven characters and then a hash that was four and then padded with three extra nulls. So now, instead of cracking all the possible combinations of 11 characters, I only have to worry about trying to crack a seven-character password and then a four-character password. So really easy to kind of brute force through. So Microsoft said, all right, we need to beef up security a little here, so we'll create NTLM. And this lets you have a password of 128 characters, so they increase the length dramatically. They also said, you know what, we should probably keep the case. So now, whatever you type in is how your password has hashed with the case. The issue with both of these, though, is that they're not salted. So if a user account, let's say user A has a password of test and user B has a password of test, that hash will be the same on that system, so which therefore leads to a rainbow table of attacks or pre-computed dictionary attacks. So now, we can create all the possible combinations and since they're never salted, we can just do a time memory trade-off and crack those passwords really fast. So essentially, if you get an LM hash, you're pretty much guaranteed to crack it because people have generated the entire character set of rainbow tables for LM. So LM hash means we can always crack it. NTLM, people are still working on it. It's a huge length, so they're not all created. Okay, so now that we talked about the different types of hashes, we've got to talk about how do we get those? And there's two real main methods out there. The first is to inject into LSAS, the local security authority subsystem. This is a process running in memory that is highly elevated with privileges. It has debug rights, so pretty much the highest rates you can get. And what you can do is you can upload a DLL into that address space and therefore inherit those permissions and then directly access the hashes. So tools like PWDump6 do this, FGDump2.01, you know, and some other PWDump versions. The other method is to read the hashes out of the SAM and system registry hives. And tools that do this are Metasploits hash dump script, SAM dump 2 and a few others that we'll talk about. And what this is doing, it's going into the SAM hive, parsing out the hash data, feeding that to some crypto algorithms, and then that's what creates what we all know as LM and NTLM hashes. So there's a couple benefits and disadvantages to these ways. One, for injecting into memory, we have to load a DLL into that. So the issue there is, well, if I'm on a box and I only have access to one box, if I'm messing around with memory, I have a chance of possibly screwing something up and then blue screening that system and I lose access to that box. And that's never good. The other issue with LSAS is that I have to use a third-party tool and I have to be on that system to do it. So I have to use a tool like PWDump that'll do that and AV will catch that most of the time. So you have to fight the fight with AV. Nice thing about registry reading is if I'm an admin, I'm just accessing the registry, just reading it. And that's just normal admin thing to do. And so AV isn't going to stop that. They're going to say, oh, yeah, cool, you're accessing the SAM hive, whatever. You're supposed to, you're an admin. You're just reading. You're not modifying anything. So it's a nice benefit to just be able to copy these hive files off, which is what you can do. And then you can extract the hashes on a different system as well. You don't necessarily need to be logged in as that user or have that system on and running, which is great. So the other nice thing about registry reading is you can do this with, you can save those hive files with just built-in Windows commands and WMIC queries. So that's pretty cool. OK, story time. So how did we get here and what are we even really talking about? Well, all right. A while ago, I was doing a social engineering engagement where the client said, hey, can you break into our corporate location by just doing physical social engineering? He said, all right, sure. So Friday afternoon, I show up and I checked the perimeter, building's locked down, so I'm forced to go through the front doors, go through the front doors, receptionist is there, says, who are you, what are you doing? I say, I'm meeting Joe Schmoe for a reason X, Y, and Z. And she's like, OK, I'm going to verify, sit in the lobby. And at this point, I'm thinking I'm dead, right? But the classic standby of, hey, can I use the bathroom while you're verifying? That worked. She's like, yep, go around the corner. It's around the corner. I'll see you in a few minutes. I'm like, all right, walk around the corner. There's a staircase there. Go up to the second floor. Walk into an office that's empty. Shut the door. Close the blinds. And boom, I'm in. Workstation is in this place. So I'm like, all right, I'm going to backtrack this box. And I'm going to copy off the SAM system and security hives. Get those, plug in USB, copy it to USB. Check to see if I can get network access and if there's any written down passwords or anything. And then I'm like, all right, I've proved it. So now I'm going to leave, walk downstairs, walk out the back. They never knew I was there. Cool, so I'm in the car. And this Friday afternoon, I'm like, all right, got my meeting with the client Monday. I need to tell them that I can crack their password, right, that's going to hit home with that a little. Open up Cane Enable. Extract the hashes from the SAM and system hives. And I notice that I have an LM hash and an NTLM hash. They're like, awesome. As we know, LM, I should be able to crack it, right? Run it through John the Ripper with some dictionary table or dictionary files. Couldn't crack, so I'm like, all right, I'm going to beef it up to LM, Rambo Tables. Don't get anything back. Really weird. So I'm like, all right, I know what they're doing. This IT admin is super tricky. He is probably storing, or he's probably inserting one of those French characters into his passwords, you know where you hold down all and you hit 156 and it's like an accented E? I'm like, this guy's messing with me. I'm like, all right, so I call up my ISP and I'm like, hey, AT&T, bump up my downstream to the highest possible value. I don't care what it costs, just do it. Because I am determined to get this guy's password. So I go to freeRamboTables.com and I download the 400 gigs over the weekend of the French Rambo Tables and I run the hash through that. And I cry because I don't crack it. I'm like, okay, great, what is going on? So I chalk it up to the fact that, all right, I must have, maybe I didn't like safely eject the USB key or something. It didn't copyright or the hives are, you know, messed up or corrupted, I don't know. But I had a sad face. Fast forward to my next pen test. I'm on a system, we're on the network for a week where they say, hey, go at it and try to get into everything you can. So I pop a shell in a system missing a patch, got my interpreter, and I'm like, I'm going to dump the hashes and I'm going to use the hash dump script which extracts those hashes through registry reading methods. Notice that I have an LM and NTLM again. So I'm like, cool. Try to crack the LM again, can't do it. So I'm like, all right, since I'm still on this system and on the network, I'm going to take that NTLM hash and I'm going to try and pass it back to the original system I extracted it from, right? Because if I got that hash from system A, I should be able to authenticate the system A with it. Doesn't work either. So at this point, I'm like, all right, great. I'm on the system and I'm thinking to myself, it's got to be the tools I'm using. Like, I don't understand why this isn't working. So I figure I'm going to fight the good fight with AV, kill AV, and I'm going to use my old standby, PW dump six, and inject into memory and see what happens. Turns out I get completely different hashes. So as you can see with the registry reading method with Metasploit, I get an LM hash with injection, PW dump six, that LM hash that's AAD3B4, whatever. That is just a blank hash. That's just representing a blank where it means no hash is there. So at this point, I'm like, okay, injection gets me one set of hashes from the same system, and registry reading gets me a completely different set. And I can use the hashes from injection though. So I know those are the right ones. So I call up some of my coworkers and I'm like, hey, I've been running into this on Pentes. Have you guys been seeing this? And they're like, yeah, I only can use tools like FG dump or PW dump that use injection to get the hashes. Like, I don't know what's up with registry reading. I'm like, all right. So maybe it's not just me. But what did the Google say I wanted to know? Turns out there's a Metasploit bug where pretty much the same situation happened. A gentleman says, hey, I have a Windows 2008 server and I make a password that's longer than 14 characters which inherently means I don't generate an LM hash. And he says, I run that run hash script, the hash dump script, and the hashes are incorrect. They never crack. So at this point, I'm like, all right, few. I'm not crazy. It's not just me. There's something weird going on. We can probably figure something out here. So, John and I have known each other for several years. We occasionally meet up for beers and we swap war stories about pen testing and what's going on in the security field. And I was telling them, I'm like, man, I cannot crack these hashes. And John knows that that shit keeps me up at night. Ryan loves hashes. So, I'm telling them, yeah, these are the different ways you can extract hashes and some of the tools that we can use and I'm like, you know, Metasploits open. We might be able to look at that and John is really good with Ruby. He's like, yeah, that'd be a cool project. Let's just work on that and see what we can find out. I'm like, all right, we're going to try and solve this problem. Cool. But we pretty much said, well, we know the tools to use and stuff but we need to reverse engineer this whole process over again because it's not working. So we had to start from scratch and we had to say, all right, where did the hashes live? So, all right. Hashes are stored in the SAM registry hive. Now, they're not just stored straight up there, obviously. You have to parse them out. You have to do mathematical algorithms and everything but we knew that we needed to play around in the SAM hive. In order to play around in the SAM hive though, we needed the sys key from the system hive. This is pretty much just an extra layer of encryption Microsoft said to throw off the bad guys from just accessing the SAM data directly. So, in order to get to the SAM data in a form that we can use, we need the sys key. Okay, cool. So now we know that. Awesome. So we just literally opened up RegEdit and browsed into the SAM and said, okay, what do we have here? Yeah, we're really scientific. So the user's accounts are like 0, 0, 0, 1F4, 1F5, etc. But it turned out they each had a key, an F key and a V key. And we're like, all right, well, what does that mean? I don't even know. Turns out the F key handles a lot of the policy information. So does the user's password expire? Do they have any log on hour restrictions? When did they last log on? Stuff like that. The V key though handled all of the goodies that we wanted. So the username and then the LM hash data and NT hash data. So this was the data that I said we want to parse out past the algorithms to get our hashes. So we're like, all right, cool. And to kind of walk through the rest of this presentation, we made kind of like a pseudo diagram here where we said, all right, instead of putting up tons of hacks and binary, we'll just have this represent all that. And so we can see that this first user up here has an LM hash which is represented by AAAAA and then an NTLM hash which is represented by BBBB. All right, the second user down here though only has an LM hash or NTLM hash, sorry. So this is kind of just what we're going to use to reference this as we talk about how we're parsing out this data. Okay, so then we said, all right, cool. We know where the data is and we know kind of where we need to play but we don't know necessarily how to do it. So we said, what tools actually extract hashes by reading the registry hives? And we came up with this list and we kind of sat back and we were like, wow, these are some pretty big name tools. You know, you got Cain and Navel there, you got the new FG dump, Metasploit, CredDump, SimDump, we're like, all right, this is a pretty big list. What we'll do is we'll start with Metasploit because Ruby's not too hard to understand and we'll go from there. But we wanted to see kind of what other tools did this and we'll kind of get back to that a little later. But we said, all right, turns out we have this Vkey which has all of our data that we wanna play with and we need to read into a certain part on this, into this key which is the offset. So we're just reading in until we hit that hash data. Then at the hash, once we get to the hash data, we said, all right, we need to figure out how to parse this. And the way that these tools did this was they said, I'm gonna measure the length of hash data. And they said, if the length of hash data is over 40 bytes, then I'm gonna assume that I have an LM and an NTLM hash. Because each hash is 16 bytes and then there's a four byte header for them. So 40, we got it, cool. If I'm over 40, I probably got both hashes. Otherwise, if I am only over 20, I've got just an NTLM and therefore I will parse that hash data completely differently or I don't have any hashes. So the main takeaway here is to say, hey, the way I'm gonna decide to parse out these hashes is by measuring the length of hash data, which inherently leads us to the flaw. Hi. So the flaw is really kind of what Ryan experienced when he was doing his penetration testing. He pulled it via one tool, gets one hash, pulls it via a different tool, gets a different set of hashes. So let's take a look at that again. If you guys remember this from earlier in Ryan's slides, we wanna figure out why we're getting bad LM and NTLM hashes with Metasploit in this particular example. So let's take a look back and let's take a look at this logic one more time. Like Ryan said, we focused on Metasploit. So that was our primary goal, debugging, trying to figure out what was going on. And we did have some samples that we were able to get that actually yielded these corrupted hashes. So using these examples, what we found is that as we were debugging through things, every system or every user that was getting corrupted hashes because there were some that were corrupt and some that weren't, had this little bit of data at the end of their binary stream. So like Ryan said that with the way that we calculate or determine whether they're gonna parse certain types of hash data is if it's greater than 40 bytes, we're gonna do the LM and NTLM. But with the additional data on the end, that actually influences this logic. So much so that we actually invalidate the bottom two options. So what this means for us is that if we're a tool and we're parsing this registry data and we're using this algorithm to figure out how to get this LM and NTLM hash data, we're really only gonna be able to extract LM and NTLM at the same time. And what that means for cases where we don't have LM storage, we're gonna parse that binary data stream as if it's got LM and NTLM regardless. And if you remember in this example, these are offset. So if we're gonna parse things the same, we're gonna have problems. So what happens is that when we look to the end of this data stream, we consider hash data and data plus plus is the same entity because this code is not intelligent to what these are. It doesn't know how to understand these data structures. So when we use this measuring stick approach, we can end up in this case where we've got bad logic. And like this goes back to the same example that Ryan showed before, the top binary stream is when we have the LM and the NTLM hashes. And when we use this logic, we parse them correctly. But like I said, if we're only allowed to parse this LM and NTLM, what we're gonna do is we're gonna parse this data like this. And what that means is that it's basically we're gonna end up in a calculator scenario. We're gonna be parsing bad data in and getting bad data out. So you can see in the first example where we parse for LM, we're gonna be grabbing like partial of the NTLM space for the LM. And then for the NTLM, we're gonna be parsing just binary blob data that's after the hash data. So this is really problematic. One of the things that, at least the examples that we've tossed around is that if you think about it like this, if you think about if I have a Word document and I have an Excel file and I do MD5 sums of both those files and I hand you those MD5 sums, but I don't give you the files and I ask you what did this come from? Tell me which file it was. Was that the doc or was that the Excel file? This is the same problem that we have because this data is not actually the NTLM hash. It's the hash data that's used that's passed through cryptographic algorithms that actually creates the eventual hash. So if we parse this in the wrong spot, what ends up is we actually get hashes that look and feel like hashes that we can go put into John, the Ripper, or any of these other cracking tools and we'll crack for days. You won't crack a thing because the hash that comes out of this is not the actual representative hash for that user. So once we figured this out, we wanted to figure out what the heck data++ was. It was something that we didn't really work on until the very end because we're trying to figure out how to parse it correctly. But one of the things that we found is that when we enabled password histories on Windows systems, the additional data++ at the end, it would grow every time a password reset would occur. So we can only assume that that is the historical passwords for that particular user. So when password histories enabled, Windows needs a way of being able to keep track of what hashes you've used previously so that when you try and use that same password that you used last time, it has a way to compare against what you've put in. And if those things compare, you can't use the same password. So really the only two things that you need to do in order to cause hash corruption for any particular users or a set of users on a system is to set password history enabled and not have an LM hash for that user, which is oddly enough a really common thing. In enterprise today, that's a Microsoft best practice which I think is kind of funny. It's kind of like that. But it's something that I think if you're in enterprise, it's something that you do. I mean, it's what your auditors tell you to do. And it's something that I think Ryan saw in a lot of his assessments. So we thought that was kind of interesting. Up till now, we've kind of shielded you from the real data in the registry. This is what it really looks like. This is just like a reg read, a reg query against a given user that's affected. What you'll see here, and I don't expect you all to be able to recite all the hex characters unless you've got some crazy vision. But what you can see here is that there's an LM hash in yellow, the first one. And then there's an NT hash in the second set. And those are the things that we really want to parse out. But like we talked about with the logic and the way this is influenced, if we're using size, like this measuring stick approach is a way to determine how to parse this data. You can see here that the additional data plus plus shown in green is obviously greater than 40 bytes. So in the cases that we found where there's actually data at the end, it's a lot of data. And it's always gonna screw up the logic and you're always gonna get corrupted hashes. So that was kind of cool. So one of the things that we really wanted to figure out because we were like, oh, this is pretty cool. How often does this really occur? And we got this question from a couple of our friends and we're like, hey, we found this really cool thing. And one of the things that we found is it's really hard. Like I said, with the example with the Word doc and Excel doc, how do I go and look at hashes and say, hmm, kind of feels good, kind of feels bad? Like, you don't know. I mean, if it doesn't crack it could just be really strong or maybe there's some like flaw in our cracking tools. So one of the things that we can draw conclusions from because we really can't say how definitively how popular this is. But we do know that like in Windows Vista and later, Elam hash storage is disabled by default. So of the two things that we have to have to be true in order for this hash to corruption to occur, one of them is a default. So I really only have one thing that I need to come to be enabled, which is histories in order for this corruption to occur. Which I think is pretty cool. I mean, it makes it a lot more prevalent from the standpoint of an enterprise. In my non-scientific approach, I've seen this on every pen test for the past year and a half. So. Yep. And the other thing too is that a lot of people are pushing out big GPO policies, their history requirements. And although this doesn't specifically affect the main controllers, it affects every other system in your enterprise. So any member server, any workstation, any Windows system from current to 2000. So in an ideal world, what we would really like to be able to do is tell whether or not these hashes are there every time. One, a reliable way of being able to say, it's here or it's not here. We don't want to have to play this measuring stick approach game because it can really lead to problems like we've described so far. And we really want to get that hash every time because we got folks like Ryan over here that are huge hash nuts and they really want to crack those hashes. So we wanted to fix that problem. So one of the things that we found, we did a little bit of research. I think this is a forensics blog we found this on, Far Cry from any kind of pentesting blog. But these guys had basically said, well, hey, there's some data in the V-key that allows you to determine whether or not these hashes are present or not. So those are headers there. Those are shown in blue up there. And I know you can't see the value, but really there's only two values that you can expect in those fields. You can get a four or you can get a 14. And what that means is if we have a four, the hash is in present. If we get a 14, the hash is present. Like Ryan said, the way that this hash structure is set up is that you've got a four byte preamble, four byte header, and you got a 16 byte block. And that actually maps up to this. We've got four bytes or 20 bytes when we translate that from a hex to decimal. So really we have a clear map whether or not the hash is present or not. We can clearly say it's there or it's not. And we can use that to make our parsing decisions correctly every time. So we don't have to guess, which is awesome. So when we go back and we look at the logic that we've described, and this diagram's become awful boring now, right? If it's there, parse it. If it's not, don't. And it makes our lives a lot easier. And in our testing, it's made our hash extraction 100% reliable in all the tests we've done. So that's kind of cool. So when we look at this compared against our examples here, these are the same examples we've looked at a couple times already. We've got a case where we've got an LM, an NTLM, and a case where we've just got an NT. With the bad logic, we're gonna parse it like this. And we're gonna end up grabbing in that garbage data. We're gonna end up with bad hashes on the outset. And with the good logic, we're gonna parse the first scenario correct, and we're gonna parse the second scenario correct. So we're always gonna get that data correctly. We're always gonna be able to turn those hashes into the right LM or NTLM passwords. And if we can't crack them, we'll be able to pass them successfully. So, Ryan and I learned a lot from playing with the Metasploit code and kind of peeling back all the layers and learning about how this process works. That was our goal, was really to fix the problem that we saw in Metasploit. But as Ryan mentioned, there's a bunch of other tools that do this. And we wanted to figure out where did this come from? Where did this decision-making process come from, this logic that allowed us to determine how we're gonna parse our hashes? And what we did is we looked at a number of change logs, blog posts, attributions, Twitter messages, I think in some cases, to figure out how were these tools influenced by the tools that came before them? So we put together a relational diagram that shows how these tools were influenced. So you can see Metasploit was influenced by CredDump, by SamDump, and all the way back to the first version of PWDump. So we looked at the source code and the source code's right, it's clear as day. We use this size. We say, oh, is it this big? Is it this big? Is it this big? And then we extract accordingly. We thought this was kind of a cool way. I've never actually seen this data represented this way. I think all of us have our own special tools that we use that kind of our back pocket. I use this one, I use this one, but there's a lot of tools, but they all kind of came from original source, which I thought was pretty cool. So when we look at this from a timeline perspective, like we saw the relationship. I wanna quickly go through just kind of where we started. So like this actually reaches all the way back to 1997. PWDump version one was released then. And then in 2004, there's actually quite a few tools that were introduced between that time frame. But then SamDump was released in 2004. We had Cain and Abel started doing this method in 2005. And then in 2007, there was something really cool that happened. And what it was was that SamDump, too, realized that they were getting incorrect hashes. You go right to their change log and they say, like, there's a problem here. I fixed the hash offset stuff. 2007. Well, three months later, CredDump was created. CredDump was one of the first tools to do this in scripting language. Scripting languages are a lot more accessible for people, including myself and Ryan. That's the reason why we focused on a scripting language to start with. The problem was, or like the big gotcha was, is that when he was basing his research or he's trying to figure out how to do this, he used SamDump as a guide. But he used the wrong version. He didn't use the fixed version. He used the version that had the old logic and that was carried forward into his tool. So although the tool was fixed in 2007, this code was re-implemented in another tool in 2008. And because this tool was so accessible because it was in a scripting language that a lot of people could understand, it was used as a source for other tool writers to write their tools. So we see explosion of tools. After that, Metasploit being one, PWDump seven, and even tools that are currently in development now that are implementing this code that skipped a couple generations. I think I was told just before this talk that it was fixed in an earlier version than SamDump and then was re-implemented again. So it's just kind of this issue that keeps plaguing us and what Ryan and I wanted to do is we really wanted to stamp it out. We didn't want to deal with this anymore and there's cases where certain tools are more applicable than others and we really didn't want people getting these bad hashes because it can result in cases where you're getting the wrong sense of security for a given system. It can have a completely trivial password but that corrupted hash, you won't be able to crack it. So the takeaways that I think for Ryan and I going through this process was that, reversing is kind of hard. Like we were not experts in going through all this binary data and it's clear to us that going through the exhaustive test cases and making sure that every scenario works is really, is exhausting. And the other thing was is that leveraging code is, it's really helpful but it can come sometimes at a cost because the assumptions that were made when that tool was written may not necessarily be true today and that was one of the reasons that caused this problem because in 97 there was no such thing as password histories but shortly after that was implemented. And then the last thing is open source is awesome and that it was allowed us to be able to go from zero knowledge about how this process worked to all the intricate bits. We figured out how it was broken by debugging the code and were able to fix the Metasploit code. So that was pretty cool. We do have a demonstration prepared for you guys today. It's gonna be on a Windows 8 machine. While I'm doing this, can I get a raise of hands of people who've actually seen Windows 8? Quite a few. All right. All right, well it looks like this. It's kind of like a mobile phone type thing. At least it feels like a mobile phone. And I wanna make a key distinction before we get started. I think I may have already mentioned this but Windows 8 is not that strategically different than any other previous Windows version all the way down to like 2000. Everything's still used, the Syskey process. We're all still, all the data underneath is still the same. We just thought it would be cool to show this demo in Windows 8 because, well first of all I had never installed it before so it seemed like a good thing to demo at Defcon. So what we're gonna do here is we're gonna, we've got a meta interpreter session on the system. We exploited it somehow, right? And what we're gonna do is we're gonna dump hashes on it. We're gonna extract hashes the same way that Ryan did on his internal penetration test. So we're gonna dump hashes and what we're gonna see here is that there's two users here that we really care about. There's the user Frank and there's a user test. Frank and test are using the exact same password. And what we'll see here is that the Frank user, his password starts with 5F1, okay? And the test user, 5F1 as well. So we know that using our kind of senses what Ryan talked about was salting because there's no salting, there's no specific stuff. The same password translates to the same hash that these users are using the exact same password. So if we go and we monkey with the password histories and we enable them on the system and again, this is a vanilla 2000 or Windows 8 box. We can, I don't know how visible that's gonna be. Can you guys see that? Good. So we're gonna put it to 10 histories. We're gonna make sure that they have to use a different password 10 times in a row before they can use the same password again. But one of the key things here is that when you make this registry modification you actually need to change the password of the user before the data structure will change. That's a key distinction. So what we're gonna do just to make things easier, we're gonna change it to an arbitrary password and then we're gonna change it back to the original password that we had from the beginning and we'll kind of show what happens there. So here we are setting a temporary password test. We're gonna set this to a really easy password that only Ryan and I know. Really secure. Yep, super secure. And what we're gonna see here is we're gonna go back and we're gonna extract these hashes one more time. Same tools, same everything. And we do get different hashes for the same password which is a little bit weird. So 5F1 and then we get this 072 thing, right? Which also had that user now has an LM hash. Yeah, both of these hashes are complete garbage. They are corrupted, you will never crack them. If you do crack them, I'll be very surprised. You probably found some weird collision and the corruption. Why you a bear? But yeah, you'll probably won't crack them and these hashes do not represent the passwords of these users, it's complete garbage. So what we do is we're gonna run a patch version of hash dump and show how we can extract the hashes properly. And I think it's important to note here is that we didn't create a hash dump too in Metasploit, we just patched their code. So we don't have any more corrupted hashes, we made no modification to the system. But the test user is now reporting the right LM and NTLM hashes for this particular user. So that's basically the wow for us. So yeah, that's the demo. So Ryan and I are kind of always trying to push the envelope and one up in each other and one of the things that we wanted to do was we didn't want to stop at Metasploit, although that's cool and a lot of people use Metasploit, we didn't want to just stop there. So what we did do is we developed patches for the tools that we could gain source of so that we could ensure that the community doesn't have this problem anymore. So we developed patches for the CredDump tool, one of the first tools, the scripting tool that originally carried this bug forward in scripting language. We patched that and reported it to the author. We also patched Metasploit's Hashtump script. One of the funny things about Metasploit and I was super surprised with these guys, I submitted the patch, I did a pull request on GitHub like Sunday afternoon at 1 p.m. And within 45 minutes, HDMor is committing this thing into their source tree. So I was like, holy crap guys. Props to you guys. Yeah, props to HDMor's here. You know, a guy never sleeps. Or never relaxes on a Sunday, that's what I guess. But in addition to those, there are tools that we don't have source for. So we can't fix them. So what we did is we reached out to all these authors about two weeks ago and gave them the full disclosure on what we're doing here and what we're gonna be talking about today. And we received an overwhelming response from all these guys. Some of these guys haven't been developing on these tools in quite some time because as far as everyone else is concerned, this is kind of like dead stuff. Like there's not really a ton of new developments here going on. So it was awesome to see the development community for these tools be extremely responsive and they're actively working on fixes, some of which will probably be released in the next week or so. So keep an eye out for those. We're pretty excited that we were able to meet some of these guys. Some of these guys, we'd seen them like when we were hacking early on in our career, it's really cool to finally meet them. So on your DEF CON CD, there is a white paper. It goes into a ton more detail about how you actually extract these hashes out of the registry. We didn't wanna create a new tool, but we did wanna provide a blueprint for how this stuff works. So you can take a registry extracted value and peel it all the way back down to the hashes using the white paper that we described. We also have the patches from Metasploit and CredDump on the CD. So if you wanna use that, you can. We've also provided the example salmon system that has both a corrupted user and a bunch of non-corrupted users. So you can see the difference if you provide the patches or use the patches to extract the new passwords. So if you wanna follow along with us or you wanna play with those, they're there for you. Lastly, there is a contest going on here at DEF CON this week. If you haven't heard of it, it's called Crack Me If You Can. It's been put on by CoreLogic. They have a challenge in their contest that the information that we described here today will help you in solving that riddle. So hopefully for those of you in the audience that are participating, this is of assistance to you. And if you have questions for us, we'll certainly love to help you.