NOTEThis article was first published on dfir.ch
Introduction
In the realm of IT infrastructure, Active Directory (AD) serves as a crucial backbone, enabling organizations to manage users, devices, and resources efficiently. However, given its central role, it also presents a significant security target, and maintaining its integrity is paramount. Misconfigurations and overlooked security gaps in AD can expose an organization to critical vulnerabilities, leading to potential breaches, data theft, and system downtime.
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).
1. ADCS (Active Directory Certificate Services
1.1 - Introduction
Figure 1: Certified Pre-Owned
The whitepaper Certified Pre-Owned: Abusing Active Directory Certificate Services by Will Schroeder and Lee Christensen introduced new attack vectors and techniques for gaining domain administrative rights through Active Directory Certificate Services (AD CS). Their research demonstrates how attackers—and defenders—can leverage the Certify tool, developed by SpecterOps, to discover and exploit vulnerable certificates within a network. Below is an excerpt showcasing an example of a vulnerable certificate, sourced from ired.team.
Figure 2: Vulnerable certificate
In the screenshot above, the presence of ENROLLEE_SUPPLIES_SUBJECT indicates that a user requesting a certificate based on this template can specify any subject, including domain administrators. This means attackers could potentially request certificates impersonating high-privilege accounts. 🤯 Additionally, the Client Authentication setting under PkiExtendedKeyUsage allows the certificate created from this template to be used for authentication against machines within Active Directory, effectively granting access across the network.
With the Enrollment Rights set to NT Authority\Authenticated Users, any authenticated user in the domain has the ability to generate a new certificate based on this template. For an in-depth analysis of these vulnerabilities, additional details are available here.
Once the vulnerable certificate template has been identified, we can request a new certificate on behalf of a domain administrator using Certify. [..] Once we have the certificate in cert.pfx, we can request a Kerberos TGT for the user for which we minted the new certificate. (Source: ired.team)
Figure 3: Rubeus - Requesting a Kerberos TGT
In a nutshell - it’s practically game over at this point. While this overview covers some of the main attack vectors, there are numerous other techniques targeting vulnerable certificates (as detailed in the original SpecterOps whitepaper), and ongoing research continues to uncover new threats in this area.
Discussions with customers show that awareness of these risks is still alarmingly low among administrators and IT security professionals. This underscores the urgent need for better education and more proactive security measures.
1.2 - Findings
1.2.1 - At least one certificate template can be modified by anyone
A certificate template is an object whose definition serves as a base to issue certificates. If a user has the right to edit it, it can manually change obscure attributes such as msPKI-Certificate-Name-Flag. Doing so will enable him to provide the subject of the certificate and thus having a certificate on behalf other users such as admins. It can be used to impersonate them and take control of the domain.
Affected Domains: 19/250
1.2.2 - At least one certificate used for authentication can have it’s subject modified when being used
Usually, the subject of a certificate is generated automatically by the certification authority. By allowing editing before its issuance, a malicious user can set the subject to an administrator account, and thus get a certificate representing them. This certificate can be abused later to impersonate them.
Figure 4: PingCastle ADCS check
Affected Domains: 24/250
1.3 - References & Tools
- https://posts.specterops.io/certified-pre-owned-d95910965cd2
- https://riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
- https://m365internals.com/2022/11/07/investigating-certificate-template-enrollment-attacks-adcs/
- https://blackhillsinfosec.com/abusing-active-directory-certificate-services-part-one/
- https://services.google.com/fh/files/misc/active-directory-certificate-services-hardening-wp-en.pdf
- https://github.com/jakehildreth/Locksmith
2. Service Accounts
2.1 - Introduction
We frequently discover service accounts configured with excessive privileges during our Active Directory assessments and incident response engagements. In many instances, these accounts are assigned elevated permissions, such as membership in the Domain Administrators group—far exceeding what is necessary for their intended purpose. This overprovisioning represents a significant security risk.
The problem is compounded when these service accounts are protected with weak or easily guessable passwords. Given their elevated privileges, these accounts become prime targets for attackers. If compromised, they can grant unauthorized access to critical systems, facilitate lateral movement within the network, and potentially lead to a complete domain compromise.
Additionally, service accounts often fall outside the scope of regular monitoring and password management policies applied to user accounts. Many have non-expiring passwords, leaving them increasingly vulnerable over time. Attackers can exploit these gaps to establish persistent access, evade detection, and circumvent response efforts, further magnifying the security threat.
Figure 5: Service account, which is part of the Domain Admin group
2.2 - Findings
2.2.1 - No password policy for service accounts found
The purpose is to give information regarding a best practice for the Service Account password policy. Indeed, having a 20+ characters password for this account greatly helps reducing the risk of Kerberoasting attacks (offline cracking of the TGS tickets)
Affected Domains: 240/250
2.2.2 - Check if Service Accounts (aka accounts with never expiring password) are domain administrators
The purpose is to check for accounts with non-expiring passwords in the “Domain Administrator” group PingCastle is checking accounts with never expiring password, that are mostly used as service accounts. “Service Accounts” can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don’t change and can be used in Kerberoast attacks.
Affected Domains: 158/250
2.2.2 - Admin Accounts are Kerberoastable
The purpose is to ensure that the password of admin accounts cannot be retrieved using 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
2.3 - References & Tools
- https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/total-identity-compromise-microsoft-incident-response-lessons-on/ba-p/3753391
- https://www.synacktiv.com/publications/a-dive-into-microsoft-defender-for-identity.html
- https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/group-managed-service-accounts-overview
3. Passwords
3.1 - Introduction
In our incident response cases, we frequently encounter local administrator accounts or accounts within the local administrator group that are secured with weak passwords—making them prime targets for lateral movement.
Also, regularly review the properties of Active Directory objects, paying particular attention to the description field, as it may inadvertently contain sensitive information such as passwords.
Figure 6: Querying the user properties
LAPS is the Microsoft solution to automatically manage the password for the built-in Administrator account on Windows devices. When machines are built or imaged, they often have the same password for the built-in Administrator account. If this is never changed, a single password can give local administrative rights to all machines and may provide opportunities for lateral movement. LAPS solves this problem by ensuring each device has a unique local administrator password and rotates it regularly. - Total Identity Compromise: Microsoft Incident Response lessons on securing Active Directory
3.2 - Findings
3.2.1 - Obfuscated Passwords
PingCastle attempts to identify passwords stored in GPOs. If PingCastle was able to retrieve a password, attackers can also obtain it and so the account should be considered compromised. Note that Microsoft published the AES key used to encrypt passwords in GPOs, which is why even an encrypted password is insecure.
Figure 7: Obfuscated passwords
As seen in the wild: One notable TTP observed by APT29 was the hunting for passwords stored in SYSVOL. This technique relies on passwords that are stored as part of Group Policy Preferences. - Trello From the Other Side: Tracking APT29 Phishing Campaigns
Affected Domains: 47/250
3.2.2 - Presence of accounts with non-expiring passwords in the domain admin group
Some accounts have passwords which never expire. Should an attacker compromise one of these accounts, he would be able to maintain long-term access to the Active Directory domain.
Affected Domains: 245/250
3.2.3 - Number of admin with a password older than 3 years
The purpose is to ensure that all admins are changing their passwords at least every 3 years
Affected Domains: 198/250
3.2.4 - Number of accounts that can have an empty password
An account can be set without a password if it has the flag “PASSWD_NOTREQD” set as “True” in the “useraccountcontrol” attribute. This represents a high security risk as the account is not protected at all without a password
Affected Domains: 110/250
4. PowerShell Script Block Logging
4.1 - Introduction
Strictly speaking not part of a guide about hardening Active Directory, but I must stress once again the importance of logging executed PowerShell code on clients and servers. In the year’s “Year in Review” (2022) of TalosSecurity, PowerShell’s Invoke-Expression is listed as number 1 of the most alerted Behavioral Protection signatures (see references below).
Figure 8: PowerShell Invoke-Expression
4.2 - Findings
4.2.1 - The PowerShell audit configuration is not fully enabled
PowerShell is a powerful language, also used by hackers because of this quality. Hackers are able to run programs such as mimikatz in memory using obfuscated commands such as Invoke–Mimikatz. Because there is no artefact on the disk, the incident response task is difficult for the forensic analysts. For this reason, we recommend to enable PowerShell logging via a group policy, despite the fact that these security settings may be part of the workstation or server images.
Affected Domains: 231/250
4.3 - References & Tools
- https://x.com/malmoeb/status/1627214815012716546
- https://www.calcomsoftware.com/ensure-turn-on-powershell-script-block-logging-is-set-to-disabled/
- https://blog.talosintelligence.com/talos-year-in-review-2022/
- https://www.splunk.com/en_us/blog/security/hunting-for-malicious-powershell-using-script-block-logging.html
- https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+powershell.file.script_block_text+language%3ATOML&type=code&l=TOML
5. Add Computers to the Domain
5.1 - Introduction
A customer called us because he discovered two new computers within his computer objects that did not match his naming scheme.
Figure 9: SAMTHEADMIN computer object
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.
Figure 10: sam-the-admin exploit
In addition to the exploit presented above, various other attack techniques rely on the fact that an unprivileged user can create new computer objects within the domain. The best way to prevent such attacks is to remove this privilege from all users on the network and only explicitly assign it to a particular group (supporters, IT administrators, etc.).
Ping Castle also checks the value of MachineAccountQuota and outputs a corresponding finding if the value is < 0. This default configuration represents a security issue as regular users shouldn’t be able to create such accounts, and administrators should handle this task.
5.2 - Findings
5.2.1 Non-admin users can add up to 10 computers to the domain
By default, a basic user can register up to 10 computers within the domain. This default configuration represents a security issue as basic users shouldn’t be able to create such accounts and this task should be handled by administrators.
Affected Domains: 171/250