How to remediate – AD Starter Scan – Kerberoasting

1. Introduction

AD Starter Scan has identified a vulnerability, AD Starter Scan – Kerberoasting, where privileged accounts are susceptible to the Kerberoasting attack. This allows attackers to discover cleartext passwords of privileged domain user accounts and gain associated rights within an Active Directory environment. This affects systems running Active Directory with vulnerable account configurations. A successful exploit can lead to full domain compromise, impacting confidentiality, integrity, and availability.

2. Technical Explanation

Kerberoasting exploits the Kerberos authentication protocol by targeting privileged accounts. Attackers request Kerberos tickets for service principal names (SPNs) associated with these accounts. These tickets are then cracked offline to reveal the account passwords. The vulnerability occurs when SPNs are set on user accounts, enabling exhaustive password guessing. An attacker only needs a simple, unprivileged user account within the Active Directory domain to initiate this attack.

• Root cause: Setting Service Principal Names (SPNs) on user accounts instead of dedicated service accounts.
• Exploit mechanism: Attackers use tools like Rubeus or Impacket’s Kerberoast to request tickets for SPNs associated with privileged accounts, then crack the tickets offline using hashcat or similar tools. For example, an attacker could run `Rubeus kerberoast -U -d ` to enumerate and attempt to crack service tickets.
• Scope: Active Directory environments running Windows Server 2008 and later are affected. Accounts in groups like Domain Admins are typically targeted.

3. Detection and Assessment

You can confirm vulnerability by checking for SPNs set on user accounts. A thorough assessment involves enumerating all accounts with SPNs, especially those with high privileges.

• Quick checks: Use PowerShell to list users with SPNs: `Get-ADUser -Filter ‘ServicePrincipalName -like “*”‘ -Properties ServicePrincipalName | Where {$_.ServicePrincipalName} | Select SamAccountName, ServicePrincipalName`.
• Scanning: Nessus plugin ID 16397 can identify vulnerable accounts. This is an example only and may require tuning for accurate results.
• Logs and evidence: Look for Kerberos ticket requests in the Security event log (Event ID 4768) associated with privileged user accounts.

Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName | Where {$_.ServicePrincipalName} | Select SamAccountName, ServicePrincipalName

4. Solution / Remediation Steps

To protect privileged accounts from Kerberoasting, remove SPNs where possible or use unprivileged accounts for services requiring them. Increasing password complexity and using gMSAs are also effective measures.

4.1 Preparation

• No services need to be stopped, but understand the impact of removing SPNs on service functionality. Roll back by re-adding the SPN if needed.
• Changes should be reviewed and approved by a domain administrator.

4.2 Implementation

1. Step 1: Identify users with SPNs using the PowerShell command from Section 3.
2. Step 2: For each user, determine if the SPN is required for functional reasons.
3. Step 3: If not required, remove the SPN using `Set-ADUser -Identity -Clear ServicePrincipalName`.
4. Step 4: If an SPN is required, create a dedicated unprivileged service account and assign it the necessary permissions instead of using a privileged user account.

4.3 Config or Code Example

Before

Get-ADUser -Identity "Administrator" | Select SamAccountName, ServicePrincipalName

After

Set-ADUser -Identity "Administrator" -Clear ServicePrincipalName

4.4 Security Practices Relevant to This Vulnerability

Several security practices can mitigate Kerberoasting risks. Least privilege reduces the impact of compromised accounts, while strong password policies make cracking tickets more difficult.

• Practice 1: Implement least privilege by granting users only the permissions they need.
• Practice 2: Enforce complex passwords and regularly rotate them. Consider using Group Managed Service Accounts (gMSAs) for services instead of user accounts.

4.5 Automation (Optional)

A PowerShell script can automate SPN removal, but exercise caution when modifying Active Directory configurations.

#WARNING: Test thoroughly before running in production!
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName | Where {$_.ServicePrincipalName} | ForEach {
  Set-ADUser -Identity $_.SamAccountName -Clear ServicePrincipalName
}

5. Verification / Validation

• Post-fix check: Run `Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName | Where {$_.ServicePrincipalName} | Select SamAccountName, ServicePrincipalName`. The output should be empty for privileged accounts.
• Re-test: Re-run the Nessus scan (plugin ID 16397) to confirm the vulnerability is no longer detected.
• Smoke test: Verify that key services relying on these accounts are still functioning as expected. For example, file shares and print servers.
• Monitoring: Monitor Security event logs for unusual Kerberos activity related to privileged accounts.

Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName | Where {$_.ServicePrincipalName} | Select SamAccountName, ServicePrincipalName

6. Preventive Measures and Monitoring

Update security baselines to include SPN restrictions on user accounts. Implement CI/CD pipeline checks to prevent the creation of vulnerable configurations. Regular patch reviews help identify and address potential vulnerabilities.

• Baselines: Update your Active Directory security baseline or Group Policy Objects (GPOs) to restrict setting SPNs on user accounts.
• Asset and patch process: Review Active Directory configurations regularly as part of a vulnerability management program.

7. Risks, Side Effects, and Roll Back

Removing SPNs may disrupt service functionality if they are required. Always test thoroughly before making changes in production. If issues occur, re-add the SPN using `Set-ADUser -Identity -ServicePrincipalName ""`.

• Risk or side effect 1: Removing a necessary SPN can cause service outages. Mitigation: Test in a non-production environment first.
• Risk or side effect 2: Incorrectly configured unprivileged accounts may not have sufficient permissions, leading to application errors. Mitigation: Carefully review and test new account configurations.
• Roll back: 1) Identify the user account affected. 2) Re-add the SPN using `Set-ADUser -Identity -ServicePrincipalName ""`.

8. References and Resources

• Vendor advisory or bulletin: Updated on December 27, 2025