This is just a refresher post on how MS17–10 can be used in combination with a golden ticket attack. It can allow an attacker unfettered access directly to domain controllers, unauthenticated, and is remotely exploitable over SMB1.
So I have a lab setup with a Server 2012 R2 domain controller that is completely unpatched.
Next we use a MS17_010 psexec module in metasploit. This module will work on 2008 R2 server all the way up to Server 2016.
The server IP address to the target domain controller is 172.16.2.1. Please take note that I have no credentials defined in my current settings for this exploit.
The next screenshot is showing the target has been successfully exploited and we have been granted a meterpreter session.
Next I am going to verify a few things. Its important that we verify we are running under NT AUTHORITY\SYSTEM. If we are not some things in post exploitation just won’t work.
Since our meterpreter instance is running on x86/windows I will need to migrate to a different process since the domain controller is an x64 system. In the screenshot below I have migrated to lsass.exe which is a 64 bit process
Next we need to build some pieces of information together first I am going to dump hashes for user accounts. This can be done in one of two ways. Running “hashdump” from a meterpreter session or running a post module “run post/windows/gather/smart_hashdump”
If you run the smart_hashdump it will drop all account hashes into the loot folder with a text file. Below is a sample output of a hashdump
Next we need to recon a few more things about the domain. Below I have used wmic to produce the full domain SID of the RID 500 account and I’ve located the list of domain admins in the environment.
I have enough pieces of domain and hash information to forge my golden ticket with the kiwi module in my meterpreter session. Here is how to load the module
Next we will forget our first golden ticket
Here is each command output legend of what each switch does when you use the golden ticket create function.
- u [user]
-k [password hash]
-s [domain SID]
Now its time to pivot into a workstation. In this scenario I have a non domain joined machine that is plugged directly into the target network. Since I know the user name and password to the local workstation I exploit it with MS17–10 with authentication as the local user.
From this point I do the same things I did on the domain controller.
I will migrate to an x64 process
I will use incognito to impersonate the local admin token to the machine
Load up kiwi in my meterpreter session
Apply the golden ticket:
Pivoting back to the local windows 7 machine that is non domain joined you will see I have a ticket that is good for 10 years and I have established a C$ connection into the domain controller. At this point I could connect to any machine that is domain joined in my target lab and start pulling off sensitive information.
Post Remediation notes to prevent this from happening:
- ) Please patch your systems and stay current with your updates.
- ) The following is a sample output of the MS Security Guide settings as part of the security compliance toolkit. This disables SMB1, enforces LDAP channel binding since this GPO is targets to my domain controller. Netbios Node Types are set to a P-node config. This will render netbios poising useless with penetration test tools such as responder for credential hash dumping. WDigest is turned off by default in 2012 and newer but is still good to enforce at the group policy level for auditing purposes. This will prevent the disclosure of passwords in plain text.
3. ) This setting will disable LLMNR and will also render responder useless for credential dumping via LLMNR/Netbios poisoning.
4. ) Audit your krbtgt accounts. Did you know that Microsoft provides a script to rotate your krbtgt keys in a safe manner?
Reset the krbtgt account password/keys
Verified on the following platforms This script is tested on these platforms by the author. It is likely to work on…
This script is works in Server 2019. The script has 3 modes to work with. I suggest running your script in informational mode so you can see when the password was last set on the KRBTGT account.
Please keep in mind when you do the Reset Mode it will only reset the account once. You have to reset the account twice. This will force an N-1 and will invalidate any golden ticket that has been forged for persistence in a domain. To be on the safe side you should perform a reset on the krbtgt account every 10 hours. This will allow enough time for your tickets to expire gracefully after performing the second reset.
5.) Consider implementing Microsoft’s latest password guidance. All domains should require a minimum of 14 characters. To prevent poor choice in passwords I am in agreement with Microsoft in dropping the maximum password lifetime guidance. While I think the ultimate goal here is to get rid of passwords in your domain environment. Giving users the opportunity to create better passwords without the fear of expiration may lead to better choices of passwords in the interim.