PrintNightmare, from Domain User to domain dominance in about 60 seconds
TL;DR This is simply an example scenario to show how serious PrintNightmare is. I cannot take credit for any of this. I simply read what Benjamin Delpy published and then used 2 of his tools in the lab.
Background
Researchers recently realized that a print feature in Microsoft Windows could be abused. The feature allowed any user to add any printer from any print server by typing in the print server name and then double clicking. The printer’s driver would auto-install. Very user friendly and works great. Awesome feature! Right?
Well, like many things in security such as name poisoning, the issue is that the vendor designed the product for ease of use and forgot what attackers might do with it. This print feature allows a lowly domain user to automatically install print drivers as system. If they were manually adding the printer through the Control Panel they would need admin privileges to install the driver. However with this ‘Point and Print’ feature Domain User privilege is enough.
Lab Setup
All that is required to follow along with the scenario is
- VM running a domain controller (DC)
- VM running a domain workstation
- Internet connection to pull Delpy’s print driver & Mimikatz
Exploitation
So what happens if an attacker sets up a print server with a specially designed driver? Benjamin Delpy, famed creator of Mimikatz, did exactly that. Simply navigate to \\printnightmare.gentilkiwi.com and login with gentilguest\password.
Please note that in this lab we are assuming that an advanced attacker created custom malware, so for simplicities sake I temporarily disabled Windows Defender. If it is enabled Defender will do its job rather well and block the print driver.
Post Exploitation
The Domain User is immediately provided with a shell, in this case cmd.exe, running as NT AUTHORITY\SYSTEM. So what would an attacker do in this scenario? They would run Mimikatz of course and see what credentials are present on the system they just compromised.
In this scenario our lab’s administrator had used this domain workstation previously. This allows the attacker to copy/paste their NTLM hash. Once they have done this they can immediately execute pass the hash (PTH) and grab the krbtgt hash.
Game Over
Our attacker already knows the domain SID. It is simply the user’s SID without the trailing ‘-XYZ’. They can also easily find it via PowerShell with only Domain User access.
At this point our attacker has everything they need to generate an infamous Golden Ticket. This will enable them to maintain persistence and domain dominance for the next 10 years.
The Golden Ticket
To be clear, the attacker requires the following information to generate a Golden Ticket:
- Domain FQDN
- Domain SID
- Krbtgt NTLM hash
An account with 2 very critical privileges (either the account’s pwd or hash will do)
This information allows the attacker to take over the entire domain.
This saves the ticket for later use. If the ticket is viewed we see that it is good for the next 10 years.
If the attacker wants to use the ticket then they can simply load it and launch a shell. Please note that for simplicities sake I forged a ticket for CORP\Administrator. The attacker can use any account they want.
Ransomware
Needless to say, given elevated credentials the attacker could also easily deploy ransomware domain wide. In fact, this is exactly what the Colonial Pipeline attackers did. Quoting from https://www.areteir.com/darkside-ransomware-caviar-taste-on-your-big-game-budget/
“We observed Darkside payload (e.g., azure_agent.exe.exe) staged on the domain controller in a network-shareable folder (e.g., C:\Windows\IME\azure), followed by the establishment of a scheduled task (e.g., \Windows\SYSVOL\domain\Policies\{L0NGMGU1D}\User\Preferences\ScheduledTasks) set with Group Policy and instructing hosts to obtain and execute the payload. This resulted in a fully automated enterprise-wide deployment less than 24 hours after data was exfiltrated.”
Mitigations
Limit users from connecting to non-approved print servers via Group Policy. Simply create a new GPO, apply it to the domain workstation OU, and navigate to
Computer Configuration\Policies\Administrative Templates\Printers\Package Point and print — Approved servers
Then set the GPO to only allow users to connect to your own print server. By default they are allowed to connect to anything.
Other mitigations should already be best practice, such as limiting Domain Admin usage to Privileged Access Workstations (PAWs) and utilizing Microsoft LAPS. This will limit an attacker’s ability to move laterally or escalate domain privileges after compromising one domain workstation. Of course run Windows Defender and keep it up to date. Custom malware may evade it, but it will catch the script kiddies and disgruntled insiders.
There are various methods to mitigate against an attacker capturing privileged credentials, using PTH, and so on, but those are an entire article on their own.
For the truly paranoid there is an administration tactic that will keep all privileged domain user’s credentials off the workstations by utilizing LAPS.
Conclusion
Stay safe, follow best practices, and patch! Remember that the attacker only met success in this scenario in the lab because Windows Defender was disabled and a Domain Admin had logged into the system previously.
There have been numerous vulnerabilities this summer including this one and HiveNightmare.
References
https://thehackernews.com/2021/07/microsoft-warns-of-critical.html
https://www.itechtics.com/enable-disable-windows-defender/
https://www.areteir.com/darkside-ransomware-caviar-taste-on-your-big-game-budget/
