Controlling the domain controller (Part 2) - Multirelaying NTLMv2 tokens to gain authentication.
All Controlling the Domain Controller articles could be found here:
Previously
In the previous part, LLMNR poisoning and extraction of NLTMv2 hashes were explained, and a potentiall attack vector was found cracking NLTMv2 hashes. However, a main problem was found:
What happens if the NTLMv2 could not be cracked because the user/service password has a high complexity?
Multirelay
Multirelay is one of the newer features that Responder.py introduced towards the end of 2016. Using this tool we can relay our NTLMv1/2 authentication to a specific target and then, during a successful attack, execute code. So… it is perfect to try a new attack vector without cracking the NTLMv2 hash.
Two conditions must be taken into account:
- SMB Signing needs to be disabled on the machine where the hash is relayed.
- The user/service whose hash is relayed must have an account on the target computer.
Detecting SMB Signing - Runfinger.py
SMB (Server Message Block), is a protocol mainly used for providing shared access to files, printers, and serial ports and miscellaneous communications between nodes on a network. With the exception of Windows Server OS’s, all Windows operating systems have SMB Signing disabled by default. Therefore, a NTLMv2 packet enveloping a SMB authentication could be relied to another system to gain authentication if the SMB packet is not signed. However, the NTLMv2 packet could not be relayed to the same system because of Microsoft Security Bulletin MS08-068 patch.
Responder.py includes a tool that allows the detection of equipment with SMB Signing: Runfinger.py.
Notice that both Windows 7 installed by default in the environment don’t sign SMB packages:
Retrieving information for 192.168.56.10...
SMB signing: False
...
Retrieving information for 192.168.56.20...
SMB signing: False
Multirelaying
To achieve a successful exploitation of this attack we need to disable the SMB and HTTP servers used by Responder otherwise there would be some conflicts between Responder and Multi-relay.
- Responder.py configuration
Previously, running RunFinger.py, SMB Signing configuration was detected and targets that don’t sign SMB were detected. Now, we will indicate Multirelay.py to relay all packages detected in the network to the target -t 192.168.56.20 and with any user -u ALL.
- Multirelay.py
As we have seen, when an NTLMv2 hash is obtained, it is relayed to 192.168.56.20 obtaining a limited shell. What can this shell do?
* dump -> Extract the SAM database and print hashes.
* regdump KEY -> Dump an HKLM registry key (eg: regdump SYSTEM)
* read Path_To_File -> Read a file (eg: read /windows/win.ini)
* get Path_To_File -> Download a file (eg: get users/administrator/desktop/password.txt)
* delete Path_To_File-> Delete a file (eg: delete /windows/temp/executable.exe)
* upload Path_To_File-> Upload a local file (eg: upload /home/user/bk.exe), files will be uploaded in \windows\temp\
* runas Command -> Run a command as the currently logged in user. (eg: runas whoami)
* scan /24 -> Scan (Using SMB) this /24 or /16 to find hosts to pivot to
* pivot IP address -> Connect to another host (eg: pivot 10.0.0.12)
* mimi command -> Run a remote Mimikatz 64 bits command (eg: mimi coffee)
* mimi32 command -> Run a remote Mimikatz 32 bits command (eg: mimi coffee)
* lcmd command -> Run a local command and display the result in MultiRelay shell (eg: lcmd ifconfig)
Extracting credentials with mimikatz
Mimikatz is a post-explotation tool that extracts plaintexts passwords, hash, PIN code and kerberos tickets from memory. Mimikatz can also perform pass-the-hash, pass-the-ticket or build Golden tickets.
In the previous shell the mimi or mimi32 command is offered, so introducing the command mimi sekurlsa::logonpasswords will extracts passwords, keys, pin codes, tickets from the memory of lsass.
Perfect, domain’s password of Administrator has been extracted, and now?
wdigest :
* Username : Administrator
* Domain : LAJA
* Password : I$ec1234
Road to domain controller - CrackMapExec
Controlling the Domain Controller is one of the goals of a pentest. But how could we got there?
CrackMapExec (a.k.a CME) is a post-exploitation tool that helps automate assessing the security of large Active Directory networks. Built with stealth in mind, CME follows the concept of “Living off the Land”: abusing built-in Active Directory features/protocols to achieve it’s functionality and allowing it to evade most endpoint protection/IDS/IPS solutions.
It is a very interesting tool with a lots of options. In this case, we will try to enumerate in which server of the network we can log in with the previous credentials retrieve: Administrator/I$ec1234. The following command would be executed:
crackmapexec smb 192.168.56.0/24 -u 'Administrator' -p 'I$ec1234'
If the host shows Pwn3d!, it indicates that the credentials worked and some actions could be performed in the system. Furthermore, some modules could be executed when credentials are valid, in this case --pass-pol to retrieve password policy, uac to check UAC status or enum_avproducts to check with antivirus systems are deployed by the system.
It’s raining shells!! - Retrieving shells in all Pwn3d! systems
There is a module in CrackMapExec that allows inject meterpreter. So… let’s inject meterpreter in all systems that allows authentication with the previous credentials… but, what is meterpreter?
Meterpreter is an advanced extensible payload that uses an in-memory DLL injection. It significantly increases the post-exploitation capabilities of the Metasploit Framework and would allow to retrieve a reverse shell.
- Configuring the listener to retrieve shells:
- Configuring crackmapexec to inject meterpreter and execute reverse shells:
msf5 exploit(multi/handler) > sessions
Active sessions
===============
Id Name Type Information Connection
-- ---- ---- ----------- ----------
1 meterpreter x86/windows 192.168.56.1:14744 -> 192.168.56.20:49260 (192.168.56.20)
2 meterpreter x86/windows LAJA\Administrator @ WIN-1DBC39578NO 192.168.56.1:14744 -> 192.168.56.99:50257 (192.168.56.99)
3 meterpreter x86/windows 192.168.56.1:14744 -> 192.168.56.10:49417 (192.168.56.10)
Wow, we have an interactive shell in all the systems in the environment with Administrator privileges.
The final steps to accomplish a domain controller pentesting is to extract the contents of ntds.dit file.
Extracting and cracking ntds.dit file
The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain.
There are several ways to extract these files, in this case the msfconsole’s ntdsgrab module will be used.
To retrieve the contents of NTDS.dit the following steps would be followed:
- 1 Esedbexport to extract the tables of NTDS.dit
- 2 Ntdsextract to retrieve information of the users using de SYSHIVE file retrieved with
ntdsgrab.