WEBVTT 00:00.990 --> 00:02.650 All right, we're back. 00:02.770 --> 00:06.010 And this is our co-worker. 00:06.010 --> 00:14.070 So we felt that we had to give him a quick introduction because, you know, where would we be if we didn't give him this introduction? 00:14.070 --> 00:21.370 So, you know, this is a statement that Lee asked me to write, that he asked me to prepare for him before this talk. 00:21.410 --> 00:23.190 So this is the direct quote from Lee. 00:23.190 --> 00:26.770 So he says, what did you just say about me, you hecking cowboy? 00:26.770 --> 00:29.990 I'll have you know I graduated top of my class in the Hashtag University. 00:29.990 --> 00:36.990 I've been involved in numerous secret pull requests of the Hashcat code repository, and I have over 300 GPUs in my basement. 00:37.270 --> 00:44.130 I'm trained in guerrilla password cracking tactics, and I'm the top contributor to hashes.org in the entire US. 00:44.130 --> 00:46.430 You are nothing to me but just another dictionary. 00:46.450 --> 00:50.930 I'll wipe you out with the precision mask attacks like the witch I've never been seen on this earth. 00:50.930 --> 00:52.390 Mark my hecking words. 00:52.390 --> 00:53.950 You think you can get away with these pull requests? 00:53.950 --> 00:55.150 Think again, cowboy. 00:55.150 --> 01:00.770 As we speak, I am contacting my secret network of GPUs across the USA, and your IP is being traced right now. 01:00.770 --> 01:02.470 So you better prepare for the storm. 01:02.550 --> 01:06.130 The cluster that wipes off your pathetic little thing you call your password. 01:06.170 --> 01:07.350 You're cracked, kid. 01:07.350 --> 01:13.090 I can crack your password anytime, and I can use it in over 700 ways, and that's not even including my FPGA. 01:13.130 --> 01:19.110 Not only am I extensively trained in password-free combat, but I also have access to the entire arsenal of your crypto miner underground. 01:19.110 --> 01:24.750 We'll use it to the full extent to wipe your miserable password off the face of the little hacker. 01:25.010 --> 01:27.910 Please welcome the password king, Lee. 01:28.770 --> 01:31.650 Welcome to Hashes, Smothered, Covered, and Scattered. 01:31.650 --> 01:34.270 Modern password cracking as a methodology. 01:34.650 --> 01:36.370 My name is Lee Wangenheim. 01:36.370 --> 01:38.810 I'm a security consultant here at Optiv. 01:38.810 --> 01:41.610 I hack things for fun as well as for a job. 01:41.610 --> 01:46.110 If I wasn't getting paid to do this, I'd be doing it on my own anyway. 01:46.370 --> 01:56.350 I've got about five years of InfoSec experience, mostly focused on the offensive side of the house, and currently I'm helping to run the crackers that we've got here at Optiv. 01:58.110 --> 02:00.130 So why does this matter? 02:00.130 --> 02:06.910 Because it only takes one password, and as we know, people tend to use weak passwords. 02:07.270 --> 02:16.530 Some examples that we've seen on actual gigs are using default passwords for Cisco devices, Microsoft SQL Server. 02:16.530 --> 02:29.310 I've even seen iDRAC accounts using the default root and Kelvin, and everybody's familiar with the fall 2019, or I guess now it would be summer 2020. 02:30.250 --> 02:35.930 This is a real issue, and we run into it more often than not. 02:35.930 --> 02:41.950 Once we've got one foothold into your network, we can use that to move laterally as much as we want. 02:42.930 --> 02:45.070 Some of the hardware that we're using. 02:45.790 --> 02:48.450 So we used to use CPUs and Rainbow Tables. 02:49.130 --> 02:53.330 CPUs, not really working, not really worth it anymore. 02:53.630 --> 02:58.790 They've kind of been overpassed now that the modern GPU rigs are out there. 02:58.790 --> 03:05.350 We used to use a lot of Rainbow Tables to look up, especially in NTLM and more common hash types. 03:05.350 --> 03:10.830 However, those have been kind of supplanted by the new GPU cracking machines. 03:10.830 --> 03:22.730 The reason behind that is it's actually faster to use a GPU to crack the hashes via brute force attack than it is to try and do a Rainbow Table lookup. 03:22.730 --> 03:34.010 Because again, you're burning CPU cycles doing Rainbow Table lookups versus GPU cycles with the new modern GPU setups. 03:34.290 --> 03:41.890 We do sometimes use cloud using the AWS boxes, the new GPU boxes. 03:42.310 --> 03:43.790 Those are pretty handy. 03:43.790 --> 03:45.010 They are expensive. 03:45.010 --> 03:54.790 However, if you do need to throw a lot of power at a hash or a series of hashes, it can be beneficial to go ahead and do that. 03:55.350 --> 04:05.170 Sometimes if we're on site and clients don't want their hashes leaving, or if we're on a Wi-Fi gig or something like that, we will use a laptop. 04:05.250 --> 04:10.830 Typically, a gaming laptop will do better, but you use what you have, right? 04:12.070 --> 04:28.660 If you do happen to still be running a mining rig in 2020, you know, for some of the GPU mining rig, GPU crypto algorithms such as Ethereum, you can use those. 04:29.160 --> 04:33.060 And, you know, you can always make a little bit of your money back. 04:33.060 --> 04:40.940 I don't do any more mining, so I don't know exactly how useful that is in today's world. 04:44.090 --> 05:00.590 So talking about AWS, some of the engagements that we do run here at Optiv are more of an enterprise security assessment, which is where we'll have a company provide every hash throughout their Windows domain. 05:00.630 --> 05:09.670 And then we will throw as many resources as we can over a certain amount of time, usually about two weeks of just letting the crackers run. 05:10.190 --> 05:14.010 And we'll try and crack as many of their passwords as we possibly can. 05:14.270 --> 05:27.010 That kind of engagement is sort of where this methodology really was born out of, as well as some of the tools that we've built internally that I'll be talking about later have come from. 05:28.550 --> 05:35.090 So this is sort of where the cloud is as of 2017. 05:35.370 --> 05:41.070 Unfortunately, we don't have too many updated stats, but it's just about the same. 05:41.350 --> 05:50.090 So it used to be about $0.14 per gigahash hour, and now it's close to $0.03 per gigahash hour. 05:50.090 --> 05:58.590 Now we do have our internal crackers, which you can see are running at about $0.07 per gigahash hour. 05:59.190 --> 06:02.930 And we built those for about $25,000. 06:02.930 --> 06:14.070 So if you're working for a large consulting firm, that has the capital to invest in their onsite cracking machine, you can absolutely save money by doing that. 06:14.070 --> 06:30.670 However, if you're either like a small time consulting firm, or you're doing this as kind of like a single contractor or something like that, absolutely look into some of the AWS machines. 06:31.150 --> 06:40.090 So the P316 is currently the largest instance that you can get with GPUs. 06:40.950 --> 07:05.190 So and so yeah, that's going to be kind of the best thing for your buck if you're looking to throw a lot of power, as well as using a new tool that we'll touch on in a little bit called Hashtopolis, which allows you to do distributed cracking, by attaching multiple versions of those multiple instances of Hashcat together. 07:05.490 --> 07:26.890 And Hashtopolis kind of acts as an orchestration engine handling the binaries and farming jobs out across all of those different those different platforms, which will allow you to combine both your in house and your cloud cloud instances, and really start throwing massive amounts of power. 07:27.370 --> 07:32.230 You just do have to keep in mind that everything will come with a cost. 07:32.230 --> 07:36.730 Hashtopolis is free, AWS instances are definitely not. 07:38.170 --> 07:43.670 So this slide is shamelessly borrowed from the Terahash Corporation. 07:43.670 --> 07:48.170 They run the Brutalis, or they produce the Brutalis machines. 07:48.350 --> 07:56.530 So currently, you can see their largest one is running 448 NVIDIA RTX 2080s. 07:56.630 --> 08:12.610 So if you're looking at running against like running a brute force attack, you're talking, doing the entire eight character key space, you know, instantly. 08:12.610 --> 08:18.870 Um, so a character passwords are absolutely in 2020 dead. 08:18.870 --> 08:23.070 I gave a version of this talk in 2019 and said that they're dead. 08:23.190 --> 08:25.510 The same was true in 2018. 08:25.590 --> 08:27.910 It's definitely true now. 08:28.210 --> 08:39.930 The amount of power that firms are able to throw at brute forcing, especially in TLM hashes, is just absolutely incredible at this point. 08:40.730 --> 08:52.650 And so really you want to work on, you know, instructing your, your individuals to have, you know, strong 12 character passwords. 08:52.650 --> 08:55.790 As you can see, the exponential growth is just incredible. 08:55.790 --> 09:05.830 So you have from an 11 character password to a 12 character password, it goes from a two week crack time on an NTLM hash to a three year crack time. 09:05.830 --> 09:16.610 And, you know, this is obviously assuming that that password is not going to be in any sort of a word list or any sort of a mask that, that we can create. 09:17.530 --> 09:26.510 So just so that we're all speaking the same language, I'll go over a few key terms, some of which you've probably heard me using previously in this talk. 09:26.510 --> 09:29.590 And, you know, I'll continue to use throughout the talk. 09:30.260 --> 09:34.810 So masks are the makeup of a word broken into its character set. 09:34.810 --> 09:56.230 This is pretty important because this is, so for instance, if you had a password one with a capital P and then all lowercase letters, and then a one, the mask is going to be, you know, capital letter, seven lowercase letters, and then one digit. 09:56.850 --> 10:07.310 This becomes really important when you're talking about attacking large numbers of passwords, as you can sort of guess at the makeup of people's passwords. 10:07.730 --> 10:27.150 For instance, if I told somebody that they're going to make, they need to make a 12 character password that has a capital letter, lowercase letters, and digits, the vast majority of English speaking individuals are going to create a password that starts with a capital letter, 10:27.150 --> 10:40.350 has, you know, 10 or 11 lowercase letters, and then has trailing digits, you know, password one, summer 2020, you know, we've all seen all of those on engagements. 10:40.350 --> 10:43.110 It's very, very common. 10:43.110 --> 10:51.550 Very rarely will you see them shift where the middle characters have your uppercasing or things like that. 10:51.550 --> 11:00.910 It's kind of attacking that human psychology and the human linguistics of how we form words, especially in the English speaking. 11:00.910 --> 11:17.910 I did read a very interesting article written by a linguistics professor that kind of touched on differences that you'll see in Asian languages, especially in also some of the Cyrillic languages as far as password creation and the different masks that we'll see. 11:17.910 --> 11:31.890 Unfortunately, I haven't worked too many, well, I haven't worked any engagements that really leaned heavily on anything other than the typical English character set. 11:32.110 --> 11:36.770 So that's where my main focus is, especially when it comes to password cracking. 11:37.150 --> 11:40.930 Hybrid attack is where you're going to be brute forcing. 11:40.930 --> 11:48.850 So again, brute forcing is just guessing every possible combination inside the character space. 11:48.850 --> 11:56.050 So A through Z, digits zero through nine, and then all of your special characters. 11:56.270 --> 12:13.350 So if I have eight character passwords, I would start with eight A's and then seven A's and a B, and then continue to work my way through as I've tried every single character set that we can against those hashes until we get a match. 12:13.710 --> 12:20.050 So a hybrid attack is going to use that brute force attack, and then you would take a mask and either append or prepend. 12:20.050 --> 12:38.470 So if you had, say, a company name, or if you knew that they had something like a five character password, and you wanted to try adding the year to the end of it. 12:38.470 --> 12:48.610 So you would do brute force all character sets for five characters and then add the year on the end of it as the hybrid attack. 12:48.610 --> 12:56.990 So the year would be your either append or prepend. 12:57.250 --> 13:01.070 So a word list is much different than a password dump. 13:01.070 --> 13:11.390 So a word list, and this is a very important distinction, a word list is the candidate of words that you're going to either run by themselves or be modified with rules. 13:11.510 --> 13:13.490 So these are going to be dictionary words. 13:13.490 --> 13:16.390 This is not supposed to be a password dump. 13:16.590 --> 13:28.110 So the difference being a password dump is going to be passwords that have already been cracked, whereas a word list is going to be basic words like summer or spring. 13:28.110 --> 13:38.370 And then you can use those words and then modify them via rules in Hashcat to create different candidates for cracking. 13:38.370 --> 13:51.130 If you take a password dump that has like summer 2020 and apply rules to it in Hashcat, sometimes those rules will either append or prepend different character sets. 13:51.130 --> 13:59.950 So you might get summer 2020 2020 using summer 2020 in a password dump as a word list. 13:59.950 --> 14:02.370 So that would be the distinction there. 14:05.150 --> 14:10.270 So this is one of my favorite quotes, if your only tool is a hammer then every problem looks like a nail. 14:10.550 --> 14:12.430 Obviously Mark Twain. 14:13.470 --> 14:16.810 And so that's what we'll touch on here in a minute. 14:20.010 --> 14:21.850 This is the kit that we use. 14:21.850 --> 14:27.690 I'll go into what each of these tools does in the next few slides. 14:31.970 --> 14:37.570 So Hashcat, it's now the de facto standard as far as password cracking is concerned. 14:37.570 --> 14:40.470 It supports just about every hash imaginable. 14:40.650 --> 14:48.450 I believe they fixed it, but there was one time that I did have a weird zip file that I did have to use John the Ripper on. 14:48.710 --> 14:56.650 But I've never really encountered anything on an engagement that Hashcat can't really do. 14:56.810 --> 15:01.850 John the Ripper was the de facto standard five to ten years ago. 15:01.850 --> 15:04.530 Again, it uses the CPU cracking. 15:05.210 --> 15:09.730 Hashcat is using GPUs. 15:09.950 --> 15:17.650 It's very, very well maintained, constantly updated, and lots of improvements. 15:17.650 --> 15:22.230 Super easy to set up and to integrate with other tools. 15:22.230 --> 15:27.390 Also, there's so much information and documentation out there about using Hashcat. 15:27.390 --> 15:33.630 So if you ever have issues, you can always look it up and usually find the answer. 15:34.590 --> 15:42.470 Hashtopolis, this is what we've been using to kind of integrate our distributed cracking operations. 15:42.470 --> 15:45.770 So this is a wrapper for Hashcat. 15:45.770 --> 15:49.590 What it does is it manages agents, jobs, word lists, and Hashcat binaries. 15:49.590 --> 16:00.050 So basically, you log into a web portal via Hashtopolis, and it goes and connects to all the different Hashcat instances that you've connected to it. 16:00.050 --> 16:04.310 You feed it a list of hashes, and you tell it to crack. 16:04.310 --> 16:15.030 And then it goes and farms all of this out to those different Hashcat instances and does all of the work for you, basically. 16:15.070 --> 16:25.550 The other great thing is if there's a new Hashcat binary that comes out, you can push an update to all of your distributed instances via Hashtopolis. 16:26.350 --> 16:40.450 So for instance, if you have a bunch of AWS instances spun up, and you wanted to quickly spin up new ones or push a new binary, you can do that very, very easily within Hashtopolis. 16:41.470 --> 16:43.070 We don't use this a lot. 16:43.070 --> 17:05.770 This is really more for those big enterprise engagements, only because the cost of running a lot of distributed AWS instances does become prohibitive, especially if we're just looking for cracking a Kerberos hash or things that we can typically do on our internal cracking machines. 17:06.570 --> 17:08.070 Hash ID. 17:08.390 --> 17:11.790 So this used to be a lot more useful. 17:12.030 --> 17:15.330 It's not the most useful anymore. 17:15.710 --> 17:29.730 If you're having trouble identifying what kind of a hash you've caught, so you find a list of hashes on a client gig, and you're not quite sure what you've got, you can use this. 17:29.890 --> 17:37.310 The nice thing about this is it is offline compared to some of the online systems that you can drop hashes into. 17:37.310 --> 17:42.930 So if you're trying to keep sensitive data off the internet, you can do it. 17:45.230 --> 18:00.130 If Hash ID isn't working for you, and you've got a new kind of hash that you're not sure on, if there's open source code on GitHub, you might be able to see what kind of a hashing algorithm it's using. 18:00.130 --> 18:14.150 So if you get it off of a new web application, you can always try and create your own hash and see if you can also self-register. 18:14.350 --> 18:39.130 So if you somehow get into a database backend and you're able to self-register on the web application, so you could create a password of password one, and then go try and crack that password that you know the password, and try and figure out what kind of a hash it is from there by throwing different kind of hashes at it. 18:40.730 --> 18:47.570 PwSpy is a tool that was built internally for Optive, but it is open source. 18:47.630 --> 18:54.150 Some of the cool things that it will do is it will go out and find the most common masks for you. 18:54.250 --> 19:16.910 So if you're cracking, you know, again, 20,000 passwords, and you've cracked, say, 40% of them on your first pass through, you can have PwSpy analyze those hashes for you, and it will go ahead and tell you which masks that you can then plug into Hashcat for potential more success. 19:17.190 --> 19:34.810 So say they're having, you know, the client has a 12 character minimum, so you find everybody is running, you know, uppercase letter, you know, 10 lowercase letters, and then a digit, or things like that. 19:34.810 --> 19:46.610 It will also identify weak passwords, so you can kind of tweak that with some of the settings in there by saying, you know, only words, or only words in a digit, or things like that. 19:46.610 --> 19:50.030 It will break out the different password links that you have. 19:50.030 --> 19:52.090 It will also pull out different base words. 19:52.090 --> 20:16.190 So if, you know, if you're doing a thing, an engagement, and you find that people are using seasons or the client name over and over again to create passwords, you can absolutely use this and show that as evidence to your client to say, you know, maybe you should put a blacklist policy in for different password terms, 20:16.190 --> 20:17.310 and things like that. 20:17.310 --> 20:25.230 The other thing that it will do is it will analyze and find reused hashes. 20:25.230 --> 20:32.790 So if you find multiple people are using the same password, this will identify that, so you could then point that out to the client. 20:33.130 --> 20:36.790 You know, it's not usually a big deal if it's summer 2020. 20:36.830 --> 20:42.230 It's a big deal, but it's not, you know, a deal with people sharing passwords. 20:42.230 --> 20:57.570 But if it's more of a complex password that you find multiple times, that could indicate that people are either sharing their passwords, or somebody's reusing passwords for, say, their local account, and then their administrator account, or, you know, 20:57.570 --> 21:01.030 even DA creds, or somewhere in a SQL server. 21:02.710 --> 21:06.410 Feel free to go download PwSpy. 21:06.410 --> 21:16.770 It's open source, and I've had a lot of people reach out and suggest edits or find bugs. 21:16.770 --> 21:26.830 So please, if there's anything, please feel free to either put in a pull request or whatever on GitHub, or reach out to me via Twitter or 21:30.090 --> 21:31.150 through GitHub. 21:33.690 --> 21:35.810 So some of the techniques that we use. 21:35.810 --> 21:38.130 So this is how we kind of hone our skills. 21:40.170 --> 21:41.450 So how do you begin? 21:41.450 --> 21:42.930 What's the best way to crack a hash? 21:42.930 --> 21:44.910 Well, so this is a loaded question to me. 21:44.990 --> 21:47.850 I get this a lot from our internal team. 21:48.250 --> 21:54.910 It kind of drives me a little bit crazy because it's kind of like asking what's the best way to use nmap. 21:55.610 --> 21:57.670 There's no one right answer. 21:57.670 --> 22:08.350 So basically, it's kind of an experience, and just depending on the goals of your engagement, what are you looking to do? 22:09.010 --> 22:10.810 So are you after one hash? 22:10.810 --> 22:12.870 Are you after multiple hashes? 22:13.270 --> 22:18.610 You know, the algorithm that you're going after is very, very important. 22:19.070 --> 22:28.130 So, you know, until mhash, you're going to be able to throw a lot more power at than WPA2, only because it's a much faster algorithm. 22:28.130 --> 22:32.230 So you're going to be able to throw more rules and more word sets. 22:32.430 --> 22:52.390 One thing we've done in the past with client engagements is if we're on a wireless gig, and, you know, say we only have a day or two on site, and we know that they're using a pre-shared key, what we'll do is we will have the client provide us that key and create that hash in either an NTLM or an MD5, 22:52.390 --> 23:04.730 and then run it against our rule sets and our word list to then demonstrate the impact to that client that says, hey, you know, we didn't have enough time to crack the WPA2 while we were on site. 23:04.730 --> 23:06.930 However, we would have cracked it. 23:06.930 --> 23:15.370 So, you know, if you have somebody sitting in your parking lot and they capture, they could potentially come back and get into your network that way. 23:15.370 --> 23:18.370 And this is, you know, how we did it. 23:18.370 --> 23:22.790 So that's one way to kind of work with your clients. 23:24.170 --> 23:27.250 So where do you get hashes? 23:28.350 --> 23:33.130 You know, always looking for hash dumps. 23:33.130 --> 23:41.670 If you can get onto a Linux box and you have root access and you can dump Etsy shadow, comp files are always great. 23:42.170 --> 23:45.390 Back-end databases that you can get into. 23:45.390 --> 23:51.610 Mimikatz if you encounter like an older Windows system that's not fully patched. 23:51.610 --> 24:02.490 Web applications a lot of times will expose hashes, you know, either via misconfigurations or just having their database exposed. 24:02.670 --> 24:06.690 We run a lot of Responder or Magnum Metal 6 on internal gigs. 24:06.690 --> 24:09.110 I'll do a demo of that in a little bit. 24:09.450 --> 24:15.750 DC sync and NTDS, you know, these are some of the common ways to find hashes. 24:15.970 --> 24:19.850 There's thousands of ways to find hashes. 24:20.970 --> 24:30.790 You know, if you're on a wireless gig and you capture a pre-shared key handshake, you can open up Wireshark and get the PSK hash out of there. 24:30.930 --> 24:33.950 There are just many, many different ways to get hashes. 24:33.950 --> 24:38.210 These are some good ways to start if you're kind of looking to get into it. 24:38.330 --> 24:53.550 I would highly recommend kind of building a local lab, setting up Responder on your local lab or setting up a database, making some hashes, and then just going ahead and trying to crack them. 24:53.570 --> 25:01.890 You can also just create a bunch of, you know, NTLM hashes or MD5 hashes via some scripts. 25:02.250 --> 25:08.330 So, make a bunch of passwords that you know and test it out in Hashcat. 25:08.330 --> 25:09.810 So, that's a good way to get started. 25:12.010 --> 25:14.190 So, developing a methodology. 25:14.190 --> 25:18.330 So, this is really where our password audit kind of came out of. 25:18.790 --> 25:33.830 So, we wanted to create a repeatable process for other people on our team to be able to follow and make it as easy as possible for a new consultant to just kind of get spun up and start working. 25:34.090 --> 25:39.930 These are going to be much more analysis based than, you know, hands on the keyboard. 25:39.930 --> 25:49.790 This is going to be a lot of, you know, letting the cracker run, using your various rules and masks and all of the stuff that we've discussed previously. 25:50.070 --> 25:54.350 Looking at the results and kind of figuring out where you want to go from there. 25:54.350 --> 26:00.210 Looking at what their hashes are doing, looking at what the passwords they're using are. 26:00.250 --> 26:01.990 Are they a secure company? 26:01.990 --> 26:07.430 Are you seeing, you know, a lot of crazy hashes that, you know, you're not able to crack? 26:07.510 --> 26:11.750 Or are you seeing a lot of, like, really simple passwords? 26:12.010 --> 26:16.290 The other thing we're going to look for is, you know, common words, easy wins. 26:16.290 --> 26:21.950 Again, I keep coming back to summer 2020, password one, company name. 26:21.950 --> 26:26.210 Company name and the date that it was founded is a really popular one. 26:27.230 --> 26:28.650 Street names. 26:28.650 --> 26:43.630 If you're in an area, if you're doing a client and there's, you know, a local sports team, you know, I'm from Ohio, so in my area, you know, you can find a lot of Ohio State or Buckeye-related passwords. 26:44.230 --> 26:48.370 You know, you could extrapolate that across the country. 26:48.370 --> 26:51.610 You know, New England, you could do Patriots or whatever. 26:53.130 --> 27:02.550 A lot of... we'll find a lot of times clients will do... will claim that they do their own password audits, but they're not really doing it effectively. 27:03.290 --> 27:12.970 You know, they might run Hashcat with like a base word list or like a Rocky or something like that and say that they covered it. 27:13.130 --> 27:22.530 You really, for these enterprise engagements, you need heavy-hitting cracking rigs, either built in-house or setting up the cloud. 27:22.530 --> 27:30.730 And I would say even just one Amazon P316 is not going to really, you know, pass muster for this. 27:30.730 --> 27:44.210 You're going to want to throw a good amount of resources at these, especially if you're talking, you know, 20,000 or more, you know, passwords that you're trying to recover. 27:48.230 --> 27:50.150 So what do we do? 27:50.150 --> 27:53.170 Again, we go for quick wins. 27:53.170 --> 27:57.970 So we run... internally we have some proprietary word lists that we use. 27:58.490 --> 28:02.170 It's kind of been tweaked over the years. 28:02.170 --> 28:10.830 It has a lot of data from all the different breaches where we've extrapolated common base words, things like that. 28:10.830 --> 28:13.090 And we'll run those without rules. 28:13.230 --> 28:22.530 And then we will slowly start adding things that increase the time of cracking, but also increase your possibility of cracking more passwords. 28:23.070 --> 28:32.070 So we will continue to run newer and newer attacks against the same list of hashes. 28:32.270 --> 28:37.970 And, you know, as you'll see in a second, it's kind of the law of diminishing returns. 28:37.970 --> 28:43.750 But as we move through the process, we tend to be pretty successful. 28:44.330 --> 28:49.910 We do in-house, we have the capability to do a 1-8 character brute force. 28:49.910 --> 28:53.930 That takes about 24 hours on our internals crackers. 28:54.170 --> 28:59.290 So we can brute force the entire NTLM keyspace within a day. 28:59.290 --> 29:02.630 So that's usually about the first day of a password engagement. 29:02.630 --> 29:09.910 And then we will run our words, our word lists, and then our rules against things after. 29:10.650 --> 29:20.650 You know, we will then use either PWSpy to create different masks, or just use common masks, things like that. 29:20.650 --> 29:28.130 And, you know, just kind of moving on and doing more and more advanced attacks as we get closer to the end of the engagement. 29:29.310 --> 29:40.410 So this is sort of what, this is actually real data, and this is what our password recovery over time looked like on a recent password assessment. 29:40.410 --> 29:48.410 So as you can see, you know, within the first few hours, we cracked the majority of the passwords we were going to crack. 29:48.410 --> 29:58.870 And as we moved through, you can see the longer password recovery attempts did yield less results. 29:58.870 --> 30:14.530 But out of, I believe this was over, this was about 18,000 passwords, or hashes that we were trying to crack, and we cracked almost 14,000 of them, which is pretty good. 30:14.810 --> 30:19.190 You know, that's, that was enough to show an impact to the client. 30:19.190 --> 30:29.790 And this is, you know, over about two weeks of letting the crackers run and then doing a lot of that analysis on the back end and tweaking the rules to match what we were seeing. 30:31.550 --> 30:33.690 So how to help your future self. 30:33.710 --> 30:35.290 This is really important. 30:35.290 --> 30:37.910 So you want to have your POP files. 30:38.870 --> 30:46.490 We'll typically separate out POP files based on clients, but we also keep a master POP file. 30:46.670 --> 30:49.790 That's a historical record of your cracked hashes. 30:49.790 --> 30:53.010 It's useful to see if you've already cracked that hash on another engagement. 30:53.010 --> 30:58.370 So if you're seeing summer 2020, you're not going to burn cycles trying to crack it again. 30:58.370 --> 31:00.110 We'll just try that hash. 31:00.110 --> 31:10.850 This obviously doesn't work against salted hashes, but it will work against, you know, NTLM or any of the, you know, MD5 or things like that. 31:11.510 --> 31:13.790 Do be really careful about bloat. 31:13.790 --> 31:21.110 It can slow down the hash, the process, because it's going to check it against the existing POP file. 31:21.110 --> 31:35.330 So for instance, we did have a pretty overzealous analyst on the team who decided to add the entirety of the LinkedIn dump into our POP file. 31:35.870 --> 31:40.950 And at the time of the dump, LinkedIn did not have any password restrictions. 31:40.950 --> 31:53.350 So you had a lot of four-character passwords or just plain text passwords, which is pretty useless against, you know, enterprise networks that are running either, or 12-character with complexity. 31:53.590 --> 31:59.350 So you do want to be careful of that, because you're going to be running each hash against that POP file. 31:59.510 --> 32:03.150 And again, you're going to be burning CPU cycles on that. 32:03.690 --> 32:04.850 Common masks. 32:04.850 --> 32:19.750 So we keep a list of in-house tools that includes the masks that we can copy in to our hashcat commands, as well as creating new masks as we see fit on the engagements. 32:19.750 --> 32:30.370 But, you know, the common ones, you know, uppercase letters at the beginning, and then trailing lowercase letters with digits at the end. 32:32.570 --> 32:34.850 So now we're going to move into a demo. 32:34.850 --> 32:41.390 I'm going to show you sort of what a typical engagement might look like, you know, on a client network. 32:44.200 --> 32:54.520 Okay, so for this demo, I have a responder lab built using VirtualBox on my Windows machine. 32:54.880 --> 33:06.320 So what I've done is I have set up a domain controller, a firewall appliance, a Kali machine, and a Windows 10 machine. 33:07.320 --> 33:11.300 So you can see all of the machines are up and running. 33:13.460 --> 33:19.960 What you see here is IPFire is running to route everything together. 33:20.380 --> 33:28.340 Windows Server 2012 is currently running to act as the domain controller in the DNS. 33:28.360 --> 33:40.440 Obviously Kali, which is going to be our attacking machine, and then the WinEval is going to be your Windows 10 simulating a client computer. 33:49.470 --> 33:51.110 Okay, so closing that out. 33:51.950 --> 34:04.730 We just want to verify once again that we are on the same network so we can see both of these hosts are actually networked together on the same subnet. 34:05.070 --> 34:07.970 So we'll go ahead and start up Responder here. 34:12.570 --> 34:17.770 So when you start up Responder, you have to feed it the interface that you're using. 34:19.150 --> 34:28.970 So what Responder is doing is poisoning the LL, MNR, and NBTNS requests that Windows machines will set out. 34:28.970 --> 34:32.990 This happens if Windows can't resolve a hostname using DNS. 34:32.990 --> 34:38.510 It will send broadcast traffic out asking for that information. 34:38.730 --> 34:55.790 So Responder kind of into the middle between a domain controller and the Windows machine and will respond with the information that they're requesting. 34:55.910 --> 35:08.390 But it will then ask that Windows machine to send its authentication to it, which the Windows machine will provide, and then Responder will capture those hashes. 35:08.390 --> 35:21.290 You can usually accomplish this by trying to access something that doesn't exist, such as file share does not exist or something like that inside your network libraries. 35:21.550 --> 35:27.530 And that should be sufficient to generate the LL, MNR broadcast traffic. 35:27.530 --> 35:29.490 And we'll see an example of that here. 35:29.490 --> 35:36.430 So I open up the folders and I go to server does not exist. 35:36.810 --> 35:42.050 And you can see the poison answers are being sent and we're capturing NTLMv2 hashes. 35:42.050 --> 35:43.790 Now this is important. 35:44.330 --> 35:51.590 As we start capturing the NTLMv2 hashes, you'll see there are multiple hashes being captured. 35:51.690 --> 35:56.010 These are actually the same hash just due to the nature of NTLMv2. 35:56.010 --> 36:01.230 They are salted so you will receive multiple hashes. 36:01.270 --> 36:12.050 When you are going to crack these hashes, what you'll want to do is take one hash per username. 36:12.170 --> 36:22.910 That way you're not spending excess time trying to crack the same hash for a user that you've already cracked or for a user that you're not going to be able to crack. 36:23.510 --> 36:30.190 So once we've got that hash, we can just copy it over into a text file, which I do here. 36:30.190 --> 36:45.330 So you can see I drop it into hash.txt and you could do this for as many of the usernames and passwords that you capture. 36:46.890 --> 36:48.970 Hopefully you get something juicy. 36:48.970 --> 36:53.370 Sometimes you'll be able to get DA creds or things like that. 36:54.130 --> 37:01.690 Okay, so now that we've got hash.txt created, we're going to go ahead and start up HashCat. 37:01.690 --> 37:06.190 So NTLMv2 hashes are mode 5600. 37:06.190 --> 37:13.650 So to accomplish that in HashCat, you feed it the TACM flag and then 5600. 37:13.710 --> 37:16.510 Then you feed it the file name. 37:16.510 --> 37:24.710 And then in this particular example, we're using a little bit of a contrived example just for brevity. 37:24.890 --> 37:38.630 So we're going to use fasttrack.txt because I happen to know that this particular password for this user, again, because I've created the lab, will be in that. 37:38.670 --> 37:53.990 Now, if this is a live gig, that's where you're going to feed some of the more advanced masks or rules or definitely stronger word lists, things like that. 37:53.990 --> 37:58.730 But you can always start with the quick and easy ones, and maybe you'll get lucky. 37:58.730 --> 38:00.090 And if you do, that's awesome. 38:00.090 --> 38:01.890 You haven't spent a lot of time. 38:01.950 --> 38:08.750 However, if you do need to use those heavier lists, please feel free to. 38:08.750 --> 38:15.830 And definitely use the masks and such that you've got working. 38:21.210 --> 38:26.450 So we start a HashCat here, again, using the mode 5600. 38:27.430 --> 38:31.810 And then we feed it the hash.txt that we created. 38:32.530 --> 38:43.910 And then we go ahead and feed it the particular word list, which in this case, again, is stored as user share word list. 38:43.910 --> 38:46.310 And then we're just using the fasttrack.txt. 38:46.370 --> 38:54.850 Once HashCat starts, again, this particular Kali instance isn't hooked up to my GPU box. 38:54.850 --> 38:58.790 So you'll get some warnings for OpenCL and things like that. 38:59.130 --> 39:04.670 But you'll see the warnings come through. 39:04.670 --> 39:11.630 And then just because I know that this works really quickly, you'll see that this cracks. 39:11.630 --> 39:16.750 And you can see password1 is our cracked password. 39:16.910 --> 39:27.830 Now, if we were cracking multiple passwords, or take longer, you would see those in your POP file. 39:27.830 --> 39:38.870 You can also create a new POP file by doing dash dash POP file dash path equals, and then name your POP file whatever you want. 39:38.870 --> 39:45.830 And that will create a POP file specifically for that particular session with HashCat. 39:45.830 --> 40:00.990 That's useful if you're running an engagement for a particular client, and you wanted to separate out the hashes that you've cracked from them versus the other engagements that you've worked. 40:04.200 --> 40:19.440 So you can see here, as the hash is cracked, it will append the password to the end of the hash file, which will be the exact same way it's presented in the POP file as well. 40:22.900 --> 40:41.580 So now that we've got our password, we can then go ahead and use those credentials to go and log in via Windows doing any particular thing that we might want to do. 40:44.110 --> 40:54.010 Okay, so with a little bit of time that we have left, I'd like to do a quick demo of PWSpy, as it's kind of a new tool that I've developed. 40:54.010 --> 40:59.850 And it was originally released during 6.14 con 2019. 41:00.010 --> 41:03.690 However, it's gone through some pretty major changes. 41:04.130 --> 41:13.930 And I'm happy to announce that the newest version is now live on GitHub for you guys to go ahead and go grab a few so shoes. 41:14.450 --> 41:30.510 So again, this was an internal tool developed mostly to help us deal with the massive amount of information coming from the enterprise password audits. 41:30.510 --> 41:49.950 So the intention was that you would take a POP file that you've created specifically for your particular client, or engagement, and then you would feed that as well as the initial hash list that you fed into Hashcat. 41:49.970 --> 41:53.390 And it would do the analysis for you. 41:54.470 --> 41:56.810 That's pretty much been accomplished. 41:56.810 --> 42:00.430 There's still a few more bugs and things that I'd like to tweak. 42:00.470 --> 42:05.090 However, let's get into it. 42:05.230 --> 42:13.330 For this particular demo, I went ahead and grabbed some passwords that we've seen in some of the public dumps that are out there. 42:13.530 --> 42:25.110 And I went ahead and created some NTLM hashes using those passwords and cracked them using the Optive Cracker to generate the POP file for this demo. 42:25.230 --> 42:27.270 So that's what you're going to see here. 42:27.270 --> 42:30.570 So I'll go ahead and open demo.pot. 42:33.570 --> 42:39.210 As you can see, these are just some common passwords, and they've already been cracked. 42:39.210 --> 42:44.370 So it's time to do the post session analysis on that. 42:44.770 --> 42:51.770 So we're going to go ahead and feed this file into pwspy. 42:52.170 --> 43:04.990 Now, pwspy, if you open up the help options, you'll see that you can feed it both a POP file and a hash list. 43:04.990 --> 43:07.170 The hash list is actually optional. 43:07.170 --> 43:08.870 You don't have to add that. 43:08.870 --> 43:20.830 As well as inside the Python script, you can turn on and off individual modules simply by commenting them out in the calls. 43:20.830 --> 43:27.530 Those are down at the bottom of the script, and I'll show you that towards the end of this demo. 43:28.050 --> 43:49.950 So in this particular case, because we're using publicly available passwords, and we haven't cracked a bunch from a particular company, so there's not going to be any reuse, there's really no sense in doing the hash list as well. 43:50.310 --> 43:53.550 So we're not going to feed that in. 43:53.550 --> 44:07.550 As well as some of the modules may not work because there's just not enough data, such as the mask builder, and definitely the password reuse won't work because you need to feed that the hash list. 44:07.870 --> 44:15.190 So we'll go ahead and run pwspy, and we'll take a look at the output. 44:20.060 --> 44:34.340 So you can see here, the output is a pretty standard script output, complete with the required ASCII text for any cool hacker tool, of course. 44:36.100 --> 44:49.230 So this shows you some of the various modules that have worked. 44:49.250 --> 44:56.150 So as we scroll back, you can see that we have the 45:00.300 --> 45:19.480 common base words, and the number of times that we've seen those, as well as there would be a password reuse, and the masks would go there as well, which would help you if you were going to do further attacks against this client. 45:20.000 --> 45:26.880 The other thing that it will do is it will tell you weak passwords. 45:27.360 --> 45:34.400 So passwords, in this case, I have it set to just passwords that are just plain text. 45:34.400 --> 45:44.460 So you can see all these passwords were cracked and consist of only letters and no numbers or special characters of any sort. 45:44.500 --> 45:50.380 You can always make this more restrictive or less restrictive by editing the Python script. 45:50.540 --> 45:58.300 One of the goals for the future is to add options to define what a weak password would be. 45:58.500 --> 46:07.580 And then the last thing that it will do is check the lengths of all the passwords that you have cracked. 46:07.820 --> 46:13.520 And as you can see, it splits those out and gives you the number of occurrences. 46:13.840 --> 46:18.840 So there were a lot of 9-character passwords, some 10-character passwords. 46:18.840 --> 46:32.800 This really becomes helpful if you are doing, again, an engagement, and let's say the client says that they've got a 12-character password policy. 46:32.980 --> 47:01.160 And you can go ahead and check against that and make sure that you didn't capture any passwords that might not fit that policy, as well as if you're going to build your custom masks that might not be output by this tool, you would be able to use the the password length to help you generate those masks as well. 47:03.490 --> 47:15.150 So the last thing I wanted to touch on with PWSpy is just kind of taking a quick look at the source code and showing where you would turn on and off those modules. 47:15.730 --> 47:31.500 So if we cap the file here, you can see that all of the function calls are down here at the bottom, which I'm highlighting here. 47:31.920 --> 47:41.000 And from there, what you can do is go ahead and comment out any of those different modules, and it will not run those. 47:41.000 --> 47:52.060 So if you didn't particularly want to run the mask builder, or check for weak passwords, or password length for whatever reason, you could go ahead and comment that out. 47:52.060 --> 47:54.420 Again, this is an open source tool. 47:54.420 --> 47:59.580 Please feel free to fork and edit it as you see fit. 48:00.980 --> 48:11.280 And I hope that this proves helpful to somebody or anybody if you are doing especially large password assessments. 48:17.310 --> 48:21.030 I'd like to thank you for taking the time to listen to today's talk. 48:21.370 --> 48:26.730 There's been a lot of great talks here at the Red Team Village, and it looks like there's a few more after me. 48:26.870 --> 48:30.370 It's been a great DEF CON, despite it being remote. 48:30.770 --> 48:44.350 At this time, I would like to just once again reiterate that password cracking methodology is more of a comprehensive approach than a one-size-fits-all. 48:44.350 --> 48:52.750 There are many different ways and approaches to cracking passwords, and what works for one person may not work for everybody. 48:52.970 --> 49:04.190 So keep that in mind, as well as always remember that password cracking is, again, not a one-size-fits-all. 49:04.190 --> 49:08.470 You're not going to be able to do this by just scripting everything. 49:08.910 --> 49:21.810 You definitely need to do that deep dive analysis and really think about what you're after and use that to guide the way that you go after your passwords in the future. 49:22.550 --> 49:35.230 Hopefully you have taken something away from this talk, and I will be in the Red Team Village Discord for any questions. 49:35.230 --> 49:39.290 I'm HX50 in there, as well as on Twitter. 49:39.290 --> 49:41.830 You can find me at HX underscore 50. 49:42.130 --> 49:50.570 And once again, I would highly encourage you to go ahead and try some of these techniques out on your own. 49:50.590 --> 49:59.210 Go ahead and create hashes, set up a lab, and go ahead and crack your own stuff. 50:00.810 --> 50:22.930 I will release the instructions on how to set up my lab, as well as possibly setting up just OVA files that you can download, as well as you can go on GitHub and feel free to grab pwspy if you so choose. 50:22.930 --> 50:31.830 You can find that at github.com slash lwangenheim slash pwspy. 50:31.830 --> 50:36.050 And obviously, that's quite a mouthful to try and spell. 50:36.050 --> 50:41.990 So if you do want to try and find it and Google doesn't help, feel free to reach out to me. 50:42.130 --> 50:48.150 I'm more than happy to either just provide you the link, or I can just send you the files directly.