NOTEThis article was first published on dfir.ch
This is the second part of a two-part series about Active Directory security. Read the first part here.
To gain insight into common issues and patterns of misconfiguration, we analyzed 250 PingCastle reports collected from Incident Response cases and Compromise Assessments. We indicate how many of the 250 domains checked were affected by the finding (Affected Domains: N/250).
PingCastle is a popular tool for auditing the security of Active Directory environments, pinpointing vulnerabilities, and offering actionable recommendations for improvement. We are following along The Ten AD Commandments, mapping every point to the corresponding PingCastle finding(s).
6. Privileges
6.1 - Introduction
PingCastle lists, among many other things, the privileges assigned to domain users via GPOs. Figure 1 shows that the Default Notebook Policy grants Domain Users the SeLoadDriverPrivilege privilege.
Figure 1: SeLoadDriverPrivilege
Why is this bad? As @0xdf put it: If I can load a driver, I can load a vulnerable driver and then exploit it. [1] I am aware that some Endpoint Detection and Response (EDR) solutions generate alerts when a vulnerable driver is loaded or written to disk, as such drivers can be exploited for Local Privilege Escalation (LPE).
Figure 2: If I can load a driver, I can load a vulnerable driver and then exploit it.
Excerpt from a Volexity blog post: A userland application cannot modify kernel memory, so the malware authors include a vulnerable driver, RTCore64.sys, to read and write into this protected memory space. A public GitHub repository, KDU, owned by hFiref0x, documents a list of drivers that can be abused for this Bring Your Own Vulnerable Driver (BYOVD) technique.
6.2 - Findings
6.2.1 - Ensure that dangerous privileges are not granted to everyone by GPO
The purpose is to ensure that standard users are not granted dangerous privileges. The SeLoadDriverPrivilege presented above is one of many dangerous privileges. Thomas Roccia (fr0gger) has compiled a list of Windows privileges (Figure 3).
Figure 3: Windows Privileges
Figure 4 shows a snippet from a Default Domain Policy, granting Èveryone the SeBackupPrivilege.
Figure 4: SeBackup
Affected Domains: 13/250
6.3 - References & Tools
- https://www.volexity.com/blog/2023/03/07/using-memory-analysis-to-detect-edr-nullifying-malware/
- https://0xdf.gitlab.io/2020/10/31/htb-fuse.html
- https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/total-identity-compromise-microsoft-incident-response-lessons-on/ba-p/3753391
- https://speakerdeck.com/fr0gger/windows-privileges
7. Harden critical accounts
7.1 - Introduction
Add critical accounts to the Protected Users Security Group to raise the bar for a successful attack against your network. 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.
Benefits of using the Protected Users Security Group:
Credential delegation (CredSSP)will not cache the user’s plain text credentials [..]- Beginning with Windows 8.1 and Windows Server 2012 R2,
Windows Digestwill not cache the user’s plain text credentials even whenWindows Digestis enabled. NTLMwill not cache the user’s plain text credentials orNT one-way function (NTOWF).Kerberoswill no longer createDESorRC4keys. Also, it will not cache the user’s plain text credentials or long-term keys after the initialTGTis acquired.
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.
✅ Be delegated with unconstrained or constrained delegation.
✅ Renew the Kerberos TGTs beyond the initial four-hour lifetime.
A word of adviceAccounts 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.
7.2 - Findings
7.2.1 - At least one member of an admin group is vulnerable to the Kerberoast attack
To access a service using Kerberos, a user requests a ticket (named TGS) to the DC specific to the service. This ticket is encrypted using a derivative of the service password, but can be brute-forced to retrieve the original password. Any account having the attribute SPN populated is considered as a service account. Given that any user can request a ticket for a service account, these accounts can have their password retrieved. In addition, services are known to have their password not changed at a regular basis and to use well-known words.
Affected Domains: 95/250
7.2.2 - Check the use of Kerberos with weak encryption (DES algorithm)
The purpose is to verify that no weak encryption algorithm such as DES is used for accounts. DES is a very weak algorithm and once assigned to an account, it can be used in Kerberos ticket requests, even though it is easily cracked. If the attacker cracks the Kerberos ticket, they can steal the token and compromise the user account.
Affected Domains: 103/250
7.2.3 - Check for the number of Administrator accounts above the baseline
The purpose is to verify if the number of administrator accounts is not disproportionate. Very few users should have domain admin accounts.
Affected Domains: 51/250
7.2.4 - At least one administrator account can be delegated
The purpose is to ensure that all Administrator Accounts have the configuration flag “this account is sensitive and cannot be delegated” (or are members of the built-in group “Protected Users” when your domain functional level is at least Windows Server 2012 R2).
Affected Domains: 232/250
7.3 - References & Tools
8. Print Spooler Service
8.1 - Introduction
A running print spooler service on domain controllers is still a relatively common finding in our Active Directory assessments, even though an attack path via spooler service and unconstrained delegations have been known for years.
Figure 5: The spooler service is remotely accessible
Apart from the (older) attack technique with unconstrained delegations (see above), the printer spooler has had various critical vulnerabilities over the last two years.
Figure 4: Printer Spooler vulnerability
In one of our Incident Response investigations, the attacker attempted to exploit the PrintNightmare (CVE-2021-34527) vulnerability. PrintNightmare can be used for Local Privilege Escalation as well as Remote Code Execution, as the screenshot below shows.
Figure 5: PrintNightmare
Disable the print spooler service on domain controllers if possible to reduce the attack risk in case of an active attacker in the network. Additionally, the corresponding Windows patches (as an example for the LPE via PrintNightmware) must be rolled out and installed quickly across the board.
8.2 - Findings
8.2.1 - Ensure that the Print Spooler service cannot be abused to get the DC credentials
When there’s an account with unconstrained delegation configured (which is fairly common) and the Print Spooler service running on a computer, you can get that computers credentials sent to the system with unconstrained delegation as a user. With a domain controller, the TGT of the DC can be extracted allowing an attacker to reuse it with a DCSync attack and obtain all user hashes and impersonate them.
Affected Domains: 140/250
8.3 - References & Tools
9. Easy Wins (for Attackers)
9.1 - Introduction
To wrap up this two-part series, here are more points you should focus on to better defend your networks.
9.2 - Findings
9.2.3 - Obsolete Domain Controller
The purpose is to ensure that there is no use of the obsolete and vulnerable OS Windows Server 20[03|08|12] as Domain Controller within the domain.
DC-2003
Affected Domains: 3/250
DC-2008
Affected Domains: 21/250
DC-2012
Affected Domains: 10/250
9.2.4 - Number of accounts that do not require Kerberos pre-authentication
Without Kerberos pre-authentication, an attacker can request Kerberos data from the domain controller and use this data to crack the account password.
Check if all accounts require Kerberos pre-authentication
Affected Domains: 19/250
Check if all admin accounts require Kerberos pre-authentication
Affected Domains: 4/250
9.2.5 - DC’s have been found where the owner is not in the Domain Admins group or the Enterprise Admin group
By default, the “Domain Administrators” group or the “Enterprise Administrators” group are set as owners for “Domain Controllers”. Nonetheless, in some cases (for instance when the server has been promoted from an existing server), the owner can be a non-admin person which joined the server to the domain. If this person has still rights over this account, it can be used to take ownership over the whole domain. A chain of compromising events can be designed to take control of the domain by including this account.
Affected Domains: 42/250
9.2.6 - DC vulnerability (MS17-010)
The purpose is to verify if Domain Controller(s) are vulnerable to the MS17-010 vulnerability.
Affected Domains: 2/250
9.2.7 - Check if a GPO assigns everyone to a local group
The purpose is to identify if there are local groups such as local administrators, terminal server access, where Authenticated Users or Everyone is being granted access by a GPO. It is possible that a GPO adds local membership using a GPO. In this case the rule triggers if one is found with “Everyone” or “Authenticated Users” or “Domain Users”, … as members. It basically means that the local Group has no restriction on belongs to it. This represents a security risk as Local Group are supposed to have more accesses or rights.
Figure 6: LocalAdmins
Affected Domains: 9/250
9.3 - References & Tools
- https://cube0x0.github.io/Pocing-Beyond-DA/
- https://www.infosecmatter.com/top-16-active-directory-vulnerabilities/
- https://blog.nviso.eu/2023/10/26/most-common-active-directory-misconfigurations-and-default-settings-that-put-your-organization-at-risk/
- https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/total-identity-compromise-microsoft-incident-response-lessons-on/ba-p/3753391
- https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/as-rep-roasting-using-rubeus-and-hashcat
- https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/from-dnsadmins-to-system-to-domain-compromise
10. Conclusion
Keeping an Active Directory (AD) secure takes effort, careful planning, and a good understanding of how attackers might try to break in. After looking at 250 PingCastle reports, we found that many organizations still have common mistakes and outdated setups that make them easy targets. Problems like giving users too many privileges, not securing important accounts, misconfiguring services like the Print Spooler, and ignoring relaying vulnerabilities give attackers the chance to take over entire systems.