[00:00.990 --> 00:09.010]  All right, we're back. And this is our co-worker. So we felt that we had to give him a quick
[00:09.010 --> 00:14.430]  introduction because, you know, where would we be if we didn't give him this introduction? So,
[00:14.430 --> 00:20.030]  you know, this is a statement that Lee asked me to write, that he asked me to prepare for him
[00:20.030 --> 00:25.670]  before this talk. So this is the direct quote from Lee. So he says, what did you just say about me,
[00:25.670 --> 00:30.090]  you hecking cowboy? I'll have you know I graduated top of my class in the Hashtag University. I've
[00:30.090 --> 00:34.990]  been involved in numerous secret pull requests of the Hashcat code repository, and I have over
[00:34.990 --> 00:41.210]  300 GPUs in my basement. I'm trained in guerrilla password cracking tactics, and I'm the top
[00:41.210 --> 00:46.430]  contributor to hashes.org in the entire US. 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:55.150]  Mark my hecking words. You think you can get away with these pull requests? Think again, cowboy.
[00:55.150 --> 00:59.610]  As we speak, I am contacting my secret network of GPUs across the USA, and your IP is being
[00:59.610 --> 01:04.310]  traced right now. So you better prepare for the storm. The cluster that wipes off your pathetic
[01:04.310 --> 01:09.230]  little thing you call your password. You're cracked, kid. I can crack your password anytime,
[01:09.230 --> 01:14.030]  and I can use it in over 700 ways, and that's not even including my FPGA. Not only am I extensively
[01:14.030 --> 01:18.530]  trained in password-free combat, but I also have access to the entire arsenal of your crypto miner
[01:18.530 --> 01:22.530]  underground. We'll use it to the full extent to wipe your miserable password off the face of the
[01:23.230 --> 01:30.850]  little hacker. Please welcome the password king, Lee. Welcome to Hashes, Smothered, Covered,
[01:30.850 --> 01:36.930]  and Scattered. Modern password cracking as a methodology. My name is Lee Wangenheim. I'm a
[01:36.930 --> 01:42.750]  security consultant here at Optiv. I hack things for fun as well as for a job. If I wasn't getting
[01:42.750 --> 01:48.630]  paid to do this, I'd be doing it on my own anyway. I've got about five years of InfoSec experience,
[01:48.630 --> 01:53.810]  mostly focused on the offensive side of the house, and currently I'm helping to run the
[01:53.810 --> 02:02.110]  crackers that we've got here at Optiv. So why does this matter? Because it only takes one password,
[02:02.110 --> 02:11.610]  and as we know, people tend to use weak passwords. Some examples that we've seen on actual gigs are
[02:11.610 --> 02:17.990]  using default passwords for Cisco devices, Microsoft SQL Server. I've even seen iDRAC
[02:17.990 --> 02:26.750]  accounts using the default root and Kelvin, and everybody's familiar with the fall 2019,
[02:26.750 --> 02:35.410]  or I guess now it would be summer 2020. This is a real issue, and we run into it more often than
[02:35.410 --> 02:41.150]  not. Once we've got one foothold into your network, we can use that to move laterally as much as we
[02:41.150 --> 02:50.450]  want. Some of the hardware that we're using. So we used to use CPUs and Rainbow Tables. CPUs,
[02:50.450 --> 02:56.230]  not really working, not really worth it anymore. They've kind of been overpassed now that the
[02:56.230 --> 03:01.910]  modern GPU rigs are out there. We used to use a lot of Rainbow Tables to look up, especially in
[03:01.910 --> 03:08.330]  NTLM and more common hash types. However, those have been kind of supplanted by the new GPU
[03:09.290 --> 03:16.070]  cracking machines. The reason behind that is it's actually faster to use a GPU to crack the hashes
[03:16.840 --> 03:23.510]  via brute force attack than it is to try and do a Rainbow Table lookup. Because again,
[03:23.510 --> 03:30.250]  you're burning CPU cycles doing Rainbow Table lookups versus GPU cycles with the new
[03:31.790 --> 03:41.890]  modern GPU setups. We do sometimes use cloud using the AWS boxes, the new GPU boxes.
[03:42.310 --> 03:47.650]  Those are pretty handy. They are expensive. However, if you do need to throw a lot of power
[03:47.650 --> 03:54.790]  at a hash or a series of hashes, it can be beneficial to go ahead and do that.
[03:55.350 --> 04:01.110]  Sometimes if we're on site and clients don't want their hashes leaving, or if we're on a Wi-Fi gig
[04:01.110 --> 04:07.850]  or something like that, we will use a laptop. Typically, a gaming laptop will do better,
[04:07.850 --> 04:16.880]  but you use what you have, right? If you do happen to still be running a mining rig in 2020,
[04:17.530 --> 04:26.740]  you know, for some of the GPU mining rig, GPU crypto algorithms such as Ethereum,
[04:26.740 --> 04:33.060]  you can use those. 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 --> 04:50.870]  So talking about AWS, some of the engagements that we do run here at Optiv are
[04:52.350 --> 04:57.530]  more of an enterprise security assessment, which is where we'll have a company provide
[04:57.530 --> 05:03.570]  every hash throughout their Windows domain. And then we will throw as many resources as we can
[05:03.570 --> 05:09.670]  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:20.070]  That kind of engagement is sort of where this methodology really was born out of,
[05:20.070 --> 05:24.210]  as well as some of the tools that we've built internally that I'll be talking about later
[05:25.030 --> 05:36.170]  have come from. So this is sort of where the cloud is as of 2017. Unfortunately,
[05:36.170 --> 05:41.070]  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:57.850]  Now we do have our internal crackers, which you can see are running at about $0.07 per gigahash
[05:57.850 --> 06:06.150]  hour. And we built those for about $25,000. So if you're working for a large consulting firm,
[06:06.170 --> 06:13.230]  that has the capital to invest in their onsite cracking machine, you can absolutely save money
[06:13.230 --> 06:19.990]  by doing that. However, if you're either like a small time consulting firm, or you're doing this
[06:19.990 --> 06:28.930]  as kind of like a single contractor or something like that, absolutely look into some of the AWS
[06:29.630 --> 06:40.090]  machines. So the P316 is currently the largest instance that you can get with GPUs.
[06:40.950 --> 06:47.030]  So and so yeah, that's going to be kind of the best thing for your buck if you're looking to
[06:47.030 --> 06:53.110]  throw a lot of power, as well as using a new tool that we'll touch on in a little bit called
[06:53.110 --> 07:00.310]  Hashtopolis, which allows you to do distributed cracking, by attaching multiple versions of those
[07:01.370 --> 07:07.670]  multiple instances of Hashcat together. And Hashtopolis kind of acts as an orchestration
[07:07.670 --> 07:12.690]  engine handling the binaries and farming jobs out across all of those different
[07:13.970 --> 07:20.270]  those different platforms, which will allow you to combine both your in house and your cloud
[07:20.270 --> 07:26.890]  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:45.310]  So this slide is shamelessly borrowed from the Terahash Corporation. They run the Brutalis,
[07:45.310 --> 07:51.890]  or they produce the Brutalis machines. So currently, you can see their largest one
[07:51.890 --> 08:02.410]  is running 448 NVIDIA RTX 2080s. So if you're looking at running against like running a brute
[08:02.410 --> 08:12.610]  force attack, you're talking, doing the entire eight character key space, you know, instantly.
[08:12.610 --> 08:21.170]  Um, so a character passwords are absolutely in 2020 dead. I gave a version of this talk in 2019
[08:21.170 --> 08:29.450]  and said that they're dead. The same was true in 2018. It's definitely true now. The amount
[08:29.450 --> 08:37.470]  of power that firms are able to throw at brute forcing, especially in TLM hashes, is just
[08:37.470 --> 08:47.390]  absolutely incredible at this point. And so really you want to work on, you know, instructing
[08:47.390 --> 08:54.010]  your, your individuals to have, you know, strong 12 character passwords. As you can see, the
[08:54.010 --> 09:00.230]  exponential growth is just incredible. So you have from an 11 character password to a 12 character
[09:00.230 --> 09:05.830]  password, it goes from a two week crack time on an NTLM hash to a three year crack time.
[09:05.830 --> 09:12.070]  And, you know, this is obviously assuming that that password is not going to be in any sort of
[09:12.210 --> 09:19.970]  a word list or any sort of a mask that, that we can create. So just so that we're all speaking
[09:19.970 --> 09:24.310]  the same language, I'll go over a few key terms, some of which you've probably heard me using
[09:24.850 --> 09:29.590]  previously in this talk. And, you know, I'll continue to use throughout the talk.
[09:30.260 --> 09:35.810]  So masks are the makeup of a word broken into its character set. This is pretty important
[09:35.810 --> 09:40.910]  because this is, so for instance, if you had a password one with a capital P
[09:41.680 --> 09:51.350]  and then all lowercase letters, and then a one, the mask is going to be, you know, capital letter,
[09:52.370 --> 09:56.230]  seven lowercase letters, and then one digit.
[09:56.850 --> 10:00.110]  This becomes really important when you're talking about
[10:01.550 --> 10:07.310]  attacking large numbers of passwords, as you can sort of guess at the makeup of people's passwords.
[10:07.730 --> 10:11.950]  For instance, if I told somebody that they're going to make, they need to make a 12 character
[10:11.950 --> 10:21.690]  password that has a capital letter, lowercase letters, and digits, the vast majority of English
[10:21.690 --> 10:27.150]  speaking individuals are going to create a password that starts with a capital letter,
[10:27.150 --> 10:35.070]  has, you know, 10 or 11 lowercase letters, and then has trailing digits, you know, password one,
[10:35.070 --> 10:43.110]  summer 2020, you know, we've all seen all of those on engagements. It's very, very common.
[10:43.110 --> 10:49.390]  Very rarely will you see them shift where the middle characters have your uppercasing
[10:50.250 --> 10:55.030]  or things like that. It's kind of attacking that human psychology and the human
[10:56.190 --> 11:01.950]  linguistics of how we form words, especially in the English speaking. I did read a very
[11:01.950 --> 11:09.170]  interesting article written by a linguistics professor that kind of touched on differences
[11:09.170 --> 11:14.650]  that you'll see in Asian languages, especially in also some of the Cyrillic languages as far
[11:14.650 --> 11:19.970]  as password creation and the different masks that we'll see. Unfortunately, I haven't worked
[11:19.970 --> 11:28.610]  too many, well, I haven't worked any engagements that really leaned heavily on anything other than
[11:29.000 --> 11:34.810]  the typical English character set. So that's where my main focus is, especially when it comes
[11:34.810 --> 11:41.610]  to password cracking. Hybrid attack is where you're going to be brute forcing. So again,
[11:41.610 --> 11:48.870]  brute forcing is just guessing every possible combination inside the character space. So
[11:48.870 --> 11:56.870]  A through Z, digits zero through nine, and then all of your special characters. So if I have
[11:56.870 --> 12:04.090]  eight character passwords, I would start with eight A's and then seven A's and a B, and then
[12:04.090 --> 12:10.730]  continue to work my way through as I've tried every single character set that we can against
[12:10.730 --> 12:16.870]  those hashes until we get a match. So a hybrid attack is going to use that brute force attack,
[12:16.870 --> 12:25.370]  and then you would take a mask and either append or prepend. So if you had, say, a
[12:25.370 --> 12:34.710]  company name, or if you knew that they had something like a five character password,
[12:34.710 --> 12:40.450]  and you wanted to try adding the year to the end of it. So you would do brute force
[12:40.450 --> 12:46.030]  all character sets for five characters and then add the year on the end of it
[12:46.030 --> 12:56.990]  as the hybrid attack. So the year would be your either append or prepend.
[12:57.250 --> 13:03.010]  So a word list is much different than a password dump. So a word list, and this is a very
[13:03.010 --> 13:07.870]  important distinction, a word list is the candidate of words that you're going to either run by
[13:07.870 --> 13:14.210]  themselves or be modified with rules. So these are going to be dictionary words. This is not
[13:14.210 --> 13:20.690]  supposed to be a password dump. So the difference being a password dump is going to be passwords
[13:20.690 --> 13:27.070]  that have already been cracked, whereas a word list is going to be basic words like summer or
[13:27.070 --> 13:35.230]  spring. And then you can use those words and then modify them via rules in Hashcat to create
[13:35.870 --> 13:43.230]  different candidates for cracking. If you take a password dump that has like summer 2020 and apply
[13:43.230 --> 13:48.690]  rules to it in Hashcat, sometimes those rules will either append or prepend
[13:49.470 --> 13:57.110]  different character sets. So you might get summer 2020 2020 using summer 2020 in a password dump
[13:57.830 --> 14:02.370]  as a word list. So that would be the distinction there.
[14:05.150 --> 14:09.270]  So this is one of my favorite quotes, if your only tool is a hammer then every problem looks
[14:09.270 --> 14:16.810]  like a nail. Obviously Mark Twain. And so that's what we'll touch on here in a minute.
[14:20.010 --> 14:27.690]  This is the kit that we use. I'll go into what each of these tools does in the next few slides.
[14:31.970 --> 14:38.090]  So Hashcat, it's now the de facto standard as far as password cracking is concerned. It supports
[14:38.090 --> 14:45.070]  just about every hash imaginable. I believe they fixed it, but there was one time that I did have a
[14:45.070 --> 14:51.290]  weird zip file that I did have to use John the Ripper on. But I've never really encountered
[14:52.270 --> 14:58.950]  anything on an engagement that Hashcat can't really do. John the Ripper was the de facto
[14:58.950 --> 15:05.950]  standard five to ten years ago. Again, it uses the CPU cracking. Hashcat is
[15:07.450 --> 15:17.650]  using GPUs. It's very, very well maintained, constantly updated, and lots of improvements.
[15:17.650 --> 15:24.830]  Super easy to set up and to integrate with other tools. Also, there's so much information
[15:24.830 --> 15:29.210]  and documentation out there about using Hashcat. So if you ever have issues, you can always
[15:29.210 --> 15:38.890]  look it up and usually find the answer. Hashtopolis, this is what we've been using
[15:38.890 --> 15:45.770]  to kind of integrate our distributed cracking operations. So this is a wrapper for Hashcat.
[15:45.770 --> 15:50.810]  What it does is it manages agents, jobs, word lists, and Hashcat binaries. So basically,
[15:50.810 --> 15:56.690]  you log into a web portal via Hashtopolis, and it goes and connects to all the different
[15:56.690 --> 16:03.370]  Hashcat instances that you've connected to it. You feed it a list of hashes, and you tell it
[16:03.370 --> 16:10.630]  to crack. And then it goes and farms all of this out to those different Hashcat instances
[16:11.490 --> 16:17.450]  and does all of the work for you, basically. The other great thing is if there's a new
[16:17.450 --> 16:21.830]  Hashcat binary that comes out, you can push an update to all of your distributed
[16:23.090 --> 16:30.690]  instances via Hashtopolis. So for instance, if you have a bunch of AWS instances spun up,
[16:30.690 --> 16:38.090]  and you wanted to quickly spin up new ones or push a new binary, you can do that very,
[16:38.090 --> 16:44.090]  very easily within Hashtopolis. We don't use this a lot. This is really more
[16:44.090 --> 16:50.570]  for those big enterprise engagements, only because the cost of running a lot of distributed
[16:50.570 --> 16:58.790]  AWS instances does become prohibitive, especially if we're just looking for cracking a Kerberos
[16:58.790 --> 17:05.770]  hash or things that we can typically do on our internal cracking machines.
[17:06.570 --> 17:15.330]  Hash ID. So this used to be a lot more useful. It's not the most useful anymore.
[17:15.710 --> 17:20.890]  If you're having trouble identifying what kind of a hash you've caught, so you find a list of
[17:20.890 --> 17:30.770]  hashes on a client gig, and you're not quite sure what you've got, you can use this. The nice thing
[17:30.770 --> 17:37.310]  about this is it is offline compared to some of the online systems that you can drop hashes into.
[17:37.310 --> 17:47.850]  So if you're trying to keep sensitive data off the internet, you can do it. If Hash ID isn't
[17:47.850 --> 17:55.650]  working for you, and you've got a new kind of hash that you're not sure on, if there's open source
[17:55.650 --> 18:00.710]  code on GitHub, you might be able to see what kind of a hashing algorithm it's using. So if
[18:00.710 --> 18:09.350]  you get it off of a new web application, you can always try and create your own hash
[18:10.270 --> 18:18.150]  and see if you can also self-register. So if you somehow get into a database backend
[18:18.150 --> 18:23.350]  and you're able to self-register on the web application,
[18:23.350 --> 18:30.750]  so you could create a password of password one, and then go try and crack that password that you
[18:30.750 --> 18:37.010]  know the password, and try and figure out what kind of a hash it is from there by throwing
[18:37.010 --> 18:45.950]  different kind of hashes at it. PwSpy is a tool that was built internally for Optive, but it is
[18:45.950 --> 18:52.750]  open source. Some of the cool things that it will do is it will go out and find the most common
[18:52.750 --> 18:59.710]  masks for you. So if you're cracking, you know, again, 20,000 passwords, and you've cracked,
[18:59.710 --> 19:07.470]  say, 40% of them on your first pass through, you can have PwSpy analyze those hashes for you,
[19:07.470 --> 19:14.090]  and it will go ahead and tell you which masks that you can then plug into Hashcat
[19:14.690 --> 19:20.190]  for potential more success. So say they're having, you know, the client has
[19:21.210 --> 19:30.050]  a 12 character minimum, so you find everybody is running, you know, uppercase letter, you know,
[19:30.050 --> 19:37.170]  10 lowercase letters, and then a digit, or things like that. It will also identify weak passwords,
[19:37.170 --> 19:42.850]  so you can kind of tweak that with some of the settings in there by saying, you know,
[19:42.850 --> 19:48.210]  only words, or only words in a digit, or things like that. It will break out the different
[19:48.210 --> 19:53.870]  password links that you have. It will also pull out different base words. So if, you know, if
[19:53.870 --> 20:01.530]  you're doing a thing, an engagement, and you find that people are using seasons or the client name
[20:01.530 --> 20:08.330]  over and over again to create passwords, you can absolutely use this and show that as evidence to
[20:08.330 --> 20:13.550]  your client to say, you know, maybe you should put a blacklist policy in for different password
[20:15.230 --> 20:20.830]  terms, and things like that. The other thing that it will do is it will
[20:22.810 --> 20:29.130]  analyze and find reused hashes. So if you find multiple people are using the same password,
[20:29.130 --> 20:34.610]  this will identify that, so you could then point that out to the client. You know, it's not usually
[20:34.690 --> 20:41.570]  a big deal if it's summer 2020. It's a big deal, but it's not, you know, a deal with people sharing
[20:41.570 --> 20:46.950]  passwords. But if it's more of a complex password that you find multiple times, that could indicate
[20:46.950 --> 20:53.130]  that people are either sharing their passwords, or somebody's reusing passwords for, say,
[20:53.130 --> 20:59.530]  their local account, and then their administrator account, or, you know, even DA creds, or somewhere
[20:59.530 --> 21:10.610]  in a SQL server. Feel free to go download PwSpy. It's open source, and I've had a lot of people
[21:10.610 --> 21:19.190]  reach out and suggest edits or find bugs. So please, if there's anything, please feel free
[21:19.190 --> 21:26.830]  to either put in a pull request or whatever on GitHub, or reach out to me via Twitter or
[21:30.090 --> 21:38.130]  through GitHub. So some of the techniques that we use. So this is how we kind of hone our skills.
[21:40.170 --> 21:44.910]  So how do you begin? What's the best way to crack a hash? Well, so this is a loaded question to me.
[21:44.990 --> 21:50.810]  I get this a lot from our internal team. It kind of drives me a little bit crazy because
[21:50.810 --> 21:57.670]  it's kind of like asking what's the best way to use nmap. There's no one right answer.
[21:57.670 --> 22:06.690]  So basically, it's kind of an experience, and just depending on the goals of your engagement,
[22:06.690 --> 22:12.870]  what are you looking to do? So are you after one hash? Are you after multiple hashes?
[22:13.270 --> 22:19.950]  You know, the algorithm that you're going after is very, very important. So, you know,
[22:19.950 --> 22:26.190]  until mhash, you're going to be able to throw a lot more power at than WPA2, only because
[22:26.190 --> 22:32.230]  it's a much faster algorithm. So you're going to be able to throw more rules and more word sets.
[22:32.430 --> 22:38.330]  One thing we've done in the past with client engagements is if we're on a wireless gig,
[22:38.330 --> 22:43.410]  and, you know, say we only have a day or two on site, and we know that they're using a pre-shared
[22:43.410 --> 22:50.030]  key, what we'll do is we will have the client provide us that key and create that hash in
[22:50.030 --> 22:56.550]  either an NTLM or an MD5, and then run it against our rule sets and our word list to then
[22:56.550 --> 23:01.750]  demonstrate the impact to that client that says, hey, you know, we didn't have enough time to
[23:01.750 --> 23:07.530]  crack the WPA2 while we were on site. However, we would have cracked it. So, you know, if you
[23:07.530 --> 23:12.030]  have somebody sitting in your parking lot and they capture, they could potentially come back
[23:12.030 --> 23:19.910]  and get into your network that way. And this is, you know, how we did it. So that's one way to
[23:19.910 --> 23:33.130]  kind of work with your clients. So where do you get hashes? You know, always looking for hash dumps.
[23:33.130 --> 23:38.990]  If you can get onto a Linux box and you have root access and you can dump Etsy shadow,
[23:38.990 --> 23:45.390]  comp files are always great. Back-end databases that you can get into.
[23:45.390 --> 23:52.770]  Mimikatz if you encounter like an older Windows system that's not fully patched. Web applications
[23:53.250 --> 24:00.770]  a lot of times will expose hashes, you know, either via misconfigurations or just having
[24:00.770 --> 24:07.370]  their database exposed. We run a lot of Responder or Magnum Metal 6 on internal gigs. I'll do a
[24:07.370 --> 24:14.190]  demo of that in a little bit. DC sync and NTDS, you know, these are some of the common ways to
[24:14.190 --> 24:23.150]  find hashes. There's thousands of ways to find hashes. You know, if you're on a wireless gig
[24:23.150 --> 24:29.010]  and you capture a pre-shared key handshake, you can open up Wireshark and get the PSK
[24:29.010 --> 24:34.450]  hash out of there. There are just many, many different ways to get hashes. These are some
[24:34.450 --> 24:40.690]  good ways to start if you're kind of looking to get into it. I would highly recommend kind of
[24:40.690 --> 24:48.550]  building a local lab, setting up Responder on your local lab or setting up a database,
[24:48.550 --> 24:54.910]  making some hashes, and then just going ahead and trying to crack them. You can also just
[24:54.910 --> 25:03.830]  create a bunch of, you know, NTLM hashes or MD5 hashes via some scripts. So, make a bunch
[25:03.830 --> 25:09.810]  of passwords that you know and test it out in Hashcat. So, that's a good way to get started.
[25:12.010 --> 25:18.330]  So, developing a methodology. So, this is really where our password audit kind of came out of.
[25:18.790 --> 25:24.850]  So, we wanted to create a repeatable process for other people on our team to be able to follow
[25:24.850 --> 25:32.850]  and make it as easy as possible for a new consultant to just kind of get spun up and start
[25:32.850 --> 25:39.930]  working. These are going to be much more analysis based than, you know, hands on the keyboard.
[25:39.930 --> 25:46.450]  This is going to be a lot of, you know, letting the cracker run, using your various rules and
[25:46.450 --> 25:52.450]  masks and all of the stuff that we've discussed previously. Looking at the results and kind of
[25:52.450 --> 25:56.910]  figuring out where you want to go from there. Looking at what their hashes are doing, looking
[25:56.910 --> 26:03.470]  at what the passwords they're using are. Are they a secure company? Are you seeing, you know,
[26:03.630 --> 26:08.890]  a lot of crazy hashes that, you know, you're not able to crack? Or are you seeing a lot of,
[26:08.890 --> 26:15.550]  like, really simple passwords? The other thing we're going to look for is, you know, common words,
[26:15.550 --> 26:22.810]  easy wins. Again, I keep coming back to summer 2020, password one, company name. Company name
[26:22.810 --> 26:30.830]  and the date that it was founded is a really popular one. Street names. If you're in an area,
[26:30.830 --> 26:37.730]  if you're doing a client and there's, you know, a local sports team, you know, I'm from Ohio,
[26:37.730 --> 26:44.450]  so in my area, you know, you can find a lot of Ohio State or Buckeye-related passwords. You know,
[26:44.450 --> 26:50.630]  you could extrapolate that across the country. You know, New England, you could do Patriots or
[26:50.630 --> 26:59.450]  whatever. A lot of... we'll find a lot of times clients will do... will claim that they do their
[26:59.450 --> 27:04.390]  own password audits, but they're not really doing it effectively. You know, they might
[27:04.950 --> 27:11.770]  run Hashcat with like a base word list or like a Rocky or something like that and say that they
[27:11.770 --> 27:18.290]  covered it. You really, for these enterprise engagements, you need heavy-hitting cracking
[27:18.290 --> 27:24.630]  rigs, either built in-house or setting up the cloud. And I would say even just one Amazon
[27:25.950 --> 27:31.730]  P316 is not going to really, you know, pass muster for this. You're going to want to throw
[27:32.590 --> 27:40.450]  a good amount of resources at these, especially if you're talking, you know, 20,000 or more,
[27:41.330 --> 27:44.210]  you know, passwords that you're trying to recover.
[27:48.230 --> 27:56.130]  So what do we do? Again, we go for quick wins. So we run... internally we have some proprietary
[27:56.130 --> 28:02.630]  word lists that we use. It's kind of been tweaked over the years. It has
[28:04.270 --> 28:09.670]  a lot of data from all the different breaches where we've extrapolated common base words,
[28:09.670 --> 28:15.950]  things like that. And we'll run those without rules. And then we will slowly start adding
[28:15.950 --> 28:21.570]  things that increase the time of cracking, but also increase your possibility of cracking more
[28:21.570 --> 28:32.070]  passwords. So we will continue to run newer and newer attacks against the same list of hashes.
[28:32.270 --> 28:38.070]  And, you know, as you'll see in a second, it's kind of the law of diminishing returns. But
[28:38.070 --> 28:47.150]  as we move through the process, we tend to be pretty successful. We do in-house, we have the
[28:47.150 --> 28:53.930]  capability to do a 1-8 character brute force. That takes about 24 hours on our internals crackers.
[28:54.170 --> 29:00.730]  So we can brute force the entire NTLM keyspace within a day. So that's usually about the first
[29:00.730 --> 29:07.510]  day of a password engagement. And then we will run our words, our word lists, and then our rules
[29:07.510 --> 29:16.970]  against things after. You know, we will then use either PWSpy to create different masks,
[29:16.970 --> 29:23.110]  or just use common masks, things like that. And, you know, just kind of moving on and
[29:23.110 --> 29:28.130]  doing more and more advanced attacks as we get closer to the end of the engagement.
[29:29.310 --> 29:34.870]  So this is sort of what, this is actually real data, and this is what our password recovery
[29:34.870 --> 29:42.290]  over time looked like on a recent password assessment. So as you can see, you know, within
[29:42.850 --> 29:48.530]  the first few hours, we cracked the majority of the passwords we were going to crack. And
[29:48.530 --> 29:58.870]  as we moved through, you can see the longer password recovery attempts did yield less results.
[29:58.870 --> 30:07.730]  But out of, I believe this was over, this was about 18,000 passwords, or hashes that we were
[30:07.730 --> 30:15.990]  trying to crack, and we cracked almost 14,000 of them, which is pretty good. You know, that's,
[30:16.710 --> 30:22.570]  that was enough to show an impact to the client. And this is, you know, over about two weeks of
[30:22.570 --> 30:26.710]  letting the crackers run and then doing a lot of that analysis on the back end and tweaking the
[30:26.710 --> 30:35.290]  rules to match what we were seeing. So how to help your future self. This is really important.
[30:35.290 --> 30:42.150]  So you want to have your POP files. We'll typically separate out POP files based on
[30:43.450 --> 30:49.790]  clients, but we also keep a master POP file. That's a historical record of your cracked hashes.
[30:49.790 --> 30:53.650]  It's useful to see if you've already cracked that hash on another engagement. So if you're
[30:53.650 --> 30:59.090]  seeing summer 2020, you're not going to burn cycles trying to crack it again. We'll just try
[30:59.090 --> 31:05.270]  that hash. This obviously doesn't work against salted hashes, but it will work against, you know,
[31:05.270 --> 31:14.250]  NTLM or any of the, you know, MD5 or things like that. Do be really careful about bloat. It can
[31:14.250 --> 31:21.110]  slow down the hash, the process, because it's going to check it against the existing POP file.
[31:21.110 --> 31:28.310]  So for instance, we did have a pretty overzealous analyst on the team who decided to add the
[31:28.310 --> 31:39.490]  entirety of the LinkedIn dump into our POP file. And at the time of the dump, LinkedIn did not have
[31:39.490 --> 31:43.690]  any password restrictions. So you had a lot of four-character passwords or just plain text
[31:43.690 --> 31:51.090]  passwords, which is pretty useless against, you know, enterprise networks that are running either,
[31:51.090 --> 31:55.230]  or 12-character with complexity. So you do want to be careful of that,
[31:55.230 --> 31:59.910]  because you're going to be running each hash against that POP file. And again,
[31:59.910 --> 32:07.670]  you're going to be burning CPU cycles on that. Common masks. So we keep a list of in-house tools
[32:08.430 --> 32:15.630]  that includes the masks that we can copy in to our hashcat commands, as well as creating new masks
[32:15.630 --> 32:23.730]  as we see fit on the engagements. But, you know, the common ones, you know, uppercase letters
[32:24.490 --> 32:30.370]  at the beginning, and then trailing lowercase letters with digits at the end.
[32:32.570 --> 32:36.270]  So now we're going to move into a demo. I'm going to show you sort of
[32:36.270 --> 32:41.390]  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:03.100]  So what I've done is I have set up a domain controller, a firewall appliance, a Kali machine,
[33:03.100 --> 33:11.300]  and a Windows 10 machine. 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:33.560]  Obviously Kali, which is going to be our attacking machine, and then the WinEval
[33:33.560 --> 33:51.110]  is going to be your Windows 10 simulating a client computer. Okay, so closing that out.
[33:51.950 --> 33:57.090]  We just want to verify once again that we are on the same network so we can see
[33:58.510 --> 34:05.990]  both of these hosts are actually networked together on the same subnet. So we'll go ahead
[34:05.990 --> 34:16.350]  and start up Responder here. So when you start up Responder, you have to feed it the interface
[34:16.350 --> 34:26.450]  that you're using. So what Responder is doing is poisoning the LL, MNR, and NBTNS requests that
[34:26.450 --> 34:32.990]  Windows machines will set out. This happens if Windows can't resolve a hostname using DNS.
[34:32.990 --> 34:39.890]  It will send broadcast traffic out asking for that information. So Responder kind of
[34:39.890 --> 34:48.530]  into the middle between a domain controller and the Windows machine and will
[34:50.790 --> 34:58.670]  respond with the information that they're requesting. But it will then ask that Windows
[34:58.670 --> 35:06.590]  machine to send its authentication to it, which the Windows machine will provide, and then Responder
[35:06.590 --> 35:11.810]  will capture those hashes. You can usually accomplish this by trying to access something
[35:11.810 --> 35:18.390]  that doesn't exist, such as file share does not exist or something like that
[35:18.390 --> 35:26.390]  inside your network libraries. And that should be sufficient to generate the LL, MNR broadcast
[35:26.390 --> 35:35.330]  traffic. And we'll see an example of that here. So I open up the folders and I go to server does not
[35:35.330 --> 35:42.050]  exist. And you can see the poison answers are being sent and we're capturing NTLMv2 hashes.
[35:42.050 --> 35:49.770]  Now this is important. As we start capturing the NTLMv2 hashes, you'll see there are multiple
[35:49.770 --> 35:56.010]  hashes being captured. These are actually the same hash just due to the nature of NTLMv2.
[35:56.010 --> 36:04.090]  They are salted so you will receive multiple hashes. When you are going to crack these
[36:04.570 --> 36:13.150]  hashes, what you'll want to do is take one hash per username. That way you're not
[36:13.150 --> 36:20.030]  spending excess time trying to crack the same hash for a user that you've already cracked or
[36:20.030 --> 36:25.330]  for a user that you're not going to be able to crack. So once we've got that hash, we can just
[36:25.330 --> 36:36.290]  copy it over into a text file, which I do here. So you can see I drop it into hash.txt and you
[36:36.290 --> 36:48.010]  could do this for as many of the usernames and passwords that you capture. Hopefully you get
[36:48.010 --> 36:53.370]  something juicy. Sometimes you'll be able to get DA creds or things like that.
[36:54.130 --> 37:00.310]  Okay, so now that we've got hash.txt created, we're going to go ahead and start up
[37:00.310 --> 37:09.750]  HashCat. So NTLMv2 hashes are mode 5600. So to accomplish that in HashCat, you feed it the
[37:09.750 --> 37:19.550]  TACM flag and then 5600. Then you feed it the file name. And then in this particular example,
[37:19.550 --> 37:25.910]  we're using a little bit of a contrived example just for brevity. So we're going to use
[37:25.910 --> 37:34.530]  fasttrack.txt because I happen to know that this particular password for this user,
[37:35.230 --> 37:41.670]  again, because I've created the lab, will be in that. Now, if this is a live gig,
[37:41.670 --> 37:51.290]  that's where you're going to feed some of the more advanced masks or rules or definitely stronger
[37:51.290 --> 37:57.590]  word lists, things like that. But you can always start with the quick and easy ones, and maybe
[37:57.590 --> 38:04.670]  you'll get lucky. And if you do, that's awesome. You haven't spent a lot of time. However, if you
[38:04.670 --> 38:12.670]  do need to use those heavier lists, please feel free to. And definitely use the masks and such
[38:12.670 --> 38:26.450]  that you've got working. So we start a HashCat here, again, using the mode 5600.
[38:27.430 --> 38:37.070]  And then we feed it the hash.txt that we created. And then we go ahead and feed it the
[38:37.630 --> 38:44.210]  particular word list, which in this case, again, is stored as user share word list. And then we're
[38:44.210 --> 38:53.430]  just using the fasttrack.txt. Once HashCat starts, again, this particular Kali instance isn't hooked
[38:53.430 --> 39:01.190]  up to my GPU box. So you'll get some warnings for OpenCL and things like that. But you'll see
[39:01.190 --> 39:09.410]  the warnings come through. And then just because I know that this works really quickly,
[39:09.410 --> 39:16.750]  you'll see that this cracks. And you can see password1 is our cracked password.
[39:16.910 --> 39:26.750]  Now, if we were cracking multiple passwords, or take longer, you would see those in your
[39:26.750 --> 39:35.210]  POP file. You can also create a new POP file by doing dash dash POP file dash path equals,
[39:35.210 --> 39:42.850]  and then name your POP file whatever you want. And that will create a POP file specifically for
[39:42.850 --> 39:50.490]  that particular session with HashCat. That's useful if you're running an engagement for a
[39:50.490 --> 39:54.830]  particular client, and you wanted to separate out the hashes that you've cracked from them
[39:55.390 --> 40:00.990]  versus the other engagements that you've worked.
[40:04.200 --> 40:13.040]  So you can see here, as the hash is cracked, it will append the password to the end of the
[40:13.040 --> 40:19.440]  hash file, which will be the exact same way it's presented in the POP file as well.
[40:22.900 --> 40:32.720]  So now that we've got our password, we can then go ahead and use those credentials to go
[40:32.720 --> 40:41.580]  and log in via Windows doing any particular thing that we might want to do.
[40:44.110 --> 40:50.030]  Okay, so with a little bit of time that we have left, I'd like to do a quick demo of PWSpy,
[40:50.030 --> 40:58.630]  as it's kind of a new tool that I've developed. And it was originally released during 6.14 con
[40:58.630 --> 41:06.450]  2019. However, it's gone through some pretty major changes. And I'm happy to announce that
[41:07.130 --> 41:13.930]  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:23.510]  So again, this was an internal tool developed mostly to help us deal with the massive amount
[41:23.510 --> 41:32.870]  of information coming from the enterprise password audits. So the intention was that
[41:32.870 --> 41:39.150]  you would take a POP file that you've created specifically for your particular client,
[41:39.850 --> 41:47.370]  or engagement, and then you would feed that as well as the initial hash list
[41:47.370 --> 41:53.390]  that you fed into Hashcat. And it would do the analysis for you.
[41:54.470 --> 41:59.410]  That's pretty much been accomplished. There's still a few more bugs and things that I'd like
[41:59.410 --> 42:08.070]  to tweak. However, let's get into it. For this particular demo, I went ahead and grabbed some
[42:08.070 --> 42:14.190]  passwords that we've seen in some of the public dumps that are out there. And I went ahead and
[42:14.190 --> 42:21.070]  created some NTLM hashes using those passwords and cracked them using the Optive Cracker to generate
[42:21.070 --> 42:29.050]  the POP file for this demo. So that's what you're going to see here. So I'll go ahead and open
[42:29.050 --> 42:39.210]  demo.pot. As you can see, these are just some common passwords, and they've already been cracked.
[42:39.210 --> 42:48.170]  So it's time to do the post session analysis on that. So we're going to go ahead and feed this
[42:48.170 --> 43:02.990]  file into pwspy. Now, pwspy, if you open up the help options, you'll see that you can feed it both
[43:03.230 --> 43:08.870]  a POP file and a hash list. The hash list is actually optional. You don't have to add that.
[43:08.870 --> 43:18.370]  As well as inside the Python script, you can turn on and off individual modules simply by commenting
[43:18.370 --> 43:25.170]  them out in the calls. Those are down at the bottom of the script, and I'll show you that
[43:25.170 --> 43:36.350]  towards the end of this demo. So in this particular case, because we're using publicly
[43:36.990 --> 43:42.690]  available passwords, and we haven't cracked a bunch from a particular company, so there's not
[43:42.690 --> 43:51.850]  going to be any reuse, there's really no sense in doing the hash list as well. So we're not going to
[43:52.510 --> 43:57.410]  feed that in. As well as some of the modules may not work because there's just not enough data,
[43:57.410 --> 44:04.730]  such as the mask builder, and definitely the password reuse won't work because you need to
[44:04.730 --> 44:15.190]  feed that the hash list. So we'll go ahead and run pwspy, and we'll take a look at the output.
[44:20.060 --> 44:27.540]  So you can see here, the output is a pretty standard script output, complete with the
[44:28.480 --> 44:34.340]  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:06.760]  common base words, and the number of times that we've seen those, as well as
[45:07.960 --> 45:14.640]  there would be a password reuse, and the masks would go there as well,
[45:14.640 --> 45:17.820]  which would help you if you were going to do further attacks against
[45:17.820 --> 45:26.880]  this client. 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:42.060]  So you can see all these passwords were cracked and consist of only letters and no numbers or
[45:42.060 --> 45:47.540]  special characters of any sort. You can always make this more restrictive or less restrictive
[45:48.120 --> 45:54.700]  by editing the Python script. One of the goals for the future is to add options
[45:55.360 --> 46:03.560]  to define what a weak password would be. And then the last thing that it will do
[46:03.560 --> 46:09.660]  is check the lengths of all the passwords that you have cracked. And as you can see,
[46:10.200 --> 46:16.480]  it splits those out and gives you the number of occurrences. So there were a lot of 9-character
[46:16.480 --> 46:22.860]  passwords, some 10-character passwords. This really becomes helpful if you are
[46:23.900 --> 46:30.660]  doing, again, an engagement, and let's say the client says that they've got a 12-character
[46:30.660 --> 46:36.320]  password policy. And you can go ahead and check against that and make sure that you didn't
[46:36.320 --> 46:44.160]  capture any passwords that might not fit that policy, as well as if you're going to build
[46:44.160 --> 46:52.640]  your custom masks that might not be output by this tool, you would be able to use the
[46:52.640 --> 47:01.160]  the password length to help you generate those masks as well.
[47:03.490 --> 47:10.630]  So the last thing I wanted to touch on with PWSpy is just kind of taking a quick look
[47:10.630 --> 47:15.150]  at the source code and showing where you would turn on and off those modules.
[47:15.730 --> 47:29.420]  So if we cap the file here, you can see that all of the function calls are down here at the bottom,
[47:29.420 --> 47:37.340]  which I'm highlighting here. And from there, what you can do is go ahead and comment out any of
[47:37.340 --> 47:43.760]  those different modules, and it will not run those. So if you didn't particularly want to run
[47:43.760 --> 47:49.880]  the mask builder, or check for weak passwords, or password length for whatever reason,
[47:49.880 --> 47:54.420]  you could go ahead and comment that out. Again, this is an open source tool.
[47:54.420 --> 48:05.540]  Please feel free to fork and edit it as you see fit. And I hope that this proves helpful to
[48:05.540 --> 48:11.280]  somebody or anybody if you are doing especially large password assessments.
[48:17.310 --> 48:22.230]  I'd like to thank you for taking the time to listen to today's talk. There's been a lot of
[48:22.230 --> 48:27.310]  great talks here at the Red Team Village, and it looks like there's a few more after me. It's been
[48:27.410 --> 48:35.350]  a great DEF CON, despite it being remote. At this time, I would like to just once again reiterate
[48:35.350 --> 48:44.350]  that password cracking methodology is more of a comprehensive approach than a one-size-fits-all.
[48:44.350 --> 48:50.910]  There are many different ways and approaches to cracking passwords, and what works for one person
[48:50.910 --> 48:59.350]  may not work for everybody. So keep that in mind, as well as always remember that password cracking
[48:59.350 --> 49:07.370]  is, again, not a one-size-fits-all. You're not going to be able to do this by just scripting
[49:07.370 --> 49:14.190]  everything. You definitely need to do that deep dive analysis and really think about what you're
[49:14.190 --> 49:21.810]  after and use that to guide the way that you go after your passwords in the future.
[49:22.550 --> 49:31.410]  Hopefully you have taken something away from this talk, and I will be in the Red Team Village
[49:31.410 --> 49:41.010]  Discord for any questions. I'm HX50 in there, as well as on Twitter. You can find me at HX underscore
[49:41.010 --> 49:49.410]  50. And once again, I would highly encourage you to go ahead and try some of these techniques out
[49:49.410 --> 49:59.210]  on your own. Go ahead and create hashes, set up a lab, and go ahead and crack your own stuff.
[50:00.810 --> 50:08.950]  I will release the instructions on how to set up my lab, as well as possibly setting up
[50:09.870 --> 50:17.310]  just OVA files that you can download, as well as you can go on GitHub and
[50:18.150 --> 50:27.630]  feel free to grab pwspy if you so choose. You can find that at github.com slash lwangenheim
[50:29.690 --> 50:36.050]  slash pwspy. And obviously, that's quite a mouthful to try and spell.
[50:36.050 --> 50:42.530]  So if you do want to try and find it and Google doesn't help, feel free to reach out to me. I'm
[50:42.530 --> 50:48.150]  more than happy to either just provide you the link, or I can just send you the files directly.