AD Security Risks

Without Kerberos pre-authentication, an attacker can request Kerberos data from the domain controller and use this data to brute-force the account password via a AS-REP Roasting attack.

Potential Mitigation:
• Contiunally monitor for and prevent accounts from not requiring Kerberos pre-authentication
• Edit the property of the identified accounts by unchecking "Do not require Kerberos preauthentication"

When the SERVER_TRUST_ACCOUNT bit is set in the userAccountControl attribute of a computer object it grants that computer object the privileges of a domain controller. When a non domain controller is found with this flag set, it can be a gn of compromise that allows an attacker to authenticate to the machine and perform elevated operations, enabling privilege escalation and the ability to carry out advanced attacks such as DCSync.


Potential Mitigation:
• Regularly review and audit accounts with permissions to set Server Trust Accounts.
• Monitor and alert on suspicious activities related to trust relationships and server configurations.
• Revoke unnecessary permissions from accounts to set Server Trust Accounts.

Inactive computers often stay in the network because of weaknesses in the decommissioning process. These stale computer accounts can be used as backdoors and therefore represents a possible security breach.

Potential Mitigation:
• Regularly review and identify potential stale computers
• Create a decomissioning process to remove stale objects from your environment

To identify a duplicate account, a check is performed on the "DN" and the "sAMAccountName". When a DC detects a conflict, there is a replacement performed on the second object.

Duplicate accounts being present often means there are process failures, and they should be identified and removed.

Potential Mitigation:
• Remove any accounts identified as duplicates and are not in use

When a Windows Server 2003 DC is promoted, a pre-Windows 2000 compatibility setting can be enabled through the wizard. If it is enabled, the wizard will add "Everyone" and "Anonymous" to the pre-Windows 2000 compatible access group, and by doing so, it will authorize the domain to be queried without an account (null session).

Potential Mitigation:
• Remove the "Everyone" and "Anonymous" from the PreWin2000 group while making sure that the group "Authenticated Users" is present, then reboot each DC. Note: removing the group "Authenticated Users" (and not keep it like advised here) is an advanced recommendation quoted in the rule A-PreWin2000AuthenticatedUsers

https://msdn.microsoft.com/en-us/library/cc223672.aspx [US]STIG V-8547 - The Anonymous Logon and Everyone groups must not be members of the Pre-Windows 2000 Compatible Access group.

When multiple sites are created in a domain, networks should be declared in the domain in order to optimize processes such as DC attribution. At least one domain controller has an IP address which was not found in subnet declaration.

Potential Mitigation:
• Locate the IP address which was found as not being part of declared subnet, then add this subnet to the "Active Directory Sites" tool. If you have found IPv6 addresses and it was not expected, you should disable the IPv6 protocol on the network card.

In Active Directory, each user and computer account has a Primary Group ID (PrimaryGroupID) attribute that specifies their default group membership. By default, user accounts have a PrimaryGroupID of 513 (Domain Users), and computer accounts have 515 (Domain Computers). If an attacker manages to change the PrimaryGroupID of a user or computer account to a different group, such as Domain Admins (PrimaryGroupID: 512), the compromised account will inherit the permissions of that group. This can lead to privilege escalation and unauthorized access to sensitive resources. Accounts with non-default PrimaryGroupIDs might have unintended elevated privileges, posing a significant security risk to the organization.

Remediation:
1. Regularly audit user and computer accounts to identify those with non-default PrimaryGroupIDs.
2. Investigate any accounts with non-default PrimaryGroupIDs to determine if the change was authorized and necessary.
3. If the change was unauthorized, reset the PrimaryGroupID to the default value (513 for users, 515 for computers) and monitor for any suspicious activities.
4. Implement strict access controls and monitoring for group management, especially for sensitive groups like Domain Admins.
5. Educate administrators about the risks associated with modifying PrimaryGroupIDs and enforce policies to prevent unauthorized changes.

If disabled accounts maintain their group memberships or have not had their permissions revoked, they can pose a security risk. An attacker can gain access to a disabled privileged user account, which still has elevated permissions and can then use this account to perform malicious activities, such as stealing sensitive data or making unauthorized changes to the system, without being detected as the account appears to be inactive.

In order to reduce this risk, organizations should
1. Regularly review and remove disabled privileged accounts that are no longer needed.
2. Implement a process to promptly revoke all permissions and group memberships from privileged accounts upon disabling them.
3. Monitor and alert on any activity from disabled accounts, as this could indicate a potential attack.
4. Implement strong password policies and multi-factor authentication (MFA) for all privileged accounts to reduce the risk of unauthorized access.
5. Conduct periodic access reviews to ensure that only authorized users have access to privileged accounts and that their permissions align with their current roles and responsibilities.

In Active Directory, a ServicePrincipalName (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. If user accounts have SPNs defined, it can make them vulnerable to certain attacks.

If an attacker compromises the password hash of an account with an SPN, they can use Kerberoasting techniques to request Kerberos service tickets for that account. They can then crack the password offline, potentially gaining access to the user's credentials. The potential damage and lateral movement capabilities would be more contained for non-privileged users than for privileged users, like Domain Admins, but it is still important to manage and secure non-privileged accounts.

Remediation:
1. Regularly audit your accounts to ensure they don't have unnecessary SPNs defined.
2. Remove any SPNs from accounts that don't specifically require them for their intended service.
3. Implement Managed Service Accounts (MSAs) or Group Managed Service Accounts (gMSAs) for services.

User accounts that are no longer actively used but are left enabled can be exploited by attackers. Stale accounts often have broad permissions that are no longer appropriate, and if the account's password were to be compromised, an attacker could use it to gain unauthorized access to the domain. This type of compromise is less likely to be noticed for inactive accounts.

Remediation:
1. Regularly review AD user accounts to identify those that have been inactive for an extended period (e.g., 30-90 days).
2. Disable or delete stale user accounts that are no longer needed.
3. Implement an automated process to detect and remove stale accounts on an ongoing basis.

The krbtgt account is a special account in Active Directory that is used to encrypt and sign Kerberos tickets. If an attacker were to compromise the krbtgt account password, they could create valid Kerberos tickets, impersonate any user, and gain unauthorized access to network resources.

Remediation:
• Regularly review krbtgt accounts to identify those that have not had their password changed for an extended period (e.g., 180 days).
• Apply strict controls for enforcing regular password updates for krbtgt accounts

In an Active Directory environment, if the password for a computer account hasn't been changed for over 90 days, this presents a security risk. An attacker might exploit these stale computer account passwords to gain unauthorized access to the network and resources.

An attacker could use brute-force attacks to guess the computer account password and gain access. The attacker could then use the compromised computer account to perform malicious activities, such as spreading malware or moving laterally through the network, escalating privilege, to gain access to network resources or take control of the entire domain.

Remediation:
1. Ensure that computer account passwords are changed at least every 90 days, in line with your organization's security policy.

2. Configure Group Policy to enforce regular password changes for computer accounts.

3. Set up monitoring and alerting systems to identify computer accounts with passwords older than the defined threshold.

4. Regularly audit and remove inactive or stale computer accounts from Active Directory to minimize the attack surface.

The built-in guest account is a default account in Active Directory that allows users to access network resources without having their own user account. When enabled, this account can pose a significant security because it allows anyone to connect to the network anonymously without leaving a trace and could allow an attacker to escalate privilege to gain unauthorized access to resources or to perform further malicious attacks.

Remediation:
1. Ensure that the guest account is disabled in Active Directory. This can be done through Group Policy or by directly modifying the account settings.
2.Regularly review your Active Directory configuration to ensure that the guest account remains disabled and no other unnecessary accounts are enabled.
3.Enable logging and monitoring of account activities to detect and investigate any suspicious behavior or unauthorized access attempts.

Newly created AD objects might be used for malicious purposes, such as:
• Gaining unauthorized access to resources
• Escalating privileges
• Conducting reconnaissance
• Establishing persistence within the network

Mitigation:
1. Regularly review and monitor newly created AD objects using tools like PowerShell or third-party security solutions.
2. Implement strict access controls and approval processes for creating new AD objects.
3. Enforce strong password policies and enable multi-factor authentication (MFA) for all user accounts.
7. Regularly audit and remove unused or stale AD objects to maintain a clean and secure AD environment.

Old passwords pose a significant security risk to an organization's Active Directory environment. They are more likely to be weak, reused, or previously compromised, making them easier targets for attackers. If an attacker gains access to an administrator account with an old password, they can use the account's elevated privileges to move laterally, access sensitive data, and cause extensive damage.

Mitigation:
• Set a maximum password age policy for AD accounts, forcing regular password changes.
• Require users to use complex passwords that meet minimum length and complexity requirements.
• Implement MFA for all administrator accounts to provide an additional layer of security beyond passwords.

At install time, the Exchange Windows Permissions universal security group (USG) was granted the ability to modify the members attribute, the ability to change and reset passwords, and the ability to modify the permissions of any object protected by the AdminSDHolder role. This security group includes all the Exchange servers. As a consequence, a malicious administrator could elevate their privileges on one of the servers and thus gain control of the Active Directory forest. Newest versions of Exchange do not introduce this security vulnerability.

Potential Mitigation:
• Regularly review the ACL of the AdminSDHolder container to ensure only the required ACEs exist to be propogated to privileged objects
• Monitor changes to the AdminSDHolder ACL to ensure only required and intended changes occur to the permissions

Users with replication permissions are capable of replicating password hashes with tools such as Mimikatz. Ensuring only the neccesary active directory objects that require replication permissions are capable of performing that action can significantly reduce the attack surface for potential attackers. Objects that may require replication permissions can include service accounts for applications that perform replication and Azure Entra ID sync accounts.

Potential Mitigation:
• Regularly review and audit accounts with replication permissions to ensure they are limited to only necessary users or groups.
• Implement the principle of least privilege, granting replication permissions only to accounts that absolutely require them.
• Monitor and alert on suspicious replication activities, such as replication requests from unauthorized sources or during unusual hours.

The Protected Users group is a special group, which is a very effective mitigation solution to counter attacks using credential theft starting with Windows 8.1.

The Protected Users group is automatically created when the PDC (primary DC) emulator role is transferred to Windows Server 2012 R2 or newer domain controller. The group is then automatically replicated to all other domain controllers.

When a computer is joined to a domain, a DNS record is created in the Dns Zone to allow the computer to update its DNS settings. By design, Microsoft choose to grant to the group Authenticated Users (aka every computers and users) the right to create DNS records. Once created, only the owner keeps the right to edit the new object. The vulnerability is that specific DNS records can be created to perform man-in-the-middle attacks. One example is to create a wildcard record (a record with the name "*"), a failover DNS record or anticipating the creation of a DNS record with the right permissions.

This rule is considered "informative" because the default configuration where Authenticated Users can create DNS records is considered safe. The reason for this classification is that no exploitation of that vulnerability has been reported. The proposed enhancement is to replace the identity who has been granted the right to create DNS Records (permission CreateChild) from Authenticated Users to Domain Computers. To perform this change, you have to edit the permission of the DNSZone whose object is located in the container CN=MicrosoftDNS,DC=DomainDnsZones. It should be noticed that if there is a privilege escalation on a computer, an attacker can impersonate the computer account and bypass this mitigation.

Potential Mitigation:
Create the DNS records manually as part as the domain join process and to revoke the permission granted to Authenticated Users.

The recovery mode is a special mode allowing an admin to fix an issue preventing the computer to boot. By pressing F8 in the short time span allowed, the computer boots with just a simple command line. Usually, the administrator password is requested to avoid that people having physical access get control of it. It can typically be done by creating a new user account and add this account as member of the administrators group. This rule checks if there are GPOs which disable this password prompt.

Locate the GPO specified in Details and turn off the setting "Recovery console: Allow automatic administrative logon" The setting is located in : Computer configuration -> Policies -> Windows Settings ->Security Settings -> Local Policies -> Security Options. As an alternative, the file GptTmpl.inf can be manually edited.

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon

When Exchange is installed, a set of permissions is modified to allow a deep Windows integration. A dependency analysis has shown that the permissions, that Exchange has set, introduced a possibility for privilege escalation. The most basic exploitation is that a member of the group Exchange Windows Permissions can modify the security permission of the domain, granting itself the right Ds-Replication-Get-Changes-All. This right allows the account to perform an attack named DCSync, which retrieves the hash of the krbtgt account. With this hash the attacker can then create a golden ticket and impersonate silently any user of the domain, including domain admins.

Potential Mitigation:
• Edit the root domain security descriptor.
• Identify the ACE giving the right ModifyDACL to the principal Exchange Windows Permissions.
• Go to the advanced settings and set the inheritance to Inherit Only.

Login scripts are scripts executed when a user logs into a system, typically used in environments where group policies or automated tasks need to be applied consistently across users. These scripts can perform a variety of tasks, such as mapping network drives, updating software, setting environment variables, or enforcing specific settings. Since these scripts run with the privileges of the logged-in user, they hold significant power over the user's environment and actions during their session.
When Open Access groups like "Authenticated Users," or "Everyone," or similar broadly-defined security principals have permissions to modify login scripts, it introduces a significant security risk. Specifically, these permissions allow any user who falls within these groups to alter the login script. Since login scripts are executed during the login process, any malicious modifications can result in the execution of arbitrary code with the privileges of the user logging in. If a privileged user, such as an administrator, logs in, the malicious code can run with elevated permissions, leading to a complete system compromise.

Potential Mitigation:
• Ensure that only trusted administrators have permissions to modify login scripts. Remove or severely limit access for groups like "Authenticated Users" or "Everyone" to prevent unauthorized modifications.
• Regularly audit the permissions on login scripts and other critical configuration files to ensure that only authorized users have access. Use tools that can automatically detect and report on insecure permissions.
• Implement monitoring and alerting mechanisms to detect when login scripts are modified. This can include file integrity monitoring (FIM) solutions that alert administrators whenever a script is altered.
• If possible, use code-signing to ensure that only verified and trusted scripts are executed. This adds an additional layer of security, making it more difficult for attackers to insert unauthorized scripts.

By default, a basic user can register up to 10 computers within the domain. This default configuration represents a security issue as basic users shouldn't be able to create such accounts and this task should be handled by administrators. This checks the GPO for SeMachineAccountPrivilege assignment which can be used to restrict the impact of the key ms-DS-MachineAccountQuota.

To solve the issue, limit the number of extra computers that can be registered by a basic user. It can be reduced by modifying the value of ms-DS-MachineAccountQuota to zero (0). Another solution can be to remove the "Authenticated Users" group in the domain controllers policy altogether. Do note, that if you need to set delegation to an account, so it can add computers to the domain, it can be done through 2 methods: Delegation in the OU or by assigning the SeMachineAccountPrivilege to a special group

Read-Only Domain Controllers (RODCs) are a special type of domain controller designed to be deployed in locations where physical security cannot be guaranteed, such as branch offices. To limit the security risks associated with these deployments, certain high-privilege accounts and groups are, by default, added to the Denied RODC Password Replication Group. This ensures that their passwords are not cached on the RODC, reducing the potential impact if the RODC is compromised.
When default members, such as highly privileged accounts (e.g., Domain Admins, Enterprise Admins), are removed from the Denied RODC Password Replication Group, their passwords can be cached on the RODC. An attacker who gains access to an RODC can exploit cached credentials in several ways:

• Credential Dumping: Tools like Mimikatz can be used to dump cached credentials from the RODC, including passwords of highly privileged accounts if they were removed from the denied group.
• Lateral Movement: With the credentials of a high-privilege account, an attacker can move laterally within the network, gaining access to other resources and potentially compromising the entire domain.
• Domain Compromise: By exploiting these cached credentials, especially of domain or enterprise admins, an attacker can escalate privileges and take control of the domain.

Potential Mitigation:
• Review and Restore Default Settings: Regularly review the membership of the Denied RODC Password Replication Group and ensure that all default members are included. This includes high-privilege groups like Domain Admins, Enterprise Admins, and the krbtgt account.
• Audit Password Replication Policies: Use tools and scripts to audit and enforce proper password replication policies on all RODCs. Ensure that only accounts that need to authenticate locally are allowed to have their credentials cached.
• Monitor RODC Access: Implement monitoring and alerting for any unusual access or changes to RODC configurations. This helps in detecting potential unauthorized changes to replication policies or cached credentials.
• Regularly Rotate Credentials: Periodically change the passwords of highly privileged accounts and the krbtgt account, especially if there is any suspicion of compromise.

Allowed RODC Password Replication Group is a security group in AD that controls which user and computer accounts can have their password hashes replicated to the RODC. Accounts in this group can have their password hashes stored on the RODC, allowing authentication in scenarios where the connection to a writable Domain Controller (DC) might not be available.

If an RODC is compromised, an attacker can extract the password hashes of these accounts, potentially allowing offline password-cracking attacks. This is particularly concerning for privileged accounts.

If the compromised account is a privileged account, such as a member of the Domain Admins group, the attacker could leverage the cracked password to escalate their privileges within the domain. This could lead to a full domain compromise.

Mitigation Strategies:
• Limit Membership in the Allowed RODC Password Replication Group: Restrict membership to only the accounts that absolutely need their passwords replicated to the RODC. Ideally, this group should not include any privileged accounts (e.g., Domain Admins).
• Implement Strong Password Policies: Ensure that strong, complex passwords are enforced, making it more difficult for attackers to crack password hashes. Implement multi-factor authentication (MFA) wherever possible.
• Regularly Rotate Credentials: Regularly change passwords, especially for accounts with privileged access. This limits the window of opportunity for an attacker if credentials are compromised.
• Monitor and Audit RODC Access: Continuously monitor RODCs for any signs of compromise or unusual activity. Implement robust logging and alerting for any suspicious actions involving RODCs.
• Patch and Update Systems: Ensure that all systems, including RODCs, are regularly patched and updated to protect against known vulnerabilities.
• Disable Cached Credentials on RODCs: If possible, disable the caching of credentials on RODCs, or at least limit the scope of accounts whose credentials are cached.

The msDS-NeverRevealGroup attribute is used to define a group of accounts whose password hashes should never be replicated to Read-Only Domain Controllers (RODCs). This is a critical security measure to ensure that certain privileged accounts, such as those with high administrative rights, are not exposed on RODCs, which may reside in less secure locations.

If the msDS-NeverRevealGroup attribute is not properly configured, or expected groups (like Administrators, Server Operators, Account Operators, Backup Operators, and Denied RODC Password Replication Group) are missing, the password hashes for these highly privileged accounts could be replicated to RODCs. This poses a significant security risk if an RODC is compromised, as attackers could extract these password hashes and attempt to crack them.

An attacker who gains access to an RODC could use tools to dump all cached password hashes. If privileged accounts' hashes are stored on the RODC due to misconfiguration, these can be targeted for cracking. If the attacker successfully cracks the password of a privileged account, they could escalate their privileges, gaining broader access to the network.

Potential Mitigation:
• Ensure Proper Configuration of msDS-NeverRevealGroup: Verify that all critical groups, such as Administrators, Server Operators, Account Operators, Backup Operators, and the Denied RODC Password Replication Group, are included in the msDS-NeverRevealGroup attribute.
• Regularly audit the configuration of msDS-NeverRevealGroup to ensure that it includes all necessary groups and that no unauthorized changes have been made.
• Implement monitoring and alerting mechanisms to detect any unusual activities on RODCs, especially related to password replication and account access.
• Limit physical and network access to RODCs, especially in less secure locations, to reduce the risk of compromise.

The DoListObject feature in Active Directory allows administrators to restrict visibility between objects in different Organizational Units (OUs) by using a special Access Control List (ACL) known as RIGHT_DS_LIST_OBJECT. This ACL can be configured to prevent accounts in one OU from viewing objects in another OU. If the RIGHT_DS_LIST_OBJECT is not configured correctly, users or attackers might be able to enumerate or access objects in OUs they should not have visibility into. This could expose sensitive information or allow reconnaissance activities.

Potential Mitigation:
• Ensure that RIGHT_DS_LIST_OBJECT is correctly configured to enforce proper isolation between OUs. Regularly review and audit ACL settings to prevent unauthorized visibility.
• If isolation is not necessary, consider reverting the DoListObject behavior to its default by adjusting the dsHeuristics setting to "0". This can reduce the complexity and potential misconfigurations.
• Monitoring and Auditing: Regularly monitor and audit access logs to detect any unauthorized attempts to view or access objects in different OUs.

In Active Directory, group membership is stored on the "members" attribute and on the "primarygroupid" attribute. The default primary group value is "Domain Users" for the users, "Domain Computers" for the computers and "Domain Controllers" for the domain controllers. The primarygroupid contains the RID (last digits of a SID) of the group targeted. An attacker could exploit the "primaryGroupID" to hide memberships in sensitive groups. Since this attribute is not often reviewed, these memberships could remain undetected, leading to privilege escalation or unauthorized access.

Potential Mitigation:
• Implement regular audits of the "primaryGroupID" attribute across all accounts to ensure it aligns with expected group memberships.
• Ensure that the "primaryGroupID" is set to its default value unless there is a strong, justified reason for an exception. Use scripts to regularly check for deviations from this standard.
• Enable monitoring and alerts for changes to the "primaryGroupID" attribute to detect potential unauthorized modifications.
• Limit who can modify the "primaryGroupID" to only a few trusted administrators.

In Active Directory, group membership is stored on the "members" attribute and on the "primarygroupid" attribute. The default primary group value is "Domain Users" for the users, "Domain Computers" for the computers and "Domain Controllers" for the domain controllers. The primarygroupid contains the RID (last digits of a SID) of the group targeted. This rule can also be triggered if one domain controller is not in the default container (named "Domain Controllers" and located at the root), which is not a recommended practice. Moving a domain controller outside its default container might prevent it from receiving critical security policies, making it vulnerable to attacks.

Potential Mitigation:
• Ensure the "primaryGroupID" is set to default values unless absolutely necessary. Regularly audit this attribute.
• Verify that all domain controllers reside in the "Domain Controllers" container to ensure proper policy application.
• Implement monitoring for changes to the "primaryGroupID" and the location of domain controllers to detect potential malicious activities.
• Limit permissions to modify the "primaryGroupID" to a select group of administrators to prevent unauthorized changes.

In Active Directory, certain rights such as REANIMATE_TOMBSTONE, UNEXPIRE_PASSWORD, and SID_HISTORY provide powerful capabilities to manipulate objects, passwords, and security identifiers (SIDs). These rights are typically reserved for highly privileged users because they can be exploited to undermine the security of the domain. These rights can be abused to reanimate deleted objects, bypass password expirations, or create alternate identities, enabling attackers to maintain persistent, stealthy access.

Exploitation by Attackers
• Undelete Objects (REANIMATE_TOMBSTONE): Attackers can restore deleted objects, such as user accounts, and use them to regain access to the environment.
• Undo Password Expiration (UNEXPIRE_PASSWORD): Attackers could prevent a compromised account's password from expiring, maintaining access for an extended period.
• Create Alternate Identities (SID_HISTORY): Attackers could use this right to impersonate other users by manipulating their SIDs, allowing them to escalate privileges or access sensitive resources.

Potential Mitigation:
• Restrict Privileges: Limit the assignment of REANIMATE_TOMBSTONE, UNEXPIRE_PASSWORD, and SID_HISTORY rights to only essential, highly trusted administrators.
• Audit and Review: Regularly audit and review the use of these rights to ensure they are not being misused. Investigate any suspicious delegations immediately.
• Remove Unnecessary Delegations: Unless there is a strong justification, remove these rights from accounts and groups that do not need them.
• Monitor for Abuse: Implement monitoring to detect the use of these rights, particularly in non-routine contexts.

When a delegation in Active Directory refers to an account that cannot be translated to an NT account, it often indicates that the delegation is linked to an account from another domain or a deleted user account. This situation can pose security risks because the delegations might still grant permissions that could be exploited. Attackers could identify and use orphaned or cross-domain delegations to access sensitive resources or escalate privileges.

Potential Mitigation:
• Remove Unnecessary Delegations: If a delegation cannot be traced to a valid account, remove it to eliminate potential risks.
• Audit and Monitor: Regularly audit delegations and monitor for any delegations linked to accounts that cannot be translated, indicating possible risks.
• Cross-Domain Review: Review cross-domain trust relationships and delegations to ensure they are necessary and secure.

Delegating control over an Organizational Unit (OU) in Active Directory involves granting specific permissions to users or groups. However, misconfigurations can occur, particularly when broad permissions are granted to groups like "Everyone" or "Authenticated Users." Such configurations can inadvertently provide more access than intended, posing significant security risks such as unauthorized access and the opportunity to exploit these permissions to escalate privileges within the domain.

Potential Mitigation:
• Review and Restrict Delegations: Regularly review delegated permissions and remove overly broad access rights. Assign permissions only to specific groups that require them.
• Apply the principle of least privilege by ensuring that users have only the minimum permissions necessary to perform their tasks.
• Continuously audit and monitor changes to OU delegations to detect and respond to any misconfigurations promptly.

In Active Directory environments, the ability for helpdesk personnel to reset user passwords can create indirect access paths to critical systems, such as key servers or Domain Admin accounts. Attackers can map out and use these indirect paths to gain unauthorized access to high-value targets within the domain.

Potential Mitigation:
• Analyze and restrict write permissions on key objects and servers to minimize risk.
• Ensure helpdesk personnel have the least privilege necessary to perform their duties, and segregate duties to limit their ability to access critical systems.
• Use tools like Netwrix Access Analyzer to identify shadow access and eliminate unnecessary permissions.

In Active Directory, certain groups like Anonymous, Everyone, Authenticated Users, Domain Users, Domain Computers, and Builtin can be inadvertently included in control paths due to overly broad permission settings. When these groups are granted write permissions on critical objects, it creates significant security risks, as these permissions can be exploited by any user or computer in the domain. Attackers can use tools like BloodHound to identify and exploit control paths where these broad groups have write permissions, gaining unauthorized access to critical resources.

Potential Mitigation:
• Review and restrict write permissions granted to groups like Everyone, Authenticated Users, and other broad groups to minimize the risk of exploitation.
• Ensure permissions are assigned only to specific, necessary groups, avoiding the inclusion of broad groups like Everyone or Domain Users in critical control paths.
• Use tools like Netwrix Enterprise Auditor to identify shadow access involving these broad groups and correct any overly permissive configurations.

Stale Users with Group Membership Permissions is a security risk that occurs when user accounts that are no longer active retain their ability to modify group memberships within Active Directory. These accounts present an adversary the opportunity to exploit these permissions to escalate their access and compromise the organization's systems and data.

To mitigate this risk:
1. Regularly review and audit user accounts to identify stale or inactive accounts.
2. Implement a process to promptly disable or remove stale accounts, revoking their group memberships and permissions including permissions on AD Objects.
3. Use automated tools or scripts to detect and alert on stale accounts with sensitive group memberships and permissions.
4. Implement a least privilege model, ensuring that users only have the permissions necessary for their roles.

By proactively managing stale user accounts and their group memberships and permissions, organizations can reduce the risk of unauthorized access and limit the potential impact of a compromised account.

Therefore, an adversary who modifies the AdminSDHolder container can establish a path of shadow administration and a means to regain administrative access to Active Directory.

Potential Mitigation:
• Routinely audit AdminSDHolder permissions for unauthorized or unnecessary permissions.
• Do not allow users to possess administrative privileges across security boundaries. For example, an adversary who initially compromises a workstation should not be able to escalate privileges to move from the workstation to a server or domain controller. Eliminating these pathways to privilege escalation is essential.
• Aggressively enforce the principle of least privilege.

To learn more about this vulnerability, visit the attack catalog page: https://www.netwrix.com/adminsdholder_modification_ad_persistence.html and this blog post: https://blog.netwrix.com/2023/06/16/adminsdholder/

Users with password reset privileges could abuse this capability to gain unauthorized access to other user accounts. If an attacker compromises an account with password reset rights, they can use it to reset passwords of high-privileged accounts, escalating their access within the organization.

Potential Mitigation:
• Regularly review and limit the number of users with password reset privileges. Assign this permission only to trusted individuals who require it for their roles.
• Implement Multi-Factor Authentication (MFA) for all accounts, especially those with password reset capabilities, to prevent unauthorized access even if passwords are compromised.
• Enable auditing and monitoring of password reset activities to detect and alert on suspicious password changes.

Directly granting domain users with permissions to modify objects within active directory violates the principle of least privilege and can lead to unauthorized changes or misuse of privileges.

Potential Mitigation:
1. Regularly audit and review the permissions assigned to domain users.
2. Apply the principle of least privilege. Remove unnecessary direct permissions from domain users. Ensure that only authorized administrators have the required permissions to manage critical objects.
3. Use role-based access control (RBAC): Implement RBAC to assign permissions based on job roles and responsibilities.
4. Use PAM solutions to control and monitor privileged access to sensitive objects. Require approval workflows and logging for privileged actions.
5. Regularly review and update permissions. Conduct periodic reviews of permissions to ensure they remain aligned with job roles and responsibilities. Remove permissions promptly when users change roles or leave the organization.

By following these steps, organizations can mitigate the risks associated with domain users having direct permissions and maintain a more secure Active Directory environment.

In an Active Directory environment, if unprivileged users are allowed to join computers to the domain, it can lead to a security risk. If an attacker were to gain access to an account like this they could add new computer accounts to the domain that could be used to maintain a foothold in the network, bypass security controls, or impersonate trusted machines to gain access to sensitive resources or deploy malicious software.

Remediation:
• Regularly review user permissions and ensure that only necessary users have permission to add computer accounts, following the principle of least privilege.
• Enable monitoring of changes in Active Directory and set up alerts for unusual activity, such as creation of a large number of new computer accounts or computer accounts being added by users who typicallly don't perform such actions.
• Use Role Based Access control (RBAC) to ensure only authorized administrative roles have ability to add computer accounts

AdminSDHolder is a container that exists in Active Directory and is used to enforce security settings for certain high-privilege groups such as Domain Admins, Administrators, Enterprise Admins and Schema Admins. The Access Control List (ACL) of the AdminSDHolder object is used as a template to copy permissions to these protected groups. A process called SDProp runs every 60 minutes by default and applies the ACL of the AdminSDHolder object to all protected groups and their members. Since this ACL is very restrictive by design, this process strengthens the security in your Active Directory domain. By modifying the dsHeuristics attribute, this protection can be disabled for a specific set of groups using the 16th value (dwAdminSDExMask).

Remediation:
• Locate the dsHeuristics attribute in the configuration partition on the object Configuration/Services/Windows NT/Directory Service
• Edit the attribute and set the 16th character to zero (0)

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/50097362-ede5-40fa-973e-8d65e782e384

By default, only Domain Admins and Enterprise Admins can link GPOs to the domain. However, if the "Link GPOs" permission is delegated to other users or groups at the domain level, it can lead to a security risk.
If an attacker or a compromised account with delegated access to GPOs linked onthe domain level, they can create and link malicious GPOs to the entire domain. Using these newly created GPOs, they can be used to distribute malware, change security settings, or grant unauthorized access to sensitive resources.

Mitigation:
• Regularly review and audit the delegated access to GPO linked at the domain level.
• Ensure that only trusted and authorized users or groups have the "Link GPOs" permission.
• Implement the principle of least privilege, granting permissions only when necessary.
• Monitor and alert on any suspicious GPO linking activities.
• Regularly review and update GPOs to ensure they align with the organization's security policies.

Group Policy Objects (GPOs) are used to manage and enforce settings across the domain and can be linked to Organizational Units (OUs) containing the Domain Controllers. An attacker can abuse delegated access to GPOs on domain controllers by creating a malicious GPO that could contain scripts and settings, providing control over the domain controllers when they reboot or refresh their group policy.

Mitigation:
• Audit accounts with the delegated access to GPOs linked on the Domain Controllers OU.
• Remove the "Link GPOs" permission from any unnecessary accounts or groups.
• Implement the principle of least privilege, ensuring that only the most essential and trusted accounts have the ability to link GPOs to the domain controller OU.
• Monitor and alert on changes to the domain controller OU's GPO linking permissions.

Having delegated access to GPOs linked on the AD site level can potentially lead to an attacker gaining control of all computers within that site. By linking a malicious GPO to an AD site, the attacker can deploy malicious settings, scripts, or software to all computers in the site, regardless of their domain or OU membership potentially leading to widespread compromise of the network.

Mitigation
• Limiting delegation to control access to link GPOs at the AD site level.
• Regularly audit GPO links and review the GPOs linked at the AD site level to ensure that no unauthorized or malicious GPOs are present.
• Follow best practices for GPO management, such as using GPO modeling, backing up GPOs before making changes, and using role-based access control for GPO management.
• Use monitoring tools to detect and alert on suspicious GPO changes or unusual activity related to GPOs.
5. Apply the principle of least privilege, granting only the necessary permissions to users and administrators.

To perform special operations, the operating system relies on privileges. They can be displayed by running the command: whoami /all.
• SeLoadDriverPrivilege can be used to take control of the system by loading a specifically designed driver. This procedure can be performed by low privileged users as the driver can be defined in HKCU.
• SeTcbPrivilege is the privilege used to "Act on behalf the operating system". This is the privilege reserved to the SYSTEM user. This procedure allows any user to act as SYSTEM.
• SeDebugPrivilege is the privilege used to debug program and to access any program's memory. It can be used to create a new process and set the parent process to a privileged one.
• SeRestorePrivilege grants write access for all system files and can be used to modify services and perform DLL hijacking to escalate privileges.
• SeBackupPrivilege can be used to backup the Windows registry and use third party tools for extracting local NTLM hashes.
• SeTakeOwnershipPrivilege can be used to take ownership of any object in the system including a service registry key. Then to change its ACL to define its own service running as LocalSystem.
• SeCreateTokenPrivilege can be used to create a custom token with all privileges and thus be abused like SeTcbPrivilege SeImpersonatePrivilege and SeAssignPrimaryTokenPrivilege can be abused to impersonate privileged tokens. These tokens can be retrieved by establishing security context such as Local DCOM DCE/RPC reflection.
• SeSecurityPrivilege can be used to clear the Windows Security Event Log and shrink the size so events are quickly overwritten. Also read security log and view events where the user inverted the login and its password.
• SeManageVolumePrivilege can be used to reset the security descriptor on the system volume and thus, change the inherited permissions to critical files

Advised Remediation:
• Locate the group policy object name in the details section of this finding.
• Remove the privileges assigned by editing the group policy object with the Group Policy Management console, finding the settings in Computer configuration -> Policies -> Windows Settings ->Security Settings -> Local Policies -> User Rights Assignment and removing the dangerous group.

Documentation:
https://www.romhack.io/slides/RomHack%202018%20-%20Andrea%20Pierini%20-%20whoami%20priv%20-%20show%20me%20your%20Windows%20privileges%20and%20I%20will%20lead%20you%20to%20SYSTEM.pdf
https://www.tarlogic.com/en/blog/abusing-seloaddriverprivilege-for-privilege-escalation/ https://github.com/decoder-it/psgetsystem https://twitter.com/0gtweet/status/1303427935647531018?s=20
https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/privilege-escalation-abusing-tokens

Two vulnerabilities have been reported in 2015 (MS15-011 and MS15-014) which allows a domain takeover via GPO modifications done with a man-in-the-middle attack. To mitigate these vulnerabilites, Microsoft has designed a workaround named "Hardened Paths". It forces connection settings to enforce Integrity, Mutual Authentication or Privacy. By default if this policy is empty, it will enforce Integrity and Mutual Authentication on the SYSVOL or NETLOGON shares. This rule checks if there have been any overwrite to disable this protection.

Potential Mitigation:
• Check if the Hardened Path section in the GPO, located in Computer Configuration/Policies/Administrative Templates/Network/Network Provider is set to 1. Check each value reported here and make sure that entries containing SYSVOL or NETLOGON have RequireIntegrity and RequireMutualAuthentication set to 1. In addition to that, check entries having the pattern \\DCName\* and apply the same solution.

Domain Controllers are critical components of the Active Directory. If an attacker is able to open a session, he will be able to discover insecure backup media or perform a local privilege escalation to become the DC admin and thus the AD admin.

Potential Mitigation:
• Locate the GPO specified and remove the privilege "Allow log on locally" or "Allow log on through Remote Desktop Services" to "Everyone", "Authenticated Users", "Domain Users" or "Domain Computers". The settings are located in : Computer configuration -> Policies -> Windows Settings ->Security Settings -> Local Policies -> User Rights Assignment.

When the group 'Authenticated Users', 'Everyone' or any similar groups have permission to modify a GPO, it can be abused to take control of the accounts where this GPO applies. It can potentially lead to the compromise of the domain

Potential Mitigation:
• Edit the Access Control List (ACL) of the GPO object or the directory where the items is located. Then remove any write permission given to the group.

Applications and other files can be deployed by a GPO. If an attacker can modify one of these files, they may be able to compromise the user's account.

Potential Mitigation:
• Locate the file mentioned by the GPO specified in Details and change its permissions.

DisplaySpecifier are Active Directory objects stored in the DisplaySpecifier container of the Configuration naming context. They are used to customize the user interface. Specifically the attribute adminContextMenu is used to customize administration actions, where COM objects or scripts can be called. If the script is stored outside the SYSVOL directory, it can be used to execute custom actions and it is run under the administrator context.

Potential Mitigation:
• Identify scripts leveraged by DisplaySpecifiers and properly secure them in SYSVOL

A way to collect an administrator credential is to take control of a workstation or server in the unsecured tiers and expect that an administrator will connect to it. An attack such as credential theft or Kerberos delegation is then performed. To reduce the impact of such compromise, the best practice is to isolate components (such as admins, DCs) in tiers. Typically, a domain admin should not be allowed to connect to any workstation or lower tier server but login only to perform highly privileged operations on tier 0 systems.

Potential Mitigation:
• You should add a GPO to prohibit the logon of specific groups Domain Admins and Administrators. The setting is located in Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment. Then "Deny" logon locally and "Deny" logon through Remote Desktop Services.

NTFRS is an old protocol and is considered insecure. The SYSVOL share is mainly hosted on domain controllers to host GPO files and login scripts. If the content can be modified, it can be used to grant to a hacker the control of the computers reading these configuration files. Starting in Windows Server 2019, promoting new domain controllers requires the DFS Replication (DFSR) to replicate the contents in the SYSVOL share.

Potential Mitigation:
• Migrate from NTFRS to DFS replication. To know if the setting is enabled, the following LDAP entry should be analyzed: CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System If there is any entry found, NTFRS is in use for SYSVOL replication.

It is possible that a GPO adds local membership on a workstation or server. If one is found with "Everyone" or "Authenticated Users" or "Domain Users", etc. as members. It basically means that the local Group has no restriction on who belongs to it. This represents a security risk as Local Group are supposed to have more accesses or rights. The GPO configuration is located in Computer Configuration / Policies / Windows Settings / Security Settings / Restricted Group This rule checks also the membership set in Computer Configuration / Preferences / Control Panel Settings / Local Users and group.

Potential Mitigation:
Edit the GPO and change the local group assignment or change the principle being added from the Everyone group

LM hash, or LAN Manager hash is a hash algorithm developed by Microsoft since Windows 3.1. Due to a flawed design, hashes retrieved from the network can be reverted to the clear text password in a matter of seconds.

Potential Mitigation:
• Identify the setting modified in the GPO and fix it. All security settings should be modified in the Domain GPO Editor and are located in Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / Security Options For NoLMHash the setting is located in: Network security: Do not store LAN Manager hash value on next password change For LmCompatibilityLevel the setting is located in: Network security: LAN Manager authentication level

This rule verifies if there is a GPO with the setting "Limit local account use of blank passwords to console logon only" disabled.

Potential Mitigation:
• Locate the policy having the setting "Limit local account use of blank passwords to console logon only" disabled and enabled the setting.

Coercion attacks are a cetegory of attacks that aim to force a domain controller to authenticate to an attacker controlled device so authentication information can be relayed to escalate privileges.

Attacks of this nature vary in mitigation. Some examples include:
• Applying a patch (PetitPotam)
• Disablling Services (Spooler)
• Changing configuration (RPC Filters via EDR or firewall)
• Ensuring integrity mechanisms (SMB Integrity)

This check is completed using a malformed RPC packet and if the error RPC_X_BAD_STUB_DATA (1783) is returned the interface is considered available and vulnerable even though full exploitation is not tested.

Potential Mitigation:
1. Apply Group Policy Object (GPO) - "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers":
Apply this GPO specifically to the Organizational Unit (OU) "Domain Controllers".
Caution: Enabling this GPO might impact services dependent on NTLM such as files copy Backups.
Consider setting the GPO in "Audit mode" initially to identify and assess the impact on affected services.

2. Enable RPC Filters in Windows Firewall:
Configure Windows Firewall to block specific Interface IDs associated with vulnerable RPC interfaces.
This is done using the netsh command. See the documentation links for more information.
Exercise caution: This method filters the entire interface, not specific Operation Numbers (OpNum).
Adjust exceptions for necessary services to ensure critical functionality.

3. Implement External Filters (e.g., EDR, Firewalls):
Leverage third-party solutions, such as Endpoint Detection and Response (EDR) tools or firewalls.
Notable project: rpcfirewall https://github.com/zeronetworks/rpcfirewall, offering logical filtering at the OpNum level.
Be cautious of potential impact and ensure compatibility with existing infrastructure.

NULL sessions have been disabled by default since Windows Server 2003 and Windows XP. For compatibility reasons a setting enabling them may still be active unless explicitly disabled.

This check uses MS-SAMR with a NULL connection and MS-LSAT with a well known SID to test whether access is possible. It is also possible to verify this using rpcclient -U '' target_ip_address from a kali distribution.

Kerberos Armoring was introduced in Windows Server 2012 and Windows 8. It ensures that all pre-authentication information is encrypted with more than just an accounts password which prevents all offline dictionary attacks such as AS-REP Roasting and Kerberoasting.

To enable Kerberos armoring for domain controllers, edit the GPO and go to Computer Configuration > Administrative Templates > System > KDC
then enable the policy "KDC support for claims, compound authentication and Kerberos armoring".
The policy should be set to at least "Supported".

Kerberos Armoring was introduced in Windows Server 2012 and Windows 8. It ensures that all pre-authentication information is encrypted with more than just an accounts password which prevents all offline dictionary attacks such as AS-REP Roasting and Kerberoasting.

A single domain controller failure can lead to a lack of availability of the domain if the number of servers are too low. To have minimum redundancy the domain of Domain Controllers should be at least 2.

The Recycle Bin avoids immediate deletion of objects (which can still be partially recovered by its tombstone). This lowers the administration work needed to restore. It also extends the period where traces are available when an investigation is needed.

Enabling the Active Directory recycle bin is an irreversible change.

To enable the Active Directory Recycle Bin first ensure the forest functional level is Windows Server 2008 R2 or above. This can be completed using the Active Directory PowerShell command Get-ADForest. Once confirmed the recycle bin can be enabled using the following command and replacing my.domain with your own domain name.

Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target 'my.domain'

After performing adprep /domainprep from Windows Server 2016 sources there may be an unwanted AccessControlEntry (ACE) in the DiscretionaryACL (DACL) of the targeted domain-naming-context's SecurityDescriptor (SD) that grants FullControl permission to the Enterprise Key Admins group ( SID ending with -527 ). This is s a bug in ADPREP that was fixed in Windows Server 2016 RS3/1709. No official fix for those who used the pre-1709 version. Note: The SID will only be resolvable after the PDC emulator role is transferred to a Windows Server 2016 domain controller.
After having carefully studied the possible impact of the following change, apply the script made by MSRC and referenced in the documentation below to alter the permission.

https://itpro-tips.com/wp-content/uploads/files/TechnetGallery/Enterprise-Key-Admins-720eb270.zip
https://secureidentity.se/adprep-bug-in-windows-server-2016/

The Log4Shell vulnerability takes advantage of Log4j’s ability to load objects using JNDI instructions, including through LDAP. This check looks for the RFC 2713 schema extension in Active Directory, which allows the representation of Java objects, and specifically searches for attributes such as javacodebase, javafactory, javaclassname, javaremotelocation, or javaserializeddata. If these attributes are found on active user accounts, they are flagged.

While these Java attributes can have legitimate uses, it's recommended to ensure they are not actively used or to set com.sun.jndi.ldap.object.trustURLCodebase to "false" in all Java code. To disable the Java extension, you can mark these attributes as defunct by following this guide: https://docs.microsoft.com/en-us/windows/win32/ad/disabling-existing-classes-and-attributes.

The classes added to the schema provide additional object types. If misconfigured, a class can be used to bypass security restrictions. There are two checks performed, possSuperiorComputer and possSuperiorUser that check for the computer and user class types being present in the possSuperiors attribute of any other classes.
Classes that contain the user or computer class in the possSuperiors attribute can be used as containers and subvert security restrictions such as allowing creation of new user and computers.

Remediation:
This vulnerability can be remediated by editing the schema for the affected class and removing computer/user class from the possSuperiors attribute. In the below documentation there are scripts that can be used to fix the active directory schema.
It should be noted that that the class msExchStorageGroup is known to have this vulnerability and documented under CVE-2021-34470. This can be exploited even if Microsoft Exchanged has been uninstalled.

https://bugs.chromium.org/p/project-zero/issues/detail?id=2186
https://gist.github.com/IISResetMe/399a75cfccabc1a17d0cc3b5ae29f3aa#file-update-msexchstoragegroupschema-ps1
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34470

In January 2021 Microsoft implemented a certificate pinning mechanism that stores the WSUS’ IIS server in a new certificate store specifically made for WSUS (WindowsServerUpdateServices) that only administrators can control.
Certificates contained in the WindowsServerUpdateServices certificate store are enforced by default to mitigate HTTPS intercepting attacks, but this can be disabled via Group Policy.

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/scan-changes-and-certificates-add-security-for-windows-devices/ba-p/2053668

WSUS is the component used on the intranet to deliver Windows updates. The recommendation of Microsoft is to use HTTPS for transport but for convenience or tests, HTTP can be configured.
The HTTP protocol can be intercepted on the network with tools such as wsuxploit or WSuspicious (see below for links) and malicious updates can be delivered.
The attacker can then take control of many assets.

https://github.com/pimps/wsuxploit
https://github.com/GoSecure/WSuspicious

In January 2021 Microsoft implemented a new behaviour for WSUS where only the system proxy will be used by default and administrators must conciously enable the less secure behaviour of using the system proxy first and then falling back to use the user proxy.

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/scan-changes-and-certificates-add-security-for-windows-devices/ba-p/2053668

The LDAP signature feature ensures the integrity of network communication between a computer and a domain controller, protecting against attacks where hackers intercept and alter communication to gain elevated privileges. This feature helps prevent such exploits. However, since not all devices support LDAP signing, it's recommended to set it to "Require signing" or at least "Negotiate signing."

If LDAP signing is set to "None" (no negotiation), attackers may exploit this vulnerability.

Remediation:
• Ensure the "Network security: LDAP client signing requirements" setting is set to either "Negotiate signing" or "Require signing". Policy Location: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options

References:
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.

The SMB downgrade attack exploits the use of the outdated SMB v1 protocol to obtain credentials or execute commands on behalf of a user. Since SMB v1 relies on older authentication methods, attackers can bypass its integrity, leaving systems vulnerable. Notably, SMB v1 was one of the key vulnerabilities exploited in the infamous WannaCry ransomware attack.

Microsoft strongly recommends disabling SMB v1 on both client and server systems whenever possible. However, if you're still using deprecated operating systems (e.g., Windows 2000, 2003, XP, CE), network printers with SMBv1 scan-to-share features, or software with custom implementations that rely on SMB v1, address these dependencies first. Otherwise, disabling SMB v1 may cause additional errors.

https://blogs.technet.microsoft.com/josebda/2015/04/21/the-deprecation-of-smb1-you-should-be-planning-to-get-rid-of-this-old-smb-dialect
https://github.com/lgandx/Responder-Windows

MS17-010 is a critical vulnerability that was published on March, 14th 2017. It can be used to compromise an entire domain via DC compromise. This exploit has been revealed by the Shadow brokers (EternalBlue, EternalRomance, EternalSinergy) and it uses the SMB v1 vulnerability.

Remediation:
• Apply windows updates to the domain controller.
• Disable SMB version 1

References:
https://blogs.technet.microsoft.com/msrc/2017/04/14/protecting-customers-and-evaluating-risk/
https://github.com/misterch0c/shadowbroker/tree/master/windows/exploits

MS14-068 is a critical vulnerability that was published on November, 18th 2014. It can be used to very quickly compromise an entire domain, which is why having DC still vulnerable to this publicly known vulnerability represents a high security risk.

Remediation:
• Apply windows updates to all affected domain controllers.

https://learn.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-068

A certificate should have clearly defined usage restrictions, typically set via the Extended Key Usage (EKU) field. If no specific purpose or "Any Purpose" is used, the certificate could be exploited to issue certificates for other users, potentially leading to impersonation. To mitigate this risk, review permissions for broad automatic enrollment of the certificate template or assign a specific EKU.

References:
https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/

An Agent certificate allows users to request certificates on behalf of others. A template has been found with the Certificate Agent EKU, which is accessible by a large number of users, posing a security risk.

Potential Mitigation:
• Periodically review certificate templates for risky EKUs and broad enrollment permissions

Potential Mitigations:
• Revoke enrollment permissions for broad security groups and assign enrollment access to required services
• If the Certificate Agent EKU is not required on the template remove the Certificate Agent enhanced key usage from the template

References:
https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/

SSL versions 2 and 3 are outdated and vulnerable. It is essential to disable them by configuring the Schannel component in Windows, which manages SSL/TLS protocols. While many Microsoft guidelines focus on IIS, Schannel tuning is necessary for securing WSUS.

Some tools may not reliably detect weak SSL protocols due to security enhancements in the .NET Framework, starting with version 4.7. To accurately test for these protocols, consider using tools like OpenSSL with deprecated protocols enabled (e.g., from Kali Linux).

Remediation:
• Apply Windows updates
• Implement registry changes to disable SSLv2 and SSLv3. IISCrypto tool can help simplify this.

References:
https://social.technet.microsoft.com/wiki/contents/articles/2249.windows-server-20082008r2-how-to-disable-sslv2-on-domain-controller-dsforum2wiki.aspx
https://support.microsoft.com/en-us/help/187498/how-to-disable-pct-1-0-ssl-2-0-ssl-3-0-or-tls-1-0-in-internet-informat
https://adsecurity.org/?p=376

To effectively detect and mitigate attacks, the appropriate events must be collected. Audit policies should strike a balance between gathering too many or too few events. It is important to compare your current audit settings with recommended best practices.

Audit settings can be configured in two locations:

Simple audit configuration: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policies.
Advanced audit configuration: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration.

Ensure the audit GPO is applied to all domain controllers, especially in OUs where it may not be enforced.

References:
https://adsecurity.org/?p=3377
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor

The behavior of Active Directory can be managed through the DsHeuristics attribute located in the configuration partition at CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration. The DoNotVerifyUPNAndOrSPNUniqueness parameter within this attribute controls whether UPN or SPN uniqueness checks are disabled. This setting was introduced to override the CVE-2021-42282 vulnerability mitigation addressed by KB5008382.

Potential Mitigations:
• Verify if the DoNotVerifyUPNAndOrSPNUniqueness parameter is enabled by checking the 21st caharacter of the DsHeuristics attribute for a non-zero value.

Potential Mitigations:
• Correct the issue by modifying the 21st character of the DsHeuristics attribute from whatever is set to 0.

References:
https://support.microsoft.com/en-us/topic/kb5008382-verification-of-uniqueness-for-user-principal-name-service-principal-name-and-the-service-principal-name-alias-cve-2021-42282-4651b175-290c-4e59-8fcb-e4e5cd0cdb29
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/spn-and-upn-uniqueness

The behavior of Active Directory can be managed through the DsHeuristics attribute located in the configuration partition at CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration. Parameters LDAPAddAutZVerifications and LDAPOwnerModify within this attribute influence the mitigation of CVE-2021-42291. KB5008383 introduced changes to the default security descriptor of Computer containers to enhance auditing and restrict computer account creation. This is critical to prevent misuse such as Kerberos abuse or relay attacks. The mitigations for CVE-2021-42291 include three settings for two parameters: LDAPAddAutZVerifications (28th character) and LDAPOwnerModify (29th character). The recommended setting for these parameters is 1 to enforce new security permissions and enable additional auditing.

Remediation:
• Follow the procedure outlined in KB5008383 to apply these changes.
- Be cautious of control characters at the 10th and 20th positions to avoid unintended changes.
- If DsHeuristics is empty, the updated value should be: 00000000010000000002000000011.

References:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5
https://support.microsoft.com/en-au/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1

Python Responder is a tool that exploits vulnerabilities in SMB protocols, particularly SMB v1, to compromise domains by injecting rogue data into network communications. SMB v1 lacks integrity checks, making it susceptible to such attacks. In contrast, SMB v2 and SMB v3 offer packet signing to ensure communication integrity but it can be disabled.

Remediation:
• Configure Group Policy to enable "Digitally sign communications (always)". This option is located in "Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options"
• Reivew Group Policy Objects for instances of "Digitally sign communications (always)" being disabled.

References:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/36172e53-ac81-48fb-b2e3-caa3761b9157
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always
https://www.cert.ssi.gouv.fr/actualite/CERTFR-2015-ACT-021/#SECTION00010000000000000000

Python Responder is a tool that exploits vulnerabilities in SMB protocols, particularly SMB v1, to compromise domains by injecting rogue data into network communications. SMB v1 lacks integrity checks, making it susceptible to such attacks. In contrast, SMB v2 and SMB v3 offer packet signing to ensure communication integrity but it can be disabled.

Remediation:
• Configure Group Policy to enable " Digitally sign communications (if client agrees)". This option is located in “Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options”
• Reivew Group Policy Objects for instances of "Digitally sign communications (if client agrees)” being disabled.

References:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/36172e53-ac81-48fb-b2e3-caa3761b9157
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always
https://www.cert.ssi.gouv.fr/actualite/CERTFR-2015-ACT-021/#SECTION00010000000000000000

LDAPS, unlike LDAP, does not allow message signatures since the TLS layer provides protection. However, this makes LDAPS vulnerable to relay attacks where forged LDAP packets can be tunnelled through TLS. To mitigate this, Channel Binding (or "Extended Protection") is used. It binds the outer TLS channel with the inner LDAP communication by passing properties like the server certificate hash to the authentication layer.

Potential Mitigations:
• Audit by enabling LDAP interface event logging on each domain controller:
• Monitor Windows Event IDs 3039 and 3040 to identify non-compliant clients.
• Once compatibility is verified, enforce Channel Binding by setting the LdapEnforceChannelBinding registry key

References:
https://support.microsoft.com/en-us/topic/use-the-ldapenforcechannelbinding-registry-entry-to-make-ldap-authentication-over-ssl-tls-more-secure-e9ecfa27-5e57-8519-6ba3-d2c06b21812e
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536/page/4
https://oxfordcomputergroup.com/resources/ldap-channel-binding-signing-requirements/
https://github.com/zyn3rgy/LdapRelayScan
https://access.redhat.com/articles/4661861
http://gary-nebbett.blogspot.com/2020/01/ldap-channel-binding.html

When migrating accounts between domains, the SID History attribute is appended to new accounts to track their original SID. This attribute can grant additional permissions based on the previous domain, affecting overall security. If the original domain's SID cannot be resolved, it indicates the domain has been removed, and SID History is no longer needed. Leaving SID History intact can pose security risks by granting unnecessary rights from the old domain.

Potential Mitigations:
• Review security descriptors across the domain to replace old SIDs with the new account SID. This process can be lengthly as requires every applied permission to a previous group is replaced with the updated group. Active Directory Migration projects should take this into account.
• Regularly audit SID History for unexpected values and remove when the original domain is decommissioned.

If LDAP signing is not enforced, attackers can perform man-in-the-middle attacks on LDAP connections, potentially adding unauthorized users to privileged groups like Administrators. LDAP signature enforcement is achieved by setting the ISC_REQ_INTEGRITY flag during Negotiate/NTLM/Kerberos authentication which is enabled through the security policy “Domain controller: LDAP server signing requirements.”

Potential Mitigations:
• Ensure all LDAP clients support LDAP signing.
• Audit clients that may not be compatible with LDAP signing.

Potential Mitigations:
• Follow Microsoft's guidelines to enable LDAP signing.
• Verify that all LDAP clients, including Unix systems, support signing.
• Enforce LDAP signing policy by configuring the relevant security policies.

References:
https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/enable-ldap-signing-in-windows-server
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536/page/4
https://github.com/zyn3rgy/LdapRelayScan

SYSVOL is a special DFS volume used to store system files such as Group Policy Objects (GPO). Read-Only Domain Controllers (RODC) should only have read-only access to this volume. If write access is mistakenly granted, attackers can modify files locally and propagate changes to writable domain controllers, potentially altering GPOs applied to domain controllers and compromising the entire domain.

Potential Mitigations:
• Ensure RODCs have read-only access to SYSVOL.
• Regularly audit RODC permissions on SYSVOL.

Potential Mitigations:
• Set msDFSR-ReadOnly to TRUE on Read Only Domain Controllers. This can be completed by using ADSI Edit, navigating to the RODC, expanding CN=DFSR-LocalSetting and CN=Domain System Volume and editing the attribute on CN=SYSVOL Subscription

References:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-frs2/3588b343-4076-4776-b5c0-78e2b3d91ed3

On Active Directory, the msDS-RevealedUsers attribute on the RODC computer object tracks all users whose credentials have been cached by the RODC. If a privileged user is listed, it indicates that their authentication secrets are cached on the RODC, potentially allowing impersonation. RODCs are often deployed in less secure environments, which increases the risk of compromise.

Potential Mitigations:
• Regularly audit the msDS-RevealedUsers attribute for privileged accounts.
• Avoid allowing privileged accounts to be cached on RODCs.

Potential Mitigations:
• Change the password for any privileged account cached on the RODC.
• Update the Password Replication Policy to prevent privileged accounts from being revealed to the RODC.

References:
https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-revealedusers

Active Directory allows Organizational Units (OUs) to be protected from accidental deletion by adding a Deny ACE to the NTSecurityDescriptor attribute, applied to Everyone, with the flags set to Delete and DeleteTree. This feature, introduced in Windows Server 2008, ensures that critical OUs cannot be deleted unless this protection is explicitly removed.

Potential Mitigations:
• Regularly audit and ensure protection is enabled for critical OUs and containers.

Potential Mitigations:
• Enable the "Protect object from accidental deletion" option for OUs through the Active Directory Users and Computers console:
- Open the Properties of the OU or container.
- Under the Object tab, check Protect object from accidental deletion.
- Apply changes.
• Use PowerShell to list and protect unprotected OUs:
Get-ADOrganizationalUnit -filter {name -like "*"} -Properties ProtectedFromAccidentalDeletion | format-table Name,ProtectedFromAccidentalDeletion
• Use PowerShell to protect all organizational units from accidental deletion:
Get-ADOrganizationalUnit -filter {name -like "*"} -Properties ProtectedFromAccidentalDeletion | where-object {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

References:
https://dirteam.com/sander/2011/07/13/preventing-ous-and-containers-from-accidental-deletion/

By default, Windows allows any authenticated user to enumerate network sessions on a computer, revealing who is connected to resources like file shares or Domain Controllers. Attackers, and tools like BloodHound, exploit this feature to map out logged-in users and admin accounts. Restricting Session Enumeration with a strict access control list means that attackers must use authenticated privileged accounts to get this information, limiting the potential for reconnaissance.

Potential Mitigations:
• Implement group policy to restrict network session enumeration.
• Use tools like NetCease to automate this process.

References:
https://github.com/p0w3rsh3ll/NetCease
https://blog.netwrix.com/2022/11/18/making-internal-reconnaissance-harder-using-netcease-and-samri1o/
https://adsecurity.org/?p=3299

Login scripts can be stored in any file share available in the network and that includes trusted domains shares. If a login script is hosted in a location outside of the domain it may not be trusted or monitored and may unknowlingly compromised.

Remediation:
• Copy the login script to a share located inside the domain

TLS 1.0 and TLS 1.1 are outdated encryption protocols that, while not immediately vulnerable to compromise, are no longer recommended. Disabling these protocols in the SChannel component of Windows is necessary to ensure a secure environment. Microsoft guidelines often focus on IIS settings but neglect SChannel.
LDAPS is automatically exposed once a certificate is available and the NTDS services are restarted.

Remediation:
• Apply necessary Windows updates and registry changes to enforce TLS 1.2+ usage. The DSInternals blog below shows how this can be completed via GPO

References:
https://support.microsoft.com/en-us/topic/kb5017811-manage-transport-layer-security-tls-1-0-and-1-1-after-default-behavior-change-on-september-20-2022-e95b1b47-9c7c-4d64-9baf-610604a64c3e
https://support.microsoft.com/en-us/help/187498/how-to-disable-pct-1-0-ssl-2-0-ssl-3-0-or-tls-1-0-in-internet-informat
https://www.dsinternals.com/en/active-directory-domain-controller-tls-ldaps/

SSL versions 2 and 3 are outdated encryption protocols that are vulnerable to various attacks. To enhance security, these protocols should be disabled in the SChannel component of Windows. Microsoft guidelines often focus on IIS, but changes need to be made directly to SChannel.

Remediation:
• Apply Windows updates and registry settings to fully disable SSLv2 and SSLv3.
• Follow Microsoft's guidance on disabling weak SSL protocols in the SChannel component.

References:
https://social.technet.microsoft.com/wiki/contents/articles/2249.windows-server-20082008r2-how-to-disable-sslv2-on-domain-controller-dsforum2wiki.aspx
https://support.microsoft.com/en-us/help/187498/how-to-disable-pct-1-0-ssl-2-0-ssl-3-0-or-tls-1-0-in-internet-informat
https://adsecurity.org/?p=376

A forest trust is a secure link between two forests, but by default, Kerberos delegation is allowed. This allows attackers in one forest (Forest A) to exploit unconstrained delegation to collect credentials, including the Ticket Granting Ticket (TGT) of privileged users in the other forest (Forest B). This can be done by abusing services such as the Print Spooler, which is enabled by default. With the TGT, the attacker can request access to systems in Forest B, potentially compromising the entire forest.
Disabling TGT Delegation can be completed using the Netdom utility.
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No
Mitigations:
• Disable TGT delegation on forest trusts except during migrations.

Remediation:
• Review and apply Microsoft's updates on TGT delegation.
• Identify and reconfigure services that rely on unconstrained delegation; resource-based delegation will not be affected.

References:
http://www.harmj0y.net/blog/redteaming/not-a-security-boundary-breaking-forest-trusts/
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/changes-to-ticket-granting-ticket-tgt-delegation-across-trusts/ba-p/440261
https://support.microsoft.com/en-us/help/4490425/updates-to-tgt-delegation-across-incoming-trusts-in-windows-server

When deployment files (e.g., applications as MSI or files copied by GPP) are stored on file shares outside of the trusted domain that may not be trusted, monitoring and unknowingly compromised. Ensuring that files are stored within the same domain, rather than on shares in other domains, reduces the risk of cross-domain attacks.

Remediation:
• Migrate deployment files to a trusted location in the domain

ADCS allows certificate requests via two services: Certification Authority Web Enrollment (WebEnrollment) and Certificate Enrollment Web Service (CES). These certificates can be used for Kerberos logins, and since ADCS can issue Domain Controller certificates, it is part of Tier 0. Legacy configurations do not enforce protection against credential relay attacks, such as PetitPotam, allowing attackers to potentially compromise the domain. Enabling Extended Protection for Authentication (EPA) or Channel Binding helps mitigate this risk by binding the TLS and HTTP layers.

Mitigation:
• Enable Extended Protection for Authentication (EPA) on ADCS servers.
• Restrict authentication methods to Kerberos only to prevent NTLM relay attacks.

Remediation:
• Open the IIS console on the enrollment server.
• In the Authentication settings, go to Advanced Settings for Windows Authentication.
• Set Extended Protection to Required for both WebEnrollment and CES services.

References:
https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429
https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
https://dirkjanm.io/ntlm-relaying-to-ad-certificate-services/
https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/

When Zone Transfers are enabled in DNS, attackers can anonymously retrieve all DNS records. This exposes the network to threats such as man-in-the-middle attacks and potential credential capture. The Zone Transfers setting applies domain-wide, and testing usually targets only one DNS server per zone.

Potential Mitigation:
• Disable Zone Transfers entirely unless required.
• Restrict Zone Transfers to authorized servers only.
• Regularly audit DNS server configurations to prevent unintended settings.

Remediation:
• Use the DNS console to access the "Forward Lookup Zones" and disable "Allow zone transfers" to "Any server".
• Alternatively, run the command:
dnscmd /zoneresetsecondaries <zone> /noxfr

References:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/f97756c9-3783-428b-9451-b376f877319a
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/dnscmd

When the insecure DNS update mechanism is enabled, attackers can anonymously modify DNS records, potentially adding malicious entries or conducting man-in-the-middle attacks to capture sensitive credentials. This vulnerability can impact local and _msdcs zones as well as any other domain zone.

Mitigation:
• Enable only secure dynamic updates for DNS records.
• Regularly audit DNS zones for insecure update settings.

Remediation:
• Go to the DNS console, navigate to the "Forward Lookup Zones", and ensure the "Dynamic updates" setting is changed from "Nonsecure and secure" to "Secure only" in the "General" tab.
• Alternatively, use the command:
dnscmd <servername> /Config <zone> /AllowUpdate 2

References:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/f97756c9-3783-428b-9451-b376f877319a
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/dnscmd

Default OUs like CN=Computers and CN=Users are stored in the wellKnownObjects attribute of the Domain object. There are 12 officially defined default locations, which can be modified using the redircmp command. Altering these defaults can affect the behaviour of certain programs, such as security audit tools, which may not recognize the modified objects.

Mitigations:
• Avoid modifying default OUs unless necessary.
• Regularly audit changes to the wellKnownObjects attribute.
• Ensure programs dependent on default OUs are updated to handle any changes.

Remediation:
• Use the redircmp tool to revert the default OU settings to their original values.

References:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/5a00c890-6be5-4575-93c4-8bf8be0ca8d8
https://rickardnobel.se/verify-redirected-computers-container-in-active-directory/

A certificate template defines the parameters for issuing certificates. If a user has permission to edit this template, they can alter attributes like msPKI-Certificate-Name-Flag, enabling them to issue certificates with custom subjects. This could allow a user to impersonate high-privilege accounts, such as domain admins, potentially leading to full domain compromise. Notably, "Domain Computers" is treated like "Everyone" if ms-DS-MachineAccountQuota is set to a non-zero value.

Potential Mitigations:
• Limit write permissions on certificate templates to trusted administrators.
• Regularly audit permissions on certificate templates.

Remediation:
• Review and adjust security permissions on certificate templates, removing write access from groups like Domain Users, Domain Computers, Everyone, and Authenticated Users.
• Ensure the ms-DS-MachineAccountQuota value is appropriately configured to limit unintended account creation.

References:
https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/

Windows PKI, or Active Directory Certificate Services (ADCS), allows users to request certificates via two services: Certification Authority Web Enrollment (WebEnrollment) and Certificate Enrollment Web Service (CES). Certificates from these services can be used for Kerberos authentication, making ADCS a Tier 0 asset. Due to legacy configurations, credential relay prevention is not enforced by default, allowing attackers to potentially exploit privileged credential relay (e.g., PetitPotam attack) to compromise the domain.

Potential Mitigation:
• Enforce HTTPS-only communication on IIS for ADCS-related services.

Remediation:
• Open IIS on the enrollment server and remove HTTP bindings from WebEnrollment (certsrv) or CES (CES_Kerberos).
• Ensure only HTTPS is allowed by keeping the HTTPS binding intact while removing the HTTP binding.
• Refer to KB5005413 for detailed steps to mitigate NTLM relay attacks in ADCS.

References:
https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429
https://dirkjanm.io/ntlm-relaying-to-ad-certificate-services/
https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf

In Active Directory, certificate requests are tracked by UPN for users and dnsHost for computers. Editing dnsHost typically updates the servicePrincipalName (SPN), where duplications are prohibited. However, there is no constraint on the dnsHost attribute itself. An attacker can manipulate this by changing the DNS of a compromised host to match that of a Domain Controller (DC) without updating the SPN. This allows them to request a certificate on behalf of the DC, gaining control over the domain.
The patch for this introduced a new OID, szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2), that embeds the requesting user’s security identifier and is enabled by default. To disable this functionality a new flag was introduced to the msPKI-Enrollment-Flag attribute for certificate templates called CT_FLAG_NO_SECURITY_EXTENSION.

Potential Mitigations:
• Edit the certificate template object and adjust the msPKI-Enrollment-Flag attribute so the CT_FLAG_NO_SECURITY_EXTENSION is no longer set. This can be completed by subtracting 524288 (0x80000) from the current value

References:
https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26931

In Active Directory Certificate Services (AD CS), there is a potential security issue where a user can modify the subject field of a certificate request before issuance. Normally, the subject is generated automatically by the certification authority (CA). However, if the certificate template has authentication-based EKUs assigned and allows the "Supply in the request" option, a malicious user can manually set the subject to an administrator account or any privileged identity. Once issued, the certificate can be used to impersonate that identity, leading to privilege escalation, unauthorized access to resources, or other security breaches within the environment.

Mitigation:
• Limit certificate template usage to specific, trusted groups of users to minimize the attack surface.

Potential Mitigation:
• Review certificate templates to ensure the "Supply in the request" option is disabled where not required.
• If the “Supply in the request” option is required, then ensure CA Manager approval is enabled so all certificates are reviewed before being issued.

References:
https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/

A domain controller must be properly configured with specific attributes and objects, including the userAccountControl attribute and objects in the configuration partition. This rule is triggered when inconsistencies are detected between the expected and actual values for these settings. The expected userAccountControl values are:
• For a Read/Write Domain Controller (RW DC): SERVER_TRUST_ACCOUNT (0x00002000) | TRUSTED_FOR_DELEGATION (0x00080000) = 0x00082000
• For a Read-Only Domain Controller (RODC): PARTIAL_SECRETS_ACCOUNT (0x04000000) | TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION (0x01000000) | WORKSTATION_TRUST_ACCOUNT (0x00001000) = 0x05001000
This rule can indicate manual or software misconfiguration or even signs of a compromise.

Potential Mitigations:
• For InvalidUserAccount: Verify that the userAccountControl value for RW DCs is 0x00082000 and for RODCs is 0x05001000. Correct any discrepancies found.
• For NoConfiguration: If the domain controller is not registered in the configuration partition, demote it immediately, as it should not be active.
• For NoNTDS: If the NTDS settings are missing, likely replication issues are present. Demote the domain controller to prevent further problems.

References:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/9164e4e8-f892-4ca2-8067-059f6f9387a4
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8ebf2419-1169-4413-88e2-12a5ad499cf5

By default, Kerberos uses RC4 as the signature algorithm for tickets. If Advanced Encryption Standard (AES) is enabled in a domain but not configured in the trusted domain, Kerberos tickets encrypted with AES will fail when sent to the trust. This causes either ticket failure or fallback to NTLM. The encryption algorithms allowed for a trust are defined by the msDS-SupportedEncryptionTypes attribute. If this attribute is not set or has a value of zero, RC4 is applied by default, while any defined value specifies which algorithm Kerberos should use.

Mitigation:
• Ensure AES support is enabled in the trust configuration to prevent fallback to RC4 or NTLM.

Remediation:
• Enable both RC4 and AES encryption for a smoother transition by running the command:
ksetup /setenctypeattr mytrust.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96
• Verify the msDS-SupportedEncryptionTypes attribute on the trust is configured to support both RC4 and AES.

References:
https://techcommunity.microsoft.com/t5/itops-talk-blog/tough-questions-answered-can-i-disable-rc4-etype-for-kerberos-on/ba-p/382718
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6cfc7b50-11ed-4b4d-846d-6f08f0812919
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797

Each Read-Only Domain Controller (RODC) contains an attribute, msDS-RevealOnDemandGroup, that defines which groups or users the RODC can retrieve. When the RODC retrieves a user account, it includes all secrets, allowing the RODC to impersonate the user. Privileged accounts and groups have a RID (Relative Identifier) lower than 1000, meaning the RODC can access sensitive data if these accounts are included in the msDS-RevealOnDemandGroup attribute.

Potential Mitigation:
• Audit which accounts and groups are allowed to be cached by the RODC.
• Regularly review and update the msDS-RevealOnDemandGroup attribute.

Potential Mitigation:
• Edit the msDS-RevealOnDemandGroup attribute to remove privileged users or groups.

References:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8dfc81be-7461-48f2-8caf-07402bccb0ea

During account migrations to another domain, the SID History attribute is often used to preserve access permissions. Officially, the SID History requires the presence of a special auditing group named DOMAIN-$$$,such as TEST−$$$ for a domain called TEST, which can be exploited by malicious tools like mimikatz. It is important to manage this group securely, especially during or after a migration process.

Potential Mitigation:
• Regularly review domain audit groups to ensure no unnecessary groups like DOMAIN-$$$ exist.
• Use LDAP queries (e.g., sAMAccountName=*$$$) to detect and monitor these groups.

Potential Mitigation:
• Remove the DOMAIN-$$$ auditing group after completing the migration.
• Ensure only authorized accounts have access to create or modify the SID History attribute.
• Monitor for unauthorized SID History modifications using security tools.

References:
https://cyber.gouv.fr/sites/default/files/IMG/pdf/NP-ActiveDirectory-NoteTech.pdf#paragraph.3.3.1.5

SID Filtering is a security mechanism that blocks accounts with SID History properties, preventing unauthorized access across domain or forest trusts. SID History is used to link an account to another, which can be exploited to propagate compromises through trusts. SID Filtering is disabled by default for domain-to-domain trusts (called "quarantine") but enabled by default for forest trusts. Disabling it in a forest trust is known as "enabling SID History."
Mitigations:
• Avoid disabling SID Filtering on forest trusts unless absolutely necessary.

Remediation:
• For domain trusts, use the command netdom trust <TrustingDomain> /domain:<TrustedDomain> /quarantine:yes to enable SID Filtering.
- Do not apply the /quarantine flag to forest trusts, as this will disrupt trust transitivity.
• For forest trusts, verify the SID Filtering status using PowerShell and disable SID History with netdom trust <TrustingForest> /forest:<TrustedForest> /enablesidhistory:no.

References:
https://msdn.microsoft.com/en-us/library/cc237940.aspx
https://activedirectoryfaq.com/2015/10/active-directory-sid-filtering/

A Downlevel trust is a special type of trust that is compatible with NT4 domains. This type of trust can be identified using the "Active Directory Domains and Trusts" tool.
Unless the remote party in the trust is an NT4 domain, this type of trust should not be used and should be recreated with a more modern trust type.

Mitigation:
• Avoid creating new Downlevel trusts unless absolutely necessary for NT4 domain compatibility.

Remediation:
• If a Downlevel trust is found and the remote party is not an NT4 domain, delete and recreate the trust using a more secure, modern trust type.

References:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/36565693-b5e4-4f37-b0a8-c1b12138e18e

ROCA" stands for "Return of Coppersmith's Attack," a vulnerability allowing attackers to retrieve private keys from public keys. This issue stems from the RSALib library by Infineon Technologies, which was used in many smart cards, Trusted Platform Modules (TPMs), and Hardware Security Modules (HSMs), including YubiKey 4 tokens. The library generated RSA keys within a limited number space, reducing the effort needed for an attacker to guess private keys.

Remediation:
• Revoke and reissue any certificates generated with the vulnerable library if they are still valid.
• Revoke and replace any dependent certificates if they rely on compromised keys.
• Remove expired certificates affected by the ROCA vulnerability from systems and stores.

References:
https://crocs.fi.muni.cz/public/papers/rsa_ccs17
https://github.com/crocs-muni/roca
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190026
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170012
https://keychest.net/roca

Active Directory backups must be verified to ensure they are performed according to Microsoft standards. Each backup updates the DIT Database Partition Backup Signature, which is crucial for ensuring that backups are current and valid. These backups are essential for rollback scenarios, such as rebuilding a domain or tracking past changes. The verification process is similar to executing the command REPADMIN /showbackup *.

Potential Mitigation:
• Plan and perform Active Directory backups according to Microsoft standards, using tools like wbadmin (e.g., wbadmin start systemstatebackup -backuptarget:d:).
• Follow specific backup schedules based on the system's Risk Management Framework (RMF) categorization:
- Moderate/High Availability: Back up Active Directory data daily.
- Low Availability: Back up Active Directory data weekly.

References:
https://technet.microsoft.com/en-us/library/jj130668(v=ws.10).aspx

SHA-1 is no longer considered safe for cryptographic use due to vulnerabilities that allow attackers to create hash collisions more easily than a brute-force attack would require. This weakness can lead to security breaches, particularly in applications like digital certificates where integrity is critical.
Mitigations:
• Avoid using SHA-1 for cryptographic purposes.

Remediation:
• Remove SHA-1-based certificates from the Group Policy Object (GPO).
• Reissue any certificates that rely on SHA-1, using a more secure hashing algorithm.

References:
https://tools.ietf.org/html/rfc6194

SHA-0 is an obsolete cryptographic hash function with significant vulnerabilities. Its design flaws make it possible for attackers to generate hash collisions in less time than a brute-force attack, compromising the integrity of any system relying on it.

Mitigation:
• Avoid using SHA-0 for any cryptographic applications.

Remediation:
• Remove any certificates that use SHA-0 from the Group Policy Object (GPO).
• Reissue certificates that rely on SHA-0 with a secure hashing algorithm.

References:
https://tools.ietf.org/html/rfc6194

MD5 is an outdated cryptographic hash function with vulnerabilities that allow attackers to create hash collisions more easily, threatening the integrity of systems relying on it. Although the root certificate algorithm doesn't directly affect security, it can indirectly result in the use of MD5 in subordinate certificates, further compromising security.

Mitigation:
• Avoid using MD5 for any cryptographic purposes.

Remediation:
• Remove certificates that use MD5 from the Group Policy Object (GPO).
• Reissue any certificates that depend on MD5 using a secure hashing algorithm.

References:
https://www.kb.cert.org/vuls/id/836068

MD4 is an outdated and vulnerable cryptographic hash function. Its design flaws make it possible for attackers to create hash collisions with less effort than brute-force attacks, compromising the security of any system using it. While the root certificate algorithm might not directly affect security, it can indirectly cause the use of MD4 in subordinate certificates, which further weakens security.

Mitigation:
• Avoid using MD4 for cryptographic applications.

Remediation:
• Remove any certificates that rely on MD4 from the Group Policy Object (GPO).
• Reissue certificates dependent on MD4 using a secure hashing algorithm.

References:
https://tools.ietf.org/html/rfc6150

MD2 is an outdated cryptographic hash function that is vulnerable to attacks, enabling hash collisions to be generated more easily than through brute-force methods. While the root certificate algorithm itself may not pose a direct security risk, it can indirectly lead to the use of MD2 in subordinate certificates, further compromising security.

Mitigation:
• Avoid using MD2 for any cryptographic operations.

Remediation:
• Remove certificates that use MD2 from the Group Policy Object (GPO).
• Reissue any certificates dependent on MD2 using a more secure hashing algorithm.

References:
https://www.ssi.gouv.fr/archive/fr/sciences/fichiers/lcr/mu04c.pdf

SHA-1 is no longer considered safe for cryptographic use due to vulnerabilities that allow attackers to create hash collisions more easily than a brute-force attack would require. This weakness can lead to security breaches, particularly in applications like digital certificates where integrity is critical.

Mitigation:
• Avoid using SHA-1 for cryptographic purposes.

Remediation:
• Remove SHA-1-based certificates from the Group Policy Object (GPO).
• Reissue any certificates that rely on SHA-1, using a more secure hashing algorithm.

References:
https://tools.ietf.org/html/rfc6194

SHA-0 is an obsolete cryptographic hash function with significant vulnerabilities. Its design flaws make it possible for attackers to generate hash collisions in less time than a brute-force attack, compromising the integrity of any system relying on it.

Mitigation:
• Avoid using SHA-0 for any cryptographic applications.

Remediation:
• Remove any certificates that use SHA-0 from the Group Policy Object (GPO).
• Reissue certificates that rely on SHA-0 with a secure hashing algorithm.

References:
https://tools.ietf.org/html/rfc6194

MD5 is an outdated cryptographic hash function with vulnerabilities that allow attackers to create hash collisions more easily, threatening the integrity of systems relying on it. Although the root certificate algorithm doesn't directly affect security, it can indirectly result in the use of MD5 in subordinate certificates, further compromising security.

Mitigation:
• Avoid using MD5 for any cryptographic purposes.

Remediation:
• Remove certificates that use MD5 from the Group Policy Object (GPO).
• Reissue any certificates that depend on MD5 using a secure hashing algorithm.

References:
https://www.kb.cert.org/vuls/id/836068

MD4 is an outdated and vulnerable cryptographic hash function. Its design flaws make it possible for attackers to create hash collisions with less effort than brute-force attacks, compromising the security of any system using it. While the root certificate algorithm might not directly affect security, it can indirectly cause the use of MD4 in subordinate certificates, which further weakens security.

Mitigation:
• Avoid using MD4 for cryptographic applications.

Remediation:
• Remove any certificates that rely on MD4 from the Group Policy Object (GPO).
• Reissue certificates dependent on MD4 using a secure hashing algorithm.

References:
https://tools.ietf.org/html/rfc6150

MD2 is an outdated cryptographic hash function that is vulnerable to attacks, enabling hash collisions to be generated more easily than through brute-force methods. While the root certificate algorithm itself may not pose a direct security risk, it can indirectly lead to the use of MD2 in subordinate certificates, further compromising security.

Mitigation:
• Avoid using MD2 for any cryptographic operations.

Remediation:
• Remove certificates that use MD2 from the Group Policy Object (GPO).
• Reissue any certificates dependent on MD2 using a more secure hashing algorithm.

References:
https://www.ssi.gouv.fr/archive/fr/sciences/fichiers/lcr/mu04c.pdf

An active trust between domains uses a shared secret, stored in a special account named after the remote domain. This secret is updated monthly, reflected by changes in the whenChanged attribute of the account. If the whenChanged attribute does not update, it could indicate that the secret was not changed, possibly due to issues with the remote domain or its non-existence.
If the whenChanged attribute remains unchanged, it suggests a potential problem with the remote domain, such as network connectivity issues or the domain no longer existing. If the remote domain is inaccessible or has been decommissioned, the trust should be removed. Failure to address this could allow the stale secret to be exploited to issue fake Kerberos tickets, potentially creating a backdoor into the system.

Potential Mitigations:
• Confirm whether the remote domain still exists.
• If the remote domain no longer exists, remove the trust.
• If the domain exists, force a password change to refresh the shared secret.

References:
https://msdn.microsoft.com/fr-fr/library/ms680921(v=vs.85).aspx

The Digital Signature Algorithm (DSA), a NIST standard introduced in 1993 as part of the Digital Signature Standard (FIPS 186), is being deprecated. The proposed FIPS 186-5 draft specifies that DSA will no longer be approved for generating digital signatures, though it may still be used to verify signatures generated before the new standard's implementation date.
Due to the deprecation of DSA for digital signature generation, it is crucial to phase out its use in systems. Continuing to use DSA after its deprecation could pose security risks and result in non-compliance with updated standards.

Potential Mitigations:
• Avoid using DSA for any new digital signature generation.

Potential Mitigations:
• Remove certificates utilizing DSA from the Group Policy Object (GPO).
• Reissue certificates that depend on DSA using a more secure and approved algorithm.

References:
https://csrc.nist.gov/publications/detail/fips/186/5/draft

RSA key certificates with modulus sizes under 1024 bits are vulnerable to brute-force attacks due to advancements in computing power. This means that attackers can potentially guess the private key, compromising the security of the certificate. A compromised certificate could allow attackers to impersonate legitimate users or services, gaining unauthorized access to systems and data.
Mitigations:
• Locate and remove the weak certificate from the GPO.

Remediation:
• Reissue certificates: If other certificates rely on the weak one, reissue them using a key size of 2048 bits or greater (consider 3072 bits for future-proofing).

References:
https://media.defense.gov/2022/Sep/07/2003-071834/-1/-1/0/CSA-CNSA-2.0-ALGORITHMS.PDF

While the modulus is the primary factor in RSA key strength, the exponent also plays a role. A weak exponent, such as 3, can be more efficient but is less secure. While 65537 is the common and recommended choice for compatibility reasons, using a smaller exponent can potentially expose the certificate to certain attacks.

Potential Mitigation:
• Avoid generating certificates with a weak RSA exponent

Remediation:
• If other certificates rely on the weak ones, reissue them using the standard exponent of 65537.

RSA key certificates with modulus sizes under 2048 bits are susceptible to brute-force attacks due to increasing computing power. This vulnerability becomes more critical for certificates valid beyond 2030 (where a minimum of 3072 bits is recommended). A compromised certificate could allow attackers to impersonate legitimate users or services, gaining unauthorized access to systems and data.

Mitigation:
• Avoid using RSA with certificates that have extremely long lifetimes
• Avoid using RSA with less than 2048 bits

Remediation:
• Reissue certificates: If other certificates rely on the weak ones, reissue them using a key size of 2048 bits or greater (consider 3072 bits for future-proofing).

References:
https://media.defense.gov/2022/Sep/07/2003-071834/1/1/0/CSA-CNSA-2.0-ALGORITHMS.PDF
https://cyber.gouv.fr/sites/default/files/2022-10/RGS-v-2-0-B1.pdf

Foreign Security Principals (FSPs) in admin groups poses significant risks by increasing the attack surface and potentially compromising domain security if the external domain is less secure or compromised.

Mitigation:
• Implement and enforce strict policies for creating and managing trust relationships between domains. Avoid adding FSPs from untrusted domains to privileged groups unless absolutely necessary and after thorough vetting.
• Conduct regular audits of privileged groups to ensure all members are necessary. Monitor FSP activities closely for any unusual or suspicious behavior.
• Apply the principle of least privilege to ensure that FSPs have only the minimum access required for their roles. Avoid granting excessive privileges that could be exploited.

Using the tool Mimikatz, a DCShadow attack is a technique that allows an attacker to create and manipulate objects in Active Directory (AD) by simulating the behavior of a domain controller (DC). An attacker can create, modify, or delete AD objects, such as user accounts, groups, or security policies. This can lead to privilege escalation scenarios, persistence, and domain compromise within the environment.

Mitigation:
• Implement security monitoring tools that can detect and alert on DCShadow attacks.
• Analyze replication traffic for unusual or unexpected changes originating from unknown sources.
• Monitor for suspicious domain controller registrations or unrecognized DCs in the environment.
• Ensure that only authorized domain controllers are allowed to replicate changes in the AD environment.
• Implement strict access controls and least privilege principles for AD administration accounts.
• Keep systems up to date with the latest security patches.
• Regularly monitor and audit AD objects and their changes for any suspicious activities.

Anonymous Bind in Active Directory allows users to connect to the AD service and perform certain read operations without providing credentials. If Anonymous Bind is enabled an attacker could potentially retrieve sensitive information about users, groups, and computers in the domain and this information could be used to identify weak targets for further attacks.

Remediation:
• Regularly audit your domain to determine whether Anonymous Bind is enabled
• Disable Anonymous Bind in every domain unless it is required
3. If Anonymous Bind cannot be disabled, ensure AD settings are adjusted to restrict the types of information that can be accessed anonymously to only information that is necessary for legitimate purposes.

The Name Service Provider Interface (NSPI) protocol is used internally by Exchange to resolve addresses and can be exposed to the internet via RPC over HTTP. The "AllowAnonNSPI" parameter stored in the attribute of DsHeuristics can be optionally set to allow access to the NSPI protocol without any account and this would allow unauthenticated users to retrieve sensitive information from the directory service.

Remediation:
• Regularly audit your domain to find where AllowAnonNSPI is enabled
2.Ensure AllowAnonNSPI is disabled (replace the 8th character of the DsHeuristics attribute with a value of 0).

PowerShell is a powerful tool for legitimate administrative tasks and is commonly exploited by attackers. PowerShell allows attackers to run programs like mimikatz in memory using obfuscated commands (e.g: "Invoke-Mimikatz"). Because these actions occur entirely in memory, there is no artifact left behind on the disk, so the incident response task becomes difficult for forensic analysts.

Remediation:
• Regularly audit your environment to determine whether PowerShell logging is enabled on any machines
2. Ensure PowerShell logging is enabled via a group policy (even if these security settings may be part of the workstation or server images).

Several Windows OS versions are no longer supported and thus no longer receive security updates, patches, or fixes for newly discovered vulnerabilities. Unsupported Windows OS versions may be susceptible to a number of attacks, e.g: Administrator's credentials can be captured, security protocols are weak, etc.

Remediation:
• Ensure all computers are upgraded to supported Windows OS versions
• Ensure all computers are upgraded regularly to apply security updates, patches, and fixes that are issued by Microsoft.

In an Active Directory environment, Domain Controllers (DCs) have extensive privilege. DCs that haven't authenticated to the domain for more than 60 days can pose a security risk. Inactive DCs are more likely to have stale passwords, not have the latest security patches, and could contain outdated or unnecessary data that could be exploited by an attacker.

Remediation:
• Ensure all DCs are monitored and login activity is audited and reviewed regularly
• Implement strict policies for disabling inactive DCs

An outbound forest trust with SID History enabled poses a security risk in Active Directory environments involving multiple forests. Outbound forest trust allows users from one forest (Forest A) to access resources in another forest (Forest B). With SID History enabled, it preserves a user's previous Security Identifier (SID) when their account is migrated from one domain or forest to another.

If SID History is enabled on the outbound forest trust, it means that when a user from Forest A accesses resources in Forest B, their previous SIDs (from Forest A) are also considered for authorization. An attacker who compromises a user account in Forest A can potentially gain unauthorized access to resources in Forest B that the user had access to before the migration, exploiting the SID History information. By carefully managing forest trusts and SID History, you can minimize the potential for unauthorized access across forests in your Active Directory environment.

Mitigation:
• Evaluate the necessity of the outbound forest trust and remove it if not required.
• If the trust is necessary, disable SID History on the trust unless it's absolutely needed for resource access.
• Regularly monitor and audit access attempts using SID History across the trusted forests.

In Active Directory, trusts allow users from one domain to access resources in another domain, with each trust having attributes that defines the trust. A trust configured with the attribute set to "TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION" is vulnerable to an attacker with domain admin rights in the trusted domain to exploit the configuration to gain unauthorized access to the trusting domain by impersonating any user in the trusting domain, even domain admins, and compromise the entire domain.

Mitigation:
• Audit all domain trusts and remove the "TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION" attribute where not absolutely needed.
• Enforce the principle of least privilege and limit domain admin accounts.
• Monitor for suspicious trust creation and modification activities.

The Print Spooler service is responsible for managing print jobs on a computer and, if enabled on a Domain Controller, presents serious security risks because it runs with high privileges and has access to sensitive resources and data. There are also known vulnerabilities with this service (e.g: CVE-2021-34527) that an attacker could exploit to executre arbitray code with SYSTEM privileges.

Remediation:
• Disable the Print Spooler service, unless needed, on all Domain Controllers
• Perform regular audits of Active Directory to uncover any unusual activity related to this service
• Monitor for unauthorized access attempts or changes to the configuration of this service and set up alerts for attempts to exploit known vulnerabilities

In an Active Directory environment the "Domain Administrators" group or "Enterprise Administrators" group are set as owners for Domain Controllers by default. In some cases, the owner can be a non-administrative account. For instance, when a server has been promoted from an existing server, the owner may be a non-admin who joined the server to the domain. If an attacker were to gain access to a non-admin account that is the owner of a Domain Controller, they could use it to take ownership of the entire domain

Remediation:
• Ensure the ownership of Domain Controllers matches the "Domain Administrators" or "Enterprise Administrators" group

In an Active Directory environment, domain controllers (DCs) are servers that manage user authentication, access control, and replication of directory data. If a DC's password is not regularly updated, it becomes vulnerable to various attacks, such as Brute-force attacks, Kerberos attacks, and Replication issues leading to inconsistencies in the Active Directory database.

Remediation:

• Ensure that Domain Controller passwords are changed at least every 30-60 days, in line with your organization's security policy.
• Configure Group Policy to enforce regular password changes for Domain Controllers
• Set up monitoring and alerting systems to identify Domain Controllers with passwords older than the defined threshold.
• Regularly audit and remove inactive or stale Domain Controller accounts from Active Directory to minimize the attack surface.

In Active Directory, the domain functional level determines which advanced features are available. As Microsoft releases newer versions of Windows Server, they introduce higher functional levels with new capabilities. If a domain is left at an obsolete functional level, it would lack important security features introduced in newer Windows Server versions, allowing attackers to exploit known vulnerabilities that have been fixed in versions and to compromise the domain more easily.

Remeditation:
• Upgrade domains to the highest functional level the domain controllers support (ideally Windows Server 2016 or later)
• Ensure all domain controllers are running the appropriate Windows Server version
• Upgrade or decommission any obsolete domain controllers

The krbtgt account is a special account used to encrypt and sign all Kerberos tickets in the domain. If an attacker gains write access to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute (used for RBCD) on the krbtgt account, they can create a malicious delegation. This malicious delegation allows the attacker to impersonate any user and access any service in the domain, effectively giving them complete control over the Active Directory environment.

To mitigate this finding
• Ensure strict access control on the krbtgt account. Only trusted administrators should have write access to this account.
• Regularly monitor and audit the permissions on sensitive accounts like krbtgt to detect any unauthorized changes.
• Ensure that sensitive accounts that should not be delegated are marked as such.

To learn more about how Resource Baseed Constrained Delegation can be abused, visit this blog post: https://blog.netwrix.com/2022/09/29/resource-based-constrained-delegation-abuse/f

Resource-Based Constrained Delegation (RBCD) is a feature in Active Directory that allows certain servers to impersonate users to access specific services on other servers. If enabled on domain controllers, it can be abused by attackers. If an attacker were to compromise a server with RBCD enabled they could configure the compromised server to allow it to impersonate users to the domain controller. The attacker would then be able to impersonate any user, even admins, to the domain controller and gain full control of Active Directory.

Remediation:
• Regularly audit your Active Directory environment to determine whether RBCD is enabled on Domain Controllers
• Ensure RBCD is not enabled on domain controllers unless absolutely necessary
• Limit RBCD to only servers that absolutely require it.
• Monitor and alert on any changes to RBCD configurations, especially on Domain Controllers.

Unconstrained delegation is a feature in Active Directory that allows a service to impersonate a user and access resources on their behalf. While this feature is useful for legitimate purposes in some scenarios, it can be abused by potential attackers. This powerful privilege should only be given to trusted servers like Domain Controllers (DCs). If a non-Domain Controller is misconfigured with unconstrained delegation an attacker who compromises that server could steal Kerberos tickets and impersonate other users, escalate privilege, and compromise the entire domain.

Remediation:
• Regularly audit your domain to determine Non-Domain Controllers have Unconstrained Delegation in place
• Replace Unconstrained Delegation with Constrained Delegation (e.g: replace "trust this computer for delegation to any service" with "trust this computer for delegation to specified services only" on the Delegation tab of the account object).
• Ensure that servers with Constrained Delegation are monitored for signs of compromise.

Unconstrained delegation is a feature in Active Directory that allows a service to impersonate a user and access resources on their behalf. While this feature is useful for legitimate purposes in some scenarios, it can be abused by potential attackers. With unconstrained delegation in place, a Kerberos Ticket Granting Ticket (TGT) can be captured and this TGT can then grant access to any service the user has access to.

Remediation:
• Regularly audit your domain to determine if users have Unconstrained Delegation in place
• Replace Unconstrained Delegation with Constrained Delegation (e.g: replace "trust this computer for delegation to any service" with "trust this computer for delegation to specified services only" on the Delegation tab of the account object).

RBCD is a security feature in Active Directory that allows a service to delegate authentication on behalf of a user to another service within the same domain. Unlike traditional delegation, RBCD doesn't require domain administrator privileges to configure. An attacker who compromises a machine with RBCD enabled can exploit this configuration to impersonate users, move laterally within the network and escalate their access potentially compromising the entire domain

Attack Process:
1. Compromise Initial Machine: The attacker gains control over a machine where RBCD is enabled.
2. Configure Delegation: The attacker modifies the resource's permissions to allow their controlled machine to impersonate users.
3. Impersonate a User: Using extensions like S4U2Self, the attacker requests a service ticket on behalf of another user.
4. Access Target Resources: The attacker uses this service ticket to access other resources or services as the impersonated user.

Mitigation:
• Limit write access to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on computer accounts to only trusted and necessary accounts.
• Regularly audit and monitor the permissions on the msDS-AllowedToActOnBehalfOfOtherIdentity attribute using tools like PowerShell or AD security scanners.
• Implement the principle of least privilege and ensure that no unnecessary accounts have write access to this attribute.
• Enable auditing of RBCD configuration changes and monitor for any suspicious modifications.
• Keep DCs and AD permissions tightly controlled and regularly updated to prevent potential misconfigurations or unauthorized access.

To learn more about abusing RBCD, read this blog post: https://blog.netwrix.com/2022/09/29/resource-based-constrained-delegation-abuse/

The krbtgt account is a special account in Active Directory used to encrypt and sign Kerberos tickets. When Resource-Based Constrained Delegation (RBCD) is enabled on the krbtgt account, it allows any server or service in the domain to obtain Ticket Granting Tickets (TGTs) on behalf of any user, without requiring the user's password. An attacker who compromises any server in the domain can abuse this misconfiguration to gain unauthorized access to any user's account, including privileged accounts like Domain Admins. This attack allows an attacker to impersonate any user in the domain and gain access to their resources and privileges, leading to complete domain compromise.

Remediation:
• Immediately disable RBCD on the krbtgt account.
• Rotate the krbtgt account password twice to invalidate any Kerberos tickets that may have been issued with the misconfigured delegation.
• Investigate the scope of the breach and identify any compromised servers or accounts.
• Implement strict controls and approval processes for enabling RBCD on any account, especially sensitive accounts like krbtgt.
• Regularly audit Active Directory for misconfigurations and adherence to security best practices.

RBCD allows a service to impersonate a user when accessing another service, based on the permissions set on the target service. If an attacker gains write access to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a DC computer account, they can exploit RBCD. The attacker can configure any domain account to impersonate users, including high-privileged accounts, when accessing services on the DC. This allows the attacker to escalate privileges and potentially take over the entire AD domain.

Mitigation:
• Limit write access to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on DC computer accounts to only trusted and necessary accounts.
• Regularly audit and monitor the permissions on the msDS-AllowedToActOnBehalfOfOtherIdentity attribute using tools like PowerShell or AD security scanners.
• Implement the principle of least privilege and ensure that no unnecessary accounts have write access to this attribute.
• Enable auditing of RBCD configuration changes and monitor for any suspicious modifications.
• Keep DCs and AD permissions tightly controlled and regularly updated to prevent potential misconfigurations or unauthorized access.

Constrained delegation is a feature in Active Directory that allows a service to impersonate a user to access specific services on their behalf. If an account that has contrained delegation enabled is compromised, it is possible to impersonate any domain user and authenticate to a service that the user account is trusted to delegate to. For these accounts, the msds-AllowedToDelegateTo attribute identifies the SPNs of the services the user is trusted to delegate to.

To mitigate this risk:
• Limit constrained delegation to only necessary services.
• Ensure servers with constrained delegation are well-protected and monitored for signs of compromise.
• Educate users about phishing tactics and the risks of clicking on suspicious links.
• Implement strong authentication methods (e.g., multi-factor authentication) to make impersonation harder.
• Regularly review and audit constrained delegation configurations to ensure they adhere to the principle of least privilege.

Read this blog post to learn more on attacking constrained delgation to elevate access https://blog.netwrix.com/2023/04/21/attacking-constrained-delegation-to-elevate-access/

When unconstrained delegation is configured, the userAccountControl attribute of the object gets updated to include the “TRUSTED_FOR_DELEGATION” flag. When an object authenticates to a host with unconstrained delegation configured, the ticket-granting ticket (TGT) for that account gets stored in memory so that the host with unconstrained delegation configured can impersonate that user later, if needed.

If an attacker compromises a non-DC server that has the "Trusted for Delegation" setting enabled, the attacker can then impersonate any user accessing the compromised server and perform actions on their behalf, potentially gaining unauthorized access to other resources in the domain.

Mitigation:
• Regularly review and audit the "Trusted for Delegation" setting on all servers in the domain.
• Ensure that only DCs and necessary service accounts have this setting enabled.
• If a non-DC server is found with this setting enabled, investigate the reason and remove the setting if it's not required.
• Implement strong security measures, such as keeping systems updated, using strong passwords, and enabling multi-factor authentication, to prevent attackers from compromising servers in the first place.

Service accounts can be trusted for delegation, allowing them to impersonate other users and access resources on their behalf. Attackers who compromise a service account with unconstrained delegation privileges can abuse this feature to impersonate any user, even privileged accounts like Domain Admins. By impersonating a high-privileged user, the attacker can gain unauthorized access to sensitive resources and perform malicious actions.

Mitigation:
• Limit the use of unconstrained delegation and only assign it to service accounts that absolutely require it.
• Implement "Kerberos Constrained Delegation" instead, which allows you to specify which services the account can delegate to, reducing the attack surface.
• Regularly monitor and audit service accounts with delegation privileges to detect any suspicious activities.
• Ensure service accounts have strong, unique passwords and are protected from compromise.

A constrained delegation is a delegation with some limitation. In this case, it is a limitation of the technical service a delegate can call (SPN). But in practice, the specific service name is not checked and the delegate can impersonate anyone on all services of a computer. For the case of a domain controller, that means that the delegate can take the control of the domain by impersonating a domain admin and doing modifications with the LDAP service. This delegation is set via the attribute msDS-AllowedToDelegateTo and is limited to Kerberos.

Potential Mitigation:
• You should edit the msDS-AllowedToDelegateTo attribute of the accounts to remove the SPN of the domain controllers involved

A constrained delegation with protocol transition is a delegation with some limitation. In this case, it is a limitation of the technical service a delegate can call (SPN). But in practice, the specific service name is not checked and the delegate can impersonate anyone on all services of a computer. For the case of a domain controller, that means that the delegate can take the control of the domain by impersonating a domain admin and doing modifications with the LDAP service. This delegation is set via the attribute msDS-AllowedToDelegateTo. The protocol transition is a special feature set in the userAccountControl which does not limit the delegation to the Kerberos protocol.

Potential Mitigation:
• You should edit the msDS-AllowedToDelegateTo attribute of the accounts to remove the SPN of the domain controllers involved.

A weak password is a vulnerability that can be easily exploited by attackers to gain unauthorized access to user accounts and resources within an organization's network. Weak Passwords are determined by matching against a known breach dictionary, such as the HaveIBeenPwned breach database. These passwords are extremely susceptible to being brute forced as a part of a credential stuffing attack.

Potential Mitigation:
• Implement and enforce strong password policies across the organization, including minimum length, complexity, and regular password changes.
• Educate users on creating strong, unique passwords and the importance of password security.
• Enable multi-factor authentication (MFA) for all user accounts to provide an additional layer of security beyond passwords.
• Use a password filter to prevent users from setting weak, easily guessable, or previously compromised passwords.
• Regularly audit and monitor user accounts for suspicious login attempts or password changes.
• Consider implementing a password manager to help users generate and securely store strong, unique passwords for each account.

By enforcing strong password policies and educating users on password security best practices, organizations can significantly reduce the risk of attackers compromising user accounts through weak passwords.

Identifies passwords stored in Group Policy Preference files. If passwords are found in the cPassword field, attackers can obtain it and so the account should be considered compromised. Note that Microsoft published the AES key used to encrypt passwords in GPOs, which is why even an encrypted password is insecure.

Potential Mitigations:
• Manually change the password to a new one. If this password is shared on many systems, each system should have a different password. If the GPO was used to define the native local administrator account, it is recommended to install a password solution manager such as LAPS.

In Active Directory (AD), by default, computer accounts automatically change their passwords every 30 days. Regular password changes are crucial to maintaining security, as they prevent prolonged use of compromised credentials and mitigate risks from side-channel attacks. The ability to create multiple computer accounts (up to 10) by default can also be exploited as a backdoor if these accounts do not follow proper password management practices. Security agencies often consider the absence of password changes as a sign of compromise, indicating that an attacker may be maintaining persistence within the network.

Potential Mitigation:
• Ensure that the registry keys controlling password changes (DisablePasswordChange and MaximumPasswordAge) are configured correctly, with regular audits to verify compliance.
• Regularly monitor and audit computer accounts for password changes and flag accounts that exceed the 30-day threshold.
• Limit the number of computer accounts that can be created by default and apply strict monitoring to detect and address potential backdoor accounts.

In Active Directory, certain accounts may be configured to store passwords using reversible encryption. This means the password is effectively stored in plaintext within the supplementalCredential attribute of the account. This configuration poses a significant security risk, as it allows attackers to retrieve the plaintext password if they gain access to the directory database through techniques like a DCSync attack.

Potential Mitigation:
• Remove the "Store password using reversible encryption" flag from all accounts to prevent storing plaintext passwords.
• Require a password change for any account that previously had reversible encryption enabled to ensure that plaintext passwords are removed from the directory.
• Run regular audits using PowerShell commands to identify any accounts that still have reversible encryption enabled and correct them promptly.

NTLMv1 is an outdated authentication protocol that is vulnerable to cryptographic attacks. Attackers can exploit NTLMv1 by capturing NTLM hashes over the network, which can then be used to impersonate users. This protocol is especially susceptible to coercive authentication attacks, where an attacker forces a Domain Controller (DC) to authenticate to a malicious server using NTLMv1, allowing the attacker to capture the DC’s credentials and potentially take control of the domain.

Potential Mitigation:
• Disable NTLMv1: Configure the LAN Manager Authentication Level to "Send NTLMv2 response only. Refuse LM & NTLM" to prevent the use of NTLMv1.
• Regularly audit network traffic and authentication logs to identify and address any instances of NTLMv1 usage.
• Ensure all systems and software in the environment are compatible with NTLMv2 or Kerberos, and update or replace systems that rely on NTLMv1.

In Active Directory, each computer has a hidden user account responsible for maintaining the computer's domain membership. The password for this account is automatically changed every 30 days unless the Domain Controller is configured to refuse these changes. If the "Domain controller: Refuse machine account password changes" setting is enabled, computer account passwords won't be updated, leading to stale credentials that are more vulnerable to attacks. Attackers could exploit these stale credentials to gain unauthorized access to the domain.

Potential Mitigation:
• Ensure the GPO setting "Domain controller: Refuse machine account password changes" is set to "Disabled" or not configured, allowing automatic password changes.
• Conduct regular audits to ensure that machine account passwords are being updated as expected.
• Implement monitoring for unusual authentication attempts or access patterns that could indicate exploitation of stale credentials.

It is a best practice to enforce strong password policies for servuce accounts to reduce the risk of compromise. Service accounts with weak or short passwords are vulnerable to brute-force attacks, potentially leading to a compromise of the services they manage.The use of Managed Service Accounts (MSAs) introduced in Windows Server 2008 R2 simplifies password management by automatically handling password changes.

Potential Mitigation:
• Implement a Strong Password Policy: Enforce a Password Setting Object (PSO) or Group Policy Object (GPO) requiring service accounts to use passwords of at least 20 characters.
• Leverage a PAM solution like Netwrix Privilege Secure to significantly enhance the security of service accounts by automating and controlling access to these critical credentials, thereby reducing the risk of compromise and ensuring compliance with security best practices.
• Perform regular audits to ensure service accounts comply with the enforced password policies and are using strong, updated passwords.

Credential Manager in Windows is a secure vault where credentials like usernames and passwords are stored. The SeTrustedCredManAccessPrivilege allows a user to access this vault, which can be exploited to retrieve sensitive credentials, leading to unauthorized access to systems and data.

Potential Mitigation:
• Ensure that SeTrustedCredManAccessPrivilege is not assigned to any user or group by editing the GPO under User Rights Assignment.
• Regularly audit user rights assignments to ensure no unnecessary privileges are granted, particularly those related to sensitive areas like Credential Manager.
• Implement monitoring to detect and alert on any unauthorized attempts to access or exploit Credential Manager.

LAPS (Local Administrator Password Solution) is recommended for managing the passwords of local administrator accounts on workstations and servers within a domain. It provides a simple and effective way to ensure that each local administrator account has a unique, regularly updated password, which is stored securely in Active Directory. Without a solution like LAPS, local administrator accounts might share the same password across multiple machines, increasing the risk of lateral movement during a compromise.

Potential Mitigation:
• Implement LAPS to automatically manage and randomize local administrator passwords, ensuring each password is unique and regularly updated.
• Conduct regular audits of local administrators and ensure proper password hygiene across these accounts
• Implement monitoring to detect and respond to any unauthorized use of local administrator accounts.

The AZUREADSSOACC computer account is crucial for enabling Azure AD Seamless Single Sign-On (SSO). This account is responsible for converting Kerberos TGS tickets to SAML tokens, allowing on-premises users to authenticate seamlessly with Azure AD. The password for this account, shared between the on-premises environment and Azure AD, should automatically update every 30 days. If this doesn't occur, the account becomes vulnerable to attacks like DCSync, which could compromise Azure AD. Using tools like Mimikatz, an attacker with sufficient privileges can perform a DCSync attack to retrieve the AZUREADSSOACC password from the Domain Controller. Once the password is obtained, the attacker can create forged Kerberos tickets and convert them into valid SAML tokens for Azure AD authentication which allows them to impersonate any user, including privileged accounts, effectively bypassing all Azure AD security measures.

Potential Mitigation:
• Use the PowerShell script provided by Microsoft to immediately roll over the AZUREADSSOACC password. This script ensures that the account's Kerberos decryption key is updated and securely stored. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-faq#how-can-i-roll-over-the-kerberos-decryption-key-of-the-azureadssoacc-computer-account
• Schedule regular executions of the password roll-over script to ensure that the AZUREADSSOACC password is periodically updated. This mitigates the risk of stale credentials being exploited.
• Implement advanced monitoring to detect abnormal behavior associated with the AZUREADSSOACC account, such as unexpected authentication attempts or Kerberos ticket requests. Utilize Azure AD Conditional Access policies to monitor and restrict high-risk sign-ins that originate from compromised tokens.
• Enhance Azure AD Conditional Access policies to add an additional layer of protection. Require multi-factor authentication (MFA) even for users authenticated via Kerberos or SAML, especially for privileged actions or access to sensitive resources.

Link-Local Multicast Name Resolution (LLMNR) is a protocol used to resolve hostnames to IP addresses within the same local network when DNS is unavailable. However, in Active Directory environments where DNS is mandatory, LLMNR is redundant and can pose significant security risks. Attackers can use tools like Responder to listen for LLMNR requests on the network. When a user mistypes a hostname, the attacker’s machine responds, leading the user to a malicious resource. Once the user connects to the attacker-controlled resource, the Windows SSO process automatically sends credentials, which the attacker can capture and use for further network penetration.

Potential Mitigation:
• Implement a Group Policy Object (GPO) to disable LLMNR by enabling the "Turn off multicast name resolution" setting. This prevents LLMNR from being used in the environment, reducing the risk of MitM attacks.
• Regularly audit your environment to ensure that the GPO is correctly applied and that no other GPOs override this setting.
• Implement network monitoring solutions to detect any unauthorized LLMNR traffic, which could indicate potential exploitation attempts.

The LAN Manager (LM) hash is an outdated and insecure hashing algorithm used in earlier versions of Windows. Due to its flawed design, LM hashes can be easily cracked, exposing the plaintext password in seconds. Modern systems should not use LM hashes, and they should be disabled to enhance security.

Potential Mitigation:
• Ensure that the Group Policy setting "Network security: Do not store LAN Manager hash value on next password change" is enabled. This will prevent the storage of LM hashes when passwords are changed.
• Set the "Network security: LAN Manager authentication level" to "Send NTLMv2 response only. Refuse LM & NTLM," ensuring that only the more secure NTLMv2 protocol is used for authentication.
• Regularly audit your environment to ensure that LM hashes are not being stored and that legacy protocols like LM and NTLM are not in use.
• After enabling these settings, prompt users to change their passwords to ensure that any existing LM hashes are replaced with more secure NTLMv2 hashes.

In some systems, particularly Unix and Mainframe environments, Single Sign-On (SSO) is implemented by storing shared secrets in user account attributes in Active Directory (AD). Attributes like unixUserPassword can store passwords in clear text or with weak encryption like ROT13, which makes them vulnerable to being queried by anyone. Additionally, the userPassword attribute, used in LDAP systems, is not secure in AD and can expose passwords in clear text when modified.

Potential Mitigation:
• Remove the unixUserPassword and userPassword attributes from user accounts unless they are securely encrypted and necessary for legacy system support.
• Ensure that all passwords stored in AD attributes are protected with strong cryptographic protocols if their storage is unavoidable.
• Conduct regular audits of AD to identify and remove insecure attributes, ensuring that passwords are not exposed or stored insecurely.
• Transition to using secure password management solutions and enforce policies that prevent storing passwords in clear text or using weak encryption within AD attributes.

In Active Directory (AD), by default, computer accounts automatically change their passwords every 30 days. Regular password changes are crucial to maintaining security, as they prevent prolonged use of compromised credentials and mitigate risks from side-channel attacks. The ability to create multiple computer accounts (up to 10) by default can also be exploited as a backdoor if these accounts do not follow proper password management practices. Security agencies often consider the absence of password changes as a sign of compromise, indicating that an attacker may be maintaining persistence within the network. A computer without a password change in the last 90 days is considered an anomoly and higher risk.

Potential Mitigation:
• Ensure that the registry keys controlling password changes (DisablePasswordChange and MaximumPasswordAge) are configured correctly, with regular audits to verify compliance.
• Regularly monitor and audit computer accounts for password changes and flag accounts that exceed the 30-day threshold.
• Limit the number of computer accounts that can be created by default and apply strict monitoring to detect and address potential backdoor accounts.

Using smart cards for sensitive accounts enhances security, but when the "Smart Card required" flag is set, the password for these accounts is not automatically updated. This can create a security risk as stagnant passwords are more vulnerable to certain attacks. If the password remains unchanged, attackers may leverage older, compromised password hashes to gain unauthorized access.

Potential Mitigation:
• Regularly update the password for accounts with the "Smart Card required" flag to ensure the NT hash is refreshed.
• If using Windows Server 2016 or later, ensure the msDS-ExpirePasswordsOnSmartCardOnlyAccounts attribute is configured to handle periodic hash changes automatically.
• Verify that the GPO "Enable rolling of expiring NTLM secrets during sign-on" is not disabled, ensuring periodic password hash updates during sign-in for smart card users.
• As an alternative, disable and then re-enable the "Smart Card required" flag to force a password hash update, or use a script like Invoke-SmartcardHashRefresh to manually refresh the NT hash.

In Active Directory an account can be created without a password if it has the flag "PASSWD_NOTREQD" set to "True" in the UserAccountControl attribute. This represents a high security risk as the account is not protected at all without a password.

Remediation:
• Regularly audit your Active Directory environment to identify any accounts with "PASSWD_NOTREQUD" set to True in the UserAccountControl attribute
• Set this flag to False for all accounts that have it

If an Active Directory (AD) user has a historical password that was found in a breach website such as Have I Been Pwned, it poses significant security risks. Finding AD users with a weak historical password exposes usesrs to risks such as Credential Stuffing attacks, Brute Force attacks, and/or social engineer techniques.

Attackers can use the breached passwords to attempt login on multiple services and accounts, including the AD environment. Since users often reuse passwords, a breached password can be used to gain unauthorized access to the AD account. Knowing historical passwords can help attackers reduce the time and effort needed to crack current passwords, especially if the user has a pattern in creating passwords (e.g., incremental changes like "Password1" to "Password2"). Lastly, historical passwords can provide attackers with personal information or patterns that can be leveraged in phishing attacks or other social engineering tactics.

Mitigation:
• Implement and enforce strong password policies across the organization, including minimum length, complexity, and regular password changes.
• Educate users on creating strong, unique passwords and the importance of password security.
• Enable multi-factor authentication (MFA) for all user accounts to provide an additional layer of security beyond passwords.
• Use a password policy to prevent users from setting weak, easily guessable, or previously compromised passwords.
• Regularly audit and monitor user accounts for suspicious login attempts or password changes.
• Consider implementing a password manager to help users generate and securely store strong, unique passwords for each account.

When an attackers discovers a password that is shared across multiple Active Directory (AD) user accounts, then this provides the possibility to move laterally across the network and escalate their privileges, potentially leading to domain compromise.


Mitigation:
• Implement and enforce a strong password policy that requires unique passwords for each account.
• Educate users about the risks of password reuse and the importance of using unique, strong passwords.
• Enable multi-factor authentication (MFA) to add an extra layer of security, even if a password is compromised.

In Active Directory, the "adminCount" attribute is set to 1 for protected accounts, such as members of privileged groups like Domain Admins, Administrators, and Schema Admins. These accounts have special safeguards applied to them by default.
If an account is removed from these privileged groups, the adminCount attribute may remain set to 1, but the account will no longer have the same safeguards. This makes the account vulnerable to attacks.

Remediation:
• Regularly audit accounts with adminCount=1 to ensure they are still members of the appropriate privileged groups.
• If an account is removed from a privileged group, manually reset the adminCount attribute to 0.
• Implement strict access controls and monitoring for all privileged accounts.
4. Use dedicated admin workstations and accounts for administrative tasks to minimize the risk of compromise.

Without the flag "This account is sensitive and cannot be delegated" any account can be impersonated by some service account. It is a best practice to enforce this flag on administrators accounts.If an attacker compromises an account with delegated administrative privileges, they can elevate their access and move laterally across the network, gaining control over critical resources.

Remediation:
• Regularly audit admin accounts to ensure "Account is sensitive and cannot be delegated" is set
• Limit delegation to only services and computers that absolutely require it
• Use Least Privilege, only delegating minimal needed rights to admin accounts
• Monitor for and alert on suspicious admin account activity and usage
• Ensure administrator accounts are members of the built-in "Protected Users" group

DES (Data Encryption Standard) Encryption Only is an outdated and insecure algorithm and once assigned to an account, it can be used in Kerberos ticket requests. If the attacker cracks the Kerberos ticket, they can steal the token and compromise the user account..

Remediation:
• Avoid using DES Encryption Only and switch to modern, secure encryption algorithms like AES (Advanced Encryption Standard) with at least 128-bit keys.
• Use encryption in combination with other security measures, such as message authentication codes (MAC) or digital signatures, to ensure data integrity and authenticity.
• Keep encryption libraries and software up to date to protect against newly discovered vulnerabilities.

LM (LAN Manager) Hash is a deprecated and insecure way of storing passwords in Windows systems. Attackers can obtain LM hashes by dumping credentials from the Security Account Manager (SAM) database or NTDS.dit file, which stores active directory data. This allows attackers to potentially crack these weak hashes and gain unauthorized access to accounts.

Remediation:
• Ensure your systems are using the more secure NTLMv2 authentication instead of LM.
• Disable LM Hash storage entirely by editing the Windows Registry or using Group Policy.
• Enforce strong, complex passwords that are harder to crack even if the hashes are compromised.
4. Keep your systems updated with the latest security patches.

Reversible encryption is a method of securing passwords where they can be decrypted and retrieved in plain text. This is considered a vulnerability because if an attacker gains access to the encrypted passwords, they can easily decrypt these passwords and use them to impersonate users, escalate privileges, or gain unauthorized access to other systems.

Remediation:
• Identify accounts with reversible encryption enabled using AD tools or PowerShell scripts.
• Change the "Store password using reversible encryption" setting to "Disabled" for each affected user account.
• Force users to change their passwords at next logon to replace the decryptable password.
• Educate administrators not to enable reversible encryption unless absolutely necessary for specific applications.
• Regularly audit AD for any accounts with this setting enabled and remediate them promptly.

Reversible password encryption is generally considered insecure because it allows passwords to be stored in a format that can be decrypted, exposing them to unauthorized access. In the context of Group Policy Objects (GPOs), if this setting is enabled, passwords associated with user accounts can be retrieved by attackers who gain access to these GPOs, leading to potential compromise of those accounts.

Remediation:
• Ensure that all domain controllers are updated with Microsoft's security patch MS14-025, released in May 2014, which prevents the storage of plaintext passwords in GPP files.
• Remove any existing GPP files containing plaintext passwords from the SYSVOL folder on all domain controllers.
• Change all passwords that were previously set using GPP to ensure they are no longer compromised.
• Educate administrators to avoid using GPP for distributing passwords and instead use more secure methods, such as Microsoft LAPS (Local Administrator Password Solution).

In Active Directory, administrators can set user accounts to have passwords that never expire. Attackers may exploit accounts with passwords that are set to never expire, to gain and maintain access to the domain.

Remediation:
• Regularly review accounts with non-expiring passwords and limit this feature to only necessary accounts.
• Enforce strong password policies for all users, including those with non-expiring passwords.
• Monitor for suspicious activity on accounts with non-expiring passwords and respond promptly to any potential breaches.

Expired passwords can pose a risk if systems or applications don't enforce password changes properly. An attacker could exploit this by using an expired password to log into a local account and then escalate privileges, particularly if the password is tied to a privileged account.

Mitigation:
• Audit Active Directory to identify users with expired passwords to ensure either the password is updated or the account disabled/deleted.
• Ensure that expired passwords are no longer usable and that users are required to change them.
• Set up monitoring to detect and respond to any attempts to use expired passwords, which could indicate an attack.

Passwords that are older than a year can present a risk to organizations due to the likeliness that over that period of time the password could have been compromised through various means including data breaches, phishing, or password reuse. An attacker uses these compromised passwords to gain unauthorized access to user accounts in Active Directory or Azure AD. Once inside, they can steal sensitive data, escalate privileges, or move laterally across the network.

Potential Mitigation
• Enforce a strong password policy that requires users to change their passwords regularly, such as every 90 days.
• Implement multi-factor authentication (MFA) to add an extra layer of security, making it harder for attackers to access accounts even if they have the password.
• Monitor for and block known compromised passwords
• Educate users about creating strong, unique passwords and the risks of password reuse.

An attacker who compromises a user's password from a less secure external service can potentially gain unauthorized access to the user's AD account. This is particularly dangerous if the compromised account has high privileges within the AD environment, such as being a member of the Domain Admins group. If an attacker successfully logs in to a high-privileged AD account using a reused password, they can gain extensive control over the AD environment by accessing sensitive data, modify AD configurations, or Elevate privileges of other accounts.

Mitigation:
• Implement and enforce a strong password policy that requires unique, complex passwords for each account.
• Educate users about the risks of password reuse and the importance of using unique passwords for different accounts.
• Enable multi-factor authentication (MFA) for all user accounts, to add an extra layer of security beyond passwords.
• Use a password manager to help users generate and store unique, strong passwords for each account.

Group Managed Service Accounts (gMSAs) are a type of Active Directory account intended for running services securely. The passwords for gMSAs are automatically rotated on a regular basis, however, the gMSA may end up with an old password that is no longer secure. If an attacker gains access to an old gMSA password, they can use it to impersonate the gMSA and gain unauthorized access to resources and services that trust the gMSA.

Mitigation:
• Regularly monitor gMSA objects to ensure their passwords are being rotated as expected.
• Set up alerts to notify administrators if a gMSA password rotation fails.
• Investigate and resolve any issues causing password rotation failures promptly.
• Limiting gMSA access to specific resources and regularly auditing gMSA usage.

gMSA (Group Managed Service Account) is a special type of Active Directory account designed for services running on multiple servers. It provides automatic password management and enhanced security compared to regular service accounts. It is important to identify where services are configured to use regular service accounts instead of gMSA as they pose a security risk. If an attacker compromises a service account password, they can gain unauthorized access to the service, lead to data breaches, lateral movement within the network, and even privilege escalation.

Remediation:
• Identify services that are using regular service accounts and migrate them to gMSA.
• Configure gMSA for each service, ensuring that it has the necessary permissions to function properly.
• Regularly review and audit service account usage to ensure gMSA is being utilized where appropriate.
• Implement strong password policies and regularly rotate passwords for any remaining service accounts that cannot be migrated to gMSA.

Computers with default passwords are easily discoverable and exploitable by attackers. Default passwords are often well-known or easily guessable, allowing attackers to gain unauthorized access to the computer and its resources. Once an attacker gains access to a computer with a default password, they can use it as a foothold to move laterally within the network, compromising other systems and resources.


Mitigation:
• Periodically audit all computers and devices to ensure that no default passwords are in use and that all passwords meet the organization's security standards.
• Remove or disable any unnecessary default accounts that come with the computer or device.

Microsoft Local Administrator Password Solution (LAPS) is a tool that automatically manages local administrator account passwords on domain-joined computers. Attackers with read permissions for LAPS can potentially retrieve these passwords, leading to unauthorized access to local administrator credentials.

Remediation:
• Regularly audit the permissions on the "ms-Mcs-AdmPwd" attribute using tools like PowerShell or AD Security Explorer.
• Ensure that only authorized groups, such as "Domain Admins" or a dedicated LAPS admin group, have read access to this attribute.
• Implement change monitoring to detect and alert on unauthorized modifications to the attribute's ACL.

An Active Directory (AD) account with reversible encryption enabled has the password stored in a format that allows it to be decrypted back into its original form. Unlike hashed passwords, which are one-way and cannot be easily reversed, reversible encryption allows for the password to be decrypted and retrieved. If an attacker gains access to the encrypted password data, they can decrypt it to obtain the original password and makes it vulnerable for attackers to exploit the credentials.

Mitigation:
• Use secure, one-way hashing for storing passwords rather than reversible encryption.
• Identify and address instances where reversible encryption is used for passwords.

Without AES keys, Kerberos authentication defaults to using older and less secure encryption types like RC4-HMAC or DES. These encryption types are vulnerable to brute force and cryptographic attacks. AES (Advanced Encryption Standard) provides stronger encryption, making it significantly harder for attackers to decrypt Kerberos tickets and other sensitive data​. This introduces an increased vulnerability to attacks such as Pass-the-Ticket or Kerberoasting attacks.

Pass-the-Ticket (PTT) Attacks: Attackers can capture Kerberos tickets and reuse them to impersonate users without needing their passwords. Older encryption types make it easier for attackers to decrypt and reuse these tickets. See our Attack Catalog for more information at https://www.netwrix.com/pass_the_ticket.html
Kerberoasting: This attack involves requesting service tickets for service accounts and attempting to crack their passwords offline. Service tickets encrypted with weaker encryption types are easier to crack, enabling attackers to gain access to service accounts and potentially escalate their privileges​. See our Attack Catalog for more information at https://www.netwrix.com/cracking_kerberos_tgs_tickets_using_kerberoasting.html

Mitigation:
• Enforce a strong password policy that requires users to change their passwords regularly, such as every 90 days.
• Implement multi-factor authentication (MFA) to add an extra layer of security, making it harder for attackers to access accounts even if they have the password.
• Monitor for and block known compromised passwords.
• Educate users about creating strong, unique passwords and the risks of password reuse.


https://www.netwrix.com/pass_the_ticket.html

When a user account has no password set, it allows anyone to log in without providing a password. This oversight poses a a major risk allowing attackers to easily gain unauthorized access to the network.

Mitigation:
• Regularly audit Active Directory for accounts with empty passwords.
• Enforce a strong password policy that requires all user accounts to have a password meeting complexity requirements.

If a computer account is inadvertently or maliciously added to a privileged group like Domain Admins, any compromise of that machine could lead to domain-wide privilege escalation. Attackers with control over a computer account in a privileged group can perform actions that are normally reserved for administrators, including managing domain controllers, modifying security settings, and accessing any resource within the domain. An attacker could use the compromised computer account to establish persistent access within the domain. Since computer accounts are often less scrutinized than user accounts, this access could remain undetected for a longer period. Persistent access through a computer account can be used to re-enable or create backdoor accounts, modify group policies, or even disable security features.

Mitigation:
• Remove computer accounts from admin groups unless absolutely necessary.
• Use separate admin workstations for administrative tasks.
• Implement strong password policies and regular password rotation for computer accounts.
• Monitor and audit computer account activities for suspicious behavior.
• Implement least privilege access controls for computer accounts.

In Active Directory, administrative accounts typically have the default owner set as "Domain Admins" or "Enterprise Admins." This setup ensures that only highly privileged users can manage these groups. When a regular domain user is set as the owner of an administrative group, that user gains the ability to modify the group's membership. This can allow them to add themselves or other users to highly privileged groups.

Attack Process:
1. The attacker compromises a regular user account that owns an administrative group.
2. The attacker adds their controlled account or another compromised account to the group.
3. The attacker can now perform privileged actions, such as creating new accounts, accessing sensitive data, or disabling security controls.

Mitigations:
• Review and Audit Group Ownership: Regularly audit the ownership of all administrative groups to ensure that only highly privileged accounts (e.g., Domain Admins) are set as owners.
• Implement Strict Access Controls: Limit who can change the ownership of groups by restricting these permissions to a small number of trusted administrators.
• Monitor Changes: Enable logging and monitoring for any changes to group memberships or ownership, using tools like SIEM to detect and respond to suspicious activities.
• Use Least Privilege: Ensure that users only have the minimum necessary privileges, and avoid assigning excessive permissions to non-administrative users.

The Pre-Windows 2000 Compatible Access security group is a backward compatibility group which allows read access on all users and groups in the domain. While Microsoft still adds Authenticated Users to this group by default, the inclusion of Authenticated Users in this group poses significant security risks. Any authenticated user, including domain-joined computers, can enumerate and access extensive information about all users and groups in the domain.

This level of access can be exploited by attackers to gather intelligence on the domain's structure, identify high-value targets like Domain Admins, and potentially escalate privileges. For instance, by having read access to attributes such as userAccountControl, an attacker can identify accounts that might have weak security configurations, like those with the "PasswordNotRequired" flag, making it easier to compromise those accounts.

Mitigation:
• It is recommended to remove Authenticated Users from the Pre-Windows 2000 Compatible Access group. This action significantly reduces the exposure of sensitive information. However, organizations should first test this change in a controlled environment to ensure it does not disrupt any legacy applications or systems that might still rely on these permissions.
• Conducting regular reviews of the members of this group and removing any that do not require these permissions is crucial for maintaining security.
• Whenever possible, upgrade or migrate systems that still require these backward-compatible settings to modern, supported versions of Windows, which do not require membership in this group.

The built-in domain Administrator account is a highly privileged account in Active Directory that has unrestricted access to the domain. Built-in domain Administrator account activity could indicate a potential security risk. Attackers often target this account because of its extensive permissions. If compromised, an attacker could use the account to perform malicious activities, such as stealing sensitive data, creating backdoor accounts, or moving laterally across the network.

Mitigation:
• Investigate the recent activity of the built-in domain Administrator account to determine if the usage was legitimate or suspicious.
• Suspicious activity should be immediately followed-up with reseting the password for the account and enable multi-factor authentication (MFA) to prevent unauthorized access.
• Limit the use of the built-in domain Administrator account and consider creating separate, dedicated administrator accounts for daily administrative tasks.
• Consider implementing a Privileged Access Management (PAM) solution to secure, monitor, and control privileged access to critical resources.

Old passwords pose a significant security risk to an organization's Active Directory environment. They are more likely to be weak, reused, or previously compromised, making them easier targets for attackers. If an attacker gains access to an administrator account with an old password, they can use the account's elevated privileges to move laterally, access sensitive data, and cause extensive damage.

Mitigation:
• Set a maximum password age policy for administrator accounts, forcing regular password changes.
• Require users to use complex passwords that meet minimum length and complexity requirements.
• Implement MFA for all administrator accounts to provide an additional layer of security beyond passwords.

The DNS Admins group has significant control over the Domain Name System (DNS) settings in the Active Directory environment. An attacker may levergae members of this group modify DNS records, potentially redirecting network traffic to malicious servers or causing denial-of-service issues.

Mitigation:
• Regularly review the membership of the DNS Admins group and ensure that only authorized and necessary accounts are included.
• Implement strict access controls and approval processes for modifying group memberships, especially for privileged groups like DNS Admins

Situations may arise where a user account is deleted and then recreated with the same username. The new account may have a different SID, but the old SID (historical SID) remains associated with the account and access control lists (ACLs) or group memberships reference the historical SID. The new account inherits these permissions, potentially granting unintended access rights to the recreated user.

Mitigation:
• Avoid deleting and recreating accounts with the same username whenever possible.
• If an account must be recreated, carefully review and update ACLs and group memberships to ensure the new account has appropriate permissions.
• Regularly audit and clean up historical SIDs to maintain a secure Active Directory environment.

This can occurs when a regular user account in Active Directory is assigned the same Security Identifier (SID) as the built-in Administrator account. This can happen due to misconfigurations or malicious actions. Many applications and services treat accounts with the Administrator SID as having full administrative privileges, even if the account itself is not in the Administrators group. This will allow the user with the regular account to gain unauthorized admin-level access to various resources.

Mitigation:
• Remove the Administrator SID from any regular user accounts that have it assigned.
• Review and correct any processes that may be improperly assigning the Administrator SID to regular accounts.

There is a higher likelihood of users having unnecessary or excessive privileges, violating the principle of least privilege. Each additional administrator account presents another potential target for attackers, increasing the overall risk of compromise. As the number of administrators grows, it becomes difficult to effectively audit and monitor their activities and making it more difficult to detect and respond to suspicious behavior. It is important to to perform a review of which users have administrative rights, and to ensure they are necessary.

Mitigation:
• Use RBAC to assign administrators only the permissions they need to perform their job duties, following the principle of least privilege.
• Conduct periodic reviews of administrator accounts to ensure that privileges are appropriate.
• Use a PAM solution to manage, monitor, and control administrator access to sensitive resources.
• Auditing and monitoring administrator activities.

In Active Directory, a ServicePrincipalName (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. If privileged user accounts like Domain Admins have SPNs defined, it can make them vulnerable to certain attacks. If an attacker compromises the password hash of a privileged account with an SPN, they can use Kerberoasting techniques to request Kerberos service tickets for that account. They can then crack the password offline, potentially gaining access to the privileged user's credentials.

Mitigation:
• Regularly audit your privileged accounts to ensure they don't have unnecessary SPNs defined.
• Remove any SPNs from privileged accounts that don't specifically require them.
• Implement Managed Service Accounts (MSAs) or Group Managed Service Accounts (gMSAs) for services instead of using privileged user accounts.

For more information on this topic please visit: https://blog.netwrix.com/2022/08/31/extracting-service-account-passwords-with-kerberoasting/

The Protected Users group is a special security group that provides various benefits and additional security messures. Protected Users group does not allow the user's credentials to be stored in the LSASS (Local Security Authority Subsystem Service) memory, which helps prevent credential theft attacks like Pass-the-Hash. It requiring Kerberos authentication and preventing the use of weaker authentication protocols like NTLM. Lastly, disabling the user's ability to use Kerberos delegation, which can be exploited in certain attack scenarios.

Mitigation:
• Identify sensitive user accounts, such as administrators, service accounts, and high-value targets.
• Add these sensitive user accounts to the Protected Users group.
• Monitor and maintain the membership of the Protected Users group regularly, adding new sensitive accounts as needed and removing those that no longer require protection.

For more information on this topic please visit: https://blog.netwrix.com/2015/02/20/add-sensitive-user-accounts-to-active-directory-protected-users-group/">https://blog.netwrix.com/2015/02/20/add-sensitive-user-accounts-to-active-directory-protected-users-group/

An Active Directory forest with various amount privileged accounts can increase the attack surface significantly due to the large number of high-value targets. Privileged accounts, such as Domain Admins, have extensive permissions and can be used to compromise the entire forest if they are breached. An attacker can target privileged accounts through various methods like phishing, password guessing, or exploiting vulnerabilities. If a privileged account is compromised, the attacker gains unrestricted access to the forest and can perform malicious activities, such as stealing data, creating backdoors, or even taking down the entire network.

Mitigation:
Ensure that privileged accounts are only granted the minimum permissions necessary to perform their tasks. Regularly review and adjust permissions as needed.
• Implement PAM tools to manage, monitor, and control privileged access. These solutions can provide features like just-in-time access, session recording, and multi-factor authentication (MFA).
• Enforce complex passwords, regular password changes, and prevent password reuse. Consider using password vaulting solutions to securely store and manage privileged account passwords.
• Require MFA for all privileged account access to add an extra layer of security beyond passwords.
• Regularly monitor privileged account usage, and audit logs for suspicious activities. Set up alerts for abnormal behavior.
• Regularly review and remove unnecessary privileged accounts. Consider using temporary, time-limited accounts for specific tasks instead of permanent privileged accounts.

Stale admin accounts in AD pose a significant security risk as they may have eleveated privileges and could be exploited by attackers to gain unauthorized access to critical systems and data.

Remediation:
1. Regularly review and audit AD admin accounts to identify stale or unused accounts.
2. Disable or delete stale admin accounts that are no longer needed.
3. Implement strong password policies and enforce regular password changes for admin accounts.
4. Enable multi-factor authentication (MFA) for all admin accounts to prevent unauthorized access.
5. Monitor admin account activities using security information and event management (SIEM) tools to detect suspicious behavior.

In an Active Directory environment, privileged user accounts, such as administrators, may be disabled when they are no longer needed or when an employee leaves the organization. If users with admistrative privileges granted are not properly removed or have their permissions revoked, they can pose a security risk exploitable by attackers. If an attacker gains access to a disabled privileged user account which still has elevated permissions they can exploit vulnerabilities or misconfigurations to re-enable the account and then perform lateral movement within the network. Even with the account disabled, the presence of its credentials and group membership in cached sessions could be leveraged by attackes to escalate privileges within the domain.

Mitigation Steps:
• Regular Audits: Conduct regular audits of disabled accounts, ensuring that high-privilege group memberships are removed.
• Account Deletion: For accounts that are no longer needed, consider fully deleting them rather than just disabling them.
• Strict Monitoring: Implement stringent monitoring for any changes to disabled accounts, particularly any re-enablement actions.
• Privileged Access Management (PAM): Use PAM solutions to manage and monitor the use of privileged accounts and their group memberships.

In an Active Directory (AD) or Azure AD environment, privileged accounts, such as administrators, have extensive access rights and permissions. This check looks for recently created admins that may have been created without authorization and is being leveraged by an attacker or malicious insider to perform malicious activities, such as stealing sensitive data, modifying configurations, or maintaining persistent access to the environment.

Mitigation:
• Implement strict access controls and approval processes for creating privileged accounts.
• Regularly review and monitor privileged account creation activities using auditing and logging mechanisms.
• Use the principle of least privilege, granting privileged access only when necessary and revoking it when no longer needed.
• Implement multi-factor authentication (MFA) for all privileged accounts to prevent unauthorized access.
• Conduct regular security assessments and audits to identify and remove any unauthorized privileged accounts.
• Privileged Access Management (PAM): Use PAM solutions to protect and monitor the use of privileged accounts

In Active Directory, the adminCount attribute is set to 1 for protected accounts, such as members of privileged groups like Domain Admins, Administrators, and Schema Admins. These accounts have special safeguards applied to them by default. These objects are governed by the SDProp proccess and as such have their ACLs controlled to match all other privileged accounts.

A privileged account without adminCount=1 is no longer governed by the SDProp process and could be left more insecure.

Potential Mitigation:
• Regularly audit accounts with adminCount=1 to ensure they are still members of the appropriate privileged groups.
• Regularly audit members of privileged groups to ensure they are set correctly with adminCount = 1
• Regular audit the AdminSDHolder container ACL which is propogated to all privileged accounts

Without Kerberos pre-authentication, an attacker can request Kerberos data from the domain controller and use this data to brute-force the account password via a AS-REP Roasting attack.

Potential Mitigation:
• Contiunally monitor for and prevent adminstrative accounts from not requiring Kerberos pre-authentication
• Edit the property of the identified accounts by unchecking "Do not require Kerberos preauthentication

The purpose is to ensure proper isolation of administrative activities and to prevent any admin from having an email address configured in the domain.

Potential Mitigation:
• Ensure that administrators do not use their privileged account for browsing the internet or receiving emails.
• Implement a Tier Zero model. In this model, low privileged actions cannot be made by highly privileged accounts such as admins. This means that, in practice, administrators should have two separate Windows accounts: one for regular activities and one for performing privileged actions.

The group "Schema Admins" is used to give permissions to alter the schema. Once a modification is performed on the schema such as new objects, it cannot be undone. This can result in a rebuild of the domain. The best practice is to have this group empty and to add an administrator when a schema update is required, then remove this group membership.

Potential Mitigation:
• Review and remove the accounts or groups belonging to the "schema administrators" group.