Healthcheck analysis

Check for local backdoor stored in SID History

T-SIDHistorySameDomain

The purpose is to ensure that accounts are not linked for more privileged accounts in the same domain

SID History is an attribute used in migration to link with a former account. It is not possible to have an account linked with an account belonging to the same domain. This can be analyzed by comparing the domain part of the SID History with the domain SID.

It is not possible to have this occurrence except if a user from domain A has been migrated to domain B and then migrated again to domain A. This should be strongly investigated as it may be linked to a compromise of the domain.

To remove the SIDHistory from a user account, run:
Get-ADUser USERNAME -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}
For a group, run:
Get-ADGroup GROUPNAME -properties sidhistory | foreach {Set-ADGroup $_ -remove @{sidhistory=$_.sidhistory.value}}
For all users in a OU:
Get-ADUser -SearchBase "OU=Accounts,DC=mydomain,DC=com" -Filter {sidhistory -like '*'} -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}

50 points if present

[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]
[FR]ANSSI - Accounts or groups with SID history set (vuln3_sidhistory_present)3
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection

The SIDHistory detail can be found in User information and Computer information and a quick summary in SID History

Check if dangerous SID are stored in the SIDHistory attribute.

T-SIDHistoryDangerous

The purpose is to ensure that the dangerous SID are not stored in the SIDHistory attribute.

SID History is an attribute used in migration to link with a former account.
This rule checks for SID not coming from a former domain (such as SYSTEM) or from a former domain but having a RID (the last part of the SID) lower than 1000.
Indeed, native privileged accounts have a SID lower than 1000.
A list of Well Known SID is referenced in the documentation below.

Identify the account, computer or group having these dangerous SID set in SID History, then clean it up by editing directly the SIDHistory attribute of the underlying AD object.

To remove the SIDHistory from a user account, run:
Get-ADUser USERNAME -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}
For a group, run:
Get-ADGroup GROUPNAME -properties sidhistory | foreach {Set-ADGroup $_ -remove @{sidhistory=$_.sidhistory.value}}
For all users in a OU:
Get-ADUser -SearchBase "OU=Accounts,DC=mydomain,DC=com" -Filter {sidhistory -like '*'} -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}

10 points if present

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]
[FR]ANSSI - Accounts or groups with unexpected SID history (vuln2_sidhistory_dangerous)2
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection

The SIDHistory detail can be found in User information and Computer information and a quick summary in SID History

Check if LDAPS is using Tls 1.0 or Tls 1.1.

A-DCLdapsProtocolAdvanced

The purpose is to ensure that all DC are using the most advanced protocols when acting as server.

TLS 1.0 and TLS 1.1 are no longer recommended to use, even if there is no pratical attack to could lead to an immediate compromise of the DC.
The SChannel component needs to be tuned in order to not propose these protocols. Many guidelines to handle this problem issued by Microsoft do not talk about SChannel but rather IIS. These guidlines are quoted in the documentation section below.

PingCastle is able to check the SSL version if LDAPS is exposed. LDAPS is automatically exposed once a certificate is available for the DC and the service restarted.
Please note that PingCastle is using the native .Net SSL stack to perform this test. .Net begins to ignore these weak protocols starting the version 4.7 of the framework and as a consequence, PingCasle may miss some weak protocol detection.

To test for these protocols, you can use a version of openssl with the deprecated protocols still compiled in, e.g. openssl-unsafe from Kali Linux, with the following commands:
openssl-unsafe s_client -connect dc.domain.local:636 -tls1
openssl-unsafe s_client -connect dc.domain.local:636 -tls1_1

Apply Windows updates and registry tweaks described in the documentation section to use Tls 1.2 and later.

Informative rule (0 point)

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://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#configuring-schannel-protocols-in-the-windows-registry
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space

The detail can be found in Domain controllers

Check if Service Accounts (aka accounts with never expiring password) are domain administrators

P-ServiceDomainAdmin

The purpose is to check for accounts with non-expiring passwords in the "Domain Administrator" group

PingCastle is checking accounts with never expiring password, that are mostly used as service accounts.
"Service Accounts" can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don't change and can be used in Kerberoast attacks.

Accounts with never expiring passwords are mostly service accounts.
To mitigate the security risk, it is strongly advised to lower the privileges of the "Service Accounts", meaning that they should be removed from the "Domain Administrator" group, while ensuring that the password of each and every "Service Account" is longer than 20 characters

15 points if the occurence is greater than or equals than 2

[US]STIG V-36432 - Membership to the Domain Admins group must be restricted to accounts used only to manage the Active Directory domain and domain controllers.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R11 [subsection.2.5]
[FR]ANSSI - Privileged accounts with never-expiring passwords (vuln1_dont_expire_priv)1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[MITRE]T1003.004 OS Credential Dumping: LSA Secrets

The detail can be found in Admin Groups

Check for GPO granting access to the domain without any account

A-AnonymousAuthorizedGPO

The purpose is to identify domains having a GPO which allows access to the domain without any account

It is possible that domains are set to authorize connection without any account, which represents a security breach. It allows potential attackers to enumerate all the users and computers belonging to a domain, in order to identify very efficiently future weak targets.
It is possible to verify the results provided by the PingCastle solution by using a Kali Linux distribution. You should run [rpcclient -U '' -N target_ip_address] to finally type [enumdomusers].

In order to remove the anonymous access, we advise to identify the GPO indicated by the program and change the setting restrictanonymous and restrictanonymoussam

5 points if present

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc963223%28v%3dtechnet.10%29
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj852184(v=ws.11%29
[US]STIG V-14798 - Directory data (outside the root DSE) of a non-public directory must be configured to prevent anonymous access.
[MITRE]T1110.003 Brute Force: Password Spraying

The detail can be found in Security settings

Check that the "Pre-Windows 2000 Compatible Access" group has not been modified from its default

A-PreWin2000Other

The purpose is checking that no additional account has been added to the "Pre-Windows 2000 Compatible Access" group

The pre-Windows 2000 compatible access group grants access to some RPC calls which should not be available to users or computers.

Remove the members from the PreWin2000 group while making sure that the group "Authenticated Users" is present. Then reboot each DC.

2 points if present

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7a76a403-ed8d-4c39-adb7-a3255cab82c5
[FR]ANSSI - Use of the "Pre-Windows 2000 Compatible Access" group (vuln3_compatible_2000_not_default)3
[MITRE]T1110.003 Brute Force: Password Spraying

Ensure that the Print Spooler service cannot be abused to get the DC credentials

A-DC-Spooler

The purpose is to ensure that credentials cannot be extracted from the DC via its Print Spooler service

When there's an account with unconstrained delegation configured (which is fairly common) and the Print Spooler service running on a computer, you can get that computers credentials sent to the system with unconstrained delegation as a user. With a domain controller, the TGT of the DC can be extracted allowing an attacker to reuse it with a DCSync attack and obtain all user hashes and impersonate them.

The Print Spooler service should be deactivated on domain controllers. Please note as a consequence that the Printer Pruning functionality (rarely used) will be unavailable.

10 points if present

https://adsecurity.org/?p=4056
https://www.slideshare.net/harmj0y/derbycon-the-unintended-risks-of-trusting-active-directory
[MITRE]T1187 Forced Authentication

The detail can be found in Domain controllers

RPC interfaces potentially vulnerable to Coerce attacks

A-DC-Coerce

The objective is to assess the vulnerability of the Domain Controller (DC) to Coerce attacks.

Coerce attacks are a category of attacks which aims to forcing domain controllers to authenticate to a device controlled by the attacker for the purpose to relay this authentication to gain privileges.
This category of attacks is usually mitigated by applying patch (PetitPotam), disabling services (Spooler), added RPC filter (EDR or firewall) or ensuring integrity (SMB integrity).
Because each of these protections can be individually bypassed (NTLM integrity is disabled on LDAPS), the aim of this scan is to detect proactively if vulnerable RPC services are exposed.

PingCastle estimates that Coerceable interfaces are protected if:
- the GPO "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" is applied through a GPO to DC
- or if RPC interfaces are not reachable

Because these interfaces need to be tested from a computer controlled by the attacker, PingCastle cannot do this test with reliability.
Instead, it sends a malformed RPC packet to try to trigger an error such as "Permission denied" or "RPC interface unavailable".
If the error RPC_X_BAD_STUB_DATA (1783) is triggered, PingCastle considers that the interface is available.
A report that a vulnerable interface is online may not be accurate because its full exploitation is not tested.

Also to avoid EDR alerts or to not perform the scan, you can run PingCastle with the flag --skip-dc-rpc

To effectively mitigate the vulnerability, consider one of the following approaches:

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.

10 points if present

https://github.com/p0dalirius/Coercer
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers
https://blog.nviso.eu/2023/12/08/rpc-or-not-here-we-log-preventing-exploitation-and-abuse-with-rpc-firewall/
[MITRE]T1187 Forced Authentication

The detail can be found in Domain controllers

Ensure that no accounts are subject to unconstrained delegation

P-UnconstrainedDelegation

This rule identifies accounts configured with Kerberos unconstrained delegation, a high-risk setting that allows a compromised service to impersonate any domain user and potentially lead to full domain compromise.

Kerberos unconstrained delegation allows a service to reuse a user’s Ticket Granting Ticket (TGT) to authenticate to any service in the domain. If the delegated account is compromised, cached TGTs can be extracted and used to impersonate any authenticating user.
If a privileged account or a Domain Controller authenticates to such a service, potentially via forced authentication techniques, the attacker can escalate privileges and compromise the entire domain. Disabling the account does not remove this risk, as delegation settings persist and become active again if the account is re-enabled.

Kerberos unconstrained delegation should be removed wherever it is configured. If delegation is required, it must be replaced with Kerberos constrained delegation.

Step 1: Remove Unconstrained Delegation
Remove the ability for the account to delegate credentials to any service.

Computer accounts
Set-ADComputer -Identity -TrustedForDelegation $false

User accounts
Set-ADUser -Identity -TrustedForDelegation $false

Step 2: Configure Constrained Delegation (Only If Required)

If an application requires delegation:
1. Open Active Directory Users and Computers
2. Open the account properties
3. Go to the Delegation tab
4. Select “Trust this computer for delegation to specified services only”
5. Select “Use Kerberos only”
6. Add only the specific services that are required for the application

Do not enable delegation if it is not strictly necessary.

5 points per discovery

https://learn.microsoft.com/en-us/archive/blogs/389thoughts/get-rid-of-accounts-that-use-kerberos-unconstrained-delegation
https://adsecurity.org/?p=1667
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[FR]ANSSI - Unconstrained authentication delegation (vuln2_delegation_t4d)2
[MITRE]T1187 Forced Authentication
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in User information and Computer information

Check if the mitigation for CVE-2021-42291 has been enabled

A-DsHeuristicsLDAPSecurity

The purpose is to identify domains having mitigation for CVE-2021-42291 not set to enabled

The way an Active Directory behaves can be controlled via the attribute DsHeuristics of CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration.
A parameter stored in its attribute and whose value is LDAPAddAutZVerifications and LDAPOwnerModify can be set to modify the mitigatation of CVE-2021-42291.
The KB5008383 has introduced changes to default security descriptor of Computer containers to add audit and limit computer creation without being admin.
Indeed, it is recommended to not let anyone create computer accounts as they can be used to abuse Kerberos or to perform relay attacks.

Mitigations in CVE-2021-42291 consist of 3 choices to be set on 2 settings.
They are named LDAPAddAutZVerifications and LDAPOwnerModify and are respectively the 28th and 29th character of this string.
For the expected values:
- With the value 0 (the default), it enables an additional audit mechanism
- With the value 1 (recommended), it enforces new security permissions, especially to require an action of the domain admin when unusual actions are performed
- With the value 2 (not recommended), it disables the audit mechanism that has been added by default and do not enable the new security permissions

The easiest and fastest way to correct this issue is to replace the 28th and 29th character of the DsHeuristics attribute.
The value of LDAPAddAutZVerifications and LDAPOwnerModify should be set to 1.

Open the procedure embedded into the KB5008383 to apply this mitigation and change the DsHeuristics value.

Note: You have to pay attention that there are control characters at the 10th and 20th position to avoid undesired changes of the DsHeuristics attribute.
Typically if the DsHeuristics is empty, the expected new value is 00000000010000000002000000011

Informative rule (0 point)

https://learn.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
[FR]ANSSI - Dangerous dsHeuristics settings (vuln3_dsheuristics_bad)3
[MITRE]T1187 Forced Authentication

Critical DNS zones allow anonymous updates

A-DnsZoneUpdate1

Critical DNS zones (domain zone and RootDNSServers) are configured to accept anonymous updates, allowing any device to modify DNS records without authentication.

Active Directory-integrated DNS zones can be configured to accept three types of updates: no updates (static), secure updates only (authenticated), or nonsecure and secure updates. This rule examines your most critical DNS zones to determine if they allow nonsecure updates.

The zones checked by this rule are the foundation of Active Directory operations: your primary domain DNS zone (e.g., contoso.com), the RootDNSServers zone, and _msdcs zones. The _msdcs zones are particularly critical as they contain the global catalog and domain controller locator records used by the entire Active Directory forest for authentication and replication.

When nonsecure updates are enabled (ZONE_UPDATE_UNSECURE), any device on the network can create or modify DNS records without authentication. For these critical zones, this means an attacker could redirect domain controller lookups, hijack global catalog queries, or impersonate critical AD services. The impact extends beyond a single domain - compromising _msdcs affects forest-wide operations.

The rule searches across all DNS storage locations in Active Directory: the DomainDnsZones partition (replicated domain-wide), the ForestDnsZones partition (replicated forest-wide), and the legacy storage in the domain naming context. It automatically filters out replication conflicts (CNF objects) and in-progress replication objects to avoid false positives.

This rule (A-DnsZoneUpdate1) focuses on these critical infrastructure zones. Its companion rule (A-DnsZoneUpdate2) examines all other zones in your environment.

To fix this vulnerability, configure the zone for secure-only updates:

GUI Method:
1. Open DNS Manager (dnsmgmt.msc)
2. Navigate to the affected zone
3. Right-click the zone → Properties → General tab
4. Change "Dynamic updates" from "Nonsecure and secure" to "Secure only"

PowerShell Method:

# Find all zones with insecure updates
Get-DnsServerZone | Where-Object {$_.DynamicUpdate -eq "NonsecureAndSecure"}

# Fix a specific zone
Set-DnsServerPrimaryZone -Name "contoso.com" -DynamicUpdate Secure -ComputerName DC01

# Fix all insecure zones
Get-DnsServerZone | Where-Object {$_.DynamicUpdate -eq "NonsecureAndSecure"} | ForEach-Object {
Set-DnsServerPrimaryZone -Name $_.ZoneName -DynamicUpdate Secure -ComputerName DC01
}


Command Line Method:

# Local server
dnscmd /Config <ZoneName> /AllowUpdate 2

# Remote server
dnscmd <ServerName> /Config <ZoneName> /AllowUpdate 2

# Example
dnscmd DC01 /Config contoso.com /AllowUpdate 2


15 points if present

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/f97756c9-3783-428b-9451-b376f877319a
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dnscmd
[FR]ANSSI - Misconfigured DNS zones (vuln1_dnszone_bad_prop)1
[MITRE]T1557 Man-in-the-Middle

Check if signing is really required for LDAP

A-DCLdapSign

The purpose is to check if signing is really required for LDAP

If the the request for signing of each LDAP request is not enforced, a man in the middle can be performed on an LDAP connection.
For example to add a user to the admin group.

This test is made by ignoring the local computer security policies.
Signature enforcement is done by setting the flag ISC_REQ_INTEGRITY when initializig the Negotiate / NTLM / Kerberos authentication.
The opposite test is made with the flag ISC_REQ_NO_INTEGRITY set.

PingCastle is testing if this setting is in place by performing a LDAP authentication with and without signature enforcement.
False positives may exists if the PingCastle program is run on the server tested. That's why, if PingCastle is run on a DC, the DC will not be tested.

You have to make sure that ALL LDAP clients are compatible with LDAP signature.
All versions of Windows since XP support this and also most of the Unix clients.

You have to follow the Microsoft article quoted in reference to enable LDAP signing.
This includes auditing the clients which are not compatible and instructions on how to enforce this policy.

5 points if present

https://learn.microsoft.com/en-US/troubleshoot/windows-server/identity/enable-ldap-signing-in-windows-server
https://support.microsoft.com/en-us/topic/2020-2023-and-2024-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a
https://github.com/zyn3rgy/LdapRelayScan
[MITRE]T1557 Man-in-the-Middle

Check if certificate enrollment can be done with HTTP

A-CertEnrollHttp

The purpose is to check if HTTP can be used to access the certificate enrollment interface

The Windows PKI, also named Active Directory Certificate Services (ADCS), can be used to request certificates.
Two services can be used: Certification Authority Web Enrollment (WebEnrollment) and Certificate Enrollment Web Service (CES).
The certificates provided by these services can be used with Kerberos to login.

Because this service can deliver certificates for Domain Controllers, it can be considered as part of Tier 0.
As a legacy service, the mechanisms to prohibit credential relay are not enforced by default.
If an attacker is able to relay privileged credentials (for example with the PetitPotam attack), it can be used to take control of the domain.

PingCastle is looking for enrollment servers registered in the Active Directory (pKIEnrollmentService objects).
It then connects to the special page http://xxx/certsrv/certrqxt.asp and http://xxx/yyy_CES_Kerberos/services.svc and tries to access the page with authentication.

If the authentication succeed and no error is returned,the program considers the interface accessible.

False positives may exists if the PingCastle program is run on the server tested. That's why, if PingCastle is run on the server, the server will not be tested.

The access to certificate enrollment with HTTP should be disabled.

This can be achieved by opening the IIS console on the enrollment server.
If the service quoted in detail is WebEnrollment, the url is certsrv, else it is ending by CES_Keberos.

In the Binding setting (link at the right), keep the HTTPS binding and remove the HTTP binding.
See the link to KB5005413 in references for more information.

Note: By default, the CES service is not accessible by HTTP.

5 points if present

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://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
https://www.vkernel.ro/blog/installing-and-configuring-cep-and-ces-for-certificate-enrolling-on-non-domain-joined-computers
[MITRE]T1557 Man-in-the-Middle

Check if Extended Protection is in place for certificate requests

A-CertEnrollChannelBinding

The purpose is to check if the Extended protection for HTTPS access to the certificate enrollment interface is in place

The Windows PKI, also named Active Directory Certificate Services (ADCS), can be used to request certificates.
Two services can be used: Certification Authority Web Enrollment (WebEnrollment) and Certificate Enrollment Web Service (CES).
The certificates provided by these services can be used with Kerberos to login.

Because this service can deliver certificates for Domain Controller, it can be considered as part of Tier 0.
As a legacy service, the mechanisms to prohibit credential relay are not enforced by default.
If an attacker is able to relay privileged credentials (for example with the PetitPotam attack), it can be used to take control of the domain.

To avoid this attack with HTTPS, a feature named Channel Binding exists. It consists of passing to the authentication layer a property of the TLS channel (typically a hash of the server certificate) to bind the outer channel (TLS) and the inner channel (HTTP).
This protection is also called "Extended Protection". See rfc5929 for more details.

PingCastle is looking for enrollment servers registered in the Active Directory.
It then connect to the special page https://xxx/certsrv/certrqxt.asp and https://xxx/yyy_CES_Kerberos/service.svc
An authentication is attempted with and without Channel Binding.

False positives may exists if the PingCastle program is run on the server tested. That's why, if PingCastle is run on the server, the server will not be tested.

The Extended Protection for Authentication (EPA, also called Channel Binding) should be activated on the enrollment server.

This can be achieved by opening the IIS console on the enrollment server.
In the Authentcation settings, open the Advanced Settings for the Windows Authentication.
Set "Extended Protection" to "Required".

Do this operation for the Certification Authority Web Enrollment (WebEnrollment) and Certificate Enrollment Web Service (CES).

See the link to KB5005413 below for more information. This KB also suggest to restrict the authentication to Kerberos only.

5 points if present

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://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
[MITRE]T1557 Man-in-the-Middle

Additional DNS zones allow anonymous updates

A-DnsZoneUpdate2

DNS zones other than the primary domain zone are configured to accept anonymous updates, allowing any device to modify DNS records without authentication.

Beyond the critical infrastructure zones checked by A-DnsZoneUpdate1, Active Directory typically hosts numerous additional DNS zones including reverse lookup zones (like 10.0.0.in-addr.arpa), application-specific zones, and subdomain zones. This rule examines all these secondary zones to identify those configured to accept nonsecure updates.

While these zones might seem less critical than your domain and _msdcs zones, they still present significant security risks when configured for nonsecure updates. Reverse lookup zones can be manipulated to bypass security controls that rely on PTR record validation. Application zones often contain service endpoints that, if hijacked, could redirect users to malicious services. Subdomain zones may host departmental or regional services that attackers could compromise.

The vulnerability exists when these zones are set to accept "nonsecure and secure" updates, meaning any network-connected device can modify records without proving its identity. This opens the door to DNS poisoning attacks, service hijacking, and reconnaissance activities that help attackers map your infrastructure.

Like its companion rule A-DnsZoneUpdate1, this check examines zones across all Active Directory partitions and filters out replication artifacts. Together, these two rules ensure complete coverage of your DNS security posture - with A-DnsZoneUpdate1 covering critical AD infrastructure and A-DnsZoneUpdate2 covering everything else.

To fix this vulnerability, configure all zones for secure-only updates:

GUI Method:
1. Open DNS Manager (dnsmgmt.msc)
2. Navigate to the affected zone
3. Right-click the zone → Properties → General tab
4. Change "Dynamic updates" from "Nonsecure and secure" to "Secure only"

PowerShell Method:

# Find all zones with insecure updates
Get-DnsServerZone | Where-Object {$_.DynamicUpdate -eq "NonsecureAndSecure"}

# Fix a specific zone
Set-DnsServerPrimaryZone -Name "10.0.0.in-addr.arpa" -DynamicUpdate Secure -ComputerName DC01

# Fix all insecure zones
Get-DnsServerZone | Where-Object {$_.DynamicUpdate -eq "NonsecureAndSecure"} | ForEach-Object {
Set-DnsServerPrimaryZone -Name $_.ZoneName -DynamicUpdate Secure -ComputerName DC01
}


Command Line Method:

# Local server
dnscmd /Config <ZoneName> /AllowUpdate 2

# Remote server
dnscmd <ServerName> /Config <ZoneName> /AllowUpdate 2

# Example
dnscmd DC01 /Config contoso.com /AllowUpdate 2


Note: Some zones may require nonsecure updates for DHCP or legacy systems. Document any exceptions.

1 points if present

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/f97756c9-3783-428b-9451-b376f877319a
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dnscmd
[FR]ANSSI - Misconfigured DNS zones (vuln3_dnszone_bad_prop)3
[MITRE]T1557 Man-in-the-Middle

Check if Authenticated Users can create DNS records

A-DnsZoneAUCreateChild

The purpose is to check if Authenticated Users has the right to create DNS records

When a computer is joined to a domain, a DNS record is created in the DnsZone 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.

As of today, 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.

The best mitigation is to create the DNS records manually as part as the domain join process and to revoke the permission granted to Authenticated Users.

Informative rule (0 point)

https://www.ws-its.de/gegenmassnahme-zum-angriff-dns-wildcard/
https://www.netspi.com/blog/technical/network-penetration-testing/exploiting-adidns/
[MITRE]T1557 Man-in-the-Middle

Ensure that the NTLMv1 and old LM protocols are banned

S-OldNtlm

The purpose is to check if NTLMv1 or LM can be used by DC

NTLMv1 is an old protocol which is known to be vulnerable to cryptographic attacks.
It is typically used when a hacker sniffs the network and tries to retrieve NTLM hashes which can then be used to impersonate users.

This attack can be combined with coerced authentication attacks - a hacker forces the DC to connect to a controlled host.
In this case, NTLMv1 can be specified so the hacker can retrieve the NTLM hash of the DC, impersonates it and then take control of the domain.
This attack is still possible with NTLMv2 but this is more difficult.

Windows has default security settings regarding LM/NTLM. Windows XP: Send LM & NTLM responses, Windows Server 2003: Send NTLM response only, Vista/2008: Win7/2008 R2: Send NTLMv2 response only.

However Domain Controllers have relaxed default settings to accept the connection of older operating systems.
That means that by default, NTLMv1 is accepted on domain controllers.
If no GPO defines the LAN Manager Authentication Level, the DC fall back to the non secure default.

After an audit of NTLMv1 usage (see the links below), you need to raise the LAN Manager Authentication Level to "Send NTLMv2 response only. Refuse LM & NTLM".
This can be done by editing the policy "Network security: LAN Manager authentication level" which can be accessed in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
The policy will be applied after a computer reboot.

Beware that you may break software which is not compatible with Ntlmv2 such as very old Linux stacks or very old Windows before Windows Vista.
But please note that Ntlmv2 can be activited on all Windows starting Windows 95 and other operating systems.

15 points if present

https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/audit-domain-controller-ntlmv1
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level
https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-ntlm-2-authentication
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R37 [paragraph.3.6.2.1]

The detail can be found in Security settings

Hardened Paths weakness

A-HardenedPaths

The purpose is to ensure that there is no weakness related to hardened paths

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, if 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.

You have to edit the Hardened Path section in the GPO.
This section is located in Computer Configuration/Policies/Administrative Templates/Network/Network Provider.
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.

5 points if present

https://labs.withsecure.com/publications/how-to-own-any-windows-network-with-group-policy-hijacking-attacks
https://talubu.wordpress.com/2018/02/28/configuring-unc-hardened-access-through-group-policy/
https://adsecurity.org/?p=1405
https://support.microsoft.com/en-us/topic/ms15-011-vulnerability-in-group-policy-could-allow-remote-code-execution-february-10-2015-91b4bda2-945d-455b-ebbb-01d1ec191328
[US]STIG V-63577 - Hardened UNC Paths must be defined to require mutual authentication and integrity for at least the \\*\SYSVOL and \\*\NETLOGON shares.
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay

The detail can be found in the Hardened Paths configuration section.

Check if LLMNR can be used to steal credentials

A-NoGPOLLMNR

The purpose is to ensure that local name resolution protocol (LLMNR) cannot be used to collect credentials by performing a network attack

LLMNR is a protocol which translates names such as foo.bar.com into an ip address. LLMNR has been designed to translate name locally in case the default protocol DNS is not available.
Regarding Active Directory, DNS is mandatory which makes LLMNR useless.
LLMNR exploits typo mistakes or faster response time to redirect users to a specially designed share, server or website.
Being trusted, this service will trigger the single sign on procedure which can be abused to retrieve the user credentials.

LLMNR is enabled by default on all OS except starting from Windows 10 v1903 and Windows Server v1903 where it is disabled.

Enable the GPO Turn off multicast name resolution and check that no GPO overrides this setting.
(if it is the case, the policy involved will be displayed below)

Informative rule (0 point)

https://youtu.be/Fg2gvk0qgjM
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay

The detail can be found in Security settings

Check for ESC1: Vulnerable Subject Control in Certificate Templates

A-CertTempCustomSubject

This check verifies if certificate templates in Active Directory Certificate Services (AD CS) allow user-controlled subject information and meet other common criteria associated with the ESC1 vulnerability.

ESC1 is a vulnerability in Active Directory Certificate Services (AD CS) that occurs when certificate templates allow users to control the Subject Name as well as meet other criteria, such as:

• User-Controlled Subject Name: Requesters can define the subject, enabling impersonation of any account in the domain.
• Excessive Enrollment Permissions: Large groups such as Domain Users and Authenticated Users have enrollment rights on vulnerable templates as well as the certificate authority.
• Authentication-based: Templates support Extended Key Usage (EKU) that allows the template to be used for Kerberos authentication.
• No Approval Requirements: Certificates can be issued without requiring manager approval and no authorized signatures are required.

To mitigate ESC1, use one or more of the options below:

Option 1: Modify Certificate Template Settings in ADCS

• Open Certificate Authority (certsrv.msc) on the CA server.
• Right-click on Certificate Templates and select Manage.
• Navigate to and right-click the vulnerable template and select Properties.
• Go to the Subject Name tab:
  • Ensure "Supply in the request" is unchecked.
• Click OK to save changes.

• Open Certificate Authority (certsrv.msc) on the CA server.
• Right-click on Certificate Templates and select Manage.
• Navigate to and right-click the vulnerable template and select Properties.
• Go to the Security tab:
  • Remove well-known low-privileged groups such as Authenticated Users, Everyone from enrollment permissions.
  • Assign only the required accounts and groups permission to request these certificates.
• Click OK to save changes.

• Open Active Directory Sites and Services (dssite.msc).
• From the top menu, click View and select Show Services Node.
• Navigate to Services > Public Key Services > NTAuthCertificates.
• Right-click the CACertificate attribute and select Properties.
  • Review the listed certificates.
  • Remove the entry for the affected CA by selecting it and clicking Remove.
• Click OK to apply the changes.

15 points if present

Certified-PreOwned https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
[FR]ANSSI - Dangerous enrollment permission on authentication certificate templates (vuln1_adcs_template_auth_enroll_with_name)1
[MITRE]T1558 Steal or Forge Kerberos Tickets

The detail can be found in Certificate Templates

Check the permission of agent certificate templates

A-CertTempAgent

The purpose of this rule is to ensure that there is no agent certificate that can be requested by anyone

An Agent certificate is a special certificate used to request certificates on behalf of other users.
A template has been detected with the agent EKU and that can be enrolled by a large number of users.

Review the permissions that allow a wide enrollment of this certificate template

15 points if present

https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
[FR]ANSSI - Dangerous enrollment permission on authentication certificate templates (vuln1_adcs_template_auth_enroll_with_name)1
[MITRE]T1558 Steal or Forge Kerberos Tickets

The detail can be found in Certificate Templates

Check for ESC2: Vulnerable EKU Configurations in Certificate Templates

A-CertTempAnyPurpose

This check verifies whether certificate templates in Active Directory Certificate Services (AD CS) have the "Any Purpose" Enhanced Key Usage (EKU) or lack an EKU entirely, potentially enabling privilege escalation or misuse.

Enhanced Key Usage (EKU) defines the intended purpose of a certificate. ESC2 arises when the following EKUs are defined along with other vulnerable criteria that enable low privileged users to request the certificate with no oversight.

• "Any Purpose" EKU is enabled: This allows the certificate to be used for any purpose, including unintended ones such as authentication or code signing.
• No EKU defined: Certificates without an EKU are treated as having "Any Purpose," making them similarly vulnerable.

• The certificate template has a vulnerable EKU as described above
• The certificate template allows excessive enrollment permissions
• The CA allows excessive enrollment permissions
• The certificate template does not require manager approval
• The certificate template does not have any authorised signatures

There are multiple ways in which remediation of this issue can be completed. It involves restricting the template in one or more ways using the instructions below.

1. Open Certificate Authority (certsrv.msc) and connect to the CA
2. Navigate to Certificate Templates, right-click and select Manage
3. Right-click the vulnerable template, and select Properties

• Go to the Security tab
• Remove excessive enrolment permissions (e.g., Domain Users or Authenticated Users)
• Grant permissions only to necessary accounts/groups

• Go to the Issuance Requirements tab
• Tick the “CA certificate manager approval” option

• Go to the Extensions tab
• Click on Application Policies and select Edit
• Add the required application policies
• Remove the Any Purpose usage if present
• Click OK

15 points if present

https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
[FR]ANSSI - Dangerous enrollment permission on authentication certificate templates (vuln1_adcs_template_auth_enroll_with_name)1
[MITRE]T1558 Steal or Forge Kerberos Tickets

The detail can be found in Certificate Templates

Ensure that DC supports Kerberos armoring when functional level is at least Windows Server 2012

S-KerberosArmoringDC

The purpose is to ensure that DC supports Kerberos armoring when functional level is at least Windows Server 2012

Kerberos Armoring is an optimization of the Kerberos protocol. It avoids the pre-authentication steps and thereby prevents pre-authentication attacks.
It is supported only starting Windows Server 2012 DC and Windows 8 workstations.
If Kerberos Armoring is requested for other operating systems (such as Windows 7 or Linux), the Kerberos authentication protocol may refuse to work.

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".

The safest settings is "Fail authentication requests when Kerberos armoring is not available" but it should be enabled only if the clients support Kerberos armoring.

Informative rule (0 point)

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831747(v=ws.11)
https://pupuweb.com/solved-how-enable-kerberos-armoring-eap-fast-ad/
[MITRE]T1558 Steal or Forge Kerberos Tickets

If activated, the detail can be found in Security settings

Check if admin accounts are vulnerable to the Kerberoast attack.

P-Kerberoasting

The purpose is to ensure that the password of admin accounts cannot be retrieved using the Kerberoast attack.

To access a service using Kerberos, a user requests a ticket (named TGS) to the DC specific to the service.
This ticket is encrypted using a derivative of the service password, but can be brute-forced to retrieve the original password.
Any account having the attribute SPN populated is considered as a service account.
Given that any user can request a ticket for a service account, these accounts can have their password retrieved.
In addition, services are known to have their password not changed at a regular basis and to use well-known words.

Please note that this program ignores service accounts that had their password changed in the last 40 days ago to support using password rotation as a mitigation.

If the account is a service account, the service should be removed from the privileged group or have a process to change its password at a regular basis.
If the user is a person, the SPN attribute of the account should be removed.

5 points per discovery

https://adsecurity.org/?p=3466
[FR]ANSSI - Privileged accounts with SPN (vuln1_spn_priv)1
[MITRE]T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting

The detail can be found in Admin Groups

Check the use of Kerberos on services accounts without AES support

S-AesNotEnabled

The purpose is to verify that AES is enabled for service accounts.

The default encryption algorithm used by Kerberos is RC4, which directly utilizes the NTLM hash of the user’s password.
However, due to the rapid advancements in computing power, it’s recommended to transition from RC4 to the more secure AES algorithm.

Before disabling RC4, the first step is to enable AES.
It’s important to note that service accounts and user accounts with the ‘serviceprincipalname’ attribute (also known as SPN) need to be configured to support AES.
Without this configuration, AES will not be fully operational.

Accounts are listed if :
1) no password changed occured after the first DC Win 2008 install to initate AES secrets or
2) they have a SPN and the account is not flaged to use AES for encryption with msDS-SupportedEncryptionTypes

Also be advised that other checks must be performed before disabling RC4 (such as trust accounts, ...). A dedicated section in this report explores AES compatibility.

It is recommended to enable AES as an encryption algorithm in the user configuration dialog or in the "msDSSupportedEncryptionTypes" attribute at LDAP level.
It has to be enabled in the property of an account by checking all the boxes "This account supports Keberos AES XXX encryption".

For GMSA account, you have to manually edit the property msDS-SupportedEncryptionTypes

Informative rule (0 point)

https://learn.microsoft.com/en-us/archive/blogs/openspecification/msds-supportedencryptiontypes-episode-1-computer-accounts
[FR]ANSSI - Service accounts supported encryption algorithms (vuln3_kerberos_properties_encryption)3
[MITRE]T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting

The detail can be found in User information and Computer information

Ensure that the rootDse Anonymous Binding is disabled

A-RootDseAnonBinding

The purpose is to ensure that Anonymous Binding on RootDse is not enabled

The rootDse is a special object that enables clients to discover the functionalities of the server, such as LDAP version or support for special processing.
On Windows, it can be accessed by default without binding, which allows everyone to access this data.
There is no confidential data in this attribute, only the Operating System version and the name of the domain.
Since Windows 2019, the rootDse access can be set to require authentication.
You can test the anonymous access of the rootDse object by launching ldp.exe and selecting 'Connect' on the Connection menu.
You should receive the error "The server has been configured to deny unauthenticated simple binds."

Edit the attribute msDS-Other-Settings of the object CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration.
Add a new line with the content: DenyUnauthenticatedBind=1

Informative rule (0 point)

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3f0137a1-63df-400c-bf97-e1040f055a99
https://blog.lithnet.io/2018/12/disabling-unauthenticated-binds-in.html
[MITRE]T1018 Remote System Discovery

Check if there is a control path involving everyone-like groups.

P-ControlPathIndirectEveryone

The purpose is to ensure that there is no control path involving everyone.

If you have access to a key server and the helpdesk can reset your password, then the helpdesk has access to the key server.
This is the kind of logic used by hackers to take control of the domain using key infrastructure objects (domain root, ...) or groups (domain administrators, ...).
Permissions are collected and analyzed to produce a control paths analysis.
Only write permissions (and specific ones) are used for this analysis.
Then the program identifies which users or computers, that are not members of known groups, can take control of this object.
To be fast, some tradeoffs have been selected. For example, logged on users on servers are ignored.
The program may also select paths which are not exploitable and ignore paths if it cannot read every permissions.
[Everyone] includes the user groups Anonymous, Everyone, Authenticated Users, Domain Users, Domain Computers and Builtin.

You should analyze the chart and determine which underlying object is involved and grants write permissions to everyone.
Then edit the permissions and locate the write permission involved.
Then delete it or replace it according to your delegation model.

25 points if present

https://github.com/BloodHoundAD/BloodHound
https://github.com/ANSSI-FR/AD-control-paths
[MITRE]T1069.002 Permission Groups Discovery: Domain Groups

The detail can be found in Control Paths Analysis

Check if NetCease has been put in place to mitigate Bloodhound

A-NoNetSessionHardening

The purpose is to ensure that mitigations are in place against the Bloodhound tool

By default, Windows computers allow any authenticated user to enumerate network sessions to it.
This means an attacker could enumerate network sessions to a file share hosting home directories or a Domain Controller to see who's connected to SYSVOL (to apply Group Policy) and determine which workstations each user and admin account is logged into.
Bloodhound uses this capability extensively to map out credentials in the network.

Disabling Net Session Enumeration removes the capability for any user to enumerate net session info (Recon).

If this mitigation is not part of the computer image, apply the following recommendations:
Run the NetCease PowerShell script (referenced below) on a reference workstation.
Open the Group Policy Management Console. Right-click the Group Policy object (GPO) that should contain the new preference item, and then click Edit .
In the console tree under Computer Configuration, expand the Preferences folder, and then expand the Windows Settings folder.
Right-click the Registry node, point to New, and select Registry Wizard.
Select the reference workstation on which the desired registry settings exist, then click Next .
Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\DefaultSecurity\
and select the check box for “SrvsvcSessionInfo” from which you want to create a Registry preference item. Select the check box for a key only if you want to create a Registry item for the key rather than for a value within the key.
Click Finish.
The settings that you selected appear as preference items in the Registry Wizard Values collection

Informative rule (0 point)

https://github.com/p0w3rsh3ll/NetCease
https://adsecurity.org/?p=3299
[MITRE]T1087.001 Account Discovery: Local Account

The detail can be found in Security settings

Check for short password length in password policy

A-MinPwdLen

The purpose is to verify if the password policy of the domain enforces users to have at least 8 characters in their password

A check is performed to identify if the GPO regarding password policy allows less than 8 characters password. Short passwords represent a high risk because they can fairly easily be brute-forced or password sprayed. Most CERT and agencies advise for at least 8 characters (and often this number goes up to 12)

To solve the issue, the best way is to either remove the GPO enabling short password, or to modify it in order to increase the password length to at least 8 characters

10 points if present

https://www.microsoft.com/en-us/research/publication/password-guidance/
[FR]ANSSI - Privileged group members with weak password policy (vuln2_privileged_members_password)2
[MITRE]T1201 Password Policy Discovery

The detail can be found in Password policies

Check the Password Policy for Service Accounts (Information)

A-NoServicePolicy

The purpose is to give information regarding a best practice for the Service Account password policy. Indeed, having a 20+ characters password for this account greatly helps reducing the risk of Kerberoasting attacks (offline cracking of the TGS tickets)
Note: PSO (Password Settings Objects) will be visible only if the user, which collected the information, has the permission to view it.

The rule is purely informative, as it gives insights regarding a best practice. It verifies if there is a GPO or PSO enforcing a 20+ characters password for the Service Accounts.

The recommended way to handle service accounts is to use "Managed service accounts" introduced since Windows Server 2008 R2 (search for "msDS-ManagedServiceAccount").
To solve the anomaly, you should implement a PSO or GPO password guarantying a 20+ length password.

Informative rule (0 point)

https://www.microsoft.com/en-us/research/publication/password-guidance/
[MITRE]T1201 Password Policy Discovery

The detail can be found in Password Policies

Check for local backdoor stored in SID History

T-SIDHistorySameDomain

The purpose is to ensure that accounts are not linked for more privileged accounts in the same domain

SID History is an attribute used in migration to link with a former account. It is not possible to have an account linked with an account belonging to the same domain. This can be analyzed by comparing the domain part of the SID History with the domain SID.

It is not possible to have this occurrence except if a user from domain A has been migrated to domain B and then migrated again to domain A. This should be strongly investigated as it may be linked to a compromise of the domain.

To remove the SIDHistory from a user account, run:
Get-ADUser USERNAME -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}
For a group, run:
Get-ADGroup GROUPNAME -properties sidhistory | foreach {Set-ADGroup $_ -remove @{sidhistory=$_.sidhistory.value}}
For all users in a OU:
Get-ADUser -SearchBase "OU=Accounts,DC=mydomain,DC=com" -Filter {sidhistory -like '*'} -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}

50 points if present

[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]
[FR]ANSSI - Accounts or groups with SID history set (vuln3_sidhistory_present)3
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection

The SIDHistory detail can be found in User information and Computer information and a quick summary in SID History

At least one administrator account can be delegated

P-Delegated

The purpose is to ensure that all Administrator Accounts have the configuration flag "this account is sensitive and cannot be delegated" (or are members of the built-in group "Protected Users" when your domain functional level is at least Windows Server 2012 R2).

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.

To correct the situation, you should make sure that all your Administrator Accounts have the check-box "This account is sensitive and cannot be delegated" active or add your Administrator Accounts to the built-in group "Protected Users" if your domain functional level is at least Windows Server 2012 R2 (some functionalities may not work properly afterwards, you should check the official documentation).
If you want to enable the check-box "This account is sensitive and cannot be delegated" but this is not possible because the box is not present (typically for GMSA accounts), you can add the flag manually by adding the number 1048576 to the attribute useraccountcontrol of the account.
Please note that there is a section below in this report named "Admin Groups" which gives more information.

20 points if present

[US]STIG V-36435 - Delegation of privileged accounts must be prohibited.
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in Admin Groups

Check for hidden group membership for user accounts

S-PrimaryGroup

The purpose is to check for unusual values in the primarygroupid attribute used to store group memberships

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. It can be used to store hidden membership as this attribute is not often analyzed.

Unless strongly justified, change the primary group id to its default: 513 or 514 for users, 516 or 521 for domain controllers, 514 or 515 for computers. The primary group can be edited in a friendly manner by editing the account with the "Active Directory Users and Computers" and after selecting the "Member Of" tab, "set primary group".
You can use the following script to list Users with a primary group id different from domain users:
$DomainUsersSid = New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::AccountDomainUsersSid,(Get-ADDomain).DomainSID)

Get-ADUser -Filter * -Properties PrimaryGroup | Where-Object { $_.PrimaryGroup -ne (Get-ADGroup -Filter {SID -eq $DomainUsersSid} ).DistinguishedName } | Select-Object UserPrincipalName,PrimaryGroup

15 points if present

[FR]ANSSI - Accounts with modified PrimaryGroupID (vuln3_primary_group_id_nochange)3
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in User information and Computer information

Ensure that GPO items cannot be modified by any user

P-DelegationGPOData

The purpose is to ensure that standard users cannot modify GPO

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

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.

15 points per discovery

[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[US]STIG V-2370 - The access control permissions for the directory service site group policy must be configured to use the required access permissions.
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Ensure that no accounts are subject to unconstrained delegation

P-UnconstrainedDelegation

This rule identifies accounts configured with Kerberos unconstrained delegation, a high-risk setting that allows a compromised service to impersonate any domain user and potentially lead to full domain compromise.

Kerberos unconstrained delegation allows a service to reuse a user’s Ticket Granting Ticket (TGT) to authenticate to any service in the domain. If the delegated account is compromised, cached TGTs can be extracted and used to impersonate any authenticating user.
If a privileged account or a Domain Controller authenticates to such a service, potentially via forced authentication techniques, the attacker can escalate privileges and compromise the entire domain. Disabling the account does not remove this risk, as delegation settings persist and become active again if the account is re-enabled.

Kerberos unconstrained delegation should be removed wherever it is configured. If delegation is required, it must be replaced with Kerberos constrained delegation.

Step 1: Remove Unconstrained Delegation
Remove the ability for the account to delegate credentials to any service.

Computer accounts
Set-ADComputer -Identity -TrustedForDelegation $false

User accounts
Set-ADUser -Identity -TrustedForDelegation $false

Step 2: Configure Constrained Delegation (Only If Required)

If an application requires delegation:
1. Open Active Directory Users and Computers
2. Open the account properties
3. Go to the Delegation tab
4. Select “Trust this computer for delegation to specified services only”
5. Select “Use Kerberos only”
6. Add only the specific services that are required for the application

Do not enable delegation if it is not strictly necessary.

5 points per discovery

https://learn.microsoft.com/en-us/archive/blogs/389thoughts/get-rid-of-accounts-that-use-kerberos-unconstrained-delegation
https://adsecurity.org/?p=1667
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[FR]ANSSI - Unconstrained authentication delegation (vuln2_delegation_t4d)2
[MITRE]T1187 Forced Authentication
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in User information and Computer information

Check if dangerous SID are stored in the SIDHistory attribute.

T-SIDHistoryDangerous

The purpose is to ensure that the dangerous SID are not stored in the SIDHistory attribute.

SID History is an attribute used in migration to link with a former account.
This rule checks for SID not coming from a former domain (such as SYSTEM) or from a former domain but having a RID (the last part of the SID) lower than 1000.
Indeed, native privileged accounts have a SID lower than 1000.
A list of Well Known SID is referenced in the documentation below.

Identify the account, computer or group having these dangerous SID set in SID History, then clean it up by editing directly the SIDHistory attribute of the underlying AD object.

To remove the SIDHistory from a user account, run:
Get-ADUser USERNAME -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}
For a group, run:
Get-ADGroup GROUPNAME -properties sidhistory | foreach {Set-ADGroup $_ -remove @{sidhistory=$_.sidhistory.value}}
For all users in a OU:
Get-ADUser -SearchBase "OU=Accounts,DC=mydomain,DC=com" -Filter {sidhistory -like '*'} -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}

10 points if present

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]
[FR]ANSSI - Accounts or groups with unexpected SID history (vuln2_sidhistory_dangerous)2
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection

The SIDHistory detail can be found in User information and Computer information and a quick summary in SID History

Check for completeness of network declaration

S-DC-SubnetMissing

The purpose is to ensure that the minimum set of subnet(s) has been configured in the domain

When multiple sites are created in a domain, networks should be declared in the domain in order to optimize processes such as DC attribution. In addition, PingCastle can collect the information to be able to build a network map. This rule has been triggered because at least one domain controller has an IP address which was not found in subnet declaration. These IP addresses have been collected by querying the DC FQDN IP address in both IPv6 and IPv4 format.

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.

5 points if present

[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in Domain controllers

Check if the protection against revealing privileged group is active

P-RODCNeverReveal

The purpose is to ensure that the protection against revealing privileged group is active

In addition to the group Denied RODC Password Replication Group there is a custom setting set for RODC in an attribute named msDS-NeverRevealGroup.
This rule checks the current value against the default one.

Check the value of the attribute msDS-NeverRevealGroup and the presence of the following expected groups:
- Administrators;
- Server Operators;
- Account Operators;
- Backup Operators;
- Denied RODC Password Replication Group

This can be managed in the Password Replication Policy tab of the computer object in the Active Directory Users and Computers console.

5 points if present

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8dfc81be-7461-48f2-8caf-07402bccb0ea
[FR]ANSSI - Dangerous configuration of read-only domain controllers (RODC) (neverReveal) (vuln3_rodc_never_reveal)3
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in Domain controllers

Check if privileged users have been revealed on RODC

P-RODCAdminRevealed

The purpose is to check if privileged users have already been revealed

On Active Directory, all users revealed to a RODC are tracked by an attribute set on the computer object of the RODC named msDS-RevealedUsers.
The program checks on the list of revealed users if one of them is known as a privileged user.
Indeed, the RODC is caching the authentication secrets related of this user, which can then be used to impersonate it.
In addition to that, RODC are placed in general on more riskier environment.

The admin account should have its secrets change (a password reset) and be sure that the account will not be revealed anymore.

5 points per discovery

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8dfc81be-7461-48f2-8caf-07402bccb0ea
[FR]ANSSI - Privileged users revealed on RODC (vuln2_rodc_priv_revealed)2
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in Domain controllers

Check the Allowed RODC Password Replication Group group

P-RODCAllowedGroup

The purpose is to ensure that the Allowed RODC Password Replication Group group is empty.

Accounts belonging to the Allowed RODC Password Replication Group group have their password hashes revealed on all RODCs.

This group should be emptied, and dedicated groups should only be added to the Password Replication Policy of each relevant RODC.

5 points if present

[FR]ANSSI - Dangerous configuration of replication groups for read-only domain controllers (RODCs) (allow) (vuln3_rodc_allowed_group)3
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Check that there is no account with never-expiring passwords

S-PwdNeverExpires

The purpose is to ensure that every account has a password which is compliant with password expiration policies

Some accounts have passwords which never expire. Should an attacker compromise one of these accounts, he would be able to maintain long-term access to the Active Directory domain.

We have noted that some Linux servers, domain joined, are configured with a password which never expires.
This is a misconfiguration because a password change can be configured. It was however not the default on some plateform.
See one of the link below for more information.

In order to make Active Directory enforce periodic password change, accounts must not have the "Password never expires" flag set in the "Account" tab of the user properties. Their passwords should then be rolled immediately.
For service accounts, Windows provides the "managed service accounts" and "group managed service accounts" features to facilitate the automatic change of passwords.
Please note that there is a document in the section below which references solutions for service accounts of well known products.
Also Linux servers should be configured with automatic machine account change.

1 points if present

https://adsecurity.org/?p=4115
https://access.redhat.com/discussions/1283873
[FR]ANSSI - Accounts with never-expiring passwords (vuln2_dont_expire)2
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in User information

Check if AES is enabled on trusts

T-AlgsAES

The purpose is to check if AES can be used with Kerberos on trusts

By default, RC4 is used as the signature algorithm on Kerberos tickets.
If AES is enabled on a domain and AES is not enabled on trust, AES tickets will not be usable on the trust. The Kerberos tickets sent to the trust will fail or the trusted domain will fallback to NTLM.

The encryption algorithms allowed for a trust are stored in an attribute named msDS-SupportedEncryptionTypes.
If this attribute is not set (or has a value of zero), RC4 will be applied by default.
Else, it defines the algorithm to use for Kerberos signature.

Enable AES on the domain.

Beware: there is a checkbox in the trust properties named "The other domain supports Kerberos AES Encryption".
If you enable this setting, AES will be enabled but RC4 will also be disabled.

The recommended way is to enable both RC4 and AES as a transition. It can be done by running the command:
ksetup /setenctypeattr mytrust.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

This way, the attribute msDS-SupportedEncryptionTypes of the trust will be modified to support both RC4 and AES.

1 points if present

https://techcommunity.microsoft.com/t5/itops-talk-blog/tough-questions-answered-can-i-disable-rc4-etype-for-kerberos-on/ba-p/382718
https://learn.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
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Verify Terminal Services configuration best practices in GPO

S-TerminalServicesGPO

This rule verifies the recommended configuration for Terminal Services.

It is a common practice for hackers to look for open sessions on remote servers.
This can be done by attempting to open the user registry and checking if there is an access denied error or if the registry hive is not available at all.
If found, the hacker can exploit this information by targeting this computer, or if the session is still active, hijack it and impact the client computer.
Indeed, you can access the local drive by default and push a malicious file such as a login script in the start menu of the remote user.
Another alternative is if the session is not secure, to capture the credentials in memory.

The printer redirection has no known attack pattern.
However due to past vulnerabilites with the Printer spooler, the complexity of the underlying protocol, the relative absence of need to this feature, we recommend to block it.
It can also be a bypass for copy / paste restriction and it is recommended to deny it in most admin bastion.

The Terminal Services configuration can be found in Policies / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session Host
The details of this rule is located in Printer Redirection and Session Time Limits.

PingCastle recommends to set the following Policy:
Set time limit for disconnected sessions: 2h (aka MaxDisconnectionTime)
Set time limit for active but idle Remote Desktop Services sessions: 8h (aka MaxIdleTime)
Do not allow client printer redirection: Enabled (aka fDisableCpm)

This rule is active if nothing is set or if the time limit is set to NEVER.

Informative rule (0 point)

https://woshub.com/remote-desktop-session-time-limit/
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-tsts/ce70794f-2138-43e8-bf6c-2c147887d6a2
https://community.spiceworks.com/t/are-redirected-printers-a-security-risk/826344/27
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Verify if there are restrictions for internet connectivity of script engines

S-FirewallScript

This rule verifies whether programs, such as script engines, are allowed to connect to the internet by default.

Malicious scripts, often distributed via phishing emails, frequently attempt to connect to the internet to propagate their infection.
To mitigate this risk, we recommend implementing a set of firewall rules through Group Policy Objects (GPOs).
These rules will prohibit direct internet connections for specific programs.

The current list of programs to restrict includes: wscript.exe, mshta.exe, cscript.exe, conhost.exe, and runScriptHelper.exe.

1) Create Firewall Rules via GPO

Configure the firewall rules under Computer Configuration / Policies / Windows Settings / Security Settings / Windows Defender Firewall with Advanced Security.
Ensure the rules are applied on the Outbound side.
Activate the rules.

2) Network Restrictions:
We recommend setting the rules as active for the following IP address ranges to allow local network access:
0.0.0.0 to 9.255.255.255
11.0.0.0 to 126.255.255.255
128.0.0.1 to 172.15.255.255
172.32.0.0 to 192.167.255.255
192.169.0.0 to 255.255.255.255

Alternatively, you can choose to apply the rules to ALL IP addresses or add your internal proxy IP.

Informative rule (0 point)

https://medium.com/@cryps1s/endpoint-isolation-with-the-windows-firewall-462a795f4cfb
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in Firewall configuration

Verify that Defender ASR mitigations are in place

S-DefenderASR

This rule confirms the activation of Defender ASR (Attack Surface Reduction) mitigations within a Group Policy Object (GPO).

Microsoft Defender, the default antivirus included with Windows, activates automatically on systems without a pre-installed alternative.
Defender’s ASR features, designed to minimize vulnerability to attacks, are available even in the standard version.
These protections have been part of Windows since the release of Windows 10 version 1710 and are also applicable to Windows Server 2012 R2.

Note: Windows 11 may enable in some conditions those 3 ASR rules: Block abuse of exploited vulnerable signed drivers, Block credential stealing from the Windows local security authority subsystem (lsass.exe), Block persistence through WMI event subscription

To apply an ASR mitigation, navigate to the GPO setting "Configure Attack Surface Reduction rules" found under Computer Configuration > Policies > Administrative Templates > Windows Components > Microsoft Defender Antivirus (formerly Windows Defender Antivirus) > Microsoft (Windows) Defender Exploit Guard > Attack Surface Reduction.
Upon enabling this setting, select "Set the state for each ASR rule".
Then, input the mitigation’s GUID as the Value name and assign 1 as the Value to enforce the rule in Block mode.
Other configurable values include 2 for Audit mode and 6 for Warn mode.
For instance, to block JavaScript or VBScript from executing downloaded executable content, use the GUID: d3e037e1-3eb8-44c8-a917-57927947596d.
It is recommended to set Defender ASR rules as recommended in the article below.


Prior to implementation, conduct an impact analysis to anticipate any potential disruptions, and utilize Audit mode to identify possible issues.

Informative rule (0 point)

https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide#per-asr-rule-alert-and-notification-details
https://blog.palantir.com/microsoft-defender-attack-surface-reduction-recommendations-a5c7d41c3cf8
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in Defender ASR

Verify the Default Application for Script File Execution

S-FolderOptions

The objective is to ensure scripts do not automatically execute upon opening by default.

By default, PowerShell scripts (.ps1) open in Notepad, which blocks these extensions from being exploited in phishing attacks that evade email filters through multi-layered archives.
However, several legacy script extensions (.js, .jse, .vbs, .vbe, .vb, .wsh, .wsf) still execute with their respective engines.
While .js and .jse files are commonly associated with web content and handled by browsers, it’s crucial to recognize their potential for harm when executed directly in Windows.
Redirecting these files to open in Notepad safeguards against inadvertent execution without affecting web browsing.
The browser navigation is not impacted by this recommendation.
Review is recommended for other script files before implementing this security measure.

Note: Javascript execution can be mitigated by an "Attack surface reduction rule" named "Impede JavaScript and VBScript to launch executables" available since Windows 10, version 1709.
But we still recommend to apply the folder options mitigation as it is more effective.

Navigate to Computer Configuration > Preferences > Control Panel Settings > Folder Options.
Create a new File Type with the "Replace" action for the extension you wish to secure.
In "Configure class settings", add a new "open" action with Notepad as the default application: C:\Windows\System32\notepad.exe.

Informative rule (0 point)

https://isc.sans.edu/diary/Controlling+JavaScript+Malware+Before+it+Runs/21171
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in Folder Options

Check if OUs and Containers are protected from accidental deletion.

P-UnprotectedOU

The purpose is to ensure that Organizational Units (OUs) and Containers in Active Directory are protected to prevent accidental deletion, which could lead to data loss and disruptions in the network infrastructure.

In Active Directory, Organizational Units can be protected from accidental deletion (reads: using the del key in the wrong place at the wrong time).
This way these objects cannot be deleted, unless the protection is removed. This Active Directory feature was first introduced in Windows Server 2008.

This protection consists of a Deny ACE added to the NTSecurityDescriptor attribute applied to Everyone with the flag set to Delete and DeleteTree.

To safeguard against accidental deletions, it is essential to enable the "Protect object from accidental deletion" option for critical OUs and Containers.
When this option is enabled, it adds an additional layer of security, preventing unintended deletions.
To implement this protection:

* Open the Active Directory Users and Computers management console.
* Locate the OU or Container that requires protection.
* Right-click on the OU or Container, select "Properties."
* In the "Object" tab, check the "Protect object from accidental deletion" option.
* Click "Apply" and then "OK" to save the changes.

You can list unprotected OU using the PowerShell command:
Get-ADOrganizationalUnit -filter {name -like "*"} -Properties ProtectedFromAccidentalDeletion | format-table Name,ProtectedFromAccidentalDeletion
and protect them using the command:
Get-ADOrganizationalUnit -filter {name -like "*"} -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

Note: only 10 will be listed below. Checkout the Delegations section for the complete list.

Informative rule (0 point)

https://dirteam.com/sander/2011/07/13/preventing-ous-and-containers-from-accidental-deletion/
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in Delegations

Check for the last backup date according to Microsoft standard

A-BackupMetadata

The purpose is to check if the backups are actually up to date in case they are needed. The alert can be triggered when a domain is backed up using non-recommended methods

A verification is done on the backups, ensuring that the backup is performed according to Microsoft standards. Indeed, at each backup the DIT Database Partition Backup Signature is updated. If for any reasons, backups are needed to perform a rollback (rebuild a domain) or to track past changes, the backups will actually be up to date. This check is equivalent to a REPADMIN /showbackup *.

Plan AD backups based on Microsoft standards. These standards depend on the Operating System. For example with the wbadmin utility: wbadmin start systemstatebackup -backuptarget:d:

15 points if the occurence is greater than or equals than 7

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj130668(v=ws.10)
[US]STIG V-25385 - Active Directory data must be backed up daily for systems with a Risk Management Framework categorization for Availability of moderate or high. Systems with a categorization of low must be backed up weekly.
[MITRE]Mitre Att&ck - Mitigation - Data Backup

The detail can be found in Backup

Check if Service Accounts (aka accounts with never expiring password) are domain administrators

P-ServiceDomainAdmin

The purpose is to check for accounts with non-expiring passwords in the "Domain Administrator" group

PingCastle is checking accounts with never expiring password, that are mostly used as service accounts.
"Service Accounts" can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don't change and can be used in Kerberoast attacks.

Accounts with never expiring passwords are mostly service accounts.
To mitigate the security risk, it is strongly advised to lower the privileges of the "Service Accounts", meaning that they should be removed from the "Domain Administrator" group, while ensuring that the password of each and every "Service Account" is longer than 20 characters

15 points if the occurence is greater than or equals than 2

[US]STIG V-36432 - Membership to the Domain Admins group must be restricted to accounts used only to manage the Active Directory domain and domain controllers.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R11 [subsection.2.5]
[FR]ANSSI - Privileged accounts with never-expiring passwords (vuln1_dont_expire_priv)1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[MITRE]T1003.004 OS Credential Dumping: LSA Secrets

The detail can be found in Admin Groups

Avoid unexpected schema modifications which could result in domain rebuild

P-SchemaAdmin

The purpose is to ensure that no account can make unexpected modifications to the schema

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.

Remove the accounts or groups belonging to the "schema administrators" group.

10 points if present

[US]STIG V-72835 - Membership to the Schema Admins group must be limited
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R13 [subsection.3.2]
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

The detail can be found in Admin Groups

Check if there is a policy preventing administrators to connect to lower tier systems.

P-LogonDenied

The purpose is to ensure that there is a tier isolation.

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, DC) 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.

To check for this policy, PingCastle looks at all GPOs and checks, if there is a GPO denying logon (SeDenyRemoteInteractiveLogonRight, SeDenyInteractiveLogonRight) of admins (Domain Admins or Administrators) to a specific scope.

False positives can occurs for this rule:
* if the expected GPO is hidden due to ACL checks
* if the targeted group is not "checked" when saving the GPO. Indeed, the group will be saved as is without a conversion to its technical name and it will prohibit a match if there are groups internationalized, aka renamed given a specific language.

As a consequence, only one deny policy on one group will fulfill this requirements. The program also does not check if the GPO is applied on an Organizational Unit or a Container.
Also this rule is enforced only if there are more than 200 users and 200 computers.

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.

1 points if present

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-f--securing-domain-admins-groups-in-active-directory
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

The detail can be found in GPO Login

Check if all privileged accounts are in the special group Protected Users.

P-ProtectedUsers

The purpose is to ensure that all privileged accounts are in the Protected User security group

The Protected User group is a special security group which automatically applies protections to minimize credential exposure. Starting with Windows 8.1. Older Operating System must be updated to take this protection in account such as the Windows 7 KB2871997 patch.
For admins, it:
- Disables NTLM authentication
- Reduces Kerberos ticket lifetime
- Mandates strong encryption algorithms, such as AES
- Prevents password caching on workstations
- Prevents any type of Kerberos delegation

Please also note that a few links (see below) recommends that at least one account is kept outside of the group Protected Users in case there is a permission problem.
That's why this rule is not triggered if only one account is not protected.

After having reviewed the potential impact on adding users to this group, add the missing privileged accounts to this group.

10 points if the occurence is greater than or equals than 2

https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
https://blog.netwrix.com/2015/02/20/add-sensitive-user-accounts-to-active-directory-protected-users-group/
https://dirteam.com/sander/2014/11/25/ten-things-you-need-to-be-aware-of-before-using-the-protected-users-group/
https://blog.andreas-schreiner.de/2018/09/07/active-directory-sicherheit-teil-1-privilegierte-benutzer/
[US]STIG V-78131 - Accounts with domain level administrative privileges must be members of the Protected Users group in domains with a domain functional level of Windows 2012 R2 or higher.
[FR]ANSSI CERTFR-2017-ALE-012
[FR]ANSSI - Privileged accounts outside of the Protected Users group (vuln3_protected_users)3
[MITRE]Mitre Att&ck - Mitigation - Privileged Process Integrity

The detail can be found in Admin Groups

Obsolete OS (Windows 10 or Windows 11)

S-OS-W10