1. Introduction
The vulnerability “AD Starter Scan – Kerberos Krbtgt” means the password for the KRBTGT account in Active Directory has not been changed recently. This is a security risk because this account holds the master key for all Kerberos authentication within the domain. A compromised KRBTGT account allows an attacker to forge tickets and take control of any user or service. Confidentiality, integrity, and availability are all at high risk if exploited.
2. Technical Explanation
The root cause is infrequent password rotation for the KRBTGT account. Attackers can exploit this by obtaining a copy of the current KRBTGT key hash through various means (e.g., credential dumping, pass-the-hash attacks). With this key, they can forge Kerberos tickets to impersonate any user or service in the domain. This requires local access to a domain controller or compromised credentials with sufficient privileges.
- Root cause: Infrequent KRBTGT password rotation.
- Exploit mechanism: An attacker obtains the current KRBTGT key hash and uses it to forge Kerberos tickets, granting them unauthorized access. For example, an attacker could use Mimikatz to dump credentials from a domain controller’s memory and extract the KRBTGT hash.
- Scope: Active Directory domains using default Kerberos configuration.
3. Detection and Assessment
You can confirm vulnerability by checking the last password change date for the KRBTGT account. A thorough method involves running a dedicated scan with Nessus or Security Center.
- Quick checks: Use PowerShell to check the ‘pwdLastSet’ attribute of the KRBTGT account.
Get-ADObject -Identity "NT AUTHORITYKRBTGT" -Property pwdLastSet | Select-Object pwdLastSet - Scanning: Nessus plugin ID 16328 (Active Directory Starter Scan – Kerberos Krbtgt). This is an example only, results may vary.
- Logs and evidence: Look for events related to KRBTGT account modifications in the Active Directory security logs. Event ID 4724 indicates a password change.
Get-ADObject -Identity "NT AUTHORITYKRBTGT" -Property pwdLastSet | Select-Object pwdLastSet4. Solution / Remediation Steps
The KRBTGT password must be changed using a precise sequence of operations to avoid disrupting domain authentication. Microsoft provides an official procedure and helper script.
4.1 Preparation
- Ensure you have access to a domain controller with appropriate administrative privileges. A roll back plan involves restoring from backup if necessary.
- Change windows should be scheduled during off-peak hours and require approval from the security team.
4.2 Implementation
- Step 1: Download the New-KrbtgtKeys.ps1 script from https://github.com/microsoft/New-KrbtgtKeys.ps1 to a domain controller.
- Step 2: Run the script with appropriate parameters, following Microsoft’s documentation. For example:
.New-KrbtgtKeys.ps1 -DomainController. - Step 3: Verify that all domain controllers have replicated the new KRBTGT key. Use the command
repadmin /showreplto check replication status.
4.3 Config or Code Example
Before
Get-ADObject -Identity "NT AUTHORITYKRBTGT" -Property pwdLastSet | Select-Object pwdLastSetAfter
Get-ADObject -Identity "NT AUTHORITYKRBTGT" -Property pwdLastSet | Select-Object pwdLastSet4.4 Security Practices Relevant to This Vulnerability
Regular password rotation is a key security practice for protecting sensitive accounts like KRBTGT. Least privilege access helps limit the impact if an account is compromised.
- Practice 1: Implement regular password rotation policies for all privileged accounts, including KRBTGT.
- Practice 2: Enforce least privilege access to minimize the potential damage from a compromised account.
4.5 Automation (Optional)
You can automate KRBTGT key rollover using scheduled tasks and PowerShell scripts. Be cautious when automating sensitive operations like this, and ensure proper logging and error handling are in place.
# Example script snippet - requires careful testing and configuration
# Schedule a task to run New-KrbtgtKeys.ps1 on a regular basis (e.g., every two years)
# Ensure the script is executed with appropriate permissions
5. Verification / Validation
Confirm the fix by checking that the KRBTGT password has been changed and that all domain controllers have replicated the new key. Test Kerberos authentication to ensure it still functions correctly.
- Post-fix check: Run
Get-ADObject -Identity "NT AUTHORITYKRBTGT" -Property pwdLastSet | Select-Object pwdLastSetand verify that the ‘pwdLastSet’ attribute has a recent timestamp. - Re-test: Re-run the Nessus plugin ID 16328 to confirm the vulnerability is no longer detected.
- Smoke test: Verify users can log in to Active Directory and access network resources.
- Monitoring: Monitor Active Directory security logs for events related to KRBTGT account modifications.
Get-ADObject -Identity "NT AUTHORITYKRBTGT" -Property pwdLastSet | Select-Object pwdLastSet6. Preventive Measures and Monitoring
Update security baselines to include regular KRBTGT password rotation as a requirement. Implement monitoring alerts for any unexpected changes to the KRBTGT account.
- Baselines: Update your Active Directory security baseline or Group Policy Objects (GPOs) to enforce a minimum password age for the KRBTGT account.
- Pipelines: Integrate checks into your CI/CD pipeline to ensure that any changes to Active Directory configuration comply with security policies.
- Asset and patch process: Review Active Directory configurations regularly as part of your asset management process.
7. Risks, Side Effects, and Roll Back
- Risk or side effect 1: Disruption to Kerberos authentication if replication fails. Mitigation: Monitor replication status closely and ensure all DCs are synchronized.
- Risk or side effect 2: Potential for service outages if the password change is not coordinated properly. Mitigation: Schedule changes during off-peak hours and communicate with stakeholders.
- Roll back: Restore Active Directory from a known good backup.
8. References and Resources
- Vendor advisory or bulletin: https://www.tenable.com/blog/new-in-nessus-find-and-fix-these-10-active-directory-misconfigurations