2/ A running print spooler service on domain controllers is still a relatively common finding in our AD assessments, even though an attack path via spooler service and unconstrained delegations have been known for years. [1]
3/ Apart from the (older) attack technique with unconstrained delegations (see above), the printer spooler has had various critical vulnerabilities over the last two years. [3]
4/ In a recent incident response investigation, the attacker attempted to exploit the PrintNightmare (CVE-2021-34527) vulnerability.
5/ PrintNightmare can be used for LPE and RCE, as the screenshot below shows. [2]
6/ Disable the print spooler service on domain controllers if possible to reduce the attack risk in case of an active attacker in the network.
7/ Additionally, the corresponding Windows patches (as an example for the LPE via PrintNightmware) must be rolled out and installed quickly across the board.
2/ To raise the bar again, add critical accounts to the Protected Users Security Group.
"This group provides protections over and above just preventing delegation and makes them even more secure; however, it may cause operational issues, so it is worth testing in your env." [2]
3/ Benefits:
1⃣ Credential delegation (CredSSP) will not cache the user's plain text credentials [..]
2⃣ Beginning with Windows 8.1 and Windows Server 2012 R2, Windows Digest will not cache the user's plain text credentials even when Windows Digest is enabled.
A customer called us because he discovered two new computers within his computer objects that did not match his naming scheme.
3/ During the detailed investigation of the incident, it turned out that these SAMTHEADMIN objects were part of an exploit code that (if successful) would give administrative rights to a standard domain user.
2/ Strictly speaking not part of a guide about hardening AD, but I must stress once again the importance of logging executed PowerShell code on clients and servers:
3/ There are other opinions about PowerShell Script Block logging because, potentially, passwords or other sensitive data could end up in event logs, and authenticated users on the workstation or server could read these logs, thus giving away the sensitive data. [1]
2/ In our AD assessments or IR cases, we repeatedly see that service accounts are highly privileged, often also part of the domain administrators group.
This can be disastrous, especially with a weak password for the service account:
3/ @Synacktiv took a closer look at the detection capabilities of Defender for Identity, including whether and how Kerberoasting could be detected. [1]