Windows password hashes.
All right, so we're currently within the Windows Credential
dumping section of this course, where we are primarily
going to be taking a look at how to dump credentials
or to find and dump credentials and hashes from Windows
systems.
And to begin with, we actually need
to get an understanding of Windows password hashes
and where Windows password hashes are stored.
So we'll be exploring the various hashing algorithms
or the types of hashes that you're likely to come across,
as well as the location of these hashes
in regards to where they're stored on a Windows system.
All right.
So starting off, let's get an understanding
of where they're stored or where password hashes are
stored on a Windows system.
All right, so the Windows operating system stores
hashed user accounts passwords locally in the SAM database.
SAM stands for the security accounts manager.
Now, if you're a bit confused as to what hashing is,
it's really very, very simple, and it all
comes down to avoiding or finding
a way to avoid storing passwords in clear text, which
many operating systems do.
So hashing is the process of converting a piece of data,
and in this case, a password string, into another value.
A hashing function or algorithm is
used to generate the new value.
The result of a hashing algorithm
is known as a hash or hash value.
So again, on modern operating systems,
it really is a huge security risk
to have user account passwords stored locally irregardless
of where they're stored.
And as a result, early on in the early 2000s,
the hashing process was revised, or the encryption process
was revised, whereby whenever a user account was created,
the password string that they provided
was automatically hashed and stored
and then authentication would be compared
with that particular hash as opposed
to the clear text password.
All right.
Now, authentication and verification
of user credentials is facilitated
by the local security authority, also known as LSA.
And this all ties into the LSASS process that runs on Windows,
and we'll get to that in a few seconds.
Now, Windows Server-- or Windows versions
up to Windows Server 2003 utilize two different types
of hashes.
You have your LM hash and your NTLM hash.
We'll get to these in a second.
Now, Windows disables LM hashing and utilizes NTLM hashing
from Windows Vista onwards, so I just
want you to be aware of that, and this will give you
an idea of the types of hashes or the format of the hash
that you're likely to come across given
the current environment.
So it's very likely that you will probably never
see an LM hash in the world or within a Windows environment
unless the target Windows system is
running a very old version of Windows, which
is very unlikely.
So the hash that you're likely to come across
is the NTLM hash or the NT hash.
And, of course, we also have various versions of NTLM.
We have NTLM version 1 and NTLM version 2.
This is something that we'll not be touching upon in terms
of the differences right now because the differences will
really come into play when it comes down
to cracking these hashes, which we will
be exploring in another course.
All right.
So now that we have an understanding of what
hashing is and you know where the hashes are stored,
which again is the SAM database, let's
understand the SAM database a little bit better.
All right, so SAM, also known as security account manager,
is a database file that is responsible for managing
user accounts and passwords on Windows.
All user account passwords stored in the SAM database are
hashed by default. So this is where the password hashes are
stored, and it's very important to note that the SAM database
file cannot be copied while the operating system is running.
So this is a security feature that
was implemented by Windows, where--
they, of course, realized that this could
be a problem if someone got access to the SAM database
while the system was running, then they would essentially
be able to dump the contents of the SAM database.
Now, the Windows NT kernel does this
by keeping the SAM database file locked, and as a result,
attackers will typically utilize in-memory techniques and tools
to dump the SAM hashes from the LSASS process memory.
All right, so remember the LSA, the local security authority
or the LSASS process, the local security Authority Subsystem,
is responsible for authentication on Windows,
and this particular service also has a cache of memory
that will again typically contain
these hashes as it interacts with the SAM database.
So tools like Mimikatz essentially
utilize or interact with the LSASS process
and try and dump the actual cache of this process in order
to identify the NTLM hashes, for example.
Now, in modern versions of Windows,
the SAM database is encrypted with a syskey,
and this is something that I'll actually
demonstrate as we move along within this section.
It's also important to note that elevated or administrative
privileges are required in order to access and interact
with the LSASS process, which means
that you need to have an elevated session on the target
system in order to dump hashes from memory or anything
like that and that is why this particular section comes
after the Windows privilege escalation section
within this course.
So you need an elevated session in order to dump hashes,
and that's something very important.
All right, so let's start off by getting an understanding
of the LM hash or LanMan hash.
So LM is the default hashing algorithm
that was implemented in the Windows operating system
prior to versions that ran the kernel NT 4.0.
The protocol is used to hash user passwords,
and the hashing process can be broken down
into the following steps.
All right, so the password is broken down
into two seven-character chunks, so that's very important,
and I'll illustrate this in a second.
And then all characters of this password string
are then converted into uppercase,
which means that the LM hash really does not support or is
not case sensitive, so that means
even if you specify a password that is case sensitive,
LM will automatically convert that password to uppercase
and then hash those two chunks.
So each chunk is then hashed separately
with the DES algorithm, which is relatively weak.
So LM hashing is generally considered
to be a weak protocol and can easily be cracked primarily
because the password hash does not include salts, consequently
making brute-force and rainbow table attacks
effective against LM hashes.
All right.
And as I said, we're not really going
to be focusing on LM hashes because, again, they are very
outdated and extremely weak.
We are primarily interested in NTLM.
So let's get an understanding of how LM hashing works.
So you can see that a user specifies a password when
they're creating an account, and it
could be a very simple password like password123.
And irregardless of whether or not
they've made the password case sensitive,
LM will essentially split it into two chunks,
into two seven-character chunks right over here
and then convert those two chunks into uppercase,
as you can see here.
And then these two chunks are then
hashed using the DES algorithm.
And then you finally have the LM hash right over here
that is comprised of two separate chunks that have both
been hashed by the DES algorithm.
All right, and that is really what it is--
or what it comes down to when you're
talking about an LM hash.
Now, let's move on to the NTLM hash,
also known as the NT hash, not to be
confused with NTLM version 1 and version 2.
All right, so let me explain what
NTLM is at a very basic level.
NTLM is a collection of authentication protocols
that are utilized in Windows to facilitate authentication
between computers.
The authentication process involves
using a valid username and password in order
to authenticate successfully.
So from Windows Vista onwards, Windows disables LM hashing
and utilizes NTLM hashing, so that
means that you will typically find
that passwords on modern versions of Windows
like Windows 7 onwards are using NTLM hashing,
so all the passwords will be in the NTLM hash format
unless specified otherwise.
And, of course, you will run into systems
that are using NTLM version 1, NTLM version 2, et cetera.
All right.
So when a user account is created,
it is encrypted-- the password is encrypted
using the MD4 hashing algorithm while the original password is
disposed of.
So the clear text password is disposed
of for obvious reasons.
And NTLM improves upon LM in the following way.
So it does not split the hash into two chunks,
for one, which is, again, it really
doesn't make a difference, but in terms of security
and cracking, this will become much more
clear as we move into the password cracking course.
But for now, just know that it doesn't
split the hash or the password into two chunks.
It is also case sensitive, which means
if a user account specifies the password
and makes it case sensitive, then
it will be hashed in that particular format.
And it also allows the use of symbols and Unicode characters.
It's also important to know that NTLM or NT hashes are stored
within the SAM database, obviously,
but they really do not have password salts, which
means that they can be cracked relatively
easily through a brute force attack or a rainbow table
attack.
All right, so that is NTLM or NT hash.
All right.
So this diagram explains the process
or rather encapsulates the NTLM hashing process.
So a user specifies a password that contains symbols and is
case sensitive, and that is then hashed using the MD4 algorithm.
And, of course, you then have your NTLM hash,
so it's fairly simple to understand.
And, of course, I'll be taking you
through the process of identifying these hashes as we
progress through this section.
OK, so that really is all that I wanted to cover in this video.
I wanted to give you an introduction
into Windows password hashes, where they're stored,
and the types of hashes that you're likely to encounter.
And this will set up the premise for the next set of videos
within this section, where we will be taking a look at how
to dump NTLM hashes on a Windows system
through the use of Mimikatz and the Windows Credential Editor.
And we will also be exploring the process
of finding a legitimate credentials-- or credentials
stored in Windows configuration files
as that is a Windows vulnerability in and of itself.
So that's going to be it for this video,
and I'll be seeing you in the next video.