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.
4/ 3⃣ NTLM will not cache the user's plain text credentials or NT one-way function (NTOWF).
4⃣ Kerberos will no longer create DES or RC4 keys. Also it will not cache the user's plain text credentials or long-term keys after the initial TGT is acquired.
Source: [1]
5/ Accounts that are members of the Protected Users group that authenticate to a Windows Server 2012 R2 domain are unable to:
✅ Authenticate with NTLM authentication.
✅ Use DES or RC4 encryption types in Kerberos pre-authentication.
6/
✅ Be delegated with unconstrained or constrained delegation.
✅ Renew the Kerberos TGTs beyond the initial four-hour lifetime.
Source: [1]
7/ A word of advise ⚠️:
"Accounts for services and computers should never be members of the Protected Users group. This group provides incomplete protection anyway, because the password or certificate is always available on the host.
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]
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]