test.mysmartlogon.com - Healthcheck analysis

Ensure that custom Display Specifiers are stored in SYSVOL

P-DisplaySpecifier

The purpose is to ensure that scripts used for the customization of admin UI are stored safely

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

The scripts identified by this rule should be moved to the SYSVOL and properly secured.

10 points if present

https://www.semperis.com/blog/active-directory-security-abusing-display-specifiers/
https://learn.microsoft.com/en-us/windows/win32/ad/display-specifiers
[FR]ANSSI - Dangerous Display Specifiers (vuln1_vuln_display_specifier)1
[MITRE]T1569 System Services

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

[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[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

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

Check for Trusts whose security is not maximum

T-SIDFiltering

The purpose is to check if all trusts are protected using the functionality named SID Filtering

SID Filtering is a mechanism used to block account presenting a SID History property. SID History is used to link an existing account to another account and can be used to propagate a compromise through trusts. SID Filtering for domain-to-domain trust is called a quarantine and is disabled by default. SID Filtering to a forest is enabled by default and disabling it is called "enabling SID History".

The algorithm to compute the SID Filtering is:
get the attribute trustDirection and TrustAttributes of the trust object.
if the direction is 0 or 1 or if the trust is intra forest (trustattributes & 32 != 0) then SID Filtering is not applicable.
Then, if the trust is a forest trust (trusattributes & 8 != 0) then
check if /enablesidhistory has been enabled - trustattributes & 64 != 0.
If enabled: SID Filtering is deactivated.
Else if not a forest trust (trustattributes & 8 == 0) then check for the quarantined attribute (trustattributes & 4 != 0).
If the quarantine flag is set, SID Filtering is enabled.

You can use the PowerShell command to get its status:
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().GetSidFilteringStatus('my.domain.to.test.local')

A trust without SID Filtering means either that a migration is in progress or that the domain can be compromised instantly via the trust.
The solution is to complete existing migration ASAP and enable the SID Filtering feature.

If the trust is a domain trust, you should use netdom /quarantine and set it to yes.
If the trust is a forest trust, you should use netdom /enablesidhistory and set it to no.
Do not apply /quarantine on a forest trust: you will break the transitivity of the trust.

100 points if the occurence is greater than or equals than 4
then 80 points if the occurence is greater than or equals than 2
then 50 points if present

https://msdn.microsoft.com/en-us/library/cc237940.aspx
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R16 [paragraph.3.3.1.6]
[FR]ANSSI - Outbound forest trust relationships with sID History enabled (vuln1_trusts_forest_sidhistory)1
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[US]STIG V-8538 - Security identifiers (SIDs) must be configured to use only authentication data of directly trusted external or forest trust.
[FR]ANSSI - Unfiltered outbound domain trust relationship (vuln1_trusts_domain_notfiltered)1

The detail can be found in Trusts section

SIDHistory check

S-SIDHistory

The purpose is to ensure that a migration has been completed correctly and that the SIDHistory attribute has been cleared out from user and computer accounts. This attribute is indeed set when migrating a user or a computer from one domain to another

The SIDHistory attribute is useful when doing a migration because it allows to keep the reference to the former account. On the other hand, once the migration is over, it is mandatory that this attribute is removed to evaluate the permissions in regards with the new account and not the former one.

To solve the security issue, you should remove all the SIDHistory attributes. To do so, you can list the objects having a SIDHistory attribute using the command: get-ADObject -ldapfilter "(sidhistory=*)" -properties sidhistory.
Each security descriptor of the domain, including file shares for example, should be reviewed to be rewritten with the new SID of the account. Then, the attribute can be removed of these accounts using the migration tool or a PowerShell snippet Remove-SIDHistory once the migration is completed.

Please note that once the SID History has been removed, it cannot be added back again without doing a real migration. Possibly hacking tools such as mimikatz could be used to undo a deletion with for example the lsadump::dcshadow attack.

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

5 points per discovery with a minimal of 15 points

[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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://support.microsoft.com/en-us/help/243330/well-known-security-identifiers-in-windows-operating-systems
[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
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]

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

Check if all DC are well registered.

S-DCRegistration

The purpose is to ensure that DC are well registered.

To be registered as a domain controller, a computer must be a member of the domain controller group, but also has some specific settings.
The settings are a change of the userAccountControl attribute and a couple of objects in the configuration partition.
This rule is triggered when an inconsistency has been detected between the expected values and the real values.

The user account control value for Read/Write DC is:
SERVER_TRUST_ACCOUNT (0x00002000) | TRUSTED_FOR_DELEGATION (0x00080000) = 0x00082000
The user account control value for Read Only DC is:
PARTIAL_SECRETS_ACCOUNT (0x04000000) | TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION (0x01000000) | WORKSTATION_TRUST_ACCOUNT (0x00001000) = 0x05001000

This rule result is either the result of a manual or software based misconfiguration. It can also be the sign of a compromise.
Depending on the anonamly reported, you have to perform the following actions:
- for InvalidUserAccount:
you have to check that the userAccountControl attribute of the AD object is either 0x00082000 for RW DC or 0x05001000 for RODC
- for NoConfiguration:
the DC registration in the Configuration partition is mising. The DC should not be active and need to be demoted.
- for NoNTDS:
the NTDS part of the DC Configuration is missing. Most probably the replication is not working. The DC should be demoted.

10 points if present

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/9164e4e8-f892-4ca2-8067-059f6f9387a4
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8ebf2419-1169-4413-88e2-12a5ad499cf5
[FR]ANSSI - Domain controllers in inconsistent state (vuln1_dc_inconsistent_uac)1
[MITRE]T1207 Rogue Domain Controller

The detail can be found in Domain controllers

Check for the ROCA vulnerability in certificates

A-CertROCA

The purpose is to ensure that there is no private key that can be recovered from a certificate

"ROCA" is an acronym for "Return of Coppersmith's attack" which enables an attacker to retrieve the private key from a public key.
It is due by a library named RSALib, provided by Infineon Technologies which is incorporated into many smart cards, Trusted Platform Module (TPM), and Hardware Security Modules (HSM) implementations, including YubiKey 4 tokens and used to generate public RSA keys.
This library was generating data in a limited number space, which decreased the number of values that an attacker has to guess.

If the certificates listed below are still valid, you have to revoke and re-issue them. If other certificates depend on them, they should be revoked and replaced too.
If the certificates have been expired, they should be removed.

15 points if present

https://crocs.fi.muni.cz/public/papers/rsa_ccs17
https://github.com/crocs-muni/roca
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190026
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170012
https://keychest.net/roca
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[FR]ANSSI - Weak or vulnerable certificates (vuln1_certificates_vuln)1

The detail can be found in Certificates

Check if LDAPS is used with weak SSL protocol.

A-DCLdapsProtocol

The purpose is to ensure that all DC don't use weak SSL protocols when acting as server.

SSL version 2 and SSL version 3 are considered broken and it is strongly advised to disable them.
The SSL protocols in Windows is provided by the SChannel component.
The SChannel component needs to be tuned in order to not propose these weak 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 -ssl2
openssl-unsafe s_client -connect dc.domain.local:636 -ssl3

Apply Windows updates and registry tweaks described in the documentation section to disable the weak SSL protocols.

10 points if present

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

The detail can be found in Domain controllers

Check for Certificates using a relatively weak signing algorithm (RSA between 1024 bits and 2048 or expires after 2030)

A-WeakRSARootCert2

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

A RSA key certificate with a modulus under 1024 bits is considered as not safe. This is checked by the rule A-WeakRSARootCert.
This rule checks for certificates having a key under 2048 bits which is considered as having a lower level of security and under 3072 bits for certificates valid after 2030.

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

Please note that this rule is the companion of the rule A-WeakRSARootCert which checks for unsecured certificates (key lower than 1024 bits).

1 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 (vuln3_certificates_vuln)3

The detail can be found in Certificates

Check for Intermediate Certificates using unsafe hashing algorithm (SHA1)

A-SHA1IntermediateCert

The purpose is to ensure that there is no use of the deprecated SHA1 hashing algorithm in Intermediate Certificate

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.

1 points if present

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

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
[US]STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[FR]ANSSI - Weak or vulnerable certificates (vuln3_certificates_vuln)3

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

[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[MITRE]T1003.004 OS Credential Dumping: LSA Secrets
[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 - Privileged accounts with never-expiring passwords (vuln1_dont_expire_priv)1
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R11 [subsection.2.5]

The detail can be found in Admin Groups

Check for accounts using smart card with unchanged password for a long time

A-SmartCardRequired

The purpose is to make sure the requirement of Smart Cards doesn't degrade password rotation

Using smart cards to protected sensitive accounts is a good thing. Nevertheless, when the "Smart Card required" flag is set, the password of the account is not changed anymore by default. Internally the hash of this password is used to sign the user's Kerberos tickets, making this account vulnerable to Silver ticket attacks. The rule is triggered 90 days after the last change of the attribute unicodePwd. This value is collected using the replication metadata of the attribute 589914

There are 3 solutions to fix this issue, the most obvious being to change the user password on a regular basis. The fastest way is to check if the domain has the attribute msDS-ExpirePasswordsOnSmartCardOnlyAccounts, which is available for Windows Server 2016 and later versions and handles periodically hash change. Another possibility, instead of changing the password, is to disable the flag "this account requires a smart card" then re-enable it, which will trigger an internal password hash change.

30 points if present

https://blogs.technet.microsoft.com/positivesecurity/2017/05/17/smartcard-and-pass-the-hash/
[MITRE]T1110.002 Brute Force: Password Cracking
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R38 [paragraph.3.6.2.2]
[US]STIG V-72821 - All accounts, privileged and unprivileged, that require smart cards must have the underlying NT hash rotated at least every 60 days.

The detail can be found in Smart Card and Password

Check for GPO which enables reversible passwords

A-ReversiblePwd

The purpose is to verify if a GPO alters the password policy of the domain to enable reversible passwords

The policy "Store passwords using reversible encryption" is enabled. In this case, it means that the password is actually stored in clear text in the supplementalCredential attribute of the account and that it can be retrieved using a DCSync attack.

In order to remove the reversible passwords, we advise to identify the GPO indicated by the program and change the setting "Store passwords using reversible encryption"

10 points if present

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption
[MITRE]T1110.002 Brute Force: Password Cracking
[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3

The detail can be found in Security settings

Check for GPO enabling the unsafe algorithm LM hash

A-LMHashAuthorized

The authentication protocol NTLM v1 can use the LM password hash algorithm which is very weak if enabled by a GPO.

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

A GPO explicitly disabled the default security policy LmCompatibilityLevel or NoLMHash. Using the information provided, identify the setting modified in the GPO and fix it.
All security settings should be modified in the Domain GPO Editor and are located in Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / Security Options
For NoLMHash the setting is located in: Network security: Do not store LAN Manager hash value on next password change
For LmCompatibilityLevel the setting is located in: Network security: LAN Manager authentication level

5 points if present

[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R37 [paragraph.3.6.2.1]
[MITRE]T1110.002 Brute Force: Password Cracking
[US]STIG V-3379 - The system is configured to store the LAN Manager hash of the password in the SAM.

The detail can be found in Security settings

Retrieve data from the domain without any account

A-NullSession

The purpose is to check if access without any account, aka NULL Sessions, is possible within the Active Directory. A NULL Session is a session opened anonymously to access the AD, often used by attackers to perform a recon operation on the AD, to identify weaknesses

Unlike other rules, which check for known cause of anonymous access, this rule tries to enumerate accounts from the domain without any account. The program uses two methods: MS-SAMR with a NULL connection and MS-LSAT, which forces SID resolution with a well known SID.
NULL sessions are deactivated by default since Windows Server 2003 and Windows XP. For compatibility reasons a setting enabling them may be still active years after.
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].

Locate other PingCastle rules such as A-PreWin2000Anonymous or A-DsHeuristicsAnonymous which triggered and apply the solutions. You can use the PingCastle scanner mode to do a manual check and prove the extraction of the data.

10 points if present

https://www.sans.org/reading-room/whitepapers/windows/null-sessions-nt-2000-286
[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 Domain controllers and Null Session

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

Check if all DC have no constrained delegation with protocol transition.

P-DelegationDCt2a4d

The purpose is to ensure that no constrained delegations with protocol transition are applied to DC

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

You should edit the msDS-AllowedToDelegateTo attribute of the accounts listed below to remove the SPN of the domain controllers involved.

25 points per discovery

[MITRE]T1187 Forced Authentication
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Constrained delegation with protocol transition to a domain controller service (vuln1_delegation_t2a4d)1

The detail can be found in Domain controllers

Check delegations for the recipient's existence

P-UnkownDelegation

The purpose is to verify that each delegation is linked to an account which exists

In the case where a delegation has been created, where the account can't be translated to a NT account, it means that the delegation is actually from another domain or that the user has been deleted.

To reduce the risk, the easiest way is essentially to remove the delegation

15 points if present

[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
[MITRE]T1187 Forced Authentication

The detail can be found in Delegations

A Delegation is granted to Everyone

P-DelegationEveryone

The purpose is to verify that there is no delegation granted to "Everyone" or to "Authenticated Users"

To delegate control to a OU, access checks can be modified. In case of a misconfiguration, access can be granted to the group "Everyone" or "Authenticated Users".

Review the delegation to remove this permission and if needed, set a more targeted group as recipient of the delegation.

15 points per discovery

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

The detail can be found in Delegations

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

Ensure that the WebClient client cannot be abused to force a DC connection to a HTTP server

A-DC-WebClient

The purpose is to ensure that DC cannot connect with normal command line to a HTTP server

By default, Windows computers supports only UNC paths (aka \\server\path).
The WebDAV protocol, implemented with HTTP, enables files on webserver to be managed as on a classic file share.
The role of the WebClient service is to provide as a native API call a service to manage files located on a WebDAV server (HTTP URLs).
If the WebClient service is active, command line tools and services can access files on a webserver without any specifc action.

When forced authentication attacks are being used (Print Spooler, PetitPotam, ...) and if this service is in use, the DC can connect to webservers.
An attacker can abuse this service to bypass classic detection rules but this does not represent a vulnerability in itself.

It is not expected that Domain Controllers access WebDAV services but please note that some backup software is known to use cloud connection and thus, requires it.
This is why this rule is classify as informative.

Also please note that WebClient can be remotely started using a 'Search Connector' file. See the details in the link below.

If the WebClient service is in official use (typically from backup applications), disable the service.

Informative rule (0 point)

https://gist.github.com/gladiatx0r/1ffe59031d42c08603a3bde0ff678feb#rpc-to-rce-steps
[MITRE]T1187 Forced Authentication

The detail can be found in Domain controllers

Check if attributes unixUserPassword and userPassword are set

A-UnixPwd

The purpose is to check if password information may be stored in AD attributes

To perform Single Sign On (SSO) systems need to share secrets with Active Directory.
This is not the case for all systems such as Unix and Mainframe and designers have found a workaround by storing this secret into a user account attribute.
However not all systems did implement a proper and cryptographically safe protocol and they are checking the password submitted in their system with an AD attribute.
At that time, it was not known that these attributes can be queried by everyone and as consequence, they did not enforce a robust protection.
Looking at the attribute unixUserPassword, the password can be retrieved either in clear text (encoded as ASCII) or with a weak algorithm such as ROT 13.

In addition to that, the way to change a password in LDAP system is to modify the value of the special attribute userPassword.
This attribute is not supposed to be visible. However Active Directory is using another attribute named unicodePwd (unless the heuristic fUserPwdSupport is set).
That means that the attribute userPassword is not special anymore and that a change of its value is displayed in clear text, considered as a normal attribute.
A misconfigured application can change the user password using this old mechanism, and as a consequence, set the user password in clear text.

The attributes unixUserPassword and userPassword from the mentioned user accounts should be cleared, unless the remote system is known to have a strong cryptographic protocol.

Informative rule (0 point)

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/f3adda9f-89e1-4340-a3f2-1f0a6249f1f8
https://www.blackhillsinfosec.com/domain-goodness-learned-love-ad-explorer/
[MITRE]T1552 Unsecured Credentials
[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3

The detail can be found in Unix Passwords

Find Password GPO

A-PwdGPO

The purpose is to alert when a password is present in a GPO. If a password is in a GPO, the password should be considered compromised and reset.

PingCastle attempts to identify passwords stored in GPOs. If PingCastle was able to retrieve a password, attackers can also obtain it and so the account should be considered compromised. Note that Microsoft published the AES key used to encrypt passwords in GPOs, which is why even an encrypted password is insecure.

To solve this issue, you should manually change the password to a new one. If this password is shared on many systems, each system should have a different password. If the GPO was used to define the native local administrator account, it is recommended to install a password solution manager such as LAPS.

20 points per discovery

https://msdn.microsoft.com/en-us/library/cc422924.aspx
[MITRE]T1552.006 Unsecured Credentials: Group Policy Preferences
[FR]ANSSI CERTFR-2015-ACT-046

The detail can be found in the Obfuscated Passwords

Check if LAPS passwords can be retrieved from computers that have been added manually by users.

A-LAPS-Joined-Computers

The purpose of this rule is to ensure that there is no LAPS permission problems with computers that have been added manually to the domain by a user

By default, every domain user can add up to 10 computers to the domain (see the rule S-ADRegistration for more information).
When a computer is added to the domain, the owner of the computer object is the user who joined the computer.
To trace this insertion, a special attribute mS-DS-CreatorSID is added, whose value is the SID of its creator.
When LAPS is installed, the local admin account has its password stored in a special attribute named, by default, ms-mcs-AdmPwd. Its access is retricted.
Because the user who created it is the owner of the underlying object, it can retrieve the LAPS attribute and get the local admin password.

In addition to check if the owner of the computer object is the user which added it, this program checks also if this user have an explicit permission on this object to write the owner, write the security descriptor, or "all extended rights".
Indeed, the right "all extended rights" allows to read the LAPS password and write access to these attributes can cancel the security hardening of changing the owner.

Review the security of the computer objects listed in the LAPS section below to change their ownership (you can give it to the domain admins group).
Check if the creator has also write permissions to change the owner or the security descriptor and if he has the right "all extended rights" on this object.
If it is the case, remove the permissions granted to this user.

5 points if present

https://azurecloudai.blog/2019/10/01/laps-security-concern-computers-joiners-are-able-to-see-laps-password/
https://www.securityinsider-wavestone.com/2020/01/taking-over-windows-workstations-pxe-laps.html
[MITRE]T1555.005 Credentials from Password Stores: Password Managers

The detail can be found in LAPS

Check for inactive trusts

T-Inactive

The purpose is to verify that every trust has a remote domain which is active.

When a trust is active, it is using a shared secret to communicate to a domain. This secret is hold in a special account whose name is the remote domain name. This password is changed every month and as consequence the whenChanged attribute of this account is changed. When there is no modification of the whenChanged attribute, it can be guessed that the secret has not been changed and that there was either a problem with the remote domain or that the remote domain does not exist anymore.

Check for network connectivity issues from the remote domain or if the remote domain still exists. If it doesn't exist anymore, the trust should be removed. Otherwise, the secret used by the trust can be used to issue fake Kerberos tickets and be used as a backdoor.

20 points if present

https://msdn.microsoft.com/fr-fr/library/ms680921(v=vs.85).aspx
[MITRE]T1557 Man-in-the-Middle
[FR]ANSSI - Trust account passwords unchanged for more than a year (vuln2_trusts_accounts)2

The detail can be found in Trusts section

Check if DNS Zones are configured with insecure update.

A-DnsZoneUpdate1

The purpose is to ensure that the DNS Zones are configured to accept only secure update.

When the insecure update mechanism is enabled, an attacker can update a DNS record anonymously.
He can then use this feature to add new entries or perform a man in the middle attack to capture credentials.

Please note that the rule A-DnsZoneUpdate1 is the companion of A-DnsZoneUpdate2 and it is used to report anomalies related to the local domain zone or the main _msdcs zone. A-DnsZoneUpdate2 reports all the other zones.

You have to enable secure updates.
Identify the faulty zone in the details below.
Go to the DNS console and select a zone in the "Forward Lookup Zones".
Right click on it and switch to the "General" tab.
Then change Dynamic updates from "Nonsecure and secure" to "Secure only".
You can also run: dnscmd servername /Config zone /AllowUpdate 2

15 points if present

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

Ensure LDAP signing requirements is not set to None

A-LDAPSigningDisabled

The purpose is to check that the integrity of the network protocol LDAP as not been endangered by explicitly disabling LDAP signing.

The LDAP signature feature enables the integrity of the network communication between the computer and the domain controller.
Hackers aim at intercepting the communication at the network layer and modify the network dialog to grant themselves admin privileges.
The goal of this feature is to defeat these attacks.
Unfortunately, not all devices support LDAP signature. That's why the best practice is to Require Signature if possible or to, at least, try to negotiate it.
In this case, the LDAP signature feature is configured to None (no negotiation), which can enable hackers to perform their attacks.

Locate the GPO specified in Details and change the setting in "Network security: LDAP client signing requirements".
Disable this setting, or set it to "Negotiate signing" or "Require Signature".
The setting is located in :
Computer configuration -> Policies -> Windows Settings ->Security Settings -> Local Policies -> Security Options.
As an alternative, the file GptTmpl.inf can be manually edited.

5 points if present

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements
[MITRE]T1557 Man-in-the-Middle

The detail can be found in Security settings

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.

As an alternative, the well known script Get-NtlmV1LogonEvents.ps1 can be used to search for NTLMv1 logon events.

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
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay
[FR]ANSSI CERTFR-2017-ACT-019
[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
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay
[US]STIG V-63577 - Hardened UNC Paths must be defined to require mutual authentication and integrity for at least the \\*\SYSVOL and \\*\NETLOGON shares.

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

Check if certificate templates can be edited by everyone.

A-CertTempAnyone

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

A certificate template is an object whose definition serves as a base to issue certificates.
If a user has the right to edit it, it can manually change obscure attributes such as msPKI-Certificate-Name-Flag.
Doing so will enable him to provide the subject of the certificate and thus having a certificate on behalf other users such as admins.
It can be used to impersonate them and take control of the domain.

Note: the program regards the group "Domain Computers" like "Everyone" if ms-DS-MachineAccountQuota is non zero.

Review the security permissions of this certificate template and remove the write access to everyone-like groups such as Domain Users, Domain Computers, Everyone, Authenticated Users, ...

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/
[MITRE]T1558 Steal or Forge Kerberos Tickets
[FR]ANSSI - Dangerous enrollment permission on authentication certificate templates (vuln1_vuln_adcs_template_auth_enroll_with_name)1

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_vuln_adcs_template_auth_enroll_with_name)1
[MITRE]T1558 Steal or Forge Kerberos Tickets

The detail can be found in Certificate Templates

Check the purpose provided by certificate templates

A-CertTempAnyPurpose

The purpose of this rule is to ensure that there is no certificate template with any purpose that can be requested by everyone

A certificate should define restrictions of its use. It is done via extensions known as EKU (extended key usage).
Without a proper purpose or with the global purpose "Any Purpose" it can be used to enroll certificates on behalf of other users and impersonate them using it.

Review the permissions that allow a wide enrollment of this certificate template automatically or specify a specific purpose (EKU)

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_vuln_adcs_template_auth_enroll_with_name)1
[MITRE]T1558 Steal or Forge Kerberos Tickets

The detail can be found in Certificate Templates

Check if authentication certificate templates allow users to control the subject

A-CertTempCustomSubject

The purpose of this rule is to ensure that no certificate request templates allow users to control the subject

Usually, the subject of a certificate is generated automatically by the certification authority.
By allowing editing before its issuance, a malicious user can set the subject to an administrator account, and thus get a certificate representing them.
This certificate can be abused later to impersonate them.

On the certificate template properties, uncheck in the property sheet "Subject Name" the field "Supply in the request".
Alternatively, restrict this template to a specific group.

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_vuln_adcs_template_auth_enroll_with_name)1
[MITRE]T1558 Steal or Forge Kerberos Tickets

The detail can be found in Certificate Templates

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
[MITRE]T1558.001 Steal or Forge Kerberos Tickets: Golden Ticket
[FR]ANSSI - Krbtgt account password unchanged for more than a year (vuln2_krbtgt)2
[FR]ANSSI CERTFR-2014-ACT-032

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
[MITRE]T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting
[FR]ANSSI - Privileged accounts with SPN (vuln1_spn_priv)1

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 all admin accounts require Kerberos pre-authentication

S-NoPreAuthAdmin

The purpose is to ensure that all admin accounts require Kerberos pre-authentication

Without Kerberos pre-authentication, an attacker can request Kerberos data from the domain controller and use this data to brute-force the account password. You can search accounts using the LDAP query (userAccountControl:1.2.840.113556.1.4.803:=4194304)

Edit the property of the involved accounts and select the Account tab. Uncheck "Do not require Kerberos preauthentication". For computers, which don't have the Account tab, you have to manually edit the attribute useraccountcontrol. Subtract 4194304 from the value of the attribute.

5 points per discovery

http://www.harmj0y.net/blog/activedirectory/roasting-as-reps/
[MITRE]T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting
[FR]ANSSI - Kerberos pre-authentication disabled for privileged accounts (vuln1_kerberos_properties_preauth_priv)1

The detail can be found in User information and Computer information

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/
[MITRE]T1201 Password Policy Discovery
[FR]ANSSI - Privileged group members with weak password policy (vuln2_privileged_members_password)2

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

Ensure that dangerous privileges are not granted to everyone by GPO

P-PrivilegeEveryone

The purpose is to ensure that standard users are not granted dangerous privileges

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

Locate the GPO specified in Details and remove the privilege.
Most of the settings are located in :
Computer configuration -> Policies -> Windows Settings ->Security Settings -> Local Policies -> User Rights Assignment.
As an alternative, the file GptTmpl.inf can be manually edited.

15 points per discovery

https://www.romhack.io/slides/RomHack%202018%20-%20Andrea%20Pierini%20-%20whoami%20priv%20-%20show%20me%20your%20Windows%20privileges%20and%20I%20will%20lead%20you%20to%20SYSTEM.pdf
https://www.tarlogic.com/en/blog/abusing-seloaddriverprivilege-for-privilege-escalation/
https://github.com/decoder-it/psgetsystem
https://twitter.com/0gtweet/status/1303427935647531018?s=20
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

The detail can be found in Privileges

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

[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[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

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

Check for Trusts whose security is not maximum

T-SIDFiltering

The purpose is to check if all trusts are protected using the functionality named SID Filtering

SID Filtering is a mechanism used to block account presenting a SID History property. SID History is used to link an existing account to another account and can be used to propagate a compromise through trusts. SID Filtering for domain-to-domain trust is called a quarantine and is disabled by default. SID Filtering to a forest is enabled by default and disabling it is called "enabling SID History".

The algorithm to compute the SID Filtering is:
get the attribute trustDirection and TrustAttributes of the trust object.
if the direction is 0 or 1 or if the trust is intra forest (trustattributes & 32 != 0) then SID Filtering is not applicable.
Then, if the trust is a forest trust (trusattributes & 8 != 0) then
check if /enablesidhistory has been enabled - trustattributes & 64 != 0.
If enabled: SID Filtering is deactivated.
Else if not a forest trust (trustattributes & 8 == 0) then check for the quarantined attribute (trustattributes & 4 != 0).
If the quarantine flag is set, SID Filtering is enabled.

You can use the PowerShell command to get its status:
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().GetSidFilteringStatus('my.domain.to.test.local')

A trust without SID Filtering means either that a migration is in progress or that the domain can be compromised instantly via the trust.
The solution is to complete existing migration ASAP and enable the SID Filtering feature.

If the trust is a domain trust, you should use netdom /quarantine and set it to yes.
If the trust is a forest trust, you should use netdom /enablesidhistory and set it to no.
Do not apply /quarantine on a forest trust: you will break the transitivity of the trust.

100 points if the occurence is greater than or equals than 4
then 80 points if the occurence is greater than or equals than 2
then 50 points if present

https://msdn.microsoft.com/en-us/library/cc237940.aspx
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R16 [paragraph.3.3.1.6]
[FR]ANSSI - Outbound forest trust relationships with sID History enabled (vuln1_trusts_forest_sidhistory)1
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[US]STIG V-8538 - Security identifiers (SIDs) must be configured to use only authentication data of directly trusted external or forest trust.
[FR]ANSSI - Unfiltered outbound domain trust relationship (vuln1_trusts_domain_notfiltered)1

The detail can be found in Trusts section

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

[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[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.

Ensure that all login scripts cannot be modified by any user

P-DelegationLoginScript

The purpose is to ensure that standard users cannot modify login scripts

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

Edit the Access Control List (ACL) of the script object or the directory where the file 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]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[US]STIG V-2370 - The access control permissions for the directory service site group policy must be configured to use the required access permissions.

The detail can be found in GPO Login script

Check if all DC have no constrained delegation with protocol transition.

P-DelegationDCt2a4d

The purpose is to ensure that no constrained delegations with protocol transition are applied to DC

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

You should edit the msDS-AllowedToDelegateTo attribute of the accounts listed below to remove the SPN of the domain controllers involved.

25 points per discovery

[MITRE]T1187 Forced Authentication
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Constrained delegation with protocol transition to a domain controller service (vuln1_delegation_t2a4d)1

The detail can be found in Domain controllers

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

A Delegation is granted to Everyone

P-DelegationEveryone

The purpose is to verify that there is no delegation granted to "Everyone" or to "Authenticated Users"

To delegate control to a OU, access checks can be modified. In case of a misconfiguration, access can be granted to the group "Everyone" or "Authenticated Users".

Review the delegation to remove this permission and if needed, set a more targeted group as recipient of the delegation.

15 points per discovery

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

The detail can be found in Delegations

Check if the guest account is enabled

A-Guest

The purpose is to ensure that the Guest account of the domain is not enabled

The Guest account is a special account whose SID is S-1-5-domain-501. It is used as a non-nominative account to allow anyone to connect to the Active Directory.
Unless there is a justification about its activation, this represents a security issue because anybody can use this account to connect to any computer without any trace.

You have to find the Guest account and disable it.

15 points if present

[MITRE]T1078.003 Valid Accounts: Local Accounts
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Check delegations for the recipient's existence

P-UnkownDelegation

The purpose is to verify that each delegation is linked to an account which exists

In the case where a delegation has been created, where the account can't be translated to a NT account, it means that the delegation is actually from another domain or that the user has been deleted.

To reduce the risk, the easiest way is essentially to remove the delegation

15 points if present

[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
[MITRE]T1187 Forced Authentication

The detail can be found in Delegations

Check for hidden group membership for computer accounts

S-C-PrimaryGroup

The purpose is to check for unusual value in the primarygroupid attribute used to store group membership

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.
This rule can also be triggered if one domain controller is not in the default container (named "Domain Controllers" and located at the root), which is not a recommended practice.

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

15 points if present

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

The detail can be found in User information and Computer information

Check that every account requires a password

S-PwdNotRequired

The purpose is to ensure that every account requires a password

An account can be set without a password if it has the flag "PASSWD_NOTREQD" set as "True" in the "useraccountcontrol" attribute. This represents a high security risk as the account is not protected at all without a password

The best solution to solve the problem is to change the "useraccountcontrol" attribute of all the accounts that have it and that are not used in trusts. If the flag is removed while there is no password set, you will have an error. You can use this to detect accounts without any passwords. Do note that you can manually check all the accounts that need to be worked on using the following PowerShell command: get-adobject -ldapfilter "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32))" -properties useraccountcontrol

15 points if present

https://docs.microsoft.com/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R36 [subsection.3.6]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in User information and Computer information

SIDHistory check

S-SIDHistory

The purpose is to ensure that a migration has been completed correctly and that the SIDHistory attribute has been cleared out from user and computer accounts. This attribute is indeed set when migrating a user or a computer from one domain to another

The SIDHistory attribute is useful when doing a migration because it allows to keep the reference to the former account. On the other hand, once the migration is over, it is mandatory that this attribute is removed to evaluate the permissions in regards with the new account and not the former one.

To solve the security issue, you should remove all the SIDHistory attributes. To do so, you can list the objects having a SIDHistory attribute using the command: get-ADObject -ldapfilter "(sidhistory=*)" -properties sidhistory.
Each security descriptor of the domain, including file shares for example, should be reviewed to be rewritten with the new SID of the account. Then, the attribute can be removed of these accounts using the migration tool or a PowerShell snippet Remove-SIDHistory once the migration is completed.

Please note that once the SID History has been removed, it cannot be added back again without doing a real migration. Possibly hacking tools such as mimikatz could be used to undo a deletion with for example the lsadump::dcshadow attack.

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

5 points per discovery with a minimal of 15 points

[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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

Ensure that files deployed by a GPO cannot be modified by everyone.

P-DelegationFileDeployed

The purpose is to ensure that files deployed to computers cannot be changed by everyone.

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

Locate the file mentioned by the GPO specified in Details and change its permissions.

5 points per discovery

[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[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.

The detail can be found in GPO Deployed Files

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://support.microsoft.com/en-us/help/243330/well-known-security-identifiers-in-windows-operating-systems
[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
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]

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

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

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

Check the Denied RODC Password Replication Group group

P-RODCDeniedGroup

The purpose is to ensure that the Denied RODC Password Replication Group group has at least its default members.

A set of critical objects are being forbidden to replicate in RODC for security reasons.
This permission is set using the Denied RODC Password Replication Group group.
Removing one of the default members of this group remove this protection, and thus, the isolation of RODC.

Add the items which have been identified as missing to the Denied RODC Password Replication Group group.

5 points if present

https://docs.microsoft.com/en-us/services-hub/health/remediation-steps-ad/review-the-removal-of-default-members-from-the-denied-rodc-password-replication-group
[FR]ANSSI - Dangerous configuration of replication groups for read-only domain controllers (RODCs) (denied) (vuln3_rodc_denied_group)3
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6cfc7b50-11ed-4b4d-846d-6f08f0812919
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797
[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 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 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
[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

Ensure that the privilege to log on Domain Controllers are not granted to everyone by GPO

P-LoginDCEveryone

The purpose is to ensure that standard users cannot login to domain controllers

Domain Controllers are critical components of the Active Directory. If an attacker is able to open a session, he will be able to discover insecure backup media or perform a local privilege escalation to become the DC admin and thus the AD admin.
Local logon requires usually physical interaction, which explains why network seggregation is a best practice, but this can be bypassed. Indeed, VNC or remote server management software is a way to perform local logon remotely.
In addition, remote server management software have been the subject of many vulnerabilites, some of them can be exploited even if this software is disabled.

Locate the GPO specified in Details and remove the privilege "Allow log on locally" or "Allow log on through Remote Desktop Services" to "Everyone", "Authenticated Users", "Domain Users" or "Domain Computers".
The settings are located in :
Computer configuration -> Policies -> Windows Settings ->Security Settings -> Local Policies -> User Rights Assignment.
As an alternative, the file GptTmpl.inf can be manually edited.

15 points per discovery

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/allow-log-on-locally
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04197764-1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

The detail can be found in Privileges

Ensure the "automatic administrative logon" feature of the recovery mode is not enabled

P-RecoveryModeUnprotected

The purpose is to check that it is not possible to go into recovery mode without the administrator password

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

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

15 points if present

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[US]STIG V-1159 - The Recovery Console option is set to permit automatic logon to the system.

The detail can be found in Security settings

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

[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[MITRE]T1003.004 OS Credential Dumping: LSA Secrets
[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 - Privileged accounts with never-expiring passwords (vuln1_dont_expire_priv)1
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R11 [subsection.2.5]

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

At least one domain controller is not owned correctly

P-DCOwner

The purpose is to perform a review of which accounts have ownership rights on a domain controller and can then modify their permissions

By default, the "Domain Administrators" group or the "Enterprise Administrators" group are set as owners for "Domain Controllers". Nonetheless, in some cases (for instance when the server has been promoted from an existing server), the owner can be a non-admin person which joined the server to the domain. If this person has still rights over this account, it can be used to take ownership over the whole domain. A chain of compromising events can be designed to take control of the domain by including this account.

To solve this security issue, you should change the ownership of the domain controller to match the "Domain Administrators" group.
To control the ownership of domain controller objects, you can use the following PowerShell command:
Get-ADComputer -server my.domain.to.check -LDAPFilter "(&(objectCategory=computer)(|(primarygroupid=521)(primarygroupid=516)))" -properties name, ntsecuritydescriptor | select name,{$_.ntsecuritydescriptor.Owner}.
To change it you can edit the owner of an object using adexplorer.exe. First, locate the DC object then right click to select properties. Open the security tab and press the advanced button. You then have a new dialog with an owner tab. Select the owner and change it for the domain administrators group. You’re done (no reboot needed).

10 points if present

[FR]ANSSI - Incorrect object owners (vuln3_owner)3
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

The detail can be found in Domain controllers

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

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

The detail can be found in Admin Groups