Rules evaluated during PingCastle Healthcheck

Date: 2019-07-16 - Engine version: 2.7.0.0

Do not forget that PingCastleReporting can produce a list of all rules in an Excel format.

This model regroup all rules per category. It summarize what checks are performed. Click on a cell to show all rules associated to a category.

Stale ObjectsPrivileged accountsTrustsAnomalies
Inactive user or computer
ACL Check
Old trust protocol
Backup
Network topography
Admin control
SID Filtering
Certificate take over
Object configuration
Irreversible change
SIDHistory
Golden ticket
Obsolete OS
Privilege control
Trust impermeability
Local group vulnerability
Old authentication protocols
Trust inactive
Network sniffing
Provisioning
Pass-the-credential
Replication
Password retrieval
Vulnerability management
Reconnaissance
Temporary admins
Weak password

Stale Objects

Each line represents a rule. Click on a rule to expand it and show the details of it.

Inactive user or computer

By reusing existing objects, whose credentials may be the same among all objects or stored on configuration files or in memory, a third party can take them over.

Inactive Account check

Rule ID:

S-Inactive

Description:

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

Technical explanation:

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

Advised solution:

To mitigate the risk, you should monitor the number of inactive accounts and reduce it as much as possible. A list of all inactive accounts is obtainable through the command: Search-ADaccount -UsersOnly -AccountInactive -Timespan 180.

Points:

10 points if the occurence is greater or equals than 15

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]

Inactive computer check

Rule ID:

S-C-Inactive

Description:

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

Technical explanation:

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

Advised solution:

To mitigate the risk, you should monitor the number of inactive accounts and reduce it as much as possible. A list of all inactive accounts is obtainable through the command: Search-ADaccount -ComputersOnly -AccountInactive -Timespan 180.

Points:

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

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]

Network topography

It is important to have a database of all the assets and control the physical security of the server. If one server is compromised physically, all the secrets of the domain can be exposed.

Check for completeness of network declaration

Rule ID:

S-DC-SubnetMissing

Description:

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

Technical explanation:

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

Advised solution:

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

Introduced in:

2.5.0.0

Points:

5 points if present

Object configuration

By abusing a misconfiguration, an attacker can gain the control of the domain.

Check for hidden group membership for computer accounts

Rule ID:

S-C-PrimaryGroup

Description:

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

Technical explanation:

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.

Advised solution:

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

Points:

15 points if present

Documentation:

https://support.microsoft.com/en-us/help/297951/how-to-use-the-primarygroupid-attribute-to-find-the-primary-group-for

Check for hidden group membership for user accounts

Rule ID:

S-PrimaryGroup

Description:

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

Technical explanation:

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.

Advised solution:

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

Points:

15 points if present

Documentation:

https://support.microsoft.com/en-us/help/297951/how-to-use-the-primarygroupid-attribute-to-find-the-primary-group-for

Check for Reversible password used for computer accounts

Rule ID:

S-C-Reversible

Description:

The purpose is to verify if there are accounts currently running with a reversible password

Technical explanation:

It is possible that domains have accounts with an encryption that can be reversed. 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 DCSync attack

Advised solution:

To remove this risk, there should be no account(s) with reversible encryption. You should remove them by removing the flag "Store password using reversible encryption" on all accounts, so that the cleartext password is removed at the next password change. You can get a list of all the possibly compromised accounts running the following PowerShell command: get-adobject -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=128)" -properties useraccountcontrol

Points:

5 points if present

Check for Reversible password used for user accounts

Rule ID:

S-Reversible

Description:

The purpose is to verify if there are user accounts currently running with a reversible password

Technical explanation:

It is possible that domains have accounts with an encryption that can be reversed. 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 DCSync attack

Advised solution:

To remove this risk, there should be no account(s) with reversible encryption. You should remove them by removing the flag "Store password using reversible encryption" on all accounts, so that the cleartext password is removed at the next password change. You can get a list of all the possibly compromised accounts running the following PowerShell command: get-adobject -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=128)" -properties useraccountcontrol

Points:

5 points if present

Check if all accounts do support kerberos pre-authentication

Rule ID:

S-NoPreAuth

Description:

The purpose is to ensure that all accounts do support kerberos pre-authentication

Technical explanation:

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)

Advised solution:

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

Points:

5 points if present

Documentation:

http://www.harmj0y.net/blog/activedirectory/roasting-as-reps/

Check that every account requires a password

Rule ID:

S-PwdNotRequired

Description:

The purpose is to ensure that every account requires a password

Technical explanation:

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

Advised solution:

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

Points:

15 points if present

Documentation:

https://support.microsoft.com/en-us/kb/305144
ANSSI - Recommandations de sécurité relatives à Active Directory - R36 [subsection.3.6]

SIDHistory check

Rule ID:

S-SIDHistory

Description:

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

Technical explanation:

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.

Advised solution:

To solve the security issue, you should remove all the SIDHistory attributes. To do so, you can list the objects having an 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. Hopefully hacking tools such as mimikatz can be used to undo a deletion with for example the lsadump::dcshadow attack.

Points:

5 points per discovery with a minimal of 15 points

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]

Obsolete OS

Operating systems have a lifecycle where its manufacturer provides patches. If the operating system is not supported anymore, vulnerabilities are not fixed anymore.

Obsolete Domain Controller (Windows 2000)

Rule ID:

S-DC-2000

Description:

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

Technical explanation:

The OS Windows 2000 as a DC is vulnerable to many publicly known exploits such as MS17-010 or MS14-068 and it can no longer be patched. A domain running this OS version should be considered compromised

Advised solution:

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

Points:

40 points if present

Documentation:

STIG V-8551 - The domain functional level must be at a Windows Server version still supported by Microsoft.
ANSSI - Recommandations de sécurité relatives à Active Directory - R12 [subsection.3.1]

Obsolete Domain Controller (Windows 2003)

Rule ID:

S-DC-2003

Description:

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

Technical explanation:

The OS Windows 2003 as a DC is vulnerable to many publicly known exploits such as MS14-068 and it is very complicated to patch it at this date. A domain running this OS version should be considered compromised

Advised solution:

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

Points:

20 points if present

Documentation:

STIG V-8551 - The domain functional level must be at a Windows Server version still supported by Microsoft.
ANSSI - Recommandations de sécurité relatives à Active Directory - R12 [subsection.3.1]

Obsolete OS (Windows 2000)

Rule ID:

S-OS-2000

Description:

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

Technical explanation:

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

Advised solution:

In order to solve this security issue, you should upgrade all the workstations to a more recent version of Windows, starting from Windows 7. Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap –Auto You can replace [-Filter *] by [-Filter {OperatingSystem -Like "Windows Server*"}

Points:

40 points if present

Documentation:

ANSSI CERTFR-2005-INF-003

Obsolete OS (Windows 2003)

Rule ID:

S-OS-2003

Description:

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

Technical explanation:

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

Advised solution:

In order to solve this security issue, you should upgrade all the workstations to a more recent version of Windows, starting from Windows 7. Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap –Auto You can replace [-Filter *] by [-Filter {OperatingSystem -Like "Windows Server*"}

Points:

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

Documentation:

ANSSI CERTFR-2005-INF-003

Obsolete OS (Windows NT)

Rule ID:

S-OS-NT

Description:

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

Technical explanation:

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

Advised solution:

In order to solve this security issue, you should upgrade all the workstations to a more recent version of Windows, starting from Windows 7. Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap –Auto You can replace [-Filter *] by [-Filter {OperatingSystem -Like "Windows Server*"}

Points:

60 points if present

Documentation:

ANSSI CERTFR-2005-INF-003

Obsolete OS (Windows XP)

Rule ID:

S-OS-XP

Description:

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

Technical explanation:

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

Advised solution:

In order to solve this security issue, you should upgrade all the workstations to a more recent version of Windows, starting from Windows 7. Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap –Auto You can replace [-Filter *] by [-Filter {OperatingSystem -Like "Windows Server*"}

Points:

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

Documentation:

ANSSI CERTFR-2005-INF-003

Old authentication protocols

Cryptography and computer power have evolved during the time and the oldest protocols do not provide the same level of security anymore. They can be broken and used to gain control of the domain.

Check for weak algorithm in password hashing (DES algorithm)

Rule ID:

S-DesEnabled

Description:

The purpose is to verify that no weak hashing algorithm such as DES is used to hash the password of the account.

Technical explanation:

DES is very weak algorithm and once assigned to an account, it can be used to sign Kerberos ticket, even though it is easily breakable. It represents a security risk for the kerberos ticket, therefore for the whole AD.

Advised solution:

It is recommended to disable DES as an algorithm in the user configuration dialog or in the "msDSSupportedEncryptionTypes" attribute at LDAP level. It be disabled in the property of an account by unchecking the box "Use Kerberos DES encryption for this account"

Points:

15 points if present

DC Vulnerability (SMB v1)

Rule ID:

S-SMB-v1

Description:

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

Technical explanation:

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

Advised solution:

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 this issues before disabling SMB v1, as it will generates additional errors.

Points:

10 points if present

Documentation:

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
ttps://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1,-smbv2,-and-smbv3-in-windows-vista,-windows-server-2008,-windows-7,-windows-server-2008-r2,-windows-8,-and-windows-server-2012
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory
ANSSI CERTFR-2017-ACT-019
ANSSI CERTFR-2016-ACT-039

Provisioning

It is important to control who can create new objects in the Active Directory. Indeed, its owner may introduced an object in which it has a strong control.

Check the process of registration of computers to the domain

Rule ID:

S-ADRegistration

Description:

The purpose is to ensure that basic users cannot register extra computers in the domain

Technical explanation:

By default, a basic user can register up to 10 computers within the domain. This default configuration represents a security issue as basic users shouldn't be able to create such accounts and this task should be handled by administrators.

Advised solution:

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

Points:

10 points if present

Documentation:

http://support.microsoft.com/?id=243327
http://prajwaldesai.com/allow-domain-user-to-add-computer-to-domain/
http://blog.backslasher.net/preventing-users-from-adding-computers-to-a-domain.html

Replication

Active Directory uses a distributed architecture to have a high level of availability. This architecture replicates each change at a regular interval. Collision of changes can create unexpected objects which can be used later.

Duplicate Account check

Rule ID:

S-Duplicate

Description:

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

Technical explanation:

In order to identify a duplicate account, a check is performed on the "DN" and the "sAMAccountName". Indeed, when a DC detects a conflict, there is a replacement performed on the second object

Advised solution:

Duplicate accounts often means there are weaknesses in term of processes, that is why they should be monitored and removed. To identify all duplicate accounts, you should use the following PowerShell commands: get-adobject -ldapfilter "(cn=*cnf:*)" ; get-adobject -ldapfilter "(sAMAccountName=$duplicate)"

Points:

5 points if present

Vulnerability management

Patching computers is part of the security process. Unpatched vulnerability is a way to gain control of a computer.

DC Vulnerability (MS14-068)

Rule ID:

S-Vuln-MS14-068

Description:

The purpose is to verify if Domain Controller(s) are vulnerable to the MS14-068 vulnerability

Technical explanation:

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

Advised solution:

To fix the security breach, you should pacth the DC as soon as it has been established it was vulnerable. You can verify that using a program in the links: this program will check remotely the last startup time of the DC and evaluate the risk

Points:

100 points if present

Documentation:

https://technet.microsoft.com/en-us/library/security/ms14-068.aspx
ANSSI CERTFR-2014-ALE-011

DC Vulnerability (MS17-010)

Rule ID:

S-Vuln-MS17_010

Description:

The purpose is to verify if Domain Controller(s) are vulnerable to the MS17-010 vulnerability

Technical explanation:

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

Advised solution:

To fix the security breach, you should pacth the DC as soon as it has been established it was vulnerable. Another good remediation is to disable SMB v1 (see "DC Vulnerability (SMB v1)). You can verify that using the github program in the links: this program will check remotely the last startup time of the DC and evaluate the risk

Points:

100 points if present

Documentation:

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

Domain Controller Update

Rule ID:

S-DC-NotUpdated

Description:

The purpose is to ensure that all the Domain Controllers are updated regularly. This is done by checking if a DC has been rebooted in the past 6 months. If not, it means it has not be patched as well in these 6 monthes

Technical explanation:

Domain Controller needs to be updated regularly because threats to the AD evolve all the time, so assets in the AD should evolve accordingly. The date of last update is computed by getting the StatisticsStartTime from [net statistics workstation]. If not available, the PingCastle solution will use the lastLogonTimestamp attribute which is refreshed based on the LastLogon attribute. Do note that there is a maximum delay for refresh: 14 days.

Advised solution:

Frequently updating the DC should be part of the AD policies, as there should be a dedicated time-slot for the servers to reboot and apply security patches

Points:

15 points if present

Documentation:

BSI M 4.315 Aufrechterhaltung der Betriebssicherheit von Active Directory

Privileged Accounts

Each line represents a rule. Click on a rule to expand it and show the details of it.

ACL Check

Delegation is used to perform day to day activities. It is important to control it.

A Delegation is granted to Everyone

Rule ID:

P-DelegationEveryone

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

15 points per discovery

Documentation:

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

At least one Administrator Account can be delegated

Rule ID:

P-Delegated

Description:

The purpose is to ensure that all Administrator Accounts have the configuration flag "this account is sensitive and cannot be delegated"

Technical explanation:

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.

Advised solution:

To correct the situation, you should make sure that all your Administrator Accounts has the check-box "This account is sensitive and cannot be delegated" active. Please not that there is a section bellow in this report named "Admin Groups" which give more information.

Points:

20 points if present

Documentation:

STIG V-36435 - Delegation of privileged accounts must be prohibited.

At least one Domain controller is not owned correctly

Rule ID:

P-DCOwner

Description:

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

Technical explanation:

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.

Advised solution:

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)

Points:

10 points if present

Check delegations for the recipient's existence

Rule ID:

P-UnkownDelegation

Description:

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

Technical explanation:

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.

Advised solution:

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

Points:

15 points if present

Documentation:

STIG V-2370 - The access control permissions for the directory service site group policy must be configured to use the required access permissions.

Check for Dangerous rights found in OU delegation

Rule ID:

P-DangerousExtendedRight

Description:

The purpose is to verify the presence of dangerous rights when a part of the domain is delegated to a third party

Technical explanation:

The right "REANIMATE_TOMBSTONE" used to undelete objects, "UNEXPIRE_PASSWORD" used to undo the expiration of a password, or "SID_HISTORY" used to create an alternate identity is considered dangerous. Indeed this rights can be used to trigger a backdoor.

Advised solution:

Unless there is a strong justification of their presence, these delegations should be removed. In addition, if the origin of this delegation cannot be found, their creation should be investigated as it can be related to a compromise of the domain

Points:

5 points per discovery

Documentation:

https://technet.microsoft.com/en-us/library/ff405676.aspx
ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

Check if the behavior DoListObject has been enabled

Rule ID:

P-DsHeuristicsDoListObject

Description:

The purpose is to check if the DoListObject feature has been enabled

Technical explanation:

The DoListObject is a feature to probihit account located in an OU to look at another OU. It proceed by checking an special ACL named RIGHT_DS_LIST_OBJECT.

Advised solution:

This is an informative rule.
If you want to reverse this behavior to its default value, find the dsHeuristics configuration which is located in CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ad,DC=contoso,DC=com.
Then edit the 3rd character and set it to zero.

Introduced in:

2.7.0.0

Points:

Informative rule (0 point)

Documentation:

https://dirteam.com/sander/2008/12/09/active-directory-visibility-modes/
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/990fb975-ab31-4bc1-8b75-5da132cd4584

Ensure that all login scripts cannot be modified by any user

Rule ID:

P-DelegationLoginScript

Description:

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

Technical explanation:

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

Advised solution:

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.

Introduced in:

2.5.0.0

Points:

15 points per discovery

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
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 bogus Windows 2016 AD prep did not introduce vulnerabilities

Rule ID:

P-DelegationKeyAdmin

Description:

The purpose is to ensure that no weaknesses have been introduced following a Windows 2016 installation.

Technical explanation:

After performing adprep /domainprep from Windows Server 2016 sources there may be an unwanted AccessControlEntry (ACE) in the DiscretionaryACL (DACL) of the targeted domain-naming-context's SecurityDescriptor (SD) that grants FullControl permission to the Enterprise Key Admins group ( SID = ending with -527 ).
This is s a bug in ADPREP that was fixed in Windows Server 2016 RS3/1709. No official fix for those who used pre-1709.
Note: The SID will only be resolvable after the PDC emulator role is transferred to a Windows Server 2016 domain controller.

Advised solution:

After having carefully studied the possible impact of the following change, apply the script made by MSRC and referenced in the documentation below to alter the permission.

Introduced in:

2.6.0.0

Points:

5 points if present

Documentation:

https://gallery.technet.microsoft.com/scriptcenter/Enterprise-Key-Admins-720eb270
https://secureidentity.se/adprep-bug-in-windows-server-2016/
ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

Ensure that dangerous privileges are not granted to everyone by GPO

Rule ID:

P-PrivilegeEveryone

Description:

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

Technical explanation:

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 allow any users 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 reflexion.

Advised solution:

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.

Introduced in:

2.6.0.0

Points:

15 points per discovery

Documentation:

https://www.romhack.io/slides/RomHack%202018%20-%20Andrea%20Pierini%20-%20whoami%20priv%20-%20show%20me%20your%20Windows%20privileges%20and%20I%20will%20lead%20you%20to%20SYSTEM.pdf
https://www.tarlogic.com/en/blog/abusing-seloaddriverprivilege-for-privilege-escalation/
https://github.com/decoder-it/psgetsystem
ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

Ensure that Exchange did not introduce security vulnerabilities

Rule ID:

P-ExchangePrivEsc

Description:

The purpose is to ensure that Exchange Installation did not introduce privilege escalation vulnerabilites by modifying domain permissions

Technical explanation:

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

Advised solution:

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

Or run the powershell script Fix-DomainObjectDACL.ps1 referenced below.

Introduced in:

2.7.0.0

Points:

15 points per discovery

Documentation:

https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1
https://blogs.technet.microsoft.com/exchange/2019/02/12/released-february-2019-quarterly-exchange-updates/
https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server
ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

Ensure that Exchange did not modify the AdminSDHolder object to introduce vulnerabilities

Rule ID:

P-ExchangeAdminSDHolder

Description:

The purpose is to ensure that no weakness has been introduced at Exchange installation.

Technical explanation:

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

Advised solution:

After having carefully studied the possible impact of the following change, alter the AdminSDHolder permissions to remove the Exchange objects.

Introduced in:

2.6.0.0

Points:

5 points if present

Documentation:

https://blogs.technet.microsoft.com/exchange/2009/09/23/exchange-2010-and-resolution-of-the-adminsdholder-elevation-issue/
ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

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

Rule ID:

P-DelegationFileDeployed

Description:

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

Technical explanation:

Application provided in a msi form or general files can be deployed by a GPO. If an attacker can modify one of this file, it can take control of the user account.

Advised solution:

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

Introduced in:

2.7.0.0

Points:

5 points per discovery

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
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 GPO items cannot be modified by any user

Rule ID:

P-DelegationGPOData

Description:

The purpose is to ensure that standard users cannot modify GPO

Technical explanation:

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

Advised solution:

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.

Introduced in:

2.6.0.0

Points:

15 points per discovery

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
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 no accounts are subject to unconstrained delegation

Rule ID:

P-UnconstrainedDelegation

Description:

The purpose is to ensure no account can impersonate any account.

Technical explanation:

When an unconstrained delegation is configured, the kerberos ticket TGT can be captured. This TGT grant then access to any service the user has access. If the user is an administrator or a domain controller (a connection can be forced using the spooler service), the domain can be compromised.

Advised solution:

Replace unconstrained delegation by constrained delegation. In practice, on the account object, tab "delegation", replace "trust this computer for delegation to any service" by "trust this computer for delegation to specified services only".

Introduced in:

2.6.0.0

Points:

5 points per discovery

Documentation:

https://blogs.technet.microsoft.com/389thoughts/2017/04/18/get-rid-of-accounts-that-use-kerberos-unconstrained-delegation/
https://adsecurity.org/?p=1667
ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

Ensure that the AdminSDHolder protection has not been disabled for some critical groups

Rule ID:

P-DsHeuristicsAdminSDExMask

Description:

The purpose is to ensure that the AdminSDHolder mechanism has not been altered

Technical explanation:

The AdminSDHolder service is a protection which prohibits an admin to loose control of the domain after a permission change or to introduce a weakness in the permissions.
It proceed by rewriting every 60 minutes the security descriptor of critical objects.

By modifying the dsHeuristics attribute, this protection can be disabled for one or more critical group.
Each critical group is associated with a value:
Account Operators: 1,
Server Operators: 2,
Print Operators:4,
Backup Operators: 8.
The 16th character of dsHeuristics represents the sum of the values associated to the groups where the AdminSDHolder has been disabled.
To disable it for the 'Backup Operators' and the 'Server Operators', the value is 8 + 2 = 0x0A = 'a'.

Advised solution:

Find the dsHeuristics configuration which is located in CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ad,DC=contoso,DC=com.
Then edit the 16th character and set it to zero.

Introduced in:

2.7.0.0

Points:

5 points if present

Documentation:

https://www.petri.com/active-directory-security-understanding-adminsdholder-object
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5

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

Rule ID:

P-LoginDCEveryone

Description:

The purpose is to ensure that standard users cannot login to Domain Controllers

Technical explanation:

Domain Controllers are critical components of the Active Directory. If an attacker is able to open a session, he will be able to discover unsecure 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.

Advised solution:

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.

Introduced in:

2.7.0.0

Points:

15 points per discovery

Documentation:

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
ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

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

Rule ID:

P-RecoveryModeUnprotected

Description:

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

Technical explanation:

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 any GPO which disable this password prompt.

Advised solution:

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.

Introduced in:

2.7.0.0

Points:

15 points if present

Documentation:

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon
STIG V-1159 - The Recovery Console option is set to permit automatic logon to the system.

Admin control

It is important to know how much administrators are in place and to track the use of emergency accounts

Check for inactive Administrator Accounts

Rule ID:

P-Inactive

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

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

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R36 [subsection.3.6]

Check for Native administrator usage

Rule ID:

P-AdminLogin

Description:

The purpose is to verify if the Native Administrator account is used.

Technical explanation:

The Native Administrator account is the main administrator account, and it is sharing its password with Directory Services Restore Mode password. Since it is the same password, it can be used to take control of the domain even if the account is disabled, notably through a DSync attack. The last login date is retrieved through the LastLogonTimestamp LDAP attribute retrieved from the Active Directory. There is an exception for 35 days to avoid this rule to be triggered at the domain creation.

Advised solution:

To mitigate the security risk, a good practice is to use the Native Administrator account only for emergency, while the daily work is performed through other accounts.
It is indeed strongly recommended to not use this account but to use nominative account for administrators and dedicated account for services.
Do note that the anomaly will be removed 35 days after the last native administrator login.

To track where the administrator account has been used for the last time, we recommend to extract the attribute LastLogon of the administrator account on ALL domain controllers.
It can be done with tools such as ADSIEdit or ADExplorer.
Then, for each domain controller, extract the events 4624 at the date matching the LastLogon date. You will identify the computer and the process at the origin of the logon event.

Please note that PingCastle relies on the attribute LastLogonTimestamp to perform this check. The LastLogonTimestamp attribute is replicated but has a latency of a maximum of 14 days, while LastLogon is updated at each logon and is more accurate but not replicated.

Points:

20 points if the occurence is strictly lower than 35

Documentation:

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models

Check for Number of Administrator accounts above the baseline

Rule ID:

P-AdminNum

Description:

The purpose is to verify if the number of administrator accounts is not disproportionate. Very few users should have domain admin accounts

Technical explanation:

Every domain administrator represents a possible security breach, this is why it is strongly advised to have as few domain administrator accounts as possible

Advised solution:

It is strongly advised to perform a review of which users have domain administrator rights, and to ensure that these rights are actually needed. Indeed, the end goal is to remove as much domain administrator as possible, as very few users actually need these high level rights

Points:

10 points if the occurence is greater or equals than 10

Documentation:

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models
ANSSI - Recommandations de sécurité relatives à Active Directory - R26 [subsection.3.5]
ANSSI - Recommandations de sécurité relatives à Active Directory - R30 [subsubsection.3.5.7]

Check that operators group are empty

Rule ID:

P-OperatorsEmpty

Description:

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

Technical explanation:

Operator groups (account operators, server operators, ...) can take indirect control of the domain. Indeed these groups have write access to critical resources of the domain.

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R27 [subsection.3.5]

Irreversible change

Most of the changes can be reversed. Some not, and it can broke the domain.

Avoid unexpected schema modifications which could result in domain rebuild

Rule ID:

P-SchemaAdmin

Description:

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

Technical explanation:

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 to remove this group membership.

Advised solution:

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

Points:

10 points if present

Documentation:

STIG V-72835 - Membership to the Schema Admins group must be limited
ANSSI - Recommandations de sécurité relatives à Active Directory - R13 [subsection.3.2]

Ensure that the Recycle Bin feature is enabled

Rule ID:

P-RecycleBin

Description:

The purpose is to ensure that the Recycle Bin feature is enabled

Technical explanation:

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

Advised solution:

First, be sure that the forest level is at least Windows 2008 R2.
You can check it with Get-ADForest or in the Domain Information section.
Then you can enable it using the powershell command:
Enable-ADOptionalFeature -identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=test,DC=mysmartlogon,DC=com' -Scope ForestOrConfigurationSet -Target 'test.mysmartlogon.com'

Introduced in:

2.7.0.0

Points:

10 points if present

Privilege control

Privileges are granted to special groups to perform their duty. Sometimes, these privileges can be used to take control of the domain.

Check if Service Accounts are domain administrators

Rule ID:

P-ServiceDomainAdmin

Description:

The purpose is to check for "Service Accounts" in the "Domain Administrator" group

Technical explanation:

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

Advised solution:

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 higher than 20 characters

Points:

15 points if the occurence is greater or equals than 2

Documentation:

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.
ANSSI - Recommandations de sécurité relatives à Active Directory - R11 [subsection.2.5]

Trusts

Each line represents a rule. Click on a rule to expand it and show the details of it.

Old trust protocol

NT4 like trusts do not provide an accurate level of security and by the use of its old protocols, put the domain at risk.

Check for trusts compatible with NT4

Rule ID:

T-Downlevel

Description:

The purpose is to ensure that there is no NT4 compatible trusts

Technical explanation:

A Downlevel trust is a special kind of trust compatible with NT4. The kind of trust can be displayed in the "Active Directory Domains and Trusts" tool.

Advised solution:

Unless the remote party of the trust is a NT4 domain, this trust shouldn't exist. It should be recreated.

Points:

20 points if present

Documentation:

https://msdn.microsoft.com/en-us/library/cc223771.aspx

SID Filtering

Isolation of domain is critical to avoid a global compromission.

Check for Trusts whose security is not maximum

Rule ID:

T-SIDFiltering

Description:

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

Technical explanation:

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 use 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')

Advised solution:

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.

Points:

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

Documentation:

https://msdn.microsoft.com/en-us/library/cc237940.aspx
STIG V-8538 - Security identifiers (SIDs) must be configured to use only authentication data of directly trusted external or forest trust.
ANSSI - Recommandations de sécurité relatives à Active Directory - R16 [paragraph.3.3.1.6]
BSI M 4.314 Sichere Richtlinieneinstellungen für Domänen und Domänen-Controller

SIDHistory

When doing migrations, a double identity may be attributed. It can have side effects up to the compromission of the domain.

Check for local backdoor stored in SID History

Rule ID:

T-SIDHistorySameDomain

Description:

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

Technical explanation:

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.

Advised solution:

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.

Points:

50 points if present

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]

Check if a migration is in progress

Rule ID:

S-Domain$$$

Description:

The purpose is to ensure that the SID History creation is not enabled

Technical explanation:

To migrate accounts to another domain, the attribute SID History should be added to the new account. Despite the fact that numerous hacking tools such as mimikatz allows the creation of the SID History attribute, its official creation requires the presence of a special auditing group named DOMAIN-$$$ such as TEST-$$$ for the TEST domain.

Advised solution:

If a migration is in progress, declare it in PingCastle so this rule won't be triggered. Else, remove this auditing group. You can locate it by using the LDAP query (sAMAccountNmae=*$$$)

Points:

5 points if present

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]

Check if the account has been migrated from a domain which doesn't exist anymore

Rule ID:

T-SIDHistoryUnknownDomain

Description:

The purpose is to ensure that every account having an SID History is part of an active migration.

Technical explanation:

When accounts are migrated from one domain to another, the attribute SID History can be appended to the new account to keep track of its former account. The origin can be tracked by removing the last digit of the SID to guess the SID of the origin domain. If the SID of the origin domain cannot be resolved, that means that the domain has been removed and as consequence that the SID History is not needed. This SID History information can be used to give additional rights and thus alter the real security rights.

Advised solution:

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 SID History attribute should be removed. Please note that once the SID History has been removed, it cannot be added back again without doing a real migration. Hopefully hacking tools such as mimikatz can be used to undo a deletion with for example the lsadump::dcshadow attack.

Points:

10 points per discovery

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]

Trust impermeability

A trust is a technical boundary which should not be altered.

Check if files deployed may be located in a trusted domain

Rule ID:

T-FileDeployedOutOfDomain

Description:

The purpose is to ensure that a compromised domain cannot use file deployed by GPO to compromise other domains

Technical explanation:

Files deployed (Application as msi, file copied by GPO, ...) can be stored in any file share available in the network and that includes trusted domains shares. If such file is located in a compromise domain, it can be used to compromise other domains.

Advised solution:

Copy the file to a share located inside the domain and not in trusted domains.

Points:

10 points if present

Check if login scripts may be located in a trusted domain

Rule ID:

T-ScriptOutOfDomain

Description:

The purpose is to ensure that a compromised domain cannot use scripts located in it to compromise other domains

Technical explanation:

Login script can be stored in any file share available in the network and that includes trusted domains shares. If a login script is located in a compromise domain, it can be used to compromise other domains.

Advised solution:

Copy the login script to a share located inside the domain and not in trusted domains.

Points:

10 points if present

Trust inactive

Any trust introduce a risk. The secret used for the trust can be exposed to take control of the domain.

Check for inactive trusts

Rule ID:

T-Inactive

Description:

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

Technical explanation:

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 being changed and that there was either a problem with the remote domain or that the remote domain does not exist anymore.

Advised solution:

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. Indeed the secret used by the trust can be used to issue fake kerberos tickets and be used as a backdoor.

Points:

20 points if present

Documentation:

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

Anomalies

Each line represents a rule. Click on a rule to expand it and show the details of it.

Backup

Althought Active Directory has been designed for redundancy, a backup process is key for a recovery plan.

Check for the last backup date according to Microsoft standard

Rule ID:

A-BackupMetadata

Description:

The purpose is 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

Technical explanation:

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

Advised solution:

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:

Points:

15 points if the occurence is greater or equals than 7

Documentation:

https://technet.microsoft.com/en-us/library/jj130668(v=ws.10).aspx
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.

Ensure that there are enough DCs to provide basic redundancy

Rule ID:

A-NotEnoughDC

Description:

The purpose is to ensure the failure of one domain controller will not stop the domain.

Technical explanation:

A single domain controller failure can lead to a lack of availability of the domain if the number of servers is too low. To have a minimum redundancy, the number of DC should be at least 2. For Labs, this rule can be ignored and you can add this rule into the exception list.

Advised solution:

Increase the number of domain controllers by installing new ones.

Introduced in:

2.6.0.0

Points:

5 points if the occurence is strictly lower than 2

Documentation:

https://social.technet.microsoft.com/wiki/contents/articles/14355.capacity-planning-for-active-directory-domain-services.aspx

Certificate take over

Certificates are an alternative to passwords. Their protection is crucial to avoid any backdoor.

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

Rule ID:

A-WeakRSARootCert

Description:

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

Technical explanation:

A RSA key certificate with a modulus under 1024 bits is considered as not safe

Advised solution:

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

Points:

5 points if present

Documentation:

https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/commercial-national-security-algorithm-suite-factsheet.cfm
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Intermediate Certificates using unsafe hashing algorithm (MD2)

Rule ID:

A-MD2IntermediateCert

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

10 points if present

Documentation:

https://www.ssi.gouv.fr/archive/fr/sciences/fichiers/lcr/mu04c.pdf
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Intermediate Certificates using unsafe hashing algorithm (MD4)

Rule ID:

A-MD4IntermediateCert

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

10 points if present

Documentation:

https://tools.ietf.org/html/rfc6150
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Intermediate Certificates using unsafe hashing algorithm (MD5)

Rule ID:

A-MD5IntermediateCert

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

https://www.kb.cert.org/vuls/id/836068
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Intermediate Certificates using unsafe hashing algorithm (SHA0)

Rule ID:

A-SHA0IntermediateCert

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

https://tools.ietf.org/html/rfc6194
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Intermediate Certificates using unsafe hashing algorithm (SHA1)

Rule ID:

A-SHA1IntermediateCert

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

1 points if present

Documentation:

https://tools.ietf.org/html/rfc6194
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Root Certificates using unsafe hashing algorithm (MD2)

Rule ID:

A-MD2RootCert

Description:

The purpose is to ensure that there is no use of the MD2 hashing algorithm in Root Certificate

Technical explanation:

The MD2 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. Nevertheless, the root certificate algorithm has no direct impact on the security, but it can be used indirectly to force the use of this algorithm in the issued certificate

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://www.ssi.gouv.fr/archive/fr/sciences/fichiers/lcr/mu04c.pdf
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Root Certificates using unsafe hashing algorithm (MD4)

Rule ID:

A-MD4RootCert

Description:

The purpose is to ensure that there is no use of the MD4 hashing algorithm in Root Certificate

Technical explanation:

The MD4 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. Nevertheless, the root certificate algorithm has no direct impact on the security, but it can be used indirectly to force the use of this algorithm in the issued certificate

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://tools.ietf.org/html/rfc6150
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Root Certificates using unsafe hashing algorithm (MD5)

Rule ID:

A-MD5RootCert

Description:

The purpose is to ensure that there is no use of the MD5 hashing algorithm in Root Certificate

Technical explanation:

The MD5 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. Nevertheless, the root certificate algorithm has no direct impact on the security, but it can be used indirectly to force the use of this algorithm in the issued certificate

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://www.kb.cert.org/vuls/id/836068
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Root Certificates using unsafe hashing algorithm (SHA0)

Rule ID:

A-SHA0RootCert

Description:

The purpose is to ensure that there is no use of the SHA0 hashing algorithm in Root Certificate

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://tools.ietf.org/html/rfc6194
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Check for Root Certificates using unsafe hashing algorithm (SHA1)

Rule ID:

A-SHA1RootCert

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://tools.ietf.org/html/rfc6194
STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).

Golden ticket

There are key secrets in Active Directory which provides seed to the cryptographic process. A leak can lead to a total compromise of a domain.

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

Rule ID:

A-Krbtgt

Description:

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.

Technical explanation:

Kerberos is an authentication protocol. It is using to sign its tickets a secret stored as the password of the krbtgt account. If the hash of the password of the krbtgt account is retrieved, it can be use to generate authentication tickets at will.
To mitigate this attack, it is recommended to change the krbtgt password every 40 days. If it 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.

Advised solution:

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 8 hours between each krbtgt password change.

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. Unfortunately this script supports only English operating systems.
Second, a more manual way is to essentially reset the password manually once, then to wait 3 days, then to reset it again. This is the safest way as it ensures the password is no longer usable by the Golden ticket attack.

Points:

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

Documentation:

https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51
ANSSI CERTFR-2014-ACT-032

Local group vulnerability

the GPO deploy settings which are applied to computers locally and it can be abuse to take control of individual computers.

Check if access to a restricted group is given to anyone by a GPO

Rule ID:

A-MembershipEveryone

Description:

The purpose is to identify if there are restricted group such as local administrators, terminal server access, … where Authenticated Users or Everyone is being granted access by a GPO

Technical explanation:

It is possible that a GPO add local membership of a restricted group. In this case the rule trigger if one is found with "Everyone" or "Authenticated Users" as members. It basically means that the Restricted Group has no restriction on belongs to it. This represents a security risk as Restricted Group are supposed to have more accesses or rights

Advised solution:

In order to correct the issue, you should edit the GPO and remove the "Members" security access rule. Another solution is to change the group by a more targeted one containing a limited set of users.

Points:

15 points per discovery

Documentation:

http://social.technet.microsoft.com/wiki/contents/articles/20402.active-directory-group-policy-restricted-groups.aspx

Network sniffing

Network attacks such as interception or modification can be used to run commands on behalf an administrator.

Check for GPO enabling the unsafe algorithm LM hash

Rule ID:

A-LMHashAuthorized

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

ANSSI - Recommandations de sécurité relatives à Active Directory - R37 [paragraph.3.6.2.1]
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory
STIG V-3379 - The system is configured to store the LAN Manager hash of the password in the SAM.

Check if LLMNR can be used to steal credentials

Rule ID:

A-NoGPOLLMNR

Description:

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

Technical explanation:

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

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

Advised solution:

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

Introduced in:

2.7.0.0

Points:

Informative rule (0 point)

Documentation:

https://youtu.be/Fg2gvk0qgjM

Check if the file share protocol can sign its network dialog

Rule ID:

A-SMB2SignatureNotEnabled

Description:

The purpose is to ensure that the SMB version 2 protocol has the signature enabled when communicating with domain controllers

Technical explanation:

Python responder is a tool used to compromise a domain by listening for SMB connections and injecting rogue data into the communications at the network level. SMB v1 does not provide a mechanism to enforce integrity and thus is compromised easily. SMB v2 (and subsequent version SMB v3) provides a way to guarantee the integrity of the network communication via a signature of each packet. By establishing a SMB v2 dialog with domain controllers, PingCastle checks the signature capability by looking at the SMB options provided by the server.

Advised solution:

Enable the group policy "Digitally sign communications (if client agrees)" or check for any policy which may alter the server settings

Introduced in:

2.5.0.0

Points:

5 points if present

Documentation:

https://msdn.microsoft.com/en-us/library/cc246675.aspx
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory
ANSSI CERTFR-2015-ACT-021

Check if the file share protocol requires its client to sign its network dialog

Rule ID:

A-SMB2SignatureNotRequired

Description:

The purpose is to ensure that the SMB version 2 protocol has the signature enforced when communicating with domain controllers

Technical explanation:

Python responder is a tool used to compromise a domain by listening for SMB connections and injecting rogue data into the communications at the network level. SMB v1 does not provide a mechanism to enforce integrity and thus is compromised easily. SMB v2 (and subsequent version SMB v3) provides a way to guarantee the integrity of the network communication via a signature of each packet. By establishing a SMB v2 dialog with domain controllers, PingCastle checks the signature capability by looking at the SMB options provided by the server.

Advised solution:

Enable the group policy "Digitally sign communications (always)" or check for any policy which may alter the server settings

Introduced in:

2.5.0.0

Points:

Informative rule (0 point)

Documentation:

https://msdn.microsoft.com/en-us/library/cc246675.aspx
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory
ANSSI CERTFR-2015-ACT-021

Ensure LDAP signing requirements is not set to None

Rule ID:

A-LDAPSigningDisabled

Description:

The purpose is to check that the integrity of the network protocol LDAP as not been explicitly disabled.

Technical explanation:

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.

Advised solution:

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.

Introduced in:

2.7.0.0

Points:

5 points if present

Documentation:

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory
ANSSI CERTFR-2015-ACT-021
STIG V-3381 - The Recovery Console option is set to permit automatic logon to the system.

Pass-the-credential

If the password is a secret which protects, its derivatives, such as the fingerprint named hash, can be used as if it was the password itself.

Check for Accounts using Smart Card with unchanged password for a long time

Rule ID:

A-SmartCardRequired

Description:

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

Technical explanation:

Using Smart Card to protected sensitive account 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

Advised solution:

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 2016 and later versions and handle 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 internally a password hash change.

Points:

30 points if present

Documentation:

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

Check for presence of the Protected users group

Rule ID:

A-ProtectedUsers

Description:

The purpose is to ensure that the schema has been updated for the creation of Protected Users group.

Technical explanation:

The Protected Users group is a special group which is a very effective mitigation solution to counter attacks using Credential theft starting with Windows 8.1. Older Operating System must be updated to take this protection in account such as the Windows 7 KB2871997 patch.

Advised solution:

The Protected Users group is automatically created when a Windows 2012 R2 domain controller is installed and upgraded to a PDC (primary DC). The group is then be automatically created and replicated.
Warning: Do not add service account into this group as this will result in "authentication failure" messages. Use "protected accounts" instead

Points:

Informative rule (0 point)

Documentation:

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
STIG V-78131 - Accounts with domain level administrative privileges must be members of the Protected Users group in domains with a domain functional level of Windows 2012 R2 or higher.
ANSSI CERTFR-2017-ALE-012

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

Rule ID:

A-LAPS-Not-Installed

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

15 points if present

Documentation:

https://www.microsoft.com/en-us/download/details.aspx?id=46899
STIG V-36438 - Local administrator accounts on domain systems must not share the same password.
ANSSI CERTFR-2015-ACT-046

Ensure that Domain Controllers don't deny the change of computers account password.

Rule ID:

A-DCRefuseComputerPwdChange

Description:

The purpose is to check that the computer account password can be changed as usual.

Technical explanation:

For each computer, there is a hidden user account. This account is used to maintain the computer inside the Active Directory domain.
The password of this account is changed every 30 days automatically except if the Domain Controller prohibits this.
This is the case when the GPO is enabled.

Advised solution:

Locate the GPO specified in Details and change the setting in "Domain controller: Refuse machine account password changes".
Disable this setting, or set it to "Disabled".
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.

Introduced in:

2.7.0.0

Points:

5 points if present

Documentation:

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes
STIG V-4408 - The domain controller must be configured to allow reset of machine account passwords.

Ensure that the printer spooler cannot be abused to get the DC Credentials

Rule ID:

A-DC-Spooler

Description:

The purpose is to ensure that credentials cannot be extracted from the DC via its printer spooler

Technical explanation:

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

Advised solution:

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

Introduced in:

2.6.0.0

Points:

10 points if present

Documentation:

https://adsecurity.org/?p=4056
https://www.slideshare.net/harmj0y/derbycon-the-unintended-risks-of-trusting-active-directory

Password retrieval

Passwords stored in clear text or obfuscated can be retrieved. By reusing the user's identity, an attacker does not need to perform attack and it is difficult to detect it.

Check for GPO which enable reversible passwords

Rule ID:

A-ReversiblePwd

Description:

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

Technical explanation:

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 DCSync attack.

Advised solution:

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

Points:

10 points if present

Documentation:

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption

Find Password GPO

Rule ID:

A-PwdGPO

Description:

The purpose is to alert when a clear text password has been identified in the GPO. Regardless of whether the password is present or not, both the account and password should be considered compromised

Technical explanation:

A check is performed to identify passwords in the GPO. If a password is identified through the PingCastle solution, it means that it can be identified through many other means by attackers, and that the account should be considered compromised.
Do note that the AES key used to encrypt passwords in GPOs has been made public for interoperability reasons, which is why even an encrypted password is compromised. It has been revealed in this page

Advised solution:

In order 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 the LAPS solution.

Points:

20 points per discovery

Documentation:

https://msdn.microsoft.com/en-us/library/cc422924.aspx
ANSSI CERTFR-2015-ACT-046

Reconnaissance

At the begining of an attack, a hacker try to collect as much data as possible. Leaking information just reduce the time an attacker needs to gain control of the domain.

Check for access without any account via a forest wide setting

Rule ID:

A-DsHeuristicsAnonymous

Description:

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

Technical explanation:

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 fLDAPBlockAnonOps can be set to allow access without any account on the whole forest level.
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.

Advised solution:

The easiest and fastest way to correct this issue is to replace the seventh (7th) character of the DsHeuristics attribute. If it is a 2, replace by 0 to fix the issue.

Points:

5 points if present

Documentation:

https://msdn.microsoft.com/en-us/library/cc223560.aspx
https://support.microsoft.com/en-us/help/326690/anonymous-ldap-operations-to-active-directory-are-disabled-on-windows
STIG V-8555 - Anonymous Access to AD forest data above the rootDSE level must be disabled.

Check for GPO granting access to the domain without any account

Rule ID:

A-AnonymousAuthorizedGPO

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

https://technet.microsoft.com/en-us/library/cc963223.aspx https://technet.microsoft.com/en-us/library/jj852184.aspx
STIG V-14798 - Directory data (outside the root DSE) of a non-public directory must be configured to prevent anonymous access.

Check for Windows 2000 compatibility which allows access to the domain without any account

Rule ID:

A-PreWin2000Anonymous

Description:

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

Technical explanation:

When a Windows 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].

Advised solution:

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

Points:

5 points if present

Documentation:

https://msdn.microsoft.com/en-us/library/cc223672.aspx
STIG V-8547 - The Anonymous Logon and Everyone groups must not be members of the Pre-Windows 2000 Compatible Access group.
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory

Retrieve data from the domain without any account

Rule ID:

A-NullSession

Description:

The purpose is to access without any account, aka NULL Sessions, 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

Technical explanation:

Unless other rules which check for known cause of anonymous access, this rule tries to enumerate accounts from the domain without any account. The program use two methods: MS-SAMR with a NULL connection and MS-LSAT which forces SID resolution with well known SID.
NULL sessions are deactivated by default since Windows 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].

Advised solution:

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.

Points:

10 points if present

Documentation:

https://www.sans.org/reading-room/whitepapers/windows/null-sessions-nt-2000-286
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory
STIG V-14798 - Directory data (outside the root DSE) of a non-public directory must be configured to prevent anonymous access.

Temporary admins

Administrators grant sometimes privileged rights to colleagues without any approval from a security officer.

Check for suspicious account(s) used in administrator activities

Rule ID:

A-AdminSDHolder

Description:

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

Technical explanation:

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.

Advised solution:

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.

Points:

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

Documentation:

https://msdn.microsoft.com/en-us/library/ms675212(v=vs.85).aspx
ANSSI - Recommandations de sécurité relatives à Active Directory - R40 [paragraph.3.6.3.1]

Weak password

Misprotected credentials can be abused to be retrieved in plain text and then, impersonate the user.

Check for GPO allowing accounts without password to be accessed from the network

Rule ID:

A-LimitBlankPasswordUse

Description:

The purpose is to identify if accounts without password are allowed to be accessed from the network. This represents a high risk, as an account without a password is essentially an account that cannot be assigned to anyone.

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

https://technet.microsoft.com/en-us/library/jj852174.aspx

Check for Short password length in password policy

Rule ID:

A-MinPwdLen

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

10 points if present

Documentation:

https://www.microsoft.com/en-us/research/publication/password-guidance/
BSI M 4.314 Sichere Richtlinieneinstellungen für Domänen und Domänen-Controller

Check the Password Policy for Service Accounts (Information)

Rule ID:

A-NoServicePolicy

Description:

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 behind Kerberoast attack (offline crack of the TGS tickets)

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://www.microsoft.com/en-us/research/publication/password-guidance/