[00:03.800 --> 00:06.840]  Let's see, how do we do the screen share on this?
[00:42.300 --> 00:43.340]  Ah, here we go.
[00:51.160 --> 00:54.180]  Okay, there we go. That's looking a lot better.
[00:54.500 --> 00:57.020]  All right, so welcome to Advanced HashCat Training.
[00:57.660 --> 01:01.540]  A quick note about who I am. I am staff here at the DEF CON Password Village.
[01:01.560 --> 01:04.160]  I am a member of the HashCat Dev Team and Team HashCat.
[01:04.300 --> 01:06.640]  I am the founder and CEO of Terrahash.
[01:06.640 --> 01:09.780]  And I'm also a password hashing competition judge.
[01:09.780 --> 01:12.380]  My name is Jeremy Gosney. I go by the Nick episode.
[01:14.900 --> 01:19.260]  All right, so number one, let's talk about entropy.
[01:20.020 --> 01:22.980]  In the password-cracking world, we don't really talk about entropy.
[01:22.980 --> 01:25.560]  We don't express password strength in terms of entropy.
[01:26.240 --> 01:29.480]  You know, in academic settings or when we're talking about, like,
[01:29.480 --> 01:34.160]  symmetric key encryption and such, you know, you'll hear, you know,
[01:34.160 --> 01:39.860]  this key has X bits of entropy or, you know, that password has 32 bits of entropy.
[01:39.860 --> 01:41.860]  We don't give a fuck about that as password crackers.
[01:41.860 --> 01:46.040]  As password crackers, what we care about is keyspace.
[01:46.400 --> 01:49.240]  Keyspace is the total number of combinations for an attack.
[01:49.240 --> 01:52.340]  It is essentially a measure of the level of effort for our attack.
[01:53.780 --> 01:56.920]  To calculate the keyspace for a dictionary attack,
[01:56.920 --> 01:59.080]  it's simply the number of words in a word list.
[01:59.620 --> 02:04.040]  For a dictionary and rule-based attack, it is the number of words in the word list
[02:04.040 --> 02:06.760]  multiplied by the number of rules in the word file.
[02:07.680 --> 02:11.460]  For a combinator attack, you multiply the keyspace of each dictionary,
[02:11.460 --> 02:13.960]  so the number of words in the first dictionary
[02:13.960 --> 02:16.780]  multiplied by the number of words in the second dictionary.
[02:17.720 --> 02:22.080]  And for a mask attack, you multiply the number of possible characters
[02:22.080 --> 02:23.680]  in each mask position together.
[02:23.680 --> 02:27.780]  And we'll get into exactly what that looks like and what that means.
[02:31.320 --> 02:35.200]  Oh, and for hybrid, of course, it's the keyspace of the word list,
[02:35.200 --> 02:38.940]  the number of words in the word list multiplied by the keyspace of the mask.
[02:40.340 --> 02:42.220]  So, keyspace examples.
[02:42.760 --> 02:46.480]  rocku.txt has 14.3 million words.
[02:46.940 --> 02:50.860]  best64.rule has 102 rules in the rule file,
[02:50.860 --> 02:54.760]  which is kind of a misnomer. It's not really best64. It's more like best102.
[02:55.040 --> 02:57.740]  So we multiply 14.3 million by 102 rules,
[02:57.740 --> 03:01.260]  gives us a keyspace of 463 billion.
[03:01.340 --> 03:04.380]  That is the total number of combinations that you need to hash
[03:06.620 --> 03:10.730]  when you combine rocku.txt with best64.rule.
[03:11.840 --> 03:17.300]  Let's say we were to do a combinator attack of rocku.txt plus rocku.txt.
[03:17.480 --> 03:22.760]  That would be 14.34 million words times 14.34 million words
[03:22.760 --> 03:28.630]  equals 205 quadrillion possible combinations for that keyspace.
[03:29.710 --> 03:35.030]  So our second attack, the combinator attack, requires 140,000 times more effort
[03:35.030 --> 03:36.410]  than the first attack.
[03:37.570 --> 03:39.750]  Now let's look at how we calculate keyspace for masks.
[03:39.750 --> 03:46.050]  I said that mask was the total of each character in each position, right?
[03:46.050 --> 03:48.630]  So we have 26 lower letters in all six positions.
[03:48.630 --> 03:52.090]  Our keyspace is 26 to the power of 6.
[03:52.370 --> 03:56.930]  That gives us a keyspace of 8 billion.
[03:57.710 --> 03:59.850]  Now let's look at this mask.
[03:59.850 --> 04:02.830]  We have special digit lower uppercase digit.
[04:03.510 --> 04:07.890]  So there's 33 possible special characters multiplied by 10 digits
[04:07.890 --> 04:09.910]  multiplied by 10 possible lowercase characters
[04:09.910 --> 04:12.250]  multiplied by 26 possible uppercase characters
[04:12.710 --> 04:21.770]  multiplied by 10 digits gives us a keyspace of 2.2 billion.
[04:24.600 --> 04:27.710]  All right, so let's look at using custom character sets.
[04:29.490 --> 04:34.870]  So in our custom character set, we have the lowercase and a digit.
[04:34.870 --> 04:37.810]  So 26 plus 10 is 36 custom characters.
[04:37.810 --> 04:43.490]  And then we have 5 lowercase letters.
[04:43.490 --> 04:45.290]  So 26 to the 5th.
[04:45.290 --> 04:47.630]  And then 2 digits is 10 to the 2.
[04:47.630 --> 04:52.510]  Gives us a total keyspace of 11.8 trillion.
[04:52.890 --> 04:54.930]  Sorry, billion. 11.8 billion.
[04:56.310 --> 04:58.330]  Same thing if you have two custom character sets.
[04:58.330 --> 05:01.510]  Our first custom character set, we have a lower and a digit.
[05:01.850 --> 05:04.630]  Our second custom character, we have a digit and a special.
[05:05.190 --> 05:07.190]  So the math, of course, is very similar.
[05:07.650 --> 05:09.990]  So we have 36 in our custom character set 1
[05:10.470 --> 05:13.950]  multiplied by 26 to the 5th for our lower digits in our mask
[05:15.150 --> 05:17.050]  multiplied by 10 possible digits
[05:18.330 --> 05:23.150]  and then 43 in our second custom character set
[05:24.470 --> 05:27.910]  for a total of 183 billion possible combinations.
[05:29.790 --> 05:31.370]  So let's kind of shelve that real quick
[05:31.370 --> 05:33.510]  and let's kind of pivot and talk about hash rate.
[05:33.510 --> 05:35.610]  Hash rate is a measure of distance over time
[05:35.610 --> 05:39.170]  and is expressed as a number of hash calculations per second.
[05:40.250 --> 05:43.270]  The hash rate depends on several variables, of course, like the hardware.
[05:43.270 --> 05:45.370]  Are we using CPU? Are we using GPU?
[05:45.370 --> 05:48.530]  Are we using an older GPU? Are we using a newer GPU?
[05:48.990 --> 05:53.770]  The hash algorithm itself plays a big part in the hash rate.
[05:54.050 --> 05:56.870]  Some hashes are stupid fast like MD4 and MD5.
[05:56.870 --> 06:00.070]  Others are brutally slow like Bcrypt and Scrypt.
[06:00.750 --> 06:04.250]  The attack mode also plays a big part in our hash rate.
[06:05.190 --> 06:09.050]  Brute force is going to be faster than a wordless attack, for example.
[06:09.970 --> 06:13.210]  The way the attack is structured, we will get into GPU acceleration
[06:13.470 --> 06:15.250]  a little bit later in the slide deck,
[06:15.250 --> 06:17.850]  but basically the way you structure your attack
[06:18.410 --> 06:21.550]  can negatively or positively impact performance.
[06:22.830 --> 06:25.990]  And, of course, the key space for the attack also plays a part in hash rate.
[06:25.990 --> 06:29.030]  If the key space is too small for GPU acceleration,
[06:29.030 --> 06:31.110]  you will not have a very high hash rate.
[06:31.970 --> 06:33.550]  And also the number of hashes.
[06:33.550 --> 06:37.930]  This has more to do with the amount of RAM or video RAM that you have.
[06:37.930 --> 06:42.450]  If you have an inordinately large number of hashes,
[06:42.450 --> 06:46.050]  it will affect the hash rate.
[06:47.170 --> 06:51.550]  So the best case scenario for HashCat is single hash brute force.
[06:52.350 --> 06:57.450]  With single hash brute force, you will get the absolute highest speed for each algorithm.
[06:58.790 --> 07:01.250]  Once you get into multi-hash brute force,
[07:01.250 --> 07:03.350]  the speed is going to drop by about 25%.
[07:05.250 --> 07:08.010]  Once you start doing single hash dictionary and rules,
[07:08.010 --> 07:11.650]  it's going to be about 50% slower than single hash brute force.
[07:13.270 --> 07:16.770]  Multi-hash dictionary and rules is going to be about 75% of the speed
[07:16.770 --> 07:18.730]  of a single hash brute force attack.
[07:18.830 --> 07:23.630]  So you can see how the attack itself actually plays a large part in the hash rate.
[07:24.590 --> 07:29.090]  Now I mentioned that some hash algorithms are faster than others.
[07:30.290 --> 07:33.330]  Fast hash algorithms like MD4, MD5, SHA1, SHA2,
[07:33.330 --> 07:38.610]  and even DEScrypt now with BitSlice DES on GPU,
[07:38.610 --> 07:41.810]  I would definitely consider to be a fast hash these days.
[07:42.470 --> 07:48.590]  Medium fast hashes would be things like MD5Crypt, Kerberos, and macOS hashes.
[07:49.490 --> 07:51.750]  And then, of course, we have the very slow hash algorithms.
[07:51.750 --> 07:57.930]  A lot of these have custom iteration counts, cost variables.
[07:57.930 --> 08:00.550]  So these can actually be made to be somewhat fast,
[08:00.550 --> 08:04.390]  but most of the time these are going to use settings that are going to be very painfully slow.
[08:06.750 --> 08:08.350]  And here's an example of that.
[08:08.350 --> 08:13.630]  This is a chart that just very quickly will visualize which algorithms we consider to be fast.
[08:14.470 --> 08:16.610]  And then kind of a medium fast here.
[08:17.330 --> 08:20.450]  And then, of course, the really painfully slow ones down here at the bottom.
[08:24.380 --> 08:29.020]  All right, so let's look at how hash rate and keyspace interact with each other
[08:29.020 --> 08:32.280]  because this is really important for when you start structuring advanced attacks.
[08:33.360 --> 08:38.460]  Mainly because we want to know, if we go to run an attack, is this a worthwhile attack to run or is it not?
[08:38.460 --> 08:42.020]  And, of course, Hashcat will tell you, like, yeah, you know, this is going to take a decade to run.
[08:42.240 --> 08:46.700]  But as a password cracker, you should kind of have a sense for what that's going to look like
[08:46.700 --> 08:49.240]  in advance of actually starting your attack.
[08:50.420 --> 08:51.960]  So let's look at the following example.
[08:51.960 --> 08:56.180]  We have a single hash NTLM brute force here.
[08:56.980 --> 09:02.140]  Sorry, the command here doesn't actually say single hash, but let's pretend that there is a single hash there.
[09:02.780 --> 09:11.580]  So four RTX 2080 TIs can pull about 380 billion hashes per second on single hash NTLM brute force.
[09:11.680 --> 09:16.280]  And, of course, our mask here has a keyspace of 95 to the 8th.
[09:20.210 --> 09:26.290]  So the math, 95 to the power of 8 divided by our 380 giga hash a second
[09:26.290 --> 09:35.410]  means that this attack will take us about 17,458 seconds or about 4.77 hours.
[09:35.410 --> 09:39.090]  So this attack will complete in under five hours, which is likely acceptable to you.
[09:39.190 --> 09:41.870]  Now let's add a character to our mask.
[09:42.490 --> 09:48.950]  Keyspace increases to 95 to the 9th at the same speed of 380 giga hash a second.
[09:48.950 --> 09:58.170]  This attack will now take us 1.6 million seconds to complete, which is a little over 19 days.
[10:00.930 --> 10:01.890]  Sorry.
[10:02.970 --> 10:07.990]  So at this point, you understand how to calculate keyspace, you understand fast versus slow hash algorithms,
[10:07.990 --> 10:11.130]  and you understand the relationship between the keyspace and the hash rate.
[10:11.170 --> 10:13.730]  But how do we actually leverage this to our advantage?
[10:15.970 --> 10:19.110]  To do that, let's talk about base and mod.
[10:24.790 --> 10:25.670]  GPU acceleration...
[10:26.830 --> 10:27.930]  Excellent, I skipped a slide there.
[10:28.790 --> 10:35.310]  So to achieve GPU acceleration, we have two concepts in HashScout called the base loop and the mod loop.
[10:35.390 --> 10:40.950]  The base loop gets executed on the host CPU and the mod loop gets executed on the GPU devices.
[10:44.370 --> 10:50.190]  If the mod loop is too small or if it's completely non-existent, you will not gain GPU acceleration on fast hash algorithms.
[10:50.190 --> 10:58.830]  This means that while your GPUs may be capable of doing the 380 billion hashes per second like you saw in the previous examples,
[10:58.830 --> 11:02.910]  they will not do so if the mod loop is too small.
[11:02.910 --> 11:08.050]  You will get no GPU acceleration, your hash rate will be abysmal down in the single digit kilohash a second.
[11:09.370 --> 11:14.850]  And we absolutely want GPU acceleration. That's kind of the entire point of GPU password cracking.
[11:16.790 --> 11:24.230]  So if you do a straight dictionary attack on GPU with no rules, then you have a base loop which is the dictionary,
[11:24.230 --> 11:28.910]  but you have no modifier whatsoever. You will not get GPU acceleration with this attack.
[11:28.910 --> 11:33.010]  It will be abysmally slow. It will actually be faster on CPU than on GPU.
[11:33.770 --> 11:39.630]  The second example here, where we're using the same dictionary, but now we're adding a modifier, rules.
[11:41.210 --> 11:48.010]  The words will be looped over from Rocky.txt on the CPU, but then the rules will be applied in the onGPU rule engine
[11:48.690 --> 11:53.330]  on each of the GPU devices, and that's where our GPU acceleration comes from.
[11:54.010 --> 12:00.630]  So the more rules you have, the more GPU acceleration you're going to gain to a point.
[12:01.490 --> 12:08.570]  I believe the tipping point there is somewhere around... well, last I looked, it was probably 50,000 rules.
[12:08.570 --> 12:11.710]  It may be a little bit higher now with larger VRAM values.
[12:14.010 --> 12:21.570]  But 30,000 to 50,000 rules is kind of the sweet spot for achieving maximum GPU acceleration with a rule-based attack.
[12:23.530 --> 12:29.590]  For a combinator attack, the base loop is going to be the inner dictionary, while the mod loop is going to be the outer dictionary.
[12:29.590 --> 12:37.650]  And then for mask attacks, it's kind of interesting, because the mask itself doesn't have any kind of obvious split like a combinator or rule-based attack does.
[12:37.910 --> 12:43.670]  So what Hashcat actually does internally is it's going to split the mask into two parts.
[12:43.670 --> 12:47.770]  So the first half is going to be the base loop, while the second half of the mask is going to be the mod loop.
[12:51.300 --> 12:57.080]  And then for hybrid attacks, again, it's pretty straightforward because it's actually logically separated in the command itself.
[12:57.080 --> 13:00.820]  The base loop is the dictionary, and the mask is the mod for A6.
[13:00.820 --> 13:04.540]  Then for A7, it's the reverse. The mask is the mod, and the dictionary is the base.
[13:05.960 --> 13:08.280]  So let's look at this in an applied example.
[13:08.420 --> 13:15.360]  So we have the same single hash NTLM brute force command that we had from the previous slides.
[13:16.980 --> 13:20.420]  Hash rate is still, let's say, 380 gigahash a second.
[13:20.420 --> 13:23.400]  Our keyspace is still 95 to the 9th.
[13:24.480 --> 13:33.000]  So per our previous math, this will take 1.6 million seconds to complete, which again is a little bit over 19 days.
[13:33.000 --> 13:38.280]  But let's say we don't want that to take 19 days. Let's say we want this attack to complete in 8 hours.
[13:40.140 --> 13:43.800]  So 8 hours is about 29,000 seconds.
[13:44.240 --> 13:49.900]  So what we're going to do is we say our hash rate is 380 billion hashes per second.
[13:49.900 --> 13:53.720]  And we want to let it run for a little over 29,000 seconds.
[13:53.720 --> 14:00.600]  So we simply multiply that to find out the number of hash calculations that we can make with our 4 2080 TIs in that amount of seconds.
[14:00.600 --> 14:10.740]  And that gives us 11.1 quadrillion guesses in 8 hours with this attack.
[14:11.180 --> 14:13.980]  So now we sit here and we flip it around.
[14:13.980 --> 14:25.380]  We want to find out what we need our base loop to look like to hit that 8 hour target.
[14:25.380 --> 14:33.600]  So right now with the mask of question mark A, the base is 95 for each character set.
[14:33.600 --> 14:40.980]  But if we take this 11.1 quadrillion and we raise it to the 1 over 9th power, we get 60.
[14:40.980 --> 14:50.420]  And what we can do with that is HashCat, for anywhere you're using a mask, actually uses Markov tables to do a probabilistic brute force.
[14:50.500 --> 14:56.980]  Instead of a classic dumb brute force where you're going A, A, A, A, A, etc. all the way through Z, Z, Z, Z.
[14:57.500 --> 15:08.540]  HashCat generates some Markov statistics and will order the search space for each character position probabilistically based on those Markov tables.
[15:09.660 --> 15:15.380]  So we can take our HashCat command and we can append this dash T 60.
[15:15.400 --> 15:19.080]  And what that does is that sets our Markov table threshold to 60.
[15:19.080 --> 15:31.540]  And what that simultaneously does is that lowers our base loop from using the 95s to using 60 instead.
[15:31.540 --> 15:39.540]  So instead of 95 to the 9th, the key space is now only 60 to the 9th, using only the top 60 characters in each mask position.
[15:43.310 --> 15:49.270]  All right. Let's kind of shift gears here and talk about loopback attacks.
[15:49.290 --> 15:54.350]  So by and large, password cracking is mostly just a feedback loop.
[15:55.230 --> 16:02.450]  You know, we crack passwords so that we can learn new passwords, which we then turn around and use to crack future passwords.
[16:02.450 --> 16:06.570]  And this cycle happens over and over for decades.
[16:07.650 --> 16:11.410]  And it holds true for every large password breach we've ever had, right?
[16:11.410 --> 16:16.870]  So starting with probably the most famous in recent history, which would be Roku.
[16:17.070 --> 16:22.110]  Roku.txt, while dated, is still kind of like the de facto example when we're talking about a word list.
[16:22.110 --> 16:25.170]  Even in this slide deck, I've used Roku.txt extensively.
[16:26.770 --> 16:28.790]  So, you know, we have the Roku passwords.
[16:28.790 --> 16:36.590]  That allowed us to identify new passwords by adding rules and, you know, basically mangling up those words to crack new passwords.
[16:36.590 --> 16:40.530]  And then once we got those new passwords, we add those to our word list collection, right?
[16:40.730 --> 16:43.030]  And then we're going to turn around and add rules to those.
[16:43.030 --> 16:47.870]  And we're going to continuously find new passwords based on the previous passwords that we've cracked.
[16:50.510 --> 16:55.970]  So in a loopback attack, which, again, you can do a loopback attack on a single run, right?
[16:55.970 --> 16:58.770]  For whatever run you're working on at that point in time.
[16:59.010 --> 17:04.910]  Or, you know, when you use previously cracked passwords, you're essentially still doing a loopback attack
[17:04.910 --> 17:09.050]  because you're taking the passwords found in your previous runs, even if those runs were a decade ago,
[17:09.050 --> 17:12.790]  and you're iterating on those to discover new passwords in your current run.
[17:14.050 --> 17:18.810]  So to do that, we'll just strip the plaintext passwords out of our hashcat.py file.
[17:20.190 --> 17:23.870]  And then we'll use that as a word list with some rules.
[17:23.870 --> 17:27.530]  Throw some best64 at it, throw some dead1 at it, you know, what have you.
[17:27.970 --> 17:32.930]  Now, we can take that a little bit further with what's called a fingerprint attack.
[17:34.010 --> 17:36.750]  Instead of using the plaintext passwords themselves,
[17:36.750 --> 17:43.630]  we can break each plaintext password down into what are known as fingerprints.
[17:44.030 --> 17:46.890]  A fingerprint would just be like, let's say, the word password.
[17:46.890 --> 17:56.230]  So it's going to split that up into P, P-A, P-A-S, P-A-S-S, P-S-S, P-A-S-S-W, so on and so forth.
[17:56.830 --> 18:02.610]  Basically expanding each word into each, you know, individual cluster of letters of itself.
[18:03.530 --> 18:09.370]  So to do that, we take our cracked passwords, whether it be looped back from your current hashcat.pot
[18:09.370 --> 18:17.010]  or cracked passwords from a previous run, you know, maybe like the RockyLeague or, you know, LinkedIn breach
[18:17.010 --> 18:21.850]  or Ashley Madison, Edmodo, Gizmodo, whatever.
[18:22.070 --> 18:26.570]  Literally dozens and dozens, if not thousands and thousands of public password breaches out there
[18:26.570 --> 18:30.030]  that have all sorts of, you know, plaintext or easy-to-crack passwords.
[18:30.030 --> 18:34.770]  And we use those to generate the fingerprints using expander.bin from hashcatutils.
[18:35.030 --> 18:42.350]  Once we have the fingerprints, we can either run that as a combinator attack or we can use that in a hybrid attack.
[18:43.910 --> 18:46.910]  You can do, you know, any numerous things with them.
[18:48.490 --> 18:51.170]  And you can also add rules to nearly any attack as well.
[18:51.170 --> 18:58.530]  So let's say you're using your fingerprints, right, and you're doing your combinator attack.
[18:58.530 --> 19:01.550]  Let's say you're using RockYou with your fingerprint file.
[19:01.830 --> 19:03.650]  Let's throw some rules on that.
[19:03.830 --> 19:11.150]  So the "-J rule is going to operate on the left-hand side there, the base loop.
[19:11.350 --> 19:17.010]  And in this example, we're deleting the last two characters from every word from the word list.
[19:17.290 --> 19:23.850]  And then we are appending our fingerprints from our loopback attacks to every word in that word list.
[19:25.250 --> 19:27.330]  This is kind of a favorite attack I like to run.
[19:27.330 --> 19:32.130]  I like to do "-J", right bracket, and then "-J", two right brackets,
[19:32.130 --> 19:35.450]  then "-J", three right brackets, so on and so forth.
[19:37.270 --> 19:41.030]  And that's going to enable you to find some pretty interesting new planes
[19:41.030 --> 19:44.010]  as we continue to cut characters off the end of the left dictionary
[19:44.010 --> 19:48.570]  and then continue to append our fingerprints to the right.
[19:50.950 --> 19:52.830]  Same thing with this example here.
[19:52.830 --> 19:58.070]  So like I said, "-J operates on the left-hand side, while "-K operates on the right-hand side.
[19:58.330 --> 20:01.130]  And of course, the C rule means to capitalize the word.
[20:01.130 --> 20:05.430]  So let's say we want to capitalize the rules from RockYou
[20:05.430 --> 20:09.230]  and then capitalize the words from our fingerprints.
[20:09.330 --> 20:13.470]  We can append "-JC", "-KC", to our command line,
[20:13.470 --> 20:21.150]  and that will enable us to capitalize each of the words on each side before combining them.
[20:23.230 --> 20:28.430]  And you can do the same thing with hybrid attacks as well.
[20:28.610 --> 20:31.770]  So let's say we have our fingerprints file, and we want to append double digits
[20:31.770 --> 20:33.570]  to every word in our fingerprints.
[20:35.030 --> 20:39.010]  We can add a "-JC", say we want to remove the last character
[20:39.010 --> 20:42.950]  from each word in our fingerprints, and then capitalize that word
[20:42.950 --> 20:46.090]  before appending the double digits.
[20:48.170 --> 20:50.590]  All right, now let's talk about stemming.
[20:50.590 --> 20:53.930]  It sounds sexual, but it isn't.
[20:53.930 --> 20:58.230]  Stemming is essentially identifying base words from each password.
[20:59.130 --> 21:03.710]  And this is going to be very useful for when you're doing your loopback attacks,
[21:03.710 --> 21:07.970]  whether, again, that's the looping back over passwords you just cracked in a previous run,
[21:07.970 --> 21:12.630]  or you're talking about looping back over passwords you've cracked
[21:12.630 --> 21:15.850]  from anything over the years.
[21:16.530 --> 21:19.530]  And essentially what we're doing in identifying these base words
[21:19.530 --> 21:24.930]  is we're unrolling the rules that people apply when they create passwords.
[21:24.990 --> 21:28.470]  So, you know, most people, when they're told to make a password stronger,
[21:28.470 --> 21:30.010]  they will uppercase the first letter.
[21:30.170 --> 21:34.530]  They'll substitute, like, an A for a four, or an E for a three, etc.,
[21:35.730 --> 21:37.890]  and probably put a couple of digits on the end.
[21:38.090 --> 21:40.670]  So when we stem, the first thing we're going to do
[21:40.670 --> 21:43.270]  is we're going to remove any leading and trailing digits and specials.
[21:43.930 --> 21:47.110]  We're going to convert it all to lowercase to normalize it.
[21:47.110 --> 21:51.410]  And any midstream digits and specials, we're going to convert those back to letters.
[21:51.890 --> 21:53.150]  And, of course, there's a lot more you can do here.
[21:53.150 --> 21:55.050]  This is kind of a very basic example of stemming,
[21:55.050 --> 21:57.970]  and there's also multiple tools out there that can do this for you.
[21:58.470 --> 22:02.810]  Like, I have some small scripts on the Hashcat forums that can do this.
[22:02.810 --> 22:05.030]  I think Pack can do this as well.
[22:06.150 --> 22:08.450]  And probably a dozen other tools that people have made on GitHub
[22:08.450 --> 22:10.230]  that can do wordless stemming.
[22:11.750 --> 22:13.790]  But once you have those stemmed words,
[22:13.790 --> 22:16.670]  you have a nice set of base words that you can use
[22:16.670 --> 22:20.450]  to either do fingerprint attack or hybrid attack,
[22:20.450 --> 22:24.030]  or you can use those with, like, rulegen.py from Pack
[22:24.030 --> 22:27.070]  to generate new Hashcat rules off of.
[22:29.630 --> 22:31.430]  So stemming, of course, is very powerful
[22:31.430 --> 22:35.230]  based on the things we can do with it once we have the common base words.
[22:37.070 --> 22:41.390]  All right, here's some more advanced things you can do with Hashcat.
[22:41.390 --> 22:44.270]  temesis.pl, again, from Hashcat Utils.
[22:44.650 --> 22:47.630]  What this is going to do is it's going to basically take fingerprints
[22:48.210 --> 22:52.450]  from each word, and it's going to create rules
[22:52.450 --> 22:55.690]  that will insert that word and fragments of that word
[22:57.550 --> 22:59.770]  throughout the word list that you pick.
[23:01.230 --> 23:04.410]  So let's say we pick rockyu, and we've created our temesis rule
[23:04.410 --> 23:06.450]  from our base words.
[23:06.710 --> 23:08.690]  It's going to go through and take every word from rockyu
[23:08.690 --> 23:12.630]  and insert patterns based on our base words.
[23:13.030 --> 23:16.330]  It's going to interlace those throughout the words in rockyu.
[23:17.050 --> 23:20.910]  And, of course, you can chain rules as well.
[23:21.170 --> 23:24.670]  So when you chain rules, the rules are applied in order.
[23:24.670 --> 23:27.090]  So we're starting with rockyu.txt,
[23:27.090 --> 23:31.630]  and then every word from rockyu is going to be...
[23:31.630 --> 23:34.650]  have the rules from our temesis.rule file applied to it.
[23:34.710 --> 23:38.410]  And then, after we apply temesis rule,
[23:38.410 --> 23:42.070]  it's going to then apply the best64 rules on top of that.
[23:42.390 --> 23:44.610]  So the key space for this can actually get really large really quick
[23:44.610 --> 23:47.750]  because it's going to be the number of words in rockyu
[23:47.750 --> 23:49.470]  times the number of rules in temesis
[23:50.090 --> 23:52.330]  times the number of rules in best64.
[23:52.570 --> 23:54.370]  So when you're performing this attack,
[23:54.370 --> 23:57.810]  it can get really large really quick.
[23:57.890 --> 24:00.190]  But it can also be really powerful.
[24:02.890 --> 24:06.930]  Rule chain like best64 and best64 is usually a good one.
[24:06.930 --> 24:12.170]  Sometimes, depending on your hash rate, you can chain dead1.rule
[24:12.170 --> 24:15.690]  or rockyu30000.rule with best64.
[24:16.870 --> 24:19.870]  But yeah, you can come up with some pretty cool attacks
[24:19.870 --> 24:21.690]  using rule chaining in this fashion.
[24:22.950 --> 24:26.270]  And sometimes it's a necessity if you have, like,
[24:28.690 --> 24:30.610]  a really targeted pattern that you want to hit
[24:30.610 --> 24:33.150]  that you can't just hit with a single rule file.
[24:33.330 --> 24:35.550]  You can create multiple rule files and chain them
[24:35.550 --> 24:37.810]  to try to generate the type of plain text you're after.
[24:39.770 --> 24:41.650]  And then, of course, there's PrinceProcessor,
[24:41.650 --> 24:43.810]  which is also available on hashcat.github.
[24:44.770 --> 24:48.650]  PrinceProcessor is sort of a more advanced combinator attack.
[24:49.790 --> 24:53.790]  It's kind of difficult to describe, but just think of it
[24:53.790 --> 24:55.490]  like a more advanced combinator attack,
[24:55.490 --> 24:57.730]  which you can pipe into hashcat through standardin.
[25:00.190 --> 25:03.410]  And that's it for advanced stuff.
[25:03.410 --> 25:06.170]  There's a lot more fun things that we can do,
[25:07.630 --> 25:11.270]  and we can cover that in a future session.
[25:11.310 --> 25:15.390]  But yeah, that's some of the really cool advanced stuff
[25:15.390 --> 25:16.410]  that you can do with hashcat.