If you have a traditional domain, it’s time to audit your Active Directory. In fact, it’s probably way past time. You probably have accounts that have been unchanged for years and might not have reviewed settings or registry entries. Attackers know that these domains have legacy settings that allow them to take greater control and use techniques to gain domain rights. Active Directory security came into the news with the release of several updates in May, you need to take many more steps than mere patching to protect your network.
Microsoft’s server tools include Best Practices Analyzer (BPA), but it doesn’t identify some of the means that attackers use to go after Active Directory domains. Several other resources analyze the health and security of Active Directory domains including Purple Knight from Semperis, PingCastle, or Quest’s Active Directory health check tool.
I ran PingCastle on a sample domain, and it became obvious that I had a lot of work to do. I had likely forgotten many older pieces in our network that now threatened its security. Here’s how I analyzed my Active Directory status.
Identify unsupported operating systems
First, I looked for unsupported server operating systems in the domain. Windows Server 2012 R2 drops out of support on October 10, 2023. My guess is many of you have that or earlier platforms in your network, probably not patched. These older platforms are often running SMB v1, which allows for weaker protocols.
Scan for weak Kerberos encryption
Next, the tool checks for the use of Kerberos with weak encryption or DES encryption. They recommend that you disabled this in the property of an account by unchecking the box “Use Kerberos DES encryption for this account”. As the PingCastle documentation notes, you can also detect which accounts support Kerberos DES encryption by running: Get-ADUser -Filter {UserAccountControl -band 0x200000}.
Identify old and unused accounts
Other tests the tool performs review for stale or inactive accounts in the network. Accounts that haven’t been logged into in years often have weak or insecure passwords. Worse, these passwords may be available to attackers on harvested password sites.
Block basic users from registering computers
Change a longstanding default that allows basic users to add registration of computers. This setting is in the news lately due to PetitPotam and other vulnerabilities. Modify the value of ms-DS-MachineAccountQuota to zero (0).
Review non-expiring passwords
Review non expiring passwords used in the domain. Remedy this by using two-factor authentication through third-party keys or software solutions to provide additional protection especially for remote access. While you are reviewing passwords, ensure that any administrator or privileged accounts have long and complex passwords or are moved to managed service accounts.
Enable Active Directory recycle bin
Review whether the AD domain’s recycle bin feature is enabled. You’ll need to be on a forest level of at least Server 2008 R2 or higher and then check the level with Get-ADForest. Enable the feature using the PowerShell command:
Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target 'test.mysmartlogon.com'
Change Kerberos passwords regularly
The disabled Kerberos account is often overlooked in a domain. Change the password for the krbtgt account on a regular basis. As the PingCastle points out, a Microsoft script can be run to guarantee the correct replication of these secrets. Unfortunately, this script supports only English operating systems. Another way is to reset the password manually once, wait three days, then reset it again. This is the safest to ensure the password is no longer usable by the golden ticket attack.
Change settings to avoid certificate abuse
Attackers can use certificates to launch attacks. One techniques uses certificate request templates. If editing before a certificate’s issuance is allowed, a malicious user can set the subject to an administrator account and assign the certificate to them. On the certificate template properties in the property sheet “Subject Name”, uncheck the field “Supply in the request”. Alternatively, restrict this template to a specific group.
Set domain controller audit policies
Set audit policies in your domain controller for specific issues. The PingCastle review recommends the following audit settings:
- Policy Change / Authentication Policy Change
- No GPO check for audit success
- Collect events 4713, 4716, 4739, 4867 to track trust modifications
- Account Management / Computer Account Management
- No GPO check for audit success
- Collect events 4741, 4742 to track computer changes
- Detailed Tracking / DPAPI Activity
- No GPO check for audit success
- Collect event 4692 to track the export of DPAPI backup key
- Account Logon / Kerberos Authentication Service
- No GPO check for audit success
- Collect events 4768, 4771 for Kerberos authentication
- Account Logon / Kerberos Service Ticket Operations
- No GPO check for audit success
- Collect events 4769 for Kerberos authentication
- Logon/Logoff / Logoff
- No GPO check for audit success
- Collect events 4634 for account logoff
- Logon/Logoff / Logon
- No GPO check for audit success
- Collect events 4624, 4625, 4648 for account logon
- Detailed Tracking / Process Creation
- No GPO check for audit success
- Collect event 4688 to get the history of executed programs
- Account Management / Security Group Management
- No GPO check for audit success
- Collect events 4728, 4732, 4756 for group membership change
- System / Security System Extension
- No GPO check for audit success
- Collect events 4610, 4697 to track LSASS security packages and services
- Privilege Use / Sensitive Privilege Use
- No GPO check for audit success
- Collect events 4672, 4673, 4674 for privileges tracking such as the debug one
- Logon/Logoff / Special Logon
- No GPO check for audit success
- Collect event 4964 for special group attributed at logon
- Account Management / User Account Management
- No GPO check for audit success
- Collect events 4720,22,23,38,65,66,80,94 for user account management
Enable PowerShell logging
Ensure that PowerShell logging is enabled. From Group Policy, follow these steps:
- Go to “Computer Configuration”.
- Go to “Administrative Templates”.
- Go to “Windows Components”.
- Go to Windows PowerShell”.
- Enable “Turn on Module logging” and “Turn on PowerShell Script Block logging”.
- Set “*” as the module list.
You may think you have done enough to secure Active Directory, but often you need third-party eyes or tools to help you understand that you are still at risk. Take the time to review your Active Directory. You may be surprised that you have more work to do to ensure that you are more protected.
Copyright © 2022 IDG Communications, Inc.
