egia.com - Healthcheck analysis

Check for certificates using a weak signing algorithm (RSA under 1024 bits)

A-WeakRSARootCert

The purpose is to ensure that there is no use of a certificate using a weak RSA key

A RSA key certificate with a modulus under 1024 bits is considered unsafe

To solve the matter, the certificate should be removed from the GPO and if needed, certificates depending on it should be reissued.

5 points if present

https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/commercial-national-security-algorithm-suite-factsheet.cfm
https://www.ssi.gouv.fr/guide/cryptographie-les-regles-du-rgs/
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[US]STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).
[FR]ANSSI - Weak or vulnerable certificates (vuln1_certificates_vuln)1

The detail can be found in Certificates

Check for Root Certificates using unsafe hashing algorithm (SHA1)

A-SHA1RootCert

The purpose is to ensure that no Root Certificates use the deprecated SHA-1 hashing algorithm

The SHA1 hashing algorithm is not considered as safe. There are design flaws inherent to the algorithm that allow an attacker to generate a hash collision in less than a brute-force time

To solve the matter, the certificate should be removed from the GPO and if needed, certificates depending on it should be reissued.

Informative rule (0 point)

https://tools.ietf.org/html/rfc6194
[FR]ANSSI - Weak or vulnerable certificates (vuln3_certificates_vuln)3
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[US]STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

The detail can be found in Certificates

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

[FR]ANSSI - Privileged accounts with never-expiring passwords (vuln1_dont_expire_priv)1
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R11 [subsection.2.5]
[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.
[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 Windows 2000 compatibility which allows access to the domain without any account

A-PreWin2000Anonymous

The purpose is to identify domains which allow access without any account because of a Pre-Windows 2000 compatibility

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)
It is possible to verify the results provided by the PingCastle solution by using a Kali distribution. You should run [rpcclient -U " target_ip_address] and press enter at the password prompt to finally type [enumdomusers].

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

5 points if present

https://msdn.microsoft.com/en-us/library/cc223672.aspx
[MITRE]T1110.003 Brute Force: Password Spraying
[US]STIG V-8547 - The Anonymous Logon and Everyone groups must not be members of the Pre-Windows 2000 Compatible Access group.
[FR]ANSSI - The "Pre - Windows 2000 Compatible Access" group includes "Anonymous" (vuln2_compatible_2000_anonymous)2

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://msdn.microsoft.com/en-us/library/cc223672.aspx
[FR]ANSSI - Use of the "Pre-Windows 2000 Compatible Access" group (vuln3_compatible_2000_not_default)3
[MITRE]T1110.003 Brute Force: Password Spraying

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

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

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://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
[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

DC vulnerability (SMB v1)

S-SMB-v1

The purpose is to verify if Domain Controller(s) are vulnerable to the SMB v1 vulnerability

The SMB downgrade attack is used to obtain credentials or executing commands on behalf of a user by using SMB v1 as protocol. Indeed, because SMB v1 supports old authentication protocol, the integrity can be bypassed

It is highly recommended by Microsoft to disable SMB v1 whenever it is possible on both client and server-side. Do note that if you are still not following best practices regarding the usage of deprecated OS (Windows 2000, 2003, XP, CE), regarding Network printer using SMBv1 scan2shares functionalities, or regarding software accessing Windows share with a custom implementation relying on SMB v1, you should consider fixing these issues before disabling SMB v1, as it will generate additional errors.

10 points if present

https://github.com/lgandx/Responder-Windows
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://docs.microsoft.com/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3
[FR]ANSSI CERTFR-2017-ACT-019
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay
[FR]ANSSI CERTFR-2016-ACT-039

The detail can be found in Domain controllers

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.f-secure.com/archive/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

Mitigate golden ticket attack via a regular change of the krbtgt password

A-Krbtgt

The purpose is to alert when the password for the krbtgt account can be used to compromise the whole domain. This password can be used to sign every Kerberos ticket. Monitoring it closely often mitigates the risk of golden ticket attacks greatly.

Kerberos is an authentication protocol. It is using a secret, stored as the password of the krbtgt account, to sign its tickets. If the hash of the password of the krbtgt account is retrieved, it can be used to generate authentication tickets at will.
To mitigate this attack, it is recommended to change the krbtgt password between 40 days and 6 months. If this is not the case, every backup done until the last password change of the krbtgt account can be used to emit Golden tickets, compromising the entire domain.
Retrieval of this secret is one of the highest priority in an attack, as this password is rarely changed and offer a long term backdoor.
Also this attack can be performed using the former password of the krbtgt account. That's why the krbtgt password should be changed twice to invalidate its leak.

The password of the krbtgt account should be changed twice to invalidate the golden ticket attack.
Beware: two changes of the krbtgt password not replicated to domain controllers can break these domain controllers You should wait at least 10 hours between each krbtgt password change (this is the duration of a ticket life).

There are several possibilities to change the krbtgt password.
First, a Microsoft script can be run in order to guarantee the correct replication of these secrets.
Second, a more manual way is to essentially reset the password manually once, then to wait 3 days (this is a replication safety delay), then to reset it again. This is the safest way as it ensures the password is no longer usable by the Golden ticket attack.

50 points if the occurence is greater than or equals than 1464
then 40 points if the occurence is greater than or equals than 1098
then 30 points if the occurence is greater than or equals than 732
then 20 points if the occurence is greater than or equals than 366

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/faqs-from-the-field-on-krbtgt-reset/ba-p/2367838
https://github.com/microsoft/New-KrbtgtKeys.ps1
https://github.com/PSSecTools/Krbtgt
[FR]ANSSI CERTFR-2014-ACT-032
[FR]ANSSI - Krbtgt account password unchanged for more than a year (vuln2_krbtgt)2
[MITRE]T1558.001 Steal or Forge Kerberos Tickets: Golden Ticket

The detail can be found in Krbtgt

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 with weak encryption (DES algorithm)

S-DesEnabled

The purpose is to verify that no weak encryption algorithm such as DES is used for accounts.

DES is a very weak algorithm and once assigned to an account, it can be used in Kerberos ticket requests, even though it is easily cracked. If the attacker cracks the Kerberos ticket, they can steal the token and compromise the user account.

It is recommended to disable DES as an encryption algorithm in the user configuration dialog or in the "msDSSupportedEncryptionTypes" attribute at LDAP level. It has to be disabled in the property of an account by unchecking the box "Use Kerberos DES encryption for this account". You can also detect which accounts support Kerberos DES encryption by running: Get-ADObject -Filter {UserAccountControl -band 0x200000 -or msDs-supportedEncryptionTypes -band 3}.

15 points if present

https://docs.microsoft.com/en-us/archive/blogs/openspecification/msds-supportedencryptiontypes-episode-1-computer-accounts
https://docs.microsoft.com/en-us/services-hub/health/remediation-steps-ad/remove-the-highly-insecure-des-encryption-from-user-accounts
[FR]ANSSI - Use of Kerberos with weak encryption (vuln2_kerberos_properties_deskey)2
[MITRE]T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting

The detail can be found in User information and Computer information

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 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 that the "Pre-Windows 2000 Compatible Access" group does not contain "Authenticated Users"

A-PreWin2000AuthenticatedUsers

The purpose is checking if the "Pre-Windows 2000 Compatible Access" group contains "Authenticated Users"

The pre-Windows 2000 compatible access group grants access to some RPC calls.
Its default and secure value is the "Authenticated Users" group which allows users to perform group look-up using legacy protocols.

If this group contains "Authenticated Users", it increases the impact of the exploitation of vulnerabilities in legacy protocols such as the Print Spooler service.
Indeed, in the #PrintNightmare attack, it enables a patch bypass on domain controllers because the property Elevated Token is on when establishing a session to the DC.
Removing the group can have side impacts and as a consequence, this is reported here as a special hardening measure.

Remove "Authenticated Users" from the PreWin2000 group.

Informative rule (0 point)

https://msdn.microsoft.com/en-us/library/cc223672.aspx
https://www.gradenegger.eu/?p=1132
[MITRE]T1210 Exploitation of Remote Services

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

Duplicate account check

S-Duplicate

The purpose is to check if there are duplicate accounts within the domain. A duplicate account is essentially a duplicate of two objects having the same attributes.

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. To identify all duplicate accounts, you can use the following PowerShell commands: get-adobject -ldapfilter "(cn=*cnf:*)" ; get-adobject -ldapfilter "(sAMAccountName=$duplicate)"

5 points if present

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

The detail can be found in User information and Computer information

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 services accounts, Windows provide the "managed service accounts" and "group managed service accounts" features to facilite 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
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Accounts with never-expiring passwords (vuln2_dont_expire)2

The detail can be found in User information

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://technet.microsoft.com/en-us/library/jj130668(v=ws.10).aspx
[MITRE]Mitre Att&ck - Mitigation - Data Backup
[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.

The detail can be found in Backup

Check for inactive administrator accounts

P-Inactive

The purpose is to ensure that all Administrator Accounts in the AD are necessary and used

Accounts within the AD have attributes indicating the creation date of the account and the last login of this account. Accounts which haven't have a login since 6 months or created more than 6 months ago without any login are considered inactive. If an Administrator Account is set as inactive, the reason for having Administrator rights should be strongly justified.

To correct the situation, you should make sure that all your Administrator Account(s) are "Active", meaning that you should remove Administrator rights if an account is set as not "Active"

30 points if the occurence is greater than or equals than 30
then 20 points if the occurence is greater than or equals than 15

[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R36 [subsection.3.6]

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

[FR]ANSSI - Privileged accounts with never-expiring passwords (vuln1_dont_expire_priv)1
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R11 [subsection.2.5]
[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.
[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 suspicious account(s) used in administrator activities

A-AdminSDHolder

The purpose is to ensure that there are no rogue admin accounts in the Active Directory

A check is performed on non-admin accounts in order to identify if they have an attribute admincount set. If they have this attribute, it means that this account, which is not supposed to be admin, has been granted administrator rights in the past. This typically happens when an administrator gives temporary rights to a normal account, off process.

These accounts should be reviewed, especially in regards with their past activities and have the admincount attribute removed. In order to identify which accounts are detected by this rule, we advise to run a PowerShell command that will show you all users having this flag set: get-adobject -ldapfilter "(admincount=1)"
Do not forget to look at the section AdminSDHolder below.

50 points if the occurence is greater than or equals than 50
then 45 points if the occurence is greater than or equals than 45
then 40 points if the occurence is greater than or equals than 40
then 35 points if the occurence is greater than or equals than 35
then 30 points if the occurence is greater than or equals than 30
then 25 points if the occurence is greater than or equals than 25
then 20 points if the occurence is greater than or equals than 20
then 15 points if present

https://msdn.microsoft.com/en-us/library/ms675212(v=vs.85).aspx
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R40 [paragraph.3.6.3.1]

The detail can be found in the AdminSDHolder User List

Check if the LAPS tool to handle the native local administrator passwords is installed

A-LAPS-Not-Installed

The purpose is to make sure that there is a proper password policy in place for the native local administrator account.

LAPS (Local Administrator Password Solution) is the advised solution to handle passwords for the native local administrator account on all workstations, as it is a simple way to handle most of the subject.

If you don't have any provisioning process or password solution to manage local administrators, you should install the LAPS solution. If you mitigate the risk differently, you should add this rule as an exception, as the risk is covered.

15 points if present

https://www.microsoft.com/en-us/download/details.aspx?id=46899
[US]STIG V-36438 - Local administrator accounts on domain systems must not share the same password.
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[FR]ANSSI CERTFR-2015-ACT-046
[MITRE]T1078.003 Valid Accounts: Local Accounts

The detail can be found in LAPS

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

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

The detail can be found in Admin Groups

Check if all admin passwords are changed on the field.

P-AdminPwdTooOld

The purpose is to ensure that all admins are changing their passwords at least every 3 years

This rule ensure that passwords of administrator are well managed.

We advised to read the ANSSI guidelines about this, which is quoted in the documentation section below.

10 points if present

[FR]ANSSI - Privileged account passwords age too old (vuln1_password_change_priv)1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

The detail can be found in Admin Groups

Check that the operator groups are empty

P-OperatorsEmpty

The purpose is to ensure that the operator groups, which can have indirect control to the domain, are empty

Operator groups (Account Operators, Server Operators, ...) can take indirect control of the domain. Indeed, these groups have write access to critical resources of the domain.

It is recommended to have these groups empty. Assign administrators into administrators group. Other accounts should have proper delegation rights in an OU or in the scope they are managing.

Informative rule (0 point)

[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R27 [subsection.3.5]

The detail can be found in Admin Groups

Check if the Dns Admins group is not empty

P-DNSAdmin

The purpose is to ensure that the Dns Admins group is not used

Administrators of the DNS Service have the possibility to inject a DLL in this service.
However this service is hosted most of the time in the domain controller and is running as SYSTEM.
That means that DNS admins are potentially domain admins.

The security descriptor used to grant admin rights is located on the nTSecurityDescriptor attribute of the object CN=MicrosoftDNS,CN=System.
The "Write All Prop" access right induces the vulnerability.

In this case, the DnsAdmins group is not empty and grant to its user the possibility to interact with the DNS Service.

Rule update:
The Patch Tuesday of October 2021 fixed this vulnerability and assigned it the identifier CVE-2021-40469.
If the patch has been applied, there is no additional mitigation to perform.

This rule is transformed into an informative rule in PingCastle 2.10.1 and will be removed in future versions of PingCastle.

You should remove the members of the Dns Admins group and do a proper delegation to the specific DNS Zones.

First, grant only "Read Property", "List", "List object" and "Read permssions" to CN=MicrosoftDNS,CN=System to enable access to the RPC service.

Then on each zone (the object in the tree below with the class dnsZone), grant "Read Property", "List", "List object", "Read permissions", "Create Child", "Delete Child", "Delete", "Delete Tree".

Informative rule (0 point)

https://medium.com/@esnesenon/feature-not-bug-dnsadmin-to-dc-compromise-in-one-line-a0f779b8dc83
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/007efcd2-2955-46dd-a59e-f83ae88f4678
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[FR]ANSSI - DnsAdmins group members (vuln4_dnsadmins)4

The detail can be found in Admin Groups

Check if administrator accounts are email enabled.

P-AdminEmailOn

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

The recommended approach for secure administration is to 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.

Ensure that administrators do not use the privileged account for browsing the internet or receiving emails.
We highly recommend that you implement this practice to lower the risk of an admin compromise.

To remove this alert, you have to edit the properties of the user account and clear the email attribute.
Keep in mind that this action will silence the alert, but the risk may still be present.

Informative rule (0 point)

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/securing-privileged-access-for-the-ad-admin-part-1/ba-p/259166
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

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://docs.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/
[FR]ANSSI - Privileged accounts outside of the Protected Users group (vuln3_protected_users)3
[MITRE]Mitre Att&ck - Mitigation - Privileged Process Integrity
[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

The detail can be found in Admin Groups

Obsolete OS (Windows 10 or Windows 11)

S-OS-W10

The purpose is to ensure that there is no use of non-supported version of Windows 10 or Windows 11 within the domain

Some versions of Windows 10 and Windows 11 OS are no longer supported, and may be vulnerable to exploits that are not patched anymore.

In order to solve this security issue, you should upgrade all the Windows 10 or Windows 11 to a more recent version.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto | where {$_.enabled -eq $true}
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows 1*"}

15 points if the occurence is greater than or equals than 15
then 10 points if the occurence is greater than or equals than 6
then 5 points if present

https://docs.microsoft.com/en-us/windows/release-health/release-information
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI CERTFR-2005-INF-003

The detail can be found in Operating Systems

Obsolete OS (Windows Server 2008)

S-OS-2008

The purpose is to ensure that there is no use of the obsolete and vulnerable OS Windows Server 2008 for the workstations within the domain

The Windows Server 2008 OS is no longer supported, as it is vulnerable to many publicly known exploits: Administrator's credentials can be captured, security protocols are weak, etc.

In order to solve this security issue, you should upgrade all the servers to a more recent version of Windows, starting from Windows Server 2012.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto | where {$_.enabled -eq $true}
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows Server*"}

15 points if the occurence is greater than or equals than 15
then 10 points if the occurence is greater than or equals than 6
then 5 points if present

https://support.microsoft.com/en-us/help/4456235/end-of-support-for-windows-server-2008-and-windows-server-2008-r2
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI CERTFR-2005-INF-003

The detail can be found in Operating Systems

Obsolete Domain Controller (Windows Server 2008)

S-DC-2008

The purpose is to ensure that there is no use of the obsolete and vulnerable OS Windows Server 2008 as Domain Controller within the domain

The OS Windows Server 2008 is not supported anymore by Microsoft (except when migrated to Azure, until January 9, 2024) and any vulnerability found will not be patched.

To resolve this security risk, the only way is to decommission DCs running Windows Server 2008 OS, in order to use new versions that are more secure and that are still being patched regarding new security threats

5 points if present

https://support.microsoft.com/en-us/help/4456235/end-of-support-for-windows-server-2008-and-windows-server-2008-r2
[MITRE]Mitre Att&ck - Mitigation - Update Software
[US]STIG V-8551 - The domain functional level must be at a Windows Server version still supported by Microsoft.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R12 [subsection.3.1]

The operating system of domain controllers can be found in Domain controllers

Obsolete OS (Windows Server 2012)

S-OS-2012

The purpose is to ensure that there is no use of the obsolete and vulnerable OS Windows Server 2012 for the workstations within the domain

The Windows Server 2012 OS is no longer supported, as it is vulnerable to many publicly known exploits: Administrator's credentials can be captured, security protocols are weak, etc.

In order to solve this security issue, you should upgrade all the servers to a more recent version of Windows, starting from Windows Server 2012.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto | where {$_.enabled -eq $true}
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows Server*"}

10 points if the occurence is greater than or equals than 15
then 5 points if the occurence is greater than or equals than 6
then 2 points if present

https://learn.microsoft.com/fr-fr/lifecycle/products/windows-server-2012-r2
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI CERTFR-2005-INF-003

The detail can be found in Operating Systems

Obsolete OS (Windows 7)

S-OS-Win7

The purpose is to ensure that there is no use of the obsolete and vulnerable OS Windows 7 for the workstations within the domain

The Windows 7 OS is no longer supported, as it is vulnerable to many publicly known exploits: Administrator's credentials can be captured, security protocols are weak, etc.
PingCastle is trying to guess if Extended Security Support (ESU) has been purchased from Microsoft. Based on the documentation referenced below, the program checks if the script Activate-ProductOnline.ps1 is present.
If the script is detected, Windows 7 is considered as supported and this rule is not triggered.

In order to solve this security issue, you should upgrade all the workstations to a more recent version of Windows, starting from Windows 10.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto | where {$_.enabled -eq $true}
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows Server*"}

5 points if the occurence is greater than or equals than 15
then 2 points if the occurence is greater than or equals than 6
then 1 points if present

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/activate-windows-7-esus-on-multiple-devices-with-a-mak/ba-p/1167196
[FR]ANSSI CERTFR-2005-INF-003
[MITRE]Mitre Att&ck - Mitigation - Update Software

The detail can be found in Operating Systems

Ensure that the functional level of the domain and the forest are up to date to use the latest security features

S-FunctionalLevel3

The purpose is checking the functional level of the domain and the forest, and ensure it is set to the latest secure version

Each functional level brings new security features:
* functional level Windows Server 2003: brings forest trusts and read-only domain controller (RODC) support;
* functional level Windows Server 2008: brings support for modern cryptographic algorithms such as AES and DFS for SYSVOL share replication;
* functional level Windows Server 2008R2: brings support for Active Directory Recycle Bin (protects objects against accidental deletion);
* functional level Windows Server 2012: brings advanced Kerberos features, such as compound authentication and claims support;
* functional level Windows Server 2012R2: brings numerous new security features such as authentication policies, authentication policy silos and the Protected users group;
* functional level Windows Server 2016 / 2019 / 2022: brings an upgraded smart card logon security and Privileged Identity Management (PIM) trust relationships between forests.

You have to raise the functional level of the domain or the forest (see the details to know if the domain and/or forest is concerned).
The recommended level is the functional level 7 (Windows Server 2016 / 2019 / 2022)

To upgrade the functional level, a requirement is that all domain controllers are running the right version.
Also, functional level needs to be upgraded level by level.

Informative rule (0 point)

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/identifying-your-functional-level-upgrade
https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/raise-active-directory-domain-forest-functional-levels
[FR]ANSSI - Insufficient forest and domains functional levels (vuln3_vuln_functional_level)3
[MITRE]Mitre Att&ck - Mitigation - Update Software

The functional levels are indicated in Domain Information

Inactive computer check

S-C-Inactive

The purpose is to ensure that there are as few inactive computers as possible within the domain.

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.

To mitigate the risk, you should monitor the number of inactive accounts and reduce it as much as possible. A list of all inactive accounts is obtainable through the command: Search-ADAccount –AccountInActive –ComputersOnly –TimeSpan 180:00:00:00 –ResultPageSize 2000 –ResultSetSize $null | ?{$_.Enabled –eq $True} | Select-Object Name, SamAccountName, DistinguishedName.

30 points if the occurence is greater than or equals than 30
then 10 points if the occurence is greater than or equals than 20
then 5 points if the occurence is greater than or equals than 15

[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]
[MITRE]Mitre Att&ck - Mitigation - User Account Management
[FR]ANSSI - Inactive servers (vuln3_password_change_inactive_servers)3

Vulnerable Schema Class check

S-ADRegistrationSchema

The purpose is to ensure that no schema class can be used to create arbitrary objects

The classes added to the schema provide additional object types. If misconfigured, a class can be used to bypass a security restriction.
For the vulnerability PossSuperiorComputer:
A class has the attribute possSuperiors containing the class "computer" and this class inherits from "container".
That means that every computer can request this class to be added.
Once this class has been added, it can be used as a container to create additional users or computers without restrictions.

For the vulnerability PossSuperiorUser:
It is the same vulnerability as PossSuperiorComputer but with the "user" class instead of the "computer" class.

For PossSuperiorComputer:
You have to edit the schema to change the value of the attribute possSuperior and remove the "computer" value.
A PowerShell script in the documentation provides a fix.

For PossSuperiorUser:
You have to edit the schema to change the value of the attribute possSuperior and remove the "user" value.
A PowerShell script in the documentation provides a fix.

Also the class msExchStorageGroup is known to have this vulnerability via the CVE-2021-34470.
In this case, the vulnerability is exploitable even if Exchange has been uninstalled.

10 points if present

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
[MITRE]Mitre Att&ck - Mitigation - User Account Management
[FR]ANSSI - Schema class allowing dangerous object creation (vuln2_warning_schema_posssuperiors)2

Inactive account check

S-Inactive

The purpose is to ensure that there are as few inactive accounts as possible within the domain. Stale user accounts are a significant security issue, as former employees and external attackers could use those accounts to attack the organization.

Inactive accounts 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.

To mitigate the risk, you should monitor the number of inactive accounts and reduce it as much as possible. A list of all inactive accounts is obtainable through the command: Search-ADAccount –AccountInActive –UsersOnly –TimeSpan 180:00:00:00 –ResultPageSize 2000 –ResultSetSize $null | ?{$_.Enabled –eq $True} | Select-Object Name, SamAccountName, DistinguishedName.

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

[MITRE]Mitre Att&ck - Mitigation - User Account Management
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]
[FR]ANSSI - Dormant accounts (vuln1_user_accounts_dormant)1

The detail can be found in User information and Computer information

Check if default OU location has been changed within the domain.

S-DefaultOUChanged

The purpose is to ensure that the default location of computers and user OU has not been changed.

Default OU such as CN=Computers or CN=Users are stored within the wellKnownObjects attribute of the Domain object.
There are 12 default locations officialy defined.
They can be changed using the program redircmp.
Changing these default can alter the behavior of programs (such as security audit programs) as they may not check the modified objects.

You have to use redircmp to set the value back to normal. See documentation for more details

Informative rule (0 point)

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/
[MITRE]Mitre Att&ck - Mitigation - User Account Management