All right, we're back. And this is our co-worker. 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? So,
you know, this is a statement that Lee asked me to write, that he asked me to prepare for him
before this talk. So this is the direct quote from Lee. So he says, what did you just say about me,
you hecking cowboy? I'll have you know I graduated top of my class in the Hashtag University. I've
been involved in numerous secret pull requests of the Hashcat code repository, and I have over
300 GPUs in my basement. I'm trained in guerrilla password cracking tactics, and I'm the top
contributor to hashes.org in the entire US. You are nothing to me but just another dictionary.
I'll wipe you out with the precision mask attacks like the witch I've never been seen on this earth.
Mark my hecking words. You think you can get away with these pull requests? Think again, cowboy.
As we speak, I am contacting my secret network of GPUs across the USA, and your IP is being
traced right now. So you better prepare for the storm. The cluster that wipes off your pathetic
little thing you call your password. You're cracked, kid. I can crack your password anytime,
and I can use it in over 700 ways, and that's not even including my FPGA. Not only am I extensively
trained in password-free combat, but I also have access to the entire arsenal of your crypto miner
underground. We'll use it to the full extent to wipe your miserable password off the face of the
little hacker. Please welcome the password king, Lee. Welcome to Hashes, Smothered, Covered,
and Scattered. Modern password cracking as a methodology. My name is Lee Wangenheim. I'm a
security consultant here at Optiv. I hack things for fun as well as for a job. If I wasn't getting
paid to do this, I'd be doing it on my own anyway. 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. So why does this matter? Because it only takes one password,
and as we know, people tend to use weak passwords. Some examples that we've seen on actual gigs are
using default passwords for Cisco devices, Microsoft SQL Server. 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. This is a real issue, and we run into it more often than
not. Once we've got one foothold into your network, we can use that to move laterally as much as we
want. Some of the hardware that we're using. So we used to use CPUs and Rainbow Tables. CPUs,
not really working, not really worth it anymore. They've kind of been overpassed now that the
modern GPU rigs are out there. We used to use a lot of Rainbow Tables to look up, especially in
NTLM and more common hash types. However, those have been kind of supplanted by the new GPU
cracking machines. 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. Because again,
you're burning CPU cycles doing Rainbow Table lookups versus GPU cycles with the new
modern GPU setups. We do sometimes use cloud using the AWS boxes, the new GPU boxes.
Those are pretty handy. They are expensive. 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.
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. Typically, a gaming laptop will do better,
but you use what you have, right? 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. And, you know, you can always make a little bit of your money back.
I don't do any more mining, so I don't know exactly how useful that is in today's world.
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. 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.
And we'll try and crack as many of their passwords as we possibly can.
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. So this is sort of where the cloud is as of 2017. Unfortunately,
we don't have too many updated stats, but it's just about the same.
So it used to be about $0.14 per gigahash hour, and now it's close to $0.03 per gigahash hour.
Now we do have our internal crackers, which you can see are running at about $0.07 per gigahash
hour. And we built those for about $25,000. 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. 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. So the P316 is currently the largest instance that you can get with GPUs.
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. 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.
You just do have to keep in mind that everything will come with a cost.
Hashtopolis is free, AWS instances are definitely not.
So this slide is shamelessly borrowed from the Terahash Corporation. They run the Brutalis,
or they produce the Brutalis machines. So currently, you can see their largest one
is running 448 NVIDIA RTX 2080s. 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.
Um, so a character passwords are absolutely in 2020 dead. I gave a version of this talk in 2019
and said that they're dead. The same was true in 2018. It's definitely true now. The amount
of power that firms are able to throw at brute forcing, especially in TLM hashes, is just
absolutely incredible at this point. And so really you want to work on, you know, instructing
your, your individuals to have, you know, strong 12 character passwords. As you can see, the
exponential growth is just incredible. 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.
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. 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. And, you know, I'll continue to use throughout the talk.
So masks are the makeup of a word broken into its character set. 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.
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.
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,
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. It's very, very common.
Very rarely will you see them shift where the middle characters have your uppercasing
or things like that. It's kind of attacking that human psychology and the human
linguistics of how we form words, especially in the English speaking. 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. 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. So that's where my main focus is, especially when it comes
to password cracking. Hybrid attack is where you're going to be brute forcing. So again,
brute forcing is just guessing every possible combination inside the character space. So
A through Z, digits zero through nine, and then all of your special characters. 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. So a hybrid attack is going to use that brute force attack,
and then you would take a mask and either append or prepend. 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. 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. So the year would be your either append or prepend.
So a word list is much different than a password dump. 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. So these are going to be dictionary words. This is not
supposed to be a password dump. 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. And then you can use those words and then modify them via rules in Hashcat to create
different candidates for cracking. 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. So you might get summer 2020 2020 using summer 2020 in a password dump
as a word list. So that would be the distinction there.
So this is one of my favorite quotes, if your only tool is a hammer then every problem looks
like a nail. Obviously Mark Twain. And so that's what we'll touch on here in a minute.
This is the kit that we use. I'll go into what each of these tools does in the next few slides.
So Hashcat, it's now the de facto standard as far as password cracking is concerned. It supports
just about every hash imaginable. 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. But I've never really encountered
anything on an engagement that Hashcat can't really do. John the Ripper was the de facto
standard five to ten years ago. Again, it uses the CPU cracking. Hashcat is
using GPUs. It's very, very well maintained, constantly updated, and lots of improvements.
Super easy to set up and to integrate with other tools. Also, there's so much information
and documentation out there about using Hashcat. So if you ever have issues, you can always
look it up and usually find the answer. Hashtopolis, this is what we've been using
to kind of integrate our distributed cracking operations. So this is a wrapper for Hashcat.
What it does is it manages agents, jobs, word lists, and Hashcat binaries. 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. You feed it a list of hashes, and you tell it
to crack. And then it goes and farms all of this out to those different Hashcat instances
and does all of the work for you, basically. 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. 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. We don't use this a lot. 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.
Hash ID. So this used to be a lot more useful. It's not the most useful anymore.
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. The nice thing
about this is it is offline compared to some of the online systems that you can drop hashes into.
So if you're trying to keep sensitive data off the internet, you can do it. 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. 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. 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. PwSpy is a tool that was built internally for Optive, but it is
open source. Some of the cool things that it will do is it will go out and find the most common
masks for you. 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. 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. 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. It will break out the different
password links that you have. It will also pull out different base words. 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, and things like that. The other thing that it will do is it will
analyze and find reused hashes. 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. You know, it's not usually
a big deal if it's summer 2020. It's a big deal, but it's not, you know, a deal with people sharing
passwords. 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, even DA creds, or somewhere
in a SQL server. Feel free to go download PwSpy. It's open source, and I've had a lot of people
reach out and suggest edits or find bugs. 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
through GitHub. So some of the techniques that we use. So this is how we kind of hone our skills.
So how do you begin? What's the best way to crack a hash? Well, so this is a loaded question to me.
I get this a lot from our internal team. It kind of drives me a little bit crazy because
it's kind of like asking what's the best way to use nmap. There's no one right answer.
So basically, it's kind of an experience, and just depending on the goals of your engagement,
what are you looking to do? So are you after one hash? Are you after multiple hashes?
You know, the algorithm that you're going after is very, very important. 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. So you're going to be able to throw more rules and more word sets.
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, 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. However, we would have cracked it. 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. And this is, you know, how we did it. So that's one way to
kind of work with your clients. So where do you get hashes? You know, always looking for hash dumps.
If you can get onto a Linux box and you have root access and you can dump Etsy shadow,
comp files are always great. Back-end databases that you can get into.
Mimikatz if you encounter like an older Windows system that's not fully patched. Web applications
a lot of times will expose hashes, you know, either via misconfigurations or just having
their database exposed. We run a lot of Responder or Magnum Metal 6 on internal gigs. I'll do a
demo of that in a little bit. DC sync and NTDS, you know, these are some of the common ways to
find hashes. There's thousands of ways to find hashes. 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. There are just many, many different ways to get hashes. These are some
good ways to start if you're kind of looking to get into it. 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. You can also just
create a bunch of, you know, NTLM hashes or MD5 hashes via some scripts. So, make a bunch
of passwords that you know and test it out in Hashcat. So, that's a good way to get started.
So, developing a methodology. So, this is really where our password audit kind of came out of.
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. These are going to be much more analysis based than, you know, hands on the keyboard.
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. Looking at the results and kind of
figuring out where you want to go from there. Looking at what their hashes are doing, looking
at what the passwords they're using are. Are they a secure company? Are you seeing, you know,
a lot of crazy hashes that, you know, you're not able to crack? Or are you seeing a lot of,
like, really simple passwords? The other thing we're going to look for is, you know, common words,
easy wins. Again, I keep coming back to summer 2020, password one, company name. Company name
and the date that it was founded is a really popular one. Street names. 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. You know,
you could extrapolate that across the country. You know, New England, you could do Patriots or
whatever. 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. 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. You really, for these enterprise engagements, you need heavy-hitting cracking
rigs, either built in-house or setting up the cloud. And I would say even just one Amazon
P316 is not going to really, you know, pass muster for this. 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.
So what do we do? Again, we go for quick wins. So we run... internally we have some proprietary
word lists that we use. It's kind of been tweaked over the years. It has
a lot of data from all the different breaches where we've extrapolated common base words,
things like that. And we'll run those without rules. And then we will slowly start adding
things that increase the time of cracking, but also increase your possibility of cracking more
passwords. So we will continue to run newer and newer attacks against the same list of hashes.
And, you know, as you'll see in a second, it's kind of the law of diminishing returns. But
as we move through the process, we tend to be pretty successful. We do in-house, we have the
capability to do a 1-8 character brute force. That takes about 24 hours on our internals crackers.
So we can brute force the entire NTLM keyspace within a day. So that's usually about the first
day of a password engagement. And then we will run our words, our word lists, and then our rules
against things after. You know, we will then use either PWSpy to create different masks,
or just use common masks, things like that. 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.
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. So as you can see, you know, within
the first few hours, we cracked the majority of the passwords we were going to crack. And
as we moved through, you can see the longer password recovery attempts did yield less results.
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. You know, that's,
that was enough to show an impact to the client. 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. So how to help your future self. This is really important.
So you want to have your POP files. We'll typically separate out POP files based on
clients, but we also keep a master POP file. That's a historical record of your cracked hashes.
It's useful to see if you've already cracked that hash on another engagement. So if you're
seeing summer 2020, you're not going to burn cycles trying to crack it again. We'll just try
that hash. 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. Do be really careful about bloat. It can
slow down the hash, the process, because it's going to check it against the existing POP file.
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. And at the time of the dump, LinkedIn did not have
any password restrictions. 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. So you do want to be careful of that,
because you're going to be running each hash against that POP file. And again,
you're going to be burning CPU cycles on that. Common masks. 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. But, you know, the common ones, you know, uppercase letters
at the beginning, and then trailing lowercase letters with digits at the end.
So now we're going to move into a demo. I'm going to show you sort of
what a typical engagement might look like, you know, on a client network.
Okay, so for this demo, I have a responder lab built using VirtualBox on my Windows machine.
So what I've done is I have set up a domain controller, a firewall appliance, a Kali machine,
and a Windows 10 machine. So you can see all of the machines are up and running.
What you see here is IPFire is running to route everything together.
Windows Server 2012 is currently running to act as the domain controller in the DNS.
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. Okay, so closing that out.
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. So we'll go ahead
and start up Responder here. So when you start up Responder, you have to feed it the interface
that you're using. So what Responder is doing is poisoning the LL, MNR, and NBTNS requests that
Windows machines will set out. This happens if Windows can't resolve a hostname using DNS.
It will send broadcast traffic out asking for that information. 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. 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. 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. And that should be sufficient to generate the LL, MNR broadcast
traffic. And we'll see an example of that here. So I open up the folders and I go to server does not
exist. And you can see the poison answers are being sent and we're capturing NTLMv2 hashes.
Now this is important. As we start capturing the NTLMv2 hashes, you'll see there are multiple
hashes being captured. These are actually the same hash just due to the nature of NTLMv2.
They are salted so you will receive multiple hashes. When you are going to crack these
hashes, what you'll want to do is take one hash per username. 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. So once we've got that hash, we can just
copy it over into a text file, which I do here. 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. Hopefully you get
something juicy. Sometimes you'll be able to get DA creds or things like that.
Okay, so now that we've got hash.txt created, we're going to go ahead and start up
HashCat. So NTLMv2 hashes are mode 5600. So to accomplish that in HashCat, you feed it the
TACM flag and then 5600. Then you feed it the file name. And then in this particular example,
we're using a little bit of a contrived example just for brevity. 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. 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. But you can always start with the quick and easy ones, and maybe
you'll get lucky. And if you do, that's awesome. You haven't spent a lot of time. However, if you
do need to use those heavier lists, please feel free to. And definitely use the masks and such
that you've got working. So we start a HashCat here, again, using the mode 5600.
And then we feed it the hash.txt that we created. And then we go ahead and feed it the
particular word list, which in this case, again, is stored as user share word list. And then we're
just using the fasttrack.txt. Once HashCat starts, again, this particular Kali instance isn't hooked
up to my GPU box. So you'll get some warnings for OpenCL and things like that. But you'll see
the warnings come through. And then just because I know that this works really quickly,
you'll see that this cracks. And you can see password1 is our cracked password.
Now, if we were cracking multiple passwords, or take longer, you would see those in your
POP file. 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. And that will create a POP file specifically for
that particular session with HashCat. 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.
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.
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.
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. And it was originally released during 6.14 con
2019. However, it's gone through some pretty major changes. 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.
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. 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. And it would do the analysis for you.
That's pretty much been accomplished. There's still a few more bugs and things that I'd like
to tweak. However, let's get into it. 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. 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. So that's what you're going to see here. So I'll go ahead and open
demo.pot. As you can see, these are just some common passwords, and they've already been cracked.
So it's time to do the post session analysis on that. So we're going to go ahead and feed this
file into pwspy. 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. The hash list is actually optional. You don't have to add that.
As well as inside the Python script, you can turn on and off individual modules simply by commenting
them out in the calls. Those are down at the bottom of the script, and I'll show you that
towards the end of this demo. 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. So we're not going to
feed that in. 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. So we'll go ahead and run pwspy, and we'll take a look at the output.
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.
So this shows you some of the various modules that have worked.
So as we scroll back, you can see that we have the
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. The other thing that it will do is it will tell you weak passwords.
So passwords, in this case, I have it set to just passwords that are just plain text.
So you can see all these passwords were cracked and consist of only letters and no numbers or
special characters of any sort. You can always make this more restrictive or less restrictive
by editing the Python script. One of the goals for the future is to add options
to define what a weak password would be. And then the last thing that it will do
is check the lengths of all the passwords that you have cracked. And as you can see,
it splits those out and gives you the number of occurrences. So there were a lot of 9-character
passwords, some 10-character passwords. 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. 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.
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.
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. And from there, what you can do is go ahead and comment out any of
those different modules, and it will not run those. 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. Again, this is an open source tool.
Please feel free to fork and edit it as you see fit. And I hope that this proves helpful to
somebody or anybody if you are doing especially large password assessments.
I'd like to thank you for taking the time to listen to today's talk. 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. It's been
a great DEF CON, despite it being remote. 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.
There are many different ways and approaches to cracking passwords, and what works for one person
may not work for everybody. So keep that in mind, as well as always remember that password cracking
is, again, not a one-size-fits-all. You're not going to be able to do this by just scripting
everything. 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.
Hopefully you have taken something away from this talk, and I will be in the Red Team Village
Discord for any questions. I'm HX50 in there, as well as on Twitter. You can find me at HX underscore
50. And once again, I would highly encourage you to go ahead and try some of these techniques out
on your own. Go ahead and create hashes, set up a lab, and go ahead and crack your own stuff.
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. You can find that at github.com slash lwangenheim
slash pwspy. And obviously, that's quite a mouthful to try and spell.
So if you do want to try and find it and Google doesn't help, feel free to reach out to me. I'm
more than happy to either just provide you the link, or I can just send you the files directly.