Module 04
Last updated
Last updated
If you have local administrative privileges on a Windows machine, you can abuse this to retrieve various forms of credentials stored on the respective machine. This includes credentials of local user accounts (stored in the SAM file) as well as temporarily cached credentials of currently logged-in users (kept in the memory of the lsass process).
There are many ways to do this. In this exercise we will use the famous tool Mimikatz.
In order to access credentials stored on the machine (and in process memory), Mimikatz needs to be run with administrative privileges. Therefore, we need to start a command prompt as admin.
In the Windows menu, type cmd and then right-click the Command prompt and choose "Run as administrator".
cd c:\temp\tools\Mimikatz_x64
mimikatz.exe
With Mimikatz up and running, we can start to retrieve stored credentials. We will start with credentials stored in the memory of the lsass.exe process.
First, we have to acquire debug privileges, so Mimikatz has enough rights to access the credentials (this will fail when not running as administrator in an elevated context).
Type the following command in the Mimikatz prompt:
privilege::debug
You can also enable logging with the following command:
log my_log.txt
Now we are ready to retrieve our credentials with the following command:
sekurlsa::logonpasswords
Next, we will also dump the passwords of the local Windows accounts from the Security Account Manager (SAM). In the mimikatz prompt, type the following command to elevate our permissions to SYSTEM (necessary to access SAM):
token::elevate lsadump::sam
Why does Mimikatz need debug privileges?
What are the prerequisites that your current session has SeDebugPrivileges
What are you going to do next with the NTLM hash of user aalfort?
Explain what Mimikatz does in the background to reveal these credentials?
Why can user aalfort’s credentials be found in the LSASS memory of Client1
Mimikatz requires this privilege as it interacts with processes such as LSASS.exe. Otherwise we won’t be able to dump sensitive informations from the memory. In a Windows System the LSASS.exe process is responsible for the following things:
Verifying and storing users credentials
Writing to the windows security log
Enforcing the security policy on the system
2. The debug privilege according to Microsoft determines which users can attach a debugger to any process or to the kernel. By default this privilege is given to Local Administrators! We have two ways to go:
become (local) Administrator
become local system
3. After gaining hashes it is up to the attacker to what they decide to do with the hash. They can try their hand at cracking it. But as we all know that it is difficult, time-consuming, and still no guarantee of gaining the correct password. Then there is this other way. During authentication, the basic procedure is the password is collected from the user, then it is encrypted and then the encrypted hash of the correct password is used for future authentication. During Credential Dumping, we see that we have extracted lots and lots of hashes. Now as an attacker we don’t know the password. So, during the authentication, we provide the hash instead of the password. Windows compares the hashes and welcomes the attacker with open arm.
4. Mimikatz is doing a memory dump of the process LSASS.exe to generate an output of sensitive logon informations.
5. After the initial authentication, Windows keeps the hash in its memory so that the user doesn’t have to enter the password again and again. The User Aalfort has an interactive session to our client and that’s the reason why we found the NTLM Hash in the memory.
