SAM Database
Local Windows credentials are stored in the Security Account Manager or
SAM database as password hashes using the NTLM hashing format, which is based on the
MD4 algorithm.
We can reuse acquired NTLM hashes to authenticate to a different machine,
as long as the hash is tied to a user account and password registered
on that machine.
Although it is rare to find matching local credentials between disparate machines,
the built-in default-named Administrator account is installed on
all Windows-based machines.
This account has been disabled on desktop editions since Windows Vista,
but it is enabled on servers by default.
To ease administrative tasks, system administrators often enable this default
account on desktop editions and set a single shared password.
Given the capability of this attack vector, let’s walk through an example.
In this case, we’ll attack the default local administrator account.
Every Windows account has a unique security identifier or SID
that follows a specific pattern:
In this structure, the SID begins with a literal “S”
to identify the string as a SID, followed by a revision level,
usually set to “1”, an identifier-authority value, often “5”,
and one or more subauthority values.
The subauthority will always end with a relative identifier or RID
representing a specific object on the machine.
Let’s use PowerShell and WMI to locate the SID of the local administrator account
on our Windows 10 victim machine.
First, we’ll determine the local computername
from the associated environment variable,
and use it with the WMI Win32_UserAccount class.
To obtain results for the local administrator account,
we’ll specify the computername through the Domain property,
and the account name through the Name property.
The output reveals a RID value of 500 as expected.
Next, we’ll attempt to obtain credentials for this user account
from the SAM database.
The SAM database is located at C:\Windows\System32\config\SAM,
but the SYSTEM process has an exclusive lock on it,
preventing us from reading or copying it
even from an administrative command prompt.
There are two potential workarounds.
First, we could use the Volume Shadow Copy Server,
which can create a snapshot, or “shadow volume”,
of the local hard drive with vssadmin,
which is installed on Windows 8.1 and later.
We can create a new shadow volume with the create shadow option,
but this option is only available on server editions of the tool.
The second approach, which will work on our Windows 10 machine,
is to execute this option through WMIC
launched from an administrative command prompt.
Specifically, we’ll launch wmic, specify the shadowcopy class,
create a new shadow volume and specify the source drive with “Volume=”.
This will create a snapshot of the C drive.
To verify this, we’ll run vssadmin and list the existing shadow volumes
with list shadows:
Now that we’ve confirmed the creation of the shadow volume,
we can copy the SAM database from it using the source path provided in the output.
Although we have copied the SAM database, it is partially encrypted
by either RC4 or AES.
The encryption keys are stored in the SYSTEM file
which is in the same folder as the SAM database.
However, it is also locked by the SYSTEM account.
We can reuse our shadow volume copy to copy this file as well:
We can also obtain a copy of the SAM database and SYSTEM files from the
registry in the HKLM\sam and HKLM\system hives, respectively.
Administrative permissions are required to read and copy.
For example, we’ll use the reg save command to save the content to the
hard disk by specifying the registry hive,
and the output file name and path.
Regardless of how we obtain the SAM database and SYSTEM file,
we must decrypt them.
At the time of writing the only two tools that can decrypt these files are
Mimikatz and Creddump7.
In this example, we’ll use Creddump.
First, we’ll install the python-crypto library,
and then clone Creddump from the GitHub repository with git clone.
Next we’ll copy the SAM and SYSTEM files from the Windows 10 victim machine
to our Kali Linux machine,
and use the pwdump python script from Creddump7
to decrypt the NTLM hashes.
We have successfully decrypted the SAM database
and obtained the NTLM password hash for the local administrator account.
In this section we have executed this process manually to demonstrate
the individual steps.
However, many post-exploitation frameworks can automate this process as well.
In the next section,
we’ll examine how Microsoft has attempted
to mitigate the risk of this attack vector.