From domain data to defensible identity security decisions.
This report provides visibility into the security posture of the organization's Active Directory environment, enabling stakeholders to identify risk, evaluate security controls, and prioritize remediation efforts.
At a Glance
A high-level read on where risk concentrates and where you can move the needle quickly.
Pass / Fail
Overall checks passed versus failed.
Findings by Risk Level
Distribution of findings by risk level.
Findings by Category
Distribution of findings by category, sorted by highest count.
Quick Wins
Highest-impact, lowest-effort remediations.
Top 10 Riskiest Findings
Highest-severity findings, ordered by impact.
Since Last Scan
How findings have shifted since the previous scan, and severity across recent runs.
Severity Trend Over Time
Critical / High / Moderate / Low across recent scans.
Change Highlights
How findings shifted since the previous scan (July 12, 2026).
Assessment Journey
Each milestone summarizes risk posture, changes, and key takeaways.
- Critical8
- High23
- Moderate17
- Low11
- Initial baseline established
- Use this scan as the starting point for measuring remediation progress, ownership, and risk reduction.
- Prioritize critical and high findings first before expanding effort to moderate and low exposure.
- Critical9
- High24
- Moderate18
- Low11
- Risk Score decreased (-18)
- Total findings increased (+3)
- Severity shift: Critical +1, High +1, Moderate +1
- Review newly introduced or worsened findings to determine root cause.
- Assign ownership for high-impact issues before the next scan to prevent the risk trend from continuing.
- Critical8
- High23
- Moderate17
- Low11
- Risk Score increased (+18)
- Total findings decreased (-3)
- Severity shift: Critical -1, High -1, Moderate -1
- Continue the remediation approach that reduced risk and validate that fixes remain in place.
- Shift attention to persistent findings that have not changed across recent scans.
Findings
Every issue identified by the scan, grouped by category. Click any card for the description, attacker context, and remediation guidance.
Authentication and Authorization
15 findings
Accounts Vulnerable to Kerberoasting
Accounts Vulnerable to Kerberoasting
Accounts Vulnerable to Kerberoasting
Kerberoasting is an attack technique where attackers extract service account credentials from a Kerberos ticket. By requesting a service ticket for a target account, attackers can obtain the ticket and perform an offline brute-force attack to crack the password. This method exploits weak service account passwords and can lead to unauthorized access of critical systems and data. What increases the danger of this attack is that any AD user can request the tickets.
After obtaining access to a domain, kerberoasting is a popular first attack to perform privilege escalation. Attackers choose this path when they don’t have a privileged position in the environment and are looking to elevate privileges. Once password hashes are obtained, the attacker will leverage their favorite password lists and rulesets against the hashes until they are cracked. Kerberos hashes are large in comparison to many other hashes obtained during hacking activities, though the computational power of newer graphics cards make cracking password hashes significantly more effective.
Recommendation
Strengthen or rotate Kerberoastable service account passwords, migrate eligible accounts to gMSA, and validate updated password age and SPN ownership.
Prerequisites
- Domain Admin or Password Reset rights for service accounts in scope.
- Service owner identification and sign-off for each affected account.
- Inventory of services and applications dependent on each account's credentials.
- Change control approval obtained.
- Rollback plan prepared for service restart in case of disruption.
Remediation Objective
- Assign strong, complex passwords (25 characters or more) to all Kerberoastable service accounts.
- Migrate service accounts to Group Managed Service Accounts (gMSA) wherever the application supports it.
- Implement a regular password rotation policy for any service accounts that cannot use gMSA.
- Monitor for Kerberos service ticket requests targeting sensitive accounts.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Reset the password on a service account to a strong, randomly generated value.
# Replace <SamAccountName> with the target service account name.
$NewPassword = ConvertTo-SecureString (New-Guid).ToString() + "!Aa1" -AsPlainText -Force
Set-ADAccountPassword -Identity "<SamAccountName>" -Reset -NewPassword $NewPassword -PassThru# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of service accounts to remediate.
# CSV must contain columns: SamAccountName
$Accounts = Import-Csv -Path ".\ApprovedServiceAccounts.csv"
# Reset each service account password with a strong random value.
foreach ($Account in $Accounts) {
$NewPassword = ConvertTo-SecureString ((New-Guid).ToString() + "!Aa1") -AsPlainText -Force
Set-ADAccountPassword -Identity $Account.SamAccountName -Reset -NewPassword $NewPassword -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after the change has been reviewed and approved.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected service accountNavigate to the OU or container containing the service account identified in the report.
- Reset the passwordRight-click the account and select Reset Password. Enter a strong, complex password of at least 25 characters. Uncheck User must change password at next logon.
- Update the dependent serviceLog in to the server or application hosting the service using this account. Update the service logon credentials with the new password using
Services.mscor the application's configuration interface. - Restart the serviceRestart the dependent service to apply the new credentials and confirm it starts successfully.
Validation
- Confirm the password last set date has been updated: Get-ADUser -Identity <SamAccountName> -Properties PasswordLastSet.
- Verify the dependent service is running and authenticating successfully.
- Request a Kerberos service ticket for the account and confirm it requires significantly more computational effort to crack (validated by password strength).
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after export of PasswordLastSet attribute for affected accounts.
- Service health validation results confirming dependent services are running.
- Change ticket and approval record.
- PowerShell transcript of password reset commands.
Additional Guidance
Kerberoasting is an attack technique that cannot be fully prevented for accounts with SPNs, as any authenticated domain user can request service tickets. The most effective defense is to make the resulting hash computationally impractical to crack by using passwords of 25 characters or more. Organizations should prioritize migrating service accounts with SPNs to Group Managed Service Accounts, which use automatically managed, high-entropy passwords that are effectively immune to offline cracking.
Monitoring should be configured to alert on anomalous service ticket request patterns, such as a single account requesting tickets for a large number of SPNs in a short time period. While false positive rates can be high, these alerts are a valuable early warning mechanism for active Kerberoasting campaigns.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Dennis.Reynolds | Dennis.Reynolds | Yes | Apr 11, 2025 | Never | Apr 11, 2025 |
| Nightman | Nightman | Yes | May 7, 2025 | Never | May 7, 2025 |
Accounts with Non-Expiring Passwords
Accounts with Non-Expiring Passwords
Accounts with Non-Expiring Passwords
Password expiration is not enforced on the reported accounts. The longer a password is in use, the longer attackers have to crack password hashes, actively control the account, or perform credential-based attacks against them. These accounts are often service accounts which typically have additional privileges and are targeted by attackers.
Account hashes are often obtained via network poisoning attacks or Kerberos-based attacks. Some of these attacks are difficult to detect, giving adversaries plenty of time to conduct password cracking. With today’s processing power, accounts without password rotation will eventually be compromised.
Recommendation
Remove the Password Never Expires flag from affected accounts, apply an approved rotation model, and document any business-approved exceptions.
Prerequisites
- Domain Admin or Account Operators rights to modify account attributes.
- Service owner identification and sign-off for all service accounts in scope.
- Inventory of services and applications dependent on each account.
- PAM solution enrollment considered as a preferred alternative for service accounts.
- Change control approval obtained.
Remediation Objective
- Enable password expiration for all accounts identified with the Password Never Expires flag.
- Coordinate with service owners to update service configurations after password resets.
- Enroll service accounts in a PAM solution or migrate to Group Managed Service Accounts (gMSA) where supported.
- Establish a password rotation schedule for accounts that cannot use gMSA.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Enable password expiration on a single account.
# Replace <SamAccountName> with the target account.
Set-ADUser -Identity "<SamAccountName>" -PasswordNeverExpires $false# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remediate.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName -PasswordNeverExpires $false -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected accountNavigate to the OU or container containing the account identified in the report.
- Open account propertiesDouble-click the account and navigate to the Account tab.
- Clear the password never expires optionIn the Account options list, uncheck the option Password never expires.
- Save changesClick OK or Apply. Coordinate with the service owner to update the service configuration before the password next expiration date.
Validation
- Confirm the PasswordNeverExpires attribute is False: Get-ADUser -Properties PasswordNeverExpires.
- Verify the account is subject to the domain password policy or a Fine-Grained Password Policy.
- Confirm dependent services are updated with a rotation plan in place.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after PasswordNeverExpires attribute export.
- Service health validation confirming rotation plan is in place.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
Non-expiring passwords should be limited to documented exceptions with compensating controls. Prioritize privileged, service, and externally exposed accounts, then move toward managed service accounts, vaulting, or PAM where long-lived credentials are currently required.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Administrator | Yes | Jun 30, 2021 | May 23, 2025 | Apr 14, 2025 | |
| Frank.Reynolds | Frank.Reynolds | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 |
| Liam.McPoyle | Liam.McPoyle | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Dayman | Dayman | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Mrs.Mac | Mrs. Mac | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Carmen | Carmen | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Gail.Snail | Gail.Snail | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Dennis.Reynolds | Dennis.Reynolds | Yes | Apr 11, 2025 | Never | Apr 11, 2025 |
| Nightman | Nightman | Yes | May 7, 2025 | Never | May 7, 2025 |
| Luther.McDonald | Luther.McDonald | Yes | May 8, 2025 | Never | May 8, 2025 |
| Dee.Reynolds | Dee.Reynolds | Yes | May 19, 2025 | Never | May 19, 2025 |
| Charlie.Kelly | Charlie.Kelly | Yes | May 19, 2025 | Never | May 19, 2025 |
| Ronald.McDonald | Ronald.McDonald | Yes | Jun 10, 2025 | Jun 10, 2025 | Jun 10, 2025 |
| Rickety.Cricket | Rickety.Cricket | Yes | Jul 2, 2025 | Never | Jul 2, 2025 |
| Roxy | Roxy | Yes | Jul 3, 2025 | Never | Never |
| Barbara.Reynolds | Barbara.Reynolds | Yes | Jul 3, 2025 | Never | Never |
| Ryan.McPoyle | Ryan.McPoyle | Yes | Jul 3, 2025 | Never | Never |
| Psycho.Pete | Psycho.Pete | Yes | Jul 3, 2025 | Never | Never |
| Da.Maniac | Da.Maniac | Yes | Jul 3, 2025 | Never | Never |
| Rex | Rex | Yes | Jul 3, 2025 | Never | Never |
| Ruby.Taft | Ruby.Taft | Yes | Jul 3, 2025 | Never | Never |
| Schmitty | Schmitty | Yes | Jul 3, 2025 | Never | Never |
| Duncan | Duncan | Yes | Jul 3, 2025 | Never | Never |
| Z | Z | Yes | Jul 3, 2025 | Never | Never |
| Hwang | Hwang | Yes | Jul 3, 2025 | Never | Never |
| Lawyer | Lawyer | Yes | Jul 3, 2025 | Never | Never |
| Ben.Smith | Ben.Smith | Yes | Jul 3, 2025 | Never | Never |
| svc_Green.Man | svc_Green.Man | Yes | Jul 3, 2025 | Never | Never |
| svc_Bird.Law | svc_Bird.Law | Yes | Jul 3, 2025 | Never | Never |
| svc_Fight.Milk | svc_Fight.Milk | Yes | Jul 3, 2025 | Never | Never |
| svc_Rum.Ham | svc_Rum.Ham | Yes | Jul 3, 2025 | Never | Never |
| svc_Wolf.Cola | svc_Wolf.Cola | Yes | Jul 3, 2025 | Never | Never |
| svc_Ingrid.Nelson | svc_Ingrid.Nelson | Yes | Jul 3, 2025 | Never | Never |
| svc_Kitten.Mittens | svc_Kitten.Mittens | Yes | Jul 3, 2025 | Never | Never |
| svc_Milk.Steak | svc_Milk.Steak | Yes | Jul 3, 2025 | Never | Never |
| John.Thundergun | John.Thundergun | Yes | Jul 3, 2025 | Never | Never |
| Doyle.McPoyle | Doyle.McPoyle | Yes | Jul 3, 2025 | Never | Never |
| Byron | Byron | Yes | Jul 3, 2025 | Never | Never |
| Waiter | Waiter | Yes | Jul 3, 2025 | Never | Never |
| Donna.Brunswick | Donna.Brunswick | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Jack.Bauer | Jack.Bauer | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Gladys.Reynolds | Gladys.Reynolds | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Shelly.Kelly | Shelly.Kelly | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Pappy.McPoyle | Pappy.McPoyle | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Margaret.McPoyle | Margaret.McPoyle | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Peter.Nincompoop | Peter.Nincompoop | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Brian.LeFevre | Brian.LeFevre | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Vic.Vinegar | Vic.Vinegar | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Hugh.Honey | Hugh.Honey | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Mantis.Toboggan | Mantis.Toboggan | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Ongo.Gablogian | Ongo.Gablogian | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Desert.Grape | Desert.Grape | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Invigaron | svc_Invigaron | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Franks.Fluids | svc_Franks.Fluids | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Paddy.Wagon | svc_Paddy.Wagon | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Electric.Dream.Machine | svc_Electric.Dream.Machine | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Paddy.Dollars | svc_Paddy.Dollars | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Lil.Kev | Lil.Kev | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Chase.Utley | Chase.Utley | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Edurado.Sanchez | Edurado.Sanchez | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Dr.Jinx | Dr.Jinx | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Don.Cheadle | Don.Cheadle | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Tiger.Woods | Tiger.Woods | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Shadynasty | svc_Shadynasty | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
Accounts with Non-Standard Primary ID's
Accounts with Non-Standard Primary ID's
Accounts with Non-Standard Primary ID's
Accounts with non-standard Primary Group IDs (PGID), may indicate hidden or misconfigured group memberships. The Primary Group ID is typically set to default values, such as Users (513/514), Computers (514/515), and Domain Controllers (516/521). Attackers can exploit non-standard PGIDs to obscure privileged access or bypass membership audits, making it difficult to detect unauthorized access or escalation.
Accounts with non-standard PGIDs are easily discoverable with hacker toolsets and are regularly a first target. These accounts are frequently leveraged to compromise accounts that aren’t properly protected by expected GPOs or to bypass alerting of Domain Administrator additions.
Recommendation
Review accounts with non-standard primary group IDs, reset unnecessary deviations, and document any approved operational requirement.
Prerequisites
- Domain Admin rights to modify the primaryGroupID attribute.
- Investigation completed to determine whether the non-standard PGID was intentionally set.
- Change control approval obtained.
Remediation Objective
- Investigate each account to determine the reason for the non-standard Primary Group ID.
- Reset the Primary Group ID to the appropriate standard value (513 for domain users, 515 for computers, 516 for domain controllers).
- Confirm GPO application and group membership visibility are correct after the change.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Reset the Primary Group ID to the standard Domain Users value (513).
# Replace <SamAccountName> with the target account.
# Standard values: Domain Users = 513, Domain Computers = 515, Domain Controllers = 516
Set-ADUser -Identity "<SamAccountName>" -Replace @{primaryGroupID = 513}# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remediate.
# CSV must contain columns: SamAccountName, PrimaryGroupID
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName -Replace @{primaryGroupID = [int]$Account.PrimaryGroupID} -WhatIf
Write-Output "Processed: $($Account.SamAccountName) -> PrimaryGroupID: $($Account.PrimaryGroupID)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open ADSI EditLaunch
adsiedit.mscfrom an administrative workstation. - Connect to the domainRight-click ADSI Edit, select Connect to, and choose Default naming context.
- Locate the affected accountNavigate to the container holding the account and double-click the account object to open its attribute editor.
- Modify the primaryGroupID attributeLocate primaryGroupID in the attribute list. Double-click to edit and set the value to the appropriate standard (513 for domain users).
- Apply changesClick OK to save.
Validation
- Confirm the primaryGroupID attribute has been updated: Get-ADUser -Properties primaryGroupID.
- Verify GPO application is as expected using gpresult /r on a system the account logs into.
- Confirm group membership visibility in Active Directory tools is correct.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after primaryGroupID attribute export.
- Change ticket and approval record.
- GPO application verification.
- Follow-up scan results showing finding resolved.
Additional Guidance
Align PGIDs with organizational standards, and investigate any deviations. Monitoring changes to PGIDs and group membership attributes can help prevent unauthorized privilege escalation. Some PAM and identity tools may not identify these accounts correctly if they rely on standard primary group assumptions. Some organizations choose to change the Primary Group ID of accounts to enforce or not enforce certain GPOs, so it’s suggested to review these accounts thoroughly to ensure they are properly protected as expected.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Rickety.Cricket | Rickety.Cricket | Yes | Jul 2, 2025 | Never | Jul 2, 2025 |
| Computer | Operating System | Created | Last Logon | Password Set |
|---|---|---|---|---|
| FIGHTMILK-PC01$ | Jul 3, 2025 | Never | Jul 3, 2025 |
Accounts with No Password Requirement
Accounts with No Password Requirement
Accounts with No Password Requirement
Password requirement settings are not enforced on the reported accounts. While GPOs may override this setting, there are various scenarios where this may not be the case. For example, if the account had an empty password set before the policy was implemented. It’s a best practice to set it on the account as well as the GPO. You could audit this by supplying an empty password or looking at the password hashes from your domain controller as the hashes are not salted.
Password spraying via SMB with tools like CrackMapExec are commonly used to identify an account with an empty password. Accounts with empty passwords allow a malicious attacker an authenticated position in the network, provides lateral movement, and possibly privilege escalation. Many threat actors will save these accounts for later use to maintain persistence in the environment.
Recommendation
Remove the PASSWD_NOTREQD flag from affected accounts, set compliant passwords where needed, and validate that domain password policy applies.
Prerequisites
- Domain Admin or Account Operators rights to modify account attributes.
- Confirm whether affected accounts currently have empty passwords; if so, coordinate a password reset.
- Service owner notification for any service accounts in scope.
- Change control approval obtained.
Remediation Objective
- Remove the PASSWD_NOTREQD flag from all identified accounts.
- Set a strong password on any account that currently has an empty password.
- Ensure that the domain password policy applies to all accounts after the flag is cleared.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove the PASSWD_NOTREQD flag from a user account.
# Replace <SamAccountName> with the target account.
$Account = Get-ADUser -Identity "<SamAccountName>" -Properties UserAccountControl
$NewUAC = $Account.UserAccountControl -band -bnot 0x20
Set-ADUser -Identity "<SamAccountName>" -Replace @{UserAccountControl = $NewUAC}
# If the account has an empty password, reset it to a strong value.
Set-ADAccountPassword -Identity "<SamAccountName>" -Reset `
-NewPassword (Read-Host -AsSecureString "Enter new password")# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remediate.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
$ADUser = Get-ADUser -Identity $Account.SamAccountName -Properties UserAccountControl
$NewUAC = $ADUser.UserAccountControl -band -bnot 0x20
Set-ADUser -Identity $Account.SamAccountName -Replace @{UserAccountControl = $NewUAC} -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected accountNavigate to the OU or container containing the account identified in the report.
- Open account propertiesDouble-click the account and navigate to the Account tab.
- Clear the no-password flagIn the Account options list, uncheck the option Password not required.
- Set a password if neededIf the account has an empty password, right-click the account and select Reset Password to assign a strong password.
- Save changesClick OK or Apply.
Validation
- Confirm the PASSWD_NOTREQD flag is cleared: Get-ADUser -Properties UserAccountControl and verify bit 0x20 is not set.
- Verify the account has a password set by checking the PasswordLastSet attribute.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after UserAccountControl attribute export.
- PasswordLastSet attribute confirmation.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
Accounts without password requirements represent a direct path to unauthenticated domain access. Even if a GPO enforces password requirements, the PASSWD_NOTREQD flag can bypass that enforcement in some scenarios.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Guest | Yes | Jun 30, 2021 | Never | Apr 4, 2025 | |
| Pepper.Jack | Pepper.Jack | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
Accounts with reversible passwords
Accounts with reversible passwords
Accounts with reversible passwords
Accounts with reversible passwords store their passwords in a format that can be easily decrypted to reveal the original plaintext password. Attackers can retrieve these passwords using methods like DCSync attacks, potentially gaining unauthorized access to systems and resources within the domain.
Attacker toolsets can easily detect these accounts and reverse the encryption, allowing for quick compromise. DCSync attacks and remote domain controller hash dumping is often leveraged for these accounts. These attacks typically occur once an attacker has an authenticated position within the network.
Recommendation
Disable reversible password storage on affected accounts, reset passwords, and validate the reversible encryption flag is cleared.
Prerequisites
- Domain Admin or Account Operators rights to modify account attributes.
- Review of affected accounts completed to locate any legacy application dependencies.
- Service owner notification for affected accounts.
- Change control approval obtained.
Remediation Objective
- Disable the Store password using reversible encryption flag on all identified accounts.
- Force a password reset on affected accounts to purge the stored reversible password from the database.
- Confirm no legitimate application dependency requires plaintext password access.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Disable reversible password encryption on a single account.
# Replace <SamAccountName> with the target account.
Set-ADUser -Identity "<SamAccountName>" -AllowReversiblePasswordEncryption $false
# Force a password reset to purge the stored reversible password.
Set-ADAccountPassword -Identity "<SamAccountName>" -Reset `
-NewPassword (Read-Host -AsSecureString "Enter new password")# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remediate.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName -AllowReversiblePasswordEncryption $false -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.
# Perform password resets for all affected accounts after flag removal.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected accountNavigate to the OU or container containing the account.
- Open account propertiesDouble-click the account and navigate to the Account tab.
- Clear the reversible encryption optionIn Account options, uncheck Store password using reversible encryption.
- Reset the passwordRight-click the account and select Reset Password to force a new password and purge the stored reversible value.
- Save changesClick OK.
Validation
- Confirm AllowReversiblePasswordEncryption is False: Get-ADUser -Properties AllowReversiblePasswordEncryption.
- Verify the account password has been reset to purge the reversible value.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after AllowReversiblePasswordEncryption attribute export.
- Password reset confirmation.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
Reversible password encryption stores a value that can be mathematically reversed to recover the original password, making it functionally equivalent to storing the password in plaintext. This setting exists solely for legacy protocol compatibility and should not be enabled in any modern environment.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Mrs.Mac | Mrs. Mac | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
Accounts with SPNs Not Supporting AES
Accounts with SPNs Not Supporting AES
Accounts with SPNs Not Supporting AES
One or more service accounts with service principal names do not support AES Kerberos encryption (msDS-SupportedEncryptionTypes lacks AES, or is unset). These accounts may receive service tickets encrypted with weaker algorithms such as RC4, which are more practical to crack offline. Service accounts should support AES and use strong, regularly managed passwords.
Service accounts with SPNs are common Kerberoasting targets. If they do not support AES encryption, service tickets may use weaker encryption that is more practical for attackers to crack offline. Weak encryption increases the value of any captured ticket and can expose the service account password.
Recommendation
Set service accounts to AES-only Kerberos encryption and reset their passwords to generate AES keys.
Prerequisites
- Rights to modify the service accounts.
- Confirm each service supports AES Kerberos encryption.
- Obtain change control approval.
Remediation Objective
- Set msDS-SupportedEncryptionTypes to AES-only (0x18) on the service accounts.
- Reset the account password so AES keys are generated.
- Confirm the service still authenticates.
Remediation Path 1: Command-Line
Use this path to set AES encryption types on the affected accounts.
# Set AES128 + AES256 (0x18 = 24) and regenerate keys by resetting the password.
Import-Module ActiveDirectory
Set-ADUser -Identity "<SamAccountName>" -Replace @{ "msDS-SupportedEncryptionTypes" = 24 }# Apply to approved service accounts (column: SamAccountName).
Import-Module ActiveDirectory
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
foreach ($Item in $Items) {
Set-ADUser -Identity $Item.SamAccountName -Replace @{ "msDS-SupportedEncryptionTypes" = 24 } -WhatIf
}Remediation Path 2: GUI
Use this path when changing a small number of accounts.
- Open Active Directory Users and ComputersLaunch ADUC and enable Advanced Features from the View menu.
- Locate the service accountNavigate to the account identified in the report.
- Open the Attribute EditorRight-click the account, select Properties, and open the Attribute Editor tab.
- Set the encryption typesSet msDS-SupportedEncryptionTypes to 24 (AES128 + AES256), then click OK.
- Reset the passwordReset the account password so AES keys are generated, coordinating with the service owner.
Validation
- Confirm msDS-SupportedEncryptionTypes includes AES (and not RC4) on each account.
- Verify the service still authenticates after the password reset.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If a service genuinely requires RC4, document the dependency and compensating monitoring.
- Record owner and target date for any temporary delay.
- Track formal risk acceptance.
Evidence
- Encryption-type export before and after remediation.
- Confirmation the service still authenticates.
- Follow-up scan results confirming resolution.
Additional Guidance
Enforcing AES is a hardening step, not a substitute for strong service-account passwords; combine it with long, random passwords or migration to gMSAs, which both rotate and use AES.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| krbtgt | No | Jun 30, 2021 | Never | Apr 4, 2025 | |
| Dennis.Reynolds | Dennis.Reynolds | Yes | Apr 11, 2025 | Never | Apr 11, 2025 |
| Nightman | Nightman | Yes | May 7, 2025 | Never | May 7, 2025 |
Accounts With Stale Passwords
Accounts With Stale Passwords
Accounts With Stale Passwords
Stale passwords provide attackers with additional opportunities to perform credential-based attacks and can prolong access to systems if compromised.
Attackers use credential stuffing, password spraying, or brute-force attacks to crack weak or outdated passwords that remain unchanged for extended periods. Tools like Mimikatz, Impacket, or Kerbrute can help identify and exploit these accounts, especially if they have elevated privileges. Once compromised, attackers can use the account for lateral movement, persistence, and privilege escalation, often going undetected due to a lack of regular password audits.
Recommendation
Reset stale active account passwords, apply standard lifecycle controls, and document any approved exceptions.
Prerequisites
- Domain Administrator credentials required.
- Distinguish between user accounts and service accounts, as the remediation approach differs.
- Confirm with account owners or service teams whether each account is still in active use.
- Obtain change control approval.
Remediation Objective
- Reset passwords for active accounts that have not had a password change within the defined policy threshold.
- Disable accounts confirmed as inactive that have stale passwords.
- Ensure all active user accounts adhere to the organization's password change policy.
- Reduce the risk of credential compromise through aged passwords that may have been exposed in prior incidents.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Force a password reset on next logon for a stale account.
# Replace <SamAccountName> with the target account.
Set-ADUser -Identity "<SamAccountName>" -ChangePasswordAtLogon $true
# Or disable the account if confirmed inactive:
# Disable-ADAccount -Identity "<SamAccountName>"# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of accounts with stale passwords.
# Required CSV columns: SamAccountName, Action (Reset or Disable)
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
if ($Account.Action -eq "Reset") {
Set-ADUser -Identity $Account.SamAccountName -ChangePasswordAtLogon $true -WhatIf
} elseif ($Account.Action -eq "Disable") {
Disable-ADAccount -Identity $Account.SamAccountName -WhatIf
}
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.msc. - Locate the affected accountNavigate to the OU containing the account.
- Force a password resetRight-click the account and select Reset Password. Set a temporary password and check 'User must change password at next logon'.
- Or disable the account if inactiveRight-click the account and select Disable Account.
- Repeat for approved affected accountsComplete the same GUI process for each account listed in the approved remediation plan.
Validation
- Confirm password last set date is updated: Get-ADUser -Identity <SamAccountName> -Properties PasswordLastSet
- Verify inactive accounts are disabled.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Export of PasswordLastSet values for affected accounts before remediation.
- Change ticket and approval record.
- PowerShell output confirming password resets or account disables.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Threat actors frequently search for stale credentials as an easy entry point into Active Directory environments. These accounts often go unnoticed in security monitoring, making them valuable for long-term persistence. Once compromised, they can be leveraged to access sensitive resources or conduct further attacks while appearing as legitimate users. Many organizations find that utilizing a PAM (Privileged Access Management) tool helps to better manage domain-based credentials.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Administrator | Yes | Jun 30, 2021 | May 23, 2025 | Apr 14, 2025 | |
| Frank.Reynolds | Frank.Reynolds | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 |
| Liam.McPoyle | Liam.McPoyle | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Dayman | Dayman | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Mrs.Mac | Mrs. Mac | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Carmen | Carmen | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Pepper.Jack | Pepper.Jack | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Bonnie.Kelly | Bonnie.Kelly | Yes | Apr 4, 2025 | Never | Jun 23, 2025 |
| Gail.Snail | Gail.Snail | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Country.Mac | Country.Mac | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Dennis.Reynolds | Dennis.Reynolds | Yes | Apr 11, 2025 | Never | Apr 11, 2025 |
| UncleJack.Kelly | Yes | May 1, 2025 | Never | May 1, 2025 | |
| Nightman | Nightman | Yes | May 7, 2025 | Never | May 7, 2025 |
| Waitress | The Waitress | Yes | May 8, 2025 | Never | May 8, 2025 |
| Luther.McDonald | Luther.McDonald | Yes | May 8, 2025 | Never | May 8, 2025 |
| Dee.Reynolds | Dee.Reynolds | Yes | May 19, 2025 | Never | May 19, 2025 |
| Charlie.Kelly | Charlie.Kelly | Yes | May 19, 2025 | Never | May 19, 2025 |
| Artemis.Dubois | Artemis.Dubois | Yes | May 23, 2025 | May 23, 2025 | May 23, 2025 |
| Ronald.McDonald | Ronald.McDonald | Yes | Jun 10, 2025 | Jun 10, 2025 | Jun 10, 2025 |
| Rickety.Cricket | Rickety.Cricket | Yes | Jul 2, 2025 | Never | Jul 2, 2025 |
| Roxy | Roxy | Yes | Jul 3, 2025 | Never | Never |
| Barbara.Reynolds | Barbara.Reynolds | Yes | Jul 3, 2025 | Never | Never |
| Ryan.McPoyle | Ryan.McPoyle | Yes | Jul 3, 2025 | Never | Never |
| Psycho.Pete | Psycho.Pete | Yes | Jul 3, 2025 | Never | Never |
| Da.Maniac | Da.Maniac | Yes | Jul 3, 2025 | Never | Never |
| Rex | Rex | Yes | Jul 3, 2025 | Never | Never |
| Ruby.Taft | Ruby.Taft | Yes | Jul 3, 2025 | Never | Never |
| Schmitty | Schmitty | Yes | Jul 3, 2025 | Never | Never |
| Duncan | Duncan | Yes | Jul 3, 2025 | Never | Never |
| Z | Z | Yes | Jul 3, 2025 | Never | Never |
| Hwang | Hwang | Yes | Jul 3, 2025 | Never | Never |
| Lawyer | Lawyer | Yes | Jul 3, 2025 | Never | Never |
| Ben.Smith | Ben.Smith | Yes | Jul 3, 2025 | Never | Never |
| svc_Green.Man | svc_Green.Man | Yes | Jul 3, 2025 | Never | Never |
| svc_Bird.Law | svc_Bird.Law | Yes | Jul 3, 2025 | Never | Never |
| svc_Fight.Milk | svc_Fight.Milk | Yes | Jul 3, 2025 | Never | Never |
| svc_Rum.Ham | svc_Rum.Ham | Yes | Jul 3, 2025 | Never | Never |
| svc_Wolf.Cola | svc_Wolf.Cola | Yes | Jul 3, 2025 | Never | Never |
| svc_Ingrid.Nelson | svc_Ingrid.Nelson | Yes | Jul 3, 2025 | Never | Never |
| svc_Kitten.Mittens | svc_Kitten.Mittens | Yes | Jul 3, 2025 | Never | Never |
| svc_Milk.Steak | svc_Milk.Steak | Yes | Jul 3, 2025 | Never | Never |
| John.Thundergun | John.Thundergun | Yes | Jul 3, 2025 | Never | Never |
| Doyle.McPoyle | Doyle.McPoyle | Yes | Jul 3, 2025 | Never | Never |
| Byron | Byron | Yes | Jul 3, 2025 | Never | Never |
| Waiter | Waiter | Yes | Jul 3, 2025 | Never | Never |
| Donna.Brunswick | Donna.Brunswick | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Jack.Bauer | Jack.Bauer | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Gladys.Reynolds | Gladys.Reynolds | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Shelly.Kelly | Shelly.Kelly | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Pappy.McPoyle | Pappy.McPoyle | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Margaret.McPoyle | Margaret.McPoyle | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Peter.Nincompoop | Peter.Nincompoop | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Brian.LeFevre | Brian.LeFevre | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Vic.Vinegar | Vic.Vinegar | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Hugh.Honey | Hugh.Honey | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Mantis.Toboggan | Mantis.Toboggan | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Ongo.Gablogian | Ongo.Gablogian | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Desert.Grape | Desert.Grape | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Invigaron | svc_Invigaron | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Franks.Fluids | svc_Franks.Fluids | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Paddy.Wagon | svc_Paddy.Wagon | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Electric.Dream.Machine | svc_Electric.Dream.Machine | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Paddy.Dollars | svc_Paddy.Dollars | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Lil.Kev | Lil.Kev | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Chase.Utley | Chase.Utley | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Edurado.Sanchez | Edurado.Sanchez | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Dr.Jinx | Dr.Jinx | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Don.Cheadle | Don.Cheadle | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| Tiger.Woods | Tiger.Woods | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
| svc_Shadynasty | svc_Shadynasty | Yes | Jul 23, 2025 | Never | Jul 23, 2025 |
Constrained Delegation Detected
Constrained Delegation Detected
Constrained Delegation Detected
Constrained delegation allows services to impersonate users when accessing specific resources on their behalf, but misconfigured or decommissioned service accounts with constrained delegation pose a significant security risk. Attackers with the ability to modify Service Principal Names (SPNs) can exploit these configurations to escalate privileges and move laterally within the environment, gaining unauthorized access to sensitive resources.
These issues are often discovered through reconnaissance tools such as BloodHound. Constrained delegation attacks can occur in various forms, such as compromising user or computer accounts with pre-existing delegations or exploiting resource-based constrained delegation, which happens when accounts have excessive permissions to certain assets.
Recommendation
Review constrained delegation assignments, remove unjustified configurations, and validate only approved services retain delegation rights.
Prerequisites
- Domain Administrator credentials required.
- Locate all accounts with constrained delegation configured (msDS-AllowedToDelegateTo attribute).
- Determine whether each delegation entry has a documented operational purpose.
- Coordinate with application and service owners before modifying delegation settings.
- Back up current delegation configurations before making changes.
- Obtain change control approval.
Remediation Objective
- Review all constrained delegation configurations and remove any that are not operationally justified.
- Restrict constrained delegation to only the specific services required for documented workflows.
- Replace protocol transition (Trusted to Authenticate for Delegation) with resource-based constrained delegation (RBCD) where possible for improved security.
- Reduce the attack surface for Kerberos delegation abuse in the event of a service account compromise.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Review all accounts with constrained delegation configured.
Get-ADObject -Filter { msDS-AllowedToDelegateTo -like "*" } `
-Properties msDS-AllowedToDelegateTo, TrustedForDelegation, TrustedToAuthForDelegation `
| Select-Object Name, msDS-AllowedToDelegateTo, TrustedToAuthForDelegation
# Remove constrained delegation from a specific account.
# Replace <SamAccountName> with the target account.
Set-ADUser -Identity "<SamAccountName>" -Clear msDS-AllowedToDelegateTo
Set-ADAccountControl -Identity "<SamAccountName>" -TrustedToAuthForDelegation $false# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of accounts to remove delegation from.
# Required CSV columns: SamAccountName
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName -Clear msDS-AllowedToDelegateTo -WhatIf
Set-ADAccountControl -Identity $Account.SamAccountName `
-TrustedToAuthForDelegation $false -WhatIf
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscwith Advanced Features enabled. - Locate the affected accountNavigate to the account identified in the report.
- Open account propertiesRight-click and select Properties, then click the Delegation tab.
- Review delegation settingsConfirm whether the delegation is justified and what services are listed.
- Modify or remove delegationSelect 'Do not trust this computer for delegation' to remove delegation entirely, or update the service list to remove unjustified entries.
- Save and testClick OK and confirm that legitimate delegated services are unaffected.
Validation
- Confirm delegation settings have been updated: Get-ADUser -Identity <SamAccountName> -Properties msDS-AllowedToDelegateTo, TrustedToAuthForDelegation
- Verify that legitimate delegated services are still functioning.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Export of delegation configurations before changes.
- Service owner justification documentation for retained delegations.
- Change ticket and approval record.
- PowerShell output confirming delegation settings after changes.
- Service functionality confirmation.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Constrained delegation can be appropriate when tightly scoped, but it should be reviewed for necessity and target restrictions. Validate each service dependency and monitor changes to delegation settings on service accounts and computers.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Nightman | Nightman | Yes | May 7, 2025 | Never | May 7, 2025 |
Guest Account Enabled
Guest Account Enabled
Guest Account Enabled
The Guest account is a well-known default account in Active Directory that allows access to the domain without a password. By default, this account has limited privileges. However, it can be used to gain initial access to your network and subsequently used as a launchpad to perform reconnaissance and privilege escalation attacks.
Attackers typically use the Guest account to pull Active Directory information down to enumerate misconfigurations and understand the environment. It is often paired with accessing open shares, which can lead to further attacks. This essentially gives an attacker an authenticated position in your domain, without setting any credentials.
Recommendation
Disable the Guest account, verify it cannot authenticate, and monitor for future reactivation.
Prerequisites
- Domain Admin or Account Operators rights to disable accounts.
- Confirm no systems or services use the Guest account for access.
- Change control approval obtained.
Remediation Objective
- Disable the Guest account in Active Directory.
- Confirm the Guest account is also disabled locally on domain controllers and member servers where applicable.
- Implement monitoring to alert if the Guest account is re-enabled.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Disable the Guest account in Active Directory.
Disable-ADAccount -Identity "Guest"
# Confirm the account is disabled.
Get-ADUser -Identity "Guest" -Properties Enabled | Select Name, EnabledRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the Guest accountNavigate to the Users container (CN=Users) and locate the Guest account.
- Disable the accountRight-click the Guest account and select Disable Account.
- Confirm the changeVerify the account icon shows a downward arrow indicating it is disabled.
Validation
- Confirm the Guest account is disabled: Get-ADUser -Identity Guest -Properties Enabled should return Enabled: False.
- Verify no authentication events for the Guest account appear in domain controller security logs.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after account status export showing Guest account is disabled.
- Change ticket and approval record.
- Event log review confirming no Guest account authentication activity.
- Follow-up scan results showing finding resolved.
Additional Guidance
The Guest account should remain disabled unless there is an approved and time-bound business requirement. Monitor for reactivation and ensure any exception includes compensating controls as this account can provide an unnecessary foothold for unauthorized access.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Guest | Yes | Jun 30, 2021 | Never | Apr 4, 2025 |
Kerberos Armoring Not Enabled
Kerberos Armoring Not Enabled
Kerberos Armoring Not Enabled
Not enabling Kerberos armoring leaves the Kerberos authentication process vulnerable to pre-authentication attacks, such as AS-REP Roasting. Kerberos armoring enhances the security of the protocol by protecting the pre-authentication steps and ensures stronger protection during authentication.
Ransomware groups utilize this tactic to obtain an authenticated position within Active Directory, which then leads to more advanced attacks. It's often one of the first attacks carried out once access to the internal network is obtained.
Recommendation
Enable Kerberos Armoring where supported, validate client and service compatibility, and document any systems that require exception.
Prerequisites
- Locate any legacy clients or services that may not support Kerberos Armoring before enabling enforcement.
- Back up affected GPO before modification.
- Obtain change control approval.
- Test in a pilot OU before broad deployment if legacy systems are present.
Remediation Objective
- Enable Kerberos Armoring (FAST) to protect Kerberos pre-authentication exchanges from offline attacks.
- Prevent downgrade attacks against Kerberos by enforcing armored ticket exchanges between clients and domain controllers.
- Reduce the attack surface for credential harvesting techniques that target Kerberos AS-REQ traffic.
- Align domain authentication configuration with current Microsoft Kerberos security guidance.
Remediation Path 1: Command-Line
Not applicable. A command-line remediation is not the preferred remediation method for this finding because Kerberos armoring should be enabled through Group Policy so KDC and client compatibility settings are scoped, tested, and rolled back through standard policy management.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Edit or create the relevant GPORight-click the GPO linked to the Domain Controllers OU and select Edit.
- Navigate to Kerberos Armoring settingsGo to Computer Configuration > Administrative Templates > System > KDC.
- Enable Kerberos ArmoringOpen 'KDC support for claims, compound authentication and Kerberos armoring' and set it to Enabled. Select 'Supported' to enable without enforcing for legacy compatibility, or 'Always provide claims and fail unarmored authentication requests' for full enforcement.
- Configure client-side policyIn the same GPO or a client-targeted GPO, navigate to Computer Configuration > Administrative Templates > System > Kerberos. Enable 'Kerberos client support for claims, compound authentication and Kerberos armoring' and set to Supported or Required.
- Apply and testUse the organization-approved policy refresh process on a test domain controller and client. Confirm Kerberos authentication is successful.
Validation
- Confirm the KDC Kerberos Armoring GPO setting is applied on domain controllers using gpresult /r.
- Verify Kerberos Armoring is active by reviewing Kerberos authentication events on domain controllers (Event ID 4768).
- Confirm no authentication failures are occurring on clients after GPO application.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- GPO backup before and after modification.
- gpresult output confirming GPO application on domain controllers and test clients.
- Kerberos authentication event log review confirming no failures.
- Change ticket and approval record.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Kerberos Armoring, also known as FAST (Flexible Authentication Secure Tunneling), wraps Kerberos pre-authentication exchanges in a secure tunnel, preventing offline cracking of AS-REQ traffic and protecting against certain downgrade attacks. It is a supported feature in Windows Server 2012 and later environments and should be enabled in any modern domain.
Kerberos Pre-Authentication In Use
Kerberos Pre-Authentication In Use
Kerberos Pre-Authentication In Use
Kerberos Pre-Authentication is a critical security mechanism that prevents attackers from easily obtaining Kerberos ticket-granting information. When Pre-Authentication is disabled, attackers can exploit vulnerabilities like AS-REP Roasting, allowing them to perform offline brute-force attacks on passwords, increasing the risk of unauthorized access. Ensuring that all accounts, especially administrative ones, have Pre-Authentication enabled is essential to maintaining secure access controls within Active Directory environments.
Ransomware groups frequently exploit Kerberos Pre-Authentication to obtain an authenticated position within Active Directory. It's often one of the first attacks executed once access to the internal network is obtained and leads to more advanced attacks.
Recommendation
Enable Kerberos pre-authentication on affected accounts, validate the account flag is cleared, and document any approved exceptions.
Prerequisites
- Domain Admin or Account Operators rights to modify account attributes.
- Review of affected accounts completed to locate any legacy application dependencies that require pre-authentication to remain disabled.
- Change control approval obtained.
- Service owner notification for any service accounts in scope.
Remediation Objective
- Enable Kerberos pre-authentication on all identified accounts where it has been disabled.
- Confirm no legitimate application dependency requires pre-authentication to remain disabled.
- Implement monitoring for AS-REP responses to detect ongoing exploitation attempts.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Enable Kerberos pre-authentication on a single account.
# Replace <SamAccountName> with the target account's SAM account name.
$Account = Get-ADUser -Identity "<SamAccountName>" -Properties UserAccountControl
# Remove the DONT_REQUIRE_PREAUTH flag (0x400000) from the account control value.
$NewUAC = $Account.UserAccountControl -band -bnot 0x400000
Set-ADUser -Identity "<SamAccountName>" -Replace @{UserAccountControl = $NewUAC}# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remediate.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
# Enable Kerberos pre-authentication on each account in the approved input file.
foreach ($Account in $Accounts) {
$ADUser = Get-ADUser -Identity $Account.SamAccountName -Properties UserAccountControl
$NewUAC = $ADUser.UserAccountControl -band -bnot 0x400000
Set-ADUser -Identity $Account.SamAccountName -Replace @{UserAccountControl = $NewUAC}
Write-Output "Updated: $($Account.SamAccountName)"
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected accountNavigate to the OU or container containing the account identified in the report.
- Open account propertiesDouble-click the account to open its properties.
- Navigate to the Account tabSelect the Account tab and review the Account options list.
- Clear the pre-authentication flagUncheck the option labeled Do not require Kerberos preauthentication.
- Save changesClick OK or Apply to save the change.
Validation
- Confirm the DONT_REQUIRE_PREAUTH flag is cleared using Get-ADUser -Properties UserAccountControl.
- Attempt an AS-REP request against the account to verify it is no longer roastable (the request should fail or require authentication).
- Review domain controller security event logs for Event ID 4768 to confirm normal Kerberos ticket issuance.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after export of UserAccountControl values for affected accounts.
- Change ticket and approval record.
- PowerShell transcript of remediation commands.
- Validation output confirming pre-authentication is enabled.
Additional Guidance
Kerberos pre-authentication is a critical control that prevents offline password cracking of account credentials without any prior interaction from the account owner. Disabling it should be treated as an exceptional configuration reserved only for demonstrably necessary legacy application integrations, with compensating controls in place.
Organizations should implement proactive monitoring for AS-REP Roasting activity by alerting on large volumes of Event ID 4768 responses with no pre-authentication required. Any new account configuration that disables pre-authentication should trigger an automated review workflow requiring documented justification before the change is permitted.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Bonnie.Kelly | Bonnie.Kelly | Yes | Apr 4, 2025 | Never | Jun 23, 2025 |
Non-Expiring Passwords in Domain Admins Group
Non-Expiring Passwords in Domain Admins Group
Non-Expiring Passwords in Domain Admins Group
Non-expiring passwords in the Domain Admins group pose a risk, as these static credentials can be easily targeted by attackers with credential-based attacks. Passwords that are not rotated for long periods of time increase the likelihood for compromise and persistence.
Once attackers obtain password hashes, they use password lists and rulesets to crack them. Non-expiring passwords are especially risky, as modern graphics cards provide the computational power to crack hashes more easily.
Recommendation
Remove non-expiring password settings from Domain Admin accounts, rotate affected credentials, and document any approved break-glass exception.
Prerequisites
- Domain Admin rights to modify account attributes.
- All affected Domain Admins notified in advance.
- Service accounts in Domain Admins group (if any) coordinated with service owners.
- PAM solution enrollment prepared as a preferred alternative.
- Change control approval obtained.
Remediation Objective
- Enable password expiration for all Domain Admin accounts with the Password Never Expires flag set.
- Enroll Domain Admin accounts in a PAM solution or enforce a rotation schedule of 90 days or less.
- Coordinate with all affected administrators to ensure they are aware of and prepared for the upcoming expiration.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Enable password expiration on a Domain Admin account.
# Replace <SamAccountName> with the target admin account.
Set-ADUser -Identity "<SamAccountName>" -PasswordNeverExpires $false# Import the Active Directory module.
Import-Module ActiveDirectory
# Get all Domain Admins with non-expiring passwords.
$DomainAdmins = Get-ADGroupMember -Identity "Domain Admins" -Recursive |
Get-ADUser -Properties PasswordNeverExpires |
Where-Object { $_.PasswordNeverExpires -eq $true }
# Display the accounts identified.
$DomainAdmins | Select SamAccountName, PasswordNeverExpires
# Apply the change from an approved CSV.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedDomainAdmins.csv"
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName -PasswordNeverExpires $false -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Navigate to the Domain Admins groupLocate and open the Domain Admins group. Review the Members tab and locate accounts with non-expiring passwords.
- Update each accountOpen each account's properties, navigate to the Account tab, and uncheck Password never expires.
- Communicate to affected administratorsNotify each administrator of the change and the upcoming password expiration timeline.
Validation
- Confirm PasswordNeverExpires is False for all Domain Admin accounts: Get-ADGroupMember -Identity 'Domain Admins' | Get-ADUser -Properties PasswordNeverExpires.
- Verify administrators can authenticate and that no service disruptions occurred.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after PasswordNeverExpires attribute export for all Domain Admin accounts.
- Administrator notification records.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
Enforce password expiration policies for all accounts in the Domain Admins group to ensure regular password updates and reduce the risk of long-term compromise. Review service accounts with non-expiring passwords, and where possible, replace them with managed service accounts (MSAs) or third-party applications such as Privileged Access Management (PAM) toolsets.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Ronald.McDonald | Ronald.McDonald | Yes | Jun 10, 2025 | Jun 10, 2025 | Jun 10, 2025 |
| Charlie.Kelly | Charlie.Kelly | Yes | May 19, 2025 | Never | May 19, 2025 |
| Dee.Reynolds | Dee.Reynolds | Yes | May 19, 2025 | Never | May 19, 2025 |
| Dennis.Reynolds | Dennis.Reynolds | Yes | Apr 11, 2025 | Never | Apr 11, 2025 |
| Frank.Reynolds | Frank.Reynolds | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 |
| Administrator | Yes | Jun 30, 2021 | May 23, 2025 | Apr 14, 2025 |
Privileged Users with Stale Passwords
Privileged Users with Stale Passwords
Privileged Users with Stale Passwords
Stale administrative passwords provide attackers with additional opportunities to perform credential-based attacks and if compromised, can prolong system access.
Organizations that properly tier and enforce best practices around privileged accounts typically take significantly more time to compromise. This forces the attacker to rely on other attack avenues such as network poisoning or social engineering.
Recommendation
Reset stale privileged account passwords, enforce appropriate rotation or lifecycle controls, and validate updated password timestamps.
Prerequisites
- Domain Admin or Password Reset rights for privileged accounts in scope.
- Notification sent to affected privileged users prior to password reset.
- Service owner identification and sign-off for any service accounts in scope.
- Change control approval obtained.
- PAM solution enrollment prepared if available.
Remediation Objective
- Reset passwords on all privileged accounts with stale credentials.
- Enforce a password rotation policy for privileged accounts, or enroll accounts in a PAM solution for automated credential management.
- Confirm dependent services are updated with new credentials where applicable.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Reset the password on a privileged user account.
# Replace <SamAccountName> with the target privileged account.
Set-ADAccountPassword -Identity "<SamAccountName>" -Reset -NewPassword (Read-Host -AsSecureString "Enter new password") -PassThru# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of privileged accounts with stale passwords.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedPrivilegedAccounts.csv"
foreach ($Account in $Accounts) {
Set-ADAccountPassword -Identity $Account.SamAccountName -Reset `
-NewPassword (ConvertTo-SecureString ((New-Guid).ToString() + "!Aa1") -AsPlainText -Force) -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected privileged accountNavigate to the OU containing the privileged account identified in the report.
- Reset the passwordRight-click the account and select Reset Password. Enter a strong password meeting complexity requirements. Uncheck User must change password at next logon for service accounts; check it for human user accounts where appropriate.
- Notify the account ownerContact the account owner through a secure channel to provide the new password or initiate a self-service reset flow.
- Update dependent servicesFor service accounts, update the service logon credentials on all dependent systems and restart the services as needed.
Validation
- Confirm the PasswordLastSet attribute has been updated for affected accounts.
- Verify that any dependent services are running and authenticating successfully.
- Confirm the account owner has successfully authenticated with the new credential.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after PasswordLastSet attribute export for affected accounts.
- Service health validation results.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
Stale privileged passwords increase the value of old credential material and should be addressed through a privileged account lifecycle process. Use PAM, strong rotation standards, and periodic review to ensure administrative accounts do not retain long-lived secrets.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Administrator | Yes | Jun 30, 2021 | May 23, 2025 | Apr 14, 2025 | |
| Frank.Reynolds | Frank.Reynolds | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 |
| Liam.McPoyle | Liam.McPoyle | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Dennis.Reynolds | Dennis.Reynolds | Yes | Apr 11, 2025 | Never | Apr 11, 2025 |
| Waitress | The Waitress | Yes | May 8, 2025 | Never | May 8, 2025 |
| Dee.Reynolds | Dee.Reynolds | Yes | May 19, 2025 | Never | May 19, 2025 |
| Charlie.Kelly | Charlie.Kelly | Yes | May 19, 2025 | Never | May 19, 2025 |
| Artemis.Dubois | Artemis.Dubois | Yes | May 23, 2025 | May 23, 2025 | May 23, 2025 |
| Ronald.McDonald | Ronald.McDonald | Yes | Jun 10, 2025 | Jun 10, 2025 | Jun 10, 2025 |
| Rickety.Cricket | Rickety.Cricket | Yes | Jul 2, 2025 | Never | Jul 2, 2025 |
Stale krbtgt Account Password
Stale krbtgt Account Password
Stale krbtgt Account Password
The krbtgt account is a crucial component in the Kerberos authentication system in Active Directory, as its password is used to sign Kerberos tickets. A stale krbtgt password increases the risk of a “Golden Ticket” attack, where attackers can forge valid Kerberos tickets, granting unauthorized access to any resource in the domain.
Attackers will remotely dump domain controllers upon achieving domain administrator level access with toolsets like Impacket’s secretsdump.py. The krbtgt account is one of the most powerful accounts within Active Directory, and is one of the first hashes to be dumped. Attackers will then use this password hash to perform Golden Ticket attacks. It is particularly valuable for persistence, allowing attackers to stay in your environment even after remediation has occurred.
Recommendation
Rotate the krbtgt password using a controlled two-reset process and confirm domain controller replication.
Prerequisites
- Domain Admin or equivalent rights to reset the krbtgt account password.
- Confirm all writable domain controllers are healthy and replicating successfully.
- Download and review Microsoft’s published krbtgt reset script before execution.
- Obtain change approval and schedule a maintenance window for the reset.
Remediation Objective
- Rotate the krbtgt account password in a controlled manner to reduce Golden Ticket risk.
- Use the Microsoft-published script to validate domain controller reachability and replication.
- Perform two resets with the required wait period between resets to clear old keys from password history.
- Monitor authentication and replication health after each reset.
Remediation Path 1: Command-Line
Microsoft and the security community recommend using either New-KrbtgtKeys.ps1 or Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1. Both scripts include health checks, simulation modes, replication monitoring, and RODC account handling.
Script repositories: https://github.com/microsoftarchive/New-KrbtgtKeys.ps1, https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
# Instructions for New-KrbtgtKeys.ps1
# Review the script, test the informational/simulation modes, and run from an approved admin workstation.
# Example workflow:
# 1. Run informational mode to review writable domain controllers and krbtgt status.
# 2. Run simulation mode to validate replication before making changes.
# 3. Run the production reset mode for the first krbtgt reset.
# 4. Wait longer than the domain Kerberos ticket lifetime, then repeat production reset mode.
# 5. Save the script transcript and validate replication after each reset.
.\New-KrbtgtKeys.ps1Remediation Path 2: GUI
The scripted remediation path is preferred as it provides checks, features, and controls that make this change safer for most environments.
- Open Active Directory Users and ComputersOn an administrative workstation or writable domain controller, open Active Directory Users and Computers.
- Enable Advanced FeaturesSelect View, then select Advanced Features so the krbtgt account is visible and manageable.
- Locate the krbtgt accountExpand the domain container, select Users, and locate the krbtgt user account. Do not reset any RODC-specific krbtgt_number account unless separately instructed as part of an RODC recovery process.
- Reset the krbtgt passwordRight-click the krbtgt account and select Reset Password. Enter and confirm a new password, then click OK. The specific password entered is not significant because Windows generates the actual strong password value automatically.
- Allow ticket lifetime and replication delayWait at least 10 hours before performing the second reset, or longer if the domain uses a longer maximum lifetime for user or service tickets. Confirm replication health before proceeding.
- Reset the password a second timeRepeat the password reset on the krbtgt account after the waiting period. The second reset clears older krbtgt password material from history and helps invalidate previously issued Kerberos tickets.
- Monitor authenticationAfter each reset, monitor domain controller replication, Kerberos authentication, and service authentication for errors before closing the change.
Validation
- Confirm the script reports successful replication to all writable domain controllers.
- Review the krbtgt PasswordLastSet value after each reset.
- Run repadmin /replsummary and confirm replication is healthy.
- Review domain controller security event logs for Event IDs 4724 and 4738 to confirm both resets.
- Monitor domain controller and authentication logs for Kerberos or service failures.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- There are no broadly accepted exceptions for this control that justifies indefinite deferral.
- Document the business reason for delaying krbtgt rotation.
- Assign an owner and target remediation date.
- Increase monitoring for Golden Ticket indicators until rotation is complete.
- Require formal risk acceptance for any extended deferral.
Evidence
- Script transcript or log showing informational, simulation, and reset execution.
- repadmin /replsummary output before and after each reset.
- krbtgt PasswordLastSet evidence captured after both resets.
- Change ticket, approval record, and maintenance window documentation.
- Follow-up scan results showing the finding resolved.
Additional Guidance
The krbtgt account is the foundation of Kerberos authentication in Active Directory. Its password hash is used to sign every Kerberos ticket issued in the domain, and its compromise enables a Golden Ticket attack that grants persistent, domain-wide administrative access. A forged ticket created from a compromised krbtgt hash remains valid until the password has been rotated twice, because the domain retains the two most recent password versions in its history. A single reset is not sufficient for full remediation.
Organizations should establish a formal rotation schedule at a cadence of at least every 180 days, and immediately following any domain controller compromise, privileged account compromise, or security incident in which domain credential exposure is possible. Routine rotations should be treated as planned maintenance events: confirm replication health, allow full convergence between resets, and notify the service desk.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| krbtgt | No | Jun 30, 2021 | Never | Apr 4, 2025 |
User Accounts with DES Enabled
User Accounts with DES Enabled
User Accounts with DES Enabled
DES is an outdated and weak encryption algorithm that is easily cracked, due to its weak 56-bit key length. Attackers can exploit this weakness by cracking Kerberos tickets encrypted with DES, allowing them to steal user credentials and escalate privileges within the domain.
DES-enabled accounts are easily detected with hacker toolsets and once observed, typically result in a successful password crack.
Recommendation
Disable DES encryption on affected user accounts, confirm compatible Kerberos encryption settings, and validate authentication after the change.
Prerequisites
- Domain Admin or Account Operators rights to modify account attributes.
- Review of affected accounts completed to locate any legacy Kerberos application dependencies.
- Change control approval obtained.
Remediation Objective
- Disable DES encryption on all identified user accounts by clearing the Use DES encryption types for this account flag.
- Confirm accounts are configured to use AES or stronger encryption algorithms.
- Verify dependent services continue to function after the change.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Disable DES encryption on a single user account.
# Replace <SamAccountName> with the target account.
Set-ADUser -Identity "<SamAccountName>" -KerberosEncryptionType "RC4", "AES128", "AES256"
# Alternatively, clear the USE_DES_KEY_ONLY flag from UserAccountControl.
$Account = Get-ADUser -Identity "<SamAccountName>" -Properties UserAccountControl
$NewUAC = $Account.UserAccountControl -band -bnot 0x200000
Set-ADUser -Identity "<SamAccountName>" -Replace @{UserAccountControl = $NewUAC}# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remediate.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName -KerberosEncryptionType "RC4", "AES128", "AES256" -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected accountNavigate to the OU or container containing the account identified in the report.
- Open account propertiesDouble-click the account and navigate to the Account tab.
- Locate the DES optionIn the Account options list, uncheck the option Use DES encryption types for this account.
- Save changesClick OK or Apply.
Validation
- Confirm the USE_DES_KEY_ONLY flag is cleared: Get-ADUser -Properties UserAccountControl and verify bit 0x200000 is not set.
- Verify the account can authenticate successfully using Kerberos.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after export of UserAccountControl and KerberosEncryptionType attributes.
- Change ticket and approval record.
- PowerShell transcript of remediation commands.
- Follow-up scan results showing finding resolved.
Additional Guidance
DES is a 56-bit symmetric encryption algorithm that is no longer considered secure for any purpose. Kerberos implementations using DES are vulnerable to practical brute-force attacks with modern hardware.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Gail.Snail | Gail.Snail | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
Directory Services Issues
6 findings
Default OU Location Modified
Default OU Location Modified
Default OU Location Modified
The modification of the default OU location in Active Directory occurs when default organizational units (OUs) like CN=Computers or CN=Users are changed, potentially causing unexpected behavior in scripts, tooling, security audits, or policies that rely on these standard locations. This change can disrupt automated processes and pose a security risk if not properly controlled or documented.
When attackers identify modified default OUs, they focus on these accounts because they are often less secure than others within the domain.
Recommendation
Review and reset default user or computer containers to approved OUs with appropriate policies, monitoring, and ownership.
Prerequisites
- Domain Administrator credentials required.
- Locate the current default OU setting for new computers and users.
- Confirm with the directory services team what the correct target OU should be for new objects.
- Obtain change control approval.
Remediation Objective
- Reset the default container for new computer and user accounts to an appropriate, monitored OU.
- Prevent new accounts from landing in the CN=Computers or CN=Users default containers, which typically lack GPO coverage and security controls.
- Ensure all newly created accounts are subject to the appropriate Group Policy and monitoring from creation.
- Reduce the risk of ungoverned accounts being created outside of the normal OU structure.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Run from an elevated command prompt on an administrative workstation.
# Redirect the default computer account location.
# Replace <ComputersOUDistinguishedName> with the approved OU distinguished name.
redircmp "<ComputersOUDistinguishedName>"
# Redirect the default user account location.
# Replace <UsersOUDistinguishedName> with the approved OU distinguished name.
redirusr "<UsersOUDistinguishedName>"Remediation Path 2: GUI
Not applicable. A GUI-only remediation path is not the preferred method for this finding because changing the default user or computer creation container requires the redirusr or redircmp command-line utilities. Active Directory Users and Computers can move objects after creation, but it does not provide a GUI-only method to change the default container.
Validation
- Confirm default computer OU: (Get-ADDomain).ComputersContainer
- Confirm default user OU: (Get-ADDomain).UsersContainer
- Create a test account without specifying an OU and confirm placement in the target OU.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Do not approve permanent exceptions for this condition.
- Document any temporary delay with owner and target date.
- Track formal risk acceptance until remediation is complete.
Evidence
- Current default OU values before changes.
- Change ticket and approval record.
- Post-change Get-ADDomain output confirming new default OU values.
- Test account placement confirmation.
Additional Guidance
Modified default object locations should be documented and reflected in provisioning, security, and monitoring processes. Ensure the target OUs receive the expected policies and permissions so newly created users or computers are not missed by controls.
Inactive Domain Controllers
Inactive Domain Controllers
Inactive Domain Controllers
Domain Controllers are considered inactive if they have not authenticated or changed their passwords within the past 30 days, which is a default. Attackers can exploit inactive Domain Controllers to reset passwords or reintroduce unwanted changes into Active Directory, potentially leading to a domain compromise.
Attackers target an inactive domain controller, as they may be less secure or misconfigured, to extract sensitive data such as password hashes or replicate directory information. Some persistence techniques exist by reintroducing the attacker-controlled domain controller to the domain.
Recommendation
Demote and decommission inactive domain controllers, clean up metadata, and validate replication topology after removal.
Prerequisites
- Confirm each listed domain controller is truly inactive and no longer required.
- Verify FSMO roles, DNS records, Global Catalog status, and application dependencies before removal.
- Back up relevant AD metadata, DNS records, and server documentation.
- Obtain change approval and define the demotion or metadata cleanup approach.
Remediation Objective
- Properly demote and decommission inactive domain controllers from the Active Directory environment.
- Remove stale domain controller objects from Active Directory to prevent replication errors and misleading directory data.
- Ensure FSMO roles are transferred to active domain controllers before decommissioning.
- Reduce the attack surface by eliminating unmanaged domain controller endpoints.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Review last logon and replication data for a specific domain controller.
# Replace <DCName> with the name of the inactive domain controller.
Get-ADDomainController -Identity "<DCName>" | Select-Object Name, OperatingSystem, LastLogonDate
# Check FSMO roles held by the DC before decommissioning.
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
# If the DC is unreachable and cannot be cleanly demoted, use metadata cleanup:
# Remove-ADDomainController -Identity "<DCName>" -ForceRemoval# Import the required module for the remediation.
Import-Module ActiveDirectory
# Import a reviewed and approved list of affected objects to remediate.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
# Update only the objects included in the approved input file.
foreach ($Item in $Items) {
# Replace the placeholder command with the approved single-object remediation command for Inactive Domain Controllers.
# Use -WhatIf when supported before applying the change.
<Approved-Remediation-Command> -Identity $Item.DistinguishedName -WhatIf
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Server Manager on the inactive domain controller if it is accessibleUse the Remove Roles and Features wizard to remove the Active Directory Domain Services role and complete the demotion workflow.
- Remove the domain controller computer objectOpen Active Directory Users and Computers and remove the retired domain controller computer object from the Domain Controllers OU after a clean demotion.
- Remove stale server referencesOpen Active Directory Sites and Services and remove stale server or NTDS Settings objects associated with the retired domain controller if they remain after demotion.
- Remove stale DNS recordsOpen DNS Manager and remove outdated A, CNAME, SRV, and other records that reference the retired domain controller.
- Review console healthUse Server Manager, Active Directory Sites and Services, DNS Manager, and Event Viewer to confirm the remaining domain controllers appear healthy and no stale references remain.
Validation
- Confirm the domain controller object is removed from the Domain Controllers OU in ADUC.
- Verify AD replication is healthy: repadmin /replsummary
- Confirm DNS records for the decommissioned DC are removed.
- Verify FSMO roles are held by active domain controllers: netdom query fsmo
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- FSMO role inventory before changes.
- DNS record export before removal.
- Change ticket and approval record.
- repadmin /replsummary output before and after decommissioning.
- AD metadata cleanup log if forced removal was required.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Inactive domain controllers represent unmanaged endpoints that may retain cached credentials, hold stale FSMO roles, or be used as a re-entry point by attackers. Domain controllers that are no longer in active use should be formally decommissioned rather than simply powered off, as abandoned domain controller objects can cause replication errors and mislead directory health assessments.
Note that some cloud based or Azure AD/Entra ID joined domain controllers may appear to be inactive or unreachable with this check.
| Domain Controller | Operating System | Last Logon | Password Set |
|---|---|---|---|
| DENNIS-LT01.paddyspub.local | Windows Server 2008 R2 Standard | Never | Jul 17, 2025 |
LDAP Signing Not Enforced on Domain Controllers
LDAP Signing Not Enforced on Domain Controllers
LDAP Signing Not Enforced on Domain Controllers
When LDAP signing is not enforced on domain controllers, the LDAP traffic is vulnerable to man-in-the-middle (MitM) attacks, where attackers can intercept and modify requests between clients and servers. This allows attackers to manipulate LDAP queries, potentially gaining unauthorized access or modifying sensitive directory data, such as adding users to privileged groups.
Malicious actors look to perform MitM attacks in this fashion to add themselves to the Domain Administrators group.
Recommendation
Identify clients using unsigned LDAP binds, enable LDAP signing enforcement, and validate that dependent applications continue to authenticate successfully.
Prerequisites
- Domain Admin or Group Policy rights to create and modify GPOs linked to domain controllers.
- LDAP event monitoring enabled (Event ID 2886, 2887, 2888, 2889) to locate unsigned LDAP clients before enforcing.
- Application and device owner review completed.
- Change control approval obtained.
- Rollback plan documented.
Remediation Objective
- Enable LDAP event logging on domain controllers to locate clients using unsigned or unencrypted LDAP binds.
- Remediate or update all identified clients before enforcing LDAP signing.
- Set the LDAP server signing requirements policy to Require signing on all domain controllers.
- Verify that all legitimate LDAP clients continue to function after enforcement.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Enable LDAP signing enforcement on domain controllers via registry.
# This is an alternative to GPO for individual domain controllers.
$RegistryPath = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters"
Set-ItemProperty -Path $RegistryPath -Name "LDAPServerIntegrity" -Value 2 -Type DWord
Write-Output "LDAP signing set to Require on $env:COMPUTERNAME"
# Values: 0 = None, 1 = Negotiate signing, 2 = Require signingRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Event ViewerOn domain controllers, open Event Viewer and review the Directory Service log for LDAP signing-related events collected during the approved monitoring period.
- Open Group Policy Management ConsoleLaunch Group Policy Management Console from an administrative workstation.
- Edit the domain controller policyRight-click the Default Domain Controllers Policy or the approved hardening GPO linked to the Domain Controllers OU and select Edit.
- Navigate to the LDAP signing settingGo to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
- Require LDAP signingOpen Domain controller: LDAP server signing requirements, set it to Require signing, and save the setting.
- Review post-change eventsAfter normal policy refresh occurs, use Event Viewer to monitor the Directory Service log for rejected unsigned bind events and coordinate remediation for any affected applications.
Validation
- Confirm the LDAPServerIntegrity registry value is set to 2 on all domain controllers.
- Verify no Event ID 2889 (simple bind without SSL) entries appear in the Directory Service log after enforcement.
- Test LDAP connectivity from known applications to confirm they continue to function.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- LDAP event log review output showing no unsigned bind events after enforcement.
- GPO backup showing LDAP signing requirement.
- Application connectivity test results.
- Change ticket and approval record.
Additional Guidance
LDAP signing is a foundational control that ensures the integrity of directory queries and authentication exchanges between clients and domain controllers. Without it, an attacker in a network-adjacent position can intercept and modify LDAP traffic, potentially injecting privilege escalation commands or harvesting credentials. Microsoft has been progressively tightening default LDAP signing requirements, and organizations should align with current best practices.
The recommended approach is to enable LDAP diagnostic logging first, monitor for unsigned bind events over several weeks, remediate any non-compliant clients, and then enforce signing. This phased approach minimizes the risk of service disruption while ensuring full protection is achieved.
| Domain Controller | Operating System | Last Logon | Password Set |
|---|---|---|---|
| PADDY-DC01.paddyspub.local | Windows Server 2019 Datacenter | Jul 13, 2026 | Jul 5, 2026 |
| ROPADDY-DC01.paddyspub.local | Windows Server 2019 Datacenter | Jul 13, 2026 | Jul 5, 2026 |
| DENNIS-LT01.paddyspub.local | Windows Server 2008 R2 Standard | Never | Jul 17, 2025 |
Legacy Operating System on Domain Controller
Legacy Operating System on Domain Controller
Legacy Operating System on Domain Controller
Deprecated, unsupported, or otherwise legacy operating systems often do not receive security patches and may have known exploits available. Many legacy operating systems are unable to support modern day security features which increase the difficulty of securing them.
Domain controllers running unsupported operating systems could allow for direct compromise of the domain.
Recommendation
Replace legacy domain controllers with supported systems, transfer required roles, and demote the outdated domain controller after replication is healthy.
Prerequisites
- Domain Admin and Enterprise Admin rights required for domain controller demotion and FSMO role transfer.
- A replacement server meeting hardware and OS requirements provisioned and tested.
- Change control approval and maintenance window scheduled.
- Full domain controller backup performed before demotion.
Remediation Objective
- Deploy a replacement domain controller running a supported operating system.
- Transfer all FSMO roles from the legacy domain controller to the replacement.
- Demote and decommission the legacy domain controller.
- Verify replication and DNS are healthy after the transition.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Transfer FSMO roles from the legacy domain controller to a replacement.
# Replace <TargetDCName> with the SAM account name of the replacement domain controller.
# Replace <LegacyDCName> with the name of the legacy domain controller being decommissioned.
Import-Module ActiveDirectory
# Transfer all FSMO roles to the target domain controller.
Move-ADDirectoryServerOperationMasterRole -Identity "<TargetDCName>" -OperationMasterRole `
SchemaMaster, DomainNamingMaster, RIDMaster, PDCEmulator, InfrastructureMaster -Force
# Demote the legacy domain controller.
# Run the following on the legacy domain controller itself.
Uninstall-ADDSDomainController `
-DemoteOperationMasterRole:$true `
-RemoveApplicationPartitions:$true `
-Force:$trueRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Provision the replacement domain controllerUsing Server Manager on a supported Windows Server host, add the Active Directory Domain Services role and complete the domain controller promotion wizard according to the approved design.
- Transfer FSMO roles using GUI toolsUse the appropriate Active Directory administrative consoles to transfer FSMO roles from the legacy domain controller to a supported domain controller. Use Active Directory Users and Computers for RID, PDC, and Infrastructure roles, Active Directory Domains and Trusts for the Domain Naming Master role, and the Active Directory Schema snap-in for the Schema Master role.
- Demote the legacy domain controllerOn the legacy domain controller, open Server Manager and use the Remove Roles and Features wizard to remove the Active Directory Domain Services role. Complete the demotion wizard and restart the server if prompted.
- Remove stale domain controller referencesUse Active Directory Users and Computers, Active Directory Sites and Services, and DNS Manager to remove stale computer objects, server objects, replication connection objects, and DNS records associated with the retired domain controller.
- Confirm administrative console healthReview Active Directory Sites and Services, DNS Manager, and Server Manager to confirm the retired domain controller is no longer referenced and that remaining domain controllers appear healthy.
Validation
- Confirm the legacy domain controller is no longer listed in AD Sites and Services.
- Run repadmin /replsummary to confirm healthy replication across remaining domain controllers.
- Verify FSMO roles are held by the intended replacement: netdom query fsmo.
- Confirm DNS records for the legacy domain controller have been removed.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after AD Sites and Services screenshot showing domain controller inventory.
- FSMO role transfer confirmation (netdom query fsmo output).
- repadmin /replsummary output before and after demotion.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
A legacy domain controller should be prioritized for replacement because it affects one of the most sensitive roles in Active Directory. Plan migration carefully, validate FSMO roles and replication, and avoid in-place changes that could destabilize authentication services.
| Domain Controller | Operating System | Last Logon | Password Set |
|---|---|---|---|
| DENNIS-LT01.paddyspub.local | Windows Server 2008 R2 Standard | Never | Jul 17, 2025 |
Stale AD Backup
Stale AD Backup
Stale AD Backup
Backups of the Active Directory database are not updated or maintained according to best practices. Outdated backups can fail to capture recent changes in the environment, making them unreliable for recovery or rollback in the event of a failure or security incident.
Stale AD backups signify poor security posture and embolden attackers, particularly relating to ransomware attacks.
Recommendation
Restore regular Active Directory backup coverage, confirm recent successful System State or full server backups, and retain evidence for recovery readiness.
Prerequisites
- Domain Admin or equivalent rights to access backup configuration on domain controllers.
- Access to the backup solution used for Active Directory (Windows Server Backup, third-party agent, or similar).
- Change control approval if modifying backup schedules in a production environment.
- Locate which domain controllers are included in the current backup scope.
Remediation Objective
- Ensure that Active Directory System State or full server backups are being performed for all domain controllers.
- Verify that backup jobs are completing successfully and that backup media is current.
- Establish or enforce a backup schedule that meets Microsoft's recommended standards (at minimum, daily backups).
- Configure alerting for failed or overdue backup jobs.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Run from an elevated command prompt or PowerShell session on the affected domain controller.
# Replace <BackupTargetVolumeOrShare> with the approved backup destination.
wbadmin start systemstatebackup -backupTarget:<BackupTargetVolumeOrShare> -quiet
# Optional: review backup versions after the job completes.
wbadmin get versionsRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Windows Server BackupLaunch Windows Server Backup from Server Manager on the domain controller.
- Review the backup scheduleIn the Windows Server Backup console, click Backup Schedule and confirm that a scheduled backup job exists and is configured to include the System State or full server backup.
- Verify the last backup statusReview the backup job history to confirm that the most recent backup completed successfully and is within the acceptable window.
- Configure alertingIf your backup solution supports email or SIEM alerting, configure notifications for failed or overdue backup jobs.
- Document the backup configurationRecord the backup schedule, scope, retention period, and storage location in your change management or configuration documentation.
Validation
- Confirm the most recent backup timestamp using repadmin /showbackup or the backup solution console.
- Verify the last backup completed without errors by reviewing the backup job history.
- Confirm alerting is configured for failed backup jobs.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the business justification for any exception.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Backup job history export or screenshot confirming successful completion.
- repadmin /showbackup output captured before and after remediation.
- Change ticket and approval record for backup schedule modification.
- Alerting configuration documentation.
Additional Guidance
Active Directory backups should be treated as a critical recovery control, not just an infrastructure task. Review backup freshness, restore test results, and ownership regularly so the organization can recover from directory corruption, ransomware, or accidental administrative changes.
Weak LDAP Encryption
Weak LDAP Encryption
Weak LDAP Encryption
Weak LDAP encryption occurs when outdated and vulnerable SSL protocols, such as SSLv2 or SSLv3, are used to secure LDAP traffic. These protocols are considered weak and can be exploited by attackers to intercept and decrypt sensitive directory information, potentially leading to unauthorized access or data manipulation.
This misconfiguration is typically attacked through network poisoning to elevate privileges or obtain an initial foothold within the domain.
Recommendation
Disable weak SSL protocols on domain controllers, enable modern TLS settings, and validate LDAPS connectivity from dependent applications.
Prerequisites
- Domain Admin or local admin rights on domain controllers.
- Inventory of applications and devices using LDAPS with weak protocols completed.
- Change control approval obtained.
- Rollback plan documented (re-enabling via registry if compatibility issues arise).
Remediation Objective
- Disable SSLv2 and SSLv3 on all domain controllers via Schannel registry settings.
- Ensure TLS 1.2 or higher is enabled and functioning.
- Verify LDAPS connectivity continues to work after the change.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
Operational caution: Disabling legacy protocols may affect older LDAPS clients. Test application compatibility before broad deployment.
# Configure Schannel protocol settings on one approved domain controller.
# Run during a maintenance window and restart the server after the change.
$ProtocolsPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"
$Settings = @(
@{ Path = "SSL 2.0\Server"; Enabled = 0; DisabledByDefault = 1 },
@{ Path = "SSL 3.0\Server"; Enabled = 0; DisabledByDefault = 1 },
@{ Path = "TLS 1.2\Server"; Enabled = 1; DisabledByDefault = 0 }
)
foreach ($Setting in $Settings) {
$Path = Join-Path $ProtocolsPath $Setting.Path
New-Item -Path $Path -Force | Out-Null
Set-ItemProperty -Path $Path -Name Enabled -Value $Setting.Enabled -Type DWord
Set-ItemProperty -Path $Path -Name DisabledByDefault -Value $Setting.DisabledByDefault -Type DWord
}# Import reviewed domain controllers for Schannel updates.
# CSV column: ServerName.
$Servers = Import-Csv -Path ".\ApprovedDomainControllers.csv"
foreach ($Server in $Servers) {
Invoke-Command -ComputerName $Server.ServerName -ScriptBlock {
$ProtocolsPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"
$Settings = @(
@{ Path = "SSL 2.0\Server"; Enabled = 0; DisabledByDefault = 1 },
@{ Path = "SSL 3.0\Server"; Enabled = 0; DisabledByDefault = 1 },
@{ Path = "TLS 1.2\Server"; Enabled = 1; DisabledByDefault = 0 }
)
foreach ($Setting in $Settings) {
$Path = Join-Path $ProtocolsPath $Setting.Path
New-Item -Path $Path -Force | Out-Null
Set-ItemProperty -Path $Path -Name Enabled -Value $Setting.Enabled -Type DWord
Set-ItemProperty -Path $Path -Name DisabledByDefault -Value $Setting.DisabledByDefault -Type DWord
}
}
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Registry EditorLaunch regedit on the domain controller with administrative rights.
- Navigate to Schannel ProtocolsGo to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
- Disable SSLv2Create or navigate to the SSL 2.0\Server subkey. Set Enabled to 0 and DisabledByDefault to 1.
- Disable SSLv3Create or navigate to the SSL 3.0\Server subkey. Set Enabled to 0 and DisabledByDefault to 1.
- Enable TLS 1.2Create or navigate to the TLS 1.2\Server subkey. Set Enabled to 1 and DisabledByDefault to 0.
- Restart the serverA restart is required for Schannel changes to take effect. Schedule during a maintenance window.
Validation
- Confirm SSLv2 and SSLv3 are disabled by testing with an SSL scanner or using openssl s_client against the LDAPS port.
- Verify TLS 1.2 is functioning correctly by testing LDAPS connectivity from known applications.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after Schannel registry export.
- SSL scanner output confirming weak protocols are disabled.
- LDAPS connectivity test results.
- Server restart documentation.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
SSLv2 and SSLv3 contain fundamental cryptographic weaknesses that make them vulnerable to decryption attacks. Organizations should configure all domain controllers to support only TLS 1.2 or higher for LDAPS connections. IIS Crypto or similar tools can provide a convenient interface for managing Schannel settings across multiple servers.
Organizations should also review TLS cipher suite configuration to ensure that weak cipher suites are disabled alongside weak protocol versions. A comprehensive Schannel hardening exercise should cover protocol versions, cipher suites, and key exchange algorithms to ensure the LDAPS implementation meets current security standards.
| Domain Controller | Operating System | Last Logon | Password Set |
|---|---|---|---|
| ROPADDY-DC01.paddyspub.local | Windows Server 2019 Datacenter | Jul 13, 2026 | Jul 5, 2026 |
Policy and Configuration Management
18 findings
Domain Controllers with SMBv1 Enabled
Domain Controllers with SMBv1 Enabled
Domain Controllers with SMBv1 Enabled
SMBv1 is a legacy protocol that lacks modern security features and is considered weak and susceptible to downgrade attacks. Allowing SMBv1 support on domain controllers introduces integrity issues on critical assets.
SMBv1 enablement is easy to detect with open-source hacker toolsets. Once identified, it’s usually paired with network poisoning attacks to elevate privileges. This type of setting signals to the hacker that your environment is not hardened and there are likely multiple avenues for compromise.
Recommendation
Disable SMBv1 on domain controllers, confirm the feature is removed or disabled, and validate that any dependent legacy systems are addressed.
Prerequisites
- Domain Admin or local administrator rights on the domain controller.
- Inventory of systems and applications that may rely on SMBv1 completed before disabling.
- Change control approval obtained.
- Rollback plan documented (re-enabling SMBv1 via registry if compatibility issues arise).
Remediation Objective
- Disable SMBv1 on all domain controllers to eliminate the risk of exploitation via known SMBv1 vulnerabilities.
- Confirm no legacy application or printer requires SMBv1 before disabling.
- Verify domain controller functionality after the change.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Disable SMBv1 on a domain controller.
# This change requires a server restart to take full effect.
# Disable the SMBv1 client.
Set-SmbClientConfiguration -EnableSMB1Protocol $false -Force
# Disable the SMBv1 server.
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force# Disable SMBv1 on multiple domain controllers remotely.
# CSV must contain a column named ServerName.
$Servers = Import-Csv -Path ".\ApprovedDomainControllers.csv"
foreach ($Server in $Servers) {
Invoke-Command -ComputerName $Server.ServerName -ScriptBlock {
Set-SmbClientConfiguration -EnableSMB1Protocol $false -Force
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
Write-Output "SMBv1 disabled on $env:COMPUTERNAME"
}
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Disable SMBv1 through Server ManagerOpen Server Manager, click Manage, then Remove Roles and Features. Navigate to Features and locate SMB 1.0/CIFS File Sharing Support. Clear the feature and complete the wizard.
- Restart during the maintenance windowRestart the domain controller during the approved maintenance window so the change takes effect.
- Review service healthAfter restart, use Server Manager and Event Viewer to confirm the server is healthy and that no SMBv1-dependent service issues are present.
Validation
- Confirm SMBv1 is disabled: Get-SmbServerConfiguration | Select EnableSMB1Protocol should return False.
- Verify domain controller services are operating normally after the restart.
- Test SMB connectivity from known client systems to confirm no disruption to authorized file sharing.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after Get-SmbServerConfiguration output.
- Change ticket and approval record.
- Server restart documentation.
- Post-restart service health confirmation.
- Follow-up scan results showing finding resolved.
Additional Guidance
SMBv1 has been deprecated by Microsoft since 2014 and is the protocol that enabled the WannaCry and NotPetya ransomware campaigns to propagate rapidly across enterprise networks. Organizations should treat SMBv1 disablement as a baseline hardening requirement for all Windows servers, starting with domain controllers.
Long-term, organizations should maintain an inventory of SMBv1-dependent devices and track them through a formal decommission or upgrade process. Network monitoring should be configured to alert on SMBv1 protocol usage to detect any undiscovered dependencies or exploitation attempts.
| Domain Controller | Operating System | Last Logon | Password Set |
|---|---|---|---|
| ROPADDY-DC01.paddyspub.local | Windows Server 2019 Datacenter | Jul 13, 2026 | Jul 5, 2026 |
Exchange Not Hardened
Exchange Not Hardened
Exchange Not Hardened
An unhardened Microsoft Exchange installation, whether active or legacy, can introduce privilege escalation vulnerabilities by altering domain permissions. Attackers can exploit these misconfigurations to modify permissions, enabling them to perform DCSync attacks, which can extract credential hashes and potentially lead to full domain compromise.
Attackers use readily available tools like Mimikatz, PowerShell Empire, Cobalt Strike, or the Impacket toolset to exploit unhardened Exchange installations and perform DCSync attacks. This technique tricks domain controllers into replicating sensitive credential data, such as password hashes. Adversaries can either attempt to crack these hashes or pass them to move laterally within the network, particularly targeting the krbtgt account to execute Golden Ticket attacks.
Recommendation
Apply the identified Exchange hardening changes, validate secure configuration, and confirm mail services remain operational.
Prerequisites
- Exchange Administrator and Domain Administrator credentials required.
- Review the specific Exchange hardening issues identified from the report (e.g., RBAC misconfigurations.
- Back up current Exchange configuration and related AD permissions before modifications.
- Plan a maintenance window for changes that may affect mail flow or client connectivity.
Remediation Objective
- Remediate specific Exchange hardening deficiencies identified in the report.
- Remove overly permissive Exchange-related AD permissions (e.g., Exchange Windows Permissions WriteDACL on the domain object).
- Disable unnecessary legacy protocols (e.g., Basic Auth, NTLM on client access, SMTP open relay).
- Reduce the Exchange attack surface and eliminate known privilege escalation paths via Exchange AD permissions.
Remediation Path 1: Command-Line
Not applicable. A command-line remediation is not the preferred remediation method for this finding because Exchange hardening is version-specific and should follow the supported Exchange administrative tools, security baseline, and change plan rather than a generic command-line remediation.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the Exchange Administrative CenterSign in to the Exchange Administrative Center with an approved Exchange administrator account.
- Review virtual directory authenticationNavigate to Servers > Virtual Directories and review authentication settings. Disable legacy authentication methods where they are not required and approved.
- Review receive connectorsNavigate to Mail Flow > Receive Connectors and confirm relay settings are restricted to approved systems and networks only.
- Review Exchange role groupsNavigate to Permissions > Admin Roles and remove unnecessary accounts from Exchange role groups.
- Review related Active Directory permissionsUse the approved Active Directory permission management console for the environment to review and remove overly permissive Exchange-related delegated permissions after service owner approval.
- Save and validateApply approved changes and confirm mail flow, administrative access, and required application integrations continue to function.
Validation
- Confirm overly permissive Exchange AD permissions have been removed from the domain object ACL.
- Verify legacy protocols are disabled on the intended virtual directories.
- Test mail flow and client connectivity after each change.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the business justification for any exception.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Exchange and AD configuration export before changes.
- Change ticket and approval record.
- Post-change ACL and configuration review confirming hardening is applied.
- Mail flow and client connectivity test results.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Exchange Server has historically introduced several well-known privilege escalation paths in Active Directory, most notably the PrivExchange vulnerability which allowed a user with a mailbox to escalate to Domain Admin through Exchange's overly permissive WriteDACL rights on the domain object. Even in patched environments, Exchange AD permissions and protocol configurations require ongoing hardening attention. Organizations should follow Microsoft's Exchange security hardening guidance and apply all relevant mitigations regardless of patch status.
Microsoft - Reducing permissions required to run Exchange Server with the Shared Permissions Model
Microsoft - February 2019 quarterly Exchange updates (reduced Exchange AD permissions)
Microsoft - Configure Exchange 2013 for shared permissions
GitHub - gdedrouas/Exchange-AD-Privesc - Exchange privilege escalation paths to Active Directory
Hardened UNC Paths Not Enforced
Hardened UNC Paths Not Enforced
Hardened UNC Paths Not Enforced
Hardened UNC paths are not enforced for SYSVOL and NETLOGON through Group Policy. Without these protections, clients may be more exposed to tampering or interception when retrieving Group Policy and logon script content from domain controllers. Hardened UNC path settings should require mutual authentication and integrity for these critical shares.
SYSVOL and NETLOGON are trusted sources for Group Policy and logon content across the domain. Without hardened UNC path requirements, attackers who can interfere with network traffic (fore example through ARP, LLMNR, or DNS spoofing) may have more opportunity to tamper with or impersonate these paths. This can affect many domain-joined systems because they routinely retrieve policy from these shares.
Recommendation
Enforce Hardened UNC Paths for SYSVOL and NETLOGON via domain-wide Group Policy.
Prerequisites
- Rights to edit and link a domain-level GPO.
- Confirmation that domain controllers support the required SMB features (all supported Windows Server versions do).
- Obtain change control approval.
Remediation Objective
- Configure Hardened UNC Paths for \\*\SYSVOL and \\*\NETLOGON requiring mutual authentication and integrity.
- Link the GPO so it applies to all domain-joined computers.
- Confirm clients receive and apply the setting.
Remediation Path 1: Command-Line
Hardened UNC Paths are a Group Policy setting; configure them centrally rather than per machine.
# Hardened UNC Paths are normally set via Group Policy (see the GUI steps). They write these registry
# values under HKLM, which a GPO should deploy to every machine rather than setting them host-by-host.
$Key = "HKLM:\Software\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths"
New-Item -Path $Key -Force | Out-Null
New-ItemProperty -Path $Key -Name "\\*\SYSVOL" -Value "RequireMutualAuthentication=1, RequireIntegrity=1" -PropertyType String -Force
New-ItemProperty -Path $Key -Name "\\*\NETLOGON" -Value "RequireMutualAuthentication=1, RequireIntegrity=1" -PropertyType String -Force# Confirm the policy is present on a domain-joined machine.
Get-Item "HKLM:\Software\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths" |
Select-Object -ExpandProperty PropertyRemediation Path 2: GUI
Use this path to configure the setting in Group Policy so it applies domain-wide.
- Open the Group Policy Management ConsoleLaunch gpmc.msc and edit (or create) a GPO linked at the domain.
- Navigate to Hardened UNC PathsGo to Computer Configuration > Policies > Administrative Templates > Network > Network Provider > Hardened UNC Paths.
- Enable the policySet the policy to Enabled.
- Add the SYSVOL and NETLOGON pathsAdd \\*\SYSVOL and \\*\NETLOGON, each with the value RequireMutualAuthentication=1, RequireIntegrity=1.
- Link and confirmEnsure the GPO is linked so all domain-joined computers receive it, then run gpupdate on a client to confirm.
Validation
- Confirm the Hardened UNC Paths policy is applied (gpresult or the registry key on a client).
- Verify clients still access SYSVOL and NETLOGON normally.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If a legacy client cannot meet the requirement, scope the exception narrowly and document it.
- Record owner and target date for any deferral.
- Track formal risk acceptance.
Evidence
- GPO settings report and a client-side registry/gpresult capture.
- Confirmation that policy and script delivery still function.
- Follow-up scan results confirming resolution.
Additional Guidance
Hardened UNC paths defend the delivery channel; also enable SMB signing domain-wide and reduce name-resolution spoofing by disabling LLMNR and NBT-NS, which are the usual ways an attacker gets into a position to man-in-the-middle SYSVOL traffic.
Misconfigured enrollment agent templates in ADCS (ESC3)
Misconfigured enrollment agent templates in ADCS (ESC3)
Misconfigured enrollment agent templates in ADCS (ESC3)
Offering misconfigured certificate templates could permit attackers to request certificates on behalf of other users, allowing them to impersonate high-privileged accounts without needing their credentials. This vulnerability arises when certificate templates have overly permissive configurations that enable users to request certificates with an alternate identity, effectively granting unauthorized access.
Adversaries leverage this early in a compromise to impersonate higher-privileged accounts within a domain to quickly escalate their access. Using tools like Certipy or Certify, they identify vulnerable templates, request certificates with alternate identities, and use these certificates to authenticate as the impersonated users. This method provides a covert path to high-privilege access and control over domain resources, often evading detection due to the legitimate appearance of certificate-based authentication.
Recommendation
Restrict enrollment agent templates to approved PKI administrators, require appropriate controls, and validate unauthorized enrollment is blocked.
Prerequisites
- Locate the specific enrollment agent template and the overly permissive enrollment rights.
- Determine which accounts legitimately require enrollment agent certificate rights.
- Coordinate with the PKI team before modifying template permissions.
- Back up template configuration before changes.
Remediation Objective
- Restrict enrollment agent certificate template permissions to authorized PKI administrators only.
- Prevent unauthorized accounts from obtaining enrollment agent certificates that can be used to enroll on behalf of other users.
- Eliminate the ESC3 attack vector where a low-privileged user obtains an enrollment agent certificate and uses it to request certificates on behalf of privileged accounts.
- Ensure enrollment agent templates are accessible only to documented, authorized personnel.
Remediation Path 1: Command-Line
Not applicable. A command-line remediation is not the preferred remediation method for this finding because enrollment agent template remediation should be performed through the Certificate Templates Console and PKI governance process because improper command-line changes can disrupt certificate issuance workflows.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Certificate Templates ConsoleRun
certtmpl.msc. - Locate the enrollment agent templateFind the template identified in the report (e.g., Enrollment Agent or a custom equivalent).
- Open template propertiesRight-click the template and select Properties.
- Restrict enrollment permissionsClick the Security tab. Remove Enroll rights from any accounts or groups that are not authorized enrollment agents. Add only the specific PKI administrator accounts or group that require enrollment agent rights.
- Configure CA enrollment agent restrictionsIn the Certification Authority console (
certsrv.msc), right-click the CA and select Properties. Click the Enrollment Agents tab and configure restrictions on which agents can enroll for which certificate templates and on behalf of which users. - Save and validateTest that authorized enrollment agents can still function and unauthorized accounts cannot obtain enrollment agent certificates.
Validation
- Confirm enrollment agent template permissions are restricted: review the Security tab in certtmpl.msc.
- Verify CA enrollment agent restrictions are configured: review the Enrollment Agents tab in certsrv.msc.
- Test that an unauthorized account cannot request an enrollment agent certificate.
- Run a follow-up scan to confirm the ESC3 finding is resolved.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- Enrollment agent template configuration export before changes.
- Change ticket and approval record.
- certtmpl.msc and certsrv.msc configuration screenshots confirming restrictions.
- Test confirming unauthorized account cannot request an enrollment agent certificate.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Limit enrollment permissions on certificate templates, enforce strict EKU restrictions to control usage, and regularly audit templates for misconfigurations. Monitoring certificate requests and minimizing permissions help to quickly detect and respond to any abuse. As multiple conditions must align for this vulnerability to be exploited, disrupting any one of these conditions may effectively prevent this escalation attack.
• Low-Privileged Enrollment Rights: The Certificate Authority (CA) permits enrollment requests from low-privileged groups, such as "Authenticated Users" or "Domain Users," which broadens the potential for misuse. • Lack of Approval Mechanisms: When certificates are issued without requiring manager approval or authorized signatures, the process lacks oversight, allowing unauthorized users to request high-privilege certificates without detection. • Loose EKU Settings: If a certificate template is configured with Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1), it allows requests on behalf of other users.
| Object | Type |
|---|---|
| Wolf Cola Enroll | Certificate template |
NT AUTHORITY\Authenticated UsersEnroll | Account |
SpecterOps - Certified Pre-Owned: abusing Active Directory Certificate Services (ESC1-ESC8)
The Hacker Recipes - ADCS Certificate Request Agent EKU template (ESC3)
Microsoft - Securing AD CS with Microsoft Defender for Identity's sensor
SpecterOps - ADCS attack paths in BloodHound, part 2 (Golden Certificate and ESC3)
Risky GPO Assignment to Local Groups
Risky GPO Assignment to Local Groups
Risky GPO Assignment to Local Groups
Assigning Group Policy Objects (GPOs) to broad groups like "Everyone," "Authenticated Users," or "Domain Users" and granting access to privileged local groups, such as local administrators, can result in over-privileged access. This misconfiguration allows users with minimal permissions to perform actions typically reserved for administrators.
Attackers exploit this misconfiguration to elevate privileges and gain access to sensitive systems. This often leads to delegation and credential harvesting attacks, enabling lateral movement across the domain.
Recommendation
Remove broad or unauthorized GPO-based local group assignments and validate endpoint local administrators reflect approved membership.
Prerequisites
- Domain Administrator or GPO Administrator credentials required.
- Locate the specific GPO and the Restricted Groups or Local Users.
- Coordinate with the GPO owner and infrastructure teams before modifying.
- Back up affected GPO before making changes.
Remediation Objective
- Remove or restrict GPO-based assignments that place overly broad or unauthorized accounts in sensitive local groups on endpoints.
- Prevent non-administrative or risky accounts from being added to the local Administrators group on domain-joined systems via GPO.
- Ensure local group membership on endpoints reflects the principle of least privilege.
- Reduce the risk of lateral movement via compromised accounts with local administrator access on multiple systems.
Remediation Path 1: Command-Line
Not applicable. A command-line remediation is not the preferred remediation method for this finding because local group assignment changes should be made through Group Policy Management so the affected GPO, item-level targeting, and rollback behavior are controlled through the policy workflow.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch Group Policy Management Console from an administrative workstation.
- Locate and edit the affected GPORight-click the GPO identified in the report and select Edit.
- Navigate to local group assignment settingsFor Restricted Groups, go to Computer Configuration > Windows Settings > Security Settings > Restricted Groups. For Group Policy Preferences, go to Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups.
- Open the affected local group assignmentSelect the entry that assigns accounts or groups to a sensitive local group, such as Administrators.
- Remove or correct the risky assignmentDelete the unauthorized entry or modify the membership so only approved principals are assigned.
- Save and confirm scopeClose the editor and confirm the GPO link, security filtering, and OU scope match the approved remediation plan.
Validation
- Confirm the GPO setting has been updated: review the GPO in GPMC.
- Run gpupdate /force on a test endpoint and verify the local group no longer contains the risky account: Get-LocalGroupMember -Group 'Administrators'
- Monitor for any access failures on affected endpoints following the change.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the policy dependency and business justification.
- Assign a policy owner and target remediation date.
- Apply compensating controls until the policy is corrected.
Evidence
- GPO backup before changes.
- Change ticket and approval record.
- Post-change GPMC configuration review confirming the risky assignment is removed.
- Local group membership test on a representative endpoint.
- Follow-up scan results confirming finding resolution.
Additional Guidance
GPO-based local group assignments via Restricted Groups or Local Users and Groups preferences are a powerful mechanism that can inadvertently grant widespread local administrator access across large numbers of endpoints. An overly broad assignment adds every account in a specified domain group to the local Administrators group on all computers in the GPO scope, dramatically expanding the lateral movement surface if any of those accounts is compromised.
To prevent recurrence, include local group assignment GPO settings in the periodic GPO security review. Establish a policy requiring formal approval and documented business justification for any GPO that assigns accounts to the local Administrators group. Use Microsoft LAPS or Windows LAPS to manage local administrator accounts rather than shared or broadly assigned local admin credentials.
| Object | Type |
|---|---|
| Default Domain Policy | Group policy |
Risky GPO Control Permissions
Risky GPO Control Permissions
Risky GPO Control Permissions
One or more Group Policy Objects grant edit or control permissions to non-standard principals. A user who can modify a GPO can change settings, scripts, or scheduled tasks that apply to systems and users within the GPO scope. GPO permissions should be reviewed carefully, especially for policies linked to domain controllers or broad organizational units.
GPO control is a powerful escalation path because policy can apply settings, scripts, scheduled tasks, and local rights across many systems. If a non-standard principal can edit or control a GPO, they may be able to affect every user or computer within scope. Broadly linked GPOs and domain controller policies are especially sensitive.
Recommendation
Remove GPO edit rights from non-default principals and restrict editing to authorized administrators.
Prerequisites
- Rights to modify GPO delegation.
- Knowledge of who legitimately administers each GPO.
- Obtain change control approval.
Remediation Objective
- Remove edit permissions from non-default principals on each affected GPO.
- Restrict GPO editing to authorized administrators.
- Investigate how the delegation was granted.
Remediation Path 1: Command-Line
Use this path to review and correct GPO delegation.
Import-Module GroupPolicy
# Review delegation on the GPO.
Get-GPPermission -Name "<GPO Display Name>" -All
# Remove a non-default principal's permissions.
Set-GPPermission -Name "<GPO Display Name>" -TargetName "CONTOSO\suspectAccount" -TargetType User -PermissionLevel None -Replace# List non-standard editors across all GPOs for review.
Import-Module GroupPolicy
Get-GPO -All | ForEach-Object {
$name = $_.DisplayName
Get-GPPermission -Name $name -All |
Where-Object { $_.Permission -match 'Edit|GpoEditDeleteModifySecurity' } |
Select-Object @{N='Gpo';E={$name}}, Trustee, Permission
}Remediation Path 2: GUI
Use this path to correct delegation through the console.
- Open the Group Policy Management ConsoleLaunch gpmc.msc from an administrative workstation.
- Locate the GPOSelect the GPO identified in the report.
- Open the Delegation tabClick the Delegation tab to see who has edit rights.
- Remove or lower the principalRemove the non-default principal, or set its permission to Read where only visibility is needed.
- ConfirmVerify only authorized administrators retain edit rights.
Validation
- Confirm only authorized administrators can edit each GPO.
- Verify legitimate GPO administration still functions.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If a team legitimately edits a GPO, scope the delegation to that GPO only and document it.
- Investigate any unexplained delegation as a potential compromise.
- Track formal risk acceptance.
Evidence
- GPO delegation export before and after.
- Investigation notes on how the delegation was granted.
- Follow-up scan results confirming resolution.
Additional Guidance
Prioritize GPOs linked to domain controllers or wide scopes, since those grant the broadest reach. Establish a small set of GPO administrators and review GPO delegation on the same cadence as privileged group membership.
| Object | Type |
|---|---|
| DeployFile | Group policy |
Risky GPO Login Script Permissions
Risky GPO Login Script Permissions
Risky GPO Login Script Permissions
Risky GPO login script permissions occur when low-privileged users, such as Authenticated Users or Everyone, have the ability to modify login scripts. This misconfiguration can allow attackers to insert or alter scripts that execute during user logins, potentially leading to remote code execution and persistence.
Attackers can modify login scripts with malicious code, allowing them to execute their payloads on multiple machines during user logins. Using tools like PowerShell or Group Policy Management Editor, the attacker could inject scripts that install malware, steal credentials, or establish persistent backdoors.
Recommendation
Restrict SYSVOL login script write permissions to approved administrators and validate standard users cannot modify deployed scripts.
Prerequisites
- Domain Administrator or GPO Administrator credentials required.
- Locate the specific login scripts referenced in affected GPOs and their file paths in SYSVOL.
- Determine which accounts legitimately require write access to the script files.
- Review the current NTFS ACLs on the script files.
- Coordinate with GPO and infrastructure teams before modifying permissions.
- Back up the script files and current ACL configuration before making changes.
- Obtain change control approval.
Remediation Objective
- Restrict write and modify permissions on GPO login script files in SYSVOL to authorized administrators only.
- Prevent non-administrative accounts from modifying login scripts that execute in user or computer security contexts.
- Eliminate the risk of script tampering leading to code execution on endpoints during logon.
- Align SYSVOL script file permissions with the principle of least privilege.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
Operational caution: Login script permission changes can affect user logon behavior. Test with a pilot user before broad rollout.
# Preview and apply an approved ACL change for one login script.
$ScriptPath = "<ScriptPath>"
$PrincipalName = "<PrincipalName>"
$ApprovedGroup = "<ApprovedGroup>"
Write-Output "Preview: remove $PrincipalName from $ScriptPath"
Write-Output "Preview: grant read and execute to $ApprovedGroup on $ScriptPath"
icacls $ScriptPath /remove:g $PrincipalName
icacls $ScriptPath /grant:r "$($ApprovedGroup):(RX)"# Import reviewed and approved login script ACL changes.
# CSV columns: ScriptPath, PrincipalName, ApprovedGroup.
$Scripts = Import-Csv -Path ".\ApprovedLoginScriptAclChanges.csv"
$PreviewOnly = $true
foreach ($Script in $Scripts) {
if ($PreviewOnly) {
Write-Output "Preview: remove $($Script.PrincipalName) from $($Script.ScriptPath)"
Write-Output "Preview: grant read and execute to $($Script.ApprovedGroup) on $($Script.ScriptPath)"
}
else {
icacls $Script.ScriptPath /remove:g $Script.PrincipalName
icacls $Script.ScriptPath /grant:r "$($Script.ApprovedGroup):(RX)"
}
}
# Set $PreviewOnly to $false only after the CSV has been reviewed and approved.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the approved file management interface or the SYSVOL shareNavigate to \\<DomainName>\SYSVOL\<DomainName>\scripts\ or the specific GPO script folder.
- Locate the affected script fileRight-click the file and select Properties.
- Review SecurityClick the Security tab, then Advanced to see all ACEs.
- Remove unauthorized write accessSelect the unauthorized entry that grants write or modify permissions and click Remove.
- Save and testClick OK. Test that the login script executes correctly from a test client workstation.
Validation
- Confirm the ACL on the script file no longer grants write access to unauthorized accounts: Get-Acl -Path <ScriptPath>
- Test login script execution on a test workstation to confirm the script still runs correctly.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the policy dependency and business justification.
- Assign a policy owner and target remediation date.
- Apply compensating controls until the policy is corrected.
Evidence
- ACL export for affected script files before changes.
- Change ticket and approval record.
- Post-change ACL review confirming unauthorized write access is removed.
- Login script execution test confirming normal operation.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Ensure that only trusted administrative accounts have the necessary permissions to modify login scripts and their parent folders. Regularly audit GPO settings to identify and correct any improper permissions on login scripts. Additionally, monitoring for changes in script paths or permissions can help detect early signs of abuse or unauthorized access attempts.
Microsoft - Using startup, shutdown, logon, and logoff scripts in Group Policy
Microsoft - Startup, shutdown, logon, and logoff scripts using the Local Group Policy Editor
The Hacker Recipes - Abusing DACL rights on logon scripts
offsec.blog - Hidden menace: identifying misconfigured and dangerous logon scripts
Unencrypted Certificate Enrollment in ADCS (ESC8)
Unencrypted Certificate Enrollment in ADCS (ESC8)
Unencrypted Certificate Enrollment in ADCS (ESC8)
Unencrypted Certificate Enrollment occurs when the certificate enrollment interface is accessible over HTTP instead of HTTPS. This exposes sensitive data, including certificate requests, to potential interception by attackers.
Adversaries exploit unencrypted certificate enrollment by relaying privileged credentials to gain control over the domain, commonly in combination with network poisoning attacks. Vulnerabilities like PetitPotam, which have become popular among ransomware groups, are frequently used to facilitate these attacks.
Recommendation
Require HTTPS for ADCS enrollment endpoints, validate certificate trust, and confirm enrollment traffic is no longer exposed in plaintext.
Prerequisites
- Enterprise Administrator or PKI Administrator credentials required, along with IIS Administrator access.
- Coordinate with the PKI and endpoint teams before making changes.
- Obtain change control approval.
- Plan a maintenance window to avoid disrupting active enrollment operations.
Remediation Objective
- Enforce HTTPS for the ADCS Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service endpoints.
- Prevent certificate enrollment credentials and request data from being transmitted in plaintext over HTTP.
- Eliminate the ESC8 attack vector, which allows an attacker to relay NTLM authentication to the HTTP enrollment endpoint to obtain certificates on behalf of other accounts.
- Align ADCS web enrollment configuration with current Microsoft PKI security guidance.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Run on the ADCS/IIS server with administrative privileges.
# Confirm that an SSL certificate is bound to the CES/CEP IIS site before enforcing HTTPS.
# List current IIS site bindings:
Get-WebBinding -Name "Default Web Site"
# Require SSL on the CertSrv virtual directory:
Set-WebConfiguration -Filter "system.webServer/security/access" `
-PSPath "IIS:\Sites\Default Web Site\CertSrv" `
-Value @{ sslFlags = "Ssl" }# Import the required module for the remediation.
Import-Module ActiveDirectory
# Import a reviewed and approved list of affected objects to remediate.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
# Update only the objects included in the approved input file.
foreach ($Item in $Items) {
# Replace the placeholder command with the approved single-object remediation command for Unencrypted Certificate Enrollment in ADCS (ESC8).
# Use -WhatIf when supported before applying the change.
<Approved-Remediation-Command> -Identity $Item.DistinguishedName -WhatIf
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Bind an SSL certificate to the IIS siteOn the CA server, open the web server management console (inetmgr). Select the site hosting the enrollment endpoint (typically Default Web Site). Click Bindings, add an HTTPS binding on port 443, and select the provisioned SSL certificate.
- Require SSL on the CertSrv virtual directoryIn the web server management console, expand the site and select the CertSrv virtual directory. Double-click SSL Settings and check 'Require SSL'. Set client certificates to Ignore or Accept as appropriate.
- Update enrollment URLsIn the Certification Authority console (
certsrv.msc), go to Properties > Enrollment Agents or update Group Policy enrollment URLs to reference the HTTPS endpoint. - Test enrollmentAttempt a manual certificate enrollment from a test client using the HTTPS URL to confirm it succeeds.
- Revoke HTTP accessConsider disabling or removing the HTTP binding from the IIS site after confirming HTTPS enrollment is functional.
Validation
- Confirm the enrollment endpoint is accessible only via HTTPS: attempt to connect via http:// and confirm it redirects or is blocked.
- Verify the SSL certificate is valid and trusted by domain clients.
- Test a manual enrollment via the HTTPS URL to confirm successful operation.
- Run a follow-up scan to confirm the ESC8 finding is resolved.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- IIS configuration backup before changes.
- SSL certificate details (thumbprint, expiry, issuing CA).
- Change ticket and approval record.
- IIS SSL Settings screenshot confirming Require SSL is enabled.
- Test enrollment confirmation via HTTPS.
- Follow-up scan results confirming finding resolution.
Additional Guidance
It's essential to enforce HTTPS for all certificate-related communications to protect sensitive credential exchanges. Regular audits should ensure that certificate enrollment services are secure, particularly those handling domain controller certificates, which are critical for domain security.
| Object | Type |
|---|---|
| paddyspub-RODC-CA | Certificate authority |
Unrestricted certificate template modification rights in ADCS (ESC4)
Unrestricted certificate template modification rights in ADCS (ESC4)
Unrestricted certificate template modification rights in ADCS (ESC4)
Certificate templates with over-permissioned write settings allow low-level users to modify template properties that can make them vulnerable to various privilege escalation attacks. This misuse could allow an attacker to create a certificate for any user, effectively impersonating them within the network and gaining unauthorized access.
Attackers typically exploit this to modify permissions on certificate templates to make them vulnerable to ESC1, which allows the attacker to perform privilege escalation to that of a domain administrator. This method is stealthy, as certificate-based authentication blends into normal operations, providing attackers with a hidden and resilient path for privilege escalation and persistence.
Recommendation
Remove unauthorized template modification rights, validate ownership and ACLs, and monitor for future certificate template permission drift.
Prerequisites
- Locate which accounts or groups have write, full control, or other modification rights on affected templ.
- Determine which accounts legitimately require template modification rights.
- Back up template ACL configuration before changes.
- Obtain change control approval.
Remediation Objective
- Remove unauthorized write and modification permissions from Active Directory Certificate Services certificate templates.
- Restrict template modification rights to authorized PKI administrators only.
- Prevent low-privileged accounts from modifying certificate templates to introduce ESC1, ESC2, or other misconfigurations.
- Eliminate the ESC4 attack vector where a low-privileged user with write access to a template can modify it to allow certificate-based privilege escalation.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Run from an elevated command prompt on an administrative workstation with RSAT installed.
# Replace <TemplateName> and <PrincipalName> with reviewed values.
dsacls "CN=<TemplateName>,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,<ForestRootDN>" /R "<PrincipalName>"
# Optional: grant approved read or enroll permissions only when required by the change plan.
# Replace <ApprovedGroup> with the approved security group.
dsacls "CN=<TemplateName>,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,<ForestRootDN>" /G "<ApprovedGroup>:GR"Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Certificate Templates ConsoleRun
certtmpl.msc. - Locate the affected templateFind the template identified in the report.
- Open template propertiesRight-click the template and select Properties.
- Review SecurityClick the Security tab, then Advanced to see all ACEs.
- Remove unauthorized write permissionsLocate entries granting Write, Full Control, or WriteDACL to accounts that are not authorized PKI administrators. Select and remove each unauthorized entry.
- Save and validateClick OK. Confirm that authorized PKI administrators can still modify the template and that unauthorized accounts cannot.
Validation
- Confirm the updated template ACL via the Security tab in certtmpl.msc.
- Verify that an unauthorized account cannot modify the template (test with a non-admin account).
- Run a follow-up scan to confirm the ESC4 finding is resolved.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- Template ACL export before changes.
- Change ticket and approval record.
- Post-change ACL review confirming unauthorized write permissions are removed.
- Test confirming unauthorized account cannot modify the template.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Ensuring proper permissions are set by following least privilege principles. Regularly auditing these permissions and ensuring only trusted principals have write capabilities on certificate templates is essential. Additionally, monitoring certificate issuance for unusual activity can serve as an early indicator of potential compromise. Pay special attention to the following permissions: Owner, FullControl, WriteOwner, WriteDacl, WriteProperty. Having values such as “Domain Users, Domain Computers, Everyone, or Authenticated Users” is considered risky.
| Object | Type |
|---|---|
| paddyspub-RODC-CA | Certificate authority |
| Fight Milk Any Purpose | Certificate template |
NT AUTHORITY\Authenticated UsersWrite owner | Account |
| Wolf Cola Enroll | Certificate template |
NT AUTHORITY\Authenticated UsersWrite owner | Account |
Unrestricted certificate template with any purpose in ADCS (ESC2)
Unrestricted certificate template with any purpose in ADCS (ESC2)
Unrestricted certificate template with any purpose in ADCS (ESC2)
Permissive certificate templates in Active Directory Certificate Services (ADCS) can allow low-privileged users to request certificates with elevated permissions, potentially enabling them to impersonate high-privileged accounts, like domain administrators. This often occurs when templates are configured with the "Any Purpose" Extended Key Usage (EKU) or without any EKU at all.
Attackers could exploit this vulnerability in several ways. For instance, if they can specify a Subject Alternative Name (SAN), they may perform attacks similar to ESC1, where they generate certificates impersonating other accounts. This also allows them to request certificates on behalf of other users, as seen in ESC3. In rarer cases, the "Any Purpose" value has been leveraged to target applications like SAML and ADFS, enabling misuse in code signing and server authentication scenarios.
Recommendation
Remove Any Purpose or SubCA EKUs from vulnerable templates, restrict enrollment, and validate templates cannot issue broadly usable certificates.
Prerequisites
- Locate all services and clients consuming certificates issued from affected template.
- Coordinate with application and service owners before modifying the template.
- Back up the certificate template configuration before changes.
- Obtain change control approval.
Remediation Objective
- Remove the Any Purpose EKU or SubCA EKU from the affected certificate template.
- Restrict the template to specific, required EKUs that reflect its intended use.
- Prevent the template from being used to issue certificates that can be used for any purpose, including code signing and smart card logon.
- Eliminate the ESC2 attack vector where any authenticated user can request an unrestricted certificate.
Remediation Path 1: Command-Line
Not applicable. A command-line remediation is not the preferred remediation method for this finding because certificate template EKU and issuance changes should be made through the Certificate Templates Console or a documented PKI change process to reduce certificate issuance and compatibility risk.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Certificate Templates ConsoleRun
certtmpl.msc. - Duplicate the template (if built-in)Right-click the affected template and select Duplicate Template.
- Open template propertiesRight-click the duplicated template and select Properties.
- Update EKU settingsClick the Extensions tab, select Application Policies, and click Edit. Remove the Any Purpose entry and add only the specific EKU(s) required for the template's intended use.
- Restrict enrollment permissionsOn the Security tab, confirm that enrollment rights are limited to the required principals.
- Publish the updated templateIn
certsrv.msc, add the new template to the CA and remove the old unrestricted template. - Trigger re-enrollmentConfigure autoenrollment via Group Policy to re-enroll consuming services.
Validation
- Confirm the updated template no longer includes Any Purpose EKU: certutil -template <TemplateName>
- Verify newly issued certificates have only the specific required EKUs.
- Confirm consuming services have re-enrolled successfully.
- Run a follow-up scan to confirm the ESC2 finding is resolved.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- Template configuration export before changes.
- Change ticket and approval record.
- certutil output confirming updated EKU settings.
- Re-enrollment confirmation from consuming services.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Configure certificate templates to limit permissions and specify purpose-specific EKUs. Regular audits of template permissions and close monitoring of certificate requests are essential for maintaining secure certificate issuance. As multiple conditions must align for this vulnerability to be exploited, disrupting any one of these conditions effectively prevents this escalation attack. • Low-Privileged Enrollment Rights: The Certificate Authority (CA) permits enrollment requests from low-privileged groups, such as "Authenticated Users" or "Domain Users," which broadens the potential for misuse. • Lack of Approval Mechanisms: When certificates are issued without requiring manager approval or authorized signatures, the process lacks oversight, allowing unauthorized users to request high-privilege certificates without detection. • Unrestricted EKU Settings: If a certificate template is configured with "Any Purpose" as the Extended Key Usage (EKU) or lacks an EKU designation, it allows users to request certificates without restriction, which can be exploited to gain escalated access.
| Object | Type |
|---|---|
| Fight Milk Any Purpose | Certificate template |
Domain UsersEnroll | Account |
NT AUTHORITY\Authenticated UsersWrite owner | Account |
Vulnerable PKI Object Access Control in ADCS (ESC5)
Vulnerable PKI Object Access Control in ADCS (ESC5)
Vulnerable PKI Object Access Control in ADCS (ESC5)
One or more PKI objects grant a non-default principal dangerous control (full control, write, write-permissions, or take-ownership). The affected objects include certificate authority objects and the Public Key Services containers, including NTAuthCertificates and the Certification Authorities store. Control over these objects lets an attacker alter the PKI itself, for example by publishing a rogue CA certificate into NTAuthCertificates so that certificates it issues are trusted for domain authentication.
An attacker who can write the NTAuthCertificates object adds an attacker-controlled CA certificate, after which any certificate that CA issues authenticates as any user. Control over the CA object, the Enrollment Services container, or the OID container similarly lets the attacker publish templates, link policies, or change CA settings.
Recommendation
Restrict write and control permissions on PKI objects to default privileged principals only.
Prerequisites
- Enterprise Admin rights (PKI objects live in the configuration partition).
- Identify the dangerous access control entries from the report.
- Obtain change control approval.
Remediation Objective
- Remove non-default full-control, write, write-DACL, and write-owner entries from the flagged PKI objects.
- Leave only SYSTEM, Administrators, Domain Admins, and Enterprise Admins.
- Pay special attention to NTAuthCertificates, whose contents are trusted for domain authentication forest-wide.
Remediation Path 1: Command-Line
Use this path to review and correct the ACL on each flagged PKI object.
# Review the ACL on a PKI object (configuration partition).
dsacls "<PkiObjectDN>"
# Remove a non-default principal's access.
dsacls "<PkiObjectDN>" /R "<DOMAIN\Principal>"# Remediate approved PKI objects (columns: PkiObjectDN, Principal).
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
foreach ($Item in $Items) {
<Approved-Remediation-Command> $Item.PkiObjectDN /R $Item.Principal
}Remediation Path 2: GUI
Use this path to review the PKI object ACLs visually.
- Open ADSI EditRun adsiedit.msc and connect to the Configuration naming context.
- Locate Public Key ServicesBrowse to CN=Public Key Services, CN=Services.
- Open the object's SecurityRight-click the flagged object (for example NTAuthCertificates or a CA object), select Properties, and open the Security tab.
- Remove non-default entriesRemove any principal other than SYSTEM, Administrators, Domain Admins, and Enterprise Admins that holds full control, write, write-DACL, or write-owner.
- Save and repeatClick OK and repeat for each flagged PKI object.
Validation
- Re-review each object's ACL and confirm only default principals remain.
- Confirm enrollment and PKI operations still function.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If a principal legitimately administers PKI, scope its rights to the minimum required and document it.
- Record owner and target date for any temporary delay.
- Track formal risk acceptance.
Evidence
- ACL export for each PKI object before and after remediation.
- Confirmation that PKI enrollment still functions.
- Follow-up scan results confirming resolution.
Additional Guidance
Treat the entire Public Key Services branch of the configuration partition as Tier 0. Monitor changes to NTAuthCertificates and the CA objects, and review delegations granted to PKI operators over time.
| Object | Type |
|---|---|
| paddyspub-RODC-CA | Certificate authority |
Weak Certificate Encryption or Signing
Weak Certificate Encryption or Signing
Weak Certificate Encryption or Signing
Certificates should not use outdated or insufficiently strong encryption algorithms, such as RSA keys under 2048 bits. Certificates with weak encryption can be exploited by attackers, compromising the security of the systems that rely on them. RSA keys below 1024 bits are especially vulnerable.
Attackers exploit this by breaking weaker cryptographic protections to impersonate trusted services or decrypt sensitive data. Using tools like RsaCtfTool or John the Ripper, they can factorize short RSA keys, allowing them to forge signatures or eavesdrop on encrypted communications. This enables them to compromise secure channels, intercept confidential information, and gain unauthorized access to critical systems.
Recommendation
Update certificate templates to require strong algorithms and key sizes, then reissue certificates where weak cryptography remains in use.
Prerequisites
- Inventory all services, devices, and users consuming certificates issued from affected templates.
- Coordinate with application and service owners before modifying templates.
- Back up certificate template configurations before making changes.
- Obtain change control approval.
Remediation Objective
- Update ADCS certificate templates to require strong cryptographic algorithms (SHA-256 or higher, RSA 2048-bit minimum or equivalent).
- Revoke or phase out certificates issued under weak cryptographic settings.
- Ensure all new certificate issuances use templates configured with current algorithm standards.
- Reduce exposure to certificate forgery and signature weakness attacks.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Run from an elevated command prompt on the issuing Certification Authority.
# Configure the CA to use SHA256 for certificate signing where supported.
certutil -setreg CA\CSP\CNGHashAlgorithm SHA256
# Restart Certificate Services to apply the change.
net stop certsvc
net start certsvcRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Certificate Templates ConsoleRun
certtmpl.mscfrom an administrative workstation. - Locate the affected templateFind the template identified in the report.
- Duplicate if neededIf the template is a built-in template, right-click and select Duplicate Template before making changes.
- Open template propertiesRight-click the template (or its duplicate) and select Properties.
- Update cryptographic settingsClick the Cryptography tab. Set the Minimum key size to 2048 or higher. Set the Request hash to SHA256 or stronger. Select an appropriate CSP or Key Storage Provider that supports strong algorithms.
- Publish the updated templateIn the Certification Authority console (
certsrv.msc), right-click Certificate Templates, select New > Certificate Template to Issue, and publish the updated template. - Trigger re-enrollmentConfigure autoenrollment via Group Policy or manually re-enroll consuming services.
Validation
- Confirm updated template settings using certutil -template <TemplateName>.
- Verify newly issued certificates use SHA-256 and meet minimum key size requirements.
- Confirm consuming services have re-enrolled and are using updated certificates.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- Certificate template configuration export before changes.
- Change ticket and approval record.
- certutil output confirming updated template cryptographic settings.
- Sample certificate inspection confirming new issuances use strong algorithms.
- Re-enrollment confirmation from consuming services.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Weak certificate encryption increases the risk of certificate forgery or interception, which can undermine authentication and data integrity. Regularly audit certificates for strong encryption standards and replace any with weak algorithms, particularly in critical systems. Update certificates to use modern cryptographic standards, such as 2048-bit RSA or higher. Administrators should monitor upcoming security guidelines for future-proofing encryption practices.
Weak Certificate Mapping Write Access in ADCS (ESC14)
Weak Certificate Mapping Write Access in ADCS (ESC14)
Weak Certificate Mapping Write Access in ADCS (ESC14)
One or more privileged objects allow non-standard principals to modify the altSecurityIdentities attribute. This attribute can define explicit certificate mappings for account authentication. Unauthorized write access may allow an attacker to map a certificate they control to a privileged account and authenticate as that account.
altSecurityIdentities maps a certificate to an account for authentication. Write access to it on a privileged object is a direct impersonation path: the attacker adds a mapping to a certificate they hold and logs in as the privileged user, with no password and no group change. It is a quiet escalation that ACL reviews focused on group membership routinely miss.
Recommendation
Remove non-default write access to altSecurityIdentities on privileged objects and audit for rogue mappings.
Prerequisites
- Domain Admin rights to modify the ACLs of the affected objects.
- Knowledge of any legitimate process that manages certificate mappings.
- Obtain change control approval.
Remediation Objective
- Remove write access to altSecurityIdentities from non-default principals on each privileged object.
- Audit altSecurityIdentities for unexpected mappings that may already have been added.
- Move toward strong (SID-based) certificate mapping.
Remediation Path 1: Command-Line
Use this path to review existing mappings and remove the dangerous write access.
REM Review the existing certificate mappings on the object.
dsacls "CN=<Object>,CN=Users,DC=contoso,DC=com"
REM Remove a non-default principal's ACEs (including write to altSecurityIdentities) from the object.
dsacls "CN=<Object>,CN=Users,DC=contoso,DC=com" /R "CONTOSO\suspectAccount"# Inspect altSecurityIdentities on a privileged object for unexpected certificate mappings.
Import-Module ActiveDirectory
Get-ADUser -Identity "<SamAccountName>" -Properties altSecurityIdentities |
Select-Object -ExpandProperty altSecurityIdentitiesRemediation Path 2: GUI
Use this path to remove the write access through the console.
- Open Active Directory Users and ComputersLaunch ADUC and enable Advanced Features from the View menu.
- Locate the privileged objectNavigate to the object identified in the report.
- Open Security > AdvancedRight-click the object, select Properties, open the Security tab, then Advanced.
- Remove the write permissionRemove the non-default principal, or remove its Write permission on the altSecurityIdentities attribute.
- Audit existing mappingsCheck the object's altSecurityIdentities value (Attribute Editor) for any mapping you did not create.
Validation
- Confirm the non-default principal can no longer write altSecurityIdentities.
- Confirm no unexpected certificate mappings remain on the object.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If a legitimate process manages certificate mappings, scope its rights to only the intended objects and document it.
- Investigate any unexpected mapping as a potential compromise.
- Track formal risk acceptance.
Evidence
- Security-descriptor export of each object before and after.
- The altSecurityIdentities value reviewed for rogue mappings.
- Follow-up scan results confirming resolution.
Additional Guidance
Enable strong certificate mapping (the SID security extension and the StrongCertificateBindingEnforcement registry setting on domain controllers) so that even an added explicit mapping cannot be used for weak-binding impersonation. Audit altSecurityIdentities changes on privileged objects as an early warning.
| Domain Controller | Operating System | Last Logon | Password Set |
|---|---|---|---|
| PADDY-DC01.paddyspub.local | Windows Server 2019 Datacenter | Jul 13, 2026 | Jul 5, 2026 |
| DENNIS-LT01.paddyspub.local | Windows Server 2008 R2 Standard | Never | Jul 17, 2025 |
Weak Hashing Algorithm In Use
Weak Hashing Algorithm In Use
Weak Hashing Algorithm In Use
The use of weak hashing algorithms, such as MD2, MD4, or MD5, exposes systems to security risks, as these outdated algorithms have vulnerabilities that allow attackers to generate hash collisions more easily than with brute-force methods. This compromises the integrity of the system, making it easier for attackers to impersonate or tamper with data.
Attackers exploit weak hashing algorithms like MD2 and MD5 on intermediate and root certificates by creating forged certificates that appear valid, enabling man-in-the-middle (MitM) attacks and unauthorized data decryption. Using tools like Hashcat, they can crack these weak hashes to impersonate trusted entities, intercept sensitive communications, or issue fraudulent certificates. This compromise allows attackers to infiltrate secure channels and compromise the integrity of encrypted data across the organization.
Recommendation
Disable weak hashing or Kerberos encryption algorithms, rotate affected credentials where required, and validate supported authentication paths.
Prerequisites
- Inventory accounts, services, and legacy systems that may depend on MD5, RC4, or legacy Kerberos settings.
- Coordinate with application and service owners before enforcing stronger encryption.
- Confirm AES support for affected services in a pilot OU or non-production scope.
- Back up relevant GPOs and obtain change approval before production deployment.
Remediation Objective
- Disable or deprecate weak hashing algorithms (MD5, RC4-HMAC) used in Kerberos or NTLM authentication.
- Enforce stronger hashing algorithms such as AES-128 and AES-256 across the domain.
- Ensure Kerberos encryption types are explicitly configured to exclude weak algorithms.
- Reduce exposure to offline hash cracking and pass-the-hash attack techniques.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Set supported Kerberos encryption types for a single account, removing weak algorithms.
# Replace <SamAccountName> with the target account name.
Set-ADUser -Identity "<SamAccountName>" `
-KerberosEncryptionType AES128,AES256# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of accounts to remediate.
# Required CSV columns: SamAccountName
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
# Update supported Kerberos encryption types to AES only for each account.
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName `
-KerberosEncryptionType AES128,AES256 -WhatIf
}
# Remove -WhatIf after reviewing the output and confirming no service impact.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Edit or create the relevant GPORight-click the GPO linked to domain controllers or the target OU and select Edit.
- Navigate to Kerberos encryption settingsGo to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
- Configure the encryption type policyLocate 'Network security: Configure encryption types allowed for Kerberos' and enable only AES128_HMAC_SHA1 and AES256_HMAC_SHA1. Uncheck DES and RC4 options.
- Apply and save the GPOClose the editor and Use the organization-approved policy refresh process on targeted systems after testing.
- VerifyConfirm that affected accounts have KerberosEncryptionType set to AES values.
Validation
- Run a follow-up assessment scan to confirm the finding no longer appears.
- Verify targeted accounts have KerberosEncryptionType updated: Get-ADUser -Identity <SamAccountName> -Properties KerberosEncryptionType
- Confirm Kerberos tickets are being issued with AES encryption using klist.exe on a test workstation.
- Monitor authentication event logs on domain controllers (Event ID 4769) for any failures following the change.
- Validate that dependent services are authenticating successfully after enforcement.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before/after export of affected account KerberosEncryptionType values.
- GPO backup prior to any policy modification.
- Change ticket and approval record.
- PowerShell transcript of remediation commands.
- Results of klist verification and Event ID 4769 review.
- Validation output confirming AES encryption type enforcement.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Weak hashing algorithms such as MD5 and RC4 expose authentication traffic to offline cracking and downgrade attacks. Organizations should enforce AES-128 and AES-256 as the only permitted Kerberos encryption types through Group Policy and validate that all accounts, services, and applications support these algorithms before enforcement. Legacy systems that cannot support AES should be prioritized for upgrade or decommission.
To prevent recurrence, include Kerberos encryption type requirements in account provisioning standards and service onboarding checklists. Review encryption type settings during periodic reviews and ensure new service accounts are never configured with RC4 or DES support.
Weak PowerShell Logging
Weak PowerShell Logging
Weak PowerShell Logging
Enabling PowerShell logging offers comprehensive insights into executed commands, the parameters used, and their execution context. This level of detail is critical for detecting malicious actions like security control bypasses, privilege escalations, and data exfiltration. Additionally, PowerShell logs are often essential for post-incident analysis, aiding in understanding the scope of a compromise and guiding appropriate remediation efforts.
PowerShell has become highly popular among hackers due to its extensive functionality, leading to the creation of numerous tools that leverage it. It is commonly used by malicious attackers as part of their toolkit.
Recommendation
Enable PowerShell Script Block Logging and related audit settings, forward events to monitoring, and validate command execution visibility.
Prerequisites
- Domain Admin or Group Policy rights to create and modify GPOs.
- SIEM or log collection capacity assessed to accommodate increased log volume.
- Change control approval obtained.
Remediation Objective
- Enable PowerShell Script Block Logging to capture the content of all executed scripts and commands.
- Enable PowerShell Module Logging to record pipeline execution details.
- Enable Protected Event Logging to protect script block log content from tampering.
- Forward PowerShell event logs to a SIEM and configure alerting for suspicious patterns.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Enable PowerShell logging via registry on a single system.
# The GPO method is preferred for domain-wide enforcement.
$PSLoggingPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell"
# Enable Script Block Logging.
$SBLPath = "$PSLoggingPath\ScriptBlockLogging"
New-Item -Path $SBLPath -Force | Out-Null
Set-ItemProperty -Path $SBLPath -Name "EnableScriptBlockLogging" -Value 1 -Type DWord
# Enable Module Logging.
$MLPath = "$PSLoggingPath\ModuleLogging"
New-Item -Path $MLPath -Force | Out-Null
Set-ItemProperty -Path $MLPath -Name "EnableModuleLogging" -Value 1 -Type DWord
Write-Output "PowerShell logging enabled on $env:COMPUTERNAME"Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Create or edit a GPORight-click the domain or target OU and create or edit a security baseline GPO.
- Navigate to PowerShell logging settingsGo to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell.
- Enable Script Block LoggingDouble-click Turn on PowerShell Script Block Logging and set it to Enabled.
- Enable Module LoggingDouble-click Turn on Module Logging, set it to Enabled, and specify the approved module logging scope.
- Link and validate the GPOLink the GPO to the approved scope and confirm the settings appear in Group Policy Results.
Validation
- Confirm PowerShell Script Block Logging is enabled: check HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging.
- Verify Event ID 4104 events are being generated in the Microsoft-Windows-PowerShell/Operational log.
- Confirm events are being forwarded to the SIEM.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- GPO backup showing PowerShell logging settings.
- Sample Event ID 4104 output confirming script block logging is active.
- SIEM ingestion confirmation.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
PowerShell logging is a foundational detective control for identifying malicious activity, as PowerShell is one of the most commonly used tools in post-exploitation attack chains. Script Block Logging captures the decoded content of all executed PowerShell commands, making it far more useful than basic command history and enabling detection of obfuscated or encoded scripts. Organizations should ensure PowerShell event logs are forwarded to a centralized SIEM with alerting configured for known malicious patterns, such as encoded command execution, AMSI bypass attempts, and offensive tooling signatures.
| Object | Type |
|---|---|
| Default Domain Policy | Group policy |
| Disable LLMNR | Group policy |
| KA | Group policy |
| KA-Computers | Group policy |
WSUS Certificate Pinning Disabled
WSUS Certificate Pinning Disabled
WSUS Certificate Pinning Disabled
When WSUS certificate pinning is disabled, the integrity of WSUS updates can be compromised, even if HTTPS is used. Attackers or proxies could intercept WSUS traffic, sign responses with their own certificates, and potentially inject malicious updates. Certificate pinning ensures that only trusted certificates from the WSUS server are accepted, preventing such attacks.
Attackers who can poison updates can rapidly move laterally within the domain and establish a strong persistence foothold.
Recommendation
Enable WSUS certificate pinning or equivalent trust validation and confirm clients reject untrusted update endpoints.
Prerequisites
- Server Administrator credentials on the WSUS server required.
- WSUS must already be configured to use HTTPS before certificate pinning can be meaningful.
- Confirm the WSUS SSL certificate is valid, trusted, and not expiring imminently.
- Obtain change control approval.
- No backup is strictly required, but document the current registry state before modification.
Remediation Objective
- Enable certificate pinning for WSUS update delivery to prevent man-in-the-middle attacks against the update channel.
- Ensure WSUS clients validate the server certificate before accepting updates.
- Reduce the risk of rogue update servers or tampered update packages being accepted by clients.
- Align WSUS configuration with Microsoft-recommended hardening guidance.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Run on the WSUS server or deploy via GPO to client systems.
# Enable certificate pinning for Windows Update by setting the required registry value.
# This enforces certificate validation for Windows Update communications.
Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate" `
-Name "PinPolicyCertificateSubjectName" -Value "<CertificateSubjectName>" -Type String# Import the required module for the remediation.
Import-Module ActiveDirectory
# Import a reviewed and approved list of affected objects to remediate.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
# Update only the objects included in the approved input file.
foreach ($Item in $Items) {
# Replace the placeholder command with the approved single-object remediation command for WSUS Certificate Pinning Disabled.
# Use -WhatIf when supported before applying the change.
<Approved-Remediation-Command> -Identity $Item.DistinguishedName -WhatIf
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Edit the relevant client GPORight-click the GPO linked to the OU containing WSUS clients and select Edit.
- Navigate to Windows Update policy settingsGo to Computer Configuration > Administrative Templates > Windows Components > Windows Update.
- Configure certificate pinningLocate the setting 'Allow signed updates from an intranet Microsoft update service location' and enable it. Additionally, configure the 'Specify the certificates to use for Windows Update' setting if available in your environment.
- Apply and testUse the organization-approved policy refresh process on a test client and confirm WSUS connectivity is maintained.
- Verify registry value on test clientConfirm the pinning registry key is present under HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate.
Validation
- Confirm the registry value for certificate pinning is present on test clients after GPO application.
- Verify WSUS client connectivity is unaffected: check Windows Update event logs for successful synchronization.
- Run gpresult /r on a test client to confirm the relevant GPO is applied.
- Run a follow-up scan to confirm the finding is resolved.
- Review Windows Update client logs for any certificate validation errors following the change.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- Registry state export before and after change.
- GPO backup after modification.
- Change ticket and approval record.
- gpresult output confirming GPO application on test clients.
Additional Guidance
Certificate pinning for WSUS ensures that clients validate the WSUS server certificate before accepting any update package, preventing attackers from redirecting update traffic to a rogue server. This control is most effective when combined with HTTPS enforcement and is a recommended component of the Microsoft WSUS hardening guidance.
To prevent recurrence, include WSUS certificate pinning validation in the patch management configuration baseline and review certificate expiry proactively. Automate certificate renewal through the internal CA and update the pinning configuration as part of the renewal process to prevent authentication failures.
| Object | Type |
|---|---|
| Default Domain Policy | Group policy |
Microsoft - Manage additional Windows Update settings (intranet update service, signed updates)
Microsoft - Windows Server Update Services (WSUS) overview
The Hacker Recipes - WSUS spoofing via unencrypted HTTP updates
Microsoft - Scan changes and certificates add security for Windows devices using WSUS for updates
WSUS Configured With User Proxy
WSUS Configured With User Proxy
WSUS Configured With User Proxy
When WSUS (Windows Server Update Services) is configured to allow user proxies, unprivileged users may route update traffic through their own proxy settings, potentially exposing update requests to interception or manipulation. While modern updates restrict this behavior by default, certain Group Policy settings, such as SetProxyBehaviorForUpdateDetection, can re-enable user proxy usage. This misconfiguration could allow attackers to redirect or tamper with update traffic, leading to security bypasses or the injection of malicious updates.
Attackers exploit this configuration by intercepting or manipulating Windows Update traffic to deliver malicious updates or execute man-in-the-middle (MitM) attacks. Using tools like ntlmrelayx from Impacket, they can relay authentication requests and gain unauthorized access to systems by hijacking update communications. This misconfiguration allows attackers to inject malicious payloads into legitimate update processes, potentially leading to remote code execution, privilege escalation, and persistent access within the organization's network.
Recommendation
Reconfigure WSUS proxy settings to avoid user-context credentials and validate update synchronization succeeds with the approved configuration.
Prerequisites
- WSUS Administrator credentials required.
- Locate the current proxy configuration in the WSUS console.
- Determine the correct system-level proxy settings for the WSUS server's network environment.
- Coordinate with the network team to confirm the correct proxy address and port.
- Obtain change control approval.
Remediation Objective
- Reconfigure WSUS to use system-level or anonymous proxy settings instead of user-context credentials.
- Prevent WSUS from storing or using user account credentials for proxy authentication.
- Reduce the risk of proxy credential exposure through the WSUS configuration.
- Ensure WSUS proxy configuration follows the principle of least privilege.
Remediation Path 1: Command-Line
Not applicable. A command-line remediation is not the preferred remediation method for this finding because WSUS proxy remediation is environment-specific and should be performed through the WSUS console or approved server configuration management process to avoid disrupting synchronization.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the WSUS administrative consoleLaunch the WSUS console from Server Manager or Start Menu.
- Navigate to OptionsIn the left pane, click Options.
- Open Update Source and Proxy ServerClick 'Update Source and Proxy Server' and select the Proxy Server tab.
- Review and update proxy settingsIf user credentials are configured, remove them. If the proxy supports anonymous or system-level authentication, clear the username and password fields.
- Test synchronizationClick OK and trigger a manual synchronization to confirm WSUS can still reach the upstream update server.
Validation
- Confirm proxy credentials are no longer stored in WSUS configuration.
- Verify WSUS upstream synchronization succeeds after the change.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the WSUS dependency and business justification.
- Assign a WSUS owner and target remediation date.
- Restrict access and monitor activity until remediation is complete.
Evidence
- WSUS proxy configuration export before changes.
- Change ticket and approval record.
- WSUS synchronization test confirming upstream connectivity.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Threat actors can exploit misconfigured WSUS proxies to manipulate update distribution, potentially injecting malicious payloads into trusted update channels. This attack vector is particularly dangerous in environments where HTTP-based WSUS servers are used, as it increases the risk of man-in-the-middle (MitM) attacks. Organizations should restrict WSUS clients to system-level proxies and disable user-defined proxy settings to maintain the integrity of software updates. Continuous monitoring of WSUS configurations and update traffic can help detect anomalies before they become security threats.
| Object | Type |
|---|---|
| Default Domain Policy | Group policy |
WSUS Using HTTP
WSUS Using HTTP
WSUS Using HTTP
When WSUS is configured to use HTTP instead of HTTPS, update communications are vulnerable to interception and manipulation by attackers. Specialized toolsets exist that can exploit HTTP traffic to inject malicious updates, allowing attackers to compromise multiple systems across the network.
Attackers who can poison updates can rapidly move laterally within the domain and establish a strong persistence foothold.
Recommendation
Reconfigure WSUS to use HTTPS, deploy a trusted certificate, and validate clients receive updates over the secured channel.
Prerequisites
- Confirm the WSUS server FQDN, IIS site, ports, and current client GPO configuration.
- Provision a trusted SSL certificate for the WSUS IIS binding.
- Back up IIS configuration and WSUS-related GPO settings before changes.
- Coordinate with endpoint and patch management owners and use a maintenance window.
Remediation Objective
- Reconfigure the WSUS server to serve updates exclusively over HTTPS.
- Update all client Group Policy settings to reference the WSUS server using its HTTPS URL.
- Ensure the SSL certificate is trusted by all domain-joined clients.
- Eliminate the risk of WSUS traffic interception and update tampering via HTTP.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Run from an elevated command prompt on the WSUS server after the IIS SSL certificate binding is configured.
# Replace <WsusServerFqdn> with the approved WSUS server FQDN.
wsusutil.exe configuressl <WsusServerFqdn>
# Restart IIS after WSUS SSL configuration.
iisreset
# Optional: reset WSUS content metadata after configuration if required by the change plan.
wsusutil.exe resetRemediation Path 2: GUI
Not applicable. A GUI-only remediation path is not the preferred method for this finding because fully enabling HTTPS for WSUS commonly requires WSUS server configuration commands in addition to IIS, WSUS, and Group Policy console changes. Because the remediation is not complete through GUI tools alone, the command-line path should be used with change control.
Validation
- Confirm the WSUS IIS site is responding on port 8531 with a valid certificate: Test-NetConnection -ComputerName <WSUSServer> -Port 8531
- Verify the SSL certificate is trusted and not expired.
- Run gpupdate /force on a test client and confirm Windows Update agent contacts WSUS via HTTPS.
- Review WSUS server synchronization logs for errors after SSL enablement.
- Run a follow-up scan to confirm the finding is resolved.
- Monitor Windows Update client event logs (Event ID 16016) for connection errors.
Exceptions
- Document the WSUS dependency and business justification.
- Assign a WSUS owner and target remediation date.
- Restrict access and monitor activity until remediation is complete.
Evidence
- IIS configuration backup prior to changes.
- Screenshot or export of original WSUS HTTP URL in GPO settings.
- SSL certificate details (thumbprint, expiry, issuing CA).
- GPO backup after updating WSUS URL.
- Change ticket and approval record.
- Validation output confirming HTTPS connectivity.
- Test client Windows Update log confirming successful HTTPS communication.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Enforcing HTTPS ensures update integrity and confidentiality in transit. Organizations should provision a certificate from an internal CA trusted by all domain clients and bind it to the WSUS IIS site before enabling SSL. To prevent recurrence, include WSUS TLS configuration in the server hardening baseline and validate HTTPS enforcement during periodic patch management audits. When deploying new WSUS infrastructure, require HTTPS as part of the build checklist and automate certificate renewal through the internal CA to avoid expiry-related outages.
| Object | Type |
|---|---|
| Default Domain Policy | Group policy |
Privileged Access Management
20 findings
Administrator Accounts May Not Practice Least Privilege
Administrator Accounts May Not Practice Least Privilege
Administrator Accounts May Not Practice Least Privilege
Administrator accounts that don’t adhere to the principle of least privilege (has an email address assigned) may be at risk of performing both routine and administrative tasks under the same account, increasing exposure to attacks. Without proper separation of privileges, a compromised admin account could lead to unauthorized access, lateral movement, or privilege escalation within the domain.
Attackers target privileged users to intercept credentials during routine tasks, such as browsing or email, using methods like phishing or pass-the-hash attacks. Compromising these users bypasses the need for further privilege escalation, as they already possess elevated access. Attackers specifically seek these users in configurations vulnerable to delegation attacks, which leave credentials at higher risk.
Recommendation
Reduce administrator account privileges to role-required access, remove unnecessary group memberships, and enforce recurring access reviews.
Prerequisites
- Determine the actual administrative role and minimum required access for each account.
- Coordinate with team leads and managers before modifying access.
- Assess whether role-based tiered administration or PAM tooling is feasible.
- Obtain change control approval for any access changes.
Remediation Objective
- Reduce privileged group membership for administrator accounts to the minimum required for their defined role.
- Separate day-to-day user accounts from privileged administrative accounts.
- Implement tiered administration where possible to limit the scope of any single account compromise.
- Ensure administrator accounts are used only for administrative tasks, not for browsing or email.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Review current members of Domain Admins.
Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object Name, SamAccountName, ObjectClass
# Remove an account from Domain Admins where a less privileged alternative is available.
# Replace <SamAccountName> with the account to remove.
Remove-ADGroupMember -Identity "Domain Admins" -Members "<SamAccountName>" -Confirm:$false -WhatIf
# Remove -WhatIf after confirming with the account owner and implementing alternatives.# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of accounts to remove from privileged groups.
# Required CSV columns: SamAccountName, GroupName
$Removals = Import-Csv -Path ".\ApprovedRemovals.csv"
foreach ($Removal in $Removals) {
Remove-ADGroupMember -Identity $Removal.GroupName `
-Members $Removal.SamAccountName -Confirm:$false -WhatIf
}
# Remove -WhatIf after reviewing output and confirming alternatives are in place.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.msc. - Review privileged group membershipNavigate to the relevant privileged groups (Domain Admins, Enterprise Admins, etc.) and review the Members tab.
- Locate over-privileged accountsFor each member, confirm their role and whether Domain Admin-level access is genuinely required.
- Remove unnecessary membershipFor accounts that do not require full Domain Admin access, click Remove on the Members tab after confirming appropriate alternatives are in place.
- Create role-specific alternatives if neededDelegate appropriate OU-level or role-specific permissions to replace Domain Admin where possible.
Validation
- Confirm updated group membership: Get-ADGroupMember -Identity 'Domain Admins'
- Verify that removed accounts can still perform their required administrative tasks via delegated access.
- Monitor for any service or task failures following the change.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Privileged group membership export before changes.
- Role justification documentation for each account reviewed.
- Change ticket and approval record.
- PowerShell output confirming updated group membership.
- Confirmation from administrators that required tasks are still functional.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Administrative users should separate day-to-day activity from privileged operations. Review accounts with email or routine-use indicators, enforce dedicated admin accounts, and monitor privileged account usage for interactive or non-administrative behavior.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Dee.Reynolds | Dee.Reynolds | Yes | May 19, 2025 | Never | May 19, 2025 |
Microsoft - Review and reduce accounts in highly privileged administrative groups
Microsoft - Too many admins in your domain: expose the problems and find a solution with PowerShell
Microsoft - Implementing least-privilege administrative models
Microsoft - Privileged access security rapid modernization plan (RAMP)
Microsoft - Enterprise access model for securing privileged access
Computer Account Detected in Privileged Group
Computer Account Detected in Privileged Group
Computer Account Detected in Privileged Group
Computer Account Detected in Privileged Group indicates that a computer account has been granted membership in a domain privileged group, such as Domain Admins. This poses a significant security risk, as compromising the computer account could allow an attacker to gain elevated privileges and control over critical domain resources. Normally, computer accounts should not have such elevated access.
Attackers often target computer accounts because they are typically less secure than user accounts, making them easier to compromise and maintain long-term persistence. Organizations frequently overlook securing these accounts, increasing the chances of a successful attack.
Recommendation
Remove computer accounts from privileged groups unless explicitly required, validate delegated access, and document any approved exception.
Prerequisites
- Domain Administrator or equivalent credentials required.
- Locate the computer account and the privileged group it is a member of.
- Determine whether the membership serves a legitimate operational purpose (e.g., backup software running as a service that requires domain-level access).
- Coordinate with the system owner or application team before removing membership.
- Obtain change control approval.
Remediation Objective
- Remove computer accounts from privileged AD groups where the membership is not operationally justified.
- Eliminate implicit elevated access for all services running on the affected computer.
- Reduce the risk of privilege escalation in the event the computer is compromised.
- Ensure privileged group membership is restricted to named user accounts with documented justification.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove a computer account from a privileged group.
# Replace <ComputerName> with the computer account name (without $).
# Replace <GroupName> with the privileged group name.
Remove-ADGroupMember -Identity "<GroupName>" -Members "<ComputerName>$" -Confirm:$false -WhatIf
# Remove -WhatIf after reviewing the output and confirming no service dependency.# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of computer accounts to remove from privileged groups.
# Required CSV columns: ComputerName, GroupName
$Removals = Import-Csv -Path ".\ApprovedRemovals.csv"
# Remove each computer account from its respective privileged group.
foreach ($Removal in $Removals) {
Remove-ADGroupMember -Identity $Removal.GroupName `
-Members ($Removal.ComputerName + "$") -Confirm:$false -WhatIf
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the privileged groupNavigate to the container holding the privileged group identified in the report and open its Properties.
- Review the Members tabClick the Members tab and locate the computer account.
- Remove the computer accountSelect the computer account and click Remove.
- Save and validateClick OK. Confirm with the system owner that services on the affected computer are functioning normally.
Validation
- Confirm the computer account has been removed from the privileged group: Get-ADGroupMember -Identity '<GroupName>'
- Monitor services on the affected computer for any failures following the removal.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Export of privileged group membership before changes.
- Change ticket and approval record.
- PowerShell output confirming computer account removal.
- Service monitoring confirming no failures on affected computer.
Additional Guidance
Computer accounts in privileged groups should be reviewed carefully because they can expand machine-level access in unexpected ways. Confirm the business purpose, remove unnecessary membership, and monitor privileged groups for non-user principals.
| Computer | Operating System | Created | Last Logon | Password Set |
|---|---|---|---|---|
| DEE-PC01$ | Windows Server 2019 Datacenter | Jun 30, 2021 | Jul 13, 2026 | Jul 6, 2026 |
Custom "Pre-Windows 2000 Compatible Access" Group Membership
Custom "Pre-Windows 2000 Compatible Access" Group Membership
Custom "Pre-Windows 2000 Compatible Access" Group Membership
The "Pre-Windows 2000 Compatible Access" group grants access to certain legacy calls, which can expose vulnerabilities if improperly configured. Custom membership in this group, particularly the addition of accounts beyond the default settings, can increase the risk of unauthorized access to sensitive domain resources by exploiting legacy protocols.
Attackers leverage the "Pre-Windows 2000 Compatible Access" group to gain broad read access to directory information, including user and group details. They use this access to gather intelligence on the organization’s structure and potentially escalate privileges or craft targeted attacks.
Recently tools have been released focusing on exploiting Pre-Windows 2000 computer accounts, making it a common technique for gaining an initial foothold in a network. These accounts can sometimes obtain an authenticated domain account, as their default password is defaulted to the hostname in all lowercase letters. If these accounts were created but never used, they are likely still configured with this default setting.
Recommendation
Review custom Pre-Windows 2000 Compatible Access membership, remove unjustified entries, and document any approved legacy dependency.
Prerequisites
- Review the current membership of the Pre-Windows 2000 Compatible Access group to locate non-default or c.
- Consult with application and service owners to determine whether each custom member has a legitimate ope.
- Back up current group membership before making changes.
- Plan a rollback if application authentication failures occur after membership changes.
Remediation Objective
- Remove custom or non-default members from the Pre-Windows 2000 Compatible Access group that do not have a documented business justification.
- Prevent unauthorized or undocumented accounts from retaining broad AD read access via this legacy group.
- Ensure group membership reflects only operationally justified entries with documented approval.
- Reduce the risk of AD enumeration and unauthorized information gathering by limiting this group's effective membership.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove a custom member from the Pre-Windows 2000 Compatible Access group.
# Replace <MemberName> with the account or group to remove.
Remove-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" `
-Members "<MemberName>" -Confirm:$false -WhatIf
# Remove -WhatIf after reviewing output and confirming no application dependency.# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of custom members to remove.
# Required CSV columns: MemberName
$Members = Import-Csv -Path ".\ApprovedRemovals.csv"
# Remove each custom member from the Pre-Windows 2000 Compatible Access group.
foreach ($Member in $Members) {
Remove-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" `
-Members $Member.MemberName -Confirm:$false -WhatIf
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the groupNavigate to Builtin and find the 'Pre-Windows 2000 Compatible Access' group.
- Open group propertiesRight-click the group and select Properties, then click the Members tab.
- Locate custom membersReview the membership list for any non-default or custom accounts or groups that are not operationally justified.
- Remove unjustified custom membersSelect the member and click Remove for each custom entry that lacks documented justification.
- Save and testClick OK. Monitor for application authentication failures following the change.
Validation
- Confirm updated group membership: Get-ADGroupMember -Identity 'Pre-Windows 2000 Compatible Access'
- Monitor application and service logs for authentication failures.
- Verify no new custom members have been added to the group after remediation.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Export of Pre-Windows 2000 Compatible Access group membership before changes.
- Change ticket and approval record.
- PowerShell output confirming updated membership after changes.
- Application and service monitoring confirming no authentication failures.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Custom membership in the Pre-Windows 2000 Compatible Access group is frequently introduced without documented justification and can persist for years after the original need has passed. Each custom member retains the broad AD read access that this group provides, including the ability to enumerate user, computer, and group attributes that would otherwise require authenticated access. Organizations should treat this group as a zero-membership target and require formal justification for any entry.
| Object | Type |
|---|---|
| Pre-Windows 2000 Compatible Access | Group |
Dangerous Control Over Privileged Objects
Dangerous Control Over Privileged Objects
Dangerous Control Over Privileged Objects
One or more non-standard principals have dangerous control over privileged Active Directory objects. Permissions such as full control, ownership, password reset, or permission modification can provide administrative influence without visible privileged group membership. These hidden control paths, often referred to as "shadow admins" should be treated as privileged access and removed unless explicitly required.
Shadow admins are a favorite attacker foothold. A help-desk account with WriteDacl on Domain Admins, or the right to reset a Domain Admin's password, is functionally a Domain Admin yet appears in no privileged group listing. One ACL edit and they own the domain.
Recommendation
Remove admin-equivalent ACL access held by non-default principals over Tier 0 objects.
Prerequisites
- Domain Admin rights to modify the ACLs of Tier 0 objects.
- Knowledge of any legitimate delegation so it is not removed by mistake.
- Obtain change control approval.
Remediation Objective
- Remove the dangerous ACE for each non-default principal from the affected Tier 0 object.
- Restore the object to its default, AdminSDHolder-protected permissions.
- Investigate how the access was granted and whether it was abused.
Remediation Path 1: Command-Line
Use this path to review and remove the dangerous access.
REM Review who holds rights on a privileged object (example: Domain Admins).
dsacls "CN=Domain Admins,CN=Users,DC=contoso,DC=com"
REM Remove all ACEs for the non-default principal from that object.
dsacls "CN=Domain Admins,CN=Users,DC=contoso,DC=com" /R "CONTOSO\suspectAccount"# Inspect the security descriptor of a privileged object before editing it.
Import-Module ActiveDirectory
(Get-Acl "AD:CN=Domain Admins,CN=Users,DC=contoso,DC=com").Access |
Where-Object { $_.AccessControlType -eq 'Allow' } |
Select-Object IdentityReference, ActiveDirectoryRights, ObjectTypeRemediation Path 2: GUI
Use this path to remove the access through the console.
- Open Active Directory Users and ComputersLaunch ADUC and enable Advanced Features from the View menu.
- Locate the privileged objectNavigate to the Tier 0 object identified in the report.
- Open the Security tabRight-click the object, select Properties, and open the Security tab.
- Remove the non-default principalSelect the flagged principal and remove it, or remove only the dangerous permissions it holds.
- Confirm protectionVerify the object's permissions match the AdminSDHolder template and save.
Validation
- Confirm the non-default principal no longer holds control over the object.
- Verify legitimate administration still functions.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If the access is legitimate delegation, document the business reason and scope it as tightly as possible.
- Investigate any unexplained access as a potential compromise.
- Track formal risk acceptance.
Evidence
- Security-descriptor export of each object before and after.
- Investigation notes on how the access was granted.
- Follow-up scan results confirming resolution.
Additional Guidance
AdminSDHolder and the SDProp process re-stamp the ACLs of protected objects roughly every hour. After cleaning up an object, confirm it is covered by AdminSDHolder, and audit the AdminSDHolder object itself, since access granted there propagates to every privileged object.
| Object | Type |
|---|---|
| Exchange Windows Permissions | Group |
| Terminal Server License Servers | Group |
| Cert Publishers | Group |
DCShadow Activity
DCShadow Activity
DCShadow Activity
DCShadow attacks allow adversaries with privileged domain access to register rogue domain controllers and push unauthorized changes into Active Directory. By doing so, attackers can inject malicious modifications while bypassing traditional logging and security monitoring. This technique enables them to create persistent backdoors, manipulate security settings, and stealthily escalate privileges without triggering standard detection mechanisms.
DCShadow is used to stealthily inject malicious changes into Active Directory by impersonating a domain controller. Attackers use tools like Mimikatz to register a rogue DC and push unauthorized modifications, such as adding privileged accounts or altering group memberships, without generating standard event logs. This technique allows attackers to maintain persistence, escalate privileges, and manipulate directory objects while bypassing traditional security monitoring.
Recommendation
Investigate suspected DCShadow activity, identify modified objects, remove rogue replication artifacts, and validate domain controller metadata integrity.
Prerequisites
- Treat the finding as a potential domain compromise and activate the incident response process.
- Ensure Domain Administrator or Enterprise Administrator access is available for containment actions.
- Preserve event logs, replication logs, SIEM data, and directory evidence before cleanup.
- Coordinate containment, credential rotation, and recovery steps with security operations and directory services.
Remediation Objective
- Detect and confirm DCShadow activity and locate all objects potentially modified by the rogue domain controller.
- Reset krbtgt and all privileged account passwords to invalidate any Kerberos tickets issued or manipulated during the attack window.
- Remove unauthorized replication ACEs from the AD schema and domain objects.
- Harden the environment to prevent future DCShadow attacks by restricting who can register a domain controller in Active Directory.
Remediation Path 1: Command-Line
Not applicable. Command-line remediation is not the preferred remediation method for this finding because DCShadow activity indicates potential compromise or unauthorized directory replication behavior. Remediation should follow the incident response process, including containment, credential rotation, forensic review, and controlled cleanup rather than a generic command-line change.
Remediation Path 2: GUI
Not applicable. A GUI-only remediation path is not the preferred method for this finding because DCShadow activity indicates potential Active Directory compromise and requires incident response, forensic review, password rotation, replication analysis, and controlled directory recovery. ADSI Edit may be used for a specific cleanup action, but it is not a complete GUI-only remediation path.
Validation
- Confirm no unauthorized nTDSDSA objects remain in the Configuration naming context.
- Verify krbtgt password has been reset twice and Kerberos tickets are re-issued correctly.
- Confirm all privileged account passwords have been reset.
- Review AD replication event logs for any ongoing unauthorized replication activity.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Do not approve operational exceptions for DCShadow indicators.
- Document any response delay with owner and target containment date.
- Track emergency risk acceptance until containment is complete.
Evidence
- Preserved forensic evidence (event logs, replication logs, SIEM exports) before remediation.
- nTDSDSA object review before and after cleanup.
- krbtgt password reset records (both resets).
- Privileged account password reset records.
- ACL review confirming no unauthorized DCSync or replication rights remain.
- Incident response report documenting the scope and timeline of the attack.
- Follow-up scan results confirming finding resolution.
Additional Guidance
DCShadow activity should be handled as an Active Directory compromise indicator rather than a routine configuration issue. Response should prioritize containment, evidence preservation, privileged credential rotation, replication review, and controlled cleanup of unauthorized directory changes.
To reduce recurrence, restrict who can create domain controller-related objects, monitor for new nTDSDSA objects, and alert on unexpected replication configuration changes. Any future domain controller deployment should follow a documented change process with directory services approval.
Disabled Privileged Accounts
Disabled Privileged Accounts
Disabled Privileged Accounts
Disabled privileged accounts present a security risk when they retain group memberships that grant elevated access. Attackers who gain control of such accounts can re-enable them and immediately inherit their previous privileges, bypassing normal escalation processes. Since disabled accounts are often overlooked in security monitoring, they are prime targets for exploitation, allowing adversaries to operate with high-level access while evading detection.
Attackers can exploit disabled privileged accounts by reactivating them or extracting their credentials for unauthorized access. Using tools like Mimikatz or BloodHound, they identify disabled accounts with historical administrative privileges and attempt to reset their passwords, modify account attributes, or leverage cached credentials for authentication. If security monitoring overlooks disabled accounts, attackers can use them for stealthy privilege escalation, lateral movement, and persistent access within the organization.
Recommendation
Remove privileged group memberships from disabled accounts and validate disabled objects no longer retain standing administrative access.
Prerequisites
- Domain Administrator credentials required.
- Confirm each disabled account is genuinely inactive and not held for retention or compliance purposes.
- Verify that no services, scheduled tasks, or applications reference the disabled accounts.
- Coordinate with HR or the account owner if the account was associated with a departed employee.
- Obtain change control approval before deleting accounts (less required for group membership removal only).
Remediation Objective
- Remove privileged group memberships from disabled accounts.
- Delete disabled privileged accounts that are confirmed as no longer required.
- Eliminate the risk of disabled privileged accounts being re-enabled and used for unauthorized access.
- Ensure the privileged group membership inventory reflects only active, operationally justified accounts.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove all privileged group memberships from a disabled account.
# Replace <SamAccountName> with the disabled account name.
$Account = Get-ADUser -Identity "<SamAccountName>" -Properties MemberOf
foreach ($Group in $Account.MemberOf) {
Remove-ADGroupMember -Identity $Group -Members "<SamAccountName>" -Confirm:$false -WhatIf
}
# Optionally delete the account after removing memberships:
# Remove-ADUser -Identity "<SamAccountName>" -Confirm:$false -WhatIf
# Remove -WhatIf after reviewing output and confirming with relevant stakeholders.# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of disabled privileged accounts.
# Required CSV columns: SamAccountName
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
$ADAccount = Get-ADUser -Identity $Account.SamAccountName -Properties MemberOf
foreach ($Group in $ADAccount.MemberOf) {
Remove-ADGroupMember -Identity $Group `
-Members $Account.SamAccountName -Confirm:$false -WhatIf
}
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.msc. - Locate the disabled privileged accountNavigate to the OU containing the account.
- Review group membershipRight-click the account, select Properties, and click the Member Of tab. Remove all privileged group memberships.
- Delete the account if appropriateAfter removing memberships, right-click the account and select Delete if it is confirmed as no longer needed.
- Repeat for approved affected accountsComplete the same GUI process for each account listed in the approved remediation plan.
Validation
- Confirm privileged group memberships have been removed: Get-ADUser -Identity <SamAccountName> -Properties MemberOf
- Confirm accounts are deleted or remain disabled with no group memberships.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Export of disabled privileged account group memberships before changes.
- Change ticket and approval record.
- PowerShell output confirming group memberships removed.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Threat actors actively seek out disabled privileged accounts as a means of gaining privileged access within Active Directory. Once re-enabled, these accounts provide an immediate pathway to critical systems, often without triggering the same level of scrutiny as active privileged users. Organizations should maintain visibility over disabled accounts, especially those with administrative access, as they can become a silent entry point for attackers. Identify suspicious activity before it leads to a full domain compromise by performing regular audits and setting up automated alerts for privilege changes.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Bill.Ponderosa | Bill.Ponderosa | No | Apr 4, 2025 | Never | Apr 4, 2025 |
gMSA Not In Use
gMSA Not In Use
gMSA Not In Use
No group managed service accounts were identified in the domain. This may indicate that services continue to rely on traditional service accounts with static passwords, which are often difficult to rotate and protect. Group managed service accounts rotate their own passwords automatically and cannot be used for interactive logon. gMSAs should be considered for eligible services to reduce password management and credential theft risk.
Static service-account passwords are a perennial weak point: they are often weak, shared, embedded in scripts, and never rotated, which makes them ideal Kerberoasting targets and lateral-movement credentials.
Recommendation
Adopt group managed service accounts for service accounts so passwords rotate automatically.
Prerequisites
- Domain Admin (or delegated) rights to create the KDS root key and service accounts.
- An inventory of services running under static-password accounts.
- Obtain change control approval.
Remediation Objective
- Create the KDS root key for the forest (one-time).
- Create gMSAs and authorize only the hosts that run each service.
- Migrate services from static-password accounts to gMSAs.
Remediation Path 1: Command-Line
Use this path to enable gMSAs and create the first service accounts.
Import-Module ActiveDirectory
# One-time per forest. In production the key needs ~10 hours to replicate before use.
Add-KdsRootKey -EffectiveImmediately
# Create a gMSA and authorize the hosts that may retrieve its password (computer accounts end with $).
New-ADServiceAccount -Name "svc-example" -DNSHostName "svc-example.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "Host1$","Host2$"# Create gMSAs from an approved list (columns: Name, DnsHostName, AllowedHosts as semicolon-separated $ accounts).
Import-Module ActiveDirectory
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
foreach ($Item in $Items) {
$hosts = $Item.AllowedHosts -split ';'
New-ADServiceAccount -Name $Item.Name -DNSHostName $Item.DnsHostName -PrincipalsAllowedToRetrieveManagedPassword $hosts -WhatIf
}Remediation Path 2: GUI
Use this path to create gMSAs through the management console.
- Create the KDS root keyOn a domain controller, run Add-KdsRootKey once for the forest (PowerShell; there is no console step for this).
- Open Active Directory Administrative CenterLaunch dsac.exe and browse to the Managed Service Accounts container.
- Create a new gMSACreate a group managed service account and set the hosts allowed to retrieve its password.
- Install on the service hostsOn each host, run Install-ADServiceAccount for the new gMSA.
- Migrate the serviceReconfigure the service to run as the gMSA (DOMAIN\svc-example$ with no password).
Validation
- Confirm gMSAs exist and services run under them.
- Confirm the static-password accounts they replaced are disabled or removed.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If a service cannot use a gMSA (no AES, non-Windows host), document it and use a long random password with periodic rotation.
- Record owner and target date for the migration.
- Track formal risk acceptance.
Evidence
- Inventory of gMSAs created and services migrated.
- Confirmation that static-password accounts were retired.
- Follow-up scan results confirming resolution.
Additional Guidance
Group managed service accounts are the standard remediation for static service-account passwords. Prioritize migrating privileged or internet-reachable service accounts first, and authorize each gMSA to only the specific hosts that run the service.
High Number of Privileged Users
High Number of Privileged Users
High Number of Privileged Users
Each privileged user account increases the attack surface. Organizations are urged to follow best practices such as least privilege, particularly involving administrative accounts.
Organizations that have fewer administrative accounts are more resistant to privilege escalation attacks such as token impersonation and pass-the-hash. When there are a multitude of privileged accounts, it’s easier to blend in with normal day-to-day operations, which allows for stealthier attacks and persistence.
Recommendation
Recertify privileged group membership, remove unnecessary administrative access, and establish recurring privileged access reviews.
Prerequisites
- Domain Admin rights to modify group memberships.
- Access recertification process initiated with business and IT stakeholders.
- Inventory of privileged group memberships and business justifications prepared.
- Change control approval obtained for each removal action.
- Rollback plan documented for any access removals that cause operational issues.
Remediation Objective
- Conduct a formal access recertification to locate accounts with unnecessary privileged group memberships.
- Remove accounts from privileged groups where membership is not justified by current role requirements.
- Implement a tiered administration model to isolate privileged access from daily user activity.
- Enforce just-in-time (JIT) access or PAM-managed shared accounts where possible.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove a user from a privileged group.
# Replace <SamAccountName> with the target account.
# Replace <GroupName> with the privileged group name (e.g., Domain Admins).
Remove-ADGroupMember -Identity "<GroupName>" -Members "<SamAccountName>" -Confirm:$false# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remove from privileged groups.
# CSV must contain columns: SamAccountName, GroupName
$Members = Import-Csv -Path ".\ApprovedRemovals.csv"
foreach ($Member in $Members) {
Remove-ADGroupMember -Identity $Member.GroupName -Members $Member.SamAccountName -Confirm:$false -WhatIf
Write-Output "Processed removal: $($Member.SamAccountName) from $($Member.GroupName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the privileged groupNavigate to the appropriate container (typically CN=Users or a dedicated admin OU) and open the privileged group's properties.
- Review the Members tabLocate accounts whose membership is not justified by a current business or operational requirement.
- Remove unjustified membersSelect the accounts to remove and click Remove.
- Document each removalRecord each removal in the change management system with the approving manager's acknowledgment.
Validation
- Confirm group membership has been updated: Get-ADGroupMember -Identity <GroupName>.
- Verify removed users retain the access necessary for their role through appropriate non-privileged accounts.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after privileged group membership export.
- Access recertification sign-off records.
- Change ticket and approval record for each removal.
- Follow-up scan results showing finding resolved.
Additional Guidance
Restrict the number of privileged users, granting only essential personnel elevated rights. Implementing a tiered administration model can further protect these accounts by isolating their use and reducing the impact of compromise. Perform regular audits to review privileged accounts and ensure their necessity in the environment. Many organizations choose to practice Just-In-Time (JIT) provisioning or leverage PAM (Privileged Access Management) toolsets to manage shared or limited administrative accounts.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Liam.McPoyle | Liam.McPoyle | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Administrator | Yes | Jun 30, 2021 | May 23, 2025 | Apr 14, 2025 | |
| Rickety.Cricket | Rickety.Cricket | Yes | Jul 2, 2025 | Never | Jul 2, 2025 |
| Frank.Reynolds | Frank.Reynolds | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 |
| Ronald.McDonald | Ronald.McDonald | Yes | Jun 10, 2025 | Jun 10, 2025 | Jun 10, 2025 |
| Artemis.Dubois | Artemis.Dubois | Yes | May 23, 2025 | May 23, 2025 | May 23, 2025 |
| Charlie.Kelly | Charlie.Kelly | Yes | May 19, 2025 | Never | May 19, 2025 |
| Dee.Reynolds | Dee.Reynolds | Yes | May 19, 2025 | Never | May 19, 2025 |
| Waitress | The Waitress | Yes | May 8, 2025 | Never | May 8, 2025 |
| Dennis.Reynolds | Dennis.Reynolds | Yes | Apr 11, 2025 | Never | Apr 11, 2025 |
| Bill.Ponderosa | Bill.Ponderosa | No | Apr 4, 2025 | Never | Apr 4, 2025 |
Non-administrative users can add computer accounts
Non-administrative users can add computer accounts
Non-administrative users can add computer accounts
By default, non-administrative users can add up to 10 computer accounts to the domain. This capability allows basic users to introduce uncontrolled machines into the domain, which can be exploited by attackers to gain unauthorized access or launch additional attacks.
Organizations are often over reliant on EDR (endpoint detection and response) tools which attackers can bypass by adding a malicious computer to the domain. These attacks often are conducted by adding a virtual machine to the environment and performing Kerberos-based attacks. These attacks become even more effective if they can poison network traffic and direct it to the malicious device.
Recommendation
Set MachineAccountQuota to zero, move computer joins into an approved process, and validate that non-administrators can no longer create computer accounts.
Prerequisites
- Domain Admin rights to modify the ms-DS-MachineAccountQuota attribute and Group Policy.
- Confirm that existing computer joining processes use administrative accounts and will not be impacted.
- Change control approval obtained.
Remediation Objective
- Set the ms-DS-MachineAccountQuota attribute on the domain root to 0 to prevent non-administrative users from adding computers.
- Configure Group Policy to restrict the Add workstations to domain privilege (SeMachineAccountPrivilege) to authorized administrators only.
- Confirm the change does not impact legitimate computer provisioning processes.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Set the ms-DS-MachineAccountQuota attribute to 0 on the domain root.
# Replace <DomainDN> with your domain distinguished name (e.g., DC=contoso,DC=com).
Set-ADDomain -Identity "<DomainDN>" -Replace @{"ms-DS-MachineAccountQuota" = "0"}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open ADSI EditLaunch
adsiedit.mscfrom an administrative workstation. - Connect to the domain naming contextRight-click ADSI Edit, select Connect to, and choose Default naming context.
- Locate the domain root objectExpand the domain naming context and right-click the domain root object (e.g., DC=contoso,DC=com). Select Properties.
- Modify the ms-DS-MachineAccountQuota attributeScroll to ms-DS-MachineAccountQuota in the attribute list. Double-click to edit and set the value to 0. Click OK.
- Configure GPO to restrict SeMachineAccountPrivilegeOpen
gpmc.msc, create or edit a GPO linked to the domain. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. Locate Add workstations to domain and configure it to include only Domain Admins or the appropriate administrative group.
Validation
- Confirm the ms-DS-MachineAccountQuota value is 0 using Get-ADDomain | Select AllowedDNSSuffixes or Get-ADObject.
- Attempt to join a computer to the domain with a non-administrative account to confirm the change is effective (access should be denied).
- Verify legitimate computer provisioning processes still function correctly.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after export of ms-DS-MachineAccountQuota attribute value.
- GPO backup and settings report for SeMachineAccountPrivilege.
- Change ticket and approval record.
- Validation test output confirming non-admin join is blocked.
Additional Guidance
Allowing non-administrative users to add computer accounts to the domain enables low-effort attack techniques that can bypass endpoint protections and be used as a foothold for further compromise. This capability should be restricted to dedicated administrative accounts as a baseline hardening measure.
Organizations should also monitor for anomalous computer account creation events (Event ID 4741) to detect any attempts to exploit this capability before it is fully restricted. Computer provisioning workflows should be reviewed to ensure they use dedicated administrative accounts with appropriately scoped permissions rather than broad domain admin rights.
Operator Groups In Use
Operator Groups In Use
Operator Groups In Use
Default Microsoft operator groups, such as "Account Operators" and "Server Operators," have elevated permissions that provide access to critical domain resources. Misuse of these groups can introduce privilege escalation pathways, allowing attackers to make unauthorized changes that compromise the security and stability of the domain.
Insider threats or malicious attackers who compromise accounts within operator groups often find it easy to escalate privileges that result in a full domain takeover.
Recommendation
Remove unnecessary accounts from built-in operator groups and replace standing membership with role-based or temporary administrative access.
Prerequisites
- Locate current members of built-in operator groups (Account Operators, Backup Operators, Print Operators.
- Coordinate with team leads and service owners to determine whether each member has a legitimate operatio.
- Back up current group membership before making changes.
- Obtain change control approval.
Remediation Objective
- Remove unnecessary accounts from built-in AD operator groups (Account Operators, Backup Operators, Print Operators, Server Operators).
- Eliminate implicit privileged access to domain controllers and AD objects granted by operator group membership.
- Replace operator group assignments with purpose-specific delegated permissions or role-based access where possible.
- Reduce the attack surface for privilege escalation through compromised operator group members.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove a specific member from an operator group.
# Replace <GroupName> with the operator group (e.g., "Account Operators", "Backup Operators").
# Replace <MemberName> with the account to remove.
Remove-ADGroupMember -Identity "<GroupName>" -Members "<MemberName>" -Confirm:$false -WhatIf
# Remove -WhatIf after reviewing output and confirming no operational dependency.# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of group membership removals.
# Required CSV columns: GroupName, MemberName
$Removals = Import-Csv -Path ".\ApprovedRemovals.csv"
# Remove each member from the specified operator group.
foreach ($Removal in $Removals) {
Remove-ADGroupMember -Identity $Removal.GroupName `
-Members $Removal.MemberName -Confirm:$false -WhatIf
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Navigate to the Builtin containerExpand the domain and select the Builtin OU.
- Open the operator groupRight-click the relevant operator group (e.g., Account Operators) and select Properties.
- Review Members tabClick Members and review current membership for accounts that do not require this level of access.
- Remove unnecessary membersSelect the account and click Remove for each member that lacks a documented operational justification.
- Repeat for each operator groupProcess all operator groups identified in the report.
- Save and validateClick OK and confirm with team leads that operational tasks are unaffected.
Validation
- Confirm updated membership for each operator group: Get-ADGroupMember -Identity '<GroupName>'
- Verify that removed accounts retain only the access required for their operational role.
- Monitor event logs for any access failures or complaints following the change.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Export of operator group membership before changes.
- Change ticket and approval record.
- PowerShell output confirming updated membership after changes.
- Confirmation from team leads that operational tasks are unaffected.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Built-in AD operator groups such as Account Operators, Backup Operators, Print Operators, and Server Operators carry implicit permissions that are often broader than expected, including the ability to manage accounts, perform privileged operations on domain controllers, and in some cases elevate to Domain Admin through indirect paths. These groups are frequently populated with accounts that no longer require this level of access or that were added without a formal review. Consider setting appropriate permissions over OUs or specific areas versus leveraging default Operator groups.
| Object | Type |
|---|---|
| Account Operators | Group |
| Print Operators | Group |
Privileged Users Allowed to Be Delegated
Privileged Users Allowed to Be Delegated
Privileged Users Allowed to Be Delegated
One or more privileged accounts are not protected from Kerberos delegation as they lack the "Account is sensitive and cannot be delegated" flag or not members of the Protected Users group. When these accounts authenticate to a service trusted for delegation, that service may be able to obtain and reuse their Kerberos tickets. For highly privileged accounts such as Domain Admins, compromise of a delegated service can lead to full domain compromise.
An attacker who controls, or can configure delegation on, a service that a privileged account authenticates to captures that account's forwarded ticket and replays it as the privileged user. Unconstrained delegation makes this trivial; resource-based and constrained delegation make it targeted.
Recommendation
Mark all privileged accounts as sensitive and cannot be delegated, or add them to Protected Users.
Prerequisites
- Rights to modify the privileged accounts.
- Confirm no privileged account legitimately requires delegation.
- Obtain change control approval.
Remediation Objective
- Set "Account is sensitive and cannot be delegated" on every privileged account.
- Where supported, add privileged accounts to the Protected Users group, which also blocks delegation.
- Verify the accounts are excluded from delegation.
Remediation Path 1: Command-Line
Use this path to mark accounts as sensitive across the privileged population.
Import-Module ActiveDirectory
Set-ADUser -Identity "<SamAccountName>" -AccountNotDelegated $true# Mark all members of a privileged group as sensitive (review membership first).
Import-Module ActiveDirectory
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
Where-Object { $_.objectClass -eq 'user' } |
ForEach-Object { Set-ADUser -Identity $_.SID -AccountNotDelegated $true -WhatIf }Remediation Path 2: GUI
Use this path when changing a small number of accounts.
- Open Active Directory Users and ComputersLaunch ADUC from an administrative workstation.
- Locate the privileged accountNavigate to the account identified in the report.
- Open the Account tabRight-click the account, select Properties, and open the Account tab.
- Set the sensitive flagUnder Account options, check "Account is sensitive and cannot be delegated".
- Save the changeClick OK and repeat for each privileged account.
Validation
- Confirm AccountNotDelegated is true (or the account is in Protected Users).
- Verify the account still authenticates to required services.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If an account genuinely requires delegation, scope the delegation tightly and document the dependency.
- Record owner and target date for any temporary delay.
- Track formal risk acceptance.
Evidence
- Export of AccountNotDelegated / Protected Users membership before and after.
- Confirmation that authentication still works.
- Follow-up scan results confirming resolution.
Additional Guidance
Add privileged accounts to the Protected Users group where compatible (it blocks delegation, NTLM, and weak Kerberos ciphers), and keep the sensitive flag set on every Tier 0 account as a baseline.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Administrator | Yes | Jun 30, 2021 | May 23, 2025 | Apr 14, 2025 | |
| Frank.Reynolds | Frank.Reynolds | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 |
| Liam.McPoyle | Liam.McPoyle | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Dennis.Reynolds | Dennis.Reynolds | Yes | Apr 11, 2025 | Never | Apr 11, 2025 |
| Waitress | The Waitress | Yes | May 8, 2025 | Never | May 8, 2025 |
| Dee.Reynolds | Dee.Reynolds | Yes | May 19, 2025 | Never | May 19, 2025 |
| Charlie.Kelly | Charlie.Kelly | Yes | May 19, 2025 | Never | May 19, 2025 |
| Artemis.Dubois | Artemis.Dubois | Yes | May 23, 2025 | May 23, 2025 | May 23, 2025 |
| Ronald.McDonald | Ronald.McDonald | Yes | Jun 10, 2025 | Jun 10, 2025 | Jun 10, 2025 |
| Rickety.Cricket | Rickety.Cricket | Yes | Jul 2, 2025 | Never | Jul 2, 2025 |
Protected Users Group Not Utilized
Protected Users Group Not Utilized
Protected Users Group Not Utilized
The Protected Users group is designed to provide enhanced security for privileged accounts by limiting the use of vulnerable authentication methods like NTLM and reducing exposure to credential theft attacks. If privileged accounts are not members of this group, they remain susceptible to common attacks such as credential caching, Kerberos delegation, and weaker encryption algorithms.
Organizations that properly tier their environments and enforce best practices, like using the Protected Users group, are generally more difficult and time-consuming to compromise. This forces attackers to rely on alternative methods, such as social engineering.
Recommendation
Enroll appropriate privileged accounts in the Protected Users group, validate authentication compatibility, and document accounts that require exception.
Prerequisites
- Domain Admin rights to modify group membership.
- Review of all candidate accounts to confirm they are human user accounts and not service accounts.
- Testing environment available to validate no service disruptions.
- Notification to affected privileged users.
- Change control approval obtained.
Remediation Objective
- Locate privileged user accounts that should be enrolled in the Protected Users group.
- Exclude service accounts, accounts running services, and any account used for non-interactive authentication.
- Add the reviewed and approved accounts to the Protected Users group.
- Monitor for authentication issues after enrollment and document any service impacts.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Add a privileged user account to the Protected Users group.
# Replace <SamAccountName> with the target account.
Add-ADGroupMember -Identity "Protected Users" -Members "<SamAccountName>"# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of privileged accounts to add to Protected Users.
# CSV must contain a column named SamAccountName.
# IMPORTANT: Only include human user accounts. Exclude service accounts.
$Accounts = Import-Csv -Path ".\ApprovedProtectedUsers.csv"
foreach ($Account in $Accounts) {
Add-ADGroupMember -Identity "Protected Users" -Members $Account.SamAccountName -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the Protected Users groupNavigate to CN=Users in the domain and open the Protected Users group.
- Add membersClick the Members tab and click Add. Enter the names of the privileged accounts to enroll.
- Save and monitorClick OK. Monitor the affected accounts for authentication issues in the days following enrollment.
Validation
- Confirm Protected Users group membership: Get-ADGroupMember -Identity 'Protected Users'.
- Verify affected accounts can authenticate via Kerberos and that no service disruptions occurred.
- Confirm NTLM authentication is blocked for Protected Users members by testing with an NTLM-only authentication attempt.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after Protected Users group membership export.
- Authentication test results confirming no service disruptions.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
The Protected Users group is one of the most effective credential protection controls available in Active Directory, automatically blocking NTLM authentication, Kerberos delegation, DES and RC4 encryption. These protections significantly raise the cost of credential theft for the covered accounts. Do not add service accounts without testing, as Protected Users restrictions will likely disrupt service authentication. Prioritize human or user-related accounts when implementing this group as the impact should be lessened.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Liam.McPoyle | Liam.McPoyle | Yes | Apr 4, 2025 | Never | Apr 4, 2025 |
| Administrator | Yes | Jun 30, 2021 | May 23, 2025 | Apr 14, 2025 | |
| Rickety.Cricket | Rickety.Cricket | Yes | Jul 2, 2025 | Never | Jul 2, 2025 |
| Frank.Reynolds | Frank.Reynolds | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 |
| Ronald.McDonald | Ronald.McDonald | Yes | Jun 10, 2025 | Jun 10, 2025 | Jun 10, 2025 |
| Artemis.Dubois | Artemis.Dubois | Yes | May 23, 2025 | May 23, 2025 | May 23, 2025 |
| Charlie.Kelly | Charlie.Kelly | Yes | May 19, 2025 | Never | May 19, 2025 |
| Dee.Reynolds | Dee.Reynolds | Yes | May 19, 2025 | Never | May 19, 2025 |
| Waitress | The Waitress | Yes | May 8, 2025 | Never | May 8, 2025 |
| Dennis.Reynolds | Dennis.Reynolds | Yes | Apr 11, 2025 | Never | Apr 11, 2025 |
| Bill.Ponderosa | Bill.Ponderosa | No | Apr 4, 2025 | Never | Apr 4, 2025 |
Risky AdminSDHolder Permissions
Risky AdminSDHolder Permissions
Risky AdminSDHolder Permissions
The AdminSDHolder object has non-standard permissions that grant dangerous control to one or more principals. Because AdminSDHolder permissions are periodically applied to protected administrative accounts and groups, improper access can propagate across privileged objects. This condition can create both privilege escalation and persistence risk within the domain.
AdminSDHolder is a classic persistence mechanism. An attacker with write access adds an access control entry granting themselves full control; within about an hour SDProp copies that entry onto Domain Admins, Administrators, and every other protected object. Even after defenders remove the access from those groups, SDProp re-adds it on the next cycle, so the backdoor survives cleanup until the AdminSDHolder ACL itself is fixed.
Recommendation
Restrict the AdminSDHolder ACL to default privileged principals only.
Prerequisites
- Domain Admin rights.
- Identify the non-default access control entries from the report.
- Obtain change control approval.
Remediation Objective
- Remove non-default full-control, write, write-DACL, and write-owner entries from the AdminSDHolder object.
- Leave only SYSTEM, Administrators, Domain Admins, and Enterprise Admins.
- Inspect current privileged accounts and groups for the same entry that SDProp may already have propagated.
Remediation Path 1: Command-Line
Use this path when remediating multiple entries or when changes need to be executed, exported, and tracked.
# Review the AdminSDHolder ACL.
dsacls "CN=AdminSDHolder,CN=System,<DomainDN>"
# Remove a non-default principal's permissions.
dsacls "CN=AdminSDHolder,CN=System,<DomainDN>" /R "<DOMAIN\Principal>"# Remove approved principals (column: Principal) from AdminSDHolder.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
foreach ($Item in $Items) {
<Approved-Remediation-Command> "CN=AdminSDHolder,CN=System,<DomainDN>" /R $Item.Principal
}Remediation Path 2: GUI
Use this path to review and correct the AdminSDHolder ACL visually.
- Open ADSI EditRun adsiedit.msc and connect to the Default naming context.
- Locate AdminSDHolderBrowse to CN=System, then CN=AdminSDHolder.
- Open SecurityRight-click AdminSDHolder, select Properties, and open the Security tab.
- Remove non-default entriesRemove any principal other than SYSTEM, Administrators, Domain Admins, and Enterprise Admins that holds full control, write, write-DACL, or write-owner.
- Save the changeClick OK; SDProp will propagate the corrected descriptor on its next cycle.
Validation
- Re-review the AdminSDHolder ACL and confirm only default principals remain.
- Inspect protected accounts and groups for the unwanted entry and remove it where propagated.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Do not approve permanent exceptions for write access by non-default principals.
- Document any temporary delay with owner and target date.
- Track formal risk acceptance until remediation is complete.
Evidence
- AdminSDHolder ACL export before and after remediation.
- List of protected objects checked for propagated entries.
- Follow-up scan results confirming resolution.
Additional Guidance
Because SDProp propagation makes AdminSDHolder a single point of control for all privileged objects, treat its ACL as Tier 0 and monitor it for change. Auditing directory service changes on the AdminSDHolder object detects both the initial tampering and ongoing persistence attempts.
| Object | Type |
|---|---|
| Terminal Server License Servers | Group |
| Cert Publishers | Group |
Risky DCSync Permissions
Risky DCSync Permissions
Risky DCSync Permissions
Non-standard users with DCSync permissions pose a significant security risk, as they can replicate credentials for any account within the domain, including domain administrators. Attackers who obtain these privileges can execute a DCSync attack, extracting NTLM password hashes and Kerberos keys without triggering typical authentication-based alerts. This access enables adversaries to conduct credential theft attacks such as Golden Ticket and Silver Ticket attacks, granting long-term control over Active Directory.
Accounts with DCSync permissions are highly sought after by attackers as they have the ability to impersonate a domain controller. Attackers use tools like Mimikatz or Impacket to perform a DCSync attack, tricking the domain controller into replicating password hashes. With these hashes, they can escalate privileges, create Golden Tickets, and maintain persistent control over the entire Active Directory environment. Once access is obtained, domain controller hashes can be remotely dumped, rendering many EDR defenses ineffective.
Recommendation
Remove unauthorized DCSync rights from the domain root and validate only approved replication principals can request directory replication data.
Prerequisites
- Domain Administrator or Enterprise Administrator credentials required.
- Locate all accounts or groups with Replicating Directory Changes and Replicating Directory Changes All rights on the domain object.
- Confirm which accounts legitimately require these rights (e.g., Azure AD Connect sync account, specific replication tools).
- Coordinate with the directory services team before removing any ACEs.
- Back up the domain object ACL before making any changes.
- Obtain change control approval.
Remediation Objective
- Remove unauthorized accounts or groups from the DCSync permission set (Replicating Directory Changes and Replicating Directory Changes All) on the Active Directory domain object.
- Ensure these rights are held only by domain controllers, the Azure AD Connect sync account (if applicable), and other explicitly authorized replication accounts.
- Eliminate the risk of credential harvesting via DCSync attacks by accounts that should not hold replication rights.
- Reduce the domain's exposure to full credential database extraction.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove approved unauthorized DCSync extended rights from the domain root object.
# Replace <DOMAIN\AccountOrGroup> with the account or group approved for removal.
$DomainDN = (Get-ADDomain).DistinguishedName
$Principal = "<DOMAIN\AccountOrGroup>"
$DCSyncRightGuids = @(
[Guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
[Guid]"1131f6ab-9c07-11d1-f79f-00c04fc2dcd2",
[Guid]"89e95b76-444d-4c62-991a-0facbeda640c"
)
$Acl = Get-Acl -Path ("AD:\" + $DomainDN)
$RulesToRemove = $Acl.Access | Where-Object {
$_.IdentityReference -eq $Principal -and $DCSyncRightGuids -contains $_.ObjectType
}
foreach ($Rule in $RulesToRemove) {
[void]$Acl.RemoveAccessRuleSpecific($Rule)
}
Set-Acl -Path ("AD:\" + $DomainDN) -AclObject $Acl# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of principals to remove from DCSync rights.
# Required CSV column: Principal
$Principals = Import-Csv -Path ".\ApprovedDCSyncRemovals.csv"
$DomainDN = (Get-ADDomain).DistinguishedName
$DCSyncRightGuids = @(
[Guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
[Guid]"1131f6ab-9c07-11d1-f79f-00c04fc2dcd2",
[Guid]"89e95b76-444d-4c62-991a-0facbeda640c"
)
foreach ($Item in $Principals) {
$Acl = Get-Acl -Path ("AD:\" + $DomainDN)
$RulesToRemove = $Acl.Access | Where-Object {
$_.IdentityReference -eq $Item.Principal -and $DCSyncRightGuids -contains $_.ObjectType
}
foreach ($Rule in $RulesToRemove) {
[void]$Acl.RemoveAccessRuleSpecific($Rule)
}
# Preview the affected principal before applying the ACL update.
Write-Output "Prepared DCSync permission removal for $($Item.Principal)"
# Remove the comment on the next line only after approval.
# Set-Acl -Path ("AD:\" + $DomainDN) -AclObject $Acl
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open ADSI EditLaunch
adsiedit.mscconnected to the Default Naming Context. - Locate the domain objectRight-click the domain root object (DC=<domain>,DC=<tld>) and select Properties.
- Review SecurityClick the Security tab, then Advanced to see all ACEs.
- Locate unauthorized DCSync entriesLook for entries with 'Replicating Directory Changes' or 'Replicating Directory Changes All' extended rights. Confirm each entry against the list of authorized replication accounts.
- Remove unauthorized entriesSelect the unauthorized ACE and click Remove.
- Save and validateClick OK. Monitor replication health after changes.
Validation
- Confirm unauthorized DCSync ACEs have been removed from the domain object ACL.
- Verify AD replication is healthy after changes: repadmin /replsummary
- Confirm Azure AD Connect or other sync tools are still functioning if applicable.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Domain object ACL export before changes.
- Change ticket and approval record.
- Post-change ACL review confirming unauthorized DCSync ACEs are removed.
- repadmin /replsummary output confirming replication health.
- Azure AD Connect sync validation if applicable.
- Follow-up scan results confirming finding resolution.
Additional Guidance
DCSync rights should be restricted to domain controllers and explicitly approved replication or directory synchronization accounts. An account with these rights can request password data from the domain, which can expose krbtgt and privileged account hashes without interactive access to a domain controller.
Review DCSync permissions during privileged access reviews and after any directory synchronization, backup, or monitoring tool deployment. Treat new or unexpected DCSync permissions as a high-priority access governance event that requires owner approval, documented justification, and follow-up validation.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Roxy | Roxy | Yes | Jul 3, 2025 | Never | Never |
| Object | Type |
|---|---|
| Exchange Windows Permissions | Group |
RODC Privileged Group Not Protected
RODC Privileged Group Not Protected
RODC Privileged Group Not Protected
When the RODC Privileged Group is not protected, privileged credentials can be replicated to Read-Only Domain Controllers (RODCs), increasing the risk of credential theft. RODCs are often deployed in less secure environments, making them more vulnerable to attacks. If privileged accounts are allowed in the Password Replication Policy, attackers can steal these credentials and gain elevated access to the domain.
Adversaries often target Read-Only Domain Controllers (RODCs) because they are frequently misconfigured or poorly maintained. A common attack method is to gain access and dump memory to retrieve account information, which can then be used to elevate privileges.
Recommendation
Add privileged groups to the denied RODC password replication policy and validate that privileged credentials cannot be cached.
Prerequisites
- Domain Administrator or equivalent credentials required.
- Locate which privileged groups (e.g., Domain Admins, Enterprise Admins, Schema Admins) are not currently listed in the RODC Denied Password Replication Policy.
- Review any RODC-specific password replication group configurations in use.
- Obtain change control approval.
- No service impact is expected, but validate with the directory services team before modifying RODC password replication settings.
Remediation Objective
- Add all privileged groups and sensitive accounts to the Denied RODC Password Replication Policy.
- Prevent privileged credentials from being cached on Read-Only Domain Controllers.
- Reduce the risk of privileged credential theft from physically compromised or remote RODCs.
- Align RODC password replication policy with the principle of least privilege.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Add a privileged group to the Denied Password Replication Policy on the RODC.
# Replace <RODCName> with the RODC computer account name.
# Replace <GroupName> with the privileged group to deny.
Set-ADAccountControl -Identity "<RODCName>" -DoesNotRequirePreAuth $false
# Use the RODC password replication policy cmdlet.
# Add a group to the Denied list on the RODC.
Add-ADGroupMember -Identity "Denied RODC Password Replication Group" -Members "<GroupName>"# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of groups to add to the Denied RODC Password Replication Policy.
# Required CSV columns: GroupName
$Groups = Import-Csv -Path ".\ApprovedGroups.csv"
# Add each group to the Denied RODC Password Replication Group.
foreach ($Group in $Groups) {
Add-ADGroupMember -Identity "Denied RODC Password Replication Group" `
-Members $Group.GroupName -WhatIf
}
# Remove -WhatIf after reviewing the output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the RODC computer accountNavigate to the Domain Controllers OU and right-click the affected RODC. Select Properties.
- Open the Password Replication Policy tabClick the Password Replication Policy tab.
- Review the Denied listConfirm that all privileged groups (Domain Admins, Enterprise Admins, Schema Admins, Group Policy Creator Owners, and equivalent) are listed in the Denied section.
- Add missing groupsClick Add, select Deny, and add any privileged groups not already listed.
- Save and closeClick OK to apply the changes.
Validation
- Confirm privileged groups appear in the Denied RODC Password Replication Policy via ADUC (Properties > Password Replication Policy on the RODC).
- Verify via PowerShell: Get-ADDomainController -Identity <RODCName> | Select-Object -ExpandProperty DeniedPasswordReplicationPolicy
- Confirm no privileged credentials are cached on the RODC: review the Revealed Passwords tab in ADUC for the RODC.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Export of RODC Password Replication Policy before and after changes.
- Change ticket and approval record.
- PowerShell output confirming denied group membership.
- Revealed Passwords tab review confirming no privileged credentials are cached.
Additional Guidance
RODCs are commonly deployed in locations where physical security cannot be guaranteed, such as branch offices. If privileged credentials are permitted to cache on an RODC, an attacker with physical access to the device can extract those hashes and use them to compromise privileged accounts across the domain. Adding all privileged groups to the Denied RODC Password Replication Policy is a foundational RODC security control.
| Domain Controller | Operating System | Last Logon | Password Set |
|---|---|---|---|
| ROPADDY-DC01.paddyspub.local | Windows Server 2019 Datacenter | Jul 13, 2026 | Jul 5, 2026 |
RODC Privileged Users Exposed
RODC Privileged Users Exposed
RODC Privileged Users Exposed
RODCs (Read-Only Domain Controllers) may expose privileged user credentials by caching them. The attribute msDS-RevealedUsers tracks users whose credentials have been revealed to the RODC. If a privileged user’s credentials are cached, it poses a risk, as RODCs are often deployed in less secure environments.
Attackers commonly use tools like Mimikatz or DCSync to exploit privileged users stored within a RODC and extract their cached credentials.
Recommendation
Remove cached privileged credentials from RODCs, reset exposed account passwords, and validate the password replication policy blocks recurrence.
Prerequisites
- Domain Administrator credentials required.
- Locate which privileged accounts have credentials currently cached on the RODC (Revealed Passwords).
- Confirm which accounts need to be removed from the cache and from the Allowed replication list.
- Consider resetting the passwords of any privileged accounts whose credentials were revealed on the RODC.
- Obtain change control approval.
Remediation Objective
- Remove cached privileged credentials from the RODC password replication cache.
- Move affected privileged accounts from the Allowed to the Denied RODC Password Replication Policy.
- Reset passwords for any privileged accounts whose credentials were exposed on the RODC as a precautionary measure.
- Ensure the RODC no longer caches any privileged account credentials.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Reset the password of a privileged account whose credentials were cached on the RODC.
# Replace <SamAccountName> with the affected account.
$NewPass = Read-Host "Enter new password" -AsSecureString
Set-ADAccountPassword -Identity "<SamAccountName>" -NewPassword $NewPass -Reset
# Move the account to the Denied RODC Password Replication Group.
Add-ADGroupMember -Identity "Denied RODC Password Replication Group" `
-Members "<SamAccountName>"
# To remove a specific account from the RODC cache, use the ADUC GUI
# (Revealed Passwords > Remove account from cache).# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of privileged accounts to remediate.
# Required CSV columns: SamAccountName
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
# Move each account to the Denied RODC Password Replication Group.
Add-ADGroupMember -Identity "Denied RODC Password Replication Group" `
-Members $Account.SamAccountName -WhatIf
}
# Remove -WhatIf after reviewing output.
# Reset passwords separately via the single remediation above for each affected account.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.msc. - Locate the RODC in the Domain Controllers OURight-click the RODC and select Properties.
- Open Password Replication Policy tabClick Password Replication Policy, then click the Advanced button.
- Review Revealed PasswordsSelect 'Accounts whose passwords are stored on this Read-only Domain Controller' to view cached credentials.
- Remove cached credentialsSelect each privileged account and click 'Remove account from cache'.
- Update Denied policyReturn to the Password Replication Policy tab and add each affected account to the Denied list.
- Reset account passwordsReset passwords for any privileged accounts that were revealed on the RODC.
Validation
- Confirm no privileged credentials remain in the Revealed Passwords list on the RODC.
- Verify affected accounts are in the Denied Password Replication Policy.
- Confirm passwords have been reset for accounts whose credentials were exposed.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Do not approve permanent exceptions for this condition.
- Document any temporary delay with owner and target date.
- Track formal risk acceptance until remediation is complete.
Evidence
- Revealed Passwords list export before remediation.
- Change ticket and approval record.
- Confirmation that cache was cleared and policy updated.
- Password reset records for affected privileged accounts.
Additional Guidance
Regularly audit RODC-revealed users to ensure no privileged accounts are exposed. Review the Password Replication Policy to prevent privileged user credentials from being cached on RODCs. Consider placing RODCs in more secure locations or strengthening physical security around them to assist in mitigating risk.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Artemis.Dubois | Artemis.Dubois | Yes | May 23, 2025 | May 23, 2025 | May 23, 2025 |
| Frank.Reynolds | Frank.Reynolds | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 |
| Domain Controller | Operating System | Last Logon | Password Set |
|---|---|---|---|
| ROPADDY-DC01.paddyspub.local | Windows Server 2019 Datacenter | Jul 13, 2026 | Jul 5, 2026 |
Schema Admins Group Not Empty
Schema Admins Group Not Empty
Schema Admins Group Not Empty
The "Schema Admins" group allows members to modify the Active Directory schema, which defines the structure of AD objects. These changes are permanent and can have far-reaching consequences. For security, this group should remain empty unless a schema update is necessary, and membership should be strictly controlled.
Schema group members are a prime target for attackers, specifically if they are looking to cause denial of service attacks.
Recommendation
Remove standing membership from Schema Admins, use temporary access for approved schema changes, and validate the group remains empty afterward.
Prerequisites
- Domain Administrator or Enterprise Administrator credentials required.
- Confirm that no active schema extension operations are in progress before removing members.
- Locate each current member and confirm with the account owner that the membership is no longer required.
- Obtain change control approval.
Remediation Objective
- Remove all accounts from the Schema Admins group when schema modification operations are not actively in progress.
- Ensure the Schema Admins group is empty except during planned, approved schema extension projects.
- Reduce the risk of unauthorized or accidental schema changes that could affect the entire forest.
- Apply the principle of just-in-time access for schema modification privileges.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove a specific member from Schema Admins.
# Replace <MemberName> with the account to remove.
Remove-ADGroupMember -Identity "Schema Admins" -Members "<MemberName>" -Confirm:$false -WhatIf
# Remove -WhatIf after reviewing output and confirming no active schema operation.# Import the required module for the remediation.
Import-Module ActiveDirectory
# Import a reviewed and approved list of affected objects to remediate.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
# Update only the objects included in the approved input file.
foreach ($Item in $Items) {
# Replace the placeholder command with the approved single-object remediation command for Schema Admins Group Not Empty.
# Use -WhatIf when supported before applying the change.
<Approved-Remediation-Command> -Identity $Item.DistinguishedName -WhatIf
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Navigate to the Users containerLocate the Schema Admins group.
- Open group propertiesRight-click Schema Admins and select Properties, then click the Members tab.
- Remove all membersSelect each member and click Remove.
- Save and validateClick OK. Confirm the group is empty.
Validation
- Confirm Schema Admins is empty: Get-ADGroupMember -Identity 'Schema Admins'
- Verify no authentication or directory operation failures occur following the change.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Do not approve permanent exceptions for this condition.
- Document any temporary delay with owner and target date.
- Track formal risk acceptance until remediation is complete.
Evidence
- Export of Schema Admins membership before changes.
- Change ticket and approval record.
- PowerShell output confirming empty group membership.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Schema Admins should normally remain empty except during approved schema changes. Remove standing membership, use time-bound access for schema updates, and monitor the group for unexpected additions.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| Frank.Reynolds | Frank.Reynolds | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 |
Shadow Credential Write Access on Privileged Objects
Shadow Credential Write Access on Privileged Objects
Shadow Credential Write Access on Privileged Objects
One or more privileged objects allow a non-standard principal to write shadow credential data through the msDS-KeyCredentialLink attribute or equivalent control permissions. This access can allow a user to add alternate authentication material and authenticate as the target account without knowing its password. When the affected object is privileged, this can create a direct path to domain compromise.
Shadow credentials abuse the Key Trust model. An attacker who can write msDS-KeyCredentialLink on a victim adds a public key under their control, requests a Kerberos ticket-granting ticket for the victim via PKINIT, and recovers the victim's NTLM hash from the PAC. Whisker, pyWhisker, and Certipy perform the sequence in seconds and clean up afterward.
Recommendation
Remove non-administrative write access to msDS-KeyCredentialLink on domain controllers and privileged accounts.
Prerequisites
- Domain Admin, or rights to modify the object's security descriptor.
- The DSInternals module to inspect existing key credentials.
- Obtain change control approval.
Remediation Objective
- Remove write access to msDS-KeyCredentialLink (and broad GenericAll / WriteDacl / WriteOwner) from non-default principals on the flagged objects.
- Inspect and clear any unexpected key credentials already present.
- Enable directory service change auditing for msDS-KeyCredentialLink.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Inspect existing key credentials on the object (requires the DSInternals module).
Import-Module DSInternals
Get-ADReplAccount -SamAccountName "<SamAccountName>" -Server "<DomainController>" | Select-Object -ExpandProperty KeyCredentials
# Review the object's ACL, then remove a non-default principal's access.
dsacls "<ObjectDN>"
dsacls "<ObjectDN>" /R "<DOMAIN\Principal>"# Remediate approved objects (columns: ObjectDN, Principal).
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
foreach ($Item in $Items) {
# Review first; this removes the principal's access from the object.
<Approved-Remediation-Command> $Item.ObjectDN /R $Item.Principal
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch ADUC and enable Advanced Features from the View menu.
- Locate the flagged objectNavigate to the privileged account or domain controller identified in the report.
- Open the security editorRight-click the object, select Properties, open the Security tab, and click Advanced.
- Remove the dangerous entryFind the non-default principal with Write to msDS-KeyCredentialLink or full control, select it, and click Remove.
- Save and repeatApply the change and repeat for each approved object.
Validation
- Confirm the principal no longer has write access to the object.
- Inspect msDS-KeyCredentialLink for unexpected entries and remove them.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If a principal legitimately manages the object, replace broad rights with the minimum required.
- Document any retained delegation with owner and justification.
- Track formal risk acceptance.
Evidence
- ACL export for each object before and after remediation.
- Output of any key credentials found and removed.
- Follow-up scan results confirming resolution.
Additional Guidance
Protect Tier 0 objects by minimizing who can modify their attributes, and audit delegated permissions on the AdminSDHolder object since its ACL propagates to all protected accounts. Enabling change auditing for msDS-KeyCredentialLink detects shadow credential additions, and the Protected Users group reduces the impact of credential theft.
| Domain Controller | Operating System | Last Logon | Password Set |
|---|---|---|---|
| PADDY-DC01.paddyspub.local | Windows Server 2019 Datacenter | Jul 13, 2026 | Jul 5, 2026 |
| DENNIS-LT01.paddyspub.local | Windows Server 2008 R2 Standard | Never | Jul 17, 2025 |
Unconstrained Delegations Detected
Unconstrained Delegations Detected
Unconstrained Delegations Detected
Unconstrained delegation allows a service or account to impersonate any user that interacts with it by caching their Kerberos ticket-granting tickets (TGT). This creates a significant security risk, as attackers who compromise a service trusted for unconstrained delegation can extract these TGTs and impersonate privileged accounts, leading to domain take over.
Unconstrained delegation is often combined with network poisoning attacks and endpoint configuration abuse to force communication from sensitive assets such as domain controllers. The attack path typically involves immediately dumping the domain controller of hashes which can be passed or cracked offline.
Recommendation
Remove unconstrained delegations or replace it with constrained delegation where required.
Prerequisites
- Domain Admin rights to modify delegation settings on accounts and computers.
- Service owner identification and sign-off for each affected account.
- Testing environment available to validate service functionality after delegation change.
- Change control approval obtained.
- Rollback plan documented.
Remediation Objective
- Remove unconstrained delegation from all non-domain controller accounts and computers where it is identified.
- Replace unconstrained delegation with constrained delegation scoped to the minimum required services.
- Confirm affected services continue to function correctly after the change.
- Implement monitoring for TGT requests from accounts with delegation enabled.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove unconstrained delegation from a specific user or computer account.
# Replace <SamAccountName> with the target account.
# For a computer account, append $ to the name (e.g., SERVER01$).
# Disable unconstrained delegation by setting TrustedForDelegation to $false.
Set-ADAccountControl -Identity "<SamAccountName>" -TrustedForDelegation $false# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts with unconstrained delegation to remediate.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedDelegationAccounts.csv"
# Remove unconstrained delegation from each account in the approved input file.
foreach ($Account in $Accounts) {
Set-ADAccountControl -Identity $Account.SamAccountName -TrustedForDelegation $false -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after the change has been reviewed and approved.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. Enable Advanced Features under the View menu. - Locate the affected accountNavigate to the OU or container containing the account identified in the report.
- Open account propertiesDouble-click the account to open its properties.
- Navigate to the Delegation tabSelect the Delegation tab.
- Remove unconstrained delegationSelect Do not trust this computer for delegation, or select Use Kerberos only constrained delegation if the service requires delegation to specific services.
- Configure constrained delegation (if required)If the service requires delegation, select Use Kerberos only and add the specific SPNs to the Services to which this account can present delegated credentials list.
- Save changesClick OK or Apply.
Validation
- Confirm unconstrained delegation is removed using Get-ADUser or Get-ADComputer with -Properties TrustedForDelegation.
- Verify that affected services are functioning correctly after the change.
- Confirm no new TGT caching is occurring for the account by reviewing Kerberos event logs.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after export of delegation settings for affected accounts.
- Service validation test results confirming functionality after change.
- Change ticket and approval record.
- PowerShell transcript of remediation commands.
Additional Guidance
Unconstrained delegation is a dangerous configuration that should be avoided in most environments due to its susceptibility to Kerberos-based attacks. Conduct regular audits to detect and remove any accounts with unconstrained delegation and implement monitoring to detect suspicious activity related to TGT requests. If a delegation must be kept, consider moving to a “constrained delegation” which will restrict which services can be delegated to. If choosing this option, ensure additional monitoring and alerting is configured for this service. Any unconstrained or constrained delegated account should be treated as a domain administrator or equivalent.
| Account | Display Name | Enabled | Created | Last Logon | Password Set |
|---|---|---|---|---|---|
| UncleJack.Kelly | Yes | May 1, 2025 | Never | May 1, 2025 |
| Computer | Operating System | Created | Last Logon | Password Set |
|---|---|---|---|---|
| DEE-PC01$ | Windows Server 2019 Datacenter | Jun 30, 2021 | Jul 13, 2026 | Jul 6, 2026 |
User-controlled certificate template subject in ADCS (ESC1)
User-controlled certificate template subject in ADCS (ESC1)
User-controlled certificate template subject in ADCS (ESC1)
This is a critical security issue where low-level users can exploit certificate request settings to impersonate higher-privileged accounts, like domain administrators. This occurs when certificate templates are configured with weak permissions that allow users to input key identity details themselves. If these conditions align, users can request certificates that allow them to assume the identity of others.
This misconfiguration is highly sought after by attackers, as it requires minimal skill to exploit and has a high success rate for privilege escalation. Once authenticated, attackers use tools like Certipy, Certify, or Rubeus, to identify vulnerable certificate templates, generate a certificate as a domain administrator, and retrieve the user’s NT hash. This hash can then be used in Pass-the-Hash attacks or cracked offline. Attackers may then employ tools like CrackMapExec or Impacket’s secretsdump.py to remotely extract hashes from the domain controller.
Recommendation
Remove enrollee-supplied subject settings from vulnerable templates, restrict enrollment, and validate that authentication certificates cannot be requested for arbitrary identities.
Prerequisites
- Enterprise Admin or CA Administrator rights to modify certificate templates.
- Inventory of services and applications using affected certificate template.
- Testing environment available to validate template changes.
- Change control approval obtained.
Remediation Objective
- Remove or restrict the Supply in Request (SAN) flag from vulnerable certificate templates.
- Require manager approval for certificate issuance on sensitive templates.
- Restrict enrollment rights to remove low-privileged groups such as Authenticated Users or Domain Users.
- Ensure that at least one of the ESC1 enabling conditions is broken to prevent exploitation.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Disable the Supply in Request flag on a vulnerable certificate template.
# This must be run with Enterprise Admin or CA Administrator rights.
# Load the PSPKI module (install if not present).
Install-Module -Name PSPKI -Force -AllowClobber
Import-Module PSPKI
# Retrieve the certificate template by name.
# Replace <TemplateName> with the display name of the vulnerable template.
$Template = Get-CertificateTemplate -Name "<TemplateName>"
# Remove the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag (0x1) from the template.
# This prevents users from specifying a Subject Alternative Name in their request.
$Flags = $Template.pKIDefaultKeySpec
Set-CertificateTemplateAcl -Template $TemplateRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Certificate Templates ConsoleRun
certtmpl.mscfrom an administrative workstation with Enterprise Admin rights. - Locate the affected templateLocate the certificate template named in the report. Right-click the template and select Duplicate Template to create a test copy, or Properties to modify directly.
- Review the Subject Name tabSelect the Subject Name tab. If Supply in the request is selected, change this to Build from this Active Directory information to prevent users from supplying their own SAN.
- Review the Security tabOn the Security tab, remove Authenticated Users or Domain Users from the enrollment permissions if they are present. Restrict enrollment to specific groups with a documented business need.
- Enable manager approvalOn the Issuance Requirements tab, check CA certificate manager approval to require manual approval of certificate requests.
- Apply changes and republishClick OK to save the template changes. In the Certification Authority console (
certsrv.msc), right-click Certificate Templates and reissue the updated template.
Validation
- Confirm the ENROLLEE_SUPPLIES_SUBJECT flag is no longer set on the template using Get-CertificateTemplate or certutil -v -dump.
- Attempt to enroll a certificate with a custom SAN using a low-privileged account to confirm the vulnerability is no longer exploitable.
- Verify that legitimate enrollment processes continue to function correctly.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- CA database backup confirmation prior to template changes.
- Before-and-after certutil output showing template flag changes.
- Certificate enrollment test results.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
ESC1 is one of the most commonly exploited ADCS vulnerabilities because it requires minimal skill to exploit and reliably results in domain administrator-level compromise. The vulnerability exists at the intersection of multiple template configuration weaknesses, and organizations can break the attack chain by correcting any single condition. The highest-priority change is removing the ability for low-privileged users to supply a Subject Alternative Name in certificate requests.
Organizations operating an Active Directory Certificate Services infrastructure should conduct a regular PKI security review that includes assessment of all certificate template configurations. Template permissions should be reviewed quarterly, and any new template should be subject to a formal security review before publication to the CA.
For this vulnerability to be exploitable, several conditions must be met: 1. Enrollment Rights for Low-Privileged Users 2. No Manager Approval or Authorized Signatures 3. Overly Permissive Security Descriptors 4. Authentication-Enabled EKUs 5. User-Specified Subject Alternative Name (SAN)
| Object | Type |
|---|---|
| Fight Milk Any Purpose | Certificate template |
Domain UsersEnroll | Account |
NT AUTHORITY\Authenticated UsersWrite owner | Account |
The Hacker Recipes - Active Directory Certificate Services (AD CS) attacks overview
The Hacker Recipes - ADCS certificate template misconfigurations (ESC1-ESC3 and more)
SpecterOps - Certified Pre-Owned: abusing Active Directory Certificate Services (ESC1-ESC8)
MITRE ATT&CK - Steal or Forge Authentication Certificates (T1649)
Environment Overview
Scope and inventory of the Active Directory tenant scanned. Use this to confirm the right environment was assessed and quickly spot foundational gaps.
Domain Configuration
Forest, schema, and naming details.
Infrastructure Status
Health checks across core AD services.
Accounts & Groups
Accounts, privileged groups, and special service identities.
Privileged Groups
High-level overview of privileged groups and their membership.
| Name | Count | Enabled | Disabled | Inactive | Password Never Expires | Service Accounts | Can be Delegated | Protected Users | External Users |
|---|---|---|---|---|---|---|---|---|---|
| Account Operators | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 |
| Administrators | 3 | 3 | 0 | 0 | 1 | 0 | 1 | 0 | 2 |
| Backup Operators | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Domain Admins | 10 | 9 | 1 | 1 | 6 | 1 | 9 | 0 | 1 |
| Enterprise Admins | 2 | 2 | 0 | 0 | 2 | 0 | 2 | 0 | 0 |
| Print Operators | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 |
| Schema Admins | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 |
| Server Operators | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Account Operators Count: 1
| Name | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Liam.McPoyle | Yes | Yes | Yes | No | No | Yes | No | 2025-04-04 | Never | 2025-04-04 | CN=Liam McPoyle,CN=Users,DC=paddyspub,DC=local |
Administrators Count: 3
| Name | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Administrator | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2025-05-23 14:29 | 2025-04-14 | CN=Administrator,CN=Users,DC=paddyspub,DC=local |
| Domain Admins | Yes | No | No | No | No | No | No | CN=Domain Admins,CN=Users,DC=paddyspub,DC=local | |||
| Enterprise Admins | Yes | No | No | No | No | No | No | CN=Enterprise Admins,CN=Users,DC=paddyspub,DC=local |
Backup Operators Count: 0
| Name | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|
Domain Admins Count: 10
| Name | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Administrator | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2025-05-23 14:29 | 2025-04-14 | CN=Administrator,CN=Users,DC=paddyspub,DC=local |
| Charlie.Kelly | Yes | Yes | Yes | No | No | Yes | No | 2025-05-19 | Never | 2025-05-19 | CN=Charlie Kelly,CN=Users,DC=paddyspub,DC=local |
| Bill.Ponderosa | No | No | No | No | No | Yes | No | 2025-04-04 | Never | 2025-04-04 | CN=Bill Ponderosa,CN=Users,DC=paddyspub,DC=local |
| Frank.Reynolds | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2026-07-13 11:18 | 2025-04-03 | CN=Frank Reynolds,CN=Users,DC=paddyspub,DC=local |
| Waitress | Yes | Yes | No | No | No | Yes | No | 2025-05-08 | Never | 2025-05-08 | CN=Waitress,CN=Users,DC=paddyspub,DC=local |
| Dennis.Reynolds | Yes | Yes | Yes | No | Yes | Yes | No | 2025-04-11 | Never | 2025-04-11 | CN=Dennis Reynolds,CN=Users,DC=paddyspub,DC=local |
| Ronald.McDonald | Yes | Yes | Yes | No | No | Yes | No | 2025-06-10 | 2025-06-10 18:49 | 2025-06-10 | CN=Ronald McDonald,CN=Users,DC=paddyspub,DC=local |
| Dee.Reynolds | Yes | Yes | Yes | No | No | Yes | No | 2025-05-19 | Never | 2025-05-19 | CN=Dee Reynolds,CN=Users,DC=paddyspub,DC=local |
| DEE-PC01$ | Yes | No | No | No | No | No | No | CN=DEE-LT01,OU=TestComputers,DC=paddyspub,DC=local | |||
| Artemis.Dubois | Yes | Yes | No | No | No | Yes | No | 2025-05-23 | 2025-05-23 17:46 | 2025-05-23 | CN=Artemis Dubois,CN=Users,DC=paddyspub,DC=local |
Enterprise Admins Count: 2
| Name | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Administrator | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2025-05-23 14:29 | 2025-04-14 | CN=Administrator,CN=Users,DC=paddyspub,DC=local |
| Frank.Reynolds | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2026-07-13 11:18 | 2025-04-03 | CN=Frank Reynolds,CN=Users,DC=paddyspub,DC=local |
Print Operators Count: 1
| Name | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Rickety.Cricket | Yes | Yes | Yes | No | No | Yes | No | 2025-07-02 | Never | 2025-07-02 | CN=Rickety Cricket,CN=Users,DC=paddyspub,DC=local |
Schema Admins Count: 1
| Name | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Frank.Reynolds | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2026-07-13 11:18 | 2025-04-03 | CN=Frank Reynolds,CN=Users,DC=paddyspub,DC=local |
Server Operators Count: 0
| Name | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|
User Accounts
Detailed information about user accounts in the environment.
User Accounts User Accounts: 74
| Name | Enabled | Password Never Expires | Creation | Last Logon | Password Last Set | Distinguished Name |
|---|---|---|---|---|---|---|
| Administrator | Yes | Yes | Jun 30, 2021 | May 23, 2025 | Apr 14, 2025 | CN=Administrator,CN=Users,DC=paddyspub,DC=local |
| Nightman | Yes | Yes | May 7, 2025 | Never | May 7, 2025 | CN=Nightman,CN=Users,DC=paddyspub,DC=local |
| Country.Mac | Yes | No | Apr 4, 2025 | Never | Apr 4, 2025 | CN=Country Mac,CN=Users,DC=paddyspub,DC=local |
| Charlie.Kelly | Yes | Yes | May 19, 2025 | Never | May 19, 2025 | CN=Charlie Kelly,CN=Users,DC=paddyspub,DC=local |
| Gail.Snail | Yes | Yes | Apr 4, 2025 | Never | Apr 4, 2025 | CN=Gail Snail,CN=Users,DC=paddyspub,DC=local |
| Bill.Ponderosa | No | No | Apr 4, 2025 | Never | Apr 4, 2025 | CN=Bill Ponderosa,CN=Users,DC=paddyspub,DC=local |
| Frank.Reynolds | Yes | Yes | Jun 30, 2021 | Jul 13, 2026 | Apr 3, 2025 | CN=Frank Reynolds,CN=Users,DC=paddyspub,DC=local |
| Guest | Yes | Yes | Jun 30, 2021 | Never | Apr 4, 2025 | CN=Guest,CN=Users,DC=paddyspub,DC=local |
| Waitress | Yes | No | May 8, 2025 | Never | May 8, 2025 | CN=Waitress,CN=Users,DC=paddyspub,DC=local |
| Dennis.Reynolds | Yes | Yes | Apr 11, 2025 | Never | Apr 11, 2025 | CN=Dennis Reynolds,CN=Users,DC=paddyspub,DC=local |
| krbtgt | No | No | Jun 30, 2021 | Never | Apr 4, 2025 | CN=krbtgt,CN=Users,DC=paddyspub,DC=local |
| Maureen.Ponderosa | No | No | Apr 9, 2025 | Never | Apr 9, 2025 | CN=Maureen Ponderosa,CN=Users,DC=paddyspub,DC=local |
| Ronald.McDonald | Yes | Yes | Jun 10, 2025 | Jun 10, 2025 | Jun 10, 2025 | CN=Ronald McDonald,CN=Users,DC=paddyspub,DC=local |
| Luther.McDonald | Yes | Yes | May 8, 2025 | Never | May 8, 2025 | CN=Luther McDonald,CN=Users,DC=paddyspub,DC=local |
| Liam.McPoyle | Yes | Yes | Apr 4, 2025 | Never | Apr 4, 2025 | CN=Liam McPoyle,CN=Users,DC=paddyspub,DC=local |
| Dayman | Yes | Yes | Apr 4, 2025 | Never | Apr 4, 2025 | CN=Dayman,CN=Users,DC=paddyspub,DC=local |
| Pepper.Jack | Yes | No | Apr 4, 2025 | Never | Apr 4, 2025 | CN=Pepper Jack,CN=Users,DC=paddyspub,DC=local |
| Bonnie.Kelly | Yes | No | Apr 4, 2025 | Never | Jun 23, 2025 | CN=Bonnie Kelly,CN=Users,DC=paddyspub,DC=local |
| Carmen | Yes | Yes | Apr 4, 2025 | Never | Apr 4, 2025 | CN=Carmen,CN=Users,DC=paddyspub,DC=local |
| Roxy | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Roxy,CN=Users,DC=paddyspub,DC=local |
| Barbara.Reynolds | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Barbara Reynolds,CN=Users,DC=paddyspub,DC=local |
| Ryan.McPoyle | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Ryan McPoyle,CN=Users,DC=paddyspub,DC=local |
| Psycho.Pete | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Psycho Pete,CN=Users,DC=paddyspub,DC=local |
| Da.Maniac | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Da Maniac,CN=Users,DC=paddyspub,DC=local |
| Rex | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Rex,CN=Users,DC=paddyspub,DC=local |
| Ruby.Taft | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Ruby Taft,CN=Users,DC=paddyspub,DC=local |
| Schmitty | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Schmitty,CN=Users,DC=paddyspub,DC=local |
| Duncan | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Duncan,CN=Users,DC=paddyspub,DC=local |
| Z | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Z,CN=Users,DC=paddyspub,DC=local |
| Hwang | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Hwang,CN=Users,DC=paddyspub,DC=local |
| Lawyer | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Lawyer,CN=Users,DC=paddyspub,DC=local |
| Ben.Smith | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Ben Smith,CN=Users,DC=paddyspub,DC=local |
| svc_Green.Man | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Green Man,CN=Users,DC=paddyspub,DC=local |
| svc_Bird.Law | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Bird Law,CN=Users,DC=paddyspub,DC=local |
| svc_Fight.Milk | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Fight Milk,CN=Users,DC=paddyspub,DC=local |
| svc_Rum.Ham | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Rum Ham,CN=Users,DC=paddyspub,DC=local |
| svc_Wolf.Cola | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Wolf Cola,CN=Users,DC=paddyspub,DC=local |
| svc_Ingrid.Nelson | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Ingrid Nelson,CN=Users,DC=paddyspub,DC=local |
| svc_Kitten.Mittens | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Kitten Mittens,CN=Users,DC=paddyspub,DC=local |
| svc_Milk.Steak | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Milk Steak,CN=Users,DC=paddyspub,DC=local |
| John.Thundergun | Yes | Yes | Jul 3, 2025 | Never | Never | CN=John Thundergun,CN=Users,DC=paddyspub,DC=local |
| Doyle.McPoyle | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Doyle McPoyle,CN=Users,DC=paddyspub,DC=local |
| Byron | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Byron,CN=Users,DC=paddyspub,DC=local |
| Waiter | Yes | Yes | Jul 3, 2025 | Never | Never | CN=Waiter,CN=Users,DC=paddyspub,DC=local |
| Donna.Brunswick | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Donna Brunswick,CN=Users,DC=paddyspub,DC=local |
| Jack.Bauer | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Jack Bauer,CN=Users,DC=paddyspub,DC=local |
| Gladys.Reynolds | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Gladys Reynolds,CN=Users,DC=paddyspub,DC=local |
| Shelly.Kelly | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Shelly Kelly,CN=Users,DC=paddyspub,DC=local |
| Pappy.McPoyle | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Pappy McPoyle,CN=Users,DC=paddyspub,DC=local |
| Margaret.McPoyle | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Margaret McPoyle,CN=Users,DC=paddyspub,DC=local |
| Peter.Nincompoop | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Peter Nincompoop,CN=Users,DC=paddyspub,DC=local |
| Brian.LeFevre | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Brian LeFevre,CN=Users,DC=paddyspub,DC=local |
| Vic.Vinegar | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Vic Vinegar,CN=Users,DC=paddyspub,DC=local |
| Hugh.Honey | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Hugh Honey,CN=Users,DC=paddyspub,DC=local |
| Mantis.Toboggan | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Mantis Toboggan,CN=Users,DC=paddyspub,DC=local |
| Ongo.Gablogian | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Ongo Gablogian,CN=Users,DC=paddyspub,DC=local |
| Desert.Grape | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Desert Grape,CN=Users,DC=paddyspub,DC=local |
| svc_Invigaron | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Invigaron,CN=Users,DC=paddyspub,DC=local |
| svc_Franks.Fluids | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Franks Fluids,CN=Users,DC=paddyspub,DC=local |
| svc_Paddy.Wagon | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Paddy Wagon,CN=Users,DC=paddyspub,DC=local |
| svc_Electric.Dream.Machine | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Electric Dream Machine,CN=Users,DC=paddyspub,DC=local |
| svc_Paddy.Dollars | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Paddy Dollars,CN=Users,DC=paddyspub,DC=local |
| Lil.Kev | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Lil Kev,CN=Users,DC=paddyspub,DC=local |
| Chase.Utley | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Chase Utley,CN=Users,DC=paddyspub,DC=local |
| Edurado.Sanchez | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Edurado Sanchez,CN=Users,DC=paddyspub,DC=local |
| Dr.Jinx | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Dr Jinx,CN=Users,DC=paddyspub,DC=local |
| Don.Cheadle | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Don Cheadle,CN=Users,DC=paddyspub,DC=local |
| Tiger.Woods | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Tiger Woods,CN=Users,DC=paddyspub,DC=local |
| svc_Shadynasty | Yes | Yes | Jul 23, 2025 | Never | Jul 23, 2025 | CN=Shadynasty,CN=Users,DC=paddyspub,DC=local |
| Dee.Reynolds | Yes | Yes | May 19, 2025 | Never | May 19, 2025 | CN=Dee Reynolds,CN=Users,DC=paddyspub,DC=local |
| Mrs.Mac | Yes | Yes | Apr 4, 2025 | Never | Apr 4, 2025 | CN=Mrs Mac,CN=Users,DC=paddyspub,DC=local |
| Artemis.Dubois | Yes | No | May 23, 2025 | May 23, 2025 | May 23, 2025 | CN=Artemis Dubois,CN=Users,DC=paddyspub,DC=local |
| UncleJack.Kelly | Yes | No | May 1, 2025 | Never | May 1, 2025 | CN=UncleJack Kelly,CN=Users,DC=paddyspub,DC=local |
| Rickety.Cricket | Yes | Yes | Jul 2, 2025 | Never | Jul 2, 2025 | CN=Rickety Cricket,CN=Users,DC=paddyspub,DC=local |
Computer Accounts
Detailed information about computer accounts in the environment.
Computer Accounts Computer Accounts: 18
| Name | Creation | Last Logon | Password Last Set | Distinguished Name |
|---|---|---|---|---|
| PADDY-DC01$ | Jun 30, 2021 | Jul 13, 2026 | Jul 5, 2026 | CN=PADDY-DC01,OU=Domain Controllers,DC=paddyspub,DC=local |
| PADDY-PC01$ | May 8, 2025 | Never | May 8, 2025 | CN=PADDY-PC01,OU=TestComputers,DC=paddyspub,DC=local |
| PADDY-DC02$ | Jul 17, 2025 | Never | Jul 17, 2025 | CN=PADDY-DC02,OU=Domain Controllers,DC=paddyspub,DC=local |
| DENNIS-LT01$ | May 8, 2025 | Never | May 8, 2025 | CN=DENNIS-LT01,CN=Computers,DC=paddyspub,DC=local |
| ROPADDY-DC01$ | Apr 9, 2025 | Jul 13, 2026 | Jul 5, 2026 | CN=ROPADDY-DC01,OU=Domain Controllers,DC=paddyspub,DC=local |
| DEE-PC01$ | Jun 30, 2021 | Jul 13, 2026 | Jul 6, 2026 | CN=DEE-LT01,OU=TestComputers,DC=paddyspub,DC=local |
| CHARLIE-PC01$ | Jun 10, 2025 | Jul 13, 2026 | Jul 5, 2026 | CN=CHARLIE-PC01,OU=New-Computers,DC=paddyspub,DC=local |
| MAC-PC01$ | May 8, 2025 | Never | May 8, 2025 | CN=MAC-PC01,CN=Computers,DC=paddyspub,DC=local |
| FRANK-PC01$ | May 8, 2025 | Never | May 8, 2025 | CN=FRANK-PC01,CN=Computers,DC=paddyspub,DC=local |
| GREENMAN-PC01$ | May 8, 2025 | Never | May 8, 2025 | CN=GREENMAN-PC01,CN=Computers,DC=paddyspub,DC=local |
| NIGHTMAN-PC01$ | May 8, 2025 | Never | May 8, 2025 | CN=NIGHTMAN-PC01,CN=Computers,DC=paddyspub,DC=local |
| DAYMAN-PC01$ | May 8, 2025 | Never | May 8, 2025 | CN=DAYMAN-PC01,CN=Computers,DC=paddyspub,DC=local |
| RUMHAM-PC01$ | Jul 3, 2025 | Never | Jul 3, 2025 | CN=RUMHAM-PC01,CN=Computers,DC=paddyspub,DC=local |
| FIGHTMILK-PC01$ | Jul 3, 2025 | Never | Jul 3, 2025 | CN=FIGHTMILK-PC01,CN=Computers,DC=paddyspub,DC=local |
| WOLFCOLA-LT01$ | May 8, 2025 | Never | May 8, 2025 | CN=WOLFCOLA-PC01,CN=Computers,DC=paddyspub,DC=local |
| KITTENMITTONS-LT01$ | May 8, 2025 | Never | May 8, 2025 | CN=KITTENMITTONS-PC01,CN=Computers,DC=paddyspub,DC=local |
| BIRDLAW-PC01$ | May 8, 2025 | Never | May 8, 2025 | CN=BIRDLAW-PC01,CN=Computers,DC=paddyspub,DC=local |
| INVIGARON-PC01$ | May 8, 2025 | Never | May 8, 2025 | CN=INVIGARON-PC01,CN=Computers,DC=paddyspub,DC=local |
Infrastructure & Cloud
Cloud sync, endpoint management, and update services. Detached or misconfigured here usually means slower patching and weaker visibility.
Cloud Services
Hybrid sync to Microsoft Entra (Azure AD).
Entra ID Sync Not Detected
Entra Connect Not Detected
Management Tools
Overview and configuration status of management and update tools.
WSUS Servers Servers: 2 Configured
| GPO Name | GPO Link | Update Source | Server URL | Install Mode | Suppress Auto-Reboot | Allow Non-Admins |
|---|---|---|---|---|---|---|
| Default Domain Policy | Yes | WSUS | server.paddyspub.local | — | No | No |
| Default Domain Policy | Yes | WSUS | server3.paddyspub.local | — | No | No |
Trusts
Active Directory trust relationships with external domains and forests.
PKI & Certificates
Overview and configuration status of PKI infrastructure and certificates.
Certificate Authorities
Certificate authority infrastructure and issued certificate counts.
Certificate Authorities CAs: 1 Certificates: 2
| CA Name | DNS Hostname | Certificates |
|---|---|---|
| paddyspub-RODC-CA | ROPADDY-DC01.paddyspub.local | 2 |
Certificate Templates
Certificate template configuration and enrollment risk indicators. Flags highlight enrollment misconfigurations associated with ADCS escalation paths.
Certificate Templates Templates: 35
| Name | Destination | Manager Approval | Enrollee Can Supply Subject | Issuance Requirements | Vulnerable ACL | Everyone Can Enroll | Agent Template | Any Purpose | For Authentication |
|---|---|---|---|---|---|---|---|---|---|
| Administrator | User | No | No | No | No | No | No | No | Yes |
| Authenticated Session | User | No | No | No | No | Yes | No | No | Yes |
| Basic EFS | User | No | No | No | No | Yes | No | No | No |
| CA Exchange | Computer | No | Yes | No | No | No | No | No | No |
| CEP Encryption | Computer | No | Yes | No | No | No | Yes | No | No |
| Code Signing | User | No | No | No | No | No | No | No | No |
| Computer | Computer | No | No | No | No | Yes | No | No | Yes |
| Cross Certification Authority | User | No | Yes | Yes | No | No | No | Yes | Yes |
| Directory Email Replication | Computer | No | No | No | No | No | No | No | No |
| Domain Controller | Computer | No | No | No | No | No | No | No | Yes |
| Domain Controller Authentication | Computer | No | No | No | No | No | No | No | Yes |
| EFS Recovery Agent | User | No | No | No | No | No | No | No | No |
| Enrollment Agent | User | No | No | No | No | No | Yes | No | No |
| Enrollment Agent (Computer) | Computer | No | No | No | No | No | Yes | No | No |
| Fight Milk Any Purpose | Computer | No | Yes | No | Yes | Yes | No | Yes | Yes |
| Wolf Cola Enroll | Computer | No | No | No | Yes | Yes | Yes | No | No |
| Exchange Enrollment Agent (Offline request) | User | No | Yes | No | No | No | Yes | No | No |
| Exchange Signature Only | User | No | Yes | No | No | No | No | No | No |
| Exchange User | User | No | Yes | No | No | No | No | No | No |
| IPSec | Computer | No | No | No | No | Yes | No | No | No |
| IPSec (Offline request) | Computer | No | Yes | No | No | No | No | No | No |
| Kerberos Authentication | Computer | No | No | No | No | No | No | No | Yes |
| Key Recovery Agent | User | Yes | No | No | No | No | No | No | No |
| OCSP Response Signing | Computer | No | No | No | No | No | No | No | No |
| RAS and IAS Server | Computer | No | No | No | No | No | No | No | Yes |
| Root Certification Authority | Computer | No | Yes | No | No | No | No | Yes | Yes |
| Router (Offline request) | Computer | No | Yes | No | No | No | No | No | Yes |
| Smartcard Logon | User | No | No | No | No | No | No | No | Yes |
| Smartcard User | User | No | No | No | No | No | No | No | Yes |
| Subordinate Certification Authority | Computer | No | Yes | No | No | No | No | Yes | Yes |
| Trust List Signing | User | No | No | No | No | No | No | No | No |
| User | User | No | No | No | No | Yes | No | No | Yes |
| User Signature Only | User | No | No | No | No | Yes | No | No | Yes |
| Web Server | Computer | No | Yes | No | No | No | No | No | No |
| Workstation Authentication | Computer | No | No | No | No | Yes | No | No | Yes |
Trusted Certificates
Enterprise trusted certificate stores and authentication-related certificates.
Trusted Certificates Certificates: 3
| Source | Store | Subject | Issuer | Valid From | Valid Until | Key Length | Signature Algorithm | Smart Card Logon |
|---|---|---|---|---|---|---|---|---|
| Enterprise Root | Certification Authorities | CN=paddyspub-RODC-CA, DC=paddyspub, DC=local | CN=paddyspub-RODC-CA, DC=paddyspub, DC=local | Apr 9, 2025 | Apr 9, 2035 | 2048 | sha256RSA | Disabled |
| Enterprise NTAuth | NTAuthCertificates | CN=paddyspub-RODC-CA, DC=paddyspub, DC=local | CN=paddyspub-RODC-CA, DC=paddyspub, DC=local | Apr 9, 2025 | Apr 9, 2035 | 2048 | sha256RSA | Disabled |
| Enterprise AIA | AIA | CN=paddyspub-RODC-CA, DC=paddyspub, DC=local | CN=paddyspub-RODC-CA, DC=paddyspub, DC=local | Apr 9, 2025 | Apr 9, 2035 | 2048 | sha256RSA | Disabled |
Group Policy
Overview and configuration status of domain group policies.
Password Policies
Domain password and account lockout policy configuration.
Password Policies Policies: 1
| Policy Name | Policy Type | Password Complexity Enabled | Maximum Password Age | Minimum Password Length | Password History Length | Reversible Encryption | Account Lockout Threshold | Account Lockout Duration |
|---|---|---|---|---|---|---|---|---|
| Default Domain Policy | Default | Yes | 42 days | 8 | 24 | Disabled | — | 30 minutes |
Screensaver Policies
Screen lock and inactivity timeout settings applied through Group Policy.
Local Administrator Group Management Policies
Policies that manage local administrator group membership on domain-joined systems.
Local Administrator Group Management Policies: 1
| GPO Name | Configuration Method | Target Local Group | Enforcement Mode | Members Defined | GPO Linked | Applies To |
|---|---|---|---|---|---|---|
| Default Domain Policy | GP Preferences | Remote Desktop Users (built-in) | Update | 1 members | Yes | DC=paddyspub,DC=local; OU=Computerz,DC=paddyspub,DC=local; OU=TestComputers,DC=paddyspub,DC=local |
Firewall Policies
Windows Firewall policy settings and inbound access controls.
Group Policy Objects
7 GPO(s) in the domain.
| Name | Enabled | Modified |
|---|---|---|
| Default Domain Controllers Policy | Yes | Jun 13, 2025 |
| Default Domain Policy | Yes | Aug 5, 2025 |
| DeployFile | Yes | May 8, 2025 |
| Disable LLMNR | Yes | Jun 17, 2025 |
| KA | Yes | May 6, 2025 |
| KA-Computers | Yes | May 6, 2025 |
| NetSession | Yes | May 7, 2025 |