| Users DES encryption attribute status |
Name:
User accounts using DES encryption to log in
Default scope:
All users |
DES encryption is weak and easy for an adversary to crack. User accounts configured to use DES encryption for authentication are particularly vulnerable to being compromised.
Remediation:
To resolve vulnerability, in the account's Account tab -Account options, uncheck “Use only Kerberos DES encryption types for this account”. |
User accounts in scope that have “Use only Kerberos DES encryption types for this account enabled |
| Account password reversible encryption status |
Name:
User accounts have a reversible password
Default scope:
All users |
User accounts with the "Store password using reversible encryption" enabled will have their passwords stored in a manner that can be easily harvested by an adversary looking for an entry point to the directory.
Remediation:
To resolve vulnerability, in the account's Account tab - Account options, uncheck “Store password using reversible encryption”. |
User accounts in scope that have “Store password using reversible encryption” enabled |
|
Name:
Computer accounts with reversible password
Default scope:
All computers |
Computer accounts with the "Store password using reversible encryption" enabled will have their passwords stored in a manner that can be easily harvested by an adversary looking for an entry point to the directory.
Remediation:
Disable "Store password using reversible encryption" unless the setting is required for the Challenge Handshake Authentication Protocol (CHAP) through remote access or Internet Authentication Services (IAS) or Digest Authentication in Internet Information Services (IIS). Set the "Store password using reversible encryption" to false on all Computer accounts either through the computer’s local security policy or the assigned group policy. |
Accounts in scope that have "Store password using reversible encryption" enabled |
| Users Kerberos preauthentication status |
Name:
User accounts with Kerberos pre-authentication disabled
Default scope:
All users |
User accounts with Kerberos pre-authentication disabled can be compromised as part of ASREP-Roasting attacks.
Remediation:
To resolve vulnerability, in the account’s Account tab -Account options, uncheck "Do not require Kerberos preauthentication". |
User accounts in scope that have “Do not require Kerberos preauthentication” enabled |
| Users Service Principal Name status |
Name:
Non-Tier Zero user accounts with Service Principal Names
Default scope:
All except Tier Zero users |
User accounts with Service Principal Names (SPNs) defined are exposed to Kerberos-based authentication attacks, providing an adversary with an entry point to the directory.
Remediation:
To resolve vulnerability, remove the Service Principal Name from the user object if possible. If the Service Principal Name cannot be removed, enforce a very strong password on the user object which contains 32 characters with upper case, lower case, numeral, and special characters. |
User accounts in scope that have “Service Principal Name” not empty |
| Users delegated account attribute status |
Name:
Tier Zero account can be delegated
Default scope:
Tier Zero users |
Administrator accounts that are not configured to disallow delegation can be delegated and taken control of by an adversary.
Remediation:
To resolve vulnerability, ensure that administrator accounts are configured so that the "This account is sensitive and cannot be delegated" option is enabled or the accounts are added to the Protected Users group. |
User accounts in scope which have "This account is sensitive and cannot be delegated" disabled and are not members of the “Protected Users” group |
| Users Password Never Expires status |
Name:
Non-Tier Zero user accounts configured for Password Never Expires
Default scope:
All except Tier Zero users |
User accounts with passwords that are not cycled regularly are more susceptible to brute force password cracking attempts. Accounts that are configured to never require a password change should be remediated accordingly.
Remediation:
To resolve vulnerability, on the user properties Account tab, ensure the “Password never expires” option is unchecked. |
User accounts in scope that have “Password Never Expires” enabled |
|
Name:
Tier Zero user accounts configured for Password Never Expires
Default scope:
Tier Zero users |
Administrative accounts with passwords that are not cycled regularly are more susceptible to brute force password cracking attempts. Accounts that are configured to never require a password change should be remediated accordingly.
Remediation:
To resolve vulnerability, on the user Properties Account tab, make sure Password never expires is unchecked. |
|
| Protected Users group membership status |
Name:
Protected Users group is not being used
Default scope:
Tier Zero users |
The Protected Users group should be used to protect Tier Zero user accounts from attacks to steal their credentials. If the group is not in use, Tier Zero accounts are exposed to possible credential theft.
Remediation:
Members of the Protected Users group are blocked from using NTLM authentication. Therefore, do not add Tier Zero users to the Protected Users group if they require access to resources that require NTLM to authenticate. In addition, accounts for services and computers should never be members of the Protected Users group as it will cause authentication to fail.
To resolve this vulnerability, consider adding any Tier Zero account that does not require NTLM and is not a service account to the Protected Users group. |
User accounts in scope that are not members of the “Protected Users” group |
| Account last used |
Name:
Enabled Tier Zero user accounts that are inactive
Default scope:
Tier Zero users |
The number of Tier Zero accounts in a domain should be limited and closely monitored. Tier Zero accounts that are not regularly used are ripe targets for being compromised without detection, allowing an adversary more time to perform reconnaissance in the environment.
Remediation:
After inactive accounts are identified, it is recommended to disable those user accounts, wait several weeks, and then delete the accounts if no issues have been reported. |
Accounts in scope that were last used more than 90 days ago
NOTE: The number of days is editable. |
|
Name:
Tier Zero computers that have not recently authenticated to the domain
Default scope:
Tier Zero computers |
Tier Zero computers such as domain controllers will authenticate with the domain regularly. Domain controllers that are not authenticating and offline are susceptible to having password hashes stolen or used to introduce nefarious changes to the directory.
Remediation:
Tier Zero computers that are offline for extended periods of time should be investigated. Domain controllers that are out of sync with the domain over 30 days should be reinstalled or removed. |
Accounts in scope that were last used more than 30 days ago
NOTE: The number of days is editable. |
|
Domain controller SMBv1 protocol status
|
|
NOTE: For vulnerabilities that use this template, the hybrid agent service account must be a member of the Domain Admins group. | |
Name:
Domain Controller is running SMBv1 protocol
Default scope:
N/A |
The SMBv1 protocol supports legacy insecure authentication protocols. If running, it can allow an adversary to access a domain controller and harvest credentials or execute commands.
Remediation:
Disable the SMBv1 protocol on the impacted domain controllers. |
Computers in scope that have the SMBv1 protocol enabled |
|
Domain controller Print Spooler status
|
|
NOTE: For vulnerabilities that use this template, the hybrid agent service account must be a member of the Domain Admins group. | |
Name:
Printer Spooler service is enabled on a domain controller
Default scope:
N/A |
If an account has unconstrained delegation configured over the Printer Spooler service on a domain controller, an adversary can use that attack path to gain access to the domain controller and leverage the Printer Spooler service vulnerability to remotely execute code or obtain the password hashes contained on the domain controller.
Remediation:
Disable the Printer Spooler service on all domain controllers. |
Domain controller that has the Print Spooler service enabled |
| Group Policy "Store passwords using reversible encryption" setting |
Name:
Group Policy allows reversible passwords
Default scope:
All Group Policies |
Group Policies containing reversible passwords are an attractive target as those passwords can be easily decrypted and used to elevate an adversary's privileges.
Remediation:
Configure the "Store passwords using reversible encryption" setting located in “Computer Configuration - Policies - Windows Settings - Security Settings - Account Policies - Password Policy” section of the Group Policy to “disabled”. There are a couple of use cases where this setting would be enabled: Challenge Handshake Authentication Protocol (CHAP) for remote access or Internet Authentication Services (IAS), Internet Information Services (IIS) Digest Authentication Disabling this setting could break these applications. If this is needed for backwards compatibility the recommendation is to apply this to a single user or smallest subset of users vs the full domain. |
Group Policy objects in scope that have "Store passwords using reversible encryption" enabled |
| Domain "Replicating Directory Changes All" and "Replicating Directory Changes" delegation |
Name:
Non-Tier Zero accounts can steal password hashes (DCSync)
Default scope:
All except Tier Zero accounts |
If non-Tier Zero accounts have the "Replicating Directory Changes All" and "Replicating Directory Changes" permissions, they can impersonate a domain controller and receive a replicated copy of the Active Directory database that will allow them to steal password hashes.
Remediation:
These delegations should be removed unless there is a compelling reason for their existence. |
Domain has "Replicating Changes All" and "Replicating Directory Changes" set to Allow for any accounts in scope |
| Object read-only domain controller msDS-NeverRevealGroup status |
Name:
Protected group credentials exposed on read-only domain controllers
Default scope:
- Administrators
- Account Operators
- Backup Operators
- Denied RODC Password Replication Group
- Server Operators
|
Read-only domain controllers (RODCs) should be configured so that Tier Zero user and group credentials are not replicated. If Tier Zero passwords are replicated, an adversary who gains access to the RODC can harvest the credentials and elevate their privileges.
Remediation:
Ensure the built-in groups Administrators, Account Operators, Backup Operators, Denied RODC Password Replication Group, and Server Operators are set to “Deny” on the Password Replication Policy tab of the read-only domain controller in Active Directory Users and Computers. |
Objects in scope are not listed in the read-only domain controller "msDS-NeverRevealGroup" attribute |
| RODC password replication policy |
Name:
Tier Zero account token can be stolen from a read-only domain controller
Default scope:
All groups except Allowed RODC Password Replication
|
Read-only domain controllers (RODCs) should be configured so that Tier Zero user and group credentials are not replicated. If Tier Zero passwords are replicated, an adversary who gains access to the RODC can harvest the credentials and elevate their privileges.
Remediation:
Remove the account from the msDS-RevealOnDemandGroup attribute. Locate the account on the Properties - Password Replication Policy tab of read-only domain controller in Active Directory Users and Computers and either remove the account or change the setting to Deny. |
Objects in scope are listed in the read-only domain controller “msDS-RevealOnDemandGroup” attribute |
| Account password last changed |
Name:
Managed and Group Managed Service accounts that have not cycled their password recently
Default scope:
All Service Accounts |
Managed Service Accounts (MSA) and Group Managed Service accounts (gMSA) that have not had their passwords cycled recently could indicate they've been compromised.
Remediation:
The reason that prevented the managed service account from updating their password the default 30 days should be investigated. Such as verifying if the msDS-ManagedPasswordInterval attribute on the service account is set to a value greater than 30. |
Accounts in scope that have not updated its password within last 30 days.
NOTE: The number of days is editable. |
| Computer account "ms-Msc-AdmPwd" attribute permissions |
Name:
Non-Tier Zero accounts with Microsoft Local Administrator Password (LAPS) access
Default scope:
All except Tier Zero Users, Groups, and Computers
|
An incorrectly configured Microsoft Local Administrator Password (LAPS) can expose the local Administrator password (ms-Mcs-AdmPwd attribute) for an adversary to steal. Confidential attributes such as ms-Mcs-AdmPwd can only be viewed by accounts with “Full control” (GenericAll) or "All extended rights" (ExtendedRight) on a computer object, and unlike other attributes, is not accessible by Authenticated Users.
Remediation:
Review accounts that can view the “ms-Mcs-AdmPwd” attribute of a computer account and determine if the access is required. If not required, remove the granted permission. |
Computer "ms-Mcs-AdmPwd" attribute has GenericAll or ExtendedRight set for any account in scope |
| User permission on Resource-Based Constrained Delegation settings for KRBTGT |
Non-Tier Zero user accounts with write permissions over Resource-Based Constrained Delegation on the KRBTGT account
Default scope:
All except Tier Zero users |
Non-Tier Zero user accounts that have the permission to write Resource-Based Constrained Delegation (RBCD) on the KRBTGT account can allow an adversary to impersonate any user and take control of the KRBTGT account, and from there, the entire domain.
Remediation:
To resolve vulnerability, review the KRBTGT object security to determine if non-Tier Zero user accounts should have Write permissions in the Resource-Based Constrained Delegation attribute. If not required, remove them. |
Users in scope that have Allow Write permission on Resource-Based Constrained Delegation settings for KRBTGT account |
| Tier Zero computers permission granted on Resource-Based Constrained Delegation |
Name:
Tier Zero computer that has write permissions on Resource-Based Constrained Delegation granted to a non-Tier Zero account
Default scope:
All except Tier Zero objects
|
Non-Tier Zero accounts that have the permission to write Resource-Based Constrained Delegation (RBCD) on a Tier Zero computer such as a domain controller can allow an adversary to impersonate any user and take control of the DC.
Remediation:
To resolve vulnerability, review the Tier Zero computer security to determine if non-Tier Zero user accounts should have Write permissions in the Resource-Based Constrained Delegation attribute. If not required, remove Write permissions on the attribute.
|
Tier Zero computers that have accounts in scope with Allow Write permission on Resource-Based Constrained Delegation |
|
gMSA root key access
|
|
NOTE: For vulnerabilities that use this template, the hybrid agent service account must be a member of the Domain Admins or Enterprise Admins group. | |
Name:
Non-Tier Zero accounts can access the gMSA root key
Default scope:
All except Tier Zero objects
|
Non-Tier Zero accounts with access to the Group Key Distribution Services Master Root Keys could gain access to any gMSA account in the environment.
The Hybrid Agent service account requires Domain Admin or Enterprise Admin permissions to read the security details on msKds-ProvRootKey objects. Vulnerability results with zero assessed objects indicates that either no msKds-ProvRootKey objects exist in the domain or the Hybrid Agent service account does not have permissions to read the msKds-ProvRootKey objects.
Remediation:
Restrict access to the msKds-ProvRootKey objects in the domain to only Tier Zero users and groups. The default groups that have access to the objects are SYSTEM, Domain Admins, and Enterprise Admins.
|
Accounts in scope that have Allow Read or Allow Write permission for msKds-RootKeyData attribute on msKds-ProvRootKey objects |
| Write access on certificate templates |
Name:
Default scope:
All except Tier Zero users and groups and Foreign Security Principal (S-1-5-9)
|
Non-Tier Zero users with write access on certificate templates allow attackers to create illegitimate certificates for any user, which allows them to elevate their privileges and compromise the domain.
A template is misconfigured at the access control level if it has Access Control Entries (ACEs) that allow unintended, or otherwise non-Tier Zero, AD principals to edit sensitive security settings in the template.
Remediation:
Remove non-Tier Zero users from having any write access to “Certificate Templates” container in Configuration - Services - Public Key Services or any pKICertificateTemplate object in that container. |
Accounts in scope have Allow Write permissions on pKICertificateTemplate objects in the “Certificate Templates” container |
| AdminSDHolder inheritance status |
Name:
Inheritance is enabled on the AdminSDHolder container
Default scope:
N/A
|
The AdminSDHolder object is rarely modified. If inheritance is enabled on the ACL of this object, it could be the result of an adversary propagating changes in the directory that make accessing additional Tier Zero accounts easier for them.
Remediation:
On the AdminSDHolder object in the System container, open Security - Advanced, click “Disable inheritance”, and select the option to “Remove all inherited permissions from this object”. |
AdminSDHolder permission inheritance set to enabled |
| User access to gMSA password |
Name:
Non-Tier Zero users with access to gMSA password
Default scope:
All except Tier Zero users
|
Non-Tier Zero users that are members of a group that is listed in a Group Managed Service Account’s (gMSA) msDS-groupMSAMembership attribute can gain access to the password of the account and move laterally to resources it manages.
Remediation:
Unless there is a business reason, remove non-Tier Zero users from the group that is listed in the Group Managed Service Account’s (gMSA) msDS-groupMSAMembership attribute. |
Users in scope that are able to retrieve the password for a Group Managed Service Account (gMSA) |
| Domain trust Kerberos AES encryption support status |
Name:
Domain trust without Kerberos AES encryption enabled
Default scope:
All Trusted Domains
|
The setting “The other domain supports Kerberos AES Encryption” determines whether the trust supports AES encryption. Trusts that do not have the setting enabled will use RC4 encrypted Kerberos tickets which are considered significantly less secure than AES.
Remediation:
Removing the previously allowed RC4_HMAC_MD5 encryption suite may have operational impacts and must be thoroughly tested for the environment before changing.
In the Active Directory Domains and Trusts console, right-click the forest root domain, and select Properties. Select the Trusts tab, highlight the trust, and then click the Properties button. Then enable the setting "The other domain supports Kerberos AES Encryption". |
Domain trust in scope has Kerberos AES encryption support disabled |
| KRBTGT account password last changed |
Name:
Kerberos KRBTGT account password has not changed recently
Default scope:
N/A |
The KRBTGT account is a domain default account that acts as a service account for the Key Distribution Center (KDC) service. During the Kerberos Authentication process, TGTs are issued to accounts requesting access to resources. These TGTs are encrypted by cryptographic key which is derived from the password of the KRBTGT account. In many Active Directory environments, the password for the KRBTGT account has not been changed since before moving to the 2008 domain functional level. This means that the password is not AES encrypted, which can expose the account to attack and break trusts with forests that require AES encryption.
Remediation:
Microsoft does not have a specific recommendation regarding password reset frequency for the KRBTGT account other than it is that the password is reset regularly. The Security Technical Implementation Guide (STIG) recommends resetting the password every 180 days. It is also considered good practice to reset the KRBTGT password whenever a Tier Zero account leaves an organization since they may have the ability to use a ticket that was previously generated while they had access. The KRBTGT account keeps the two most recent passwords in password history. Therefore, the password should be reset twice to invalidate all tickets issued from the old KRBTGT password. When the tickets are invalidated, all machines and all applications will contact the domain controllers in the environment for new Kerberos tickets.
|
Kerberos KRBTGT account password has not been updated within the last 180 days |
| Group Policy "Allow Administrator account lockout" status |
Name:
Group Policy does not enforce built-in Administrator account lockout on all computers
Default scope:
All computers
|
In order to prevent brute force attacks, Microsoft implemented account lockouts for built-in Administrator accounts and added the ability to enforce and control the lockout behavior using the GPO setting "Allow Administrator account lockout". The lockout behavior only affects network logons, such as RDP attempts. Console logons are still allowed during the built-in Administrator account lockout period.
Computers using Windows 11, version 22H2 or setup with October 11, 2022, Windows cumulative updates pre-installed may have the Local Security Policy "Allow Administrator account lockout" setting enabled by default but older Windows OS versions that had the October 11, 2022, Windows cumulative update installed after initial setup will have the "Allow Administrator account lockout" setting not configured.
Remediation:
Configure the "Allow Administrator account lockout" setting located in "Computer Configuration - Policies - Windows Settings - Security Settings - Account Policies - Account Lockout Policy" section of the Group Policy to "Enabled".
In addition, if not already configured, the Microsoft baseline recommendation is to set "Account lockout duration" to "10 minutes", "Account lockout threshold" to "10 invalid attempts", and "Reset account lockout counter after" to “10 minutes". This will ensure accounts would be locked out after 10 failed attempts within 10 minutes and the lockout would last for 10 minutes. |
Computer objects in scope do not have an assigned group policy with "Allow Administrator account lockout" Enabled |
