PingCastle Health Check rules

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

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:

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:

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:

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:

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:

Points:

60 points if present

Documentation:

ANSSI CERTFR-2005-INF-003

Obsolete OS (Windows Vista)

Rule ID:

S-OS-Vista

Description:

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

Technical explanation:

The Windows Vista 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 10. 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*"}

Introduced in:

2.8.0.0

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

Obsolete OS (Windows XP)

Rule ID:

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

Account take over

Members of administrators' groups are a priority target. By misconfiguring their protection, the password of the account can be retrieved by an attacker or it can leverage internal mechanisms of the AD such authentication to act on its behalf.

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.

Check if admin accounts are vulnerable to the kerberoast attack.

Rule ID:

P-Kerberoasting

Description:

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

Technical explanation:

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

Please note that this program skips service accounts having their password changed for less than 40 days ago to allow a mitigation using a password change process.

Advised solution:

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

Introduced in:

2.7.0.0

Points:

5 points per discovery

Documentation:

https://adsecurity.org/?p=3466

Check if there is a policy preventing administrators to connect to unsecured workstations.

Rule ID:

P-LogonDenied

Description:

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

Rule ID:

P-ControlPathIndirectEveryone

Description:

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

Technical explanation:

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

Advised solution:

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

Introduced in:

2.8.0.0

Points:

25 points if present

Documentation:

https://github.com/BloodHoundAD/BloodHound
https://github.com/ANSSI-FR/AD-control-paths

Check if there is a control path involving too much users or computers.

Rule ID:

P-ControlPathIndirectMany

Description:

The purpose is to ensure that there is no control path involving a large number of users.

Technical explanation:

Advised solution:

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

Introduced in:

2.8.0.0

Points:

25 points if the occurence is greater or equals than 200
then 15 points if the occurence is greater or equals than 100
then 10 points if the occurence is greater or equals than 50
then 5 points if the occurence is greater or equals than 20

Documentation:

https://github.com/BloodHoundAD/BloodHound
https://github.com/ANSSI-FR/AD-control-paths

Check if there is an explicit delegation on DNS which is not using the DnsAdmins group.

Rule ID:

P-DNSDelegation

Description:

The purpose is to ensure that no specific delegation has been setup to manage the Microsoft DNS.

Technical explanation:

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

The security descriptor used to grant admin rights is located on the nTSecurityDescriptor attribute of the object CN=MicrosoftDNS,CN=System.

In this case, an explicit delegation has been setup and this delegation is not using the existing DnsAdmins group.

Advised solution:

You should remove the explicit delegation located in the CN=MicrosoftDNS,CN=System container and make the user or group member of the DnsAdmins group.

Introduced in:

2.8.0.0

Points:

5 points if present

Documentation:

https://medium.com/@esnesenon/feature-not-bug-dnsadmin-to-dc-compromise-in-one-line-a0f779b8dc83
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/007efcd2-2955-46dd-a59e-f83ae88f4678

Check if there is the privilege Access Credential Manager as a trusted caller user right has been explicitly granted.

Rule ID:

P-TrustedCredManAccessPrivilege

Description:

The purpose is to ensure that there is no assignment of the SeTrustedCredManAccessPrivilege privilege.

Technical explanation:

The Credential Manger is a vault where credentials are being stored.
This privilege can be used to retrieve the secret data.

Please note that, as today, there is no public POC published to exploit this privilege and no supported API needing that privilege.

Advised solution:

You should edit the GPO and remove the GPO right assignment.

The setting is located in Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.

Introduced in:

2.8.0.0

Points:

5 points if present

Documentation:

https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management
https://docs.microsoft.com/en-us/windows/win32/secauthn/authentication-functions#credentials-management-functions
STIG V-63843 - The Access Credential Manager as a trusted caller user right must not be assigned to any groups or accounts

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:

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.
SeSecurityPrivilege can be use to clear the security event log and shrink it to make events flushed soon. Also read security log and view events where the user inverted the login and its password.

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:

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:

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

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

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

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.

Introduced in:

2.7.0.0

Points:

10 points if present

Check if kerberos delegation can be used to take control of the forest from a trusted forest

Rule ID:

T-TGTDelegation

Description:

The purpose is to ensure that a forest cannot be used to compromise another forest using kerberos delegation

Technical explanation:

A Forest trust is a link between two forests. By default, this trust is secure and prohibits SID History attacks.
However, it allows kerberos delegation by default.
By configuring an uncontrainst delegation on forest A, an attacker located in forest A can collect admin or domain controller credentials, the TGT of the session, of the forest B.
This collection can be forced by using services such as the printer spooler, enabled by default on all domain controllers.
Having collected this TGT, the attacker can then request access to other systems in forest B, by asking for a TGS given the TGT, and then gain control of the whole forest.

Advised solution:

TGT Delegation on forest trusts should be disabled, except for migrations.
You can use netdom to turn the TGT delegation on forest trust OFF.
Example: netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No
As an alternative, you can locate the forest trust and change its LDAP trustattribute from the value 8 to the value 520.

The impact is to have non working services which relies on unconstrained delegation. Resource based delegation is not impacted.

See the official Microsoft recommandations and a script to find potentially impacted services in the links below.

Introduced in:

2.7.0.0

Points:

10 points per discovery

Documentation:

http://www.harmj0y.net/blog/redteaming/not-a-security-boundary-breaking-forest-trusts/
https://techcommunity.microsoft.com/t5/Premier-Field-Engineering/Changes-to-Ticket-Granting-Ticket-TGT-Delegation-Across-Trusts/ba-p/440283/tab/rich
https://support.microsoft.com/en-us/help/4490425/updates-to-tgt-delegation-across-incoming-trusts-in-windows-server

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.

Audit

Check if there is powershell logging enabled.

Rule ID:

A-AuditPowershell

Description:

The purpose is to ensure that Powershell logging is enabled.

Technical explanation:

Powershell is a powerful language, also used by hackers because of this quality. Hackers are able to run programs such as mimikatz in memory using obfuscated commands such as Invoke-Mimikatz.
Because there is no artefact on the disk, the incident response task is difficult for the forensic analysts.
For this reason, we recommend to enable Powershell logging via a group policy, despite the fact that these security settings may be part of the workstation or server images.

Advised solution:

Go to Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell
And enable "Turn on Module logging" and "Turn on Powershell Script Block logging"
We recommend to set "*" as the module list.

Introduced in:

2.8.0.0

Points:

Informative rule (0 point)

Documentation:

https://adsecurity.org/?p=2604
https://docs.microsoft.com/en-us/powershell/scripting/wmf/whats-new/script-logging?view=powershell-6
STIG V-68819 - PowerShell script block logging must be enabled

Check if there is the expected audit policy on domain controllers.

Rule ID:

A-AuditDC

Description:

The purpose is to ensure that the audit policy on domain controllers collect the right set of events.

Technical explanation:

To detect and mitigate an attack, the right set of events need to be collected.
The audit policy is a compromise between too much and too few events to collect.
To solve this problem, the suggested audit policy from adsecurity.org is checked against the audit policy in place.

Advised solution:

Identitfy the Audit settings to apply and fix them.
Beware that there is two places for audit settings:
a) in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policies
b) in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration

Introduced in:

2.8.0.0

Points:

10 points if present

Documentation:

https://adsecurity.org/?p=3299

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.

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:

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

Check if LDAPS is used with weak SSL protocol.

Rule ID:

A-DCLdapsProtocol

Description:

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

Technical explanation:

SSL version 2 and SSL version 3 are considered weak and it is strongly advised to disable them.
The SSL protocols in Windows is provided by the Schannel component.
The Schannel component needs to be tuned in order to not propose these weak protocols. Many guidelines to handle this problem issued by Microsoft do not talk about Schannel but rather IIS. These guidlines are quoted in the documentation section below.

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

To test these protocol, you can use openssl with the following commands:
openssl s_client -connect dc.domain.local:636 -ssl2
openssl s_client -connect dc.domain.local:636 -ssl3

Advised solution:

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

Introduced in:

2.8.0.0

Points:

10 points if present

Documentation:

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

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]
STIG V-3379 - The system is configured to store the LAN Manager hash of the password in the SAM.
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory

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:

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.

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

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

Date: 2020-07-17 - Engine version: 2.8.1.0

Risk model

Stale Objects

Inactive user or computer

Inactive Account check

Inactive computer check

Network topography

Check for completeness of network declaration

Object configuration

Check for hidden group membership for computer accounts

Check for hidden group membership for user accounts

Check for Reversible password used for computer accounts

Check for Reversible password used for user accounts

Check if all accounts do support kerberos pre-authentication

Check that every account requires a password

SIDHistory check

Obsolete OS

Obsolete Domain Controller (Windows 2000)

Obsolete Domain Controller (Windows 2003)

Obsolete OS (Windows 2000)

Obsolete OS (Windows 2003)

Obsolete OS (Windows NT)

Obsolete OS (Windows Vista)

Obsolete OS (Windows XP)

Old authentication protocols

Check for weak algorithm in password hashing (DES algorithm)

DC Vulnerability (SMB v1)

Provisioning

Check the process of registration of computers to the domain

Replication

Duplicate Account check

Vulnerability management

DC Vulnerability (MS14-068)

DC Vulnerability (MS17-010)

Domain Controller Update

Privileged Accounts

Account take over

At least one Administrator Account can be delegated

Check if admin accounts are vulnerable to the kerberoast attack.

Check if there is a policy preventing administrators to connect to unsecured workstations.

ACL Check

A Delegation is granted to Everyone

At least one Domain controller is not owned correctly

Check delegations for the recipient's existence

Check for Dangerous rights found in OU delegation

Check if the behavior DoListObject has been enabled

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

Check if there is a control path involving too much users or computers.

Check if there is an explicit delegation on DNS which is not using the DnsAdmins group.

Check if there is the privilege Access Credential Manager as a trusted caller user right has been explicitly granted.

Ensure that all login scripts cannot be modified by any user

Ensure that bogus Windows 2016 AD prep did not introduce vulnerabilities

Ensure that dangerous privileges are not granted to everyone by GPO

Ensure that Exchange did not introduce security vulnerabilities

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

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

Ensure that GPO items cannot be modified by any user

Ensure that no accounts are subject to unconstrained delegation

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

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

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

Admin control

Check for inactive Administrator Accounts

Check for Native administrator usage

Check for Number of Administrator accounts above the baseline

Check that operators group are empty

Irreversible change

Avoid unexpected schema modifications which could result in domain rebuild

Ensure that the Recycle Bin feature is enabled

Privilege control

Check if Service Accounts are domain administrators

Trusts

Old trust protocol

Check for trusts compatible with NT4

SID Filtering

Check for Trusts whose security is not maximum

SIDHistory

Check for local backdoor stored in SID History

Check if a migration is in progress